В больших компаниях редко возникает вопрос «Что собой представляют эти новомодные методики и технологии?», скорее «Как мы можем их у себя применить?».

DevOps существует почти 10 лет, и в последние два-три года большие нормальные организации уже освоились с премудростями DevOps. («Но что такое этот ваш DevOps?!» — вероятно, подумали вы. Договоримся, что это «улучшение качества вашего ПО за счёт ускорения цикла релизов с помощью облачных методик и автоматизации, а также с помощью дополнительных преимуществ ПО, которое остаётся в production».)

Когда Мэтта Карри, менеджера по Agile-трансформации в компании Allstate, спросили о применении DevOps, он ответил: «Думаю, когда айтишники его опробуют, то уже никогда не будут работать по-другому». Вероятно, вы слышите подобное вновь и вновь, когда речь заходит про внедрение DevOps.

Хотя внесение улучшений и изменений часто кажется чем-то, что не может произойти в вашей организации, результаты слишком заманчивы, чтобы их игнорировать, да и бизнес ожидает от ИТ последовательного наращивания возможностей и эффективности. Как сказал Джон Митчелл, директор по цифровой стратегии и поставке компании Duke Energy: «Согласно нашим бизнес-результатам, стало в 10 раз лучше».

Меньше аналитического паралича, больше непрерывного планирования

Сосредоточенность на улучшении ПО с помощью методик DevOps требует смены образа мышления в организации. Даже спустя 20 лет якобы практикования Agile, разработка ПО традиционно считается длительным проектом, который выполняется ради соответствия множеству требований и ориентирован на определённую дату релиза. Медленные и осторожные Agile Release Trains и процессы планирования также мешают увеличивать ежегодное количество релизов, становясь преградой для циклов обратной связи, которые помогают улучшать приложения в рамках «мелкосерийной» разработки.

В то же время, многие организации перешли в разработке ПО на проектно-ориентированный подход. Это означает, что ИТ-персонал и подрядчики вынуждены заранее проводить огромную аналитическую работу и брать на себя массу обязательств, которые потом используются для управления ими ради выдерживания графика работ.

Чтобы ИТ специалисты могли продемонстрировать ответственный подход к работе, и чтобы бизнес мог в этом удостовериться, объем каждой задачи должен был быть определен точно, ограничен и согласован заранее. Всю деятельность приходится объединять в проекты, которые превратились в единицы работы с определёнными набором результатов, началом и концом.

Сейчас шибко подкованные фанаты Agile ткнут пальцем: «Да, но как узнать, что создаваемое ПО действительно полезно?» Это как раз и есть цель всех упомянутых выше методов контроля.

Более современный взгляд на создание приложения подразумевает, что облик будущего ПО должен формироваться на основе систематического исследования нужд и желаний пользователей, изучения, какие решения срабатывают (и какие нет!), сборки приложения и наблюдения за тем, как люди его используют, а затем весь процесс начинается заново.

Обычно у разработчиков есть лишь смутное представление о том, что должно делать будущее приложение, пока они не начали над ним работать. Многие попадают в традиционную ловушку: думают, что глубоко понимают решаемую задачу и абсолютно точно представляют, к чему идут. Но зачастую оказывается, что команда считает нужным идти на юг, а в результате выясняется, что идти надо было на север.

Это означает, что гораздо меньше времени тратится не только на предварительное планирование, но и на последующие проверки, насколько точно разработчики следуют плану. Вместо того, чтобы проверять статусы проектов, вы должны проверять, поставлено ли что-то ценное для бизнеса в виде полезного ПО.

Управление проектом

Со всеми этими разговорами о «продуктах, а не проектах», вы наверняка надеетесь, что всех этих управленцев из руководства проектами можно гнать поганой метлой. В определённой степени это верно. Но, как отмечают многие, отдел управления проектами всё же нужен, особенно для достаточно сложных приложений.

Недавно, после долгого внутреннего монолога на тему DevOps в крупной копании, проницательный менеджер проекта столкнулся с необходимостью модернизации критически важного программного решения, реализованного как «крысиное гнездо», но ему помешали устаревшие сервисы. Это было странное сочинение из длинного списка межсервисных зависимостей, инструкций, COTS-использований, особенностей данных и интеграций. Помню, как мой язвительный персонаж сказал: «Ага. Похоже, тут необходимо управление проектом. Удачи. Следующий вопрос!»

Не столь речистый, Мэтт Карри изложил своё видение эвристики по использованию управления проектами enterprise-уровня. «Отдел управления проектами крайне полезен в случае больших объёмов разработки и длинного цикла обратной связи. Когда объёмы становятся значительно меньше, а цикл обратной связи укорачивается, уменьшается и потребность в управлении проектами. Ещё управление проектами полезно, когда у вас есть много внешних координаций».

Финансы

Работа с финансированием в DevOps-ориентированных компаниях требует некоторой аккуратности. Как было раньше: поскольку ИТ-департамент сам приобретал средства для разработки, QA и Staging среды требовали капитальных вложений (CAPEX). Необходимые серверы были каплей в море по сравнению с количеством оборудования, нужного для production, его стоимость даже превышала CAPEX. А благодаря DevOps-подходу, который обычно базируется на использовании публичных облачных сервисов, эти затраты переносятся на операционные расходы (OPEX).

Конечно, команды разработчиков любят работать по OPEX-модели, потому что это ускоряет финансовое планирование и создание рабочей инфраструктуры, что позволяет быстрее создавать и выпускать ПО. Но если бухгалтерия не будет внимательно отслеживать расходы, это может закончиться плачевно.

