OpenSRE：记忆优先的 AI SRE 代理，让故障调查不再靠"猜"

凌晨三点，告警又响了

凌晨 3:17，P0 告警刺破寂静：支付服务错误率飙升至 23%。值班工程师从床上爬起来，SSH 连上服务器，翻日志、查监控、调接口——忙活了 40 分钟，终于定位到是上游第三方支付网关超时。但当工程师在内部群汇报"查出来了"时，同事苦笑："这个网关上周四也崩过一次，当时是另一个同事处理的……"

这几乎是每一个 on-call 工程师的真实写照：故障年年有，次次从头查。团队的知识散落在不同人的脑海里，没人能系统地记住"这个问题上次是怎么解决的"。而 OpenSRE，正是来解决这个问题的。

什么是 OpenSRE？

OpenSRE（Open Site Reliability Engineering）是一个开源的 AI SRE 代理，由开发者 Swapnil Dahiphale 创建并开源（Apache-2.0 许可）。它自动调查生产环境故障、定位根因，并在每次调查后积累记忆，让团队越用越聪明。

项目的核心理念是"记忆优先"（Memory-First）：不是每次故障都当新问题处理，而是让 AI 记住过去的调查过程和解决方案，下次遇到类似的"症状"，能直接调用记忆中的 playbook，节省大量排查时间。

从技术上看，OpenSRE 并不是一个简单的脚本，而是一个完整的多服务分布式系统，包含以下核心组件：

• sre-agent：核心 AI 代理，基于 Claude Agent SDK 构建的 LangGraph 状态机，负责接收故障事件、执行调查流程
• episodic memory（情景记忆）：每次调查结束后，将关键发现、使用的工具、最终解决方案写入 Neo4j 图数据库，供后续调查检索
• knowledge graph（知识图谱）：Neo4j 中存储服务拓扑关系，代理在调查时可以理解服务依赖链和故障扩散半径（blast radius）
• 51 个生产就绪调查技能：覆盖 Datadog、Grafana、PagerDuty、Elasticsearch、Kubernetes、AWS、Jenkins、Argo CD 等主流平台
• web console：浏览器端调查管理界面，支持查看历史调查、记忆中心、配置编辑
• Slack/Teams 机器人：可直接在 Slack 或 Microsoft Teams 中触发故障调查

用生活化的语言理解：像一个经验丰富的"老运维"

可以把 OpenSRE 想象成一个永远不会离职、记忆力超强的高级运维工程师。传统的人工 on-call 模式里，值班工程师可能对某些服务不够熟悉，遇到故障需要边查边学；但 OpenSRE 代理已经内置了 51 种工具技能，并且每次调查都会把过程记录下来。

打个比方：传统 on-call 像每次考试都让你从零复习，而 OpenSRE 像一个一直在做笔记的学霸，每次考试前都能快速复习所有重点。 当告警触发时，OpenSRE 自动启动调查，同时查询 Neo4j 中过去的记忆，找到"症状相似"的调查记录，复用其中有效的排查路径。

核心功能：故障调查的完整闭环

1. 自动故障调查

当收到告警（PagerDuty、Slack 或直接 API 调用）后，sre-agent 自动启动调查流程：分析告警上下文 → 调取相关监控数据 → 执行诊断命令 → 推理根因 → 生成报告。每次调查都有完整的执行日志，可审计、可回放。

2. 情景记忆 + 知识图谱双记忆

这是 OpenSRE 区别于普通 AI 脚本的核心差异。**情景记忆（Episodic Memory）**记录调查过程：什么时间收到了什么告警、调用了哪些工具、每步的输出是什么、最终判断是什么。**知识图谱（Knowledge Graph）**则记录服务依赖关系：支付服务依赖哪些下游服务？数据库的主从关系是什么？当某个服务故障时，哪些服务会受影响？

两者结合，OpenSRE 在调查时会自动"想起来"：这个问题之前遇到过，当时是因为 X 原因导致的，当时用了 Y 工具验证了 Z 结论。工程师不用重复劳动。

3. 51 个生产技能

覆盖主流可观测性和基础设施平台：

• 监控：Datadog、Grafana（Prometheus 数据源）
• 告警：PagerDuty、Slack（接收告警和发送通知）
• 日志：Elasticsearch、Kibana
• 基础设施：AWS（EC2、S3、CloudWatch）、Kubernetes（kubectl、Helm）
• CI/CD：Jenkins、Argo CD
• 数据库：PostgreSQL 连接检查

