Перейти к содержимому

Метрики Delivery: скорость и надёжность по DORA

Delivery превращает выбранное решение в работающий продукт. DORA измеряет поставку изменений в production; показатели очередей и прохождения задач дополняют её через метрики потока. Продуктовый эффект оценивается отдельно — в Discovery.

Уточнение источника: статья WP Craft описывает набор из четырёх метрик. Официальное руководство DORA, обновлённое 5 января 2026 года, использует пять, включая Deployment Rework Rate. Ниже приведён этот набор. Время восстановления относится к неудачным деплоям, а не ко всем возможным сбоям сервиса.

МетрикаРасчётПример
Deployment Frequency — частота деплоевЧисло production-деплоев за период; возможен также анализ интервала между ними20 деплоев за 10 рабочих дней — в среднем 2 в рабочий день
Change Lead Time — время поставки измененияПервый успешный production-деплой с изменением − время коммитаС понедельника 10:00 до вторника 16:00 — 30 часов
Failed Deployment Recovery Time — время восстановления после неудачного деплояВремя до восстановления сервиса после деплоя, потребовавшего немедленного вмешательстваДля 20, 40 и 120 минут среднее — 60 минут, медиана — 40 минут
Change Fail Rate — доля неудачных деплоевДеплои, потребовавшие немедленного вмешательства, ÷ все production-деплои × 100%3 из 40 — 7,5%
Deployment Rework Rate — доля внеплановых исправляющих деплоевВнеплановые деплои вследствие production-инцидентов ÷ все production-деплои × 100%4 из 40 — 10%; иллюстративный пример расчёта

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

Change Fail Rate считает исходный проблемный деплой один раз, даже если он вызвал несколько инцидентов. Deployment Rework Rate считает последующие внеплановые деплои для исправления инцидентов. У этих показателей разные числители; один не заменяет другой.

  • Git: идентификатор и время коммита, связь изменения с артефактом поставки.
  • CI/CD: идентификатор деплоя, окружение, состав изменений, время и результат. Staging-деплои не включайте в production-метрики.
  • Журнал инцидентов: проблемный деплой, момент обнаружения деградации, фактическое восстановление и исправляющие деплои.

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

Не смешивайте дату создания тикета с Change Lead Time. Развёртывание и открытие функции через feature flag могут происходить в разные моменты; частота деплоев не доказывает, что пользователи получили новую ценность.

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

Проверьте эффект изменения по всему набору. Цель «деплоить чаще» без контекста провоцирует улучшение цифры без улучшения системы. Внешние бенчмарки используйте с указанием версии отчёта и сопоставимых условий; несхожие сервисы и команды не объединяйте в один рейтинг.