运维告警降噪

1客户嘴上要的

「每天几万条告警，值班的人看不过来。上个 AIOps，用 AI 把告警聚类压缩，再自动找根因。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 7 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周找真问题（按规则统计，不按告警统计）

   • 跟运维负责人、3 个值班工程师、2 个开发负责人坐，导出监控平台（Zabbix、Prometheus）近一个月的告警，按「产生告警的规则」统计。发现：每天 2.8 万条告警，前 50 条规则产生了 75%；全部 1,900 条规则里，一半找不到负责团队——创建人已离职、对应系统已下线，或者是新机器上线时默认套用的模板。
   • 值班工程师说，半夜被叫醒后最难的是「不知道这条告警该谁管、要做什么」。
   • 真问题是「告警规则没人认领，也没有生命周期：谁建、谁负责、什么时候改、什么时候删，都没人管」。成功标准改成：「每条会打电话的规则 100% 有负责团队和响应动作；值班工程师夜间被叫醒次数从每周 14 次降到 3 次以内；过去半年的 P1/P2 故障回放时 100% 能触发告警。」
   • 踩坑别先上算法压告警。源头规则不治理，压下去的量一定会反弹。
2. 2–3

   第 2–3 周认领和清理

   • 把规则清单按系统发给各团队认领，两周内无人认领的规则降级为「仅记录」，不再通知任何人。
   • 每条打电话的规则必须写「响应动作」：被叫醒后第一步做什么。写不出响应动作的规则，就不该打电话，降级为 IM 通知或看板。
   • 前 50 条规则逐条处理：调阈值、降级、合并或删除，由负责团队确认。
   • 拓扑只做一件事：从 CMDB 补齐核心业务链路，用于把同链路的告警合并，本期不全面治理 CMDB。
   • 踩坑降级或删除规则前，一定要用历史故障回放。删掉一条看似无用的规则，可能就漏掉一类故障。
3. 4–5

   第 4–5 周原型 + evals

   • AI 用在治理上，而不是只用在告警上。第一，「规则体检」：每月自动给每条规则出报告——触发次数、自动恢复比例、被处理比例、关联过的故障数，并建议「保留 / 调阈值 / 降级 / 下线」。第二，「新规则评审」：新增规则必须填负责团队、响应动作和回放结果，缺项不能上线。第三，同一规则短时间内的重复告警合并。
   • evals：用过去半年 40 次故障回放治理后的规则集，要求 100% 触发；体检建议由 SRE 抽 100 条评估，采纳率不低于 80%。
   • 踩坑体检建议「下线」的规则，要先通知负责团队，观察一周再下线。
4. 6

   第 6 周真实夜班试运行 + 并肩改

   • 在一个值班组试运行两周，由值班工程师本人在真实夜班中使用。FDE 第二天早上和他一起复盘每次被叫醒：该不该叫、响应动作有没有用。
   • 值班工程师反馈：「告警里直接写着响应动作和负责人，半夜不用再翻文档找人」「有两条规则的响应动作是『观察』」——这两条降级为通知。
5. 7

   第 7 周交接交接

   • 交给 SRE 负责人：每月主持一次规则体检会，各团队处理自己的体检建议；新规则一律走评审。每月用故障回放跑一次 evals。
   • 没有体检会和评审流程，规则数会重新膨胀，三个月后又回到第一周的状态。

4这个案例教给你的可复用判断