Multi-window multi-burn-rate-алертинг: почему AND лучше OR

On-call-команда использует один алерт: «фаер если error rate за последний час выше 1.44%.» Пейджер срабатывает в 2 ночи. Инженер логинится. Проблема ушла сама 55 минут назад — но часовое окно всё ещё содержит плохие данные. Инженер не спит зря.

Почему наивные SLO-алерты ломаются двумя способами

SRE Workbook классифицирует шесть подходов к SLO-алертингу. Пять ломаются предсказуемо.

Approach 1 (сырой error rate > SLO-порог): срабатывает сотни раз в день на мелких всплесках. Один плохой батч запросов — пейдж; команды учатся игнорировать пейджер — классическая спираль alert fatigue.

Approach 5 (одно-оконный burn-rate-порог, например 14.4x за 1ч): лучше — ловит реальные outage’и — но сброс медленный. После устранения инцидента часовое окно ещё час содержит 55 минут плохих данных. Инженеры не могут понять, помог ли их фикс.

Approach 6 (MWMBR) — единственный, балансирующий задержку детекции, устойчивость к шуму и задержку восстановления. Production-default в Google, Datadog, Grafana, Splunk, Honeycomb, Sloth, Pyrra.

Двухоконный трюк

Ключевая идея: комбинировать длинное окно (устойчивость к шуму) AND короткое окно (разрешение восстановления):

• Длинное окно (например 1ч): подтверждает, что горение устойчивое, а не транзиентный спайк
• Короткое окно (например 5м): подтверждает, что горение всё ещё происходит прямо сейчас

Логика AND:

• Только длинное окно высокое: инцидент, вероятно, завершился; короткое очистилось
• Только короткое окно высокое: короткий спайк, ещё не накопившийся в устойчивое горение
• Оба высокие: реальный outage, и серьёзный, и живой — пейджить

Когда инцидент устраняется, короткое окно очищается в течение 5 минут. Алерт гаснет в течение 5 минут, а не 55. Задержка детекции и время сброса оба ограничены.

Каноническая MWMBR-конфигурация (99.9% SLO)

Реализация на Prometheus

# Recording rule: fast-request ratio за 1ч
record: job:slo_latency_fast:ratio_rate1h
expr: |
  sum(rate(http_request_duration_seconds_bucket{le="0.2"}[1h]))
  /
  sum(rate(http_request_duration_seconds_count[1h]))

# Page-алерт: 1ч И 5м оба выше 14.4x burn
alert: SLOLatencyBurnFast
expr: |
  (
    (1 - job:slo_latency_fast:ratio_rate1h) > (14.4 * 0.001)
    and
    (1 - job:slo_latency_fast:ratio_rate5m) > (14.4 * 0.001)
  )
labels:
  severity: page
annotations:
  summary: "Latency SLO горит с >14.4x за 1ч И 5м"

14.4 * 0.001 — это burn_rate × (1 − SLO) = 14.4 × 0.001 = 0.0144 — порог error rate, соответствующий 14.4x burn на 99.9% SLO.