Статья будет полезна тем, кто начинает или планирует проведение цифровой трансформации и DevOps трансформации как ее части.
Перед ДОМ.РФ и Банком ДОМ.РФ стоит задача цифровой трансформации компании, в том числе DevOps трансформации. Меня зовут Евгений Панков и я – один из участников группы, задача которой, проводить изменения подходов, связанных с разработкой, тестированием и эксплуатацией.
Движение DevOps включает в себя практики, инструменты и культурные изменения. Я расскажу о своем опыте формирования видения того, какие практики мы будем рекомендовать для использования в командах, какие подходы использовал я для взаимодействия с командами для понимания состояния развития практик в них и донесения до коллег общего видения, какие практики мы хотим развивать.
Вопросы, которые нужно при этом решить виделись следующие:
Как составить список практик?
Для систематизации информации о практиках и получения актуальных сведений о том, как практики влияют на достижение показателей производительности команд, я использовал данные исследования компании DORA[i], State of Devops за 2019 год, исследование компании Экспресс 42, проводившееся в 2020 году, и книгу Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.
После прочтения исследований и книги у меня появилось понимание по составу и значимости существующих практик, а также того, как практики группируются по категориям. И все равно это описание дает верхнеуровневое представление о практиках. Нужно было провести их декомпозицию, чтобы впоследствии можно было внедрять практики постепенно и последовательно, а участники команд могли быстрее в них разобраться.
Мне очень помогла метафора представления всего жизненного цикла поставки как единой "трубы". Раскладывая практики по этой "трубе", можно представить себе весь набор в виде отдельных составляющих.
Например, что нужно для реализации практики CI (Continuous integration)? В Википедии, CI описывается как практика, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.
Для реализации этой практики нужно применить несколько других:
Управлять версиями исходного кода;
Автоматизировать сборку;
Писать и запускать Unit тесты;
Применять статический анализ кода;
Писать и запускать минимальный набор автотестов;
Автоматизировать развертывание на окружение;
Интегрировать все вышеописанное в пайплайн;
Вызывать пайплайн по различным событиям (например, merge в общую ветку).
Таким образом я декомпозировал все практики начиная от сборки и заканчивая мониторингом. Получилось 63 штуки.
Как говорить со всеми командами про практики на одном языке?
Для применения практик участникам команд, конечно необходимо иметь или приобретать необходимую экспертизу. Я не увидел в командах проблем с освоением определенных инструментов и подходов. При этом, чтобы участники команды понимали, что мы подразумеваем под реализацией той или иной практики, недостаточно иметь ее описание, нужно определить и критерии ее реализации (Definition of Done, DoD).
Например, для практики Логирование DoD я определил так: команда разработки может получить логи всех окружений в удобном для анализа формате с возможностью поиска. Логи анализируются для решения и предотвращения инцидентов и для других целей.
Список практик и их DoD я оформил как модель зрелости с разбивкой на уровни зрелости, которые почти* полностью повторяют последовательность прохождения по "трубе" от системы контроля версий до мониторинга работы в промышленной среде с разбиением на 4 группы.
*Например, практика магистральной разработки, хотя и относится к началу "трубы", но отнесена мной к 4 уровню зрелости, так как требует зрелости многих других практик, включая максимально полное покрытие всеми видами тестирования и др.
Кроме уровней зрелости, практики разбиты на категории. У нас четыре категории: практики, связанные с разработкой (CI), практики, связанные с прохождением доработки по окружениям до промышленного уровня (CDL), практики, связанные с возможностями подготовить и сделать релиз быстрее и качественнее (CDP), практики, связанные с культурными изменениями (ADM).
Описание реализации модели зрелости
Модель зрелости реализована на текущий момент в Excel. Этот инструмент, решает следующие задачи:
содержит список практик с кратким описанием (DoD);
позволяет командам заполнять состояние по каждой практике;
отражает тепловую карту по всем командам;
разделяет практики по категориям;
отражает процент реализации уровней модели зрелости и процент реализации категорий.
Теперь по порядку про каждую задачу. Всего для решения задач, потребовалось три листа Excel.
На первом листе в первом столбце заносим команды, остальные столбцы для практик в последовательности реализации "трубы". Значения ячеек могут быть: 1 - практика реализована для всех компонент приложения, число от 0 до 1 – доля реализации практики относительно компонент приложения. Например, есть два компонента, но версионный контроль кода реализован только для одного, тогда значение будет 0,5. 0 ставим если практика не реализована, а если не применима в принципе, то ставим -. Получаем тепловую карту:
На втором листе, в первой колонке заносим список практик, во второй - описание, дальше следуют колонки с уровнем зрелости и категорией, описанием критериев реализации практики, а остальные колонки содержат названия команд и формулы, которые ссылаются на первый лист и по названию команды и практики получают значение реализации этой практики.
Формулы внизу каждой колонки с командой, рассчитывают процент выполнения уровней и категорий.
Cледующий лист в первой колонке содержит название команды, а в следующих - в первой строке указаны названия уровней зрелости и категорий, формулы в строках получают с предыдущего листа значения процентов выполнения уровней и категорий.
Фиксируя эти данные во времени, строю графики как меняется средняя зрелость и средние значения категорий.
Работая с моделью зрелости, я не рассчитывал, что уровни будут одинаково применимы ко всем командам, как отмечено в книге Accelerate. В этом, если модель применять одинаково ко всем, минус подхода с моделью зрелости. Однако я не стал отказываться от модели зрелости в описанном виде. Если практика неприменима для конкретной команды, делаем соответствующую отметку. Например, команда, разрабатывающая приложения в 1С, не применяет практику «Управление зависимостями» (имеются в виду внешние библиотеки, подключаемые в код) – все необходимые зависимости уже включены в платформу.
Хотя в книге Accelerate авторы противопоставляют понятие модели зрелости и модели возможностей, я думаю, что они успешно дополняют друг друга.
В моем случае модель зрелости позволяет описать практики и оценить реализацию всей "трубы". А модель возможностей позволяет понять, как практики связаны между собой, как они группируются, что получит команда от их реализации.
Описание реализации модели возможностей
Комбинируя знания из исследования, книги Accelerate и нашей специфики, которая отражена в модели зрелости, я реализовал модель возможностей в плагине Gliffy для Confluence (но вы можете использовать любой удобный вам инструмент).
Суть модели - практики/возможности, которые декомпозированы по составу и агрегированы в более крупные (например Continuous integration). Удобство в том, что команда может понять, какой минимум нужно реализовать для старта, какие практики обязательны для реализации той или иной возможности в полном объеме и какие нужно развивать для получения определенной возможности, которая нужна команде в ближайшее время.
В модели возможностей выделены цветом уровни практик для сохранения связи с моделью зрелости. При этом нет явно заданной лестницы развития практик по уровням, за исключением базового (первого). Команда сама может выбирать, какие из практик наиболее актуальны для нее и для ее развития. Анализируя ответы участников команды в опроснике, я предлагаю ей свои выводы и рекомендации развития практик по модели возможностей.
Модель возможностей - более простой для конечного потребителя инструмент по сравнению с моделью зрелости, но более сложный в реализации, так как необходимо представлять, каким образом практики влияют друг на друга и какие возможности в данный момент актуальны для конкретной команды.
Для построения модели возможностей мне нужен контекст команды, который я получаю с помощью опросника, подобного тому, который применяли авторы книги Accelerate в своих исследованиях. Кстати, накопив с помощью таких опросников знания о деталях развития практик в командах, в том числе о четырех ключевых метриках, представленных DORA, вы сможете составить свой отчет о состоянии DevOps в вашей компании и с помощью инструмента оценки производительности определить категории для ваших команд.
У нас оказались в наличии все четыре категории - от Low performers до Elite performers. Ниже опишу как я делал опросник.
Описание реализации опросника
Опросник нужен мне для получения объективной информации о состоянии развития практик в команде, о зонах роста и том, что получается делать хорошо. Для получения такой информации важно, чтобы опросник заполнили все члены команды, все кто участвует в процессе создания ценности. Это позволяет, во-первых, получить максимально независимую оценку, во-вторых, - взгляд на одни и те же вещи от разных ролей. Таким образом, например, можно сразу понять - команда пришла к DevOps в смысле взаимодействия Dev и Ops, или разработчики ничего не знают про релизы на продуктиве, а сопровождение - про работу приложения в средах разработки и тестирования.
Фактически мой опросник покрывает все или почти все практики по модели зрелости, содержит вопросы про четыре метрики DORA в формулировке, в которой они приведены в исследовании, а также открытые вопросы о слабых и сильных сторонах команды.
Вопросы по практикам лучше формулировать не в виде «есть или нет», а так, чтобы можно было на основании ответов о реальной ситуации в команде сделать вывод – реализована данная практика или нет. Почему именно так? Во-первых, участник опроса может не знать, что означает та или иная практика, во-вторых, описание практик может толковаться в разных источниках с некоторым отличием и пониматься разными людьми по-разному.
Таким образом, вместо того, чтобы спрашивать, есть ли у вас Trunk Based Development, нужно задать несколько вопросов, которые говорят о признаках реализации этой практики. Признаки - это фактически плюсы, которые получает команда. В качестве примера приведу вопросы из исследования компании «Экспресс 42», проводившегося в 2020 году.
По результатам ответов на такие вопросы у меня сразу есть и понимание, что обсуждать с командой. Исходя из того, на какие вопросы получены отрицательные ответы, можно давать рекомендации и обсуждать с командой, что нужно изменить для того, чтобы на вопросы был дан утвердительный ответ. Конечно, не все может быть применимо в определенных командах, но нужно убедиться, что это именно особенность команды или процесса, а не отсутствие понимания, как можно повысить эффективность работы.
Ответы на вопросы по метрикам я потом использую для определения категории производительности команды, делаю это при помощи калькулятора от DORA. В дальнейшем я смогу провести повторный опрос и определить, как изменилась производительность команды.
Вопросы о проблемах/зонах роста я использую для определения приоритета практик, требующих развития. А то, что команда выделяет, как получающееся у нее хорошо, использую в качестве референса для других команд, у которых будут релевантные проблемы.
Обязательно показать результаты опросника команде, это может помочь выровнять понимание по разным вопросам, и команда сможет использовать эти результаты ретроспективно.
Результаты я оформляю в виде списка полученных ответов, дополненных диаграммами распределения ответов, моими комментариями, выводами и рекомендациями. Естественно все это потом обсуждается на встрече с командой.
В качестве инструмента для опросника можно использовать любой удобный для вас инструмент, я использую «Google Формы».
И, как писал выше, по результатам опросника готовлю модель возможностей с выделенными практиками, которые реализованы полностью, частично, не реализованы и те, которые не реализованы, но я намерен рекомендовать их применять.
Цикл развития практик в командах
Цикл работы с практиками в наших командах состоит из оценки текущего их состояния, наблюдений за прогрессом и определения дальнейших шагов для развития.
Для определения текущего состояния практик команде нужно заполнить модель зрелости. Команда делает это самостоятельно или с моей помощью, если требуется ответить на вопросы по практикам. Таким образом мы понимаем текущую зрелость и практики, которые требуют развития. Если в команде уже реализован ряд практик, и есть потребность более подробно определить приоритеты развития, то я использую опросник, с помощью которого даю рекомендации команде и строю модель возможностей (см. описание опросника и модели возможностей).
Текущий прогресс реализации практик отслеживаем на основании данных, которые команды вносят в модель зрелости. Прогресс отражается в виде тепловой карты, процентов выполнения по уровням модели и среднего процента по всем уровням зрелости и линейных графиков изменения этих величин со временем (см. описание реализации модели зрелости).
В качестве подтверждения реализации практик, кроме опросника и модели зрелости, мы хотим использовать метрики (четыре метрики DORA и другие); сейчас их получение в процессе реализации.
Дальнейшее развитие команды определяют по нереализованным в модели зрелости практикам и своим ретроспективам, где обсуждают влияние практик на цели команды. Если не все очевидно и требуется копнуть глубже, я повторно запускаю опросник, по результатам которого могу дать дополнительные рекомендации и обновить модель возможностей.
Применение описанных выше методик позволило мне в течение полугода провести оценку состояния практик и помочь 28 командам последовательно и регулярно определять задачи по их развитию. Таким образом было сформировано общее видение на практики и масштабирован подход с их внедрением.
В заключение приведу некоторые результаты: на момент написание статьи у 7 команд полностью построен конвейер сборки и развертывания (от dev до prod окружения) включая выполнение автотестов, средний уровень зрелости по всем командам 62%. Ежеквартально команды выполняют задачи по развитию практик, что в среднем повышает их уровень зрелости на 15%. Для оценки того, как команды меняют свою производительность во времени, мы реализовываем сбор четырех основных показателей скорости и качества, предложенных DORA (LT, CFR, MTTR, RF) и ведем мониторинг динамики этих показателей. Таким образом, системный подход к развитию инженерной культуры позволяет постепенно шаг за шагом развивать практики DevOps, ориентируясь прежде всего на объективные показатели прогресса и обретение командами новых возможностей.
[1] Ключевые метрики DORA: LT (Lead Time), CFR (Change Failure rate), MTTR (Medium Time to restore), DF (Deployment Frequency)
[i] DORA – компания, занимающаяся аналитическими исследованиями в области эффективности и производительности software development. С 2014 года проводит самое масштабное исследование факторов зрелости, определяющих стандарты разработки программного обеспечения и продуктивности ИТ компаний. В настоящее время в исследованиях DORA участвуют порядка 31 000 профессионалов из разных компаний по всему миру.