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-ов и три Slack-канала. Когнитивная нагрузка — DORA не видит, что разработчик тратит полдня на то, чтобы разобраться в запутанной системе конфигурации, прежде чем написать одну строчку кода. Качество кода — метрики DORA не различают между «мы быстро деплоим хороший код» и «мы быстро деплоим технический долг». Наконец, состояние потока — прерывания, контекст-свитчинг, время на глубокую работу — всё это DORA не покрывает.

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

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

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

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