Как выбрать пороги срабатывания алертов, чтобы избежать alert fatigue и ложных срабатываний?

Question

Accepted Answer

Основное правило: **алертить на симптомы, а не на причины**, и **вызывать на дежурство только по поводу действенных и срочных проблем**. Шумный алерт, который срабатывает каждую ночь, будет отключен или проигнорирован — поэтому реальный риск не в пропущенном алерте, а в дежурном, который привык к шуму и спит через настоящий.

## Симптомы вместо причин

Алертить на **пользовательские SLO** (процент ошибок, латентность, доступность), а не на внутренние причины типа «CPU > 80%». Высокий CPU может быть безопасен; важно, влияет ли это на пользователей.

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

## Алерты на скорость расхода бюджета ошибок с несколькими временными окнами

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

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

Короткое окно предотвращает вызов по проблеме, которая уже самоустранилась; длинное окно предотвращает вызов по кратковременному всплеску.

## Дежурство vs тикет vs дашборд

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

Если алерт не требует действия, он не должен вызывать дежурного — превратите его в тикет или панель дашборда. Затем **совершенствуйте со временем**: проверяйте каждый вызов, удаляйте те, на которые никто не реагировал.

## Почему это важно

Alert fatigue — это риск для надежности, не просто раздражение: люди автоматически фильтруют шумные каналы, поэтому чем больше ложных срабатываний вы отправляете, тем выше вероятность пропустить настоящий сбой. Алертинг на симптомы с учетом скорости расхода бюджета, с резервированием дежурства только для действенных срочных ситуаций, делает каждый вызов значимым — а это то, что держит дежурного в тонусе.