转载

对抗警报疲劳的七个步骤！

警报疲劳是一个棘手的问题，但事不宜迟，越早开始越好。利用警报数据，你可以有效清理监控系统，排除不可操作的警报。

简便起见，我们编写了对抗警报疲劳的七个步骤。

减少警报疲劳的七个步骤

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 到事件中，或直接将运行手册链接加到服务描述里。