您如何选择告警阈值以避免告警疲劳和假正例？

Question

IT Interview Practice · 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 }
```

短窗口防止对已自行解决的问题进行分页；长窗口防止对短暂波动进行分页。

## 分页对比工单对比仪表板

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

如果告警不可操作，就不应该分页 — 将其转换为工单或仪表板面板。然后**随时间调整**：检查每个分页，删除那些没有人采取行动的分页。

## 为什么这很重要

告警疲劳是一个可靠性风险，而不仅仅是一个烦恼：人类会在心理上过滤嘈杂的通道，因此您发送的假正例越多，真正的中断被错过的可能性就越大。对症状进行告警，使用燃尽率窗口，并为可操作的紧迫情况保留分页，可以保持每个分页都有意义 — 这就是保持值班人员响应的原因。

症状而非原因

多窗口燃尽率告警

分页对比工单对比仪表板

为什么这很重要

相关问题