SREGym：一个用于 AI SRE 智能体的高保真故障场景实时基准

# 具有高保真故障场景的 AI SRE 智能体实时基准测试

来源: https://arxiv.org/html/2605.07161 Yiming Su⋄∗ Saad Mohammad Rafid Pial⋄ Yifang Tian† Lily Gniedziejko⋄ Hans-Arno Jacobsen† Yinfang Chen⋄ Tianyin Xu⋄ 伊利诺伊大学厄巴纳-香槟分校⋄ 多伦多大学†

###### 摘要

AI 智能体正日益被用于诊断和缓解生产系统中的故障，这被称为智能体站点可靠性工程（Agentic Site Reliability Engineering, SRE）。当前的 SRE 基准测试局限于过于简化的 SRE 任务，且由于定制化的设计，很难进行扩展。我们提出了 SREGym，这是一个针对 SRE 智能体的高保真基准测试。SREGym 提供了一个建立在真实世界云原生系统栈之上的实时系统环境，通过故障注入器模拟高保真的故障场景。SREGym 通过模拟 (1) 不同层的广泛故障、(2) 各种环境噪声以及 (3) 多样的故障模式（如亚稳态故障和相关故障），来建模生产环境的复杂性。SREGym 被架构为一个模块化、可扩展的框架，能够跨系统栈编排故障和噪声注入器。SREGym 目前包含 90 个具有挑战性且逼真的 SRE 问题。我们使用 SREGym 评估了前沿智能体，结果表明它们在处理不同类型的故障时能力差异显著，端到端结果相差高达 40%。SREGym 作为一个开源项目正在积极维护，并已被研究人员和从业者所使用。

## 1 引言

软件生命周期远不止于编写代码，它还包括部署在生产环境中的系统的持续运行。虽然编码智能体已经改变了软件开发 [62, 1]，但加速的（vibe）编码带来了可靠性挑战：据报道，AI 生成的代码引入的缺陷比人工编写的代码多 1.7 倍 [49]，且 43% 由 AI 进行的代码变更逃避了测试并导致生产问题 [2]。如今，主要服务已经经历了由 AI 生成代码导致的生产中断 [4]。智能体 AI 的能力必须超越编写代码，扩展到缓解生产事故，即站点可靠性工程（SRE）。

SRE 需要具备与编码和一般软件工程（SWE）不同的能力。SRE 智能体必须跨多模态可观测性数据（例如，系统配置 [80, 69]、时间序列指标 [60, 42]、非结构化日志 [83, 89] 和分布式追踪 [43, 9, 66]）进行推理，与特定领域的工具交互，并执行多步缓解计划，而这些计划的后果仅在运行时可见。这些要求使 SRE 成为智能体 AI 中一个独特的挑战性领域。

> (a) 一个故障场景，其中微服务缺少发送请求所需的环境变量。
> (b) Stratus（使用 Sonnet-4.6）和 Codex（使用 GPT-5.4）在解决该问题时的智能体轨迹。

**图 1：** SREGym 中的一个 SRE 问题以及两个智能体在解决它时的轨迹。

现有的基准测试不足，落后于智能体 SRE 的发展。静态问答数据集 [47, 67] 局限于领域知识。异常检测和根因分析（RCA）的基准测试 [33, 39, 79] 仅评估 AI 是否能在静态数据集中检测和 analyzing 故障，而不能评估它们是否能解决故障。最近的努力如 AIOpsLab [14] 和 ITBench [41] 通过创建具有模拟故障的实时系统环境迈出了一步。然而，它们局限于**过于简化**的 SRE 任务。例如，它们主要关注应用层问题，而现实世界的故障根源遍布整个系统栈；操作系统 [16] 和硬件 [35, 57] 等底层故障已知更难处理。此外，它们大多在一个原本干净的环境中模拟单一故障，缺乏生产环境中共存的噪声和不相关事件 [30, 46, 37]。不幸的是，由于定制化设计（例如，在特定问题的脚本中硬编码故障模拟，且缺乏对分布式事件协调的支持），这些基准测试很难扩展。

