Hur väljer du alertgränser för att undvika alert fatigue och falsklarm?

Question

Accepted Answer

Grundregeln: **alertera på symptom, inte orsaker**, och **sida endast för det som är åtgärdbart och brådskande**. Ett högljudt alarm som utlöses varje natt blir nedtonat eller ignorerat — så den riktiga risken är inte ett missat alarm, det är en avkänslig on-call som sover genom det verkliga.

## Symptom före orsaker

Aletera på **användarcentrerade SLO:er** (felfrekvens, latens, tillgänglighet), inte på interna orsaker som "CPU > 80%". Högt CPU kan vara ofarligt; det som spelar roll är om användarna påverkas.

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

## Flerfönster burn-rate-varningar

En enda statisk gräns är antingen för känslig eller för långsam. Istället, alertera på hur snabbt du bränner **felbudgeten**, med två fönster så att en snabb bränning sida omedelbar och en långsam bränning sida endast om hållbar.

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

Det korta fönstret förhindrar sidning för ett problem som redan löst sig själv; det långa fönstret förhindrar sidning på en kort puff.

## Sida vs biljett vs instrumentpanel

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

Om en varning inte är åtgärdbar, bör den inte sida — gör den till en biljett eller en instrumentpanelskarta istället. Sedan **finjustera över tid**: granska varje sida, radera de som ingen agerade på.

## Varför det är viktigt

Alert fatigue är en tillförlitlighetsrisk, inte bara en irritation: människor filtrerar mentalt bort bullriga kanaler, så ju fler falsklarm du skickar, desto större sannolikhet är det att ett verkligt avbrott missas. Att alertera på symptom med burn-rate-fönster, och reservera sidan för åtgärdbar brådskande, håller varje sida meningsfull — vilket är det som håller on-call responsiv.