Всем доброе утро!
На связи вновь Крылов Александр, и сегодня я решил поделиться мыслями о том, как можно применить опыт DevOps Governance в Enterprise, который я ранее описывал в этой статье на примере компании, разрабатывающей собственный продукт. Прошло время, и опыт был переиспользован для разработки продукта на примере компании Bimeister. И началось это еще в августе 2023 года.

Что хотелось бы отметить - в этой статье не будет детальной расшифровки с уточнениями доклада с DevOops 2023, с которым так же можно ознакомиться по ссылке выше. В данной статье я расскажу о ряде отличий Governance в Enterprise и о том, как он может выглядеть в компании-разработчике своего продукта. Помимо этого я также расскажу, какие работы удалось провести за год в компании, а какие - нет и почему.

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

Начнём, традиционно, с небольшой исторической справки. На момент внедрения и по сей день есть ряд особенностей компании:

• Нам 6 лет;

• У нас есть CTO;

• Есть постоянные заказчики;

• Могут быть TOP — down решения, но не всегда;

• Внедряется – cost center vs profit center;

• В наличии build vs buy-решения;

• Есть процесс согласование ресурсов на активности, который сейчас на стадии трансформации;

• У нас есть transparency meetups - процесс прямого общения с сотрудниками всех топов компании, в начале в форме монолога, а потом в форме вопросов-ответов.

Мы также позиционируем себя как ИТ компания:

• Прививаем DevOps-культуру и DevOps as a Service (сервисный подход);

• В наличии гильдии DevOps и DevSecOps, где мы общаемся с нашими стейкхолдерами о том, что у кого болит, обмениваемся обратной связью и новостями;

• Мы используем подходы Agile, Scrum, релизимся по спринтам, в наличии Kanban практики и зачатки westrum культуры;

• У нас есть внутренняя разработка, мы не работаем с подрядными организациями;

• У нас проходят демо продуктов каждый спринт и инкремент, и это прекрасно. С примером того, как проходят наши демо, можно ознакомиться на страницах соц сетей нашего CTO по этой ссылочке. Там тепло и лампово про то, как и что мы делаем в каждом спринте.

• В разработке наших продуктов мы используем новейшие технологии и стараемся быть в тренде по этому вопросу вокруг всего цикла разработки - как на уровне методик и процессов, так и с инфраструктурными элементами CI/CD;

• Нас 500 человек, и все они - ИТ;

• У нас есть свой процесс безопасной разработки (SAST), чтобы сделать наш продукт лучше.

Докинем немного терминологии, помимо того, что было выше, чтобы мы писали и читали на одном языке.

Команды Alfa-Omega. У нас есть свои команды разработки, каждая из которых пилит свой отдельный компонент продукта или цельный продукт. И тут речь не только про разделение на back и front, но и на бизнесовые и технические компоненты продукта.

Мы имеем 3-хнедельные спринты, которые в кварталах складываются в мощнейшие инкременты.

У нас есть кураторы проведения работ, но в отличие от enterprise, где за это могут отвечать сами DevOps, техруки систем, владельцы продуктов или CTO, в нашем случае это лиды направлений, вроде TL DevOps и TL Dev.

Поскольку у нас есть продукты, есть и их владельцы, а раз есть владельцы и много команд, а живём мы по scrum-у, есть свои scrum-мастера, которые помогают достигать намеченных результатов и быть командам в одном информационном поле. И для этого у нас организованы еженедельные SOS или Scrum of Scrum - процесс по синхронизации и обмену последней информацией, в том числе по проблемам и вариантам их решения между CTO и scrum-мастерами с целью максимально быстрых поисков решений по возникающим вопросам.

Да, одна из основных предпосылок была озвучена выше, но она, самом собой, была не одна. Что же было ещё?

• Отсутствие аудита и реаудита систем;

• Отсутствие плана/контроля развития технической архитектуры продукта;

• Недостаточно прозрачные процессы разработки;

• Недостаточно прозрачное понимание ценообразования проектов.

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

Начнём с того, что за это время эволюционировали метрики DORA capabilities, которые развили полёт фантазии. И если раньше всё было весьма упрощено в таком виде

