Критерии остановки эксперимента: когда продолжать, ставить на паузу и откатывать изменение

07.09.2026 · Аппаратные решения

Эксперимент опасно заканчивать по формуле «на графике уже всё видно». До запуска полезно определить не только целевую метрику, но и условия, при которых эксперимент продолжается, временно замораживается, прекращается или приводит к откату изменения. Иначе одна и та же динамика легко получает разные трактовки в зависимости от того, какой результат команда хочет увидеть.

Для инженерного эксперимента это особенно важно: решение должно зависеть не от настроения в момент просмотра дашборда, а от заранее описанного контракта. В нём отдельно фиксируют цель, защитные метрики, допустимые ограничения, правила чтения промежуточных данных и действие при нарушении условий.

Такой контракт связывает сразу несколько слоёв системы. Canary deployment ограничивает масштаб воздействия, наблюдаемость показывает состояние новой версии, а критерии остановки отвечают на следующий вопрос: что именно делать, когда полученные сигналы перестают соответствовать допустимому сценарию.

Остановка эксперимента — не одно действие

В рабочих обсуждениях слова «остановить тест» часто скрывают несколько разных решений. Их лучше развести заранее, потому что последствия у них разные.

Решение	Что происходит	Когда оно уместно
Продолжить	Экспозиция и сбор данных идут по плану	Нет нарушений защитных условий, данные пригодны для анализа, запланированное окно ещё не завершено
Зафиксировать текущий этап	Долю новой версии не увеличивают, но эксперимент не сворачивают	Появился пограничный сигнал, которому нужно больше данных или диагностика без расширения воздействия
Поставить на паузу	Команда временно прекращает дальнейшее воздействие или анализ до выяснения причины	Есть проблема с телеметрией, назначением групп, инфраструктурой или другим условием, которое делает вывод ненадёжным
Остановить эксперимент	Экспериментальное сравнение завершается	Достигнуто заранее заданное условие завершения либо продолжение больше не отвечает цели эксперимента
Откатить изменение	Система возвращается к заранее определённому стабильному состоянию	Нарушено защитное условие, риск для пользователей или системы выше допустимого

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

Сначала задают цель, потом — то, что нельзя сломать

Основная метрика отвечает на вопрос, ради чего вообще проводится эксперимент. Guardrail-метрика отвечает на другой вопрос: какое ухудшение нельзя игнорировать, даже если основная метрика выглядит лучше.

Например, изменение алгоритма может повысить долю завершённых действий, но одновременно увеличить частоту ошибок или задержку ответа. Тогда рост основной метрики сам по себе ещё не даёт решения «раскатывать дальше».

Guardrail полезен только тогда, когда до старта понятно:

какой именно показатель защищаем;
в какую сторону его изменение считается ухудшением;
какая область пользователей, запросов или инфраструктуры относится к проверке;
какое условие считается нарушением;
нужно ли подтверждение сигнала дополнительным окном или другим методом;
что происходит после нарушения: уведомление, фиксация текущего этапа, пауза или rollback;
кто принимает решение, если автоматическое действие не предусмотрено.

Универсального процента ухудшения здесь нет. Допустимая граница зависит от самой метрики, её вариативности, цены ошибки, масштаба воздействия и того, насколько критичен защищаемый компонент. Произвольный порог, выбранный уже после появления неудобного графика, перестаёт быть защитным правилом и превращается в объяснение задним числом.

Stop condition лучше описывать как правило, а не как число

Формулировка «остановить при росте ошибок» слишком расплывчата. Непонятно, какие ошибки считаются, с чем они сравниваются, за какой период и должно ли однократное отклонение немедленно запускать действие.

Более полезный формат выглядит как небольшой контракт:

Поле	Что фиксируем до запуска
Сигнал	Конкретная метрика или диагностическое условие
Область	Какая версия, сегмент, сервис или единица эксперимента относится к правилу
База сравнения	Контроль, исходное состояние или другое заранее обоснованное сравнение
Направление риска	Что именно считается ухудшением
Окно проверки	Какой объём наблюдений или какой временной контекст нужен до решения
Метод решения	Как отделяется устойчивый сигнал от случайного колебания
Действие	Продолжить, удержать этап, поставить на паузу, остановить или откатить
Ответственный	Кто разбирает неоднозначный случай и кто имеет право отменить автоматическое действие

