Cum alegi praguri de alertare pentru a evita oboseala de alerte și fals pozitivele?

Question

Accepted Answer

Regula de bază: **alertează pe simptome, nu pe cauze**, și **solicită intervenție doar pentru ceea ce este acționabil și urgent**. O alertă zgomotoasă care se declanșează în fiecare noapte este ignorată sau dezactivată — deci riscul real nu este o alertă lipsă, ci un inginer on-call desensibilizat care doarme peste cea adevărată.

## Simptome peste cauze

Alerteaza pe **SLO-uri cu impact asupra utilizatorilor** (rata de erori, latență, disponibilitate), nu pe cauze interne precum "CPU > 80%". CPU ridicat poate fi inofensiv; ceea ce contează este dacă utilizatorii sunt afectați.

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

## Alerte cu rată de consum multi-fereastră

Un prag static unic este fie prea sensibil, fie prea lent. În schimb, alertează pe viteza cu care consumi **bugetul de erori**, folosind două ferestre temporale, astfel încât o consum rapid declanșează intervenție imediat și o consum lent declanșează intervenție doar dacă se menține.

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

Ferestra scurtă previne alertarea pentru o problemă care s-a rezolvat deja; ferestra lungă previne alertarea pentru o scurtă anormalitate.

## Intervenție vs ticket vs tablă de bord

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

Dacă o alertă nu este acționabilă, nu ar trebui să declanșeze intervenție — transformo într-un ticket sau un panou pe tablă de bord. Apoi **ajustează în timp**: analizează fiecare intervenție și șterge pe cele pentru care nimeni nu a luat măsuri.

## De ce contează

Oboseala de alerte este un risc de fiabilitate, nu doar o inconveniență: oamenii filtrează mental canalele zgomotoase, deci cu cât mai mulți fals pozitivi trimiți, cu atât mai probabil este ca o pană adevărată să fie ratată. Alertarea pe simptome cu ferestre de rată de consum și rezervarea intervenției pentru urgența acționabilă menține fiecare intervenție semnificativă — ceea ce menține inginerul on-call reactiv.