Метрики DORA, скорость команды, время цикла, пропускная способность, оценка здоровья команды
Время освоения: ~40 минут Цель: Научиться выбирать, внедрять и интерпретировать инженерные метрики так, чтобы они улучшали процессы, а не искажали поведение команды
| Метрика | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | Несколько раз в день | Раз в день — раз в неделю | Раз в месяц — раз в 6 мес. | Реже раза в 6 мес. |
| Lead Time for Changes | Менее 1 часа | 1 день — 1 неделя | 1 неделя — 1 месяц | Более 6 месяцев |
| MTTR | Менее 1 часа | Менее 1 дня | 1 день — 1 неделя | Более 1 недели |
| Change Failure Rate | 0–5% | 0–15% | 0–15% | 16–30% |
| Категория | Метрики | Что измеряют |
|---|---|---|
| Delivery | Deployment Frequency, Lead Time, Cycle Time | Скорость доставки ценности |
| Quality | Change Failure Rate, Bug Escape Rate, Test Coverage | Надёжность и качество кода |
| Team | Velocity, Throughput, MTTR | Мощность и устойчивость команды |
| Health | eNPS, Attrition Rate, психологическая безопасность | Долгосрочная устойчивость |
| Используй | Не используй |
|---|---|
| DORA для измерения зрелости DevOps | Velocity для сравнения команд |
| Cycle Time для поиска узких мест | Story points как KPI разработчика |
| Bug Escape Rate для оценки качества | Lines of Code как меру продуктивности |
| eNPS для мониторинга здоровья команды | Количество коммитов для оценки вклада |
Инженерные метрики отвечают на вопрос: «Насколько эффективно работает наша инженерная организация?» Без метрик решения принимаются на интуиции. С неправильными метриками — на иллюзии.
Зачем нужны инженерные метрики:
Метрики для улучшения, не для контроля: метрики команды должны принадлежать команде. Как только они становятся инструментом контроля сверху вниз, поведение меняется — люди оптимизируют метрику, а не реальную ценность.
💡 Ключевая мысль: Goodhart's Law — «Когда метрика становится целью, она перестаёт быть хорошей метрикой». Команда начнёт оптимизировать число, а не то, что оно должно было измерять. Например: если KPI — количество деплоев, появятся деплои из одной строки. Если KPI — test coverage, появятся тесты без assertions.
DORA (DevOps Research and Assessment) — исследование Google, которое выявило 4 метрики, лучше всего коррелирующие с бизнес-результатами: скоростью доставки, стабильностью и прибыльностью.
Что это: Как часто команда делает деплой кода в продакшн.
Почему это важно: Высокая частота деплоев означает маленькие батчи изменений. Маленькие батчи легче тестировать, проще откатывать, быстрее доставляют ценность.
Как измерять: Считать количество деплоев в продакшн за период (день/неделя). Инструменты: CI/CD дашборды (GitHub Actions, GitLab CI, Argo CD).
Антипаттерн: Деплоить чаще ради метрики, не улучшая процессы — это нарушение Goodhart's Law.
Что это: Время от первого коммита по задаче до попадания изменений в продакшн.
Почему это важно: Длинный lead time означает длинную петлю обратной связи. Команда долго не знает, работает ли фича в продакшне.
Как измерять: Временная метка первого коммита → временная метка деплоя в продакшн. Автоматизировать через CI/CD пайплайн или инструменты типа LinearB, Jellyfish.
Что влияет на lead time: размер PR, длина очереди на ревью, ручные этапы в пайплайне, время на тестирование.
Что это: Среднее время от момента инцидента до полного восстановления сервиса.
Почему это важно: Инциденты неизбежны. Важна не их полное отсутствие, а способность быстро восстанавливаться — это и есть resilience (устойчивость).
Как измерять: Фиксировать время начала инцидента и время восстановления. Инструменты: PagerDuty, Opsgenie, incident tracking в Jira.
Что улучшает MTTR: observability (логи, метрики, трейсы), runbooks, feature flags для быстрого отключения, автоматические алерты.
Что это: Доля деплоев, которые привели к инцидентам, откатам или hotfix-ам.
Почему это важно: Показывает качество процесса доставки. Высокий CFR означает, что деплои регулярно ломают продакшн.
Как измерять: (Количество проблемных деплоев / Всего деплоев) × 100%. Elite — менее 5%.
Баланс с Deployment Frequency: увеличение частоты деплоев без роста CFR — признак зрелого инженерного процесса.
Velocity (скорость): среднее количество story points за спринт. Использовать только для внутреннего планирования. Не сравнивать между командами — шкалы points уникальны для каждой команды.
Cycle Time (время цикла): время от начала работы над задачей до её завершения. Полезна для поиска узких мест в процессе. Если cycle time растёт — ищи причину (WIP, блокеры, сложность задач).
Throughput (пропускная способность): количество задач завершённых за период. Более объективен чем velocity, так как не зависит от оценок в story points.
Как использовать правильно:
Доля багов, обнаруженных в продакшне, от общего числа дефектов. Низкий Bug Escape Rate означает, что QA-процессы работают эффективно.
Формула: (Баги в продакшне / Все баги) × 100%
Процент кода, покрытого автоматическими тестами. Важен не сам процент, а его динамика и качество тестов. 80% coverage с плохими тестами хуже, чем 60% с качественными.
Антипаттерн: Гнаться за 100% coverage — появятся бессмысленные тесты, написанные для метрики.
Отношение времени на рефакторинг к общему времени разработки. Индикатор того, насколько технический долг замедляет команду.
Технические метрики показывают, что происходит сейчас. Метрики здоровья команды предсказывают, что будет через 6–12 месяцев.
Вопрос: «Насколько вероятно, что вы порекомендуете нашу компанию как место работы?» (0–10). Считается как % промоутеров (9–10) минус % детракторов (0–6).
Использование: Проводить ежеквартально. Смотреть динамику, не абсолютное значение. Сочетать с follow-up вопросами «почему?»
Измерять через опросы (шкала Эдмондсон): «Могу ли я высказать мнение без страха наказания?», «Комфортно ли мне признавать ошибки?»
Почему важно: Команды с высокой психологической безопасностью быстрее учатся, реже скрывают проблемы, эффективнее проводят blameless postmortem-ы.
Процент ушедших сотрудников за период. Высокий attrition — самый дорогой сигнал о проблемах. Замена одного разработчика стоит 6–12 месячных зарплат.
Начни с вопроса: «Какую проблему мы хотим решить?» Затем выбери 3–5 метрик, которые покажут прогресс. Не измеряй всё — измеряй важное.
Прежде чем улучшать, зафиксируй текущее состояние. Baseline даёт точку отсчёта и позволяет увидеть улучшения.
Автоматизировать сбор данных насколько возможно. Ручной сбор — источник ошибок и дополнительной нагрузки на команду. Инструменты: Grafana, LinearB, Jellyfish, встроенные дашборды в GitHub/GitLab.
Метрики без обсуждения бесполезны. Встроить анализ метрик в существующие ритуалы:
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Velocity как KPI команды перед руководством | Команда накручивает числа, берёт лёгкие задачи, режет качество | Velocity — внутренний инструмент планирования, не KPI |
| Измерение Lines of Code как меры продуктивности | Больше кода ≠ больше ценности; создаёт стимул раздувать код | Измерять деплои, lead time, бизнес-результаты |
| Слишком много метрик одновременно | Время тратится на сбор данных, а не на их использование | 3–5 ключевых метрик, остальные — по необходимости |
| Ручной сбор метрик | Данные устаревают, есть ошибки, команда тратит время впустую | Автоматизировать через CI/CD, Jira, Git аналитику |
| Сравнение DORA метрик разных команд без контекста | Разные домены, зрелость, legacy — сравнение некорректно | Сравнивать динамику одной команды, не абсолютные значения |
| Игнорировать метрики здоровья команды | Attrition и выгорание не видны до кризиса | Проводить eNPS ежеквартально, отслеживать психологическую безопасность |
Оцените свою команду по 4 метрикам DORA:
Проанализируйте текущие метрики вашей команды:
Далее: Культура команды