То теперь DORA расцвела во всей красе и стала выглядеть так:

Как мы с Вами можем наблюдать, теперь внимание уделяется большему количеству критериев, что в свою очередь перекладывается на технические метрики под таким соусом, который можно увидеть на рисунке ниже.

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

Одно из привлекательных решений, которое стоит упомянуть и которое пересекается с предыдущим опытом - это DevOps Maturity model от компании Accenture, построенная на базе подхода Governance.

Эту модель они используют при аудите процессов разработки, но по факту, это пресловутая Maturity model, скрещенная с DevOps Governance от небезызвестных ребят из Gartner. Да, выступление ребят с её презентацией было ни много, ни мало в 2016 году, но очень многое актуально и по сей день. Кстати, тут можно ознакомиться с видео выступления с DevOps enterprice summit, что, поверьте мне, не будет лишним для копилки ваших знаний, поэтому я оставлю это тут.

А тут можно ознакомиться и с самой презентацией с выступления. К сожалению, работает только из под VPN. А мы идём дальше.

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

Матрица зрелости продукта – прозрачный процесс аудита и реаудита продуктов компании с использованием:

• практик гибкой разработки;

• культуры и практик DevOps;

• подходов DORA, DASA, DevOps maturity в том числе в части контроля производства с использованием метрик;

• современных подходов к автоматизации;

• современных инструментов CI/CD.

© Крылов Александр

Перейдём к этапам внедрения процесса. В отличие от матрицы зрелости для Enterprise, где их было 12, у нас их будет 11. Своё название изменили этапы 3, 4, 6 и 11, а 7 этап, где мы осуществляли "Приоритизацию работ по системам", мы убираем, т.к. мы не будем разбивать матрицу по продуктам, а будем аудировать продукт и процессы его разработки как единое целое. Вот какие у нас получились этапы:

1. Сбор списка продуктов

2. Определение ресурсов команды

3. Мутация блоков и методологии

4. Мутация глоссария

5. Согласование количества уровней зрелости

6. Пересмотр первичных метрик

7. Аудит по согласованным метрикам

8. Планирование и согласование работ

9. Реализация

10. Контроль работ

11. Реаудит раз в квант времени

Раскроем каждый из этапов с учётом особенностей и изменений.

Начнём с 1 этапа - сбора списка продуктов:

• 4 продукта (как один);

• Аудируем их как одну платформу, без разделений;

• Перечень команд по продуктам от Alfa до Omega (11 команд).

Тут всё просто, собрали информацию и переходим к следующему этапу 2 - Определению ресурсов команды. И вот тут сразу могут начаться проблемы и появиться вопросы:

Какие ресурсы у нас могут быть использованы?

DevOps, внутренние команды (аналитика, разработка, тестирование), но у каких команд эти ресурсы есть?

Идёт продуктовая разработка, у PM всё расписано по ресурсам разработки и тестирования на спринты вперёд, и что же нам делать?

Одним из самых оптимальных решений является выделение квоты в 10% на техдолг команд. В рамках него могут быть задачи техдолга, вроде рефакторинга или избавления от легаси, а так же согласование ваших работ в рамках процесса по работе с матрицей. Да, согласовать это будет не так просто, как может показаться, но в случае успеха, у вас появятся какие-то плавающие ресурсы, которые можно будет использовать в рамках работ. Например, мы согласовали на ежеспринтовой основе квоту команды тестирования для тестирования задач DevOps там, где это необходимо, где возможно влияние на продукт в виде 2 дней от 3-хнедельного спринта, а далее мы можем распоряжаться этим ресурсом, как захотим. Как говорится в перефразированной поговорке - "язык до Рима доведёт". Поэтому надо уметь договариваться и выбивать хотя бы минимальное количество ресурсов, иначе дальнейший ход работ будет попросту невозможен. А доказав профит от результата первично проделанных работ минимальными ресурсами, уже можно будет требовать их больше спустя некоторое время. А для этого нам потребуются графики и метрики. Но едим слона по частям, а значит переходим к следующему этапу.

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

Практики разработки:

• кодирование;

• модульное/интеграционное тестирование;

• статический анализ;

• сборка;

• CI/CD.

Тестирование:

