DevPace
БлогСправкаНовостиСкачатьДемоТарифыПривязка устройстваВойтиНачать

DORA-метрики: что это и почему они не про пользователей

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

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

Оглавление

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

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

Позже исследовательская программа DORA была приобретена Google и с тех пор ежегодно публикует отчёт State of DevOps — на основе опроса тысяч инженерных организаций по всему миру. В этих отчётах те же четыре метрики используются, чтобы разложить организации по категориям зрелости процесса поставки: от низкой до элитной. Отчёты меняются от года к году, добавляют новые срезы и вопросы, но ядро остаётся тем же — четыре метрики DORA, о которых пойдёт речь дальше.

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

Deployment frequency: как часто команда деплоит в продакшн

Deployment frequency — это то, как часто команда действительно выкатывает изменения в продакшн: не в тестовое окружение и не в ветку, готовую к релизу, а именно до пользователя. Метрика считает не количество коммитов и не количество pull request’ов, а именно завершённые развёртывания рабочего кода.

Логика метрики простая: команда, которая деплоит часто и небольшими порциями, обычно проходит через более короткий цикл обратной связи. Если в релиз попадает одна небольшая правка, и что-то идёт не так — источник проблемы очевиден. Если релиз копит изменения неделями и выкатывается одним большим пакетом, найти виновника среди полусотни изменённых файлов и десятка задач заметно труднее, а сама операция несёт больше риска просто по объёму того, что меняется одновременно.

Важная оговорка: высокая частота деплоя сама по себе не цель. Деплоить часто ради самой частоты — тот же соблазн, что и коммитить часто ради числа коммитов. Deployment frequency осмысленна только вместе с остальными тремя метриками, и в первую очередь — с change failure rate, о которой ниже.

Lead time for changes: сколько времени идёт от коммита до релиза

Lead time for changes измеряет время от момента, когда изменение закоммичено, до момента, когда оно успешно работает в продакшне. Это метрика скорости всего конвейера поставки — код-ревью, сборка, автоматические тесты, шаги деплоя, — а не скорости написания самого кода.

Здесь легко перепутать lead time for changes с тем, сколько разработчик потратил времени на саму задачу — но это разные вещи. Разработчик мог написать патч за двадцать минут, а затем изменение неделю ждало ревью, ещё день — слота в очереди деплоя, и ещё несколько часов — прогона медленного набора интеграционных тестов. Вся эта неделя целиком и есть lead time for changes, хотя фактическое время работы пользователя внутри неё — двадцать минут. Метрика измеряет систему вокруг изменения, а не усилие, вложенное автором коммита.

Именно поэтому lead time for changes часто оказывается полезным диагностическим инструментом для процесса, а не для пользователя: длинный lead time обычно указывает не на то, что кто-то долго пишет код, а на узкое место в конвейере — медленное ревью, редкие окна деплоя, нестабильные тесты, которые приходится перезапускать.

Change failure rate: доля изменений, которые ломают продакшн

Change failure rate — доля изменений, которые после выкатки в продакшн приводят к сбою, деградации сервиса или требуют немедленного отката, хотфикса или патча. Метрика считается как отношение неудачных изменений к общему числу деплоев за период.

Change failure rate — это естественный противовес deployment frequency. Наращивать частоту релизов, одновременно роняя продакшн каждым вторым из них, — не прогресс, а другая форма проблемы, просто быстрее повторяющаяся. Здоровый процесс поставки старается одновременно повышать частоту деплоя и удерживать долю сбоев низкой — а не жертвовать одним ради другого.

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

Time to restore service: как быстро команда восстанавливает сервис

Time to restore service — время, которое требуется команде, чтобы восстановить нормальную работу сервиса после сбоя, вызванного изменением. Метрика не про то, случаются ли инциденты — они случаются у всех, — а про то, насколько быстро организация способна их обнаружить, диагностировать и устранить.

Эта метрика напрямую зависит от вещей, которые почти никогда не в руках одного разработчика: качества мониторинга и алертинга, наличия понятного runbook’а для типовых инцидентов, скорости эскалации и координации между людьми в момент сбоя, возможности быстро откатить изменение вместо того, чтобы искать точечный фикс под давлением времени. Команда с хорошим time to restore service не обязательно та, что реже ошибается, — а та, что умеет быстро восстанавливаться, когда ошибка всё же произошла.

