Como você escolhe limites de alerta para evitar fadiga de alerta e falsos positivos?

Question

IT Interview Practice · Accepted Answer

A regra central: **alertar sobre sintomas, não causas**, e **paginar apenas sobre o que é acionável e urgente**. Um alerta ruidoso que dispara toda noite é silenciado ou ignorado — então o risco real não é um alerta faltante, é um on-call dessensibilizado que dorme durante o real.

## Sintomas sobre causas

Alerte sobre **SLOs voltados para o usuário** (taxa de erro, latência, disponibilidade), não sobre causas internas como "CPU > 80%". CPU alta pode ser inofensiva; o que importa é se os usuários são afetados.

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

## Alertas de taxa de queimação com múltiplas janelas

Um único limite estático é ou muito reativo ou muito lento. Em vez disso, alerte sobre a velocidade com que você está queimando o **orçamento de erro**, usando duas janelas para que uma queimação rápida pagine imediatamente e uma queimação lenta pagine apenas se sustentada.

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

A janela curta previne a paginação de um problema que já se resolveu sozinho; a janela longa previne a paginação em um breve aumento.

## Paginar vs ticket 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)
```

Se um alerta não é acionável, não deve paginar — transforme-o em um ticket ou painel de dashboard. Em seguida, **ajuste ao longo do tempo**: revise cada página, delete as que ninguém agiu.

## Por que isso importa

A fadiga de alerta é um risco de confiabilidade, não apenas um incômodo: humanos filtram mentalmente canais ruidosos, então quanto mais falsos positivos você envia, mais provável é que um apagão genuíno seja perdido. Alertar sobre sintomas com janelas de taxa de queimação, e reservar a página para urgência acionável, mantém cada página significativa — o que é o que mantém o on-call responsivo.

Sintomas sobre causas

Alertas de taxa de queimação com múltiplas janelas

Paginar vs ticket vs dashboard

Por que isso importa

Perguntas relacionadas