Что такое DORA-метрики и как их измерять, часть 1

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

Спросите любую команду: «Вы реально быстро выполняете работу или просто постоянно чем-то активно заняты?» – и мало кто сможет ответить честно.

У большинства стороны всё бурлит: выходят релизы, закрываются тикеты, все постоянно что-то чинят, согласовывают и двигают задачи по доске. Кажется, что работа живёт. Но если копнуть глубже – за какое время фича реально доезжает до прода? Как часто всё ломается по дороге? И сколько времени уходит на то, чтобы всё починить? Тут-то и выясняется, что чёткой картины ни у кого нет.

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

• Где мы действительно летим, а где только делаем вид?

• Где команда буксует и теряет время?

• Где наша излишняя перестраховка на самом деле только копит риски?

Они подсвечивают главное: проблемы чаще всего кроются в самом устройстве процесса, а не в людях.

Кстати, есть один живучий миф: мол, нельзя работать и быстро, и стабильно. Считается, что нужно выбирать – либо релизим часто, либо надёжно. Но на практике всё обстоит иначе. Крутым командам не приходится идти на компромиссы. Они выкатывают обновления быстро, а если что-то и падает – спокойно и без паники (возможно даже с легкой иронией) всё поднимают. Секрет прост: они научились управлять потоком задач как отлаженной системой, вместо перманентного режима тушения пожаров.

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

Если упростить, DORA – это система метрик изменения эффективности работы внутренних процессов.

Само название аббревиатура от DevOps Research and Assessment.

Assessment. Изначально это был исследовательский проект энтузиастов, который много лет собирал данные о том, как команды разрабатывают, тестируют, выкатывают и восстанавливают изменения. Исследование расширялось и постепенно стала всемирно известной программой Google Cloud, оторая изучает, какие практики и способности реально связаны с качественной поставкой софта и операционной устойчивостью.

У DORA есть четыре ключевых метрики, или так называемая золотая четверка. Их суть – понять насколько быстро код проходит путь до пользователя и насколько стабильно он там работает. 

Всё начинается с Deployment Frequency (частота деплоев).
Она отвечает на простой, но часто неудобный вопрос: как часто вы реально доводите работу до продакшена? Многие команды живут в иллюзии скорости: внутри что-то постоянно фиксится, задачи перелетают из статуса в статус, а в живом продукте неделями ничего не меняется. Метрика отсекает внутренний шум и фиксирует только поставку ценности пользователю.

В одной из команд, с которой мы работали, деплои происходили раз в две недели. После перехода на Trunk-based development и автоматизацию тестов частота выросла до 3–4 раз в неделю.

При этом CFR не вырос — потому что размер каждого изменения уменьшился в 5 раз.

В паре с частотой идет Lead Time for Changes (время цикла).
Это путь от первого коммита до появления изменений в проде. Если код написан, но три дня ждет ревью или неделю пылится в очереди на тестирование, Lead Time это сразу вскроет. Метрика подсвечивает, где именно буксует процесс: в ручных согласованиях, долгих проверках или излишней бюрократии.

Типичная картина:

Разработчик закоммитил код в понедельник утром. Ревью назначено на тимлида, у которого ещё 6 PR в очереди. Ревью проходит в среду. Тестирование — в четверг. Деплой — в пятницу. Lead Time — 5 дней, из которых 4 — ожидание. Код написан за 3 часа, а до прода ехал неделю.

Чтобы скорость не превратилась в бесконечный пожар, существует Change Failure Rate (процент изменений, которые привели к сбою). Она показывает, какой процент релизов заканчивается деградацией сервиса, откатом или судорожным хотфиксом. Быстро доставлять изменения – сомнительное достижение, если каждый второй выкат ломает систему. Но смысл тут в оценке здоровья системы, а не в поиске виноватых: насколько надежны тесты, не слишком ли большие порции кода вы пытаетесь пропихнуть за раз и насколько быстро работает обратная связь.

Замыкает четверку MTTR (время восстановления).
Если сбой всё же случился, как быстро команда способна прийти в себя? Насколько оперативно вы замечаете проблему, понимаете причину и возвращаете всё в норму. Сейчас эксперты всё чаще фокусируются именно на восстановлении после неудачных деплоев, чтобы не смешивать это с посторонними инцидентами. Это показатель того, насколько команда контролирует свою инфраструктуру.

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

Рассмотрим каждую из них подробнее.

Deployment Frequency

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

Если ваша команда деплоит раз в месяц, то каждый релиз превращается в «событие года» с ночными дежурствами и бесконечными чеклистами. 

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

