Всем доброе утро!
На связи вновь Крылов Александр, и сегодня я решил поделиться мыслями о том, как можно применить опыт 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 этапа - сбора списка продуктов:
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, отбирая самое вкусное для себя. Самое главное - это не делать слишком много на старте, лучше потом волнами добавлять метрики, а с начала выбрать только самое необходимое. Также можно добавить цветовую градацию по тому, что реализовано, а что - нет, и это так же является новшеством. Да - это рюшка, но она удобна для визуального восприятия.
Зеленый – реализовано;
Жёлтый – в процессе;
Красный – ��е реализовано.
А в общей картине это может выглядеть так
То, как могут выглядеть первичные метрики, я описал в таблице ниже. Обращу внимание, что изначально мы не добавляем метрики безопасности, это сделано намерено, на мой взгляд и по опыту, их лучше добавлять второй волной.
Название практики | Название метрики |
Модульное тестирование | % покрытия модульными тестами |
CI/CD | время на сборку при непрерывной интеграции |
% успешных сборок непрерывной интеграции | |
время на поставку | |
% успешных поставок | |
Методология тестирования | время на прохождение смок-тестов |
время на прохождение регресс-тестов | |
% автоматизации тестовых сценариев | |
% ложных срабатываний у автотестов | |
% пропущенных дефектов в интеграционные среды | |
% успешно пройденных тестов | |
Инфраструктура | время на подготовку нового окружения |
Переходим к 7 этапу внедрения - Аудит по согласованным метрикам.
Сразу подсвечу один момент - если дойдя до этого этапа вам ещё не удалось согласовать ресурсы, про которые я говорил в рамках 2 этапа, то будьте готовы, что первичный аудит вы будете делать самостоятельно. Это может быть по причине отсутствия на данном этапе поддержки от C-уровня, и, как следствие, невозможности использования полноценного Top-Down подхода. В этом ничего страшного нет, с миру по нитке.
С какими вопросами можно столкнуться?
Зачем нам это надо?
Что это такое?
У нас нет ресурсов! Кто их согласует для этих работ?
Согласуйте ресурсы! Вы согласовали их с владельцем?
Руководство согласовало и спустило это сверху?
Чья это инициатива и кто это согласовал?
Какой будет профит?
Как это может выглядеть на старте в части ресурсов?
Этап | Статус | Продукт | Framework | Потребность в реализации | Задача | Ответственный |
1 | Аудит | Bimeister | .Net | Что-то | DevOps-XXX | TL DevOps |
2 | 2024 |
|
|
|
|
|
| Целевой |
|
|
|
|
|
Пример того, что может получиться, взят у блока разработки и представлен в таблице ниже.
Статус | Разработка | |||||
Кодирование | Модульное тестирование | Статический анализ | Сборка | Анализ кода на уязвимости по ИБ | CI/CD | |
08.2023 | 1,5 | 1 | 0 | 1,5 | 1 | 1,5 |
2024 | 2 | 1,5 | 1 | 2 | 2 | 2 |
Целевой | 3 | 3 | 3 | 3 | 3 | 3 |
Тут сразу идём по ранее согласованной шкале от 0 до 4. Вот такие могут быть роли участников работ и объёмы ресурсов.
Роли | Служба DevOps | Тестирование | Продукт |
Инженеры DevOps | Y FTE | Х FTE | 1,5 FTE |
Тестировщики | 1 FTE | ||
Разработчики | 6 FTE |
Кто потенциально может помочь и кого вы можете затянуть в свою лодку?
Разработчики;
Тестировщики;
Архитектура;
Лиды направлений.
Но будьте готовы к сопротивлению, и если бы не появившаяся квота ресурсов тестирования позднее, то работы по матрице в этом направлении вообще бы не велись. Учитывайте особенность процессов согласования ресурсов в вашей компании и идите по этому пути. Ибо - таков был путь ;) Ну а мы переходим к 8 этапу - Планирование и согласование работ.
Планируем по следующим критериям:
Тип работ;
Скоуп работ;
Объём ресурсов команд;
Согласование ресурсов;
Согласование сроков.
Я не буду дублировать вариант того, как это возможно реализовать, т.к. это уже было сделано в этой статье, на базе которой создана эта, но ряд моментов, которые можно подсветить, озвучу.
С точки зрения чек-листа того, что может потребоваться для согласования, можно составить такой список:
Собираем и описываем фактуру по ограничениям в текущих процессах и технологиях и их влияние на развитие продукта;
Готовим slide decks по результатам раннего исследования в формате презентации и доски в miro или аналогах;
Описываем постановку задач на первичное проведение работ по улучшениям;
Описываем технику/автоматизацию/процессы на понятном бизнесу языке;
Описываем потенциальные или реальные преимущества как краткосрочные, так и долгосрочные от описанных выше изменений;
Таймлайн внедрения;
Согласование ресурсов.
Варианты описания преимуществ от автоматизации и проведения работ:
Уменьшить расходы на релизный цикл;
Cократить негативное влияние человеческого фактора за счёт автоматизации и отказа от мануальных действий;
Повысить чистоту и качество кода, снизив количество дефектов;
Уменьшить T2M;
Уменьшить время сборки и, как следствие, сократить трудозатраты на процессы, где она используется;
Уменьшить время на траблшутинг команд тестирования и разработки;
Ускорить устранение сбоев.
Пример таймлайна внедрения.
Еще лучше показать диаграмму Ганта, например, на базе gunt structure jira:
А вот так может выглядеть пример формата запроса на ресурсы:
Да, в Ганте бы это выглядело более наглядно, но тут мы в это углубляться не будем. Более подробно с описанием 8 этапа можно ознакомиться в видео ниже, начиная с 43 минуты.
А мы переходим к 9 этапу - Реализация. В нашем случае это з��няло 1,5 месяца. И тут кроме тех нюансов, что были описаны выше в части сопротивления и согласования ресурсов, добавить больше нечего.
На 10 этапе - Контроль работ мы *этим самым и занимаемся. Промежуточные статусы осуществляем раз в месяц, глобальное планирование актуализируем раз в квартал. Планирование лучше делать, если это возможно, на год вперёд, если нет, то на квартал с разбивкой по месяцам, больше мельчить нет смысла. В рамках контроля ещё можно проводить:
Статусы с product owner;
Уточнение по срокам работ;
Ведение работ;
Контроль исполнителей;
Выделение куратора работ от службы DevOps.
После чего переходим к 11 этапу - Реаудит раз в квант времени. Квант у всех может быть разный, мельчить меньше полугода нет смысла, по опыту, лучше - раз в год.
Что у нас получилось реализовать, если кратко:
внедрена матрица зрелости продуктов;
сформированы точки контроля и временные срезы;
реализован прозрачный контроль за развитием продукта;
понятен и реализован процесс снижения T2M.
Что же нам дало внедрение данного подхода?
Есть единый прозрачный процесс контроля развития технической части продукта и взаимодействия всех участников цикла разработки;
Более прозрачные метрики зрелости разработки для бизнеса с пониманием, что на что влияет. Тут важно сказать, что ещё много планов по тому, что предстоит сделать, но начало положено в виде цифрового профиля разработчика;
За счёт доп автоматизации:
- больше фич в sprint текущими ресурсами;
- повышение качества тестирования спринтов;
- повышение чистоты кода.
А вот теперь самое интересное, что можно назвать послесловием.
Да, многое можно сказать на словах, но реальный профит в некоторых случаях оказалось оценить и посчитать намного сложнее, чем думалось изначально, т.к. к моменту внедрения либо не была реализована процедура снятия метрик для понимания результатов, либо было не понятно, как эти метрики собирать. Что также является проблемой, которую мы ещё решаем.
Сейчас я расскажу ряд реальных реализаций и профита, а вот полноценные детали с цифрами уже будут в отдельной будущей статье, т.к. ещё предстоит не мало работы по созданию и рефакторингу этих самых метрик.
Начнём коротко и по существу.
Стэк, на котором будет осуществляться сбор и вывод метрик, - надо выбрать, и подробно об этом будет рассказано в будущей статье. Но с этого надо начинать, ибо описано не мало как кастомных реализаций, так и коробочных решений.
Измерить время сборки, время деплоя и вывести это - не так сложно, но если вы хотите снимать метрики коммитов разработчиков за период времени, считать среднее время на коммит и количества закрываем задач за релиз или спринт, то тут уже придётся подумать, как это лучше делать. Почему? Потому что инструментов CI/CD много, и у каждого по разному реализовано API, что надо учитывать, поэтому одну прямую реализацию переиспользовать даже на том же стеке один в один не выйдет, потому что архитектура пайпов у всех построена по-разному.
Если мы хотим собирать метрики перехода по статусной модели flow issuetype jira и соотносить их с исполнителем, то тут надо подумать над реализацией - как лучше и менее ресурсонагрузочно на сервер - через запросы в БД или api jira.
И последнее, что я также хочу сказать - если вы хотите собирать метрики по репозиториям, мейнтейнерам, коммитам, MR/PR, то исходите из вашего процесса разработки. И для того, чтобы некоторые метрики появились, возможно, в процессе разработки придётся что-то изменить, не факт, что это будет так, но такое возможно. Например, начать использовать ребейзы вместо сквошей формирования MR/PR.
Безусловно, всего я тут не опишу и процесс формирования метрик ещё находится в разработке, в том числе для доказательств профита от работ, которые сейчас из-за их отсутствия попросту сделать невозможно.
И это будет заключительным выводом - планируйте реализацию метрик не постфактум проведения работ в рамках матрицы, а заранее или во время этих работ, а ещё лучше - до работ, чтобы можно было сравнить результат до работ и после, при этом храните всю историю метрик, чтобы можно было их в последствии анализировать.
А продолжение с детализацией метрик и какие работы на что повлияли будет в будущих статья, а на сегодня всё.
С вами был Крылов Александр, до новых встреч!
