摘要：警报疲劳是开发者挑战。需清理警报，基于SLO优先处理，自动化低紧急响应，并利用AI辅助。目标是确保人工处理的警报均可操作且关键，提高效率。

警报疲劳是开发者挑战。需清理警报，基于SLO优先处理，自动化低紧急响应，并利用AI辅助。目标是确保人工处理的警报均可操作且关键，提高效率。

译自：How AI Can Help IT Teams Find the Signals in Alert Noise

作者：Jennifer Riggins

伦敦 — “闪烁的灯光对我们很多人来说既是诅咒也是福音，” PagerDuty 的开发者倡导者 Mandi Walls 在这里举办的 DevOpsDays London 活动中告诉听众。

她补充说：“无论它们代表好消息还是坏消息，都无关紧要。”

如果，正如她所定义的那样，警报是“实时且需要你关注”的东西，那么我们正生活在一个警报疲劳的时代。开发者需要抵制所有打断他们工作流程的推送通知、蜂鸣声、铃声和提示音。

一定程度的救火工作是这份工作的一部分。但是，什么时候才是真正关键的需要半夜叫醒开发者？这个决定并非关乎真正的紧急情况。团队需要处理所有其他的电话、寻呼和提示。

本月在 DevOpsDays London 活动中，Walls 提供了一个框架，以确保这些负责“修复和维护客户体验”的随叫随到人员能够更高效、压力更小。这通过正确结合服务水平目标 (SLO)、自动化和机器学习 (ML) 来实现。

在一个更少的人参与生产更多代码的时代，我们有责任为我们的安全工程师、系统管理员、站点可靠性工程师 (SRE) 和随叫随到的开发人员提供最可操作的实时警报。方法如下。

理解警报疲劳的巨大风险

这种无关紧要的警报洪水让你的安全和你的员工都面临风险。

根据《OX 2025 应用程序安全基准报告》，对于普通组织而言，大约 95% 到 98% 的警报是非关键或误报。同一份报告还发现，84% 的安全专业人员表示因警报过载而精疲力尽，其中三分之一的人正在积极寻找新的工作以应对警报量。

这并非反应过度。警报疲劳是认知负荷和决策疲劳的结果。曾任职于哈佛医学院、现任职于巴伊兰大学的神经科学家 Moshe Bar 在 OX 举办的网络研讨会上表示，这从根本上改变了思维模式：“我们变得不那么有创造力，不那么喜欢探索。我们利用熟悉的模板，转而采用更简单的解决方案。”

Walls 概述的警报疲劳后果包括：

延迟响应时间

漏掉警报

忽略误报

增加压力和倦怠

更高的员工流失率

生产力下降

质量较低的事件回顾和文档

没有时间进行事后分析和反思，经验就会丢失，事件就会重演。Walls 提到了未具名的运营客户，他们可能在短时间内收到超过 100,000 条警报：“在某种程度上，你不得不宣布警报破产。那已经毫无意义了。”

警报很重要，但同样重要的是不要被非紧急警报打扰，分散你对真正优先事项的注意力。

减少和优先处理警报的策略

在一个我们拥有更多代码——以及希望有更多测试、监控和可观测性来照看它——的时代，团队必须更有条理，更有选择性地决定什么会在凌晨 2 点把他们叫醒。

听起来可能不那么有趣，但如果你的团队面临大量不可操作、不紧急的混乱警报，那么是时候优先进行清理了。Walls 警告说，这可能非常耗时。团队通常需要特意留出一个冲刺周期，专注于清理现有警报。

她继续说，从最嘈杂的警报开始，然后重新审视每个警报信号，并提问：

它是否可操作？ 我现在能做些什么吗？提供数据来促使产品经理解决它。

它是否紧急？ Walls 说，要“承认你所运行的一切并非都是 Sev-1”，它可能只是一张工单。

它是否有用？ 她说：“我们希望达到这样的程度：所有传入并提醒人类用户的警报都对客户体验至关重要。”她强调，这些客户应包括你的内部用户，无论你管理的是人力资源工具还是内部开发者平台。

Walls 说，要轻松发现“对你的业务有实际影响”的警报。“即使你只是支持内部 IT 流程，特别是如果警报来自薪资系统，这些都是你希望每个人都能正常获得报酬的事情，对吧？”

减少警报疲劳的方法：

不要在成功时发出警报。 Walls 说，几乎总是，你不需要实时知道某个东西是否正在工作——只需让它默默地工作。

不要发送不可操作的警报。 “这个东西坏了，没有解释”并不能帮助解决问题。

设置适当的紧急程度和严重程度，推迟低紧急程度的警报。 Walls 警告说：“这需要一点谦逊”，因为总会有工程师辛勤工作却不受欢迎的功能。

删除或暂停失效的警报。 监控工具和生产环境之间可能存在一些延迟。关闭那些不是最新或长期失效的警报。

人工智能可以帮助识别哪些警报可以降低优先级，因为它非常擅长识别不同类型警报的模式和类别。

如何将警报策略建立在 SLOs 基础上

Walls 接下来指出，警报策略应与SLO挂钩。SLO 总是具体且可衡量的性能目标，但与服务水平协议 (SLA) 不同，它仍然是内部关注的焦点。

将你的 SLO 与你的生产指标挂钩，将它们根植于对你的外部和内部用户重要的一切。一旦设定了目标，以一种能帮助产品经理优先处理频繁出现问题的功能、错误修复或更新的方式，将它们传达给产品经理。

