Всем доброе утро!
Меня зовут Крылов Александр.

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

Так же, следует добавить, что данная статья является уточнением и углубление темы доклада с конференции DevOpsConf 2023 - DevOps Governance в Enterprise.
С видео выступлением конференции можно ознакомиться тут.
Перейдём к описанию.

В современных реалиях не так просто прийти к бизнесу и сказать: "Давайте всё автоматизируем, и всё будет хорошо!" Нет, это так не работает, особенно в крупных компаниях. А если у вас ещё и нет единого процесса внесения изменений, то каждый будет кто в лес по грибы, кто домой за скатертью-самобранкой приходить и навязывать свои идеи.

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

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

Кому может быть полезна данная статья, спросите Вы? Ответ прост - Представители Enterprise, руководители направлений и управлений, head of DevOps, лидеры центров компетенций и экспертизы, техлиды, тимлиды, CTO.

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

А теперь, давайте познакомимся.
Я Lead DevOps. За 10 лет работы в ИТ прошёл полный путь от первой линии поддержки до начальника службы devops.

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

Lead DevOps

• соавтор и ведущий подкаста ProITStand

• основатель телеграмм канала по техническим мануалам t.me/devopslove

• постоянный спикер конференций DevOpsСonf, HighLoad++, Team Lead Сonf с 2020 года

Всё наше повествование пройдёт по следующему сценарию:

1. Историческая справка

2. RnD-решения

3. Что такое матрица зрелости

4. Этапы внедрения матрицы

5. Результат внедрения

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

Нашу историческую справку мы начнём с того, что у мы Enterprise. И вот некоторые из признаков этого:

• Нам 100 лет

• У нас есть CIO вместо CTO

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

• Vendor engineering

• Top — down решения

• Cost center vs profit center

• Build vs buy-решения

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

• Аббревиатуры систем

• У нас есть «коллеги»

Что представляет собой наше ИТ:

• Деление на развитие и поддержку

• Наличие DevOps-культуры

• Использование Agile, Scrum, Kanban практик

• Наличие внутренней разработки

• Использование новейших технологий

• Более 500 человек в ИТ

• ~ 70 проектов в год

• Fullstack-команда на систему 4-8 человек

• На крупные проекты более 200 из внешних и внутренних

Мы используем внутренний глоссарий:

Система - обособленная АС, приносящая бизнес пользу.
Бизнес-критичные системы - АС, которые приносят прибыль компании.
Проект - активность, затрагивающая одну или более систем с неким бизнес value.
Команды - участники цикла разработки: аналитики, разработчики, DevOps, тестирования, лиды.
Работы - некая активность, целью которой что-то улучшить в существующих системах.
Техрук - технический руководитель проекта или системы.
Владелец системы - заказчик или ответственный за систему, может быть, как со стороны ИТ, так и бизнеса.
Лид направления - человек, отвечающий за некую орг структуру - тестирование, аналитика, DevOps.
Куратор - ответственный за проведение каких-либо работ.
Внутренний ресурс - участники цикла разработки, работающие в стенах компании.
Внешний ресурс - вендора или подрядчики, консалтинг.
Целевая система - та система, которая будет в компании ещё минимум 5 лет.
Не целевая система - та система, которая заканчивает свой ЖЦ (о нём немного позднее), или планируется выводиться из эксплуатации в ближайшее время, не планирует развиваться.
Бизнес - заказчики работ на доработки систем с целью принесения прибыли компании.
DevOps as services - подход DevOps, как сервис. В нашем случае сквозная сервисная служба.
FTE (Full-time employee) - ресурсная единица в проектном офисе - 1 FTE = 1 человек на full time нагрузку на проект/систему/активность.

Жизненный цикл наших систем представляет собой следующий набор этапов

Проблемы, которые встали перед нами, которые могут возникнуть и у Вас в при схожем построении процессов, и которые мы решать по ходу повествования:

• Наличие внутренних и внешних команд (vendor engineering): ~ 60% внутри, 40% внешние

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

• Отсутствие плана (контроля) развития систем

• Нет прозрачности процессов ИТ

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

• ~ 30 % нецелевых систем

