运维篇 · 05 · AI 辅助运维
本章目标
把 AI（Claude）嵌入运维日常，缩短 MTTR、降低人肉分析量。
一、AI 在运维侧的 8 个嵌入点
| # | 场景 | 痛点 | AI 价值 |
|---|---|---|---|
| 1 | 日志分析 | 海量日志找异常 | 识别异常模式 + 聚类错误 |
| 2 | 告警归因 | 多条告警找根因 | 聚合相关告警 + 推断根因 |
| 3 | 故障诊断辅助 | 翻文档、翻日志累 | 问答式交互 + 推理步骤 |
| 4 | Runbook 生成 | 新人难上手 | 根据历史故障生成 runbook |
| 5 | 复盘报告撰写 | 写作耗时 | 基于时间线 + 日志生成初稿 |
| 6 | 容量预测 | 手工算资源难 | 基于历史趋势预测未来 |
| 7 | 混沌演练设计 | 不知道该测什么 | 基于拓扑生成演练场景 |
| 8 | 配置审计 | 配置漂移难发现 | 对比多环境配置找异常 |
二、核心 Prompt 模板
2.1 日志异常分析
分析以下日志，找出异常模式。
## 日志时间范围
[开始时间] - [结束时间]
## 日志内容
[粘贴 100-1000 行日志]
## 任务
1. **聚类错误**：把相似的错误归类,统计每类出现次数
2. **时间分析**：标出错误突增的时间点
3. **关联分析**：是否存在错误链（A 错 → B 错）
4. **优先级**：按"紧急度 × 频率"排序
## 输出格式
### 核心发现
- 发现 1: [简述] | 次数: N | 首次出现: HH:MM | 最后出现: HH:MM
### 时间线
[关键事件时间点]
### 建议优先级
1. 立即处理：...
2. 尽快处理：...
3. 可延后：...
### 需要进一步调查的线索
- ...
2.2 告警归因
以下是最近 10 分钟触发的所有告警。帮我：
1. **聚合相关告警**（可能是同一问题引起）
2. **推断最可能的根因**
3. **建议排查顺序**
## 告警列表
| 时间 | 告警名 | 服务 | 值 |
|------|-------|------|-----|
| 10:30 | HighErrorRate | order-service | 2.5% |
| 10:31 | HighLatency | order-service | P99=1.2s |
| 10:32 | DBConnectionPoolHigh | order-service | 95% |
| 10:32 | HighQueueLength | mq | 50000 |
| ...
## 服务拓扑
[描述服务间依赖]
## 输出
1. 推测根因（3 个最可能的，按概率排）
2. 验证每个根因的方法
3. 建议的处置优先级
2.3 故障诊断对话
我正在处理一个 SEV-2 故障,需要你辅助诊断。
## 故障现象
[描述症状]
## 已知信息
- 最近发布: [时间 + 版本]
- 最近变更: [配置 / 依赖]
- 已尝试: [做过哪些检查]
## 当前线索
[粘贴关键日志/监控数据]
## 请你
1. 列出接下来应该检查的 3-5 个方向，按价值排序
2. 每个方向的具体执行命令或查询
3. 如果我要更多信息，你需要知道什么
我会根据你的建议继续排查,边查边反馈。
这是一个多轮对话 — 把 Claude 当成"老专家",边聊边查。
2.4 Runbook 自动生成
基于以下故障复盘报告,帮我生成一份新的 Runbook。
## 故障背景
[粘贴复盘报告]
## Runbook 模板
参照 docs/chapters/05-operations/03-incident-response.md 里的 Runbook 结构。
## 要求
1. 现象描述要具体（告警名、错误信息）
2. 快速定位步骤要可执行（命令、查询）
3. 处置方案要分层（首选、备选、兜底）
4. 常见根因 top 3
## 输出
完整的 Markdown Runbook，可以直接放到 runbook 库。
2.5 复盘报告初稿
基于以下信息生成故障复盘报告初稿。
## 时间线
[粘贴故障群里的关键消息 + 时间戳]
## 监控数据
[粘贴或描述关键指标的变化]
## 处置动作
[列出执行过的操作]
## 报告要求
参照 docs/chapters/05-operations/04-postmortem.md 的模板,包含：
1. 摘要
2. 时间线
3. 详细经过
4. 根因分析（至少做 5 Why）
5. 做得好的 / 做得不好的
6. 改进项（SMART 原则）
## 注意
- 保持 blameless culture，不指名道姓
- 改进项要具体可执行
- 标注"本报告由 AI 生成,需人工审核"
2.6 容量预测
基于以下历史数据,帮我预测未来 3 个月的容量需求。
## 历史数据（最近 6 个月）
| 月份 | 日均 QPS | 峰值 QPS | DAU | 存储(TB) |
|------|---------|---------|-----|---------|
| ...
## 业务趋势
- 本季度预计用户增长: 30%
- 即将上线的功能: [描述]
- 即将到来的大促: [时间]
## 当前资源
- 服务实例数: N
- 数据库规格: ...
- 存储总量: ...
## 输出
1. 未来 3 个月的容量预测（QPS / DAU / 存储）
2. 是否需要扩容?什么时候扩?扩多少?
3. 风险点
4. 建议的扩容节奏
2.7 混沌演练方案
帮我设计一组混沌工程实验。
## 系统拓扑
[描述服务间依赖]
## 目标
验证系统在以下场景下的韧性:
1. 单个实例挂掉
2. 某依赖服务完全不可用
3. 网络延迟高
4. 数据库慢
5. CPU 满载
## 输出
对每个场景给出:
1. 实验方案（用 Chaos Mesh / Gremlin 的语法）
2. 预期行为（系统应该怎么响应）
3. 验证方法（看哪些监控）
4. 爆炸半径控制（万一失控怎么停）
5. 演练前准备
2.8 配置漂移审计
我有三个环境的配置文件,帮我找出异常。
## Dev 环境
```yaml
[粘贴 dev config]
Staging 环境
[粘贴 staging config]
Prod 环境
[粘贴 prod config]
任务
- 列出三个环境之间的所有差异
- 标注哪些差异是合理的（如 URL、实例数）
- 标注哪些差异是可疑的（如参数值不一致）
- 标注哪些本应一致但不一致
- 建议修复方向
## 三、AI 辅助的最佳实践
### 3.1 实时性与离线分析结合
**实时（告警时）**：
- 用 AI 快速归因
- 生成处置建议
- 多轮对话辅助诊断
**离线（非告警时）**：
- 分析历史故障模式
- 生成 runbook
- 优化监控规则
### 3.2 给 AI 结构化输入
不要粘贴 1 万行日志让 AI "自己看"。先做预处理：
```bash
# 先聚合/过滤再给 AI
grep "ERROR" app.log | awk '{print $5}' | sort | uniq -c | sort -rn > summary.txt
把 summary.txt 给 AI,效果远好于原始日志。
3.3 建立团队 Playbook
把常用的诊断 prompt 做成 skill:
ep-code-ai/skills/operations/playbooks/
├── diagnose-high-error-rate.md
├── analyze-slow-query.md
├── explain-alert-storm.md
├── postmortem-draft.md
├── capacity-forecast.md
└── config-audit.md
3.4 让 AI 的输出可审计
- 保留 prompt 原文（用于复现）
- 保留 AI 的回答
- 标注"AI 建议 vs 人工决策"
- 关键决策必须人工签字
四、AI 使用的风险
4.1 不要让 AI 做的事
- ❌ 自动执行破坏性操作（如"重启所有服务"）
- ❌ 直接改生产配置
- ❌ 替代人类决策（AI 是助手，不是 IC）
- ❌ 处理涉密信息（客户数据、内部 IP）
4.2 必须人工确认的事
- 任何影响生产的操作
- 告警的真伪判断（避免被幻觉误导）
- 故障的定级
- 复盘报告的最终结论
- 对外通报文案
4.3 信息安全
- 日志给 AI 前要脱敏（密码、Token、个人信息）
- 生产配置不直接贴到 AI 对话
- 客户数据绝不外传
五、AI 运维成熟度模型
| 等级 | 特征 | 改进方向 |
|---|---|---|
| L1 手工 | 人肉查日志、写报告 | 开始用 AI 辅助写 |
| L2 辅助 | AI 帮忙起草、分析 | 积累 Prompt 库 |
| L3 流程化 | AI 嵌入固定环节 | 扩大覆盖面 |
| L4 自助 | 一线值班能自助用 AI 诊断 | 培训 + 工具化 |
| L5 半自治 | 部分告警 AI 自动处置 | 谨慎引入,必须可回滚 |
六、团队 Prompt 库
6.1 组织方式
skills/operations/
├── README.md ← 总索引
├── prompts/
│ ├── incident/ ← 故障处置
│ ├── analysis/ ← 分析类
│ ├── postmortem/ ← 复盘
│ ├── capacity/ ← 容量
│ └── chaos/ ← 混沌
└── playbooks/ ← 组合 Prompt（完整流程）
├── on-call-assistant.md
└── weekly-review.md
6.2 Prompt 的评估
对 prompt 定期评估:
- 使用频率
- 输出质量（1-5 打分）
- 节省的时间
- 发现的问题（AI 漏掉 / 误导的）
持续迭代。
七、CLI 脚手架（Sprint 3 新增）
本仓库 tools/ 下提供运维场景零依赖脚手架:
| 能力 | 位置 |
|---|---|
| Prometheus 告警 → 企微/钉钉/飞书/Slack 转发 webhook server | tools/integrations/alertmanager/ |
kubectl 薄封装: rollout-status / scale（prod 保护）/ logs | tools/integrations/k8s/ |
| 多环境配置 diff + 敏感值明文扫描 | tools/cross-platform/scripts/config-audit.js |
| 运维度量周报（Runbook/发布/故障/复盘 + 回滚/Hotfix 数） | tools/metrics/operations/ |
在 CI 里的自动校验见 .github/workflows/ci.yml 的 config-audit job（prod 明文敏感值阻塞合入）。