Хей, всем привет! Вот и вышел свеженький State of DevOps. Это уже 10-й юбилейный выпуск, теперь ещё вкуснее и интереснее. Поразбираем, что же там внутри. Будут факты, сюрпризы, важные мысли, на что обратить внимание, немножко набросов и мемасиков, куда ж без них. 

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

Я Сергей Задорожный, руководитель отдела платформенных решений банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки» от Яндекс Практикума. Раньше занимался написанием бэкендов на Java и Kotlin, потом архитектурой, выстраиванием процессов, а сейчас заношу DevOps-практики в финтех-энтерпрайз. Автор канала IT Friday, член ПК DevOops и знатный мемолог. Люблю котиков и блэк-метал.

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

В основе исследования лежат опросы от DORA (DevOps Research And Assessment). Каждый год в течение 10 лет они проводят опрос среди инженеров, руководителей и других представителей IT.  За всё время в этом поучаствовали 39 000 респондентов, в том числе и я. 

В 2024 году в опросе приняли участие 3000 специалистов из трёх ключевых отраслей:

• IT-технологии — 36%,

• финтех — 16%,

• ритейл — 9%.

Помимо опроса в этот раз отдельно, для более полной картины, провели интервью с 11 экспертами: созванивались с каждым на час, обрабатывали диалог ИИшкой и выделяли важные моменты. Некоторые самые интересные цитаты анонимно привели в исследовании (в отличие от русского State of DevOps — там неанонимные).

Мне понравилась эта идея, и я её спёр, поэтому для обсуждения я тоже позвал экспертов — их мнение будет появляться в статье, а ещё будут вот такие врезки:

Капитан очевидность

Вроде и очевидное, но не всегда об этом думаешь

Выводы

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

Бу, испугался

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

Есть над чем подумать

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

Введение. В этом сезоне State of DevOps

Когда я проходил опрос от DORA, уже было понятно, что в трендах будет AI (Artificial Intelligence), PE (Platform Engineering) и DevExp (Developer Experience). Я был в предвкушении, меня особенно интересовала часть с PE. 

И вот недавно вышло исследование.

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

Но начнем по порядку. Что ж, погнали! 

DORA-метрики и элитность

Скрытая корреляция. Пересмотр DORA-метрик

Угадайте, какая из DORA-метрик постоянно выбивалась на протяжении всех исследований? Какая из четырёх метрик аффектила другие? 

• Change lead Time — время от коммита до развёртывания на проде;

• Deployment frequency — как часто изменения поставляются на прод;

• Change failure rate — процент изменений на проде, приводящий к ошибкам, которые требуют роллбэков или хотфиксов;

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

• Failed deployment recovery time — время для починки после провального деплоя.

Капитан очевидность

Ошибки в релизах порождают хотфиксы и доработки.

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

Теперь State of DevOps определяет производительность поставки программного обеспечения через два отдельных фактора:

● пропускная способность разработки программного обеспечения;

● стабильность разработки программного обеспечения. 

Однако для консистентности с прошлыми исследованиями при разбиении на кластера Elite, Medium, High, Low авторы пока рассматривают четыре метрики. В дальнейшем, может, будет пять.

Выводы

В DORA рассмотрели новую метрику rework rate, т.к. ошибки на проде зачастую порождают повторную работу. Возможно, в будущем её добавят к основным четырём.

Software delivery performance необходимо рассматривать с двух сторон: пропускная способность поставки (software delivery throughput) и стабильность поставок (software delivery stability).

Метрики software delivery throughput:
• Change lead time;
• Deployment frequency;
• Failed deployment recovery time.

Метрики software delivery stability:
• Change failure rate;
• Rework rate.

Маленькое отступление

Очень интересно читать исследования об IT-индустрии, практиках и инструментах State of DevOps, Technology и другие, матчить их на свою команду или организацию, обдумывать, почему так и куда всё движется. Но чтобы покрутить отчёт с разных сторон и получить больше фидбэка, гораздо круче сделать это в компании:

• от ещё не выгоревших новичков до инженерных инженеров, поевших сурового энтерпрайза;

• других причастных, специалистов из IT;

• представителей бизнес-отделов;

• специалистов компаний разного типа: аутсорс, стартапы, энтерпрайз;

• специалистов из разных индустрий: финтех, ритейл, телеком.

Как раз такую разностороннюю компанию и получилось собрать. Вечером, в выходной, в дождливую осеннюю погоду взяли внезапно подорвались и устроили андеграундный митап, чтобы обсудить State of DevOps — это всё, что нужно знать про ростовскую айтишку. 