Таблица: четыре метрики DORA и как их обычно считают

Метрика DORA Что измеряет Как чаще всего собирается
Deployment frequency Как часто команда выкатывает изменения в продакшн Логи системы деплоя / CI-CD-конвейера за период
Lead time for changes Время от коммита до успешного релиза в продакшн Сопоставление меток времени в git и в системе деплоя
Change failure rate Доля релизов, вызвавших сбой, откат или хотфикс Данные системы инцидент-менеджмента, сопоставленные с релизами
Time to restore service Время восстановления сервиса после сбоя, вызванного изменением Время от открытия инцидента до его закрытия в системе мониторинга/инцидентов

Общее во всех четырёх строках таблицы: ни одна метрика не берётся из наблюдения за отдельным пользователем. Все они собираются из систем, которые существуют на уровне команды или организации, — CI/CD, системы деплоя, трекер инцидентов, мониторинг. Это не побочная деталь, а прямое следствие того, что именно эти метрики измеряют.

Категории зрелости: Elite, High, Medium, Low

В ежегодных отчётах State of DevOps организации по совокупности четырёх метрик распределяют по нескольким категориям зрелости процесса поставки — условно от низкой до элитной (Elite, High, Medium, Low performers в терминологии отчётов). Конкретные числовые границы между категориями отчёт от года к году уточняет и пересматривает, поэтому здесь сознательно не приводятся цифры — за точной актуальной формулировкой порогов стоит смотреть последний опубликованный отчёт DORA, а не полагаться на цифру из статьи произвольной давности.

Важнее самих порогов — принцип, по которому строится категория: она присваивается по совокупности всех четырёх метрик сразу, а не по одной из них в изоляции. Команда с очень высокой deployment frequency, но высокой же change failure rate, не попадает в верхнюю категорию только за счёт частоты релизов — низкая устойчивость перевесит. И, что здесь принципиально, категория присваивается организации, сервису или команде — не отдельному разработчику внутри неё. В отчётах DORA не существует и никогда не существовало понятия «Elite-разработчик»: единица анализа — процесс поставки, а не пользователь.

Почему DORA — это не про конкретного разработчика

Это центральная мысль всей статьи, и стоит разобрать её прямо, а не оставлять подразумеваемой. Соблазн понятен: у DORA-метрик хорошая репутация, они выглядят строго и количественно, и рано или поздно кто-нибудь предлагает считать их не для команды, а для конкретного разработчика — «сколько раз лично Иван задеплоил в этом месяце» или «какой у Марии change failure rate».

Проблема не в том, что так «не принято» — проблема в том, что так технически бессмысленно, потому что ломается сама причинно-следственная связь, на которой строится метрика. Deployment frequency — не результат работы одного пользователя: релиз проходит через ревьюера, через CI-конвейер, настроенный кем-то другим, через окно деплоя, которое администрирует третий человек. Lead time for changes ещё нагляднее: изменение может неделю пролежать в очереди ревью не по вине автора, а из-за того, что ревьюер был в отпуске — и вся эта неделя механически попадёт в «личный» lead time автора, ничего не говоря о его работе. Change failure rate одного пользователя статистически почти не имеет смысла: чтобы получить надёжную долю, нужны десятки деплоев за период, а у отдельного разработчика их банально может быть слишком мало, чтобы цифра не была случайным шумом. Time to restore service почти всегда результат командной работы в момент инцидента — эскалации, координации нескольких людей, — и приписывать скорость восстановления одному пользователю, участвовавшему в процессе, произвольно.

Здесь же работает эффект, уже описанный на примере строк кода и коммитов в обзоре метрик продуктивности разработчика: как только метрика становится индивидуальным KPI, у пользователя появляется стимул оптимизировать саму метрику, а не то, что она должна отражать. Если change failure rate станет личным показателем, самая рациональная реакция разработчика — не улучшать качество кода, а избегать деплоев вообще, дробить изменения так, чтобы формально не быть автором «сбойного» релиза, или просто откладывать рискованные, но нужные изменения на чужую смену. Ни один из этих сценариев не делает продукт лучше — они делают метрику удобнее для того, кого по ней оценивают.

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

Как проверить эти метрики на себе

