Автор: Чарльз Арауджо (Charles Araujo), оригинал заметки: Is DevOps Falling into the Maturity Trap?

Я увидел это не так давно на конференции. Менеджер по развитию одного крупного предприятия объяснял, как они придумали модель зрелости DevOps на основе CMMI. Он говорил о текущем состоянии зрелости и плане по достижению «полной зрелости» в ближайшие три года; рассказывал, как они представляли этот план руководству и получили одобрение на создание новой «DevOps команды».

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

К сожалению, это кино мы уже смотрели. И оно без хеппи-энда.

Потанцуем?

Возможно, я слишком категоричен. Я уверен, что компании, которые идут по пути зрелости, на самом деле, движимы благими намерениями. Однако проблема с разговорами о зрелости в том, что они быстро вытесняют то, ради чего все затеивается. Я провел много оценок зрелости (не применительно к DevOps, но в ряде других областей), и это всегда мучение. Ценность подобных оценок достаточно ограничена, за исключением того факта, что они говорят заказчику, что «все не так уже и плохо», но и не слишком хорошо. А затем указывают на те области, в которых он недостаточно совершенен, что позволяет консультантам продать ему еще больше консалтинга, чтобы это исправить.

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

Встречайте DevOps-инженеров

По мере того, как все большее число организаций обращает внимание на практики DevOps, растёт количество моделей зрелости DevOps, в основном с подачи консалтинговых и технологических компаний, занятых DevOps-автоматизацией. И это понятно. Как мы знаем, DevOps – это в первую очередь культурная трансформация, которую трудно оценить как обычный ИТ-проект, трудно измерить и отчитаться о прогрессе. Поэтому менеджмент хочет получить хоть какие-нибудь цифры, которые сможет использовать для обоснования/оправдания затрат на свои авантюры. По той же самой причине менеджмент начинает создавать различные организационные структуры, посылая руководству сигналы о том, что работа кипит.

В крупных компаниях уже появились целые DevOps-команды и должности, вроде DevOps-инженера. Конечно, это не что иное, как подмена понятий. По своей сути, DevOps – новый способ организации работы и взаимодействия, чтобы внедрять изменения эффективнее, быстрее и надежнее. Принятие принципов DevOps в отдельных местах внутри организации имеет смысл для компании, экспериментирующей с новой концепцией, но в конечном итоге все должны следовать этим принципам, чтобы компания стала эффективной и гибкой. Создание выделенных DevOps-команд и должностей только отдаляет от этой цели.

DevOps ≠ Continuous Delivery

Не стоит рассматривать DevOps как проект или методологию. В какой-то степени использование слов «разработка» (dev) и «эксплуатация» (ops) в названии этого подхода мешают прочувствовать его реальное предназначение – создание интегрированной операционной модели для ИТ, а в дальнейшем, для всей компании, когда ПО начинает играть решающую роль в бизнес-модели.

Но вместо этого организации рассматривают DevOps как еще одну методологию разработки и как синоним автоматизации развертывания. DevOps становится приложением для приложений. Этот подход ошибочен. Организации не должны путать DevOps с его близким родственником – Continuous Delivery. Continuous Delivery – это процесс структурирования всей цепочки создания программного продукта, который позволяет постоянно интегрировать код на протяжении всего жизненного цикла разработки и, благодаря высокой степени автоматизации, быстро тестировать и выводить ПО в эксплуатацию. Continuous Delivery – это мощный подход, который может повысить организационную гибкость, резко сократить время вывода продуктов на рынок, улучшить качество и надежность софта. Это критично для любого приложения, ориентированного на заказчика и важного для бизнеса. Но это не обязательно относится к каждому приложению, используемому сотрудниками предприятия.

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

Это не относится к DevOps. Напротив, организации должны принимать его всецело, использовать как новый принцип работы внутри ИТ. Чтобы по-настоящему раскрыться, DevOps должен стать вирусным явлением в вашей компании.

Кто молчит о зрелости

Во всей шумихе вокруг DevOps, есть компании, которые никогда не говорят о зрелости – пионеры DevOps. На той же конференции, на которой мне довелось услышать увлекательные рассказы о модели зрелости DevOps, я имел возможность пообщаться с одним из основателей движения DevOps в Netflix. Он ни разу не упомянул слово «зрелость». Вместо этого он говорил о бизнес-целях, которые они пытались достичь, о стремлении улучшить процессы развертывания, о способах сделать и работу систем и процесс их развития более устойчивым. Он объяснил, как они применяют новые инструменты, чтобы решать эти задачи. Но он ничего не сказал о зрелости.

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

Проведение оценок зрелости и создание новых организационных структур – понятные реакции на давление. Но позволить организации пойти по этой дороге равносильно подрыву самой идеи DevOps и тех культурных преобразований, которые лежат в основе этого движения.