尧图网页设计 
作者来自 Elastic Matt IssetElastic 可观测性可以自主处理三种常见故障事件它会扩展、重启或回滚工作负载然后确认服务已经恢复整个过程都由你自己的集群中的推理模型完成。每个运营团队都知道凌晨 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 KubernetesECKoperator 原生部署并由其在 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*。Gartner《可观测性平台魔力象限》2025 年 7 月 7 日。Gartner 不认可其研究出版物中描述的任何供应商、产品或服务。GARTNER 和 Magic Quadrant 是 Gartner, Inc. 和/或其关联公司的注册商标本文经许可使用。保留所有权利。原文Automated incident response on Red Hat OpenShift | Elastic Observability Labs 安心睡过凌晨 3 点的告警：在 Red Hat OpenShift 上使用 Elastic 实现自动化故障事件响应
作者来自 Elastic Matt IssetElastic 可观测性可以自主处理三种常见故障事件它会扩展、重启或回滚工作负载然后确认服务已经恢复整个过程都由你自己的集群中的推理模型完成。每个运营团队都知道凌晨 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 KubernetesECKoperator 原生部署并由其在 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*。Gartner《可观测性平台魔力象限》2025 年 7 月 7 日。Gartner 不认可其研究出版物中描述的任何供应商、产品或服务。GARTNER 和 Magic Quadrant 是 Gartner, Inc. 和/或其关联公司的注册商标本文经许可使用。保留所有权利。原文Automated incident response on Red Hat OpenShift | Elastic Observability Labs