安心睡过凌晨 3 点的告警：在 Red Hat OpenShift 上使用 Elastic 实现自动化故障事件响应

作者：来自 Elastic Matt Isset

Elastic 可观测性可以自主处理三种常见故障事件：它会扩展、重启或回滚工作负载，然后确认服务已经恢复，整个过程都由你自己的集群中的推理模型完成。

每个运营团队都知道凌晨 3 点的告警。一项服务变慢，一个告警被触发，然后有人被叫醒，开始翻查仪表板、日志和追踪数据，以寻找能够解释服务中断的那个关键数据信号。等他们找到时，客户早已受到影响。这篇文章介绍的是一种不同的方法：自主 SRE，即由 Elastic 可观测性从检测到修复自主处理常规故障事件，而且整个过程都运行在你自己的 Red Hat OpenShift 集群中，因此，真正把人叫醒的告警将成为例外，而不是日常。这里不会介绍深入的配置，只会从高层介绍它的工作方式，以及它会如何改变那些负责运行系统的人的工作。

为什么手动故障事件响应无法在规模化环境中跟上

现代平台运行的规模，是人类大脑从未被设计用来进行分类处理的。单个服务每秒可以处理数万笔事务，而每一笔事务都会留下指标、日志和追踪数据。当出现故障时，答案就隐藏在这片数据洪流中的某个地方，但人工寻找非常缓慢，而缓慢的代价很高。AI 时代让情况变得更糟，而不是更好：数据量正在不断累积，而团队增加的工具越多，答案就越分散。

手动模式会出现三个问题：

成本和数据量不断爆炸。 遥测数据的庞大规模不断推高可观测性成本，而团队通常会丢弃数据来控制账单，这意味着当他们进行排查时，那个能够解释服务中断的关键数据信号可能根本不存在。
上下文丢失且彼此割裂。 真正的完整情况通常同时存在于容器日志、基础设施事件和应用追踪中。当这些数据位于不同的工具中时，没有任何单一平台能够在告警触发的瞬间将它们关联起来，而在压力之下手动拼接这些信息既缓慢又容易出错。
调查缓慢且决策仓促。 每花一分钟寻找原因，就意味着服务中断持续一分钟，而凌晨 3 点凭猜测做出的重启决定可能会让故障事件变得更加严重，而不是得到改善。

结果就是长时间的服务中断、压力巨大的团队，以及无论构建多少仪表板都始终居高不下的平均修复时间（MTTR）。仪表板可以向你展示问题。它们无法修复问题。

自动化故障事件响应如何端到端地工作

自主 SRE 意味着系统自主处理完整的故障事件闭环：它检测问题、调查可能的原因、通过纠正操作解决问题，然后验证操作是否有效。这与熟练的值班工程师在脑海中执行的流程相同，只不过它能够持续运行，并以机器速度执行。

它遵循一个简单的循环：检测、调查、解决、验证。

检测。 Elastic 可观测性持续收集整个环境中的指标、日志和追踪数据，并维护一个实时系统模型：一张始终保持最新的服务、主机以及它们之间依赖关系的地图。它会找出真正重要的事件，而不是用原始告警淹没团队。
调查。 当某个指标越过阈值时，平台会汇总相关证据，并向一个 AI 模型询问正在发生什么、它有多大的信心，以及这个问题还会影响哪些其他服务。该模型能够读取这些证据，并用通俗易懂的语言进行解释。
解决。 根据诊断结果执行修复步骤，例如扩展服务、重启服务或回滚最近的更改，可以自动执行，也可以在获得人员批准后执行。
验证。 然后系统会检查修复是否有效，以及服务是否恢复健康状态，并记录整个过程，以便人员能够准确查看发生了什么以及为什么这样处理。

这里最重要的词是_循环_。系统不会在告警或建议处停止。它弥合了从知道到行动之间的鸿沟，而服务中断恰恰就发生在这道鸿沟中。

Elastic 可观测性如何为 AI 根因分析关联遥测数据

自主行动的效果取决于其背后的上下文，而上下文正是 Elastic 可观测性的优势所在。它将整个环境中的指标、日志和追踪数据汇集到一个地方，然后建立一个实时模型来描述这些数据之间如何关联，因此系统能够基于完整的情况进行推理，而不是基于某一个嘈杂的数据信号进行判断。

这种统一视图之所以重要，有三个原因：

更好的诊断。 让 AI 模型基于真实且相互关联的遥测数据，而不是单个指标进行推理，意味着诊断结果能够反映实际发生的情况，而不是猜测。
更少的错误操作。 当证据完整时，系统就不太可能针对症状采取行动，却忽略真正的原因。
值得信赖的记录。 每一次观察、决策和行动都会被记录下来，因此每个故障事件都会自带完整的审计轨迹，而不是留下故事中的空白。

这与 Elastic 已经为搜索和安全提供的基础相同，只不过现在将其应用于保持服务健康。

为什么自动化故障事件响应运行在 Red Hat OpenShift 上

