Короткий ответ
Error budget = (1 − SLO) за выбранный период; например, при SLO 99.9% за 30 дней допустимая "неудача" — 0.1% запросов, что при 10 млн запросов в месяц даёт budget 10 000 неуспешных запросов; при истощении budget команда обычно замораживает рискованные релизы и фокусируется на надёжности до восстановления запаса.
Как это работает подробнее
error budget переводит абстрактный процент SLO в конкретное, понятное число "допустимых неудач" за период, что упрощает принятие решений — вместо вопроса "это нормально?" команда смотрит "сколько budget осталось и с какой скоростью он тратится". Скорость расхода (burn rate) показывает, истощится ли budget раньше конца периода при текущем темпе деградации.
Пример кода
example.txt
SLO: 99.9% успешных запросов за 30 дней
Общий трафик за месяц: 10 000 000 запросов
Error budget: 0.1% × 10 000 000 = 10 000 неуспешных запросов допустимо
Текущее состояние на 10-й день месяца: уже произошло 7 000 ошибок
Вывод: budget почти истощён на треть месяца -> нужно замедлить релизы и разобраться в причинеЧто использовать на практике
- Практика. при истощении budget команды обычно применяют заранее согласованную политику (error budget policy): временный мораторий на non-critical релизы, приоритизация technical debt и надёжности над новыми фичами, обязательный post-mortem для крупных инцидентов, которые съели budget. Важно, что это политика, согласованная заранее между инженерной командой и продуктом/бизнесом, а не одностороннее решение SRE.
- Практика. Если burn rate продолжится на том же уровне, budget истощится примерно к 15-му дню месяца — это явный триггер для активации политики error budget согласно заранее принятым правилам, а не ожидания конца месяца.
Подводные камни
- Частые ошибки. считать error budget только в процентах без перевода в абсолютные понятные числа, из-за чего команда не чувствует реальный масштаб допустимого риска; не иметь заранее согласованной политики действий при истощении budget, из-за чего решение принимается ситуативно и вызывает конфликт с продуктовыми планами; игнорировать burn rate и реагировать только по факту полного истощения budget в конце периода, когда реагировать уже поздно.