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

Бенчмарки DORA

Когда говорят о DORA-бенчмарках, обычно имеют в виду один известный график с четырьмя уровнями зрелости команд: elite, high, medium и low.

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

Отсюда выросла логика: деплоишь чаще, восстанавливаешься быстрее, ломаешь прод реже – значит, ты ближе к elite. Но рынок взял эту модель и превратил её в некую вечную универсальную шкалу, а сама DORA за это время стала куда осторожнее в своих формулировках.

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

Модель метрик тоже меняется.
В актуальном гайде DORA метрики разбиты на две группы:

Throughput (производительность)

• Время от коммита до деплоя (Lead Time for Changes) — сколько времени проходит от момента, когда разработчик зафиксировал изменение в коде, до его появления в продакшене. Охватывает всё: код-ревью, прогон тестов, сборку, деплой. Длинный лид-тайм обычно сигнализирует о бутылочных горлышках в процессе — например, в ручных проверках или медленном CI.

• Частота деплоев (Deployment Frequency) — как часто команда выкатывает изменения в прод. У elite-команд это может происходить несколько раз в день, а у low — раз в несколько месяцев. Высокая частота сама по себе не цель, но косвенно говорит о том, что каждый деплой небольшой и менее рискованный.

Stability (стабильность)

• Процент проблемных изменений (Change Failure Rate) — какая доля деплоев приводит к деградации сервиса, откату или срочному хотфиксу. Метрика показывает не количество багов вообще, а именно те случаи, когда релиз потребовал немедленного вмешательства. Высокий CFR при частых деплоях — сигнал, что скорость опережает качество обратной связи.

• Время восстановления после неудачного деплоя (Time to Restore Service) — как быстро команда возвращает сервис в рабочее состояние после инцидента, вызванного деплоем. Метрика отражает зрелость процессов реагирования: наличие мониторинга, runbook'ов, возможности быстрого rollback.

• Налог на переделки (Deployment Rework Rate) — какую долю деплоев составляют незапланированные исправления: хотфиксы, патчи, откаты. В отличие от CFR, который фиксирует сам факт проблемы, Rework Rate показывает, сколько ресурсов команда тратит на разгребание последствий вместо создания новой ценности.

Где начинается проблема

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

Две команды в одной компании. Команда А деплоит 12 раз в неделю, Change Failure Rate – 8%. Команда Б деплоит раз в две недели, CFR – 2%. Менеджмент решает, что Б "хуже" по частоте. Но Б поддерживает платёжный шлюз с SLA 99.99%, где каждый деплой проходит через обязательный compliance review. А поддерживает внутренний дашборд.

Сравнивать их deployment frequency – всё равно что сравнивать скорость скорой помощи и такси.

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

Сравнивать команды в лоб почти всегда ошибка 

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

В актуальном гайде написано так: 

Метрики лучше всего работают для измерения одного конкретного сервиса, а не команд в целом. И контекст имеет огромное значение.

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

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

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

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

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

Как автоматизировать сбор метрик?

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

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

Для этого нужны четыре типа источников: 

• Система контроля версий;

• CI/CD-контур;

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

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

Чаще всего это выглядит как Git + CI/CD + issue/incident tracker + алерты. Каждый источник закрывает свою часть: Git фиксирует момент появления изменения, CI/CD знает, что и когда ушло в прод, а трекер инцидентов показывает деградацию и момент её устранения.

Самое важное начинается там, где нужно связать события между собой. Lead Time не существует без связки «коммит → деплой». Change Failure Rate не считается без атрибуции «деплой → инцидент». Recovery Time требует двух временных меток: когда инцидент открылся и когда закрылся. Без этих связей автоматизация просто быстро и красиво считает неправильные вещи.

— У нас есть дашборд с метриками.

— Откуда данные?

— Из Jenkins.

— А инциденты?

— Из головы, в общем-то.

— Тогда у вас есть красивый дашборд, а не метрики.

