AI 站点可靠性工程 (SRE) Agent

2026年7月7日
| 没有评论

背景

SRE 自动化的演进：从手动干预到 Agent 驱动

在现代复杂的微服务与多云生产环境中，传统的监控手段（Monitoring）往往只能在故障发生时触发零散的告警。然而，从感知告警到确定根因（RCA）的路径依然处于“人工黑盒”状态，高度依赖工程师的手动调查。OpenSRE 的核心价值在于其通过自动化调查和结构化 RCA，填补了监控告警与故障修复之间的执行断层。

作为一名企业级 SRE 架构师，我们不仅将 OpenSRE 视为一个自动化工具，更将其定位为一个开放式强化学习（Open Reinforcement Learning）环境。它通过整合日志（Logs）、指标（Metrics）、追踪（Traces）和运行手册（Runbooks），实现了从自然语言意图到闭环事件响应的跃迁。这种架构允许企业根据自身的系统“怪癖”持续训练 Agent，从而在长期演进中实现系统可用性的战略级提升。

OpenSRE 是一个开源框架，用于构建 AI 站点可靠性工程 (SRE) Agent，能够自动排查并解决生产环境故障。当生产环境出现问题时，相关证据通常会散落在日志、指标、链路追踪、运维手册和聊天记录中——OpenSRE 将所有这些信号统一整合到一个有据可查的排查流水线中，通过跨连接系统进行推理来定位根因，并建议修复步骤。

该框架基于 ReAct (Reason → Act → Observe，即 推理 → 执行 → 观察) 的 Agent 循环构建，可连接覆盖可观测性平台、云基础设施、数据库、数据流水线、故障管理系统及 LLM 服务商的 60 多种工具。它运行在你自己的基础设施上，通过安全护栏和数据脱敏策略来恪守你的数据边界，并输出结构化的调查报告，其中包含可能的根因、经过验证的推论以及具体的修复步骤。

OpenSRE 的功能

当告警触发时——无论是来自 Datadog、Grafana、CloudWatch、Sentry、Alertmanager 还是其他任何受支持的来源——OpenSRE 都会自动执行包含五个阶段的排查工作流：

  1. 获取告警上下文，并关联来自已连接集成中的日志、指标、链路追踪和部署元数据
  2. 推理使用 ReAct 循环跨系统进行推理，调用工具、评估结果，并决定下一步的排查方向
  3. 生成结构化的调查报告，包含可能的根因、有效性评分以及分类的证据
  4. 建议提供下一步操作建议，并（可选地）通过经过授权的修改类工具执行修复操作
  5. 发布将摘要直接发送至 Slack、PagerDuty、Jira 或 Google Docs——无需切换上下文

只要工具能提供答案，Agent 就不会凭空猜测。每一项结论都链接至其背后的底层数据；对于无法证实假设，会明确标记为“未经验证的推论”。

能力

描述

结构化故障排查

跨所有已连接的信号源（日志、指标、链路追踪、事件、拓扑结构）进行关联的根因分析

感知运维手册的推理

Agent 会读取你的运维手册，并在排查过程中自动应用

预测性故障检测

在问题触发告警之前，提前捕捉正在萌芽的异常

有据可查的根因分析

每一项结论都链接到具体的工具输出——拒绝数据幻觉

极致的 LLM 灵活性

支持自带模型——兼容 Anthropic、OpenAI、Ollama、Gemini、OpenRouter、NVIDIA NIM、Bedrock、DeepSeek、Groq 等

️ 安全护栏与数据脱敏

在敏感内容抵达 LLM 之前，对其进行检测、脱敏或拦截

合成测试与 E2E 基准测试

提供带评分的根因分析套件和基于云的场景测试，持续驱动 Agent 进化

架构概述 