Мы понимали, что есть различные пути решения, что мы можем пойти по одному из 3 путей и получить некое что-то, что поможет нам решить эти проблемы.

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

• Модель DevOps от Gartner: технологии, люди, процессы, культура;

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

• DORA capabilities;

  

Уже намного интересней, но, к сожалению, не покрывает всех наших вопросов.
Метрики эффективности разработки DORA - это полезный инструмент, который может пригодиться, особенно в небольших компаниях или командах для замера базовых метрик эффективности разработки, поэтому рекомендую обратить на него внимание, как и на следующий подход, с которым мы столкнулись, а именно

• DASA DevOps;

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

• Оценка аудита со стороны;

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

• Опыт коллег из прошлых компаний:

  • делали ли они аудит систем?

  • делали ли они это сами?

  • как делали?

  • какие метрики использовали?

Интересно, но хватит ли нам знаний? Напрашивается вполне очевидный вопрос. Но, кто не пытается, тот не пьёт шампанское.

Если суммировать выводы всех изысканий, в том числе после уточнения ценников по консалтингу, получили такой результат:

• Консалтинг — дорого;

• Готового решения на рынке под нас — нет; (понимайте, что и под Вас их так же может не быть, т.к. каждая компания по своему уникальна)

• Выгодней идти своим путём.

Решение было таково - Создаём своё решение под названием «матрица зрелости систем» на базе существующего опыта коллег с использованием изученных практик. Стартом активности стал февраль 2020 года.

И мы плавно переходим к определению того, что же такое матрица зрелости.

Матрица зрелости систем – прозрачный процесс аудита и реаудита систем компании с использованием:
- практик гибкой разработки;
- культуры DevOps;
- современных подходов к автоматизации;
- современных инструментов CI/CD.
© Крылов Александр

С тем, что такое матрица, определились, теперь перейдём к описанию этапов внедрения.
В нашем случае таких этапов получилось 12:

1. Сбор списка систем

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

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

4. Составление глоссария по разделам

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

6. Отбор первичных метрик

7. Приоритизация работ по системам

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

9. Планирование работ

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

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

12. Реаудит раз в год

1.Сбор списка систем
На данном этапе происходит обзор всего парка по системам, в нашем случае, их точное количество составило - 34.
Сформировали список и состав команд с разделением на внешние и внутренние.

2.Определение ресурсов команды
На данном этапе надо понять составы команд по ранее собранному списку систем.

Аллокация FTE:

• DevOps внутри;

• DevOps снаружи;

• Команды внутри;

• Команды снаружи;

• Где есть ресурсы у команд?

3.Детализация блоков и методологии
На данном этапе Вам следует понять, какие практики и методологии Вы будете использовать в вашей матрице. В нашем случае, за основу блоков и сабблоков мы взяли:

-Разработка:

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

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

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

• сборка;

• анализ на уязвимости;

• CI/CD.

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

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

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

• команда.

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

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

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

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

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

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

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

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

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

В основу был взят подход, описанный тут - https://www.rfc-editor.org/rfc/rfc2119

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

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

Мы поняли, что лучше всего взять модель уровней зрелости на базе CMMI и это нам подошло. Уровней было выбрано 5. Отмечу, что уровней может быть 3, 5, 7, 10. 3 Для нас оказалось мало, 10 и 7 избыточно, поэтому, мы остановились на 5.

6.Отбор первичных метрик
На данном этапе Вам необходимо определить метрики, на основе которых Вы сможете понимать текущее положение дел, текущую зрелость, и то, куда Вы можете и хотите стремиться.
Для того, чтобы наши достижения могли иметь индикативность, мы вернулись к тому, с чем столкнулись на стадии RnD, а именно обратились к метрикам DORA, а так же нашли agile метрики, которые используют atlassian, совместив это с информацией по состоянию devops в 2020 году

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

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

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

7.Приоритизация работ по системам

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

8.Аудит по согласованным метрикам
Начался этап аудита. Данный этап, на старте, будет самым объёмным. И Вам надо быть готовым к тому, что он не пройдёт гладко и у коллег могут появляться к Вам вопросы, вроде таких:

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

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

• У нас нет ресурсов;

• Согласуйте ресурсы;

