prapti-jain/ai-incident-response-engineer
GitHub: prapti-jain/ai-incident-response-engineer
一个端到端的 AI 故障响应演示系统，利用 Gemini 对真实微服务遥测数据进行有证据追溯的根本原因分析和自动化事后总结。
Stars: 0 | Forks: 0
# AI 故障响应工程师
这是一个端到端的故障响应演示，它从实时微服务中摄取**真实遥测数据**——而非模拟数据——并使用 Gemini 生成**有依据的根本原因分析**和**自动化事后总结**。当异常检测标记出错误率或延迟升高时，系统会从故障窗口期提取实际的日志和指标，为每个条目分配一个稳定的 ID，并要求模型引用具体的证据。RCA 中的每一项结论都可以追溯到 Postgres 中的一行数据，使得输出结果可审计，而不是一个黑盒摘要。
**在线演示：** [仪表盘](https://ai-incident-response-engineer.vercel.app) · [遥测健康状况](https://incident-telemetry.onrender.com/health)
## 架构
```
flowchart LR
Browser --> Frontend["Next.js frontend
(Vercel)"] Frontend --> Telemetry["Telemetry service
(Render)"] Frontend --> ServiceA["service-a
(Render)"] Telemetry --> Neon["Postgres / Neon"] ServiceA --> ServiceB["service-b
(Render)"] ServiceA --> Ingest["/ingest/logs · /ingest/metrics"] ServiceB --> Ingest Ingest --> Neon Neon --> Detector["Anomaly detector"] Detector --> Incidents["incidents table"] Incidents --> RCA["Gemini RCA"] RCA --> RcaReport["incidents.rca_report"] Incidents --> Postmortem["Gemini postmortem"] Postmortem --> PmReport["incidents.postmortem"] ``` ## RCA 依据机制的工作原理 1. **证据检索** —— 当你为某个故障触发 RCA 时，遥测服务会向 Postgres 查询该故障发生时间窗口前后的日志和指标（在开始/结束时间前后留有余地）。这些条目按时间顺序排序，如果时间窗口较大，则会均匀采样至一个上限，以确保 prompt 保持有界。 2. **稳定 ID** —— 发送给 Gemini 的证据包中，每一行日志和每一个指标点都会获得一个数字 ID。Prompt 将每个条目列出为 `[id] timestamp service source …`。 3. **约束生成** —— Gemini 被指示最多提出三个排序后的根本原因，并且只能引用所提供列表中的 ID。响应将作为结构化 JSON 进行验证；任何对未知 ID 的引用都会被拒绝。 4. **关联回源行** —— 模型响应后，被引用的 ID 将被解析为原始的日志/指标行，并与 RCA 结果一起返回。UI 允许你展开每个原因并查看其背后的确切证据。 **为何这很重要：** 当被问及开放式的“出了什么问题？”时，LLM 会随意产生幻觉。提供依据强制模型将假设锚定在可观察的数据上。值班工程师（或面试官）可以通过点击查看引用的遥测数据来验证每一项声明——而不仅仅是相信一段听起来合理的文字。 ## 本地开发 **终端 1 —— 后端**（Postgres 引导、迁移、三个 FastAPI 服务）： ``` ./scripts/start.sh ``` **终端 2 —— 前端：** ``` cd frontend && npm run dev ``` 打开 [http://localhost:3000](http://localhost:3000)。如果需要覆盖 API URL，请将 `frontend/.env.local.example` 复制到 `frontend/.env.local`。 **Gemini API key**（用于 RCA 和事后总结所必需的）： ``` # services/telemetry/.env GEMINI_API_KEY=your-key-here ``` 本地 Postgres 默认使用 `postgresql://telemetry:telemetry@127.0.0.1:5432/telemetry`（通过 Docker Compose 或 Homebrew）。如有需要，可使用 `DATABASE_URL` 进行覆盖。 ## 技术栈 | 层级 | 工具 | |-------|-------| | 前端 | Next.js, Tailwind CSS, Recharts | | 后端 | FastAPI, SQLAlchemy, Alembic | | 数据库 | Postgres（生产环境使用 Neon） | | AI | 通过 `google-genai` 使用 Gemini | | 部署 | Vercel（前端）+ Render（telemetry, service-a, service-b） | 基础设施在 [`render.yaml`](render.yaml) 中为这三个后端服务进行了定义。 ## 已知限制 - **Render 免费层冷启动** —— 服务在闲置一段时间后会休眠。空闲后的首次请求可能需要 50 秒以上的时间来唤醒实例。 - **error_rate 恢复** —— 滚动窗口保留 100 个请求；在清理一次峰值以及加上 60 秒的恢复计时器后，大约需要 180 个干净的请求才能使 error_rate 恢复到基线水平。 - **事后总结质量 (v1)** —— 当证据不足时，时间线可能会比较稀疏，并且在对外共享之前，影响范围的表述可能需要人工审查。
(Vercel)"] Frontend --> Telemetry["Telemetry service
(Render)"] Frontend --> ServiceA["service-a
(Render)"] Telemetry --> Neon["Postgres / Neon"] ServiceA --> ServiceB["service-b
(Render)"] ServiceA --> Ingest["/ingest/logs · /ingest/metrics"] ServiceB --> Ingest Ingest --> Neon Neon --> Detector["Anomaly detector"] Detector --> Incidents["incidents table"] Incidents --> RCA["Gemini RCA"] RCA --> RcaReport["incidents.rca_report"] Incidents --> Postmortem["Gemini postmortem"] Postmortem --> PmReport["incidents.postmortem"] ``` ## RCA 依据机制的工作原理 1. **证据检索** —— 当你为某个故障触发 RCA 时，遥测服务会向 Postgres 查询该故障发生时间窗口前后的日志和指标（在开始/结束时间前后留有余地）。这些条目按时间顺序排序，如果时间窗口较大，则会均匀采样至一个上限，以确保 prompt 保持有界。 2. **稳定 ID** —— 发送给 Gemini 的证据包中，每一行日志和每一个指标点都会获得一个数字 ID。Prompt 将每个条目列出为 `[id] timestamp service source …`。 3. **约束生成** —— Gemini 被指示最多提出三个排序后的根本原因，并且只能引用所提供列表中的 ID。响应将作为结构化 JSON 进行验证；任何对未知 ID 的引用都会被拒绝。 4. **关联回源行** —— 模型响应后，被引用的 ID 将被解析为原始的日志/指标行，并与 RCA 结果一起返回。UI 允许你展开每个原因并查看其背后的确切证据。 **为何这很重要：** 当被问及开放式的“出了什么问题？”时，LLM 会随意产生幻觉。提供依据强制模型将假设锚定在可观察的数据上。值班工程师（或面试官）可以通过点击查看引用的遥测数据来验证每一项声明——而不仅仅是相信一段听起来合理的文字。 ## 本地开发 **终端 1 —— 后端**（Postgres 引导、迁移、三个 FastAPI 服务）： ``` ./scripts/start.sh ``` **终端 2 —— 前端：** ``` cd frontend && npm run dev ``` 打开 [http://localhost:3000](http://localhost:3000)。如果需要覆盖 API URL，请将 `frontend/.env.local.example` 复制到 `frontend/.env.local`。 **Gemini API key**（用于 RCA 和事后总结所必需的）： ``` # services/telemetry/.env GEMINI_API_KEY=your-key-here ``` 本地 Postgres 默认使用 `postgresql://telemetry:telemetry@127.0.0.1:5432/telemetry`（通过 Docker Compose 或 Homebrew）。如有需要，可使用 `DATABASE_URL` 进行覆盖。 ## 技术栈 | 层级 | 工具 | |-------|-------| | 前端 | Next.js, Tailwind CSS, Recharts | | 后端 | FastAPI, SQLAlchemy, Alembic | | 数据库 | Postgres（生产环境使用 Neon） | | AI | 通过 `google-genai` 使用 Gemini | | 部署 | Vercel（前端）+ Render（telemetry, service-a, service-b） | 基础设施在 [`render.yaml`](render.yaml) 中为这三个后端服务进行了定义。 ## 已知限制 - **Render 免费层冷启动** —— 服务在闲置一段时间后会休眠。空闲后的首次请求可能需要 50 秒以上的时间来唤醒实例。 - **error_rate 恢复** —— 滚动窗口保留 100 个请求；在清理一次峰值以及加上 60 秒的恢复计时器后，大约需要 180 个干净的请求才能使 error_rate 恢复到基线水平。 - **事后总结质量 (v1)** —— 当证据不足时，时间线可能会比较稀疏，并且在对外共享之前，影响范围的表述可能需要人工审查。
标签：AIOps, API集成, 可观测性, 智能运维, 根因分析, 自动化诊断