问题描述
最近，我们经常听到”警报疲劳”这个词。我有几个关于这个问题的问题：
– 这个术语是从哪里来的？
– 它是由像PagerDuty这样的公司发明的吗？
– 警报疲劳到底是什么？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
警报疲劳（Alert Fatigue），也被称为报警疲劳（Alarm Fatigue），已经存在了几十年。它影响许多行业，包括医疗、技术和建筑行业。根据《Alert Fatigue by Other Names》的参考资料，关于这个问题的最早文献出现在以色列阿拉伯冲突期间。对这个问题的实践和理解是古老的。
PagerDuty并没有发明这个术语。
警报疲劳的定义如下：
当一个人接触到大量频繁的警报（报警）并因此对它们变得麻木时，就会发生警报疲劳。
这是一个关于警报疲劳的经典例子：伊索寓言中关于”喊狼来了”的故事。在技术和医疗领域，当警报频繁发生（有或没有原因）时，我们会对它们变得麻木。这种麻木的结果是：
显著降低我们对类似后续威胁的反应。
换句话说，我们对警报变得如此习以为常，要么忽视它，要么花时间才能承认它的存在。
参考资料
– Alert fatigue by other names
– Alarm_fatigue
– Cry Wolf – When Experience Becomes Fateful
方案2
我花了多年时间开发各种监控工具，这些工具使用了各种方法来跟踪数据点，包括过滤日志、收集系统统计信息（例如：从/proc查询数据或运行命令并解析输出），或者在应用程序工作流代码中放置简洁的“标记”代码以跟踪整体性能。在所有这些不同的方法中，根据条件触发警报的过程并没有发生太大变化。通过这些经验，我学到了一些避免“警报疲劳”的关键原则，它可以简单地描述为通过您的寻呼机、电子邮件或移动通知接收到如此多的警报消息，以至于可以忽略它们（无论是因为被告知忽略还是自行决定），导致您的员工忽视可能重要的事件，逐渐变得疯狂，或者暗自希望您早日离世。
话虽如此，以下是创建触发警报的几个关键原则，我认为现在和20年前一样重要。当然，创建良好的监控和警报还有许多其他原则，所以这并不是一个完整的列表。
– 所有警报都应该是“可操作的”。也就是说，如果发送了一个警报通知，意味着接收者应该采取一些行动。非可操作的警报是“警报疲劳”的主要原因，因为有先例可以忽略警报，这可能导致类似于“我不知道这是什么意思，所以它一定是垃圾”的情况。相反，如果说一个警报是“可操作的”，这意味着任何事情，从手动验证某些原因可能不明显的东西（例如手动运行一个进程，以便可以进行主观评估），或者可能是重新启动等纠正步骤。不要在半夜因为不明确是否存在潜在问题而给人们发信息。这可能看起来很明显，但是在创建警报时很常见，而不自觉地创建了这样的警报，所以一个好的做法是确保您接收到您创建的任何新警报，这样您就可以亲自体验支持工程师接收到的内容，以便根据需要进行调整或适应，同时还要沟通您正在做什么，以便支持工程师意识到您正在“解决问题”，并且不会立即认为这个新警报是垃圾。一旦您的经验表明，在调整警报条件的时间后，通知与需要采取行动的条件相称，然后通知它是“实时的”，并且应该被视为这样。（还有一种方法可以识别“正在开发的警报”也是有帮助的）。另一方面，如果您或您的团队有基础设施触发警报，您最终会告诉支持人员“只是忽略它”，而不做任何修复，那么您就有了一个关键的流程问题。理想情况下，应该暂停此警报，直到“修复”为止。总结一下，“警报噪音”会导致“喊狼来了”的问题，最终会导致人们忽视那些不可避免的实际网站退化的事情，而且你会受到伤害。这不是“是否”，而是“何时”。
– 通知的“坚持性”应该与问题相适应。例如，当您遇到影响生产的事件时，无论是白天还是晚上，应该向能够解决问题的相关人员发送警报，期望在短时间内确认警报，然后再自动升级等等…另一方面，如果问题是可以等到下一个工作日解决的，比如磁盘慢慢填满或者不是生产问题，可以发送一封电子邮件或者在Slack频道中发送一条消息，以便稍后解决，可能是下一个工作日。建立一些具有特定SLA的优先级系统。
– 尽可能使用监控依赖关系来避免警报“风暴”。一个合适的监控工具集应该允许您建立依赖关系，以便在出现一个总体问题会导致其他依赖于它的监控失败时，抑制警报。一个简单的例子是，如果一个主机无法访问，只发送一个网络不可达的警报。不要发送关于磁盘、端口等等的警报，因为这些都需要网络连接才能工作，并且只会给您带来“未知”的结果。当您需要清晰度以便您可以快速通过查看警报列表几秒钟内解决问题时，这只会使事情变得混乱。
如果您的团队中出现了“警报疲劳”问题，首先从这三个原则开始。如果在执行这些原则后，您的警报变得有意义和简洁，但是数量上仍然过多，那么您可能需要专注于创建自动恢复作为您监控工作的下一个阶段，从离散的运行簿开始。例如，如果由于无法自行恢复的异常而导致Web服务无响应，而不是发送警报，尝试重新启动。仅在重新启动无法解决问题时发送警报，并在解决后发送非紧急消息，这可以在下一个工作时间内注意到。
以上是如果您的团队中出现了“警报疲劳”问题时的三个原则。