• И т.д.

И это справедливо, мы внедряем некий монструозный процесс, о котором пока знают ещё не все, не смотря на презентацию. И, конечно же, куда уж тут без сопротивление сторонников чего-либо нового, живущих по принципу - "Работает, не трогай". И их можно понять. Поэтому мы стали искать сторонников доказывать и завоёвывать, весьма успешно, большие территории в виде систем и команд. Но, были и те, кто стоял до последнего и никакие доводы им были ни почём. Тут нам помогло то, что мы Enterprise, да и такое бывает, и у нас есть CIO, а именно TOP DOWN безоговорочное решение, которому надо следовать и буйство утихло.
Понятно, что это подойдёт не всем и придётся матрично горизонтально или снизу искать сторонников и есть множество способов этого, но данное повествование больше не про подавление сопротивления, а про внедрение процесса. Поэтому мы пойдём дальше.

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

Далее нам эту самую матрицу надо заполнить на основе ранее созданного глоссария и индикаторов соотношения к нашим уровням от 1 до 5.
При этом, возможны пограничные состояния, когда система находится между уровнями. Например, у нас уже все индикаторы 2 уровня есть и мы находимся на нём, но при этом уже соблюдено ряд требований для следующего уровня на 50%, так рождается оценка 2,5. Важно, что в таких случаях лучше не мельчить далее десятых, иначе потом запутайтесь.

Что касается ресурсного составляющего, то лучше всего расписывать аллокацию ресурсов, как показывает практика, примерно в таком виде.

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

• Техруки;

• Владельцы систем;

• Лиды направлений (разработка, тестирования, аналитика).

То есть, все роли, которые были заинтересованы в улучшениях.

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

Например, на некой системе Х, у нас есть 2 FTE, разработчика, которые мануально пишут код, мануально занимаются выкладкой и т.д. Это явно задача для того, чтобы сделать улучшение и повысить зрелость.

Важно! Лучше всего это делать в формате презентации не более 30-40 минут.

Давайте перейдём к этому кейсу подробней по сценарию, который Вы видите ниже:

Опишем проблематику в виде ограничений на системе N:

• трудоемкость переноса изменений между средами;

• Manual rollback;

• сложность привязки/отслеживания изменений в системе с бизнес-задачами;

• риски изменения одного и того же объекта разными разработчиками;

• сложность передачи задач от одного разработчика к другому;

• невозможность реализации задач по АТ.

Важно! Данной защитой должен заниматься человек, умеющий говорить с бизнесом на его языке и рассказывать ИТ терминологию максимально понятно любому обывателю.

Опишем постановку задачи:

• Автоматизация и организация процессов разработки на функционале системы N — решаемая задача

• В 2020-м году в БИТ РГС реализуется инициатива по внедрению в ИТ-ландшафт инструментов CI/CD. Система N — как одна из целевых

• Работы по внедрению основных инструментов методологии CI/CD в процесс разработки, тестирования и эксплуатации системы N планируется реализовать тогда-то.

Описываем наше решение рассказываем, что есть DevOps и CI/CD простым языком, после чего, переходим к конкретики по реализации с уточнением по стэку, что у нас есть и какие вопросы он решает

После чего описываем преимущества от внедрения.

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

Обязательно, выделяем отдельный слайд под таймлайн внедрения со сроками и описанием возможности параллельности работ, есть такая возможность есть.

После чего описываем какое количество ресурсов потребуется на проведение работ.

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

9.Планирование работ

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

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

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

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

Любые работы следует контролировать, для этого мы стали делать следующее:

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

12.Реаудит раз в год

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

Реализовано:

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

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

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

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

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

• произошла смена фокуса по ресурсам.

Профит:

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

• Детальные метрики зрелости для бизнеса с пониманием, что на что влияет;

• За 2 года определено 23 целевых и 11 нецелевых систем и проведено более 30 крупных задач по улучшению.

Заключение:

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

• полноценное внедрение заняло 4 месяца (до 10 этапа);

• первая полная картина работ от матрицы – год;

• Enterprise – это небыстро;

• за 2 года можно сделать очень много при желании.

Шаблон матрицы зрелости можно найти тут