Runbook（直译为“运行手册”）是一套标准化的操作流程文档，用于指导工程师或系统在遇到特定事件（如系统故障、日常维护、紧急发布）时，按预定步骤快速、正确地完成任务。
你可以把它想象成飞机的紧急检查清单或消防员的灭火预案——在压力大、时间紧的情况下，无需思考“下一步做什么”，只需照着步骤执行。
一份典型的 Runbook 包含：
触发条件：什么时候使用这份手册（例如“CPU 持续 5 分钟超过 90%”）
角色与权限：谁负责执行、需要哪些系统权限
详细步骤：命令行、API 调用、界面操作等，甚至包括截图
验证方法：如何确认每一步已成功
回滚方案：如果失败，如何撤销操作
联系人：升级路径（遇到问题找谁）
问题：订单支付服务响应变慢。
Runbook 可能写：
登录跳板机 ssh jump@prod
运行 kubectl get pods -n payment 查看异常 Pod
重启问题 Pod：kubectl delete pod <pod名>
验证：运行 curl localhost:8080/health，预期返回 200
若未恢复，按联系人列表通知 SRE 组长
降低人为错误：高压下不会漏步骤
加速恢复：无需现场查资料或调试
知识传承：老员工的经验被固化下来
合规：满足审计对操作可追溯的要求
在现代 DevOps 中，Runbook 正逐渐从纯文档演变为半自动化或全自动化（例如使用 Rundeck、StackStorm 等工具），称为 “Automated Runbook”。不过，即使全自动，背后依然遵循同一套逻辑：输入条件 → 执行步骤 → 验证输出。
如果你需要，我可以给出一份简单的 Runbook 模板，或说明如何编写第一个 Runbook。
下面是一份通用 Runbook 模板，你可以直接复制到文档（如 Confluence、Markdown 文件）中，根据实际场景填写。模板已按“故障排查”场景设计，稍加修改也适用于部署、回滚、备份等任务。
例如： 订单服务 CPU 飙升处理 Runbook
已登录跳板机 / Kubernetes 控制节点
拥有 kubectl、curl 权限，或已切换至 prod 命名空间
已知服务所在集群：k8s-prod-cluster
备好监控面板链接（如 Grafana 看板）
查看 Pod 资源使用
kubectl top pods -n order-ns --sort-by=cpu
检查最近事件
kubectl get events -n order-ns --sort-by='.lastTimestamp'
查看日志错误高峰
kubectl logs -l app=order-api -n order-ns --tail=100 | grep ERROR
kubectl scale deployment order-api -n order-ns --replicas=4
验证：kubectl get pods -n order-ns | grep order-api（状态全为 Running）
kubectl delete pod -l app=order-api -n order-ns
注意：会短暂中断请求（约10-30s），确保有重试机制。
修改配置中心（如 Apollo）开启限流：
curl -X POST config-service/update -d '{"order.rate.limit":100}'
CPU 使用率 < 50%
kubectl top pods -n order-ns | grep order-api
接口测试正常
curl -w "%{http_code}" https://order.example.com/health
查看告警是否消除（监控面板不再触发）
扩容回滚：kubectl scale deployment order-api -n order-ns --replicas=2
限流回滚：curl -X POST config-service/update -d '{"order.rate.limit":0}'（0 表示不限流）
执行时间：____
执行人：____
实际效果：☐ 成功 ☐ 失败 ☐ 部分成功
根本原因（如有）：____
改进建议：____
首次使用前：把所有 order-api、order-ns 等示例占位符替换为真实资源名
定期演练：每季度模拟一次，验证步骤是否依然有效
自动化：将第4步的脚本放入 Rundeck/Ansible 中，变成“一键执行”
需要我帮你针对某个特定场景（如数据库备份、新版本回滚）定制一份模板吗？
本回答由 AI 生成，内容仅供参考，请仔细甄别。
下面是一份专门针对新版本回滚场景的 Runbook 模板。适用于应用发布后出现严重 Bug、性能下降或数据异常时，快速恢复到上一个稳定版本。
例如： 订单服务 v2.3.0 回滚 Runbook
确认当前故障确实由新版本引起（对比旧版本监控基线）
确认上一个稳定版本的镜像/包仍然可用
通知相关方（产品、客服、运营）即将回滚
备份当前版本的配置与日志（用于事后分析）
打开数据库备份（如需回滚 schema）
⚠️ 谨慎操作：此步不可逆，需确认兼容性
接口返回正常
curl -w "%{http_code}" https://order.example.com/api/v1/health
错误率降至正常水平（< 0.1%）
核心业务场景测试通过
监控告警消除（观察 5 分钟）
回滚执行时间：____
执行人：____
回滚是否成功：☐ 是 ☐ 否
根本原因（新版本问题）：____
影响时长：从故障发生到回滚完成共 ____ 分钟
改进措施：
增加金丝雀发布阶段
完善自动化测试覆盖
本次回滚流程优化点：____
提前演练：每季度在生产预发环境真实回滚一次
保留历史版本：至少保留最近 5 个稳定镜像/包
回滚窗口：尽量在低峰期（如凌晨）执行，但故障时优先恢复
全自动回滚：结合监控系统（Prometheus + 告警）自动触发回滚
需要我针对你的具体部署环境（比如 ECS、K8s、Serverless）进一步调整模板吗？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。