Команда хочет обнаруживать быстрый срыв SLO, не дожидаясь исчерпания бюджета ошибок. Какой принцип алертинга для этого применяют?
Для этого используют алертинг по скорости сжигания бюджета ошибок (error budget burn rate). Он сравнивает текущую долю ошибок с допустимой долей по SLO и позволяет подать сигнал, когда бюджет расходуется слишком быстро, задолго до его полного исчерпания.
Одного алерта на полное исчерпание бюджета недостаточно: он сообщает о нарушении политики уже постфактум. Поэтому в SRE-подходах стали контролировать не только остаток бюджета, но и скорость его расходования.
Такой подход связывает оперативные сигналы с долгосрочной целью надёжности. Команда может реагировать на опасный кратковременный инцидент, не превращая каждый небольшой всплеск ошибок в срочную аварию.
Допустим, SLO доступности на 30 дней составляет 99,9%. Это означает, что допустимая доля неуспешных запросов равна 0,1%, то есть примерно 43,2 минуты недоступности за 30 дней при расчёте по времени.
Если система начнёт расходовать весь месячный бюджет за несколько часов, проверка только факта полного исчерпания бюджета сработает слишком поздно. За это время продолжится выпуск изменений или рост нагрузки, а команда потеряет возможность своевременно остановить ухудшение.
Burn rate рассчитывают как отношение фактической доли ошибок к допустимой доле ошибок. При burn rate 1 бюджет расходуется примерно с плановой скоростью; при burn rate 10 весь бюджет будет израсходован примерно за одну десятую расчётного окна.
Для окна SLO в 30 дней burn rate 20 означает потенциальное исчерпание бюджета примерно за 1,5 дня, если текущая скорость сохранится. Поэтому алерт можно связать не с нулевым остатком бюджета, а с превышением заданного burn rate.
На практике часто используют два временных окна: короткое и длинное. Короткое окно быстро обнаруживает резкий инцидент, а длинное подтверждает, что проблема не является единичным кратковременным всплеском. Условие срабатывания на обоих окнах снижает шум, но пороги требуют настройки под критичность сервиса и стоимость реакции.
Важно отличать burn rate от абсолютного числа ошибок. Одна и та же скорость ошибок может быть приемлемой для одного SLO и критичной для другого. Кроме того, расчёт должен использовать ту же сущность, что и SLO: например, долю неуспешных запросов, а не произвольную метрику загрузки CPU.
Компромисс состоит в выборе чувствительности. Слишком низкий порог создаёт ложные тревоги и приводит к усталости от алертов, слишком высокий — обнаруживает проблему поздно. Поэтому обычно разделяют срочные сигналы для быстрого расходования бюджета и менее срочные уведомления для устойчивого, но медленного ухудшения.
У API с SLO 99,9% после выпуска новой версии доля ошибок выросла до 2%. Команда рассмотрела три варианта: ждать полного исчерпания месячного бюджета, алертить на любую ошибку или использовать burn rate по короткому и длинному окнам.
Первый вариант слишком поздний, поскольку бюджет сгорает ещё до сигнала. Второй создаёт шум: отдельные ошибки не означают существенный риск для SLO. Третий вариант позволяет подать срочный сигнал при устойчивом резком росте ошибок и не реагировать на единичный кратковременный всплеск.
Команда выбрала двухоконный алерт по burn rate и отдельно связала его с автоматической остановкой дальнейшего развёртывания. Это решение защищает бюджет ошибок, не превращая каждую малую флуктуацию в инцидент; конкретные пороги при этом проверяются на исторических данных сервиса.
Вопрос: Почему алерт по burn rate может сработать, даже если бюджет ошибок ещё почти не израсходован?
Ответ: Burn rate оценивает скорость расходования, а не только накопленный расход. При резком росте ошибок небольшой уже потраченный бюджет может соответствовать очень высокой текущей скорости, поэтому система предупреждает о будущем исчерпании заранее.
Вопрос: Что произойдёт, если рассчитывать burn rate по слишком короткому окну?
Ответ: Алерт станет чувствительным к случайным выбросам и малому числу запросов. Например, несколько ошибок в период низкого трафика могут дать большую долю ошибок, хотя реальный ущерб для SLO несущественен. Поэтому короткое окно обычно дополняют длинным или минимальным условием по объёму наблюдений.
Вопрос: Почему одинаковый порог burn rate не подходит всем сервисам?
Ответ: Сервисы различаются критичностью, объёмом трафика, стоимостью простоя и допустимым временем реакции. Для критичного API нужен более ранний сигнал и, возможно, автоматическая остановка изменений; для внутреннего сервиса допустима менее чувствительная политика. Порог также зависит от длины SLO-окна и выбранного компромисса между скоростью обнаружения и количеством ложных тревог.