DORA-метрики на практике — что измерять и как улучшать поставку
Четыре метрики DORA простым языком: частота деплоев, время поставки, доля сбойных изменений и MTTR. Как их собирать и что с ними делать, чтобы релизы стали предсказуемыми.
DORA-метрики стали стандартом разговора о здоровье поставки, но на практике их часто либо не считают вовсе, либо считают «для отчёта» и не используют. Разберём четыре метрики по существу: что каждая означает, как её собрать без ручного труда и какие решения она подсказывает.
Что такое DORA-метрики
DORA (DevOps Research and Assessment) — это исследовательская программа, которая выделила четыре показателя, статистически связанных с производительностью команд:
- Частота деплоев (Deployment frequency) — как часто вы выкатываете в прод.
- Время поставки изменений (Lead time for changes) — сколько проходит от коммита до прода.
- Доля сбойных изменений (Change failure rate) — какой процент деплоев приводит к сбою.
- Время восстановления (MTTR) — как быстро вы чините прод после инцидента.
Первые две метрики говорят о скорости, вторые две — о стабильности. Зрелые команды улучшают и то, и другое одновременно — это и есть «элитный» уровень DORA.
Частота деплоев
Высокая частота деплоев — это не самоцель, а следствие малых батчей. Когда вы выкатываете часто, каждое изменение маленькое, его проще ревьюить, проще откатить и проще диагностировать, если что-то пошло не так.
Что подсказывает метрика: если деплои редкие и большие — ищите узкие места в CI/CD, ручные шаги, длинные циклы ревью. Дробление релизов почти всегда улучшает и стабильность тоже.
Время поставки изменений
Lead time показывает, сколько живёт изменение от написания до прода. Длинное время поставки означает, что код «застревает» — в ревью, в ожидании тестов, в очереди на релиз.
Что подсказывает метрика: разложите lead time на этапы (ревью, CI, ожидание релиза). Обычно один-два этапа дают основную задержку — туда и направьте усилия.
Доля сбойных изменений
Change failure rate — процент деплоев, потребовавших отката, хотфикса или вызвавших инцидент. Это прямой индикатор качества того, что вы выкатываете.
Что подсказывает метрика: растущий CFR — сигнал, что ревью и тесты пропускают проблемы. Здесь помогает контекстное ревью: проверка изменений против архитектурных решений и прошлых инцидентов ловит как раз те ошибки, которые приводят к сбоям.
Время восстановления (MTTR)
MTTR измеряет, как быстро вы возвращаете систему в норму. Важно не «никогда не падать» (это недостижимо), а быстро восстанавливаться.
Что подсказывает метрика: высокий MTTR обычно означает, что трудно понять, что сломалось. Если инциденты связаны с конкретными деплоями и PR, диагностика занимает минуты, а не часы.
Как собирать DORA без ручного труда
Главная ошибка — считать метрики вручную в таблицах. Это не масштабируется и быстро забрасывается. DORA должна собираться автоматически из тех данных, которые у вас уже есть: события деплоя из CI/CD, коммиты и PR из Git, инциденты из системы алертов.
В ShipGrid DORA-метрики считаются автоматически и стоят рядом с сигналами ревью — руководитель видит на одном экране и скорость, и стабильность, и причины: какие деплои дали сбой и какие изменения за ними стоят.
Главное
- DORA — это не отчёт, а инструмент принятия решений.
- Улучшайте скорость и стабильность вместе, а не по очереди.
- Связывайте метрики с деплоями, PR и инцидентами — тогда цифра превращается в конкретное действие.
Хотите видеть DORA-метрики своей команды рядом с ревью и инцидентами? Свяжитесь с нами — покажем на вашем стеке.