Change Failure Rate — это доля деплоев, которые приводят к откату, хотфиксу или инциденту в продакшене. Метрика отражает качество тестирования, ревью и релизных процессов в команде. Целевое значение для высокоэффективных организаций — ниже 15%, и его рост — повод пересмотреть подходы к валидации изменений.
Процент деплоев, вызвавших сбой или деградацию сервиса. Элитный уровень: <5%; начальный: >30%.
УСИЛИВАЮТСЯ: Ошибка в общей библиотеке монорепозитория способна сломать десятки сервисов разом. Без строгого контроля радиуса поражения один коммит может парализовать работу всей организации. Google решает это через обязательное тестирование всех зависимых проектов (presubmit).
Радиус поражения растёт с размером общей кодовой базы.
Больше сбоев → больше инцидентов.
Высокий CFR → избегание деплоев.
Сбои → культура страха вокруг релизов.
Давление пропустить тщательное ревью → формальное одобрение.
>1,000 строк → на 70% ниже обнаружение дефектов.
Высокое покрытие ловит больше багов до прода.
Разделённое внимание увеличивает частоту ошибок.
Глубокая концентрация → код более высокого качества.
Перегруженные разработчики делают больше ошибок.
Вовлеченные разработчики более внимательны к качеству.
Устраняет баги типа 'у меня работает'.
Хрупкий код чаще ломается при изменениях.
Плотность багов растет выше порога.
Постепенные раскатки ловят проблемы при малом радиусе поражения.
Меньшие частые деплои снижают риск.
Четкое владение обеспечивает правильное ревью изменений. Без этого общий код модифицируется без ревью экспертов.
Изменение общей утилиты, затрагивающее 50 сервисов, имеет радиус поражения в 50× больше, чем изменение одного сервиса.
Лучшие описания PR дают ревьюерам полный контекст даже без синхронного обсуждения.
Доменные эксперты-ревьюеры в каждом часовом поясе означают, что код проверяют люди, которые его понимают.
Внедрение AI коррелирует со снижением стабильности доставки.
45-51% AI-кода имеет уязвимости безопасности.