Чтобы раскачать эту метрику, недостаточно просто нажать кнопку деплоя чаще. Нужно инвестировать в автоматизацию CI/CD и избавляться от ручных проверок там, где это возможно. Элитные перформеры по версии DORA (Топ 15%) деплоят несколько раз в день, в то время как отстающие могут делать это раз в полгода. Но помните: высокая частота деплоев – это не самоцель, а следствие того, что вы научились делать доставку кода незаметной и предсказуемой.

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

Lead Time for Changes 

Чистая эффективность вашего инженерного трубопровода. Она считает время от момента первого коммита (когда код попал в репозиторий) до момента, когда он начал приносить пользу на проде. DORA специально ограничивает этот отрезок, исключая этап обсуждения идеи. Почему? Потому что проектирование и продуктовые споры штука творческая и нелинейная, а вот путь готового кода до пользователя должен быть как прямая магистраль.

В здоровых компаниях Lead Time составляет меньше суток. Если у вас этот путь занимает неделю, значит, код где-то киснет. Самые частые места заторов  это долгое ожидание Code Review (когда PR висит три дня, потому что все заняты), очереди на ручное тестирование или жесткие релизные окна, когда код готов в понедельник, а выкатывать разрешают только в четверг. Lead Time подсвечивает не то, как медленно пишут разработчики, а то, как сильно им мешает организационное трение.

Улучшение метрики требует хирургической работы над процессами. Это может быть переход к Trunk-based development (отказ от долгоживущих веток), внедрение автоматизированных тестов, которые проходят за 10–15 минут, или упрощение системы согласований. Важно понимать, что каждый час, который готовый код проводит в ожидании деплоя это потери. За это время могут возникнуть конфликты слияния, или сама фича может потерять актуальность.

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

Change Failure Rate 

CFR главный предохранитель в системе DORA.
Метрика показывает, какой процент ваших изменений приводит к проблемам на проде: отказам системы, критическим багам или необходимости срочного отката. Если Deployment Frequency это ваша педаль газа, то CFR индикатор того, не горят ли у вас при этом тормоза. Элитные команды удерживают этот показатель в районе 0–15% (а в самых свежих отчетах даже ниже 5%).

Высокий процент ошибок обычно сигнализирует о проблемах с обратной связью. Это значит, что ваши тесты не ловят баги, стейджинг (тестовая среда) слишком сильно отличается от продакшена, или у команды нет культуры ответственности за свой код после мерджа. Интересно, что CFR почти никогда не равен нулю у тех, кто реально быстро развивается. Нулевой CFR часто означает, что команда настолько боится ошибок, что почти не рискует и релизится черепашьими темпами, обложившись горой согласований.

Чтобы снизить CFR, нужно внедрять практику «Shift Left» – тестировать как можно раньше и чаще. Автоматизация здесь критична, но не менее важна наблюдаемость (observability). Команда должна видеть, как их код ведет себя под нагрузкой, еще до того, как пользователи начнут писать в поддержку. Использование Feature Flags (флагов фич) также драматически снижает риск: вы можете выкатить код выключенным, проверить его на проде и плавно включить только для части пользователей.

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

Time to Restore Service

Ошибаются все, даже сверхэлита индустрии. Разница лишь в том, что элита восстанавливается после сбоя меньше чем за час, а новички могут лежать днями. Метрика Time to Restore (ранее известная как MTTR) замеряет время от момента обнаружения инцидента на проде до его полного устранения. В контексте DORA фокус делается именно на сбои, вызванные неудачными деплоями или изменениями в инфраструктуре.

Быстрое восстановление про готовность системы к сбоям, а не про сисадмина, который готов подорваться ночью чтобы срочно чинить.

 Если у вас есть кнопка автоматического отката (Rollback), если вы используете стратегии Blue-Green или Canary-деплоев, то время восстановления будет минимальным. Если же для исправления ошибки вам нужно заново собирать билд, прогонять все тесты и проходить через все круги согласований  вы будете лежать долго, теряя деньги и лояльность клиентов.

Для улучшения этой метрики критически важен мониторинг. Вы не можете починить то, о чем не знаете. Команды с низким Time to Restore узнают о проблемах из алертов системы, а не из жалоб в соцсетях. Культура безвиновных ретроспектив (blameless post-mortems) здесь тоже играет ключевую роль: вместо поиска виноватого команда фокусируется на том, как сделать систему устойчивее и как в следующий раз заметить проблему на 10 минут раньше.