Отдельный вопрос – что именно считать деплоем, инцидентом и неудачным изменением. Универсального ответа нет: считается ли выкладка на 5% трафика полноценным прод-деплоем? Где заканчивается обычный баг и начинается инцидент, который должен влиять на Change Failure Rate? Это решает каждая команда самостоятельно, и пока этого решения нет, никакая автоматизация не поможет.

Когда ручной сбор – норма?

Раз речь пошла про Git, CI/CD и нормализацию событий легко решить, что DORA история только для зрелых команд с уже собранной телеметрией. Но это не так.

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

Ручной или полуавтоматический сбор особенно уместен в трёх случаях: 

• Когда нет сквозной связки между Git, деплоями и инцидентами; 

• При наличии инфраструктуры, но определения внутри ещё не устоялись;

• Если команда просто не хочет тратить месяцы на телеметрию, не понимая пока её ценности. 

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

У ручного подхода есть ограничения.
Часть инцидентов не попадёт в учёт, часть хотфиксов не будет помечена как rework. На одном сервисе это терпимо, на десяти начнёт разваливаться. Есть и риск политической фильтрации: команда может подсознательно занижать failure rate или не считать неудобные случаи инцидентами.

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

Где DORA заканчивается 

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

Это важно помнить, потому что метрики выглядят как «почти всё, что нужно знать о команде». На деле они отвечают на вопрос про скорость и стабильность доставки – но не на вопрос, делаете ли вы вообще что-то нужное пользователю. Можно держать отличный deployment frequency и низкий fail rate, но катить в прод функцию, которой никто не пользуется. Для понимания продуктовой полезности нужны другие инструменты например, продуктовые метрики adoption или usability (степень лояльности и использования новых функций).

Второй слепой угол – состояние команды.
Developer experience не извлекается из логов CI/CD и Git: удовлетворённость, когнитивная нагрузка, уровень фрустрации самостоятельная область измерения со своими фреймворками.

Третий – техдолг.
DORA может косвенно сигнализировать о проблемах: растущий rework rate или ухудшение recovery time часто идут рядом с деградацией архитектуры. Но прямого измерителя техдолга здесь нет.

Четвёртый всё, что происходит до коммита. Если команда хочет понять, где теряется время в приоритизации, согласованиях или product discovery, одной DORA  не хватит, нужен более широкий взгляд на весь поток работы.

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

Логи – не синоним объективности

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

Связка с другими фреймворками 

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

— По DORA мы в топе. Lead time меньше часа, деплоим каждый день.

— Отлично. Команда довольна?

— Ну... народ устал немного. On-call каждую неделю, алерты ночью.

— А пользователи пользуются тем что вы деплоите?

— Это надо у продакта спрашивать.

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

— По метрикам мы elite.

Именно здесь DORA заканчивается — и начинаются другие инструменты:

Фреймворк SPACE: мониторит состояние людей. Можно иметь приличный lead time и частые деплои, при этом убивая команду контекст-свитчингом, перегрузкой on-call и хрупкими ручными процессами. DORA покажет, что доставка идёт, SPACE поможет понять, какой ценой это достигается.

DevEx-метрики: смотрят на то, как система ощущается изнутри: сколько времени уходит на локальную сборку, насколько предсказуем CI, как часто разработчик упирается в flaky tests, насколько тяжело пройти путь от идеи до merge request. DORA описывает систему снаружи, а DevEx описывает изнутри.

Flow metrics нужны, когда проблема сидит до коммита: в handoff'ах, ожиданиях и согласованиях. Cycle time, flow efficiency, WIP, queue time – всё это полезно там, где работа простаивает между этапами, а production delivery как таковая здесь ни при чём.

Продуктовые рамки:  когда вопрос уже про ценность, а про доставку. H.E.A.R.T. и продуктовые метрики отвечают на то, начали ли пользоваться функцией, удобно ли она работает и принесла ли ожидаемый результат. DORA ответит, насколько хорошо вы довезли изменение до прода.

Продуктовые метрики – нужно ли оно было вообще.

Ну или более практичная в понимании развилка:

• Болит скорость и стабильность доставки – DORA