这种方法能够适用于受监管、主权以及本地部署环境的原因在于，整个闭环都运行在你自己的 Red Hat OpenShift 集群中。关于故障事件的一切信息，无论是遥测数据、诊断结果还是行动，都不需要离开你的环境。

四个方面让 Red Hat OpenShift 成为这一方案的理想运行环境：

完整技术栈都在集群内部。 Elastic 可观测性通过 Elastic Cloud on Kubernetes（ECK）operator 原生部署并由其在 Red Hat OpenShift 上进行管理，因此数据基础与它所监控的工作负载位于同一环境中。这能够让分析保持快速，同时让你掌控自己的数据。它既可以运行在托管的 OpenShift 上（例如 Red Hat OpenShift Service on AWS 或 Azure Red Hat OpenShift），也可以运行在自管理的 Red Hat OpenShift 上。
推理模型也在本地运行。 Red Hat OpenShift AI 在同一个集群内部提供语言模型，例如 IBM Granite。用于诊断你的故障事件的 AI 不会将你的遥测数据发送到外部服务，这使得这种方法能够适用于物理隔离和主权环境部署。
修复操作原生支持 Red Hat OpenShift。 当系统采取行动时，它执行的是普通的 Red Hat Kubernetes 操作：扩展 deployment、重启工作负载、回滚到上一个正常版本。这些都是你的平台团队已经信任的操作，只不过现在由系统自动触发并进行验证。
它是一个经过验证的打包起点。 整个方案作为快速入门方案发布在 Red Hat 目录中，由双方共同构建，因此团队可以直接在现有的 Red Hat OpenShift 环境中部署它并看到整个闭环运行，而无需从零开始组装各个组件。

最终的收益是在不做任何取舍的情况下实现主权：你可以获得机器速度、AI 驱动的故障事件响应，同时让每一个字节的遥测数据和每一个决策都留在你已经运行的基础设施内部。

从告警到经过验证的修复

下面介绍当整个闭环建立之后，一个常规故障事件如何按照团队实际体验的方式完成处理。

一项服务开始变慢。响应时间超过正常范围，触发告警，而这正是通常会让人半夜被叫醒的触发条件。不同的是，平台会立即收集相关证据：是哪项服务、最近发生了什么变化、相关的错误和事件。然后，它会将这些信息交给运行在 Red Hat OpenShift AI 上的模型，由模型返回通俗易懂的诊断结果、置信度以及_影响范围_，也就是如果放任不管，这个故障事件将影响到的其他服务集合。

如果你已经允许某项建议操作自动运行，那么系统随后会将其作为原生 Red Hat Kubernetes 操作执行；例如扩展服务以吸收负载，然后平台持续监控响应时间，直到其恢复正常。整个过程，从首次告警到确认恢复，都会被记录为一个案例：发生了什么、为什么发生、采取了什么措施，以及证明修复有效的证据。早上，团队看到的是一份已经完成的故障事件报告，而不是重新还原一次紧急故障处理过程。

工程师的工作职责从_寻找和修复_转变为_审核和改进_。这才是真正的变化。工作从被动救火转向监督。

哪些 Kubernetes 故障事件可以自动修复

自主响应在常见且容易理解的故障事件中最有价值，也就是那些令人厌烦而不是新颖的故障。每种故障都对应一个系统可以执行并随后验证的原生 Red Hat Kubernetes 操作：

发生的情况	Red Hat Kubernetes 操作	通过以下方式确认
服务在负载下变慢	扩展 deployment 以增加容量	监控响应时间恢复正常
服务耗尽内存并崩溃	正常重启工作负载	检查服务恢复健康并保持运行
最近的更改导致某些功能出现问题	回滚到上一个正常版本	确认服务再次通过健康检查

这些故障事件构成了团队收到的大多数告警，而它们恰恰是最适合通过闭环处理、从团队工作中移除的故障。新颖或高风险的故障事件仍然会交由人员处理，这是有意为之的设计。

如何保持对自动化修复的控制

自主并不意味着无人负责。原则很简单：agent 提出建议，你做决定。系统消除的是繁琐工作，而不是监督，而且通过几条规则就能确保人始终牢牢掌握控制权。

每个操作都会被记录。 从诊断到操作再到验证的完整过程，都会作为一个可供审核的案例被记录下来。任何事情都不会在记录之外发生。
置信度是决策的一部分。 修复选项会按照置信度进行排序，因此高置信度的修复可以自动执行，而低置信度的情况则会交给人员处理，而不是直接采取行动。
人类设定边界。 你决定系统可以自主执行哪些操作，以及哪些操作需要人员批准。在任何重要环节，你都可以让人员参与其中。
你的模型，在你的集群中。 推理过程运行在你自己环境中的 Red Hat OpenShift AI 上，因此敏感的遥测数据无需离开你的环境。对于受监管和主权环境而言，这意味着整个闭环，包括数据和决策，都由你掌控。

目标是构建一个能够像优秀的初级工程师一样赢得信任的系统：它会展示自己的工作过程，知道什么时候需要寻求帮助，并且绝不会隐藏自己做过什么。