Поясню: операционные расходы на среды для подготовки ПО к production могут выглядеть меньше заранее потраченных капитальных вложений, однако, когда приложение переходит в production, операционные расходы могут начать множиться, словно водоросли в стоячем пруду. Это особенно характерно для успешных приложений, которые переваривают выделенные на операционные расходы средства с непредсказуемой скоростью. Если вы можете эффективно управлять 10 000 серверов в production, то с точки зрения финансов целесообразнее построить собственный ЦОД. Размер экономии в этом случае всегда будет предметом споров (учитывая, что и производители серверов постоянно подпитывают наши опасения, неуверенность и сомнения), но с точки зрения финансов лучше внимательно следить, где именно должны выполняться вычисления и как это повлияет на планирование.

Избавляемся от тикетов

Учитывая обещание привести в порядок процессы управления релизами и приобретения ИТ-ресурсов, неудивительно, что перемены приходят и в традиционное управление ИТ-сервисами. Уменьшается доля и роль тикетов в процессе разработки. Джон Митчелл: «Это так приятно, когда не нужно просить, планировать и ждать появления инфраструктуры. Команда “облачных” инженеров, сидящих вместе с разработчиками, может решать проблемы в реальном времени, а не ждать закрытия своих тикетов. Так здорово наблюдать, как один из наших мобильных разработчиков-хипстеров по-приятельски общается со здоровенным брутальным ops-инженером».

Такая наглядная и измеримая метрика — хороший способ мотивировать всех этих BOFH. «Сначала было трудно их задобрить, но, когда они увидели, что привычные 35-40 заявок в неделю превращаются почти в 0, это их убедило».

Но подумайте обо всех этих несчастных CAB!

Далее следуют попытки впихнуть невпихуемое: «Если я делают 8-15 релизов в неделю, то как мне пройти через все эти комитеты по изменениям (CAB, Change Advisory Board)?». Вне зависимости от приносимой ими пользы, необходимо ускорить работу CAB, которые, скорее, «насоветуют» столько, что вам рано или поздно придётся сознаться в диверсиях относительно принятой в компании политики разработки архитектуры ПО. В большинстве компаний, с которыми я общался, делается упор на автоматизацию, построение конвейеров, платформы. Также очевидно, что обычно нужно еще и заменить от 9 до 5 Enterprise-архитекторов (как именно — пока неясно).

Определённую помощь в проверке развертывания ПО в production могут оказать инструменты вроде Chef’s InSpec. При этом нативные облачные платформы, вроде различных дистрибутивов Cloud Foundry, Red Hat OpenShif и Istio, содержат компоненты, помогающие превратить CAB в роботов.

Начало

Итак, вместо всех этих предварительных планирований и размышлений, у нас есть способ выбора и упорядочивания ваших первых приложений в соответствии с DevOps. Огромный совет от тех, кто это уже сделал — или понял, что пора сделать: начинайте с малого. Джон Митчелл: «Мы начали понемногу, и потом заметили, что в это втягивается всё больше бизнеса».

Источники, близкие к компании Home Depot, широко рассказывают о том, что там начинали с малых проектов, постепенно переходя к более крупным. Эти начальные проекты назывались «научными», но имели настоящую ценность для бизнеса (например, организация мест для покраски и использования арендованных инструментов). Успех таких проектов означает создание бизнес-ценности (читай: меньше отстоя, больше денег). С другой стороны, по мере того, как вы будете узнавать больше о применении DevOps, сопутствующие ошибки будут играть меньшую роль, чем, к примеру, падение .com-сайта.

Правда, иногда приходится сразу делать большие ставки. В целом, всё зависит от потока денежных средств в компании. Начинать с малого не так рискованно, но операционная/финансовая ситуация может заставить вас пойти ва-банк.

Как только вы решили, над каким приложением будете работать, начинается процесс продумывания хорошего дизайна. Но вместо того, чтобы заниматься только предварительным анализом и составлением спецификаций (как вы предполагали!), дизайнеры участвуют в течение всего процесса разработки. Это подразумевает перемены в мышлении и организации как самих дизайнеров, так и других подразделений: они будут взаимодействовать каждый день, а не наблюдать со стороны из своих уютных кабинетиков.

Самый лёгкий день— вчерашний

Как только мы заводим двигатель, его нужно обслуживать, что обычно меняет представление об управлении. Компании нужно постоянно уменьшать потери времени на выполнение тикетов и очереди на code review, неустанно повышая эффективность где только можно. Самой важной и полезной частью DevOps является принцип, позаимствованный прямо из концепции «бережливого производства» — постоянное улучшение. Сам DevOps тоже изменяется по мере того, как технологии автоматизируют некоторые «ручные» операции, а большие компании нарабатывают всё больше знаний, возможно, даже «убивая» потом DevOps и внедряя ему на смену что-то новое.

На руководящем уровне этот акцент на постоянное обучение подразумевает создание и поддержание компании, которая всё время совершенствуется, и даже полностью изменяется. MBA-зануды называют это «ощущением безотлагательности» (Sense of Urgency). И, как давно уже известно, если в компании нет этого стремления к переменам, то ничего и не произойдёт. В последние годы я не раз наблюдал: пока не возникнет какой-то внешней угрозы для компании — гхм-гхм, Amazon, гхм — мало что изменится, невзирая на любые приказы руководства или старания молодого DevOps-эксперта. Но, как любят цитировать мои более мрачные коллеги: «It is not necessary to change. Survival is not mandatory». («Нет нужды меняться. Выживание не обязательно»).