• Болит состояние команды, когнитивная нагрузка, качество рабочего дня – SPACE / DevEx

• Болит поток до релиза: очереди, зависания, согласования – flow metrics и value stream mapping

DORA сильная базовая ось, которая очень хорошо показывает здоровье delivery-механизма. Чем взрослее команда, тем яснее: одна линза остальные заменить не может.

А что с DORA у российских команд?

Публичной статистики именно по России с внятной разбивкой по DORA-кластерам почти нет. Честнее будет разобрать наблюдаемых паттернах, которые часто встречаются у локальных команд и напрямую влияют на метрики.

Пожалуй, самая сквозная история – тяжёлый релиз как организационная норма. В enterprise, банках, госе и крупных legacy-контурах production change до сих пор воспринимается как событие, требующее отдельного административного ритуала: релизного окна, ручных апрувов и даже межкомандной координации. Это одновременно давит на deployment frequency и раздувает lead time – причём не из-за кода или тестов, а из-за ожидания. Сами по себе редкие релизы могут выглядеть как осторожность, но в логике DORA это просто дорогой и медленный путь до прода.

В одной из команд, с которой мы работали, от merge в main до появления в проде проходило 11 дней. Из них 9 – ожидание релизного окна и ручные согласования. Код был готов, тесты пройдены, но деплой происходил строго по четвергам, после подписи трёх человек.

Рядом с этим живёт другая проблема: автоматизация развивается неравномерно. CI/CD может быть – но последние мили релиза всё равно проходят через ручные проверки, чек-листы и отдельные контуры тестирования. Российские инженерные публикации последних лет почти всегда говорят о CI/CD через внедрение лучших практик и условный переход к SDET/QAOps – то есть рынок активно догоняет зрелую культуру непрерывной поставки, а не живёт в ней как в давно решённой норме.

Отдельная боль инструментальная разнородность. На локальном рынке одновременно сосуществуют GitHub Actions, GitLab CI, Jenkins, самописные пайплайны и внутренние оркестраторы. Проблема здесь зачастую даже не в отсутствии инструментов, а в том, что события из этих инструментов трудно собрать в единую согласованную модель. Нет слоя между Git, deploy events, incident management и мониторингом. Bottleneck сидит именно здесь.

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

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

Рекомендации: с чего начать команде, если она хочет внедрять DORA без гигантского проекта

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

Второй шаг – словарь событий, а не дашборд. Команда должна заранее договориться, что именно у неё считается deployment, failed change, recovery и rework. Без этих определений любая автоматизация будет быстро и красиво считать неправильные вещи.

Дальше – минимальный baseline. Для начала достаточно ответить на несколько простых вопросов за выбранный период: сколько раз команда выкатывалась в продакшн, сколько выкладок потребовали срочного вмешательства, сколько времени уходило на восстановление и сколько незапланированной работы съедали последствия проблем. Идеальная телеметрия на этом этапе необязательна – интеграция всех систем сразу может просто не стоить усилий.

Когда baseline есть, важно выбрать одну главную боль, а не пытаться улучшить всё сразу. Редкие и тяжёлые релизы – начинать с deployment frequency и lead time. Прод горит при частых деплоях – в центре внимания change fail rate, recovery time и rework. Всё выглядит нормально, но команда хронически не успевает  стоит дополнить DORA flow-метриками или DevEx-сигналами.

И последнее: первый baseline уже хороший результат, а не промежуточная ступень к настоящему внедрению. Следующий шаг постепенно убирать ручной учёт там, где он начинает мешать, и выстраивать событийную модель из Git, CI/CD, incident management и мониторинга. Порядок здесь принципиален: сначала смысл и определения, потом автоматизация.

Короткий стартовый план выглядит так: выбрать один сервис, договориться о терминах, снять baseline за 2–4 недели, понять главный bottleneck, менять процесс и только после этого автоматизировать то, что уже стало осмысленным.

Начните с одного сервиса и четырёх вопросов. Через месяц у вас будет baseline. Через три — понимание, где на самом деле болит.