Что такое метрики DORA?
DORA — это методика и набор метрик для оценки производительности (команды и процессов). При помощи DORA можно понять, насколько эффективно и результативно проходят релизы, насколько эффективно поддерживается ПО. Часто применяется для оценки качества DevOps-процессов.
DORA — это 4 буквы от DevOps Research and Assessment, а не от названия метрик. Этот Research провел Google в 2022 и подвел итоги в формате метрик и рекомендаций:
Основные метрики DORA
- Частота развертываний (Deployment frequency) — это частота коммитов с изменениями
- Время развертывания (Lead time for changes) — это время между коммитом и появлением изменения на продакшене
- Среднее время восстановления (Mean time to recovery) — это среднее время для восстановления сервиса в случае сбоя/неудачного изменения
- Коэффициент отказов изменений (Change failure rate) — это процент изменений, которые привели к сбою/потребовали отката изменения
Детальный разбор метрик
Частота развёртываний/Deployment Frequency
Никто не знает какой именно продукт нужен пользователям, поэтому компании стремятся проверять максимально быстро (быстро делай - быстро ошибайся - быстро исправляйся). И теперь частые релизы — это стандартное ожидание к IT командам.
Описывают 4 уровня крутости:
- Элитный уровень: Несколько релизов в день
- Высокий уровень: Релизы каждую неделю/месяц
- Средний уровень: Релизы каждый месяц/полгода
- Низкий уровень: Релизы реже, чем раз в полгода
Понятно, что если у тебя SaaS/Интернет-магазин/Сайт, то стремиться стоит к частым релизам, а вот с коробочным решением релизы будут реже. Оценивай свой уровень с умом.
На эту метрику влияют:
- Размер фичей (нужно стремиться выкатывать порциями, под feature flags)
- Количество активных гипотез (нужно, чтобы различные продуктовые гипотезы могли работать одновременно)
Время выполнения изменений/Lead Time for Changes
Эта метрика измеряет время между коммитом и выпуском кода в продакшн. По сути, показывает уровень автоматизации этого процесса, а также зависимости от конкретных людей.
Для расчета нужно взять всё время от коммита разработчика до того, когда этот коммит оказался на продакшене (в том числе и время на ревью кода, проведение тестов).
Описывают 4 уровня крутости:
- Элитный уровень: Менее одного часа
- Высокий уровень: От одного дня до одной недели
- Средний уровень: От одного месяца до шести месяцев
- Низкий уровень: Более шести месяцев
На эту метрику влияют:
- Размер коммита/изменения (нужно стремиться к атомарным и небольшим изменениям)
- Время ревью (нужно стремиться к неблокирующему code review)
- Время отклика на ревью (нужно, чтобы команда не забивала на неделю)
- Code churn (нужно стремиться, чтобы объем свеже созданного и почти сразу же удаленного кода был минимальным)
Частота отказов изменений/Change Failure Rate
Эта метрика показывает, какой процент твоих изменений приводит к проблемам в продакшене. Простыми словами — сколько раз ты "накосячил" и пришлось откатывать или экстренно чинить.
Формула простая:
(количество неудачных развёртываний / общее количество развёртываний) × 100
Описывают 4 уровня крутости:
- Элитный уровень: 0-15% (почти идеально!)
- Высокий уровень: 16-30%
- Средний уровень: 31-45%
- Низкий уровень: Более 45%
Важно понимать: если у тебя низкая частота развёртываний, то и отказов будет мало — но это не значит, что ты крутой. Нужно смотреть на обе метрики вместе.
На эту метрику влияют:
- Качество тестирования (нужно стремиться к автоматизированным тестам, включая интеграционные и end-to-end)
- Размер изменений (маленькие изменения = меньше риск)
- Процесс code review (нужно, чтобы ревьюеры действительно проверяли логику изменения, а не просто ставили галочку)
- Мониторинг и алерты (нужно быстро узнавать о проблемах, а не через неделю от пользователей)
Время восстановления сервиса/Mean Time to Recovery (MTTR)
Эта метрика показывает, как быстро ты можешь починить сломанный сервис. От момента обнаружения проблемы до момента, когда всё снова работает.
Описывают 4 уровня крутости:
- Элитный уровень: Менее одного часа (почти мгновенно!)
- Высокий уровень: Менее одного дня
- Средний уровень: От одного дня до одной недели
- Низкий уровень: Более одной недели
На эту метрику влияют:
- Мониторинг и алерты (нужно быстро узнавать о проблемах)
- Автоматизация восстановления (rollback, health checks, auto-scaling)
- Документация и runbooks (нужно знать, что делать в случае проблем)
- Компетенции команды (нужно, чтобы кто-то умел быстро диагностировать и исправлять проблемы)
Вместе эти четыре метрики дают тебе комплексную картину того, как работает твоя команда в целом, и где могут быть области для улучшения. Это также может помочь выявить высокопроизводительных инженеров и выделить команды, нуждающиеся в поддержке.
Почему стоит использовать метрики DORA?
Делать быстро и не косячить — это базовые ожидания менеджмента от IT команды. При помощи DORA метрик можно договориться о конкретных цифрах для "что такое быстро" и "что такое не косячить".
Например, фичи должны появляться каждую неделю, 9 из 10 должны выкатываться без проблем.
А для IT команды - это возможность увидеть узкие места и начать над ними работать вместе.
Типичные ошибки применения DORA
- Выполнение метрик ради метрик (т.е. сиюминутное достижение целей)
- Не учитывать особенности индустрии в которой работаете (глобальный релиз в черную пятницу в магазине...к беде)
- Смотреть на одну метрику, а не в комплексе
- Анализ метрик "на глаз", а не автоматически