Veror245/Autonomous-Incident-Response-System

# 自主事件响应系统 一个由 AI 辅助的多智能体站点可靠性工程 (SRE) 平台，能够对事件进行分诊，使用工具验证根本原因假设，执行修复（在安全的情况下），必要时上报给人工，并生成事后报告。 该系统结合了： - **FastAPI** 后端，用于流式传输事件执行 - **LangGraph** 工作流编排，用于自主决策循环 - **Streamlit** 运维仪表板，用于实时可观察性和人机协同 (HITL) - **SQLite + ChromaDB** 记忆层，用于操作历史和检索增强上下文 - **n8n + Telegram bot 集成**，用于外部自动化、警报接收和事件通知 ## 目录 - [为什么做这个项目](#why-this-project) - [核心功能](#core-capabilities) - [系统架构](#system-architecture) - [工作流生命周期](#workflow-lifecycle) - [技术栈](#tech-stack) - [项目结构](#project-structure) - [快速开始](#getting-started) - [配置](#configuration) - [运行系统](#running-the-system) - [Telegram 集成](#telegram-integration) - [API 参考](#api-reference) - [人机协同流程](#human-in-the-loop-flow) - [数据与记忆模型](#data-and-memory-model) - [截图占位符](#screenshot-placeholders) - [故障排除](#troubleshooting) - [安全说明](#security-notes) - [路线图构想](#roadmap-ideas) - [许可证](#license) ## 为什么做这个项目 现代事件往往伴随大量噪音、高压，且分诊缓慢会导致高昂成本。本平台为自主事件处理提供了一个内置安全护栏的实用蓝图： - 快速接收和分类原始警报 - 基于工具的验证，而非仅凭猜测推理 - 暂停/恢复以进行人工审批的上报机制 - 执行追踪流式传输，提供运维可见性 - 持久化事件记忆以改善未来响应 ## 核心功能 - **自主事件分诊** - 根据组件和严重程度 (`P0`-`P3`) 对传入事件进行分类 - 生成结构化假设以供调查 - **RAG 辅助的历史记忆查找** - 在决定下一步操作之前，从 ChromaDB 搜索过往事件报告 - 鼓励复用已知有效的修复方案 - **带有实时工具的验证循环** - 动态选择诊断工具（例如，DB 连接池检查、支付延迟检查） - 遍历假设进行迭代，直到一个被验证或全部被拒绝 - **自动化修复操作** - 选择并调用修复工具（例如，扩展 DB 连接、回滚部署、清除缓存） - 捕获执行细节以供事后追踪 - **人机协同 (HITL) 上报** - 当置信度低、假设耗尽或事件严重程度需要审批时，中断图执行 - 支持在人工覆盖决策后恢复流程 - **实时运维 UI** - 在 Streamlit 中流式传输事件更新和日志 - 实时状态卡片、节点进度、中断 payload 渲染、最终报告视图 - **事件报告和长期记忆** - 自动生成 markdown 事后报告 - 将事件、假设、操作、追踪持久化到 SQLite - 将报告 embeddings 存储在 ChromaDB 中以供未来检索 - **外部自动化钩子** - 通过 webhook 将中断/报告 payload 发送到 n8n 以进行通知/工作流处理 - **Telegram 群组操作** - 支持在群组中使用 `/alert <事件详情>` 从 Telegram 接收事件 - 通过 bot 工作流自动将生成的 incident 报告回传至 Telegram 群组 - 支持 Telegram 中的 HITL 审批，响应人员可在其中批准/拒绝修复并恢复工作流执行 ## 系统架构 ``` UI/API Alert or Telegram /alert -> FastAPI /investigate -> LangGraph Workflow -> Triage -> Verifier (loop) -> Action (if verified) -> Escalation (if needed) -> Report -> Stream events to UI + webhook -> Persist to SQLite + ChromaDB Report/Interrupt Webhook -> n8n -> Telegram Bot -> Telegram Group Telegram Approve/Reject Action -> n8n -> POST /api/v1/resume/{thread_id} ``` 图表渲染可在 `graph.png` 中查看。 ## 工作流生命周期 1. **事件接收** - 客户端直接 (UI/API) 或通过 n8n 桥接的 Telegram `/alert` 流程将 `raw_incident` 发送到 `POST /api/v1/investigate`。 2. **分诊** - 分类组件和严重程度；查询历史记忆；生成假设。 3. **验证循环** - 使用选定的诊断工具测试每个假设。 4. **决策分支** - 已验证的假设 -> 修复操作。 - 无已验证假设 / 低置信度 / 触发护栏 -> 上报。 5. **HITL（如果被中断）** - 人工在 UI 或 Telegram 中审查 payload，并通过 `POST /api/v1/resume/{thread_id}` 恢复。 6. **报告 + 持久化** - 生成最终 markdown 报告，存储完整的事件生命周期，并可通过 webhook 自动化将报告内容发送到 Telegram 群组。 ## 技术栈 - **后端**：FastAPI, Pydantic, LangGraph, LangChain - **前端**：Streamlit - **LLM 集成**：兼容 OpenAI 的 endpoint + Ollama 模型 - **记忆**： - 关系型：通过 SQLAlchemy 使用 SQLite (`sre_memory.db`) - 向量型：使用 Ollama embeddings 的 ChromaDB (`chroma_data/`) - **自动化**：n8n webhook 回调 - **消息传递**：Telegram Bot API（通常通过 n8n 工作流编排） - **容器化**：Docker, Docker Compose - **包/运行时工具**：`uv` (Python 依赖/运行时管理器) ## 项目结构 ``` backend/ api/main.py # FastAPI app, streaming endpoints, webhook dispatch graph/graph.py # LangGraph construction and routing graph/state.py # Shared workflow state schema graph/nodes/ # Triage, Verify, Action, Escalation, Report nodes tools/sre_tools.py # Diagnostic/action tools + RAG search tool core/models.py # SQLAlchemy data model core/schema.py # Pydantic schemas (hypothesis/action) utils/database.py # SQLite initialization/session management frontend/ app.py # Streamlit control panel with live stream handling docker-compose.yml # n8n + backend + frontend orchestration bot_test.py # Test webhook payload sender (useful for n8n/Telegram flow testing) graph.png # Workflow graph artifact sre_memory.db # SQLite memory store chroma_data/ # Chroma vector store persistence ``` ## 快速开始 ### 前置条件 - Python 3.13+ - Docker + Docker Compose（用于容器化运行） - 后端/报告工具可访问的 Ollama endpoint - n8n（如果使用 webhook 自动化路径） ### 选项 A：Docker（推荐） ``` cd "C:\Users\asus\PycharmProjects\Autonomous-Incident-Response-System" docker compose up --build ``` 暴露的服务： - 前端：`http://localhost:8501` - 后端 API：`http://localhost:8000` - n8n：`http://localhost:5678` ### 选项 B：本地开发（不使用 Docker） ``` cd "C:\Users\asus\PycharmProjects\Autonomous-Incident-Response-System" uv sync uv run fastapi run backend/api/main.py ``` 在另一个终端中： ``` cd "C:\Users\asus\PycharmProjects\Autonomous-Incident-Response-System" uv run streamlit run frontend/app.py ``` ## 配置 在项目根目录创建一个 `.env` 文件。应用程序使用的示例变量名： ``` OLLAMA_API_KEY= N8N_WEBHOOK_URL= ``` ### 环境变量 | 变量 | 用途 | |---|---| | `OLLAMA_API_KEY` | 图节点用于兼容 OpenAI 调用的 API 密钥 | | `N8N_WEBHOOK_URL` | 用于异步中断/报告 webhook payload 的 endpoint | 如果您通过 n8n 将事件路由到 Telegram，则 bot 特定的值（例如，bot token 和目标群组/聊天 ID）通常在 n8n 凭据/工作流变量中配置，而不是在此后端中。 ## 运行系统 1. 启动后端和前端（Docker 或本地）。 2. 打开 `http://localhost:8501`。 3. 将原始事件警报粘贴到输入区域。 4. 点击 **开始调查**。 5. 观察实时节点日志和状态更新。 6. 如果被中断，提交人工决策并恢复。 7. 查看生成的事后报告。 替代接收路径： - 在您配置的 Telegram 群组中发送 `/alert <事件详情>`，以通过 n8n 触发相同的调查流程。 自动化消息传递路径： - 中断事件和最终报告可由 n8n 通过 bot 转发到您的 Telegram 群组。 ## Telegram 集成 本项目通过 webhook 自动化支持 Telegram 辅助操作： - **入站 (Telegram -> 系统)** - 在 Telegram 群组中，运维人员发送 `/alert <事件详情>`。 - 您的 n8n Telegram 触发器解析消息并使用 `raw_incident` 调用 `POST /api/v1/investigate`。 - **出站 (系统 -> Telegram)** - 后端将 `interrupt` 和 `report` webhook payload 发送到 `N8N_WEBHOOK_URL`。 - n8n 将这些 payload 转发到 Telegram，以便群组接收实时更新和最终报告。 - **来自 Telegram 的 HITL 审批** - 中断 payload 包含调查上下文和 `thread_id`。 - 在 Telegram 中，响应人员可以对建议的修复选择 **批准** 或 **拒绝**。 - n8n 将选择映射为 API 语义并调用 `POST /api/v1/resume/{thread_id}`： - `批准` -> `decision: "override"` - `拒绝` -> `decision: "ignore"` - **推荐的 n8n 映射** - `/alert` 文本 -> `raw_incident` - `report.content` -> 格式化的 Telegram 消息 - `interrupt.payload` -> 面向响应人员的审批提示消息 - Telegram 动作回调 -> 用于恢复 API 调用的 `decision` + `thread_id` ## API 参考 ### `POST /api/v1/investigate` 启动新的事件工作流并流式传输 Server-Sent Events。 请求体： ``` { "raw_incident": "DATADOG ALERT: Database connection pool exhausted..." } ``` 响应： - `text/event-stream` - header `X-Thread-ID: INC-XXXXXXXX` ### `POST /api/v1/resume/{thread_id}` 在人工决策后恢复暂停的调查。 可以从 Streamlit UI 或当群组响应人员批准/拒绝修复时由 n8n Telegram 动作工作流调用此 endpoint。 请求体： ``` { "decision": "override", "action_type": "restart_service", "target": "api-server" } ``` ### `GET /` 基本健康检查式的根响应。 ## 人机协同流程 在以下情况下会触发上报： - 没有假设得到验证 - 置信度/验证路径表明信任度低 - 严重程度护栏需要明确批准（例如，`P0`） 在上报期间： - 后端向前端发送中断事件 - 后端可以将中断 payload（包括 `thread_id`）转发到 n8n webhook - 运维人员提交覆盖/忽略决策 - 图从中断点恢复执行 Telegram 辅助的 HITL 选项： - n8n 在 Telegram 群组中发布带有操作按钮的审批消息 - 批准/拒绝操作触发 `POST /api/v1/resume/{thread_id}` - n8n 将 Telegram 动作映射为 `override`/`ignore` 决策 payload ## 数据与记忆模型 平台在两个层中持久化事件上下文： - **SQLite (`sre_memory.db`)** - `incidents` - `hypotheses` - `actions` - `traces` - `past_incidents` - **ChromaDB (`chroma_data/`)** - 将最终报告嵌入到 `sre_runbooks` 集合中 - 在未来的分诊中启用语义相似性检索 ## 截图 ### 1) 仪表板概览  ### 2) 实时调查流  ### 3) 人工干预提示  ### 4) 最终事后报告  ### 5) 执行图  ## 故障排除 - **后端无法访问模型 endpoint** - 验证 Ollama/兼容 OpenAI 的 URL 可访问性和凭据。 - **前端无法连接到后端** - 确保 `API_URL` 指向后端，并且端口 `8000` 可达。 - **n8n 中无 webhook 事件** - 检查 `N8N_WEBHOOK_URL`、隧道可见性（如果使用 ngrok）以及 n8n 工作流状态。 - **Telegram 群组未收到报告消息** - 验证 n8n Telegram 节点凭据、bot 在群组中的成员/管理员权限，以及正确的群组/聊天 ID 映射。 - **UI 侧边栏中图图片不可见** - 确认 `graph.png` 存在并已在 Docker 中挂载 (`/app/graph.png`)。 - **记忆检索结果为空** - 验证 `chroma_data/` 持久化情况，并确认报告正在被生成/embedded。 ## 安全说明 - 仅将密钥存储在 `.env` 或安全的密钥管理器中；切勿硬编码凭据。 - 如果之前提交过任何密钥，请立即轮换它们。 - 在生产部署之前，限制 CORS 源并加强 webhook 暴露的安全性。 - 在连接到真实基础设施操作之前，请将模拟修复工具视为占位符。 ## 路线图构想 - 为 HITL 操作添加身份验证和基于角色的审批 - 用生产安全且经过审计的集成替换模拟工具 - 在前端添加事件时间轴视图和搜索功能 - 引入针对节点行为和 API 流式传输的自动化测试 - 添加针对代码 lint、类型检查和安全扫描的 CI 检查 ## 许可证 本项目根据 MIT 许可授权。有关详细信息，请参见 `LICENSE`。

标签：AI, AIOps, AIR, AI工作流, AI风险缓解, AV绕过, Black Hat, ChromaDB, DLL 劫持, FastAPI, HITL, Human-in-the-Loop, IT运维, Kubernetes, LangGraph, LLM, Multi-Agent, n8n, Post-mortem, PyRIT, Python, RAG, RCA, SecOps, Socks5代理, SQLite, SRE, Streamlit, Telegram Bot, Unmanaged PE, Workflow Orchestration, 事件分类, 事件管理, 事后总结报告, 云安全架构, 互联网扫描, 人工智能, 人机协同, 偏差过滤, 可视化仪表盘, 告警分诊, 多智能体系统, 大语言模型, 安全运营, 工作流编排, 开源框架, 扫描框架, 报警处理, 持续部署, 持续集成, 故障排查, 无后门, 智能告警, 智能运维, 机器人集成, 根因分析, 检索增强生成, 模块化设计, 版权保护, 用户模式Hook绕过, 站点可靠性工程, 自主事件响应, 自动修复, 自动化代码审查, 自动化修复, 访问控制, 请求拦截, 运维自动化, 逆向工具