摘要
- 告警通知降噪的目标，是避免值班人员在告警风暴中被短信、电话、IM 消息反复打断。
- 对通知来说，最佳体验通常不是把 300 条告警压成 5 条或 9 条，而是在同一轮事故语境下只触达 1 次。
- 对查看来说，不能只给一条简略消息，而要在页面上按服务、规则、级别等维度聚合展示，让值班人员能快速定位类别和影响面。
- 通知策略要和分派、升级、静默、认领、协同配合：先把人叫醒，再把完整上下文交给处理页面。
- 本文的核心结论是：通知降噪和查看降噪要分开设计，通知入口尽量收敛，事件详情在页面展开。
一个典型的告警风暴场景
比如在某个凌晨 1 点 30 分，突然爆发了 300 条告警，具体类别和数量如下：
- 1条交换机网口的状态告警
- 10条机器失联告警
- 100个服务成功率告警，有a服务、b服务、c服务、d服务
- 100个服务延迟告警，有e服务、f服务、g服务
- 89个连接失败告警，有e服务、f服务、g服务、h服务
这个公司有 OnCall 团队或运维团队，作为告警接收的第一层团队。所以，这 300 个告警会一次性分派给值班人员张三。
如果张三一下子收到 300 条短信或电话，手机可能一直处于被呼叫状态，甚至没有办法联系其他人。这就是典型的通知疲劳：不是值班人员不重视告警，而是通知本身已经干扰了响应动作。
因此，这类场景真正需要解决的问题不是“告警事件能不能被归类”，而是“值班人员需要被通知几次，以及被通知后能不能快速进入处理上下文”。
常见做法：先对告警事件做归类
很多厂商的典型做法，是对告警事件做归类：
- 按照告警规则归类，这 300 个告警事件可以归为 5 个。
- 按照服务归类，可能归为 9 个。
- 采用文本聚类，可能最终归为 x 个。
这样处理以后，作为接收人的我，一次性收到 x 个告警。每个告警消息里会带一些概要信息，看起来比 300 条通知少了很多。
这个做法当然有价值，但它还不是通知降噪的终点。因为对值班人员来说，5 条、9 条或 x 条电话短信，仍然可能在同一时间段反复打断响应动作。
更理想的通知策略：只通知一条，详情到页面看
我作为用户，真正期望的是：如果最终就归为 1 条通知就好了。
这样做有两个直接收益：
- 节省电话、短信等通知成本。
- 减少对值班人员的重复打扰，让值班人员可以把注意力放到定位和协同上。
问题是，如果所有消息都聚拢在一个通知里，这个通知的内容会不会过于简略？其实还好，原因如下：
- 相比根据告警规则、服务聚类，1 条通知确实减少了一些信息，但减少得没有想象中那么多。在通知消息这个载体里，5 条、9 条和 1 条都只能承载概要信息。
- 真正查看具体告警事件详情时，一定是在页面上看，而不是在短信里或者电话里看。
- 页面上应该支持聚类，也应该支持自定义聚类规则，比如 Prometheus alertmanager 或者 Nightingale 都支持类似的展示方式。
下面是一个页面聚合展示的例子：
既然如此，就可以直接把这 300 条告警在通知层面归类为 1 条，然后把处理链接返回给用户。用户收到之后，消息里的提示大概是：
xx 告警了，共 300 条，最高级别 Critical，处理链接 https://xxxx
这条通知要完成的任务很明确：告诉值班人员“有事发生了、规模是多少、最高级别是什么、去哪里处理”。更细的分组、服务、规则、事件列表，不应该挤在通知里，而应该在处理页面里展开。
通知降噪策略总览
| 策略环节 | 要解决的问题 | 推荐做法 | 注意事项 |
|---|---|---|---|
| 通知收敛 | 同一轮告警风暴反复打扰值班人 | 在通知层面尽量收敛为 1 条入口消息 | 通知要包含总量、最高级别和处理链接 |
| 页面聚合 | 值班人需要看清告警类别和影响面 | 在页面按规则、服务、级别等维度聚合展示 | 不要把所有细节塞进短信或电话 |
| 分派和值班 | 谁应该第一时间处理 | 将事件分派给 OnCall 团队或运维值班人 | 分派目标要明确，避免多人同时被无差别打扰 |
| 升级 | 首轮值班人未响应或需要协同 | 结合升级策略把事件转给下一层人员或团队 | 升级应服务于响应闭环，而不是制造更多重复通知 |
| 静默 | 已知变更或无需重复打扰的场景 | 对明确范围内的重复通知做静默 | 静默不等于删除事件，页面仍应保留可查看上下文 |
| 认领与协同 | 多人处理时需要同步状态 | 支持认领、备注、协同处理 | 让后来者能看到当前进展，减少重复沟通 |
底层逻辑：区分通知降噪和查看降噪
上面的做法其实就是 Flashduty 的做法。作为一个统一的事件 OnCall 中心，Flashduty 既可以支持告警聚合降噪，也支持排班、认领、升级、协同等其他功能。
这套降噪逻辑的关键，是区分对待通知降噪和查看降噪。
通知降噪：把打扰次数降到最低
通知降噪关注的是“人被打扰几次”。在告警风暴里，通知的目标不是让值班人员在短信里读完所有细节，而是尽快知道有高优先级事件需要处理。
所以，通知降噪做到极致，就是通知一条。它承担的是唤醒和入口作用。
查看降噪：把页面信息组织清楚
查看降噪关注的是“人进入页面后能不能看懂”。页面上要根据聚合规则做聚合展示，让用户一目了然地知道有哪些类别的告警事件、哪些服务受影响、最高级别是什么。
这两件事不能混在一起做。如果把查看详情的任务交给短信或电话，通知会变长、变碎、变难读；如果只做 1 条通知但页面没有聚合能力，值班人员进入页面后仍然会被 300 条事件淹没。
因此，合理的设计应该是：通知尽量短，页面足够清楚。
FAQ
Q1：告警通知降噪是不是等于把告警合并掉？
不是。通知降噪主要减少的是对人的重复打扰，不应该让告警事件详情消失。事件详情仍然要在页面上可查看，并且最好能按规则、服务、级别等维度聚合展示。
Q2：为什么不把 300 条告警按规则或服务归成 5 条、9 条再通知？
这种做法比直接通知 300 条好，但对值班人员来说，同一时间收到多条短信或电话仍然是打扰。更好的方式是通知层面收敛为 1 条入口消息，页面层面再提供聚合视图。
Q3：一条通知里至少应该包含哪些信息？
至少应该说明发生了什么、共有多少条告警、最高级别是什么，以及处理链接在哪里。比如：
xx 告警了，共 300 条，最高级别 Critical，处理链接 https://xxxx
Q4：静默会不会导致漏告警？
静默应该用于明确范围内的重复通知控制，而不是删除告警事件。合理的做法是减少不必要的触达，同时在页面保留事件上下文，让值班人员需要时可以继续查看和处理。
结论
告警通知降噪的本质，不是追求某个漂亮的压缩比例，而是让值班人员在告警风暴中只被必要地打扰，并且被打扰后能快速进入完整处理上下文。
通知层面，尽量收敛为一条清晰的入口消息；查看层面，在页面上做好聚合、分派、认领、升级、静默和协同。两者配合起来，才是真正对值班人员友好的告警降噪。
