Статьи

Бюджеты ошибок и алерты по burn rate: будить по правильным причинам

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

Примеры обобщённые и иллюстративные. Они не взяты из среды какого-либо клиента: подстройте пороги и параметры под свою систему.

Начните с того, что видят пользователи

Большинство шумных алертов возникает из-за оповещений о причинах — CPU, память, перезапущенный под, — а не о том, что чувствуют пользователи. Индикатор уровня сервиса (SLI) измеряет это напрямую: долю корректных запросов, которые были успешными. Успешный может означать ответ без серверной ошибки, ответ быстрее порога или и то и другое.

Цель уровня сервиса (SLO) задаёт целевое значение этой доли за окно — например, 99,9 % успешных запросов за 30 дней. Разница до 100 % — это бюджет ошибок: здесь 0,1 % запросов, или около 43 минут полной недоступности за месяц.

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

Алерт вида «доля ошибок выше 1 % в течение 5 минут» одновременно слишком чувствителен и слишком медлителен. Он будит из-за короткого всплеска, съевшего крошечную часть бюджета, и никогда не срабатывает на 0,5 % ошибок, которые тихо сжигают весь бюджет за неделю.

Это решает burn rate. Это скорость расходования бюджета относительно SLO: burn rate 1 расходует ровно весь бюджет за окно; burn rate 14,4 расходует 30-дневный бюджет чуть более чем за двое суток.

Алерты с несколькими окнами и порогами burn rate

Подход из SRE Workbook Google сочетает каждый порог burn rate с длинным окном, которое доказывает значимость проблемы, и коротким окном, которое доказывает, что она всё ещё происходит. Для SLO 99,9 % за 30 дней типичная отправная точка такая:

Будить: burn rate выше 14,4 за 1 час и за 5 минут — 2 % бюджета израсходовано за час.
Будить: burn rate выше 6 за 6 часов и за 30 минут — израсходовано 5 % бюджета.
Тикет: burn rate выше 1 за 3 дня и за 6 часов — израсходовано 10 % бюджета.

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

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

Детали, от которых зависит результат

Recording rules: заранее вычисляйте долю ошибок для каждого окна, чтобы выражения алертов оставались дешёвыми и читаемыми.
Малый трафик: при нескольких запросах в минуту один сбой — это большая доля. Требуйте минимального числа запросов или измеряйте синтетическими проверками.
SLO по задержке: считайте плохими событиями запросы медленнее порога, используя корзины гистограммы, в которые входит значение порога.
Исключения: заранее решите, учитываются ли клиентские ошибки и health checks, и запишите это рядом с SLO.

Зачем нужен бюджет

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