DORA Metrics

Самый полезный урок из истории DORA для меня в том, что сами метрики меняются: исследование уточняет модель, и вслед за ней уточняется список. В 2023 году broad MTTR заменили на failed deployment recovery time, а с 2024 года к модели добавили deployment rework rate. Дашборд с «четырьмя ключами» после этого остаётся исторически понятным, но текущую модель из пяти метрик он уже не показывает.

DORA делит их на две группы. Пропускная способность изменений: change lead time, deployment frequency, failed deployment recovery time. Нестабильность изменений: change fail rate и deployment rework rate. Reliability остаётся показателем операционной производительности, а не «пятой метрикой доставки» — прежнюю формулировку сама DORA разобрала отдельно. Отсюда явная граница со SLO / Budget Review: SLO описывает опыт пользователя и надёжность сервиса, DORA — результат процесса доставки изменений.

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

Что должен уметь

Главный навык на уровне L5 — читать пять метрик как систему в контексте одного приложения или сервиса, а не добиваться роста одного числа. Критерий зрелости здесь не «красивый дашборд», а решение об улучшении процесса, которое команда может связать с наблюдаемым трендом.

Называет пять текущих DORA-метрик, раскладывает их на throughput и instability и объясняет границу между MTTR инцидента и failed deployment recovery time.
Читает тренды своего сервиса и не сравнивает абсолютные значения приложений с разным контекстом как рейтинг эффективности.

Фиксирует определения deployment, failed deployment, recovery и rework для конкретного сервиса до настройки расчёта.
Связывает данные контроля версий, CI/CD и инцидентов так, чтобы для каждой метрики можно было проверить происхождение событий и границы окна.
Отделяет незапланированный корректирующий deploy от планового изменения при расчёте deployment rework rate.

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

L6+

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

Материалы

Книги

Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Фундамент исходной четырёхметричной модели и методологии исследования. Читал бегло, для общего развития книга своё даёт, но за текущими названиями и составом метрик сюда идти уже нельзя — сверяться всё равно по актуальному руководству DORA.
Gene Kim, Patrick Debois, John Willis, Jez Humble — The DevOps Handbook (IT Revolution, 2-е изд., 2021). Полезен как операционный контекст, но в части состава DORA-метрик устарел — за ним идти не стоит.

Статьи и доклады

DORA — Software delivery performance metrics. Пять метрик, группировка throughput / instability, область применения и типовые ошибки. Определения сверяю по этой странице, а не по книгам: она обновляется, последняя правка — 5 января 2026 года, а книжные списки метрик к этому моменту устарели.
DORA — A history of DORA’s software delivery metrics. Нужен, чтобы не смешивать версии модели: отдельно объясняет переход от MTTR к failed deployment recovery time, роль reliability и добавление deployment rework rate.
DORA — Quick Check. Подходит как вход в разговор и baseline, но не заменяет проверяемые определения и сбор событий из инженерных систем.
DORA — Capabilities catalog. Открываю уже после того, как ограничение найдено. По моим наблюдениям, в обратном порядке каталог читается как список практик, которые надо внедрить, хотя он предлагает способ улучшить процесс, а не ещё один способ ранжировать команды.

Инструменты

Four Keys — архивная эталонная реализация исходных четырёх метрик. Полезна, чтобы разобрать модель событий, но текущую модель из пяти метрик без доработки не покрывает.
Git / CI/CD / incident data — предпочтительный источник событий, если команда может проследить происхождение данных. Конкретный продукт вторичен по отношению к явным определениям и проверяемой связи change → deploy → intervention.

Best practices

История самих DORA-метрик — хороший публичный контрпример идее «однажды настроили и забыли». Модель меняла названия, границы и число показателей. Значит, у владельца дашборда рядом с цифрами лежат версия методики и дата последней сверки с первичным источником — иначе через год никто не сможет сказать, что именно измерял график в прошлом квартале.

Пять метрик, две группы — это и есть весь состав. Reliability шестым числом не дописывается, общий MTTR инцидентов метрикой доставки не называется. Измеряется приложение или сервис: так рекомендует DORA, и агрегирование несопоставимых команд действительно скрывает различия вместо того, чтобы что-то объяснить. Определения идут раньше интеграций — сначала договориться, что здесь считается deploy, вмешательством и rework, и только потом строить сбор данных.

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

Различайте два времени восстановления. Failed deployment recovery time начинается в контексте неудачного deploy, который требует немедленного вмешательства. MTTR инцидента может включать отказы совсем другой природы, поэтому смешивание меняет смысл показателя и делает сравнение периодов недостоверным.

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

Связанные листья

SLO / Budget Review — операционная надёжность и опыт пользователя; не шестая DORA-метрика.
CI/CD — основной источник событий change и deploy, а также место улучшения потока доставки.
Progressive Delivery — снижает blast radius изменения и даёт механизмы быстрого вмешательства при неудачном deploy.
Change Governance — правила согласования изменений могут проявляться в change lead time; причинность проверяется отдельно.
Postmortem Culture — даёт контекст для change fail rate, rework и восстановления, но не подменяет расчёт метрик.

Открытые вопросы

Как единообразно помечать deployment rework там, где hotfix, rollback и обычный deploy идут одним pipeline? Готового ответа у меня нет.

Второй открытый вопрос — хранение истории методики. Хочется, чтобы дашборд показывал разрыв ряда там, где поменялось определение, а не склеивал несопоставимые периоды в один красивый тренд.