Очень круто посидели, детально поразбирали свежее исследование, покрутили с разных сторон и накидали очень много интересных мыслей. Душевно и продуктивно провели 3 часа, исписали 6 досок, и время пролетело просто мгновенно. Огромное всем спасибо, кто пришёл!

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

Вопросы

Всегда ли неудачное изменение ведет к хотфиксам? Например, вдруг ошибка на проде решается исправлением на стороне инфраструктуры.

Считается ли поставка удачной, если не приносит бизнес-ценности?

Надо ли учитывать, сколько пользователей затрагивает неудачная поставка?

Интересно посмотреть первые DORA-метрики и все прошлые State of DevOps.

Входит ли в DORA тест гипотез, проверка MVP-проектов или другая предварительная работа перед реализацией приложений?

Почему DORA-метрики оторваны от бизнесовых и не учитывают другие факторы?

Как насчёт кастомных метрик?

Elite vs Low. Меряемся элитарностью

Тут спойлеров нет, просто сухие метрики. Разве что медиум-перформеры чуть выбиваются из общей картины: релизят реже, но с меньшими ошибками, чем High.

Выводы

В каждой отрасли есть свои Elite и Low компании. Да, у них могут быть уникальные проблемы, связанные с конкретикой отрасли, но смысл разделения по эффективности остаётся тот же.

Каждый может стать Elite.

Важно отслеживать динамику и пробовать двигаться: например, от Medium к High.

Вопросы

Где мы и наш уровень зрелости организации?

Как измерять глобально на всю организацию? Брать среднее по проектам?

В High можно попасть и без автоматики?

Какие ещё факторы оказывают влияние на производительность?

Игорь Курочкин

Enabling.team

Как эксперт, который разобрал все отчёты State of DevOps, хотел бы отметить, что не стоит уделять большого внимания кластерам, переживать по поводу того, являетесь вы Elite или Low. 

Всё будет зависеть от вашего контекста: индустрии, размера компании, инженерной зрелости, этапа развития продукта или сервиса, типа команды (продуктовая, платформенная, инфраструктурная и др.). 

Кластера в отчёте меняются каждый год, временами Elite кластер отсутствовал, потом снова появлялся. На это влияют участники, которые проходили опрос, а также появление  новых практик и инструментов. 

DORA-модель и методология дают хорошую отправную точку, чтобы понять, в какие основные практики (capabilities) инвестировать и на какие базовые метрики смотреть. Но этого недостаточно для получения инсайтов и принятия решений. 

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

От Low к Elite. Процесс улучшений

Переход от Low к Elite — это не просто переход от hand job к автоматике. Это целый процесс, и это не погоня за метриками. При этом, чтобы понимать свой текущий уровень и знать, куда двигаться, важно отслеживать метрики в динамике.

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

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

Что же касается оценки самих приложений, то каждое приложение или сервис имеет свой контекст и связи. Сложно оценить приложение в вакууме. 

Авторы исследования приводят очевидную, но важную последовательность действий по улучшению DORA-метрик проекта. 

Алгоритм по улучшению показателей эффективности

1. Начните с главного приложения, соберите кросс-функциональную команду, пройдите DORA Quick Check.

2. Составьте value stream map, чтобы команда могла понять, что препятствует эффективности.

3. Составьте план улучшений.

4. Реализуйте план.

5. Повторно соберите метрики и проанализируйте их.

Выводы

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

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

Вопросы

Сложно ли собрать DORA-метрики?

Как влияет зависимость проектов друг от друга при сборе DORA-метрик?

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

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

Кто пользуется GitLab’ом для сбора DORA-метрик?

Можно ли собирать метрики эффективности аудитом, опросами, когда нет инструмента?

Что составляет среду для улучшений?

Полезняшки

Книга «Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации» — от создателей исследований State of DevOps

Сайт DORA — помимо исследований, там ещё есть методички и другие интересности.

«Мы сегодня многое поняли»

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

• Эффективность работы команд измеряется через две категории: пропускная способность деплоя и стабильность, при этом важно учитывать rework rate, т.к. ошибки ведут к новым релизам.

• Переход от Low к Elite требует систематической работы и учёта метрик в динамике. Но главное — не погоня за цифрами, а создание среды для обучения и улучшений. 

• DORA-метрики важны для анализа, но не учитывают бизнес-ценность, поэтому стоит дополнить их пользовательскими и бизнес-показателями.

На этом не всё, дальше следующая часть, в которой мы обсудим ИИ и как оно повлияло, влияет и будет влиять на нашу айтишечку и не только. Stay tuned ;)