kauthamd/multi-agent-SRE-assistant

# 多智能体 SRE 助手 这是一个用于站点可靠性工程（SRE）工作流的智能体事件响应模拟器。本项目将 n8n 多智能体工作流与模拟的生产事件数据集相结合，使 AI 系统能够对告警进行分类、检查 Kubernetes 和应用程序证据、识别可能的根本原因、检索 runbook 指南，并生成具备人工审批意识的事件报告。 默认场景会调查一起生产环境的 `checkout-api` 事件，即用户在部署后遇到结账失败的情况。 ## 本项目演示的内容 - 由专门的 SRE 智能体进行的多智能体事件调查 - 跨告警、Kubernetes 状态、日志和发布历史的证据驱动型根因分析 - 基于 runbook 指导的修复建议 - 在执行影响生产环境的操作前设定明确的人工审批边界 - 提供可重用的本地数据集，用于测试和迭代智能体 SRE 工作流 ## 项目结构 ``` . |-- agentic_incident_dataset/ | |-- alerts.json | |-- application_logs.txt | |-- deployment_history.txt | |-- expected_agent_output.md | |-- incident_input.txt | |-- kubectl_describe_pod.txt | |-- kubectl_get_pods.txt | |-- recent_changes.json | |-- additional_scenarios/ | | |-- cpu_saturation_incident.txt | | |-- db_timeout_incident.txt | | `-- imagepullbackoff_incident.txt | `-- runbooks/ | |-- crashloopbackoff_runbook.md | `-- high_5xx_runbook.md `-- n8n/ `-- Agentic Incident Response System.json ``` ## 系统架构 n8n 工作流 `Agentic Incident Response System` 采用分阶段的多智能体模式： ``` flowchart TD User[Incident prompt from SRE or operator] --> Trigger[n8n Chat Trigger] Trigger --> Evidence[Incident evidence bundle] Evidence --> AlertAgent[Alert Analysis Agent] Evidence --> KubeAgent[Kubernetes Investigation Agent] Evidence --> LogAgent[Application Log Analysis Agent] AlertAgent --> Findings[Consolidated specialist findings] KubeAgent --> Findings LogAgent --> Findings Findings --> RCAAgent[Root Cause Analysis Agent] RCAAgent --> RemediationAgent[Remediation Agent] RemediationAgent -. RAG lookup .-> Runbooks[Runbook knowledge base] Runbooks -. Retrieved guidance .-> RemediationAgent RemediationAgent --> ApprovalAgent[Human Approval Boundary Agent] ApprovalAgent --> ReportAgent[Incident Report Agent] ReportAgent --> Output[Final incident report] ``` 1. **Chat Trigger** 接收事件提示词。 2. **专家智能体 (Specialist Agents)** 并行分析告警、Kubernetes 健康状况和应用程序日志。 3. **RCA 智能体** 关联专家发现并识别可能的根本原因。 4. **修复智能体 (Remediation Agent)** 使用 RAG 检索 runbook 指南并推荐安全的下一步操作。 5. **人工审批智能体 (Human Approval Agent)** 定义哪些生产操作需要审批。 6. **事件报告智能体 (Incident Report Agent)** 创建最终面向管理层的事件报告。 该工作流使用 `gpt-4o-mini` 并将 temperature 设为 `0` 以进行确定性分析。它还包含 OpenAI embeddings 和用于 runbook 检索的 Pinecone 向量存储工具。 ### 架构说明 - **n8n** 负责编排工作流，并在各智能体之间传递结构化的证据。 - **OpenAI Chat Model** 为专家智能体、根因分析、修复规划、审批边界审查以及最终报告生成提供支持。 - **修复智能体 RAG** 从 runbook 知识库中检索指南，确保建议立足于已知的标准操作程序。 - **事件数据集文件** 模拟生产环境遥测数据和运维人员产出的数据，无需直接实时访问 Kubernetes、Prometheus 或日志系统。 - **人工审批边界** 可防止系统声称或执行影响生产环境的操作，例如回滚、重启、配置更新或扩缩容。 ## 默认事件场景 使用 [agentic_incident_dataset/incident_input.txt](agentic_incident_dataset/incident_input.txt) 中的默认提示词： ``` checkout-api is failing after the latest deployment. Users are seeing 500 errors during checkout. Please investigate and recommend next steps. ``` 预期的根本原因： ``` PAYMENT_PROVIDER_URL was changed to an invalid internal endpoint during deployment checkout-api:v2.4.8, causing startup dependency validation to fail and checkout-api pods to enter CrashLoopBackOff. ``` 预期的修复方案： ``` Request human approval, then either roll back checkout-api from revision 43 to revision 42 or correct PAYMENT_PROVIDER_URL and redeploy. ``` ## 设置 ### 前置条件 - 启用了 LangChain 节点的 n8n - 在 n8n 中配置好 OpenAI 凭证 - 在 n8n 中配置好 Pinecone 凭证 - 一个用于 runbook 检索的 Pinecone index，且需与工作流配置相匹配： ``` devops-runbook-assistant ``` ### 导入 n8n 工作流 1. 打开 n8n。 2. 导入 [n8n/Agentic Incident Response System.json](n8n/Agentic%20Incident%20Response%20System.json)。 3. 确认已为以下项目分配凭证： - OpenAI Chat Model - OpenAI Embeddings - Pinecone Vector Store 4. 确认 Pinecone index 名称在您的环境中是正确的。 ### 使 n8n 能够访问数据集文件 工作流目前从以下位置读取文件： ``` /home/node/.n8n-files/agentic_incident_dataset/ ``` 将 `agentic_incident_dataset` 目录复制或挂载到您的 n8n runtime 中的该路径下。 对于基于 Docker 的 n8n 设置，请将此仓库目录挂载到 container 中，并根据需要更新文件读取节点的路径。 ## 运行演示 1. 打开导入的 n8n 工作流。 2. 启动一次 chat 执行。 3. 粘贴来自 [agentic_incident_dataset/incident_input.txt](agentic_incident_dataset/incident_input.txt) 的事件提示词。 4. 运行工作流。 5. 将最终报告与 [agentic_incident_dataset/expected_agent_output.md](agentic_incident_dataset/expected_agent_output.md) 进行对比。 最终响应应将事件归类为与部署相关的 Kubernetes 应用程序事件，引用高 5xx 错误率和 CrashLoopBackOff 证据，识别出无效的支付提供商 URL，并在回滚或配置修正前要求审批。 ## 数据集内容 默认数据集包括： - `alerts.json`：关于结账影响的 Prometheus 和 Kubernetes 告警 - `kubectl_get_pods.txt`：显示三个 `checkout-api` pod 处于 `CrashLoopBackOff` 状态的 pod 状态 - `kubectl_describe_pod.txt`：详细的 pod 证据，包括镜像 `checkout-api:v2.4.8` 和无效的 `PAYMENT_PROVIDER_URL` - `application_logs.txt`：显示支付提供商 endpoint 发生 DNS 查找失败的启动失败日志 - `deployment_history.txt`：当前版本 `43`，之前稳定的版本 `42` - `recent_changes.json`：事件发生前紧接着的部署、配置更改和 feature flag 活动 - `runbooks/`：针对 CrashLoopBackOff 和高 5xx 错误率事件的运维指南 - `additional_scenarios/`：用于测试 ImagePullBackOff、CPU 饱和和数据库超时事件的提示词 ## 扩展项目 要添加新场景： 1. 在 `agentic_incident_dataset/additional_scenarios/` 下添加一个提示词。 2. 添加或更新用于告警、Kubernetes 输出、日志、部署和近期变更的模拟证据文件。 3. 在 `agentic_incident_dataset/runbooks/` 下添加相应的 runbook。 4. 将新的 runbook 内容在 Pinecone 中建立索引。 5. 运行 n8n 工作流，并将输出与预期的调查路径进行比较。 好的场景应该包含充足的证据，使智能体能够跨至少两个独立的来源进行关联，例如告警加日志、Kubernetes 状态加部署历史，或近期变更加 runbook 指南。 ## 安全模型 本项目特意被设计为一个模拟器。工作流应给出生产操作的建议，但不应自动执行回滚、重启、扩缩容、配置更新或部署更改。 人工审批智能体 (Human Approval Agent) 必须阻止影响生产环境的操作，直到人工运维人员审查并批准该修复路径。 ## 备注 - 数据集是模拟的，但是参照真实的 SRE 事件数据资料构建的。 - 工作流文件在导入后默认处于未激活状态。 - 根据您的 n8n 部署方式，可能需要更新 n8n 工作流内部的文件路径。 - 我无法访问所提及的 ChatGPT 对话，因此本 README 是根据仓库内容和工作流配置创建的。

标签：BurpSuite集成, n8n, PyRIT, SRE, 偏差过滤, 告警分诊, 多智能体系统, 工作流自动化, 根因分析, 自动化运维