一天两千条告警，等于没有告警
告警疲劳是可观测性建设里最普遍的失败模式。这篇讲怎么系统性地降噪。
一个真实场景
我们接手过一个环境，值班群一天两千多条告警。值班同学的做法是把群设成免打扰，每天早上翻一遍。结果某次真的出了 P1 故障，告警发出后 47 分钟才有人看到。
这不是值班同学的问题。人对高频无意义信号的钝化是生理性的，指望靠责任心对抗是不现实的。必须从告警设计上解决。
一条判断标准
每条告警都要能回答：收到它以后要做什么？如果答案是「看一下」「记录一下」「暂时不用管」，那它就不该是告警，应该降级成看板指标或日报内容。
只有「需要人立刻做某个具体动作」的信号才配得上打断别人。
降噪四步
-
01
统计与归零
导出过去 30 天所有告警，按规则统计触发次数。然后逐条问：这条告警导致过任何实际动作吗？答案是「没有」的，全部关闭或降级。这一步通常能砍掉 60%-80%。
交付物：告警统计表、关闭清单
3-5 天
-
02
合并与抑制
一个数据库故障可能触发几十条下游告警。配置依赖抑制：上游告警触发时，抑制下游的衍生告警。同类告警做聚合，10 台机器同时磁盘告警，发一条而不是十条。
交付物：抑制规则、聚合策略
1 周
-
03
换用症状指标
从「原因型告警」转向「症状型告警」。不告警「CPU 高」，告警「下单成功率下降」。前者可能无害，后者一定要处理。原因型指标留给排查时看。
交付物：业务指标清单、SLO 定义
1-2 周
-
04
分级与路由
P1 电话叫醒，P2 即时消息，P3 进工单队列，P4 进日报。不同级别走不同通道，避免所有东西挤在一个群里。
交付物：分级规则、路由配置
3-5 天
改造前后对比（某客户实际数据）
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 日均告警量 | 2,140 条 | 23 条 |
| 需要人工处理的比例 | 约 2% | 约 78% |
| P1 事件平均发现时间 | 31 分钟 | 2 分钟 |
| 夜间被叫起次数（月） | 18 次 | 3 次 |
| 误报率 | 无法统计 | 9% |
告警量降到 23 条不是靠调高阈值糊弄过去，而是靠关闭无动作告警、合并衍生告警和换用症状指标。
几个具体技巧
- 用错误预算燃烧率代替固定阈值：短时波动不打扰，持续劣化及时暴露
- 所有告警必须带 Runbook 链接，没有处置手册的告警不允许上线
- for 子句用足：瞬时抖动不发告警，持续 N 分钟才触发
- 维护窗口内自动静默，避免变更期间的预期告警
- 每月复盘告警质量：哪些是误报、哪些漏报、哪些该降级
- 新增告警要走评审，说明它对应什么动作、谁处理、有无 Runbook
别用「调高阈值」糊弄
把 CPU 告警从 70% 调到 95% 确实能减少告警数，但这是掩盖问题而不是解决问题。正确做法是判断这个指标是否该产生告警——如果 CPU 高但业务正常，它就不该告警，而不是该调高阈值。