转载

对抗不可执行告警的四种措施

对于运维团队而言，很多告警其实并不能帮助他们解决掉实际的问题，相反有时会加重多余的负担，这主要是因为大多数的告警并不具备足够的可执行性：

它们指出的问题压根儿不需要响应
它们缺少关键的信息，迫使你需要花费很长的时间去寻找更多的源头，用以来估量它们的紧迫性

过量的不可执行告警会造成告警疲劳，浪费时间和资源，从而耽误你解决实质性的问题，可能这些已经在你身边正悄无声息地发生着：

你是否自动忽略收到的多余告警？
你是否收到很多与你无关的告警？
每当你收到告警时，是否为了获得你真正需要的信息而采取一系列常规的行动？

如果有以上这样的情况，就能确定你是在遭受着告警疲劳，本篇将会列出四种常见的不可执行告警及其解决办法。

1、无益的标题

问题：标题是告警的重要组成部分，因为它是你第一眼看到的东西。含糊不清的标题会迫使人们为了获取更多的信息而对告警主体进行不必要的挖掘，而当不同的告警使用相似的标题时，会使你感到更加沮丧、困惑，导致时间和精力上的浪费。

例子：在收到标题为「CPU LOAD 1.90」的告警后，你又收到一个标题为「CPU LOAD 1.80」的告警。这俩告警是否是关于同一个服务器的呢？负载1.80是否关键？这个问题会有什么影响？如果告警能提供解答而不是添加更多的问题，岂不是更好吗？

改进措施：所有的告警标题都应该简短且具有一定的描述性，它们应该让人在看到第一眼的时候就知道问题是什么，出现在哪里并且需要怎样去解决。例如「Server billing-1 load is critical for 5 min」就比「CPU LOAD 1.80」更具有执行性。

2、缺少必要信息

问题：告警的内容通常是有限或者模糊的，导致我们为了获取更深层次的理解，往往会花费大量的时间去解读这些告警，以求查找到更多的信息。有时，在 Nagios ，Graphite，Pingdom 或 New Relic 的某处发现了相关的信息，但实际上大量的时间并不是用在了解决问题上，而是花在了寻找上面。

例子：在解决服务器过载问题时，大家都是使用着差不多的套路：譬如连接服务器，查看 load 值等。而且，下次一个相似的告警发生时，你还得一次次地执行这些相同的步骤。

改进措施：我们熟练的打开操作系统键入问题信息，来追踪那些告警的源头去进行整体考量。假如告警信息这个载体能呈现给我们更多有用的源信息的话，比如：执行的行为或者相关资源的链接（这些资源包括脚本、协议或者研发者对问题发生原因的理解），那么对于决策和追踪排查的效能就会有很明显地提升.

3、不需要解决的告警

问题：生产环境是复杂且动态的。为了保持系统的稳定性，运维和研发团队需要读取到重要的系统信息。直觉告诉我们，这需要将每个告警和异常通知都给到这些人，然而实际上，大多数的告警收到后并没有采取有效措施，并且还时常会把有用的告警覆盖掉。

例子：用户输入无效的信用卡账号，会立即发送告警，这个信息应该非常值得关注才对。但我们不能控制用户的行为，所以一般情况下这个告警只是额外的噪声而已，对此我们也毫无办法。

改进措施：如果收到告警后不能立即采取行动，那就别发送它，而去找到需要你做出反应的问题。例如，把提示无效信用卡账号的告警替换为一个可执行的告警，比如指示用户支付成功率急剧下降的告警———可能系统会做出较大的变化，需要回滚操作。另外一种解决办法是采用每日或每周报告，汇总不需要实时处理的信息。这样，真正有用的信息就可以实时地被接收来处理。