当所有事情都紧急时，就没有什么事情是真正紧急的了。什么是警报疲劳？如何应对？

你加入了一个新团队，被添加到他们的邮件列表和 Slack 通知频道。
第二天，你碰巧是第一个登录的人：

15 条通知，生产环境中的几个应用程序报错了！

你对代码库和基础设施不太熟悉，只能摸索着前进，浏览代码仓库，在 AWS CloudWatch 中搜索或在 Kibana 中筛选日志，却始终不得要领。
最重要的是，你完全不知道该怎么办！：
是应该重启服务器？还是应该清除缓存？或者应该通知相关人员？

一个小时或更长时间后，一位同事进来，你向他解释了问题，由于你未能找出并解决问题，你感到有些担忧和沮丧。

然后，他耸了耸肩说：

哦……别浪费时间看那个了。那是个错误，但很正常。

这正常吗？！为什么 正常？！

我们的 Slack 频道收到警报，警告存在严重的生产错误，而你却告诉我我不用担心，因为这很正常，不是什么令人担忧的迹象？

是的，除非发生得太频繁，否则这不是问题。

哦，好的。那么“过于频繁”具体指的是什么：一小时内出现 50 个错误，一天内出现 50 个错误，还是端点调用次数的 20% 或 100%？

真的，别担心，我查看了一下日志，没有发现任何可疑情况，就像我说的，一切都正常。

从恐慌到麻木

你是否遇到过这种情况？
不幸的是，这种情况很常见（而且不幸的是，这种情况也发生在单元测试或构建过程中——你刚接触一个项目，尝试运行它，却在终端看到很多错误，你担心你的代码或配置有问题，于是询问你的同事，而每个人都翻白眼，告诉你忽略它们继续下去）。

这或许并非某些人所称的“警报疲劳”（也称“警报警报疲劳”），即值班开发人员因线上应用出现问题而不得不每晚醒来。
但即便不考虑睡眠不足、加班和倦怠，团队成员不得不将时间和精力浪费在无关的通知和警报上，也让我感到非常担忧。

令人担忧的是，当不稳定的测试或持续集成流水线频繁失败时，最终会没有人再关心它们是否失败。然后人们不再信任持续集成和测试，要么我们停止编写测试，要么我们仍然需要手动完成许多工作。

当警报过多时，其中大部分只是通知我们某些东西“可能”出错或损坏，到某个时候，我们就不再对 Slack 通知或电子邮件感到担忧，也没有人会急于查看仪表板和日志来了解发生了什么。

直到发生不好的事情，却没有人做出反应。

警报疲劳。为什么会发生这种情况？

错误处理、日志记录、跟踪、指标、警报：在匆忙实施和交付应用程序时，这些往往都会被忽略。

我们过于专注于功能实现，以至于把错误处理放在最后一步。我们会在发现错误时，在测试过程中，甚至在生产环境中，不断添加错误捕获机制。由于我们通常无法确定是否已经捕获了所有错误，最终导致警报系统过于宽泛且过于敏感，几乎每次都会触发。这本身
倒没什么大不了的，但团队需要投入额外的精力和资源来尽快妥善处理错误（然而，一旦生产环境中出现错误，所有人都会蜂拥而至地进行bug修复，然后紧急情况过去后…… “下次再考虑警报吧，咱们继续冲刺！ ”）。

防止警觉疲劳

在放过重大错误和被警报淹没之间找到合适的平衡点并非易事。

优先排序

首先，我们需要确定什么是错误（是代码中的异常还是与业务逻辑相关的错误），以及我们应该如何处理它。然后，我们需要确定优先级。
哪些是关键错误？哪些错误需要监控并最终采取行动？哪些只是警告？哪些可以记录下来，偶尔查看一下？

• 设置一个仪表盘，以便快速概览应用程序的运行状况，以及任何从业务角度来看可能重要的统计数据，例如调用次数、持续时间、软错误（从业务逻辑角度来看的错误，但并非代码崩溃或异常）等等。
• 为那些需要立即干预（人工干预）的指标设置警报。

