告警哲学 · 少即是多

大多数人以为告警系统的失败是“漏报”。错了。真正的失败是“太吵，以至于没人看”——而这必然导致漏报。

这是一条可预测的死亡螺旋：

注意这个循环的残酷之处：事故复盘的结论往往是“我们应该加个告警”——于是回到第一步，螺旋加速。

打破它的唯一方法是反过来：删告警。

别把“值班的人不看告警”归咎于态度。这是人的注意力机制决定的：

• 如果一条告警 90% 的时候是误报，人必然会开始忽略它 —— 这不是懒，是理性的适应：99 次狼来了之后，不去看是期望收益更高的选择。
• 一旦形成“先忽略再说”的习惯，它会泛化到所有告警 —— 包括那 10% 真的。这是最可怕的部分：一条吵的告警会污染整个告警系统的可信度。
• 半夜被叫醒的代价是复利的 —— 睡眠被打断的人，第二天的判断力显著下降。一次无谓的 page，损害的不只是那一晚。

所以“多一条告警不会有坏处”这个直觉是彻底错的：每条噪音告警都在消耗整个系统的信噪比，而信噪比是公共资源——它被消耗掉之后，所有告警都失效了。

推论：一条误报率高的告警，比没有告警更糟。 因为没有告警时你知道自己是瞎的，会去想别的办法；有个吵的告警时，你以为自己有覆盖，实际上没有。

在加任何一条 page 级告警前，逐条过这个筛子（第 3 章提过，这里给完整版）：

□ 1. 用户在受影响吗?
     └─ 不是 → 不该 page(放看板/ticket)

□ 2. 需要人立刻介入吗?
     └─ 系统能自愈(重试/failover/扩容) → 不该 page

□ 3. 有 runbook 吗?
     └─ 没有 → 你只是把一个人叫醒,然后让他从零开始猜

□ 4. 我凌晨 3 点会为它起床吗?
     └─ 不会 → 它凭什么是 page?

□ 5. 它误报的概率有多大?
     └─ 高 → 先去修阈值(用[燃烧率](/manual/observability/slo-burn-rate)),别急着上线

□ 6. 它和已有的告警重复吗?
     └─ 重复 → 删掉一个(通常该留症状那条)

第 3 条（“有 runbook 吗”）最常被跳过，但它极其重要。 一条没有 runbook 的 page 意味着：被叫醒的人（可能不是写这条告警的人、可能对这个服务不熟）要在凌晨、脑子不清醒、有时间压力的情况下，从零开始理解发生了什么。

runbook 不需要很长，但必须回答三件事：

1. 这条告警是什么意思（用人话，不是重复表达式）。
2. 最可能的原因是什么（按概率排序）。
3. 第一步该做什么（哪怕是“看这个面板”）。

定期（比如每月）跑这几个查询——它们会告诉你哪些告警该删：

# ① 最吵的告警 Top 10(过去 30 天 firing 的时长)
topk(10,
  sum by (alertname) (count_over_time(ALERTS{alertstate="firing"}[30d]))
)

# ② 从没响过的告警(死规则)—— 需要和规则列表比对
# 先看哪些响过:
count by (alertname) (count_over_time(ALERTS[90d]))
# 规则里有、但这里没有的 → 90 天没响过 → 它真的有用吗?

# ③ 响得太频繁(震荡)的告警
topk(10,
  sum by (alertname) (
    changes(ALERTS_FOR_STATE[7d])     # 状态变化次数
  )
)

# ④ pending 但从没 firing 的(说明 for 太长,或者阈值在边界抖动)
count by (alertname) (ALERTS{alertstate="pending"})

每个查询对应一个该采取的行动：

“90 天没响过的告警”这条特别值得警惕： 你无法区分“系统健康”和“这条规则根本不工作”。没被验证过能触发的告警，等于不存在——第 9 部分会讲怎么测试告警规则。

一个让人不舒服、但真实的结论：大多数团队该做的第一件事，是删掉一半的告警。

为什么这提升而非降低可靠性？

• 信噪比是公共资源 —— 删掉噪音，剩下的告警才会被认真对待。10 条每条都可信的告警，远胜于 100 条没人看的。
• 被删掉的大多是“原因”类告警 —— 它们本来就该在看板上而不是电话里。删掉它们，不会失去任何信息——那些指标还在，你排障时照样能看。
• 少数几条 SLO 告警覆盖面更广 —— 一条基于燃烧率的告警，覆盖了所有你没想到的故障模式；而 50 条基于原因的告警，只覆盖了你想到的那 50 种。

一个可执行的做法：

① 列出所有 page 级告警
② 每条问:"过去 6 个月,它响的时候有几次真的需要人立刻做事?"
   └─ 0 次 → 立刻降级成 ticket 或删掉
   └─ 少数几次 → 降级
③ 剩下的,用第 4 章的筛子再过一遍
④ 用[燃烧率告警](/manual/observability/slo-burn-rate)补上覆盖

理想状态：一个服务的 page 级告警应该是个位数——基本就是几条 SLO 燃烧率告警 + 服务完全不可达 + 少数几个“一次就致命”的条件（证书过期、数据损坏）。如果你有 50 条 page 级告警，几乎可以肯定其中 40 条不该是 page。