我们接手的每一套监控系统都是同一个样子。成千上万项检查。每天数百条告警。一个没人打开的专用邮件文件夹。还有一位工程师，不用看就能告诉您哪三条告警是真正有意义的。
那位工程师才是真正的监控系统。软件只是在他周围制造噪音。
人人都熟悉的症状
告警疲劳常被说成是人的问题：团队变得麻痹大意，需要更认真地对待告警。这种说法是错误的，而且会让情况更糟。
如果 95% 的告警都无需处理，那么忽略告警就是正确的策略。团队只是准确地掌握了基础比例。您无法通过培训消除这一点，也不应该希望如此：一位对每天两百条通知中的每一条都全力紧急响应的工程师，不出一个月就会身心俱疲、无法工作。
告警疲劳不是纪律问题，而是设计问题，解决办法是删除告警。
危险的后果不在于噪音本身，而在于真正的告警，也就是凌晨 3 点那条确实重要的告警，会落入一个大家早已学会忽略的频道，而且看起来和当晚其他四十条告警一模一样。
这是关于警报最古老的故事，我们把它讲成了“狼来了”。
一个问题解决大部分麻烦
对每一条会叫醒值班人员的告警，问一个问题：
检验
这件事现在需要有人去处理吗？
如果需要，就呼叫值班人员。如果可以等到早上，它就是一张工单。如果永远不会有人去处理，它就是仪表板上的一项，或者根本不应该存在。
只要如实执行，这一检验通常能去掉传统监控系统 80% 到 90% 的呼叫。它遇到的阻力总是一样的：“但我们想知道这件事。”
想知道是合理的，但这和需要被打断不是一回事。它们对应三个不同的去处：呼叫、工单队列或仪表板。大多数嘈杂系统的核心错误，就是所有告警都被发送到了第一个去处，只因为那是默认设置。
针对症状告警，而不是针对原因
第二个改变是：究竟针对什么告警。
大多数接手的系统都针对原因告警：CPU 超过 90%、内存超过 80%、进程重启、队列超过一千条消息。每一条听起来都合理，但加在一起会产生巨大的噪音，因为没有一条能可靠地说明出了问题。
CPU 偏高可能只是批处理作业在正常工作。进程重启可能只是一次例行部署。队列里有一千条消息，在周二可能再正常不过。
基于症状的告警问的是另一个问题：用户会注意到什么？
| 基于原因（嘈杂） | 基于症状（可操作） |
|---|---|
| CPU 超过 90% 持续 5 分钟 | 请求延迟超过 2 秒持续 5 分钟 |
| 一台 Web 服务器宕机 | 负载均衡器后的健康服务器少于 N 台 |
| 队列深度超过 1,000 | 最早的消息已超过 10 分钟 |
| 磁盘使用率 85% | 按当前速度磁盘将在 4 小时内写满 |
| 备份作业返回非零值 | 26 小时内没有成功的备份 |
| 证书将在 30 天后过期 | 证书将在 7 天后过期且尚未续期 |
右栏具备左栏所没有的三个特性。触发频率低得多。几乎每一条都很重要。而且在底层系统变化时依然正确：您可以替换整个后端，“请求报错”仍然是正确的告警，而每一个 CPU 阈值都需要重新调整。
特别留意队列的例子。没有吞吐量，深度就毫无意义；一个有一万条消息但正在快速消化的队列是健康的，一个只有五十条但一小时没动过的队列则已经出了故障。消息的等待时长才反映您真正关心的东西。
如何重建一个嘈杂的告警系统
人们的本能是逐个调整阈值。这要花上一年时间，而且底层设计原封不动。我们从另一个方向入手。
1. 停止所有告警的呼叫。把现有告警全部发送到一个低优先级频道。这听起来很鲁莽，其实不然，因为本来就没人在看它们，您只是把隐含的事实明确了下来。
2. 写下什么才算紧急情况。去问业务部门，而不是工程师。答案通常简短而具体：客户无法登录、订单无法处理、电话打不通、数据面临风险。大多数企业能列出五到十条。
3. 为每一条建立告警，从用户的角度出发。不是“数据库是否在线”，而是“订单能否完成”。合成事务在这里非常好用：一个每分钟真实登录并走完关键流程的脚本，比五十项基础设施检查告诉您的更多。
4. 只针对这些发出呼叫。其余的全部转为工单或仪表板。
5. 只把证明有价值的告警加回来。每次事件之后，问一问是否有某条告警能更早发现它。如果有，就只加上那一条。告警集合依据事实而不是焦虑逐步增长。
对于原本有数百条告警的环境，大多数组织最终只保留八到二十条会呼叫值班人员的告警。覆盖范围并没有变差，反而更好了，因为剩下的告警会有人看。
每条告警都需要一份运行手册
一条凌晨 3 点触发、内容为 DiskSpaceWarning: prod-db-02 的告警是一道谜题，而不是一条指令。工程师必须在半睡半醒之间弄清楚它是什么意思、是否重要以及该怎么做。
每条会呼叫值班人员的告警都应链接到一份简短文档，回答四个问题：
- 它实际是什么意思？用通俗的语言说明。
- 对用户有什么影响？现在是否有人受到影响？
- 我先检查什么？按顺序列出两三个最可能的原因。
- 我该如何处理，又该向谁升级？
这还有一个有用的副作用。如果您无法为某条告警写出运行手册，如果对“我该如何处理”的如实回答是“我想，看一看吧”，那么这条告警就没有通过第一部分的检验，不应该呼叫任何人。运行手册的要求既是文档，也是一道过滤器。
如何衡量是否奏效
每月跟踪三个数字：
- 每个值班班次的呼叫次数。常见的基准是平均不超过大约两次。超过这个数，注意力就会下降，响应质量也随之下降。
- 可操作率。有多大比例的呼叫让人采取了行动？低于大约 75%，说明仍然有噪音。这是最有用的一个数字。
- 没有告警的事件。客户比监控更早报告的问题。这是对矫枉过正的检查：如果这个数字在上升，说明删减过度了。
然后每周开一次十五分钟的复盘：触发了什么、是否可操作、是否保留？反复触发却无需处理的告警要删除或降级。正是这个会议让系统不再倒退，因为嘈杂的监控不是一次性发生的，而是一项项看似合理的检查日积月累而成的。
目标说起来很简单，在实践中却出奇地少见：每当呼叫到来，所有人都相信它。这比任何没人看的覆盖范围都更有价值。
什么是告警疲劳？
指一个团队收到的告警太多，而且其中大部分最终都无关紧要，以至于他们不再紧急响应告警的状态。这是监控系统的设计缺陷，而不是团队的纪律问题。一旦误报的基础比例高到一定程度，忽略告警就成了理性的反应。
如何减少告警疲劳？
对每一条会呼叫值班人员的告警做同一个检验：这件事需要有人立刻处理吗？如果不需要，它应该是仪表板上的一项或一张工单，而不是一次呼叫。接着，针对用户可见的症状而不是内部原因告警，为每条告警配备运行手册，并每周复盘实际触发了哪些告警，删除或降级所有无需处理的告警。
基于症状的告警和基于原因的告警有什么区别？
基于原因的告警针对内部状况触发：CPU 偏高、队列已满、进程重启。基于症状的告警针对用户的实际体验触发：结账失败、网站变慢、请求报错。症状告警数量少得多，几乎每一条都很重要，而且在底层系统变化时依然有效。
磁盘空间告警应该呼叫值班人员吗？
很少需要。磁盘使用率 85% 只需一张工单，因为在工作时间内有充足的时间处理。如果磁盘将在一小时内写满，而系统在磁盘写满时就会故障，那才需要呼叫。区别在于距离产生影响还有多少时间，而不在于阈值本身，因此基于写入速度的预测性告警远比固定百分比有用。
值班工程师每个班次应该收到多少条告警？
一个广泛采用的基准是：平均每个值班班次不超过大约两次呼叫。超过这个数量，工程师就无法认真对待每一次呼叫，响应质量随之下降。如果您长期超过这个数，解决办法是删减告警，而不是增加人手。