Метрики

Время освоения: ~40 минут Цель: Научиться выбирать, внедрять и интерпретировать инженерные метрики так, чтобы они улучшали процессы, а не искажали поведение команды

Инженерные метрики отвечают на вопрос: «Насколько эффективно работает наша инженерная организация?» Без метрик решения принимаются на интуиции. С неправильными метриками — на иллюзии.

Зачем нужны инженерные метрики:

Метрики для улучшения, не для контроля: метрики команды должны принадлежать команде. Как только они становятся инструментом контроля сверху вниз, поведение меняется — люди оптимизируют метрику, а не реальную ценность.

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.

Метрики без обсуждения бесполезны. Встроить анализ метрик в существующие ритуалы:

Оцените свою команду по 4 метрикам DORA:

Проанализируйте текущие метрики вашей команды:

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

Ключевые выводы:

Время освоения: 40 минут Уровень: Продвинутый Для кого: Тимлиды, Engineering Managers, Senior Engineers