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