Такой формат защищает от двух противоположных ошибок: продолжать опасный эксперимент из-за хорошей основной метрики и сворачивать нормальное изменение из-за одного шумного скачка.

Критерии остановки бывают разного происхождения

Все условия не стоит сводить в один список p-value и технических алертов. На практике у них разная природа.

1. Защитные условия продукта и системы

Это сигналы, которые ограничивают допустимый ущерб: ошибки, падения, задержки, неуспешные операции, нагрузка на критичный компонент или другой показатель, связанный с надёжностью и пользовательским опытом.

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

2. Условия качества данных

Если экспериментальная инфраструктура перестала давать достоверное сравнение, продолжать интерпретацию результата опасно. Причиной может быть нестабильное назначение вариантов, неожиданное соотношение групп, потеря событий, разная работа telemetry между вариантами или ошибка идентификации единицы эксперимента.

Это не обязательно «провал варианта». Часто правильное действие — поставить анализ на паузу и сначала восстановить пригодность данных. Иначе техническую проблему легко принять за продуктовый эффект.

3. Условия статистического завершения

Если эксперимент допускает промежуточные решения по накопленным данным, метод анализа должен учитывать сам факт повторных просмотров. Обычный фиксированный тест нельзя безнаказанно проверять снова и снова и заканчивать в тот момент, когда случайное колебание впервые стало «значимым».

Для такого сценария используют заранее выбранный последовательный метод или другую процедуру, которая корректно учитывает промежуточные решения. Важно не конкретное название метода, а совпадение между статистическим дизайном и реальным поведением команды: если команда собирается принимать решение до фиксированного финала, это должно быть предусмотрено в анализе с самого начала.

4. Ресурсные и календарные ограничения

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

Такое завершение не нужно маскировать под доказательство эффекта. В отчёте достаточно честно зафиксировать, почему сбор данных остановлен и какой вывод при имеющихся данных допустим.

Почему нельзя останавливать тест при первом удобном p-value

Проблема раннего просмотра возникает не из-за самого дашборда. Смотреть на данные можно и иногда необходимо — особенно ради безопасности. Ошибка появляется, когда стандартный анализ с фиксированным моментом решения фактически превращают в последовательный: проверяют результат много раз и заканчивают эксперимент именно на удачном промежуточном значении.

При таком поведении вероятность ложноположительного решения становится выше той, которую команда ожидает от однократного теста. Поэтому фраза «мы проверяем каждый день, но метод тот же» описывает уже другой процесс принятия решения.

Отсюда важное разделение:

операционный мониторинг может идти постоянно, потому что система должна быстро замечать реальные проблемы;
статистическое решение об эффекте должно соответствовать заранее выбранной процедуре анализа;
экстренный rollback не обязан ждать финального продуктового вывода, если нарушено критичное защитное условие.

Эти три режима не стоит смешивать в одной кнопке «Stop experiment».

Guardrail не обязан автоматически объявлять эксперимент проигранным

Срабатывание защитной метрики означает прежде всего то, что появился риск, который нужно обработать по заранее описанному правилу. В одном эксперименте это действительно немедленный veto и rollback. В другом — остановка дальнейшего ramp-up и ручная диагностика. В третьем — повторная проверка сигнала по предусмотренной процедуре.

Поэтому полезно отделять факт нарушения от действия после нарушения. Если эти два шага склеены только в голове команды, решения начинают меняться от случая к случаю.

Простейшая схема:

guardrail в норме
→ продолжаем по плану

пограничный сигнал
→ не увеличиваем экспозицию
→ проверяем данные и устойчивость сигнала

подтверждённое нарушение
→ выполняем заранее назначенное действие

критический инцидент
→ защищаем систему и пользователей
→ rollback может предшествовать финальному анализу гипотезы

Rollback должен быть частью дизайна, а не импровизацией

Фраза «если что — откатим» почти ничего не гарантирует. До запуска нужно понимать, что именно считается стабильным состоянием и каким способом к нему возвращаются.

Минимально полезно зафиксировать:

какая версия или конфигурация считается точкой возврата;
можно ли отключить изменение независимо от нового деплоя;
какая доля трафика должна вернуться на стабильный вариант;
есть ли необратимые побочные эффекты, которые rollback кода не отменяет;
кто запускает откат и кто подтверждает восстановление;
какие сигналы после отката должны вернуться в нормальное состояние;
что записывается в журнал эксперимента после срабатывания условия.

