您的工程团队是否正在经历警觉疲劳？ 问这8个问题

警报疲劳是处理运营和维护基础设施的工程团队的常见问题。

问题通常源于随着团队的成长和开始使用越来越复杂的更多基础设施而随意编写警报的方法。 这是很正常的——随着公司或团队的成长，可观察性文化和可靠的警报实践通常需要时间才能形成。

创建过于敏感、过于嘈杂和过于谨慎的警报很容易。 一开始，一切似乎都值得警惕，因为最好在产品的早期阶段小心并最大化生产信号。

“随着功能和基础设施的数量和复杂性的增长，改进警报通常是优先级列表中的一部分”

自然地，这种方法不能很好地扩展，但随着功能和基础设施的数量和复杂性的增长，改进警报通常是优先级列表中的一部分。 结果是为待命工程师提供了许多半有意义的警报、噪音、上下文切换和多任务处理。 在极端情况下，队友精疲力尽，警报被忽略，您的待命团队从提高服务质量转变为持续救火而没有任何有意义的影响。

像所有公司一样，Intercom 也不能幸免于这些低效率。 因此，我们设计了一个相对轻量级的流程来对抗警觉疲劳。

我们如何看待警报策略

“警报纪律”的概念是控制警报的核心。 像功能工作一样，警报和警报策略应该以一种深思熟虑的、结构化的方式来处理。 然而，与专题工作不同，这不是可以提前计划好的事情。

毕竟，您不太可能在发布新功能之前预测其运行状况和噪音。 您必须定期、有计划地监控警报，以免警报工作达到不可持续的水平。

评估团队警报时要问的 8 个问题

我们为处理频繁警报的团队引入了定期警报审查会议。 这些最初每六周的工程周期发生一次或多次，但随着警报和监视器的状态提高到更易于管理的水平，它们之间的间隔变得更大。

每个警报审查会话都以在上一期间触发的警报的有序列表开始，按触发频率排序。 我们使用 PagerDuty 平台作为我们的警报源，其分析功能为我们提供了分解警报频率和响应所需的信息。 首先审查对整体噪音贡献最大的警报（即最频繁的火灾）。

然后通过问题清单传递每个警报：

1. 警报仍然相关吗？

任何由过时或未维护的系统触发的警报都不应打扰待命工程师，应立即删除。

2. 警报是否可行？

如果随叫随到的工程师收到警报，他们是否可以立即采取措施来修复或改善根本原因？ 如果警报不可操作且无用，则应将其删除。 问题或性能下降的每周摘要可能是警报中信息的更好位置。

3. 即使不可操作，警报中的信息是否立即有用？

我们可以将警报信息分为两大类。

• 信号：这些警报警告系统运行在其极限，但并不一定意味着服务受到影响。 例如，您的一台服务器以 100% 的 CPU 运行。 如果服务仍然运行良好，是否应该花费宝贵的时间进行调查？ 毕竟，您的服务器只是以最佳的工作成本比运行！
• 症状：当客户体验受到影响时，会触发这些警报。 这里的一个例子是您的服务返回给调用者的 5XX HTTP 错误的数量。

这两个类别协同工作效果最好。 待命人员应对症状做出反应并排除故障，并将信号仅作为进一步的信息来源。

4、如果alert是可操作的，分页的，是否需要立即处理？

如果问题不需要立即处理，它不应该在半夜叫醒任何人。 在这些情况下，团队应决定在警报中显示信息的替代方法，例如，Slack 或仪表板通知，或问题跟踪机制中的打开任务。

5. 如果可行，是否有运行手册或故障排除链接？ 这些步骤是否足够清晰，团队中的任何工程师都可以遵循？

作为一名随叫随到的工程师——尤其是新工程师——最糟糕的经历之一是随着时间的推移在工程团队中积累的大量部落知识。 仅仅为了意识到你不熟悉系统的那个区域并且没有很好的记录，就跳上一个高严重性的生产事件是令人生畏的。

“使警报故障排除信息保持清晰、简单和最新，这对于减少平均缓解和从事件中恢复的时间大有帮助”

即使你有专业知识，你也可能很久以前就写过代码，以至于你记不清它应该做什么。 保持警报故障排除信息清晰、简单且最新，这对于减少缓解事件和从事件中恢复的平均时间（MTTM 和 MTTR）大有帮助。

6. 如果可行，是否有仪表板链接，是否显示所有已知的潜在原因？

仪表板是一次显示大量系统信息的好方法，这意味着工程师不必深入研究各种日志、指标和跟踪来找出问题的原因。 将数据聚合到仪表板中并提供链接作为警报的一部分，可以更快地进行故障排除。

7. 警报是否过于敏感或不够具体？ 它会从脱敏或范围变化中受益吗？

许多警报很有用，但校准错误。 它们可能太宽泛而没有每次都应该开枪，或者太具体而针对同一事件开枪多次，这只会增加噪音。

8. 最后，是否必须由人来进行修复？

在某种程度上，所有计算机代码都将人类可以做的事情自动化。 那么为什么不自动修复触发警报的问题呢？ 虽然某些棘手的警报很难自动修复，例如代码中的错误或系统中的性能问题，但自动操作可以解决许多常见问题。

如果您在 AWS 等云平台上运行并且可以预置基础设施而不必担心请求额外的硬件，则尤其如此。 例如，如果您的搜索集群中的某个节点显示出故障磁盘，为什么不自动替换它呢？ 如果服务由于流量增加而导致计算资源不足，为什么不扩大规模并添加额外的虚拟机或容器呢？ 然后可以通过非警报渠道将补救的详细信息发送给团队，以便他们可以在空闲时进行查看。

您对这些问题中的任何一个回答“否”了吗？

对这些问题中的任何一个回答“否”都会引发团队的一项高优先级任务，即需要做一些工作来改进警报——无论这意味着阻止它分页、改进故障排除步骤、自动化它，还是简单地修复底层系统问题。

该方法的关键是以定期和有计划的方式执行此操作。 它可以保持低噪音水平，让您的运营和随叫随到的工程师感到高兴和高效。 他们可以专注于提高质量和产生影响，而不是救火。

您对我们在 Intercom 的工作方式感兴趣吗？ 我们很乐意与您交谈——查看我们的开放工程职位。