在本文中，我们提出了 SREGym，一个针对 SRE 智能体的高保真基准测试。SREGym 遵循先前工作 [14, 41] 的高层原则，即暴露一个建立在真实世界云原生系统栈之上的**实时**系统环境，其中故障通过故障注入器进行模拟。^1^ 我们遵循经典的故障-错误-失败（Fault-Error-Failure）模型术语 [5, 44]，其中**故障**是根本原因（例如，软件 bug、硬件故障和配置错误）；故障可能导致称为**错误**的异常行为，如果处理不当，这些错误会进一步传播并表现为用户可见的**失败**。**不同之处在于**，SREGym 对动态、嘈杂且事件频发的生产环境的复杂性进行建模，以实现**高保真**故障场景，这不仅挑战 AI，还确保了问题的相关性。SREGym 目前包含 90 个逼真且具有挑战性的 SRE 问题。**图 1** 显示了一个问题及相应的智能体行为。SREGym 呈现了三个新特性：

1.  **模拟跨系统栈的广泛故障**，包括硬件故障 [35]、OS 内核故障 [16, 57]、误操作 [28, 70]，以及应用问题。
2.  **模拟各种环境噪声**，即与目标故障根本原因无关的低影响故障，它们引入歧义并可能导致分散注意力。
3.  **支持多样的故障模式**，如亚稳态行为 [10, 36, 38] 和并发、相关故障 [84, 26]，通过编排分布式事件（例如，故障和噪声）。

SREGym 被架构为一个模块化、可扩展的框架，将跨栈的故障和噪声注入器组合成高保真故障场景作为 SRE 问题。模块化和可扩展性不仅是为了工程学科实现可用性和可维护性（这对作为社区驱动的基准的 SREGym 至关重要；见附录 B），也是其作为有用基准使命的关键推动者。例如，噪声必须与目标故障一起组合，而亚稳态行为的表现需要多个相关故障和事件的时间协调。SREGym 提供了一个统一的编程接口，通过变异现有故障场景（例如，通过改变噪声）和创建新场景来策划高质量的 SRE 问题。

我们使用 SREGym 评估了一个 SRE 智能体（Stratus [13]）和两个编码智能体（Claude Code [20] 和 OpenAI Codex [21]），使用了不同的模型（包括 Sonnet-4.6、GPT-5.4 和 Kimi K2.5）。在不同智能体-模型组合中，诊断和缓解的成功率分别在 38.9%-72.6% 和 57.3%-78.5% 之间。智能体在解决应用问题上表现出强大的能力，但在根源在于其他层/模式的故障上则显著下降，端到端结果相差高达 40%。对于复合故障，智能体倾向于得出部分结论，错过了全面解决的机会。同样，智能体也以非平凡的方式受到噪声的影响。总体而言，通过用高保真故障场景挑战前沿 AI 智能体和模型，SREGym 为推进智能体 SRE 技术走向生产就绪奠定了基础。SREGym 作为一个开源项目在 https://github.com/SREGym/SREGym 上积极维护。它已被研究人员和从业者使用。

## 2 SREGym

构建高保真 SRE 基准测试具有挑战性。基准测试必须创建一个逼真的操作环境并模拟复杂的故障场景。我们在开发 SREGym 时强制执行以下设计原则（附录 B 记录了我们的工程实践）：

*   **创建嘈杂且事件频发的环境。** 一个干净、安静的环境不仅不现实，而且难以挑战 AI。然而，很少有现有基准测试对噪声进行建模。SREGym 提供受控的噪声，同时不损害可靠评估。
*   **模拟故障，而非症状。** 我们拒绝现有基准测试中常见的使用混沌工程工具创建故障症状的做法，这种症状只能通过停止工具来缓解。相反，我们专注于模拟细粒度故障。
*   **可组合性是扩展问题的关键。** SREGym 通过支持将故障和噪声编排成不同的故障场景来实现可组合性。先前的工作使用 Ansible 脚本，这些脚本难以扩展或支持需要分布式事件的故障模式。
*   **可用性和可扩展性至关重要。** 可用性/可扩展性可能不反映学术新颖性，但对基准测试的成功至关重要。SREGym 支持一键式操作，并提供用于问题扩展的 API（使用户能够贡献新问题）。

