别再半夜敲命令了：用 LLM + 自动化脚本，把 Runbook 变成“会思考的运维同事”

我先问你一个问题，你别急着回答，先在脑子里过一遍：

你们团队的 Runbook，是不是长这样？

• Wiki 里躺着
• 写得很全，但没人翻
• 真出故障的时候，大家靠“肌肉记忆 + 经验”
• 最后修好了，再补一句：“下次注意”

说句扎心的：
传统 Runbook，本质是“给人看的文档”，不是“给系统用的能力”。

而 LLM 的出现，第一次让我觉得：

Runbook，终于可以不只是文档了。

一、Runbook 的最大问题，从来不是“没写”

很多管理者以为：

“我们缺的是 Runbook”

但干过运维的人都知道，真正的问题是：

• 故障发生时

  • 你来不及翻
  • 翻到了也不一定匹配

• 每个环境都不一样

• 每次事故都有“变种”

所以现实是：

Runbook ≠ 执行
Runbook ≠ 决策
Runbook ≠ 修复

它只是“参考资料”。

二、LLM 出现后，Runbook 这件事彻底变味了

我第一次把 LLM 接进告警链路时，脑子里冒出来一句话：

“这不就是一个 24x7 不会累、不怕背锅、还愿意查文档的运维吗？”

当然，它不是“替代人”，
而是把人从低价值动作里解放出来。

LLM 能帮 Runbook 做什么？

简单拆一下：

1. 读懂告警
2. 结合上下文判断场景
3. 选择对应的处理流程
4. 触发自动化脚本
5. 回收结果，再判断是否升级

这一步一拆，你会发现：

Runbook，开始“活”了。

三、智能 Runbook 的核心架构（说人话版）

我不画复杂架构图了，用一句话总结：

LLM 负责“想”，脚本负责“干”。

一个典型链路是这样的：

告警 → LLM 分析 → 生成修复计划 → 自动化脚本执行 → 结果反馈 → 再决策

注意重点：

• LLM 不直接干活
• 脚本不自己做决定
• 两者各司其职

四、一个真实得不能再真实的场景

场景：

凌晨 2 点，Prometheus 告警：

API 错误率 > 5%，持续 3 分钟

传统流程：

1. 值班同学醒来
2. 看 Grafana
3. 查日志
4. 判断是不是数据库、缓存、网络
5. 手敲命令
6. 修完写复盘

智能 Runbook 流程：

1. 告警触发

2. LLM 接收上下文：

   • 告警信息
   • 最近发布记录
   • 历史故障案例

3. LLM 输出判断：

   “疑似某节点连接池耗尽，建议重启 해당 pod，并检查最大连接数配置”

4. 触发脚本

5. 校验结果

6. 成功 → 自动关闭告警
   失败 → 升级人工

五、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 不是来抢饭碗的，
它是来把人从“重复、低价值、容易出错”的动作里拉出来的。

让人去干更值钱的事：

• 架构优化
• 稳定性设计
• 故障预防

最后一句话送你

未来最值钱的运维，不是敲命令最快的，而是最会“设计自动化决策”的。