Честный ответ здесь короткий: ни одну из четырёх DORA-метрик нельзя измерить локально — фоновым инструментом на одном рабочем компьютере, без доступа к системам всей команды. Deployment frequency и lead time for changes требуют данных CI/CD-конвейера и системы деплоя. Change failure rate и time to restore service требуют данных трекера инцидентов и системы мониторинга. Всё это существует на уровне инфраструктуры команды, а не на уровне отдельного ноутбука.

Что действительно можно сделать лично — это не подменить DORA-метрики, а честно определить границу. Если у вас или вашей команды уже есть доступ к CI/CD-панели и к трекеру инцидентов, все четыре метрики можно и стоит смотреть на уровне сервиса — это ровно те данные, для которых DORA и была придумана. Если такого доступа нет — например, вы один из нескольких разработчиков в команде без выделенной DevOps-инфраструктуры, — попытка приблизительно посчитать DORA-метрики вручную по логам обычно даёт больше искажений, чем пользы, и осмысленнее для начала внедрения DORA-метрик — завести хотя бы базовое логирование деплоев и инцидентов, а не пытаться сразу получить точную цифру без источника данных.

Отдельно от DORA стоит то, что можно честно измерить именно на своём уровне, без данных всей команды: собственный ритм git-коммитов, доля глубокой работы и частота переключений между категориями активности. Это не DORA-метрики и не их замена — это личные прокси-сигналы совсем другого рода, которые описывают структуру рабочего дня одного пользователя, а не процесс поставки команды. График git-коммитов по дням в DevPace показывает именно это: факт и время коммитов конкретного пользователя — честные метаданные локального уровня, которые полезно видеть, но которые нельзя путать с deployment frequency всей команды, даже если оба понятия звучат похоже.

FAQ

Можно ли использовать DORA-метрики для оценки эффективности одного разработчика? Нет — это прямое нарушение методологии фреймворка. Все четыре метрики измеряют процесс поставки команды или сервиса: на deployment frequency, lead time for changes, change failure rate и time to restore service влияют ревью, CI-конвейер, окна деплоя, координация при инцидентах — то есть система вокруг пользователя, а не только его личные действия. Применённые к одному разработчику, эти метрики либо статистически бессмысленны из-за малого числа наблюдений, либо провоцируют оптимизацию самой цифры в ущерб реальному качеству работы.

Чем DORA-метрики отличаются от SPACE? DORA сфокусирована на одном узком, но важном срезе — на пути изменения от коммита до пользователя: как часто и как быстро происходит релиз, и насколько он надёжен. SPACE — более широкий фреймворк из пяти измерений, включающий удовлетворённость, качество коммуникации и объём активности; подробный разбор — в статье про SPACE. DORA и SPACE не конкурируют, а описывают разные слои: DORA — инженерный конвейер, SPACE — более широкую картину работы разработчика.

С чего начать внедрение DORA-метрик, если раньше их не считали? Начать стоит не с расчёта всех четырёх метрик сразу, а с того, откуда вообще будут браться данные: логирование фактических деплоев (не намерений задеплоить, а завершённых развёртываний) и базовый трекер инцидентов, связанный с релизами. Deployment frequency и lead time for changes обычно проще получить первыми, если уже есть CI/CD-конвейер. Change failure rate и time to restore service требуют дисциплины в фиксации инцидентов и их причин — без этого числа будут неполными или произвольными с самого начала.

Итог

DORA-метрики — deployment frequency, lead time for changes, change failure rate и time to restore service — измеряют процесс поставки программного обеспечения, а не пользователя внутри него. Это следует не из этикета, а из самой природы данных: все четыре метрики собираются из систем, общих для команды — CI/CD, деплой, мониторинг, трекер инцидентов, — а не из наблюдения за одним рабочим местом. Попытка применить их к отдельному разработчику либо статистически бессмысленна, либо превращается в тот же эффект закона Гудхарта, что уже ломал метрики вроде числа строк кода и коммитов: метрика становится целью и перестаёт отражать реальность.

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

Смотрите также

Столбчатый график «Git-коммиты по дням» на странице «Тренд» в DevPace с неравномерными столбцами по дням

Ритм личных git-коммитов — честный локальный сигнал, но не deployment frequency: DORA считает завершённые релизы всей команды, а не факт коммита одного пользователя.

Посмотреть демо

Опубликовано: 30 июля 2026 г.