Релизы выходят часто, но значительная часть изменений требует отката или срочного исправления. Какой показатель качества поставки это выявляет?
Это выявляет коэффициент неудачных изменений (Change Failure Rate): долю поставок, после которых потребовались откат, срочное исправление или другое восстановительное действие. Показатель оценивает не количество найденных дефектов, а стабильность изменений после их попадания в целевую среду.
Команды долго оценивали поставку преимущественно по скорости и частоте релизов. Такой подход мог поощрять быстрые, но нестабильные изменения, поэтому в практике управления инженерными процессами понадобился показатель, связывающий выпуск изменения с последствиями для эксплуатации.
Change Failure Rate используется в модели инженерных метрик DORA вместе с показателями скорости поставки. Его задача — не заменить тестовые метрики, а показать, насколько часто процесс доставки приводит к необходимости восстановления.
Низкое число дефектов, найденных QA, ещё не означает стабильную поставку. Ошибка может проявиться только при реальном трафике, специфичной конфигурации или взаимодействии с внешней системой.
Если оценивать только частоту релизов, команда может увеличить темп ценой роста откатов и срочных исправлений. Если считать только дефекты, найденные до production, останутся незамеченными последствия изменений, которые формально прошли тестирование.
Показатель рассчитывают как отношение числа изменений, потребовавших восстановительного действия, к общему числу поставленных изменений за выбранный период. В числитель обычно относят откаты, исправления, экстренные патчи и другие случаи, когда поставка вызвала заметное нарушение или потребовала вмешательства.
Важно заранее зафиксировать правила подсчёта. Нужно определить, что считается изменением, какая среда учитывается, как обрабатываются повторные попытки поставки и какой период анализа применяется. Без единой трактовки разные команды будут получать несопоставимые значения.
Метрика показывает частоту неудач, но не их тяжесть. Два процесса могут иметь одинаковый показатель: в одном происходят короткие откаты без пользовательского ущерба, в другом — редкие, но длительные инциденты. Поэтому показатель следует рассматривать вместе с длительностью восстановления, влиянием инцидентов и данными анализа первопричин.
Метрику нельзя использовать как индивидуальную оценку QA или разработчиков. Иначе команда начнёт скрывать инциденты, дробить изменения искусственно или избегать рискованных, но необходимых улучшений. Её назначение — обнаруживать слабые места процесса поставки и выбирать меры снижения риска.
Команда выпускает изменения ежедневно. За месяц было 100 поставок, после 18 из них потребовались откат или срочное исправление. Значит, коэффициент неудачных изменений за этот период составляет 18% при согласованных правилах классификации.
Рассматривались три варианта. Можно было увеличить число ручных регрессионных проверок перед каждым выпуском: это могло снизить часть ошибок, но увеличило бы время обратной связи и не проверило бы поведение под реальным трафиком. Можно было просто сократить частоту релизов: это уменьшило бы количество событий, но не устранило бы причины неудачных изменений и увеличило бы размер поставки.
Выбранным решением стали анализ первопричин для неудачных поставок, автоматическая проверка совместимости изменений и постепенное включение функциональности для ограниченной аудитории. Такой подход позволил раньше обнаруживать проблемы и уменьшать радиус воздействия, не отказываясь от частых поставок.
Доля пострелизных дефектов считает дефекты и зависит от правил их регистрации, серьёзности и полноты обнаружения. Change Failure Rate считает поставки, которые потребовали восстановления, поэтому одна неудачная поставка учитывается как событие независимо от количества связанных дефектов. Он отвечает на вопрос о надёжности процесса изменений, а не о полном числе ошибок в продукте.
Только если одинаково определены единица поставки, критерии неудачи, учитываемая среда и период измерения. Команда, выпускающая маленькие изменения, и команда, поставляющая крупные пакеты, имеют разный профиль риска даже при одинаковом проценте. Поэтому показатель полезнее для анализа динамики одной команды и сопоставимых процессов, чем для механического рейтинга подразделений.
Сам по себе рост частоты релизов не доказывает ухудшение качества. Нужно анализировать одновременно общий объём поставок, долю неудачных изменений, тяжесть последствий и время восстановления. Если частота поставок выросла, а доля неудач стабильна и восстановление ускорилось, процесс мог стать эффективнее; если растут и доля, и ущерб, следует искать проблемы в стратегии тестирования, контролях поставки или управлении изменениями.