自动化故障事件响应如何降低 MTTR

最直接的结果是 MTTR 降低，因为故障事件中最缓慢的部分------在有人理解问题之前所花费的时间------基本上被消除了。使用 Elastic 可观测性的团队已经用实际数据量化了这种变化：

WePay，一家 Chase 公司，将故障事件中发现客户影响所需的时间缩短了 90%，从而改善了应用性能并更快地发布产品。
DISH Media 实现了 100% 的可见性，覆盖范围提升了 10 倍，并缩短了开发人员解决问题所需的时间。
Accolade 使用 Elastic 可观测性监控约 400 项服务，并将开发人员生产力提升了一倍。

除了这些数字之外，这种变化还是结构性的：

一致性。 无论是凌晨 3 点还是下午 3 点，闭环都会以同样正确的方式进行响应。没有疲劳，也没有临时拼凑的修复方案。
能力。 工程师不再需要在夜间花时间处理常规故障事件，并可以将这些时间重新投入到只有人类才能完成的工作中。
韧性。 更快速、更一致的恢复意味着服务中断能够保持在较小范围内，而客户甚至不会注意到这种小规模的服务中断。

换句话说，自主 SRE 不仅让故障事件响应变得更快，还改变了你最优秀的人才将时间花在哪里。这也是市场正在发展的方向：Elastic 被评为 2025 年 Gartner《可观测性平台魔力象限》领导者。

如何在现有的 OpenShift 集群上开始使用

你不需要重建现有技术栈就可以开始。由于该方案作为快速入门方案发布在 Red Hat 目录中，自然的第一步是在现有的 Red Hat OpenShift 环境中进行部署，并使用 Elastic 可观测性作为跨服务的统一视图，这样良好决策所需的上下文就已经存在。从这里开始，你可以让整个闭环以建议模式运行，由它进行诊断和提出建议，同时由人员批准每个操作；随着系统在处理常规故障事件方面逐渐赢得信任，再逐步扩大其自主权限。

在 Red Hat OpenShift 上部署意味着可观测性技术栈、运行在 Red Hat OpenShift AI 上的推理模型以及修复 agent 都会在同一个集群中一起启动，因此团队可以在广泛采用之前，端到端地看到完整的检测---调查---解决---验证闭环运行起来。

首先，让系统进行监控和解释。让它提出建议。然后，再逐个故障事件地让它采取行动。迈向零接触运营的过程是渐进式的，而沿途的每一步都能为你的团队夺回如今花在凌晨 3 点告警上的时间。

常见问题

什么是自主 SRE？ 自主 SRE 是一种方法，其中可观测性平台自主处理完整的故障事件闭环：检测问题、调查可能的原因、通过纠正操作解决问题，并验证服务是否恢复。它将常规故障事件自动化，让工程师能够专注于新颖和高风险的问题。

为什么要在 Red Hat OpenShift 上运行自主 SRE？ 在 Red Hat OpenShift 上运行整个闭环，可以让完整技术栈都位于集群内部：Elastic 可观测性（通过 ECK operator 部署）、运行在 Red Hat OpenShift AI 上的推理模型，以及修复 agent 都运行在你自己的环境中。没有任何遥测数据或决策会离开集群，这使得该方案非常适合受监管、主权、物理隔离和本地部署环境。它可以运行在 Red Hat OpenShift Service on AWS、Azure Red Hat OpenShift 或自管理的 Red Hat OpenShift 上。

自主 SRE 会取代我的工程师吗？ 不会。它消除的是重复性工作和常规的凌晨 3 点告警，并将工程师的工作从寻找和修复转变为审核和改进。人类决定哪些操作可以自动执行，批准任何敏感操作，并在事后审核每个操作。

Elastic 可观测性如何决定应该做什么？ 它让 AI 模型基于真实且相互关联的遥测数据进行推理，包括来自整个环境的指标、日志和追踪数据，以及服务之间依赖关系的实时模型。模型会返回原因、置信度和影响范围，而平台只会在你设定的边界内采取行动。

让系统自动采取行动安全吗？ 每个操作都会被记录为可供审核的案例，修复选项会按照置信度进行排序，低置信度的情况会交由人员处理，而你可以选择哪些操作自动执行、哪些操作需要批准。修复步骤都是普通的 Red Hat OpenShift 操作，也就是你的平台团队已经信任的那些操作。

可以在不将我的数据发送到外部服务的情况下运行吗？ 可以。通过在你的集群内部使用 Red Hat OpenShift AI 提供推理模型，敏感的遥测数据无需离开你的基础设施。这使得该方案适用于受监管、主权和本地部署环境。

要进一步了解这一架构背后的实现，请参阅配套的 Red Hat OpenShift 集群内自主 SRE 技术栈技术演练（即将发布）。要了解 Elastic 如何支持 agentic 和 AI 驱动工作流的整体情况，请参阅 Elastic 的 Search AI Platform。

原文：Automated incident response on Red Hat OpenShift | Elastic Observability Labs