Walls 举了一个例子：“用户非常喜欢这个组件。我们如何确保这个组件始终达到他们期望的效果？”

她认为，SLO 让你有能力对每一个错误事件提出疑问：它是否值得实时通知人类？

Walls 说：“我们希望有一些回旋余地。我们希望对在特定时间段内有多少警报代表一个真正的问题，以及有多少警报只是因为互联网今天就是互联网，监控和服务本身之间存在一些奇怪之处，抱有一定程度的容忍。”

“我们希望达到一个境界，即我们确信当警报通知人类时，存在一个需要修复的真正问题，而 SLO 将帮助我们实现这一点。”

务必为你的 SLO 计算一个错误预算——Walls 建议通常在容忍范围内的时间占 95%。这使得你的随叫随到团队在 5% 的时间里，当事情飙升但并非真正的紧急情况时（至少目前还没有），可以保持待命状态。她还建议，你可以通过根据错误预算添加阈值来改变警报的数量。

她说，这种做法也为你在用户如何使用功能的暂存阶段的不可预测性留下了回旋余地。这 5% 的时间让你有机会监控和观察他们将如何使用它。

因此，SLO 的总体目标是减少她所称的“意外情况”的警报数量，这些情况没有达到容忍阈值，这样你只会收到目前真正重要的警报。

识别何时以及如何自动化警报响应

Walls 表示，PagerDuty 提醒人类的警报中，大约 20% 到 23% 在五分钟内得到解决。这意味着近四分之一的警报不需要深入分类或特殊处理。随叫随到的人员已经了解警报内容，甚至没有从修复中学习。

Walls 说：“人类在五分钟内解决问题意味着浪费了人们的时间。”因此，她表示，此类警报是自动化的理想目标；它们往往是架构中你从未有时间修复或现代化的警报。

她说：“我们希望达到这样的境界：我们可以要求机器为我们做这件事。我们希望[解决方案]由警报触发，这样人类就不必知道了。”

你可以根据参数为 AI 代理分配一个指标：例如，它每周重启三到四次是可以接受的。但你肯定不希望它重启 300 次。

Walls 说，在复杂的分布式环境中，我们可以编写这种自动化程序，让人类介入处理与新颖警报相关的常见问题。例如，如果自动化未能奏效，那么就提示人类工程师找出失败的原因。这随后就成了工程师的一个可操作警报，从而阻止 AI 代理持续重复错误。

Walls 说，一个很棒的 AI 用例是利用自动化来预生成信息和遥测数据，以加快响应时间。这可以是预先填充 Slack 频道，其中包含指向仪表板和日志中显示的数据的链接。她提醒说，要小心，这些不应该只是创建更多警报，而不是帮助更快地补救它们。

SREs 今天实际的 AI 用例

根据 DarkTrace 的 2025 年报告，大约三分之二的首席信息安全官 (CISO) 计划在明年内为其安全堆栈添加 AI 驱动的功能。那么 AI 目前在哪里发挥作用？

Astronomer 工程副总裁 Dave O’Connor 告诉 The New Stack：“SRE 领域的 AI 过度关注事件响应，这很无聊。不要更快地救火。”相反，他说，要致力于信号，以预防未来的事件。

他说，你可以要求 AI“分析我们六到十二个月的事件，并告诉我哪里做错了。使用这些极其强大的分析工具。它们在发现模式方面比人类好得多。”

SRE 和其他安全工程师有很多“搁浅的知识”——例如 Prometheus 的工作原理——O’Connor 还建议将其输入到带有聊天机器人覆盖的知识库中。

这以及其他 AI SRE 用例需要有意识的数据共享和清理。

Walls 说：“我需要知道它们是否都与特定的问题或一组问题相关，”这使得智能警报分组成为早期 AI SRE 的绝佳用例。

她警告说，问题是“警报通常很糟糕，所以输入垃圾/输出垃圾”。

此外，警报通常由不同平台上的不同团队拥有，甚至可能在不同的云中。SRE 团队将受益于清理警报消息，甚至在将其输入大型语言模型 (LLM) 之前手动将它们分组。这包括语言以及服务和已部署资产的命名标准化。

Walls 说：“当你拥有这些工具时，它们功能强大得令人难以置信。但你必须确保你的数据经过对齐，才能真正为你所用。”

与 O’Connor 提出的知识倾倒和转移建议类似，Walls 也指出：“在系统上工作的人可能确切地知道系统如何配置以及它们之间如何通信，他们对系统图有一个心智模型，[显示] AI 模型知道什么和不知道什么。”

你需要与那些在这些系统上工作的人合作，他们可以帮助将心智模型转化为 AI 可以理解的内容。

对所有科技组织来说，关注有意义、重要且当下需要人工响应的事情是有益的。你还希望每个到达人工响应者的警报都是可操作的，并且重复警报很少。

考虑到这一点，Walls 制定了一份 SRE 清单：

清理警报。

通过 SLOs 关注你的用户，并根据这些指标优先处理警报。

通过自动化将垃圾信息从人工工作流程中清除。

训练机器成为高效的队友。

这一切听起来都很昂贵吗？

正如 Walls 所说，“漏掉警报，导致更长的事件，出现更多的停机或故障，降低整体客户体验，这些也都是昂贵的。”

来源：晓加科技论