Jak wybrać progi alertów, aby uniknąć alert fatigue i fałszywych alarmów?

Question

IT Interview Practice · Accepted Answer

Podstawowa zasada: **alertuj na symptomy, nie na przyczyny** i **powiadamiaj tylko o tym, co można naprawić i jest pilne**. Hałaśliwy alert, który co nocy się uruchamia, zostanie wyciszony lub zignorowany — więc rzeczywiste ryzyko to nie brakujący alert, ale znudzony on-call, który przespał prawdziwy alarm.

## Symptomy zamiast przyczyn

Aletuj na **SLO zwrócone do użytkownika** (współczynnik błędów, opóźnienie, dostępność), nie na przyczyny wewnętrzne takie jak "CPU > 80%". Wysoka CPU może być nieszkodliwa; ważne jest, czy użytkownicy są dotknięci.

```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
```

## Alerty burn-rate z wieloma oknami czasowymi

Single threshold jest albo zbyt wrażliwy, albo zbyt wolny. Zamiast tego alertuj na to, jak szybko spalasz **error budget**, używając dwóch okien czasowych, aby szybki burn powiadomił natychmiast, a powolny burn powiadomił tylko jeśli się utrzyma.

```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 }
```

Krótkie okno zapobiega powiadomieniu o problemie, który już się rozwiązał; długie okno zapobiega powiadomieniu z powodu krótkotrwałego impulsu.

## Powiadomienie vs zgłoszenie vs dashboard

```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)
```

Jeśli alert nie jest działalny, nie powinien powiadamiać — zamień go na zgłoszenie lub panel dashboard. Następnie **dostrajaj w czasie**: przejrzyj każde powiadomienie, usuń te, na które nikt nie reagował.

## Dlaczego to ważne

Alert fatigue jest ryzykiem dla niezawodności, nie tylko uciążliwością: ludzie mentalnie filtrują hałaśliwe kanały, więc im więcej fałszywych alarmów wyślesz, tym większe prawdopodobieństwo, że prawdziwa awaria zostanie przeoczona. Alertowanie na symptomy z burn-rate windows i zarezerwowanie powiadomienia dla działalnych pilnych spraw utrzymuje każde powiadomienie znaczące — co jest tym, co utrzymuje on-call responsywny.

Symptomy zamiast przyczyn

Alerty burn-rate z wieloma oknami czasowymi

Powiadomienie vs zgłoszenie vs dashboard

Dlaczego to ważne

Powiązane pytania