Сервис исчерпал допустимый бюджет ошибок, но бизнес настаивает на новом релизе. Как механизм error budget должен повлиять на решение?
При исчерпанном error budget релиз, повышающий операционный риск, должен быть приостановлен либо пропущен только через явно оформленное исключение с ответственным владельцем. Команда временно переключает capacity с доставки новых функций на восстановление надёжности, пока фактический уровень ошибок не вернётся в согласованные пределы.
Error budget не является автоматическим запретом на любые изменения. Это заранее согласованное правило принятия решений, связывающее допустимое нарушение SLO с приоритетами разработки.
Подход возник как часть практик SRE для разрешения конфликта между скоростью выпуска изменений и надёжностью сервисов. Без такого механизма команда разработки заинтересована чаще поставлять функции, а эксплуатация — минимизировать любые изменения, способные вызвать инциденты.
SLO задаёт целевой уровень качества сервиса, например доступность или долю успешных запросов. Разница между целевым уровнем и допустимым уровнем отказов образует бюджет ошибок: он показывает, какой объём нестабильности организация сознательно принимает за выбранный период.
Если бизнес продолжает выпускать изменения после исчерпания бюджета, нарушается заранее согласованный уровень риска. Последствия могут включать рост инцидентов, ухудшение пользовательского опыта, увеличение нагрузки на поддержку и потерю доверия к SLO как к рабочему критерию.
Простое требование не выпускать ничего после превышения порога тоже может быть ошибочным. Аварийное исправление, изменение для снижения риска или обязательное регуляторное обновление могут быть важнее обычного функционального релиза, поэтому политика должна различать типы изменений.
Сначала определяют SLO, период расчёта, источник данных и момент, с которого бюджет считается исчерпанным. Ошибки должны измеряться по пользовательски значимому сигналу: например, по неуспешным запросам, недоступности критичного сценария или превышению допустимой задержки, а не только по числу внутренних исключений.
Далее задают правила использования бюджета. Пока бюджет сохраняется, команда может выпускать изменения в обычном режиме. При его быстром расходовании усиливают проверки, требуют постепенного выпуска или дополнительного наблюдения. При исчерпании бюджета обычные рискованные изменения ставят на паузу, а приоритет получают устранение причин деградации, повышение наблюдаемости и проверка восстановительных процедур.
Решение должно опираться на тренд, а не только на текущее значение. Быстрое потребление бюджета указывает на риск нарушения SLO до конца расчётного периода даже тогда, когда остаток ещё формально положителен.
Исключения оформляют явно: указывают причину, оценку риска, компенсирующие меры, срок действия и ответственного за принятие решения. Такой процесс не устраняет риск, но делает его видимым и не позволяет замаскировать бизнес-приоритет под техническое одобрение QA.
Главный компромисс состоит в выборе чувствительности политики. Слишком жёсткие правила могут замедлить безопасные исправления и создать стимул обходить процесс, а слишком мягкие превратят error budget в информационный отчёт без влияния на решения. Поэтому пороги и исключения нужно периодически пересматривать по данным об инцидентах, изменениях и фактическом пользовательском ущербе.
У сервиса оплаты SLO успешных операций установлен на уровне 99,9% за месяц. После неудачного релиза бюджет ошибок почти исчерпан, а команда хочет выпустить новую функцию, которая меняет расчёт скидок.
Рассматривались три варианта. Первый — выпустить изменение полностью: это сохраняет план бизнеса, но добавляет риск к уже нестабильному сервису. Второй — полностью заморозить все изменения: это снижает операционный риск, но задерживает исправления и не различает опасные функции от безопасных. Третий — сначала исправить причину деградации, затем провести ограниченный выпуск новой функции с усиленными проверками и автоматическим откатом.
Выбран третий вариант. Изменение прошло на небольшой доле трафика, для него установили отдельные показатели ошибок, а обычные функциональные релизы временно приостановили. Это сохранило возможность безопасного исправления и не позволило использовать исчерпанный бюджет как основание для бесконтрольной поставки.
1. Вопрос: Должен ли исчерпанный error budget блокировать аварийное исправление?
Нет, не обязательно. Цель бюджета — управлять совокупным риском, а аварийное исправление может уменьшать вероятность дальнейших нарушений SLO. Для него всё равно нужны минимальные проверки, ограниченный выпуск, наблюдение за результатом и явно зафиксированное обоснование исключения.
2. Вопрос: Что делать, если SLO формально не нарушен, но бюджет быстро расходуется?
Ориентироваться на скорость расходования бюджета и прогноз до конца окна. Если текущая тенденция приведёт к превышению допустимого ущерба, уже сейчас следует усилить контроль изменений, исследовать источник деградации и пересмотреть план релизов. Ожидание фактического нарушения SLO сделает управление реактивным.
3. Вопрос: Можно ли использовать один общий error budget для всех функций сервиса?
Можно, но это снижает точность решений. Общий бюджет удобен для простой политики, однако критичный платёжный сценарий может требовать отдельного SLO, поскольку его отказ существенно опаснее сбоя второстепенной функции. Разделение оправдано, если источники данных надёжны, границы ответственности понятны, а дополнительные бюджеты не создают противоречивых правил.