omgoswami24/incident-response

# 自主 AI 事件响应 一个闭环的 AI SRE 智能体，基于真实运行的服务进行演示： **检测 → 诊断 → 修复 → 验证 → 记录** —— 无任何预设脚本的步骤。 ## 问题所在 当生产环境出现故障时，大部分平均恢复时间（MTTR）并未花在修复 任何东西上——而是花在了*弄清楚到底发生了什么变化*。值班工程师收到 告警，盯着监控大盘，排查最近的部署，猜测 问题原因，执行回滚，然后观察图表。平均恢复时间主要被 诊断所占据，而诊断正是 LLM 擅长的 证据关联工作——*前提*是你能信任围绕它们构建的闭环。 本项目端到端地构建了这个闭环，并且——最关键的部分是—— **通过测量数据来验证 AI 的工作，而不是仅凭它的一面之词**： 1. 一个模拟的电商服务在真实环境下运行，承受持续的合成负载 （约 450 req/s），并为每个 endpoint 提供实时的 p95 延迟/错误率指标。 2. “注入故障”**实际上部署了一个错误的 commit**：它会 checkout 一个 git 历史中包含真实回归（N+1 查询、手误输错的缓存 TTL、被删除的空值检查、错误的连接池大小）的分支，这些回归被埋藏在 干扰 commit 中，随后重启服务。服务发生了真实的性能下降。 3. **异常检测器**——它从未被告知注入了故障—— 将实时指标与其在服务健康时学习到的基线进行比较， 并开启一个事件，告警文本完全由测量数据生成。 4. LLM 读取该告警以及最近约 15 次 commit（提交信息 + 完整 diff）， 并找出问题原因。注入的场景仅作为隐藏的 真实基准（ground truth）存储；**诊断结果会在 LLM 给出 最终答案后与之进行对比评分**，并且仪表盘会如实显示 ✓/✗。 5. 通过 RAG 检索操作手册（本地 Chroma 向量库），影响评估**基于 实测流量**计算得出（下降的吞吐量 × 错误/放弃率 × 平均订单金额），并在 Slack 上发布简报及建议的修复方案。 6. 在人工点击批准后，系统会**对可疑的 commit 执行 `git revert`、重新部署，并在解决问题前 监控指标是否恢复正常**。 如果诊断错误，指标将无法恢复（或者 revert 操作 无法应用），事件系统会如实报告这一点——系统无法给自己的 作业打分。 7. 根据记录的证据生成完整的复盘报告。 一个典型的事件会在仪表盘上实时运行整个闭环，耗时约 90 秒。 ## 真实与模拟的界限（诚实清单） | 组件 | 真实或模拟 | |---|---| | 目标应用 + 流量 | **真实** —— FastAPI 服务在持续闭环负载下运行；延迟/错误测量均为真实数据 | | 数据库延迟 | **模拟延迟，真实并发** —— 每次查询会在模拟的网络往返期间占用真实且固定大小的连接池中的连接，因此查询次数和连接池大小在负载下会产生真实的影响 | | 故障注入 | **真实部署** —— 对包含植入错误 commit 的分支执行 `git checkout` + 进程重启 | | 异常检测 | **真实** —— 学习到的基线与滚动时间窗口对比；它对注入的内容（或是否注入了内容）一无所知 | | Commit 诊断 | 基于 git diff 的**真实 LLM 推理**；它有可能是错误的（实际情况有时确实如此） | | 操作手册检索 | **真实向量搜索**（Chroma，本地 embeddings） | | 影响评估 | **实测的**吞吐量/延迟/错误 × 配置的业务常量（AOV） | | 修复与验证 | **真实** —— `git revert`、重新部署，并根据实时指标对照学习到的基线判断恢复情况 | | Slack / GitHub | 默认在 `Protocol` 适配器后**模拟实现**；存在真实的 API 实现，可通过环境变量进行切换 | | 事件复盘 | 根据记录的事件证据**真实生成 LLM 内容** | ## 架构 ``` ┌───────────────────────────── backend (FastAPI) ─────────────────────────────┐ │ │ │ live/traffic.py ──► ecommerce-app (child uvicorn process, :8001) │ │ 32 virtual users ▲ git checkout / revert + restart │ │ │ │ │ │ ▼ live/app_manager.py ◄──────────── pipeline/remediation │ │ live/metrics.py ▲ │ │ rolling windows, ┌──────────────────────────────┐ │ approve │ │ p95 / error rate │ pipeline/orchestrator │ │ │ │ │ │ commit_analysis (LLM+diffs) │ │ │ │ ▼ │ runbook_rag (Chroma) │ incidents API │ │ live/detector.py ────► │ impact_estimator (measured) │ ──► SSE stream ──► React │ baseline vs window, │ slack_brief (adapter) │ dashboard │ │ opens incidents │ postmortem (LLM) │ │ │ └──────────────────────────────┘ │ │ state_machine.py — every status change validated, timelined, broadcast │ └───────────────────────────────────────────────────────────────────────────────┘ ``` - `backend/app/live/` —— 运行环境：目标应用的进程管理 （部署/回滚/重置）、闭环负载生成器、滚动指标存储、 异常检测器。 - `backend/app/pipeline/` —— 智能体：诊断、RAG、影响评估、简报、 修复 + 验证、事件复盘。 - `backend/app/state_machine.py` —— 事件状态流转的单一咽喉点 （`firing → analyzing → briefed → remediating → resolved → postmortem_generated`，`closed` 作为运维人员的干预覆盖）；每次状态流转 都会写入时间线事件并通过 SSE 广播。 - `backend/app/seed/seed_ecommerce_repo.py` —— 构建目标应用的 git 仓库：健康的 `main` 分支，加上四个名称中立的 `deploy/r-*` 分支，每个 分支都在干扰 commit 中隐藏了一个真实的回归。该应用完全可以 真实运行；其性能特征正是检测器所要测量的对象。 - `backend/app/adapters/` —— 包含本地/模拟默认实现的 `GitHubAdapter` / `SlackAdapter` `Protocol`，以及真实的 API 实现 （`tests/test_adapter_conformance.py` 会对两者运行相同的测试套件）。 - `frontend/` —— React 仪表盘：实时显示各 endpoint 相对基线的走势图、 基于 SSE 的事件时间线、诊断结果 + 真实基准揭晓、修复 审批、前后对比恢复表、Slack 简报、事件复盘。 ## 环境配置 需要 Python 3.12、Node 18+ 以及 [uv](https://docs.astral.sh/uv/)。 ``` # 1. 获取免费的 Gemini API key（无需信用卡）： # https://aistudio.google.com/apikey cp .env.example .env # paste your key into GEMINI_API_KEY # 2. Backend（同时 seed 并运行目标应用和 load generator） cd backend uv venv --python 3.12 uv sync --group dev source .venv/bin/activate python -m app.seed.seed_runbooks # one-time: runbooks -> Chroma uvicorn app.main:app --port 8000 # 3. Frontend（单独的终端） cd frontend npm install npm run dev ``` 打开 http://localhost:5173。检测器需要约 1 分钟的健康流量 来学习其基线；然后选择一个故障卡片并观察： 1. 环境栏中部署的分支发生改变；指标真实发生性能下降。 2. 检测器（约 15–30 秒）基于测量的告警文本开启一个事件。 3. LLM 结合推理过程和置信度给出具体 commit；真实基准会在其旁边 揭晓（✓/✗）。 4. 批准修复操作，观察前后对比恢复表根据实时指标 填充数据，随后生成事件复盘。 `POST /api/environment/reset`（或重置按钮）将恢复到纯净的 main 分支。 ## 测试 ``` cd backend && source .venv/bin/activate && pytest tests/ -v ``` 涵盖了状态机（包括失败/覆盖路径）、带有模拟 LLM 的诊断 pipeline（包含诊断正确和错误的情况）、指标 窗口化处理、检测器违规逻辑（包括抖动防护以及 告警文本中不泄露真实基准的特性）、恢复验证，以及 适配器一致性（当存在凭证时，会自动运行真实的适配器测试）。 ## 接入真实的 Slack/GitHub ``` # .env GITHUB_ADAPTER=real GITHUB_OWNER=your-org GITHUB_REPO=your-repo GITHUB_TOKEN=ghp_... SLACK_ADAPTER=real SLACK_BOT_TOKEN=xoxb-... ``` 无需修改代码 —— pipeline 仅依赖于适配器 `Protocol`，并且 `adapters/factory.py` 会根据环境变量切换具体实现。 ## 设计说明 - **绝不直接告诉 AI 答案。** 告警文本由指标生成； 分支名称保持中立（`deploy/r-142`）；注入的场景仅存在于 用于事后评分的 `ground_truth_*` 字段中。Prompt 采用的是 标准的 RCA（根因分析）先验知识（如近因效应、对配置变更的怀疑），而不是 特定于场景的提示。 - **验证高于信任。** 只有当相同的 检测器基线表明服务已恢复时，修复才算“完成”。错误的诊断会表现为 修复失败，且清晰可见。 - **在关键环节引入人工干预（Human-in-the-loop）。** 检测、诊断和证据 收集均是自主的；而 revert 操作需要一次明确的批准。 - **完全免费运行。** 支持 Gemini 免费层级（带有模型回退链）、 本地 Chroma embeddings、SQLite，无需任何外部账号。

标签：逆向工具