**图 2** 从组件角度概述了 SREGym。我们将在本节其余部分介绍主要组件。

> **图 2：** SREGym 框架和基准测试套件的概述。

### 2.1 问题定义：用户视角

SREGym 目前包含 90 个 SRE 问题。SREGym 中的问题在一个类似生产的实时环境中创建一个故障场景，SRE 智能体必须对其进行诊断和缓解。形式上，问题是一个四元组 $P = (\mathcal{E}, \mathcal{I}, \mathcal{F}, \mathcal{O})$，包括：

*   **系统环境 $\mathcal{E}$。** SREGym 暴露一个类似生产的环境，其中部署了用户应用、后端系统以及控制/管理服务（例如，Kubernetes 控制器）。
*   **智能体接口 $\mathcal{I}$。** 供智能体观察和与 $\mathcal{E}$ 交互的暴露工具和 API。
*   **故障和噪声 $\mathcal{F}$。** 一个或多个故障的集合 $\mathcal{F} = \{f_1, ..., f_k\}$，每个故障针对 $\mathcal{E}$ 中的特定组件。$\mathcal{F}$ 的子集可能被指定为**噪声**：瞬态、低影响的干扰，智能体必须将其与目标故障的根本原因区分开来。
*   **预言机 $\mathcal{O} = (\mathcal{O}_d, \mathcal{O}_m)$**，其中 $\mathcal{O}_d$ 是诊断预言机，$\mathmathcal{O}_m$ 是缓解预言机。

对于每个问题，评估智能体的输入和预期输出描述如下。

*   **输入。** 智能体可以通过智能体接口 $\mathcal{I}$，使用标准可观测性模式查询包含故障 $\mathcal{F}$ 的系统环境 $\mathcal{E}$。
*   **预期输出。** 智能体针对一个问题提交两次。第一次是描述故障根本原因的自然语言诊断。此提交触发 $\mathcal{O}_d$（见 §2.5）。第二次提交表示智能体已完成其缓解工作，并基于实际系统和应用状态触发 $\mathcal{O}_m$。

遵循智能体评估的最佳实践 [23, 94]，SREGym 在可能的情况下使用程序化验证以实现可靠评估。

### 2.2 系统环境

SREGym 暴露一个基于云原生的、基于 Kubernetes 的系统环境，其中应用部署在 Docker 容器中。SRE 问题根据故障场景（§2.4）选择部署哪些应用。SREGym 附带一个云原生应用目录，包括 DeathStarBench [27]、Train Ticket [93]、Astronomy Shop [56] 以及内部应用（卫星轨道模拟器和航班预订服务），并配有后端数据系统（例如，MongoDB、TiDB、Kafka、MySQL 等）。每个应用都有相应的负载（例如，用户流量）。应用和后端系统由 Kubernetes 操作员管理。应用、系统和操作员使用 Helm 包管理器 [34] 部署。建立在**事实上的**云原生栈之上，该环境具有高度可扩展性——它支持任何带有 Kubernetes 清单或 Helm 图表的真实世界云原生应用和系统，并且可以部署在任何主流硬件平台上。例如，部署商业智能体 SRE 产品 Resolve AI [64] 的自定义可观测性数据流控制器 [63] 只需一条 `kubectl` 命令。

### 2.3 智能体接口

SREGym 不对被评估智能体的架构或交互模式做任何假设，以避免智能体与基准测试之间脆弱的耦合。^2^ 基准测试为智能体暴露模型上下文协议（MCP）服务器，允许它们观察和与目标系统及其环境交互。SREGym 提供以下接口作为 MCP 服务器：

*   **Metrics**：用于通过 Prometheus [55] 查询时间序列性能指标。
*   **Logs**：用于通过 Loki [50] 搜索和过滤容器日志。