三者有什么区别
Runbook、Playbook、SOP 都是运维与管理文档，但关注点不同：Runbook 面向系统操作，给出可照做的步骤与验证方法；Playbook 面向场景协同，写清触发条件、角色分工与决策路径；SOP 面向日常重复作业，保证不同人执行结果一致。实际使用中常组合出现，Playbook 做出决策后调用对应 Runbook 执行操作。
怎么写得有用
三类文档的共同底线是可执行、可验证：Runbook 每一步要写清命令、预期输出与失败分支；Playbook 要写清触发条件、角色表、决策分支与沟通模板；SOP 要写清动作、责任岗位与记录要求。三者都应标注维护人、适用版本与最后验证时间，在系统或组织变化后同步更新，否则现场照做反而会引入新故障。
基本信息
| Runbook | 系统级操作步骤 + 预期结果 + 验证方法 |
|---|---|
| Playbook | 场景级角色分工 + 决策路径 + 沟通模板 |
| SOP | 重复作业的标准动作与记录要求 |
| 通用要求 | 标注适用版本、维护人与最后验证时间 |
典型使用场景
- 单机故障处置：按 Runbook 重启服务并验证端口与日志
- 数据库主从切换：Runbook 记录切换顺序与校验语句
- 重大故障响应：Playbook 定义指挥角色与升级路径
- 安全事件处置：Playbook 规定技术、法务、对外的联动顺序
- 日常备份与对账：SOP 保证每天同一套动作与留痕
- 新人值班培训：先读 Runbook 跟做，再独立值守
Runbook 片段示例
Runbook 片段示例
# Runbook：服务无响应处置
1. 确认现象：curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/health
2. 查看进程与监听：systemctl status app; ss -lntp | grep 8080
3. 重启服务：systemctl restart app
4. 验证：健康检查返回 200，且日志中无 ERROR
5. 仍失败：升级到二级支持，附上 1-3 步输出对照与读者
| 类型 | 关注点 | 主要读者 |
|---|---|---|
| Runbook | 操作步骤与验证 | 值班工程师 |
| Playbook | 角色分工与决策路径 | 指挥者与协同人员 |
| SOP | 动作一致性与留痕 | 日常执行岗 |
命名不必强求统一，关键是三件事各就各位：怎么操作、谁决策、日常怎么重复做。同一场景下 Playbook 应直接链接到对应 Runbook，避免现场再找一遍。
Playbook 只写不演练会失效：联系人与角色半年就会过期，演练时按真实时间线走一遍并同步更新。