警报疲劳是一个棘手的问题，但事不宜迟，越早开始越好。利用警报数据，你可以有效清理监控系统，排除不可操作的警报。
简便起见，我们编写了对抗警报疲劳的七个步骤。
减少警报疲劳的七个步骤
1.付诸行动
清理监控系统并不简单，而且人们容易对高级别警报产生麻木感。但是，第一步需要决定如何处理报警。不妨先浏览一下你的报警数据，看下班时间出现了多少警报以及其影响。
接着，团队启动清理警报的工作流程。Etsy 就曾设立过「黑客周」来解决大型监控卫生问题，当然，一周留出几小时或每个月留一天进行清理工作也可以。
2.删除不可操作的警报并调整阈值
首先回顾最常见的警报（提示：你可以通过 PagerDuty 的 Advanced Reports 深入了解事件）。然后询问最近当值的人员，判断每个警报是否可操作。
一旦发现不可操作的警报，直接删除之。
对 CPU 和内存使用监控和警报非常普遍，因为这些指标会暗示是否存在错误。但是，这些指标无法给出具体的错误信息，所以它们是不可操作的。Etsy 已经放弃监测这些指标，转而专注于排查更具体、可操作的信息。
你可能还需要调整检查的阈值。来自 Exosite 的 Dan Slimmon 曾分享过一个非常不错的谈话 「烟雾警报和汽车警报」，详细介绍了两个医学检测概念如何应用于设置警报问题。这两个概念是敏感性和特异性，将两者结合可得到阳性预测值（PPV）——警报响起时确实存在问题的可能性。该谈话还分享了如何通过滞后（结合考虑当前值与历史值）与其他技术，改进 PPV 的策略。
3.延迟处理不严重事件
尽管所有警报都很重要，但有些可能并不紧急。所以无需为了后者在半夜将整个团队叫醒。你可以为非严重事件创建单独的工作流程，以保证它们不再打扰你休息或当前的工作。在 PagerDuty 中，可以通过在低严重性服务中禁用「Incident Ack Timeout」和「Incident Auto-Resolution」来设置。
4.整合相关警报
当故障出现时，你可能会得到指向同一问题的多个警告。你可以根据监测依赖性进行设置，并利用 OneAlert 最佳实践教程来整合警报：
使用 incident key 告知 PagerDuty 哪些事件是相互关联的。例如，如果多台服务器宕机，每台服务器可能都会向 PagerDuty 发出通知。但如果这些通知的 incident key 相同，我们可以将通知整合成一个警告，告诉你30个服务器正处于宕机状态。
警报风暴期间，PagerDuty 会捆绑首个事件之后触发的警报。例如，如果一分钟内有10个事件被触发，在第一个警告后，你只会再收到一个汇总警报。
5.为警报添加名称和描述
收到警告后，得知某处出现问题，却没有能衡量问题严重程度的信息，也不知该如何处理，这种情况最为糟糕。
给警告添加描述性名称。如果设定一个指标（比如，已使用的磁盘空间），请确保有足够信息使他人了解其意义。磁盘空间达到了80%还是99%？
在警报描述中添加相关的故障排除信息，比如指向现有文档或运行手册的链接，能帮助团队深入挖掘当前事件。在 PagerDuty 中，你可以添加 aclient_url 到事件中，或直接将运行手册链接加到服务描述里。
6.确保相关人员收到警报
当团队刚开始监控时，他们通常会将所有警报发送给所有人。事实上，没人愿意接收毫无意义的信息，如果你有不同的团队负责不同的架构模块，可以使用 Escalation Policies 调整警报设置。
7.更新定期审查
为了保证清理工作的效果，你需要每周定期审查这些警报。 Etsy 就定制过有趣的审查流程 「Opsweekly」（点此查看其 Github repo），但也有些公司使用电子表格来定期审查。
为了防止警告疲劳成为常态，可以为待命团队设定量化指标。一旦满足限度，无论是在监测清理过程还是在休息时间，都必须采取处理行动。 PagerDuty 会查看每周的警报数，如果某个待命团队接收的报警数超过15，我们会总结并审查这些警报。
最重要的，是养成警报监控的团队协作精神。如果你收到一个不可操作的警告，即便只有一次，你也有责任确保该警报不会再打扰其他成员。
目前市面上的类似 SaaS 云告警平台有几个，大家可以参考下：国外的 PagerDuty、VictorOps、OpsGenie，国内目前做的比较好的是 OneAlert ，感兴趣的同学可以去免费试用一下！
原文链接：https://www.pagerduty.com/blog/lets-talk-about-alert-fatigue/
