DORA: четыре ключевые метрики

Откуда взялись DORA-метрики

Когда в компании заходит разговор «надо измерять продуктивность разработки», обычно тут же всплывает DORA — четыре метрики из исследовательской программы DevOps Research and Assessment. Широкую известность они получили благодаря книге Accelerate, которую Николь Форсгрен, Джез Хамбл и Джин Ким выпустили в 2018 году. Исследование было масштабным: несколько лет команда собирала данные тысяч организаций через ежегодный State of DevOps Report и статистически доказывала, что определённые технические практики коррелируют с бизнес-результатами. У них получилось найти четыре метрики, которые хорошо разделяют высокопроизводительные команды и всех остальных.

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

Четыре метрики

Deployment Frequency — частота деплоев

Как часто команда выкатывает изменения в продакшен. Не количество коммитов и не количество PR-ов — деплои в прод. Элитные команды, по данным DORA, деплоят по несколько раз в день, команды нижнего уровня — реже раза в месяц. Логика простая: чем чаще деплои, тем меньше изменений в каждом, тем легче найти проблему и тем быстрее ценность доходит до пользователей.

Lead Time for Changes — время от коммита до продакшена

Сколько проходит от пуша кода разработчиком до его работы в продакшене. Элитные команды укладываются в день, у нижнего уровня это занимает от месяца до полугода. Сюда входит всё: code review, прохождение CI, staging, approval-процессы, окна деплоя. Lead Time в две недели — сигнал серьёзных заторов в pipeline.

Change Failure Rate — процент неудачных изменений

Доля деплоев, которые приводят к деградации сервиса, хотфиксу или откату. Элитные команды держат показатель на уровне 0–15%, нижний уровень — 46–60%. Эта метрика про стабильность, она уравновешивает первые две: нет смысла деплоить десять раз в день, если каждый второй деплой ломает продакшен.

Time to Restore Service (MTTR) — время восстановления

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

Уровни производительности

DORA выделяет четыре уровня — Elite, High, Medium, Low — и распределяет команды по комбинации четырёх метрик. Важный момент: уровень определяется по самому слабому показателю. Нельзя быть Elite с отличной частотой деплоев, но ужасным MTTR. Цепь по самому слабому звену. Одна из самых ценных идей DORA — она заставляет работать над всем pipeline целиком, а не оптимизировать одну метрику в ущерб остальным.

Чего DORA не измеряет

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

Удовлетворённость разработчиков — можно деплоить десять раз в день и ненавидеть свою работу, потому что каждый деплой требует ручного прохождения через пять approval-ов и три канала в мессенджере. Когнитивная нагрузка — DORA не видит, что разработчик тратит полдня на разбор запутанной системы конфигурации, прежде чем написать одну строчку кода. Качество кода — метрики не отличают «быстро деплоим хороший код» от «быстро деплоим технический долг». Состояние потока — прерывания, контекст-свитчинг, время на глубокую работу — DORA не покрывает.

Ловушка Гудхарта

Закон Гудхарта: когда метрика становится целью, она перестаёт быть хорошей метрикой. С DORA это происходит постоянно. Команды разбивают один осмысленный деплой на десять мелких, чтобы поднять Deployment Frequency. Перестают помечать инциденты как инциденты, чтобы не портить Change Failure Rate. Особенно опасно, когда метрики привязывают к KPI менеджеров: стимулы смещаются с реального улучшения процессов на манипуляцию числами.

Как начать измерять

Начинать стоит с того, что уже есть, и без покупки дорогих платформ. Частоту деплоев считают по CI/CD-логам, Lead Time — по временным меткам в git и в системе деплоя, Change Failure Rate — по тикетам инцидентов, MTTR — по логам алертинга. Главное — собирать данные регулярно и обсуждать тренды с командой, а не использовать метрики как инструмент давления. DORA — отправная точка для разговора о том, где болит в delivery pipeline, но не финальная точка в измерении Developer Experience. Для более полной картины — SPACE.