allwyn7/sre-aiops-agent

# SRE AIOps 代理 一个由 GitHub Copilot 驱动的事故响应代理，能够自动诊断生产事故、关联最近的代码变更、生成修复的 Pull Request、制作运维跑手（runbook），并从每次事故中学习——全部在 GitHub 内完成，零外部依赖。 ## 工作原理 ``` ┌─────────────────────────────────────────────────────────────────┐ │ Incident Trigger │ │ (GitHub Actions workflow_dispatch, repository_dispatch, │ │ Azure Monitor webhook, or local CLI) │ └───────────────────────────┬─────────────────────────────────────┘ │ ┌─────────────▼─────────────┐ │ Agent (Node.js) │ │ │ │ 1. Load alert + logs │ │ 2. Fetch recent PRs │ │ (skip if infra) │ │ 3. Read knowledge base │ └─────────────┬─────────────┘ │ ┌─────────────▼─────────────┐ │ GitHub Models (gpt-4o) │ │ models.inference.ai.azure │ │ │ │ • Diagnose root cause │ │ • Generate fix files │ │ • Generate SRE artifacts │ └─────────────┬─────────────┘ │ ┌─────────────▼─────────────┐ │ GitHub API │ │ │ │ • Create Issue (report) │ │ • Open fix PR (code/IaC) │ │ • Commit runbooks/rules │ │ • Update knowledge base │ └─────────────┬─────────────┘ │ ┌─────────────▼─────────────┐ (infrastructure only) │ GitHub Actions Dispatch │ │ │ │ • Trigger remediation │ │ workflow (scale K8s, │ │ rotate certs, update │ │ network policies) │ │ • Comment result on Issue │ └───────────────────────────┘ ``` ### 流水线步骤 1. **摄取（Ingest）** — 加载 `alert.json` + `logs.txt` + 最近合并的 PR 以及来自 GitHub 的责任 PR 差异（基础设施事故跳过 PR） 2. **学习（Learn）** — 读取 `knowledge-base/incidents.md`，识别过去事故中的重复模式 3. **诊断（Diagnose）** — 大语言模型关联日志、PR 差异（或基础设施信号）与历史事故，输出结构化的根因 JSON 4. **修复（Remediate）** — 大语言模型生成修复文件（Flyway 迁移、代码补丁、配置修复、功能标志切换、IaC 清单或回滚） 5. **SRE 制品（SRE Artifacts）** — 大语言模型生成跑手、Prometheus 告警规则、容量/灾备/性能优化建议 6. **报告（Report）** — 创建包含 Mermaid 时间线、严重级别、MTTR 预估、升级路径和制品链接的 GitHub 事后事故 Issue 7. **修复 PR（Fix PR）** — 打开包含生成修复文件的 PR；CI 自动验证（仅升级事故跳过） 8. **基础设施调度（Infrastructure Dispatch）** — 对于 `infrastructure_action` 类型事故：调度 GitHub Actions 工作流执行修复（扩容 K8s、轮换证书、更新网络策略） 9. **学习（Learn）** — 将事故条目追加到知识库；提交跑手、告警规则和优化建议 ## 事故场景 ### 应用类事故（责任 PR → 代码修复） | 场景 | 事故 | 严重级别 | 修复类型 | 根因 | |------|------|----------|----------|------| | `scenario-1-oom-cache` | OutOfMemoryError — 堆内存耗尽 | P1 | `code_fix` | PR #48 添加了无淘汰策略的静态 HashMap 缓存 | | `scenario-2-500-schema-drift` | HTTP 500 — Hibernate SQLGrammarException | P1 | `flyway_migration` | PR #52 移除了 JPA 字段但未生成对应的 Flyway 迁移以删除数据库列 | | `scenario-3-n-plus-one-timeout` | 请求超时 — 连接池耗尽 | P2 | `code_fix` | PR #55 将查询策略改为 EAGER，导致每次请求执行 1,205 条 SQL | | `scenario-4-xsuaa-auth` | HTTP 401/403 — XSUAA 令牌校验失败 | P1 | `config_fix` | PR #58 更新了 `xsappname` 但未重新创建服务绑定 | | `scenario-5-cap-deep-expand` | OData 超时 — HANA 连接池耗尽 | P2 | `feature_flag` | PR #62 在 CAP 的 `package.json` 中启用了 `deep_reads`，每个请求生成 300+ 条 HANA 查询 | ### 基础设施类事故（无责任 PR → IaC 修复 + 工作流调度） | 场景 | 事故 | 严重级别 | 修复类型 | 根因 | |------|------|----------|----------|------| | `scenario-6-k8s-pod-crashloop` | 容器 CrashLoopBackOff — OOMKilled | P1 | `infrastructure_action` | 流量峰值超出容器内存限制（512Mi），HPA 最大副本数为 3 | | `scenario-7-tls-cert-expiry` | HTTPS 握手失败 — 证书过期 | P1 | `infrastructure_action` | cert-manager HTTP-01 求解器配置错误，Let's Encrypt 证书未自动续期 | | `scenario-8-dns-network-policy` | 服务间 DNS 超时 | P2 | `escalation` | K8s 1.28→1.29 升级改变了网络策略语义，阻止了到 kube-system 的 DNS 出站流量 | ## 核心功能 ### 8 种修复类型 代理根据诊断选择最合适的修复策略： | 类型 | 使用时机 | 示例 | |------|----------|------| | `flyway_migration` | 数据库架构与 JPA 实体不一致 | 添加 `DROP COLUMN` 迁移 | | `code_fix` | 应用代码中引入的 Bug | 修复 N+1 查询、添加缓存淘汰 | | `config_fix` | 服务绑定或应用配置错误 | 修正 `xsappname`、更新绑定 | | `feature_flag` | 新功能标志导致影响扩大 | 设置 `cds.features.deep_reads: false` | | `pr_rollback` | P0/P1 事故，最快缓解手段是回滚 | 生成回滚到 PR 前状态的文件 | | `dependency_update` | 依赖版本存在漏洞或缺陷 | 在 `pom.xml` / `package.json` 中升级版本 | | `infrastructure_action` | 需要变更基础设施配置 | K8s 资源扩容、证书轮换、网络策略更新 — 生成 IaC PR 并调度 GitHub Actions 工作流 | | `escalation` | 需要人工或外部干预 | 云厂商工单、手动 DNS 变更、跨团队复杂协调 | ### 每次事故生成的 6 项 SRE 制品 每次运行都会生成： | 制品 | 存放位置 | |------|----------| | GitHub 事后事故 Issue（含 Mermaid 时间线、严重级别、MTTR 预估、升级路径） | GitHub Issues | | 运营跑手（detect → triage → diagnose → resolve → verify → prevent） | `knowledge-base/runbooks/` | | Prometheus / Alertmanager 告警规则 | `knowledge-base/alerting-rules/` | | 容量规划建议 | `knowledge-base/recommendations/` | | 灾备评估 | `knowledge-base/recommendations/` | | 性能调优建议 | `knowledge-base/recommendations/` | ### 知识库学习闭环 代理在每次诊断前读取历史事故，并在每次修复后追加新记录。随着时间推移，它会： - 识别重复出现的错误模式并引用之前的事故 ID - 用已知解决方案加速诊断 - 构建在团队更替中仍然存在的组织记忆 ### GitHub Copilot 聊天集成 代理可作为交互式 SRE 助理集成到 GitHub Copilot Chat 中。通过 GitHub MCP 服务器（`.vscode/mcp.json`）和代理模式提示（`.github/prompts/`），SRE 可直接从 IDE 调查并响应事故： | 命令 | 功能 | |------|------| | `@workspace /sre-diagnose scenario-6-k8s-pod-crashloop` | 交互式诊断事故 — 通过 MCP 读取告警、日志、责任 PR 和知识库 | | `@workspace /sre-status` | 实时事故仪表板 — 显示所有开启的事故、修复 PR 及其当前状态 | | `@workspace /sre-remediate scenario-2-500-schema-drift` | 触发完整代理流水线并监控修复生命周期 | | `@workspace /review-fix-pr 42` | 对修复 PR 进行 SRE 代码审查，提供合并/搁置/拒绝建议 | MCP 服务器使 Copilot 能直接访问 GitHub 问题、PR 和仓库内容——无需任何外部服务即可成为对话式 SRE 代理。 ### 自愈 CI 修复循环 如果代理生成的修复 PR 未能通过 CI，修复代理会自动介入： ``` Fix PR → CI fails → Repair Agent → Reads CI error logs + original PR files → LLM generates corrected fix → New repair PR opened (labeled aiops-repair) → Original PR closed with link → CI runs on repair PR → human reviews & merges ``` **循环保护机制：** 若修复 PR 同样未通过 CI，代理会发布评论请求人工介入，而不是无限循环。 ## 零外部依赖 代理使用 **GitHub Models**（gpt-4o）进行认证，通过标准的 `GITHUB_TOKEN` 访问 GitHub API。不需要 Anthropic 密钥、Azure 订阅或独立的 LLM 服务。 | 关注点 | 处理方式 | |--------|----------| | LLM 认证 | `GITHUB_TOKEN`（每个 Actions 运行内置） | | GitHub API | 同一 `GITHUB_TOKEN` 通过 Octokit 调用 | | 企业内网/私有部署 | 设置 `GITHUB_API_URL` 为 GHE 端点，如需使用 GitHub Models 可添加 `GITHUB_MODELS_TOKEN` | ## 快速开始 ### 选项 A — GitHub Actions（全自动） 1. 派生本仓库（必须位于 github.com 上，GitHub Models 需要 github.com 令牌） 2. 进入 **Actions → SRE AIOps – Incident Response → Run workflow** 3. 选择一个场景并点击 **Run workflow** 4. 观察 Issue 和 PR 自动生成 无需配置密钥。`GITHUB_TOKEN` 由 Actions 自动注入。 ### 选项 B — 本地运行 ``` cd agent npm ci GITHUB_TOKEN= \ GITHUB_REPO= \ INCIDENT_SCENARIO=scenario-2-500-schema-drift \ node index.js ``` 对于 GitHub Enterprise（例如 github.tools.sap），添加： ``` GITHUB_TOKEN= \ GITHUB_MODELS_TOKEN= \ GITHUB_API_URL=https://github.tools.sap/api/v3 \ GITHUB_REPO= \ INCIDENT_SCENARIO=scenario-2-500-schema-drift \ node index.js ``` ## 仓库结构 ``` .github/workflows/ incident-response.yml # workflow_dispatch trigger — runs the full agent pipeline ci.yml # validates agent-generated fix PRs (Maven build + Flyway check) repair-fix.yml # self-healing: auto-repairs failed fix PRs infra-remediation.yml # infrastructure remediation: scale K8s, rotate certs, update policies azure-monitor-trigger.yml # Azure Monitor webhook → agent pipeline agent/ index.js # orchestrator (9-step pipeline, handles app + infra incidents) repair.js # self-healing repair agent github-client.js # GitHub REST API wrapper (Octokit, GHE-compatible, workflow dispatch) llm-client.js # GitHub Models wrapper (gpt-4o, retry + JSON parsing) adapters/ azure-monitor.js # Azure Monitor Common Alert Schema → agent alert format prompts/ diagnose.txt # SAP BTP / CAP / infrastructure-aware diagnosis prompt remediate.txt # fix generation prompt (8 remediation types) sre-artifacts.txt # runbook + alerting rules + capacity/DR/perf artifacts repair.txt # CI failure analysis + corrected fix generation output/ create-issue.js # post-incident Issue with Mermaid timeline + full SRE context create-pr.js # fix PR creator (labels: aiops-generated, infrastructure) knowledge-base.js # appends runbook entry to incidents.md commit-sre-artifacts.js # commits runbook, alerting rules, recommendations dispatch-remediation.js # dispatches infra-remediation.yml workflow incidents/ scenario-1-oom-cache/ scenario-2-500-schema-drift/ scenario-3-n-plus-one-timeout/ scenario-4-xsuaa-auth/ scenario-5-cap-deep-expand/ scenario-6-k8s-pod-crashloop/ # K8s pods OOMKilled, CrashLoopBackOff scenario-7-tls-cert-expiry/ # TLS cert expired, HTTPS failures scenario-8-dns-network-policy/ # DNS blocked by network policy after upgrade knowledge-base/ incidents.md # learning loop knowledge base (seeded + auto-updated) runbooks/ # auto-generated operational runbooks alerting-rules/ # auto-generated Prometheus/Alertmanager rules recommendations/ # auto-generated capacity, DR, and performance recommendations app/ # Spring Boot bookshop microservice (demo target for scenarios 1-4) ``` ## 演示脚本 ### 第一幕 — 事故 ### 第二幕 — 代理响应 ### 第三幕 — 2 分钟内生成 6 项制品 ### 第四幕 — 学习闭环 ### 第五幕 — CAP / 功能标志场景 ### 第六幕 — 基础设施类事故（无责任 PR） ### 第七幕 — TLS 证书过期 ### 第八幕 — 网络策略 / 升级 ## 技术栈 | 层级 | 技术 | |------|------| | 代理运行时 | Node.js 20，ES 模块 | | LLM | GitHub Models — gpt-4o（`models.inference.ai.azure.com`） | | GitHub 集成 | Octokit REST（兼容 GitHub Enterprise） | | 应用 | Spring Boot 3.2.4，JDK 21（场景 1-4） | | CAP 应用 | SAP CAP Node.js，`@sap/cds` 7.x，HANA Cloud（场景 5） | | 数据库 | PostgreSQL 16 / HANA Cloud，Flyway 10.x | | CI/CD | GitHub Actions | ## 设计决策 **不依赖外部密钥。** 使用 GitHub Models 意味着同一个 `GITHUB_TOKEN` 即可完成 LLM 认证，无需额外配置、轮换或付费。 **建议而非执行。** 代理生成 PR 但不会自动合并或回滚。这符合“人工在环”原则——团队可逐步扩大自动化程度（CI 后自动合并低风险迁移，保留回滚的人工审批）。 **以 GitHub 为事实来源。** 每个事故、诊断、修复和学到的跑手都作为 GitHub 问题、PR 和 Markdown 文件保存。不需要独立仪表盘或外部知识库。 **GitHub Actions 作为基础设施编排。** 对于基础设施事故，代理调度 GitHub Actions 工作流来执行修复（扩容 K8s、轮换证书、更新网络策略）。这表明 Actions 不仅是 CI/CD，更是完整的基础设施自动化层。 **应用与基础设施采用同一流水线。** 同一代理同时处理应用 Bug（追溯到责任 PR）和基础设施故障（无责任 PR）。流水线自适应：跳过基础设施事故的 PR 上下文，使用基础设施专用诊断，生成 IaC 文件而非代码补丁，并调度修复工作流。单一工具覆盖所有 SRE 事故响应。 **设计即学习。** 过去事故持续输入诊断提示，代理在每次运行中持续改进——这是 AIOps 的核心承诺。基础设施事故与应用事故一同存入知识库，构建完整的运维记忆。

标签：AIOps, API集成, Azure 机器学习推理, Azure 监控, GitHub Actions, GitHub Copilot, GitHub Models, GNU通用公共许可证, gpt-4o, LLM 推理, MITM代理, Node.js, PR 生成, Ruby, SRE, Webhook, 云端原生, 修复自动化, 偏差过滤, 力导向图, 变更关联, 可观测性, 告警处理, 持续学习, 根因分析, 测试用例, 生产事故, 知识库, 自动化诊断, 自动笔记, 自定义脚本, 运行手册, 零外部依赖, 靶机