• методология;

• инструменты;

• команда.

Сопровождение:

• инфраструктура;

• логирование;

• мониторинг.

И новый блок - Безопасность (в момент внедрения было 4 подблока, сейчас их стало больше):

• Сборка;

• Доставка;

• Управление секретами;

• Управление дефектами;

• Управление и анализ зависимостей;

• Анализ архитектуры;

• Требования безопасности;

• Безопасная разработка (SAST, SCA);

• DAST;

• Тестирование на проникновение;

• Безопасность конфигурации (харденинг);

• Обновление продукта;

• Обновление зависимостей продукта.

В принципе, для начала вполне достаточно разделов - SAST, сборка, доставка и безопасность конфигурации, а далее уже можно внедрять постепенно всё остальное.

Перейдём к 4 этапу - мутация глоссария.

• Терминология для команд (общий язык);

• Описание процессов (обязано быть);

• Описание инструментов (должно быть);

• Описание методологии (что должно быть и чего не должно).

Более подробно наш глоссарий раскрыт тут в папочке Product.

После успешной мутации перейдём к 5 этапу - Согласование количества уровней зрелости.

Тут мы также используем 5-уровневую CMMI, с небольшой поправкой на ветер.

Мы переименуем уровни и начнём не с 1, а с 0. Зачем мы это делаем? Затем, что 0 уровень у нас будет индикатором того, чего нет от слова совсем. В предыдущем примере enterprise в нашем аудите систем не было полностью отсутствующих критериев, поэтому у нас и был сразу 1 уровень, а тут это уместно, поэтому реализовано именно так.
Каждому уровню мы дали название и получилось так:

• Нулевой;

• Базовый;

• Средний;

• Продвинутый;

• Максимальный.

Переходим к 6 этапу - Пересмотр первичных метрик.

Берём коктейль из DORA core model v2, миксуем с ранее известными метриками, и нежно добавляем russia state of devops 2023 и 2024, отбирая самое вкусное для себя. Самое главное - это не делать слишком много на старте, лучше потом волнами добавлять метрики, а с начала выбрать только самое необходимое. Также можно добавить цветовую градацию по тому, что реализовано, а что - нет, и это так же является новшеством. Да - это рюшка, но она удобна для визуального восприятия.

• Зеленый – реализовано;

• Жёлтый – в процессе;

• Красный – не реализовано.

А в общей картине это может выглядеть так

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

Переходим к 7 этапу внедрения - Аудит по согласованным метрикам.

Сразу подсвечу один момент - если дойдя до этого этапа вам ещё не удалось согласовать ресурсы, про которые я говорил в рамках 2 этапа, то будьте готовы, что первичный аудит вы будете делать самостоятельно. Это может быть по причине отсутствия на данном этапе поддержки от C-уровня, и, как следствие, невозможности использования полноценного Top-Down подхода. В этом ничего страшного нет, с миру по нитке.

С какими вопросами можно столкнуться?

• Зачем нам это надо?

• Что это такое?

• У нас нет ресурсов! Кто их согласует для этих работ?

• Согласуйте ресурсы! Вы согласовали их с владельцем?

• Руководство согласовало и спустило это сверху?

• Чья это инициатива и кто это согласовал?

• Какой будет профит?

Как это может выглядеть на старте в части ресурсов?

Пример того, что может получиться, взят у блока разработки и представлен в таблице ниже.

Тут сразу идём по ранее согласованной шкале от 0 до 4. Вот такие могут быть роли участников работ и объёмы ресурсов.

Кто потенциально может помочь и кого вы можете затянуть в свою лодку?

• Разработчики;

• Тестировщики;

• Архитектура;

• Лиды направлений.

Но будьте готовы к сопротивлению, и если бы не появившаяся квота ресурсов тестирования позднее, то работы по матрице в этом направлении вообще бы не велись. Учитывайте особенность процессов согласования ресурсов в вашей компании и идите по этому пути. Ибо - таков был путь ;) Ну а мы переходим к 8 этапу - Планирование и согласование работ.

Планируем по следующим критериям:

• Тип работ;

• Скоуп работ;

• Объём ресурсов команд;

• Согласование ресурсов;

