Коротко. Бюджет ошибок — это допустимый объём ненадёжности, который остаётся после SLO. Если цель 99,9%, то 0,1% времени сервис может быть недоступен — это и есть бюджет. Считается как (1 − SLO) × период. Бюджет превращает «надёжность» из спора в число: пока он не исчерпан, команда катит новые фичи; как только закончился — замораживает релизы и чинит надёжность.
Зачем нужен бюджет ошибок
Без бюджета ошибок две команды вечно спорят: разработка хочет быстрее выпускать фичи, эксплуатация хочет стабильности. Бюджет даёт общий язык — число, с которым обе стороны согласны заранее.
Стопроцентная надёжность — это не цель, а ловушка: она стоит бесконечно дорого и тормозит развитие. Бюджет ошибок честно говорит, сколько сбоев можно себе позволить.
Формула расчёта
Базовая формула выводится прямо из SLO:
Бюджет ошибок (%) = 100% − SLO
Бюджет ошибок (время) = (1 − SLO) × длина периода
Пример: SLO = 99,9%, период = 30 дней
30 дней = 43 200 минут
Бюджет = (1 − 0,999) × 43200 = 0,001 × 43200 = 43,2 минуты
Это значит: за месяц допустимо до 43,2 минуты простоя.
Сколько бюджета даёт каждый SLO
| SLO | Бюджет в месяц | Бюджет в неделю |
|---|---|---|
| 99% | ~7 ч 18 мин | ~1 ч 41 мин |
| 99,9% | ~43,2 мин | ~10,1 мин |
| 99,95% | ~21,9 мин | ~5,0 мин |
| 99,99% | ~4,4 мин | ~1,0 мин |
Расход бюджета по запросам
Бюджет можно считать не только по времени, но и по запросам — это точнее для API документацию:
Всего запросов за месяц = 10 000 000
SLO = 99,9% успешных
Допустимо ошибок = (1 − 0,999) × 10 000 000 = 10 000 ошибок
Если за две недели уже 7 000 ошибок:
осталось 10 000 − 7 000 = 3 000 ошибок на остаток месяца
Скорость расхода высокая — пора тормозить рискованные релизы.
Политика бюджета ошибок
Цифра без правил бесполезна. Заранее договоритесь о действиях:
- Бюджет не исчерпан — катите фичи в обычном темпе.
- Бюджет на исходе (< 25%) — усиливаете тесты, замедляете рискованные изменения.
- Бюджет исчерпан — заморозка фич, только исправления надёжности до восстановления.
- Постоянный перерасход — пересмотр SLO или серьёзные вложения в инфраструктуру.
Скорость сжигания (burn rate)
Burn rate показывает, во сколько раз быстрее нормы расходуется бюджет. Если за час сожжён бюджет, рассчитанный на сутки — burn rate = 24, и это повод для немедленного алерта. Настроить такие алерты помогает грамотная политика оповещений.
Как enterno.io помогает следить за бюджетом
enterno.io как внешний мониторинг сайтов фиксирует каждый эпизод недоступности и копит историю простоев. На платных планах проверки идут каждую минуту или раз в 30 секунд, что точнее отражает реальный расход бюджета, чем редкие пятиминутные пробы. Алерты в Telegram, Slack, email, webhook, PagerDuty и Jira предупредят, когда инцидент начинает «съедать» бюджет.
Историю инцидентов и доступность удобно показывать на статус-странице, а сами мониторы дают данные для расчёта. Для дежурных задач пригодится heartbeat-мониторинг.
Частые вопросы
Чем бюджет ошибок отличается от SLO?
SLO — это цель доступности, а бюджет ошибок — её зеркальное отражение: ровно та доля ненадёжности, которую SLO разрешает. Они всегда в сумме дают 100%.
Что делать, если бюджет исчерпан в середине месяца?
Согласно политике — заморозить новые фичи и направить силы на надёжность. Бюджет восстанавливается со следующего расчётного периода.
Можно ли «накапливать» неизрасходованный бюджет?
Обычно нет: бюджет привязан к окну (например, скользящие 30 дней) и обнуляется с каждым новым окном. Это держит фокус на свежей надёжности.
Как часто считать бюджет?
Непрерывно по скользящему окну. Многие команды смотрят расход ежедневно, а burn-rate алерты — в реальном времени.
Начните измерять расход бюджета. Поднимите мониторы на enterno.io/monitors и собирайте историю простоев для точного error budget.