Что такое burn rate alerts и почему их рекомендует Google SRE

Классический мониторинг часто строится вокруг простых правил: CPU выше 90%, память заканчивается, сервис недоступен несколько минут — отправить уведомление.

Однако такие алерты не всегда помогают понять главное: насколько быстро сервис движется к нарушению своих целей качества.

Например, если у сервиса есть SLO доступности 99,9%, то допустимый простой составляет примерно 43 минуты в месяц. Но сам факт появления ошибок ещё не говорит, насколько серьёзна ситуация. Ошибки могут исчезнуть через минуту, а могут привести к полному исчерпанию допустимого запаса уже через несколько часов.

Для решения этой задачи в практике Google SRE появился подход burn rate alerts — оповещения на основе скорости расходования error budget.

Что такое burn rate

Burn rate — это скорость, с которой сервис расходует свой запас допустимых ошибок.

Чтобы понять этот показатель, сначала нужно разобраться с понятием error budget.

Если SLO сервиса составляет 99,9% доступности, это означает, что допустимый уровень ошибок равен:

100% - 99,9% = 0,1%

Эти 0,1% и являются запасом ошибок.

Например:

• SLO: 99,9% успешных запросов;
• error budget: 0,1%;
• за месяц допускается примерно 43 минуты недоступности.

Если сервис расходует этот запас равномерно, проблем нет. Но если ошибки начинают происходить значительно чаще, команда должна получить сигнал.

Именно это показывает burn rate.

Например:

• burn rate = 1 — запас ошибок расходуется с нормальной скоростью;
• burn rate = 10 — запас будет исчерпан в десять раз быстрее;
• burn rate = 100 — весь месячный error budget закончится примерно за семь часов.

Чем выше burn rate, тем быстрее сервис приближается к нарушению SLO.

Почему обычные алерты не всегда работают

Представим сервис с SLO 99,9%.

Можно настроить простой алерт:

HTTP 500 > 5% в течение 5 минут

Но у такого подхода есть проблемы.

Если ошибок стало 5% на несколько секунд, это может быть незначительным всплеском.

Если ошибок всего 1%, но они продолжаются несколько часов, это уже серьёзная проблема — сервис постепенно расходует весь доступный запас качества.

Обычный алерт смотрит на текущее состояние:

«Есть ли сейчас много ошибок?»

Burn rate alert отвечает на другой вопрос:

«С какой скоростью мы приближаемся к нарушению SLO?»

Это гораздо ближе к реальному влиянию на пользователей.

Как работают burn rate alerts

Вместо фиксированного порога ошибок используется отношение текущего уровня ошибок к допустимому уровню из SLO.

Упрощённо:

Burn Rate = текущая скорость ошибок / допустимая скорость ошибок

Например:

SLO:

99,9% успешных запросов

Допустимый уровень ошибок:

0,1%

Если за короткий период количество ошибок составляет:

1%

то сервис расходует error budget:

1% / 0,1% = 10

То есть burn rate равен 10.

Это означает, что текущая скорость ошибок в десять раз выше допустимой.

Почему Google SRE рекомендует несколько временных окон

Один из важных принципов Google SRE — не использовать только одно окно мониторинга.

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

Например, можно использовать два уровня:

Быстрый алерт

Проверяет небольшой промежуток времени.

Например:

burn rate > 14 за последние 5 минут

Такой сигнал говорит о серьёзном инциденте, который может быстро уничтожить error budget.

Медленный алерт

Проверяет более длинный период.

Например:

burn rate > 2 за последние 6 часов

Он показывает постепенное ухудшение качества сервиса.

Комбинация этих подходов позволяет реагировать как на крупные аварии, так и на медленные деградации.

Пример использования burn rate

Допустим, у API есть следующие требования:

SLO: 99,95% успешных запросов

Error budget:

0,05%

За последние 30 минут количество ошибок выросло до:

0,5%

Расчёт:

0,5 / 0,05 = 10

Получается burn rate 10.

Это означает, что при сохранении текущей ситуации месячный запас ошибок будет израсходован примерно в десять раз быстрее нормы.

Команда получает сигнал не потому, что сервер упал, а потому что сервис начал слишком быстро терять качество.

Преимущества burn rate alerts

Использование burn rate позволяет:

• связывать алерты с бизнес-целями;
• уменьшать количество бесполезных уведомлений;
• быстрее находить проблемы, влияющие на пользователей;
• понимать критичность инцидента;
• принимать решения на основе SLO, а не случайных технических метрик.

Например, высокая загрузка CPU сама по себе не всегда является проблемой. Если пользователи получают быстрые ответы, вмешательство может быть не нужно.

Но даже небольшое увеличение количества ошибок API может быть критичным, если оно быстро расходует error budget.

Типичные ошибки при использовании burn rate

Одна из распространённых ошибок — применять burn rate без правильно выбранного SLO.

Если цель качества выбрана неправильно, то и алерты будут бесполезными.

Например, слишком строгий SLO создаст постоянный поток предупреждений, а слишком мягкий позволит замечать проблемы слишком поздно.

Также не стоит использовать burn rate как замену всем остальным метрикам.

Он хорошо отвечает на вопрос:

«Насколько быстро мы приближаемся к нарушению обязательств качества?»

Но не отвечает:

«Почему сервис работает плохо?»

Для поиска причины всё ещё нужны обычные технические метрики: логи, трассировки, показатели инфраструктуры и состояние компонентов системы.

Итоги

Burn rate alerts — это способ строить мониторинг вокруг пользовательского качества, а не отдельных технических показателей.

Вместо того чтобы реагировать на случайные скачки ошибок, команда отслеживает скорость расходования error budget и понимает, насколько быстро сервис движется к нарушению SLO.

Именно поэтому Google SRE рекомендует использовать burn rate alerts как основу для алертинга в системах с определёнными целями доступности.

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