技能以模块化方式组织，新技能可以相对容易地添加。

4. Web 控制台

内置的 web_ui（基于 Next.js）提供：

• 调查面板：查看当前进行中的调查进度
• 记忆中心：浏览 Neo4j 中存储的历史调查记录
• 配置编辑器：管理调查规则和技能启用状态

5. Slack & Teams 集成

不离开通讯工具，直接在 Slack 群里输入 /investigate <告警描述>，OpenSRE 就会在后台启动调查并在群里实时推送进展。最终的调查报告也会直接发回 Slack 线程。这对于已经深度使用 Slack 的工程团队非常友好。

部署：本地开发快速上手

OpenSRE 提供了完整的 docker-compose 栈，make dev 一键启动全部核心服务（无需手动安装任何依赖）：

git clone https://github.com/swapnildahiphale/OpenSRE.git
cd OpenSRE
cp .env.example .env
# 编辑 .env，填入 ANTHROPIC_API_KEY
make dev

启动后访问 http://localhost:3002，粘贴终端中显示的管理员 Token 即可登录。核心服务包括：

服务	端口	说明
web-ui	3002	浏览器控制台
config-service	8080	配置管理 API
sre-agent	消息队列	调查执行引擎
Neo4j	7474/7687	图数据库
PostgreSQL	5433	元数据存储

此外，项目提供了 Kubernetes 部署配置（sre-agent/k8s/），支持在已有 K8s 集群中部署生产环境。企业用户还可以使用 LiteLLM 代理接入 OpenAI、Google Gemini 等多模型，摆脱单一模型依赖。

硬件需求

无需 GPU，因为 LLM 调用走的是 API（Anthropic Claude 或 LiteLLM 代理）。本地部署推荐配置：

• 内存：4GB+（Neo4j + PostgreSQL + Agent 运行时）
• 磁盘：2GB+（Neo4j 图数据库存储 + 日志）
• CPU：2 核以上

局限与挑战

尽管设计理念先进，OpenSRE 也有一些需要正视的问题：

1. 对外部 API 强依赖：默认使用 Anthropic Claude（claude-sonnet-4-6）作为推理模型，且需要配置 ANTHROPIC_API_KEY。如果 Claude API 不可达，整个代理将无法工作。LiteLLM 虽然提供了多模型切换能力，但配置复杂度增加。

2. 知识图谱初始录入成本：Neo4j 中的服务拓扑和依赖关系需要手动录入或通过工具自动发现，初始搭建需要一定工作量。若依赖关系数据不准确，blast radius 分析结果也会受影响。

3. 调查深度有上限：AI 代理在面对全新类型故障时，仍然可能无法准确推理根因，尤其是在告警信息不完整或上下文缺失的情况下。

4. 安全考虑：调查过程中 sre-agent 会持有一定的云平台凭证（AWS keys、Kubernetes kubeconfig），生产部署时需要严格管控权限，建议配合最小权限原则和审计日志。

5. 团队协作流程：OpenSRE 目前主要面向单人/小团队场景，在大型组织的 on-call 流程（多角色审批、SLA 追踪）方面功能较薄。

在 SRE 工具链中的定位

OpenSRE 不是 Prometheus/Grafana 的替代品，也不是 PagerDuty 的竞品。它填补的是告警响应之后、人工调查之前这段空白：

• 可观测性层（Prometheus/Grafana/Datadog）负责数据采集和告警触发
• OpenSRE 负责告警触发后的自动化调查和记忆积累
• 人工介入 保留在 OpenSRE 给出建议后，由工程师判断和执行

这种定位让 OpenSRE 天然成为一个"副驾驶"而非"自动驾驶"——AI 提供分析和建议，最终决策权仍在人。

总结

OpenSRE 是一个设计理念清晰、工程实现扎实的 AI SRE 开源项目。它用情景记忆 + 知识图谱解决了运维团队最痛的"知识流失"问题，用 LangGraph 状态机确保调查流程可控可追溯，用 51 个生产技能覆盖了主流监控平台的集成。对于已经搭建好可观测性基础设施、但 on-call 效率低的团队，OpenSRE 值得深入评估和试用。

如果你的团队正在寻找一种方式来减少重复故障排查时间、积累运维知识，OpenSRE 提供的"记忆优先"思路是一个值得参考的方向——毕竟，最好的故障修复，是不再重复修复同一个故障。