Что такое DORA
DORA (DevOps Research and Assessment) — исследовательская программа, которая с 2014 года ежегодно опрашивает тысячи специалистов и ищет связь между практиками разработки и результатами компаний. С 2018 года программа входит в Google Cloud. Метрики DORA описаны в книге «Accelerate» Николь Форсгрен, Джеза Хамбла и Джина Кима и стали стандартом, по которому оценивают скорость и надёжность релизов.
В данных DORA скорость и стабильность не противоречат друг другу. Команды, которые выкатывают изменения чаще, в среднем реже ломают production и быстрее восстанавливаются.
Пять метрик
В отчёте 2024 года DORA разделила метрики на две группы: пропускная способность и нестабильность. Тогда же добавили пятую метрику — rework rate.
| Метрика | Группа | Что измеряет |
|---|---|---|
| Lead time for changes | Пропускная способность | Время от коммита до работы изменения в production |
| Deployment frequency | Пропускная способность | Как часто команда выкатывает изменения в production |
| Failed deployment recovery time | Пропускная способность | Сколько времени уходит на восстановление после неудачного релиза |
| Change failure rate | Нестабильность | Доля релизов, после которых нужно срочное вмешательство: откат, хотфикс |
| Deployment rework rate | Нестабильность | Доля незапланированных релизов, которые чинят ошибки в production |
Время восстановления раньше называлось MTTR и относилось к стабильности. В 2023 году метрику переопределили, а в модели 2024 года перенесли в пропускную способность: оно показывает, как быстро команда может провести исправление через свой процесс.
Как считать каждую метрику
Lead time for changes
Для каждого коммита, попавшего в production, — разница между временем коммита и временем релиза, который его выкатил. Итог — медиана за период. Данные: Git и журнал релизов из CI/CD.
Полезно разложить lead time на этапы: работа над кодом, ожидание ревью, ревью, ожидание релиза. Так видно, где теряется время. После внедрения агентов этап написания кода обычно сокращается, а ожидание ревью растёт.
Deployment frequency
Число релизов в production за период. Считается по журналу деплоев. Для сервисов с несколькими компонентами считают релизы каждого сервиса отдельно и смотрят медиану по команде.
Change failure rate
Доля релизов, после которых понадобился откат, хотфикс или исправление вперёд. Самая сложная в сборе метрика: нужно связать инцидент или откат с релизом, который его вызвал. Минимальный вариант — помечать релизы-исправления в CI и связывать их с исходным релизом через тикет инцидента.
Failed deployment recovery time
Время от начала инцидента, вызванного релизом, до восстановления сервиса. Данные: система инцидентов или мониторинг. Медиана за период.
Deployment rework rate
Доля релизов, которые не планировались и выкатывались, чтобы исправить ошибку, заметную пользователям. Метрика показывает, сколько пропускной способности уходит на переделки. Для команд с агентами она особенно важна: рост числа релизов при росте rework rate означает, что агенты добавили команде работы.
Ориентиры
В отчёте 2024 года DORA разделила команды на четыре уровня кластерным анализом. К уровню elite отнесли 19% респондентов. Их показатели:
- lead time меньше одного дня;
- релизы по требованию, несколько раз в день;
- доля неудачных изменений около 5%;
- восстановление после неудачного релиза меньше чем за час.
У низкого уровня, 25% респондентов, lead time от месяца до полугода, а неудачным оказывается около 40% изменений.
В отчёте 2025 года DORA ушла от деления на четыре уровня и описала семь типов команд по сочетанию показателей релизов, качества и самочувствия людей. Для практики ориентиры важны меньше, чем динамика: метрики своей команды сравнивают с её же стартовым замером.
Какие метрики разработки добавить к DORA
DORA показывает результат на выходе. Чтобы понять причину, нужны метрики процесса:
- Размер изменений. Медианный размер MR в строках и файлах. Крупные изменения дольше ревьюят и чаще ломают production.
- Время до первого ревью и время ревью. Показывают, становится ли ревью узким местом.
- Незавершённая работа. Сколько MR одновременно открыто на человека.
- Доля переписанного кода. Какая часть кода переписывается в первые 2–3 недели после мержа.
- Время сборки и тестов в CI. Длинный CI тормозит и людей, и агентов, которые запускают проверки десятки раз за задачу.
Частые ошибки при замере
- Метрики как KPI отдельных людей. DORA-метрики описывают команду и процесс. Привязка к оценке людей приводит к дроблению релизов и переклассификации инцидентов.
- Средние значения. Один зависший на месяц MR испортит среднее lead time. Медиана и 85-й перцентиль показывают картину честнее.
- Нет стартового замера. Через три месяца после внедрения агентов не с чем сравнить, и разговор идёт про ощущения.
- Сравнение разных команд. Мобильное приложение с релизом раз в две недели и внутренний сервис с десятью деплоями в день нельзя ставить в один рейтинг.
- Только скорость. Рост частоты релизов без контроля change failure rate и rework rate может означать, что команда чаще выкатывает ошибки.
DORA-метрики при внедрении AI
Отчёт DORA 2025 года описывает AI как усилитель: команды с хорошими процессами получают прирост, у команд со слабыми процессами проблемы растут. DORA-метрики — способ понять, в какой группе ваша команда.
Порядок, который используют в проектах Праксора:
- До изменений в процессе снять стартовые DORA-метрики пилотной команды за 2–3 последних месяца.
- Добавить AI-метрики: доля решений, которые принимают агенты, и влияние этих решений на качество.
- Раз в неделю смотреть динамику и привязывать дефекты к спекам.
- Через три месяца сравнить со стартом на ревью с руководством.
Подробнее об измерении эффекта AI — в статье Как измерить эффект AI в разработке.
Замер в программе Праксора
На диагностике фиксируем стартовые метрики, чтобы через три месяца было с чем сравнить. На финальном ревью показываем DORA-метрики и AI-метрики против стартового замера. Пять шагов программы
Вопросы
Какие метрики входят в DORA?
Lead time for changes, deployment frequency, failed deployment recovery time, change failure rate и deployment rework rate. Пятая метрика, rework rate, появилась в отчёте 2024 года.
Откуда брать данные для DORA-метрик?
Из Git, журнала релизов CI/CD и системы инцидентов. Lead time и частота релизов собираются автоматически, для доли неудачных изменений нужно связывать инциденты и откаты с релизами.
Можно ли использовать DORA-метрики для оценки разработчиков?
Не стоит. Метрики описывают команду и процесс выпуска изменений. Привязка к оценке людей искажает данные: релизы дробят, инциденты переклассифицируют.
Как DORA-метрики помогают оценить внедрение AI?
Они показывают, стали ли изменения быстрее доходить до production и не выросла ли нестабильность. Для этого нужен стартовый замер до внедрения и сравнение через 2–3 месяца.