别再半夜敲命令了：用 LLM + 自动化脚本，把 Runbook 变成“会思考的运维同事”
我先问你一个问题，你别急着回答，先在脑子里过一遍：
你们团队的 Runbook，是不是长这样？
- Wiki 里躺着
- 写得很全，但没人翻
- 真出故障的时候，大家靠“肌肉记忆 + 经验”
- 最后修好了，再补一句：“下次注意”
说句扎心的：
传统 Runbook，本质是“给人看的文档”，不是“给系统用的能力”。
而 LLM 的出现，第一次让我觉得：
Runbook，终于可以不只是文档了。
一、Runbook 的最大问题，从来不是“没写”
很多管理者以为：
“我们缺的是 Runbook”
但干过运维的人都知道，真正的问题是：
故障发生时
- 你来不及翻
- 翻到了也不一定匹配
- 每个环境都不一样
- 每次事故都有“变种”
所以现实是：
Runbook ≠ 执行
Runbook ≠ 决策
Runbook ≠ 修复
它只是“参考资料”。
二、LLM 出现后，Runbook 这件事彻底变味了
我第一次把 LLM 接进告警链路时，脑子里冒出来一句话：
“这不就是一个 24x7 不会累、不怕背锅、还愿意查文档的运维吗？”
当然，它不是“替代人”，
而是把人从低价值动作里解放出来。
LLM 能帮 Runbook 做什么？
简单拆一下：
- 读懂告警
- 结合上下文判断场景
- 选择对应的处理流程
- 触发自动化脚本
- 回收结果，再判断是否升级
这一步一拆，你会发现：
Runbook，开始“活”了。
三、智能 Runbook 的核心架构（说人话版）
我不画复杂架构图了，用一句话总结：
LLM 负责“想”，脚本负责“干”。
一个典型链路是这样的：
告警 → LLM 分析 → 生成修复计划 → 自动化脚本执行 → 结果反馈 → 再决策
注意重点：
- LLM 不直接干活
- 脚本不自己做决定
- 两者各司其职
四、一个真实得不能再真实的场景
场景：
凌晨 2 点，Prometheus 告警：
API 错误率 > 5%，持续 3 分钟
传统流程：
- 值班同学醒来
- 看 Grafana
- 查日志
- 判断是不是数据库、缓存、网络
- 手敲命令
- 修完写复盘
智能 Runbook 流程：
- 告警触发
LLM 接收上下文：
- 告警信息
- 最近发布记录
- 历史故障案例
LLM 输出判断：
“疑似某节点连接池耗尽，建议重启 해당 pod，并检查最大连接数配置”
- 触发脚本
- 校验结果
- 成功 → 自动关闭告警
失败 → 升级人工
五、LLM 到底“聪明”在哪？
不是它会敲命令，
而是它会“选策略”。
举个例子。
同样是服务不可用：
有时是：
- 连接池耗尽
有时是：
- JVM Full GC
有时是：
- 配置下发错误
传统脚本是：
systemctl restart service
智能 Runbook 是：
“在重启之前，我先看看值不值得重启。”
六、一个简化版的 LLM 决策示例
prompt = f"""
当前告警：
{alert_text}
系统状态：
- CPU: {cpu}
- Memory: {mem}
- GC: {gc}
- 最近发布：{deploy_info}
请判断最可能原因，并给出处理建议（仅返回步骤）。
"""
response = llm.generate(prompt)
LLM 输出的不是“命令”，而是策略：
1. 检查连接池使用率
2. 若超过 90%，重启 pod
3. 重启后观察 2 分钟
4. 若未恢复，升级人工
然后，你再把它映射成白名单脚本：
if pool_usage > 90:
kubectl rollout restart deploy/api
这一步非常关键：
❌ LLM 不直接执行命令
✅ LLM 只决定“走哪条路”
七、为什么我强烈反对“LLM 直接 SSH 上服务器”
说句不好听的：
这不是智能运维，这是“智能自杀”。
正确姿势是：
所有可执行动作
- 都提前脚本化
LLM
- 只能在“允许的动作集合”里选择
你要给 LLM 的不是 root 权限，
而是一个受控的操作菜单。
八、智能 Runbook 最有价值的三个地方
1️⃣ 把经验变成系统能力
老运维脑子里的：
“我一看这告警就知道怎么回事”
终于可以被“固化”了。
2️⃣ 降低夜间故障的人力成本
不是每个告警都值得把人叫醒。
- 能自动修的 → 自动
- 修不了的 → 带着结论叫人
这差别太大了。
3️⃣ 事故复盘质量明显提升
因为 LLM 会记录：
- 当时看到了什么
- 为什么选这个策略
- 执行结果如何
复盘第一次变成：
“我们为什么这样判断”
而不是：
“当时太乱了，记不清了。”
九、但我必须泼一盆冷水
智能 Runbook 不是银弹。
它非常不适合：
- 架构混乱
- 自动化基础为零
- 环境差异极大
- 没有操作边界意识的团队
如果你现在连：
- 标准化部署
- 脚本收敛
- 权限治理
都没做，
先别急着上 LLM。
十、我的真实感受（说句人话）
我做运维这么多年，第一次觉得：
“Runbook，终于不是给新人背的了。”
LLM 不是来抢饭碗的，
它是来把人从“重复、低价值、容易出错”的动作里拉出来的。
让人去干更值钱的事：
- 架构优化
- 稳定性设计
- 故障预防
最后一句话送你
未来最值钱的运维，不是敲命令最快的，而是最会“设计自动化决策”的。