Именно здесь stop conditions естественно продолжают тему canary release. Ограниченная экспозиция снижает радиус воздействия, но сама по себе не решает, когда увеличивать долю новой версии и когда возвращаться назад. Эти решения появляются только после связи rollout со считываемыми сигналами и заранее определёнными действиями.

Без наблюдаемости правило остановки остаётся декларацией

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

До запуска стоит проверить не только «есть ли метрика на графике», но и весь путь сигнала:

событие действительно возникает в нужной части системы;
оно привязано к правильной версии или варианту;
данные доходят до хранилища без систематической потери;
задержка поступления известна;
дашборд или правило используют ту же формулу, которая была зафиксирована в плане;
есть способ перейти от аномального значения к логам, трассировкам или другому диагностическому контексту.

Если этого пути нет, даже идеально сформулированный guardrail может не сработать вовремя. Тогда проблема уже не в критерии остановки, а в наблюдаемости самого эксперимента.

Отдельно проверяйте здоровье эксперимента

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

В такой ситуации не нужно выбирать между «победил контроль» и «победил treatment». Сначала следует остановить интерпретацию и диагностировать систему назначения и сбора данных.

Практический pre-launch контракт

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

Поле	Что записать
Гипотеза	Какое изменение проверяем и какой результат ожидаем
Основная метрика	Какой показатель отвечает на главный вопрос эксперимента
Guardrails	Что не должно ухудшиться сверх заранее принятой границы
Здоровье эксперимента	Какие проверки подтверждают корректность assignment и telemetry
План наблюдения	Когда смотрим операционные сигналы и когда допускается статистическое решение
Условие продолжения	Что должно быть истинно для сохранения или увеличения экспозиции
Условие паузы	Какой сигнал требует диагностики без окончательного вывода
Условие остановки	Когда экспериментальное сравнение завершается
Условие rollback	Какое нарушение требует возврата к стабильному варианту
Действие после остановки	Какие данные и причины фиксируются перед следующим решением
Ответственный	Кто подтверждает неоднозначный случай и выполняет действие

Самая полезная проверка этой таблицы звучит просто: сможет ли другой инженер, который не участвовал в обсуждении гипотезы, по этим правилам понять, что делать при конкретном сигнале? Если нет, критерии ещё слишком расплывчаты.

Что фиксировать в момент остановки

После stop condition важно сохранить не только итоговый график. Для воспроизводимого разбора нужны:

время срабатывания условия;
версия и конфигурация эксперимента;
текущая экспозиция;
метрика или диагностический сигнал, который инициировал действие;
снимок основных и защитных показателей;
состояние assignment и telemetry;
принятое действие: hold, pause, stop или rollback;
кто подтвердил решение;
что изменили после остановки;
какие вопросы остались без ответа.

Такой журнал особенно важен, когда эксперимент не дал ожидаемого результата. Иначе через несколько недель команда видит только финальное состояние системы и восстанавливает причины по памяти.

Типовые ошибки

Критерий появляется после запуска. Команда сначала смотрит на данные, а потом выбирает удобное правило решения.
Основную метрику принимают за единственную. Локальный выигрыш заслоняет ухудшение надёжности или пользовательского опыта.
Любой скачок guardrail запускает rollback. В правило не заложены шум, задержка данных и способ подтверждения пограничного сигнала.
Наоборот, rollback всегда требует долгого согласования. Даже критичный сигнал продолжает воздействовать на пользователей, пока команда обсуждает очевидное действие.
Статистический и операционный мониторинг смешаны. Проверка безопасности превращается в неформальный способ досрочно искать «победителя».
Остановка считается доказательством причины. Сам факт, что метрика ухудшилась после изменения и сработал защитный механизм, ещё не объясняет, почему это произошло.
Никто не отвечает за действие. Условие формально существует, но в момент срабатывания непонятно, кто должен заморозить ramp-up или откатить версию.

Итог

Хороший stop condition — это не магическое число на дашборде. Это заранее согласованная связь между сигналом, областью эксперимента, способом проверки и конкретным действием.

Рабочая схема выглядит так: цель → guardrails → здоровье данных → правило промежуточного наблюдения → условие продолжения или паузы → условие остановки → rollback при необходимости → фиксация причин и состояния.

Так эксперимент остаётся управляемым даже тогда, когда данные идут не по ожидаемому сценарию. Команда не обязана заранее знать результат, но она должна заранее понимать, какие сигналы изменят её действия и почему.