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

Эволюция практик DevOps в организации

Давайте посмотрим на три возможных (но не единственных) пути эволюции - один из которых приведет нас к успеху, другой - похоронит бизнес навсегда. Отталкиваться в процессе мы будем от модели CMM (Capability Maturity Model) - рассматривая инженерные практики через призму зрелости организации. Деление это может оказаться весьма условным.

Начальный уровень (Initial level)

Опустим этапы планирования продукта и выбора технологического стека - он располагается не в той части SDLC, к которой относится собственно DevOps. Компания нанимает разработчиков с компетенцией, достаточной для разработки собственно программного кода продукта. Вот как выглядит организация начального уровня (список далеко не исчерпывающий):

• Технологии:
  

  • ручное развертывание окружений

  • мануальное или отсутствующее тестирование

  • ручной деплоймент

  • отсутствие управления миграциями

  • ручной процесс сборки

  • нет управления конфигурацией

  • отсутствует или находится в зачаточном состоянии мониторинг

• Процессы:
  

  • рефлексивное управление как реакция на изменение ситуации

  • разработка как и тестирование происходит ad-hoc

• Люди:
  

  • команды создаются вокруг компетенций

  • развитие компетенций и обучение происходит на ходу, или отсутствует

• Культура:
  

  • слабая коммуникация

  • отсутствие общего видения развития продукта

  • инновации не внедряются или незначительны

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

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

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

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

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

Уровень повторяемости (Repeatable level )

Итак, мы на втором уровне. Да, я уже упоминал про шаблонность DevOps практик в первой статье и насколько сейчас все стало проще в плане развертывания. Мы вполне можем взять технологические шаблоны - неважно откуда они растут, из решений предлагаемых вендорами (AWS, GCP, etc) или готовыми open-source решениями, такими как k8s вдобавок к организационным. Точно так же по мере роста продукта увеличивается стоимость внесения изменений - но все больше упираясь скорее в проблему коммуникации между командами и в отсутствие зрелой инженерной культуры. Вот примерные черты компании на втором уровне зрелости:

• Технологии:
  

  • окружения версионированы и отделены от собственно разработки

  • функциональное автоматизированное тестирование (покрывается как правило критически важные сценарии)

  • автоматизированный процесс сборки

  • появляется система управления миграциями и версионирование

  • тулинг управления конфигурацией

  • базовый мониторинг

• Процессы:
  

  • рефлексивное управление как реакция на изменение ситуации

  • появляется планирование доставки в продукт

  • разработка строится как правило на основе Scrum

  • тестирование на основе обозначенных требований

  • начинает внедрятся практика документирования

• Люди:
  

  • команды создаются вокруг доставки

  • возникает непрерывный процесс обучения

• Культура:
  

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

  • пропитка общим видением развития продукта, культура разработки направлена на поддержку интересов бизнеса

  • инновации внедряются по необходимости

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