使用阈值和异常检测

我们的大多数项目都基于 AWS，并且大多采用无服务器架构。
这对我们来说非常有利，因为所有服务都已具备大量指标，而且添加告警（以及创建自定义指标）也相对简单。如果绝对数值可能具有误导性，
您可以使用静态阈值或异常检测——尤其是在我们的应用程序在一天中的不同时段使用量差异很大的情况下。（例如，过去 30 分钟内出现 5 个错误的静态阈值在中午流量高峰期可能永远不会达到，但在夜间请求量极低但全部失败的情况下，则可能会触发呼叫值班。）

负责任地通知

如果你使用 Slack 来发送通知和警报，请尽量减少噪音。

• 为不同的项目使用不同的渠道——这样不同的团队成员就可以屏蔽他们不“负责”的应用程序的通知。
• 使用不同的颜色/级别的通知，这样即使收到 20 条警报，也能立即发现那条红色的关键警报。

如果您使用电子邮件，我们还使用过一个很棒的技巧：邮件过滤器。
例如，Gmail 有一个很有意思的功能：您在电子邮件地址后添加的“+”号后面的任何内容基本上都不会被视为电子邮件地址的一部分，而是可以用于过滤器中，例如myteam-alerts+critical@gmail.com或myteam-alerts+justkeepaneyeonit@gmail.com。因此，您可以基于该电子邮件收件人创建 Gmail 过滤器，并聚合和过滤不同类型的通知。

明确所有权

谁负责查看错误？何时查看？多久
查看一次？这项服务是否需要值班？
如果某些事情可以稍后处理，那么谁会在早上第一时间检查警报和错误？
你可以拥有各种各样的仪表盘，可以堆积通知和电子邮件，但如果没有人主动查看和处理这些错误，这一切都毫无意义。

疫情前，我们在办公室工作时，有一个巨大的屏幕显示所有仪表盘，所以如果某个指标显示红色，任何人都能注意到并大声提醒。 现在独自在家办公，每个人都能看到Slack或邮件里的感叹号或数字，但我们总是很忙，所以尽量不去理会，并且自欺欺人：

要不要我看看？算了，我估计别人已经在看了。

那么……谁应该关注这些警报？如果出现问题，谁应该进行调查并做出反应？
务必明确这一点，并做到公平公正，否则最终会导致一些问题被忽视，一些非常敬业的团队成员会因为既要完成自己的任务又要花时间处理警报（这些时间不计入估算和计划中）而精疲力竭，或者可能会出现两个（或更多）人浪费时间在同一个警报上，做着同样的调查工作。

定义操作

创建运行手册。
什么是运行手册？它是一份详细的步骤清单，列出了在发生错误或触发警报时需要采取的步骤。

• 这是什么错误？（解释并提示可能的原因）
• 它来自哪里？（链接到日志、仪表盘和代码库）
• 我应该从哪里开始调查？（指向已知存在问题的文档或代码/配置部分的链接）
• 我该如何解决这个问题？
• 如果我无法解决这个问题，我应该采取什么措施来缓解这个问题？
• 如果我想升级问题，或者如果我意识到问题不在我的职责范围内（例如，另一个部门的微服务开始崩溃，而我们的应用程序没有它就无法运行），我应该联系谁？

拥有这样一份清单非常有帮助，因为它规范了解决问题的方法，避免了团队中只有“专家”才能调查和解决问题，并让每个团队成员摆脱了在发生不好的事情时（当我们独自在办公室或家里时）不清楚该做什么的压力。

概要

• 不要忽视/低估错误处理、指标和监控的重要性。务必为此安排时间。
• 明确优先事项和职责
• 提前计划
• 不要让错误被忽视
• 保持冷静

在生产环境中，您通常如何处理告警和错误？
您使用哪些工具？有什么技巧可以分享吗？

照片由Usman Yousaf拍摄，来自Unsplash。