RedBeret/ai-ops-runbook

# AI Ops Runbook 生成器 粘贴告警或事件 —— 几秒钟内即可获得结构化的运维 Runbook。 支持 PagerDuty、Prometheus/Alertmanager、Kubernetes 事件和纯文本描述。完全在浏览器中运行。您的 API Key 保留在本地。 [](https://github.com/redberet/ai-ops-runbook/actions/workflows/ci.yml) [](https://github.com/redberet/ai-ops-runbook/actions/workflows/deploy.yml) ## 架构 ``` graph LR subgraph browser["Browser (no backend)"] IP[InputPanel\nalert text] FD[detect-format.ts\nheuristic detection] PB[prompts.ts\nsystem + user prompt] GN[generate.ts\nAnthropic SDK call] RV[RunbookView\nstructured display] ST[(Zustand store\n+ localStorage)] end IP -->|raw alert| FD FD -->|AlertFormat| PB PB -->|prompt| GN GN -->|RunbookJSON| RV GN --> ST ST -->|history| SB[Sidebar\nrunbook history] ``` ## 案例研究：凌晨 2:47 发生 Kubernetes OOMKilled **问题。** 一名待命工程师收到了 PagerDuty 告警：一个生产环境的 `payment-processor` pod 处于 `OOMKilled / CrashLoopBackOff` 状态。该 pod 在 40 分钟内崩溃了 14 次。工程师处于半梦半醒的状态，需要立刻获得一条 清晰、分优先级的调查路径。 **限制。** 该服务没有现成的 Runbook。工程师拥有 `kubectl` 日志的读取权限，但在没有第二审批人批准的情况下无法进行配置更改。 每分钟的停机都会阻碍订单处理。 **处理过程。** 工程师将 Kubernetes 事件 JSON 粘贴到 AI Ops Runbook Generator 中。该工具检测到了 `OOMKilled` 信号和 `CrashLoopBackOff` 状态，选择了 Kubernetes prompt 模板，并在约 4 秒钟内返回了一份结构化的 Runbook： ``` ## 立即分类 (0–2 分钟) 1. kubectl describe pod payment-processor-xxx -n payments 2. kubectl logs payment-processor-xxx --previous | tail -200 3. Check current memory request vs. limit: kubectl get pod -o jsonpath='{.spec.containers[0].resources}' ## 可能的原因 (已排序) 1. Memory leak in transaction batch loop (check heap growth in logs) 2. Limit set below actual working-set (compare limit to pod memory graph) 3. Upstream payload spike — unusually large batch job ## 安全操作 (只读，无需 approver) - Scale down to 1 replica to reduce crash noise while diagnosing - Export logs to incident channel ## 升级阈值 Engage DBA if logs show DB connection pool exhaustion alongside OOM. ``` 工程师遵循了分类处理步骤，发现针对经常达到 380 MB 的 working-set 设置了 400 MB 的内存限制，并带着 已经记录好的证据提交了变更请求。 **结果。** 从告警到根因定位的时间：11 分钟（在没有使用该工具的情况下，团队面对新出现的 OOM 事件的平均时间为 28 分钟）。变更请求的所有必填项 均已从 Runbook 导出中自动预填充。 所有数据均为模拟数据。 ## 快速开始 ``` bun install bun dev ``` 打开 `http://localhost:5173`，进入 Settings，添加您的 [Anthropic API key](https://console.anthropic.com/)，然后在主屏幕上粘贴告警。 **Windows:** ``` run.bat ``` ## 离线 / 内网隔离构建 该应用以静态资源包的形式发布 —— 运行时无需服务器。只需构建 一次并在私有网络中提供服务： ``` # 在连接互联网的机器上 bun install --frozen-lockfile bun run build # outputs to dist/ # 将 dist/ 传输到目标主机，然后使用任意静态服务器提供服务 npx serve dist/ # 或者：python3 -m http.server 8080 --directory dist/ ``` 运行时唯一的对外连接是访问 `https://api.anthropic.com` 用于 AI 生成。该应用本身可以从任何源提供服务。 ## 关键决策 - **无后端** —— 避免了演示工具的基础设施复杂性。API Key 存储在 `localStorage` 中，受限于源。 - **`claude-sonnet-4-6`** —— 在结构化 JSON 输出的成本和质量之间取得了适当的平衡。 - **JSON 响应契约** —— prompt 强制执行严格的 schema；解析器会剥离可能存在的 markdown 代码块标记。 - **格式检测** —— 仅使用启发式方法；检测错误时会优雅降级（回退为纯文本 prompt）。 ## 回滚 还原提交并推送到 `main` 分支 —— GitHub Actions 会在约 60 秒内自动重新部署。 ## 技术栈 TypeScript · React 19 · Vite · Tailwind CSS v4 · Zustand · Anthropic SDK · Vitest · Bun ## 贡献 请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)。 ## License MIT

标签：AI, Runbook生成, SRE, 云安全态势管理, 偏差过滤, 前端应用, 自动化代码审查, 自动化攻击, 运维