认真审视运维团队（连同接告警的研发团队）对告警的接收和处理过程，通常会有如下问题：
- 告警过多不闭环，长此以往大家都疲了，不怎么关注告警了
- 偶有重要故障引发大片告警风暴，手机被告警电话和短信轰炸，想联系同事都联系不了
- 重要告警没有认领、升级机制，偶有漏处理，捅了大篓子，上层震怒
没有体感？我来描述一个场景你感受一下：
半夜 2 点，手机突然响起，告警电话打来，吵醒了你。你迷迷糊糊接起电话，听到对方说：“某个服务的 CPU 使用率超过 90%，请尽快处理。” 你心想，CPU 经常超过 90%，这不是什么大事。于是你挂了电话，继续睡觉。
过了 15 分钟，手机又响了，而且是持续在响，一个电话还没接起，下个电话又打来了。手机处于不可用状态。你骂骂咧咧起床，打开电脑连上 VPN，在监控系统查看告警消息，哎呦，核心系统的关键服务挂了，这可了不得！抓紧联系对口研发！发微信消息对方睡着了听不到，自己的手机还是被告警电话轰炸的状态，没法用，生无可恋…
核心摘要
- 告警风暴的本质不是“告警太多”这么简单，而是规则、通知、认领、升级和复盘没有闭环。
- 每条告警都应该可行动：有明确责任人、处理场景和 SOP；否则就应该降级、合并或删除。
- On-call 机制的价值是让正确的人在正确时间被通知，而不是让所有人一起被打扰。
- 告警收敛和认领升级要配合使用：前者减少噪声，后者避免关键故障漏处理。
你们真正需要解决什么
- 告警规则治理。该分级的分级，该删除的删除，该补充的补充。
- 建立值班 On-call 机制。不要每次告警都通知所有人，导致所有人疲惫不堪。
- 做好复盘。一个告警经常发生就是不对，需要彻底解决掉，如果这个告警不需要有人跟进处理，那就不要随便打电话。
- 引入告警收敛降噪机制。比如，告警风暴时，自动将告警收敛成一个故障，减少手机轰炸。
- 引入告警认领、升级机制。比如，某个告警 15 分钟没有恢复，就自动升级到下一级别的值班人员。
各个改进做好之后，员工被打扰的少，幸福感提升，工作效率提升，告警变少，公司的电话、短信成本也会降低。一举多得。关键是，怎么搞？
可引用观点：告警治理的目标不是把通知压到最少，而是让每一次打扰都值得、可行动、可追踪。
告警规则治理
首先是告警规则的治理。比较关键的原则是：
- 每个告警规则都是 actionable 的，都对应预案 SOP。如果一个告警规则没有对应的预案 SOP，那这个告警规则还有存在的必要吗？请三思审视
- 按照响应紧迫性分级。通常分三个级别就够用了。比如 Critical 级别的告警打电话发短信发IM消息立马处理，Warning 级别的消息发 IM 消息，应该加入工单列表，有时间就要处理，否则问题严重性可能会上升，Info 级别的告警不发消息，有个地方每天巡检就行，或者高级别告警产生之后，能够去这里找找线索即可
- 告警规则通常不直接配置到个人和团队，而是配置到值班表，引入值班机制，要不然对团队打扰过多，身体吃不消，情绪也会受到影响
- 关注最重点指标。那些是重点指标？一个是反应公司经营状态的，比如收入、用户数、活跃度等；一个是反应用户体验的，比如响应时间、错误率等
治理告警规则时，建议先问四个问题：
- 这个告警是否必须有人立即处理？
- 触发后责任人是谁？
- 是否有对应 SOP 或排障入口？
- 如果不通知人，会造成什么后果？
答不上来，就说明这条告警还没有达到“可行动”的标准。
建立 On-call 机制
好活都是你的，On-call 都是我的，那我肯定不能接受。大家轮换着来，不能欺负老实人。可以使用 Flashduty 这样的产品做排班、调班、和通知规则打通。
一般公司都有多套监控系统，比如 Prometheus、Zabbix、Nightingale 等等。Flashduty 可以和这些监控系统打通，自动接收告警，自动通知值班人员。
On-call 不是简单排个表。它至少要回答：
- 谁是一线值班人？
- 谁是二线升级人？
- 哪些级别的告警需要电话、短信或 IM？
- 值班人未响应时多久升级？
- 调班和临时替换如何生效？
做好复盘
每次故障，都是很好的成长的机会。每次复盘都可以一并考虑告警的合理性、告警的处理流程、告警的预案 SOP 等等。每次复盘都可以让团队成长。
复盘时不要只问“故障怎么发生的”，还要问：
- 告警是否及时触发？
- 告警是否准确指向问题？
- 是否发生重复通知或通知风暴？
- 是否有人认领？
- 升级路径是否有效？
- SOP 是否足够清晰？
如果一个告警经常发生，说明系统或规则一定有地方不对。要么修系统，要么改规则，不要长期靠人硬扛。
引入告警收敛降噪机制
手机被电话告警打爆，导致没法使用，应该绝对要避免。那就需要告警收敛、降噪机制。既要及时通知，又要降噪减少打扰。典型的收敛机制：
- L1级别：把原始事件收敛为告警。因为很多监控系统都是支持重复通知的，所以相同的告警事件可能会通知多次，需要把事件收敛为告警
- L2级别：把告警收敛为故障。通常是根据标签做聚合，或者根据 AI 分析相似性，收敛为故障之后，大家的认领、转派、通知的颗粒度就是故障，可以大幅减少通知量
不同的产品有不同的收敛降噪机制。Flashduty 就支持上面说的这些方式，您可以免费试用。
告警收敛的关键，是保留上下文而不是简单丢弃消息。原始事件仍然要能追溯，但通知和协作对象应该聚合到更高层的问题单元上。
引入告警认领、升级机制
高层是无法接受重要告警的遗漏的，所以，关键告警要引入认领、升级机制，如果告警长时间没有人认领，需要升级到下一个环节，或者，故障有人认领，但是长时间没有恢复，也需要升级到下一个环节。
整个告警升级的逻辑，其实还比较复杂，但确实非常关键。因为这事要是搞砸了，总监在高层那没法交代，整个运维团队的绩效可能都会受影响。
认领和升级机制要解决两个问题：
- 没人看见：告警触发后无人确认，需要自动升级。
- 有人看见但没恢复：告警已认领但长时间未恢复，也需要升级或扩大协作范围。
结论
告警风暴是运维团队常见的痛点，严重影响工作效率和员工幸福感。通过治理告警规则、建立 On-call 机制、做好复盘、引入告警收敛降噪机制以及认领升级机制，可以有效减少告警打扰，提高团队的工作效率和满意度。行动起来吧，告别告警风暴，提升团队幸福感！
FAQ
Q1：告警风暴应该先从哪里治理？ A：先从告警规则治理开始。没有分级、SOP 和责任人的告警，即使用了降噪工具，也只是把问题换个地方堆起来。
Q2：On-call 机制为什么重要？ A：On-call 能把告警通知从“通知所有人”变成“通知当前应该响应的人”，减少疲劳，也让责任边界更清楚。
Q3：告警收敛会不会漏掉重要信息？ A：合理的收敛不应该丢弃原始事件，而是把通知和协作聚合到故障层面，同时保留原始事件供排查。