• Согласование сроков.

Я не буду дублировать вариант того, как это возможно реализовать, т.к. это уже было сделано в этой статье, на базе которой создана эта, но ряд моментов, которые можно подсветить, озвучу.

С точки зрения чек-листа того, что может потребоваться для согласования, можно составить такой список:

• Собираем и описываем фактуру по ограничениям в текущих процессах и технологиях и их влияние на развитие продукта;

• Готовим slide decks по результатам раннего исследования в формате презентации и доски в miro или аналогах;

• Описываем постановку задач на первичное проведение работ по улучшениям;

• Описываем технику/автоматизацию/процессы на понятном бизнесу языке;

• Описываем потенциальные или реальные преимущества как краткосрочные, так и долгосрочные от описанных выше изменений;

• Таймлайн внедрения;

• Согласование ресурсов.

Варианты описания преимуществ от автоматизации и проведения работ:

• Уменьшить расходы на релизный цикл;

• Cократить негативное влияние человеческого фактора за счёт автоматизации и отказа от мануальных действий;

• Повысить чистоту и качество кода, снизив количество дефектов;

• Уменьшить T2M;

• Уменьшить время сборки и, как следствие, сократить трудозатраты на процессы, где она используется;

• Уменьшить время на траблшутинг команд тестирования и разработки;

• Ускорить устранение сбоев.

Пример таймлайна внедрения.

Еще лучше показать диаграмму Ганта, например, на базе gunt structure jira:

А вот так может выглядеть пример формата запроса на ресурсы:

Да, в Ганте бы это выглядело более наглядно, но тут мы в это углубляться не будем. Более подробно с описанием 8 этапа можно ознакомиться в видео ниже, начиная с 43 минуты.

А мы переходим к 9 этапу - Реализация. В нашем случае это заняло 1,5 месяца. И тут кроме тех нюансов, что были описаны выше в части сопротивления и согласования ресурсов, добавить больше нечего.

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

• Статусы с product owner;

• Уточнение по срокам работ;

• Ведение работ;

• Контроль исполнителей;

• Выделение куратора работ от службы DevOps.

После чего переходим к 11 этапу - Реаудит раз в квант времени. Квант у всех может быть разный, мельчить меньше полугода нет смысла, по опыту, лучше - раз в год.

Что у нас получилось реализовать, если кратко:

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

• сформированы точки контроля и временные срезы;

• реализован прозрачный контроль за развитием продукта;

• понятен и реализован процесс снижения T2M.

Что же нам дало внедрение данного подхода?

1. Есть единый прозрачный процесс контроля развития технической части продукта и взаимодействия всех участников цикла разработки;

2. Более прозрачные метрики зрелости разработки для бизнеса с пониманием, что на что влияет. Тут важно сказать, что ещё много планов по тому, что предстоит сделать, но начало положено в виде цифрового профиля разработчика;

3. За счёт доп автоматизации:
   - больше фич в sprint текущими ресурсами;
   - повышение качества тестирования спринтов;
   - повышение чистоты кода.

А вот теперь самое интересное, что можно назвать послесловием.

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

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

Начнём коротко и по существу.

1. Стэк, на котором будет осуществляться сбор и вывод метрик, - надо выбрать, и подробно об этом будет рассказано в будущей статье. Но с этого надо начинать, ибо описано не мало как кастомных реализаций, так и коробочных решений.

2. Измерить время сборки, время деплоя и вывести это - не так сложно, но если вы хотите снимать метрики коммитов разработчиков за период времени, считать среднее время на коммит и количества закрываем задач за релиз или спринт, то тут уже придётся подумать, как это лучше делать. Почему? Потому что инструментов CI/CD много, и у каждого по разному реализовано API, что надо учитывать, поэтому одну прямую реализацию переиспользовать даже на том же стеке один в один не выйдет, потому что архитектура пайпов у всех построена по-разному.

3. Если мы хотим собирать метрики перехода по статусной модели flow issuetype jira и соотносить их с исполнителем, то тут надо подумать над реализацией - как лучше и менее ресурсонагрузочно на сервер - через запросы в БД или api jira.

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

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

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

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

С вами был Крылов Александр, до новых встреч!