Бюджеты ошибок

Что такое бюджет ошибок

Error budget — допустимое отклонение от SLO за то же окно оценки. Он превращает требование надёжности в конкретный ресурс: пока бюджет не исчерпан, команда может выпускать изменения; при слишком быстром расходе приоритет смещается к стабильности.

Бюджет ошибок = 100% − SLO

Для SLO 99,9% бюджет составляет 0,1%. Если сервис получил 1 000 000 учитываемых запросов за четыре недели, допускается не более 1 000 неуспешных запросов при request-based SLI.

Во временной модели при SLO 99,9% за 30 дней бюджет — 43,2 минуты недоступности. Модели нельзя смешивать: долю ошибок запросов нельзя напрямую переводить в минуты простоя.

Расход и скорость расхода

Расход бюджета показывает, какая доля допустимого отклонения уже использована:

Расход, % = фактические ошибки / допустимые ошибки × 100%

При бюджете 1 000 ошибок фактические 250 ошибок означают расход 25%.

Burn rate показывает, насколько быстро бюджет расходуется относительно равномерного темпа:

• 1 — темп соответствует полному расходу к концу окна;
• больше 1 — SLO будет нарушен при сохранении темпа;
• 0 — ошибок в выбранном интервале нет.

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

Политика использования

Бюджет полезен только при заранее согласованных действиях. Пример упрощённой политики:

Состояние	Решение
SLO выполняется, расход умеренный	Обычный процесс релизов
Бюджет быстро расходуется	Расследование, дополнительная проверка изменений, приоритет работам над устойчивостью
Бюджет за окно исчерпан	Приостановка необязательных изменений до восстановления SLO
Критическая уязвимость или восстановление	Исключение из ограничений на релизы

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

Внедрение за пять шагов

1. Зафиксировать SLI, SLO, окно и источник данных.
2. Настроить расчёт фактического и допустимого числа ошибок в одной модели.
3. Показать текущий остаток и burn rate на дашборде.
4. Согласовать владельца решений и действия для каждого состояния.
5. Связать крупный расход с postmortem и конкретными follow-up.

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

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

• Расчёт SLO за месяц, а бюджета — за несопоставимый период.
• Смешение request-based и time-based моделей.
• Автоматическая остановка всех релизов без владельца и исключений.
• Игнорирование пропавших данных и неправильно классифицированных ошибок.
• Бюджет на графике без изменения реальных приоритетов.

Связанные инструменты

• Prometheus — recording rules и оповещения по скорости расхода.
• Grafana — панели SLO, остатка и burn rate.
• Better Stack — связь целей, телеметрии и инцидентов.

Связанные материалы

• SLI, SLO и SLA — исходная цель для расчёта.
• Alerting — оповещения по burn rate.
• CI/CD — выпуск и приостановка изменений.
• Метрики DevOps и инфраструктуры — пример расчёта расхода бюджета.

Материалы и источники

• Google SRE Workbook: Error Budget Policy — пример политики, расчёт и действия при нарушении SLO.
• Google SRE: Embracing Risk — бюджет как баланс надёжности и скорости изменений.
• Google SRE Workbook: Alerting on SLOs — скорость расхода и окна оповещения.