Помните, что эта метрика  проверка вашей инженерной зрелости в бою. Она показывает, насколько прозрачна ваша инфраструктура и насколько команда доверяет своим инструментам. Высокая скорость восстановления дает разработчикам право на ошибку: когда ты знаешь, что любая проблема фиксится за 5 минут одним нажатием кнопки, ты перестаешь бояться релиза и начинаешь работать смелее и продуктивнее.

Deployment Rework Rate (налог на ошибки)

Не ждали пятой метрики?
В 2024 году DORA официально расширила золотую четверку, добавив пятый показатель – Deployment Rework Rate. Если старые метрики измеряли скорость и стабильность, то эта подсвечивает эффективность: какую долю усилий команда тратит на развитие продукта, а какую на исправление собственных косяков.

В чем суть?
Это процент внеплановых деплоев (хотфиксов, патчей, исправлений деградации), которые не приносят новой ценности, а лишь возвращают систему в рабочее состояние. По сути, метрика движения назад. Она показывает, сколько ресурсов съедает некачественный процесс поставки.

С первого взгляда есть пересечение с CFR, но там сухая статистика поломок. Он говорит: «Вы ломаете прод в 15% случаев», ноон не объясняет, во что это обходится команде. Одно дело нажать кнопку отката за 5 минут, и совсем другое неделю клепать патчи, чтобы закрыть дыры в безопасности или производительности. Rework Rate делает эту скрытую работу видимой.

Чтобы было проще понимать:

• CFR показывает, как часто случаются инциденты.

• MTTR  как быстро вы на них реагируете.

• Rework Rate – сколько реального времени и сил уходит на разгребание завалов вместо создания фич.

Это отличный инструмент для разговора с бизнесом. Когда команда не успевает в срок, Rework Rate наглядно объясняет, что ресурс уходит не на лень, а на налог за сложность и нестабильность системы.

Как работать с DORA-метриками и не обманывать себя?

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

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

DORA создает целостную картину системы: скорость показывает, насколько быстро вы двигаетесь, стабильность – насколько устойчиво вы стоите на ногах, а новая метрика Rework Rate подсвечивает, какой объем ресурсов вы тратите на бег на месте.

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

Частоту деплоев легко раздуть мелкими техническими выкладками или бесконечными хотфиксами, которые формально считаются релизом, но не несут никакой ценности для бизнеса. Lead Time можно искусственно улучшить, если просто дробить задачи в трекере на микроскопические части, не меняя при этом реальную инертность процессов вроде долгого ревью или очередей на тестирование. Даже Change Failure Rate превращается в игру определений, если команда договаривается считать инцидентами только полные падения системы, игнорируя незначительные деградации. В таких условиях метрика перестает быть инструментом правды и становится инструментом политической отчетности.

То же самое касается времени восстановления и налога на переделки. Можно формально закрыть инцидент, как только сервис подал признаки жизни, и записать в отчет красивые «десять минут на восстановление», хотя корень проблемы не найден, а инфраструктура держится на костылях. А с Deployment Rework Rate самообман часто кроется в том, что незапланированную работу просто прячут внутри обычных продуктовых задач. Если не маркировать исправление вчерашних ошибок как «переделку», вы никогда не увидите реальную цену своего технического долга. DORA прямо предупреждает: метрики нужны для поиска точек роста и проверки гипотез, а не ради самого факта измерения.

Чтобы реально улучшить показатели, нужно менять не цифры в таблице, а саму инженерную культуру. Для ускорения потока главным рычагом остается Continuous Delivery – переход к маленьким порциям кода, автоматизацию всего пути от коммита до продакшена и отказ от релизных дней, которые разве что копят стресс. 

Стабильность же растет не от запретов, а от качества обратной связи. Чем лучше у команды развит мониторинг и наблюдаемость, тем быстрее она замечает проблемы и тем меньше боится ошибок. Вместо того чтобы вводить дополнительные этапы согласования, которые только замедляют процесс, стоит инвестировать в автоматические откаты и канареечные релизы. Это снижает цену ошибки и позволяет восстанавливаться за считанные минуты. Если вы только подходите к внедрению DORA, не пытайтесь сразу построить идеальный дашборд. Начните с одной базовой линии и одного честного вопроса: где у нас сейчас больше всего трения? Улучшайте систему, а метрики подтянутся сами.

А мы ещё поговорим про DORA и в следующем материале расскажем о важных нюансах: работы с ними и другие подробности:

• Ещё способы улучшения DORA-метрик

• Бенчмарки DORA (кластеры производительности)

• Автоматический сбор (CI/CD, Git, трекер задач, мониторинг, incident management)

• Ручной сбор

• Чего Dora не показывает

• Как в России у команд дела с DORA (не певицей)

До встречи!