opensre/ ├── app/ │ ├── agent/ │ │ ├── investigation.py # 核心的 思考→调用工具→观察 循环 │ │ ├── prompt.py # 系统提示词与告警上下文构建器 │ │ ├── result.py # InvestigationResult 数据类与诊断解析器 │ │ └── correlation/ # 上游证据关联与评分 │ ├── tools/ # 60 多种工具实现与注册表 │ │ ├── base.py # 包含元数据架构的 BaseTool 抽象基类 │ │ ├── registry.py # 自动发现工具注册表 │ │ └── [ToolName]Tool/ # 每个集成工具对应一个独立目录 │ ├── guardrails/ # 敏感内容检测、脱敏与拦截 │ ├── masking/ # 数据脱敏策略与检测器 │ ├── sandbox/ # 隔离的代码执行环境 │ ├── services/ # 集成客户端 (Datadog, Grafana, AWS 等) │ ├── pipeline/ # 独立运行器 (排查、对话) │ ├── delivery/ # 报告格式化与发布 (Slack, Jira, Docs) │ ├── state/ # Agent 状态管理与证据追踪 │ ├── config.py # LLM 提供商配置、模型分层与环境变量 │ └── cli/ # 交互式 Shell、命令与配置向导 ├── docs/ # 产品文档与集成指南 ├── infra/ # Docker Compose、CI、基准测试与脚本 ├── tests/ # E2E、合成、单元与基准测试套件 └── Dockerfile # 生产环境容器构建

该管道采用了线性状态机 模式，其中每个阶段都会接收共享的 AgentState 字典，执行自身逻辑，并返回一个包含更新的字典，随后这些更新会被合并回原状态中。没有任何阶段会直接读取全局状态，所有数据都通过强类型的 AgentState 外壳进行流转。这种设计使得管道具备高度确定性、可独立测试性以及可组合性——每个阶段本质上都是一个纯函数：(state_in) → updates_dict

安全与隐私

OpenSRE 的设计充分考虑了生产环境的严苛要求。安全护栏引擎 会依据可配置的规则，对所有流入和流出 LLM 的文本进行扫描，并执行 redact（脱敏）、block（拦截）或 audit（审计）操作。数据脱敏层 (app/masking/) 提供了上下文感知检测器，能够在工具输出进入 Agent 的上下文窗口之前，剔除其中的敏感信息。

核心安全特性：

  • 结构化且可审计的 LLM 提示词 —— 拒绝隐式的提示词工程
  • 默认进行本地会话处理 —— 拒绝原始日志的静默批量导出
  • 基于工具的授权门禁 —— 修改类操作可被强制要求人工显式授权
  • 沙盒化的代码执行 —— 诊断代码通过 app/sandbox/runner.py 在隔离环境中运行
  • 可关闭的遥测采集 —— 设置 export OPENSRE_NO_TELEMETRY=1 即可禁用 PostHog 和 Sentry


生产环境部署与落地实践

弹性部署架构选择

OpenSRE 提供了适应不同企业规模的弹性部署方案：

  • 核心服务：基于 FastAPI 的高性能调查服务器，支持流式输出。
  • 接入入口：除了 CLI，还支持 opensre-mcp (Multi-Channel Platform)，这是管理远程、托管调查请求的标准接口。
  • 平台兼容性：支持 Docker 化部署，并可无缝迁移至 AWS、Railway 或 Vercel。

架构师应优先使用内置的 Makefile 基准测试工具。通过执行 make benchmark，可以针对 RDS PostgreSQL 和 EKS 的典型故障场景运行 Synthetic Test Suite，验证部署后的系统在真实负载下的 RCA 准确率。

持续改进与基准评估

实施 OpenSRE 是一个持续进化的过程。企业应建立基于 Synthetic RCA 场景的性能评分闭环，通过定量衡量 Agent 在不同故障类型下的表现，不断迭代 Prompt 模板和工具链。

总结： OpenSRE 不仅是一套工具，它是企业级 AI-SRE 的底座。通过结合状态化 Graph 架构、双向安全防护以及基于 RL 的持续评估机制，它为企业构建了一个从告警感知到 RCA 闭环的自动化流水线，是实现现代化弹性基础设施的必经之路。

文章摘自：https://www.cnblogs.com/wintersun/p/21203908

flask, python, tornado, 人工智能AI