tamirdresher/squad-holmesgpt-demo

# Squad + HolmesGPT — 生产级 Kubernetes 事件响应 ## 问题 Kubernetes 事件的代价高昂。在生产环境中出现故障时： 1. 触发告警（PagerDuty、Prometheus Alertmanager 等） 2. 待命工程师收到呼叫——通常是在凌晨 3 点 3. 他们执行 `kubectl describe`、`kubectl logs`，搜索 Runbooks 和 Slack 历史记录 4. 形成假设，尝试修复，进行验证 5. （通常）撰写事件报告 步骤 2–4 平均耗时 **30–90 分钟**。这些时间大部分花在了信息收集上，而这本可以由机器完成。 **HolmesGPT** 负责自动化诊断。**Squad** 则负责打通从诊断到修复再到形成组织记忆的完整闭环。 ## 什么是 HolmesGPT？ [HolmesGPT](https://github.com/robusta-dev/holmesgpt) 是一个 CNCF Sandbox 开源 AI 工具，专为 Kubernetes 环境中的**根因分析**而设计。 ``` Alert fires │ ▼ HolmesGPT ──► kubectl describe / logs / events ──► Prometheus metrics queries ──► Runbook lookup ──► Helm release history │ ▼ "OOMKilled: memory limit 512Mi, actual usage 1.2Gi. Consider increasing limits or investigating memory leak." ``` **擅长领域：** - 自然语言查询：`holmes ask "why is my payment service crashing?"` - 告警丰富化：将 AI 诊断结果附加到 Prometheus/Alertmanager 告警中 - 原生 Kubernetes：直接从集群读取数据（除非您自行配置，否则数据不会流出） - 可插拔 LLM：支持 OpenAI、Bedrock、Azure OpenAI、Ollama **不擅长的领域：** - 修复（仅用于诊断） - 记住过往事件 - 跨多领域协同（同时处理安全性 + 性能 + 配置漂移） - 创建包含修复代码的 PR - 自动更新 Runbooks - 从解决方案中学习 ## 什么是 Squad？ Squad 是一个驻留在您代码库中的**多智能体 AI 框架**。它提供： - 具备领域专业知识的**专业 Agent**（基础设施、安全、代码等） - **协调器路由**，将合适的 Agent 分配给对应的问题 - **持久化记忆** — 决策和上下文被提交到代码仓库中 - **GitHub 集成** — 读取 issues，发起 PR，发布调查摘要 - **工作队列** — Ralph 监控进行中的事件并跟踪解决状态 可以将 Squad 视为响应 HolmesGPT 诊断结果的**专家团队**。 ## HolmesGPT vs Squad + HolmesGPT ``` ───────────────────────────────────────────────────────────────────── WITHOUT SQUAD WITH SQUAD ───────────────────────────────────────────────────────────────────── Alert fires Alert fires │ │ ▼ ▼ HolmesGPT HolmesGPT diagnoses diagnoses │ │ ▼ ▼ Engineer reads Squad Coordinator (Picard) receives diagnosis output │ │ ┌───┴────────────────────────────┐ │ │ │ ▼ ▼ ▼ Manual fix? B'Elanna (Infra) Worf (Security) reviews K8s config checks for CVEs / drift, resource limits misconfigurations │ │ ▼ ▼ Opens PR with Posts security finding limit increase as separate issue + HPA config │ │ │ └──────────┬────────────────┘ │ ▼ Data (Code Expert) checks if OOM is a code-level leak │ ▼ Creates issue with memory profiling steps │ ▼ Scribe logs decision to incident history │ ▼ Ralph marks incident resolved + updates runbook ───────────────────────────────────────────────────────────────────── Result: engineer notified Result: PR ready to merge, with diagnosis only runbook updated, issue filed, security checked — engineer just needs to approve ───────────────────────────────────────────────────────────────────── ``` ## 架构 ``` ┌─────────────────────────────────────────┐ │ Alert Sources │ │ Prometheus │ PagerDuty │ Alertmanager │ └──────────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ HolmesGPT │ │ │ │ • kubectl logs/describe/events │ │ • Prometheus queries │ │ • Helm history │ │ • Runbook lookup │ │ │ │ Output: structured diagnosis JSON │ └──────────────────┬──────────────────────┘ │ diagnosis + context ▼ ┌─────────────────────────────────────────┐ │ Squad Coordinator (Picard) │ │ │ │ • Parses HolmesGPT output │ │ • Creates GitHub issue with context │ │ • Routes to relevant specialists │ │ • Tracks resolution status │ └───────┬──────────┬──────────┬──────────┘ │ │ │ ┌────────────▼─┐ ┌─────▼──────┐ ┌▼──────────────┐ │ B'Elanna │ │ Worf │ │ Data │ │ (Infra) │ │ (Security) │ │ (Code/App) │ │ │ │ │ │ │ │ - K8s drift │ │ - CVE check│ │ - Memory leak │ │ - Resources │ │ - RBAC │ │ - App config │ │ - HPA/VPA │ │ - NetPol │ │ - Code review │ │ │ │ │ │ │ │ → Opens PR │ │ → Files │ │ → Creates │ │ with fix │ │ security │ │ issue with │ │ │ │ issue │ │ code steps │ └─────────────┘ └────────────┘ └───────────────┘ │ ┌──────────────────────▼──────────────────────────┐ │ Scribe │ │ • Logs incident to .squad/decisions/ │ │ • Updates runbook in docs/ │ │ • Creates incident report issue │ └─────────────────────────────────────────────────┘ ``` ## 演示场景：OOMKilled 的支付服务 ### 步骤 1：触发告警 ``` FIRING: KubernetesPodOOMKilled pod: payment-service-7d4b9c-xk2p namespace: production container: payment-api message: Container was OOM killed ``` ### 步骤 2：HolmesGPT 进行诊断 ``` holmes investigate alert \ --alertmanager http://alertmanager:9093 \ --alert-name KubernetesPodOOMKilled ``` 输出： ``` Root Cause: OOMKilled due to memory exhaustion - Current limit: 512Mi - Peak observed usage: 1.24Gi (from metrics over last 24h) - No memory leak pattern detected in logs (gradual growth) - Possible cause: increased load on /api/checkout endpoint (+340% traffic last 2h) - Related: Helm chart last deployed 3 days ago (no resource changes) Recommendation: Increase memory limit to 1.5Gi, add HPA rule ``` ### 步骤 3：Squad 接管 ``` GitHub Issue created by Picard: Title: [Incident] OOMKilled: payment-service (production) Body: [HolmesGPT diagnosis attached] Labels: incident, production, needs-remediation Squad routes: → B'Elanna: "Update resource limits and HPA config" → Worf: "Verify no security concerns with the deployment" → Data: "Check if checkout handler has unbounded memory use" ``` ### 步骤 4：Squad 输出结果 ``` B'Elanna opens PR: - deployment.yaml: memory limit 512Mi → 1.5Gi, request 256Mi → 512Mi - hpa.yaml: add HPA targeting 70% memory utilization - Title: "fix(infra): increase payment-service memory limits (OOM incident)" - Links to incident issue Worf comments on issue: - "No CVEs in current image, RBAC looks correct, NetworkPolicy unchanged" - "Recommend adding memory usage alert at 80% threshold" Data comments on issue: - "Reviewed checkout handler — no obvious unbounded allocation" - "Suggest profiling with pprof under load before closing" Scribe updates docs/runbooks/oomkilled.md with incident summary Ralph marks incident as "PR open, pending merge" ``` ### 步骤 5：工程师审批 工程师审查 PR（已预填充并测试），予以批准并合并。从触发告警到事件关闭，耗时 **< 15 分钟**。 ## Squad Agent 定义 (演示) 有关此演示场景中使用的 Agent 配置文件，请参见 [`.squad/agents/`](.squad/agents/)。 ## 为什么这很重要 | 指标 | 无 Squad | 有 Squad | |--------|--------------|------------| | 首次修复操作时间 | 30–90 分钟 (人工) | 3–5 分钟 (自动) | | 知识沉淀 | 通常会流失 | 提交至代码仓库 | | Runbook 更新 | 手动，常被忽略 | 自动 | | 每次事件的安全检查 | 极少 | 始终执行 | | 跨领域分析 (基础设施 + 代码 + 安全) | 需要多人协作 | 并行自动处理 | | 工程师认知负担 | 高 (告警疲劳) | 仅需审查 + 批准 | ## 与 KubeCon 演讲的关系 KubeCon 会议 "Scaling Platform Ops with AI Agents: Troubleshooting to Remediation" 探讨了： - **故障排查**（当前 AI 工具所具备的能力）与 **修复**（团队真正需要的能力）之间的差距 - 单智能体工具（如 HolmesGPT、k8sgpt）的强大之处及其在应用范围上的局限性 - 为什么**多智能体协作**是 AI 辅助平台工程的下一步发展方向 - 让 AI 修复变得安全且可审计的真实模式（基于 PR、经人工审批） 本演示是上述架构模式的具体实现。 ## 快速开始 ### 前置条件 - Kubernetes 集群（本地：kind、k3d 或 Docker Desktop） - 已安装 [HolmesGPT](https://github.com/robusta-dev/holmesgpt) - 具有仓库访问权限的 GitHub token - OpenAI 或 Azure OpenAI API key ### 尝试演示 ``` # 克隆此 repo git clone https://github.com/tamirdresher/squad-holmesgpt-demo cd squad-holmesgpt-demo # 部署 demo app（故意资源不足） kubectl apply -f demo/k8s-manifests/ # 模拟 OOM incident kubectl apply -f demo/scenarios/simulate-oom.yaml # 运行 HolmesGPT 诊断 holmes investigate pod payment-service -n production # 查看 squad 会做什么（dry-run 模式） cat demo/scenarios/squad-response-example.md ``` ## 参考 - [HolmesGPT](https://github.com/robusta-dev/holmesgpt) — CNCF Sandbox - [Robusta](https://robusta.dev) — HolmesGPT 维护者 - [k8sgpt](https://k8sgpt.ai) — 另一个 K8s AI 诊断工具 (CNCF Sandbox) - [Squad Framework](https://github.com/tamirdresher/tamresearch1) — 多智能体 AI 开发助手

标签：AI, AIOps, AI风险缓解, AutoRemediation, Black Hat, CNCF, DLL 劫持, HolmesGPT, Incident Response, LLM, Multi-Agent, PagerDuty, RCA, Squad, SRE, Unmanaged PE, web渗透, 事故响应, 人工智能, 偏差过滤, 告警富化, 告警管理, 告警诊断, 多智能体, 大语言模型, 子域名突变, 开源, 故障排查, 无线安全, 智能体框架, 根因分析, 模块化设计, 生产环境, 用户模式Hook绕过, 自动化代码审查, 自动化修复, 自动化攻击, 自动化运维, 自定义请求头, 运维自动化