故障切换预案文档要写什么
好的预案标准是「交给没参与过的人也能执行」：判定标准要量化（谁探测、几路失败、持续多久才算故障），决策人要唯一且当班可联系，执行步骤要细化到可复制的命令，每一步都要有验证点，最后还要有善后与复盘安排。预案存在的意义是把故障当天从「临场判断」变成「照单执行」。
基本信息
| 文档形态 | Runbook（操作手册），放在值班可随时访问的位置 |
|---|---|
| 必备章节 | 判定标准、决策人、执行步骤、验证点、回退与善后 |
| 演练节奏 | 季度桌面推演 + 半年实战演练 |
| 关联文档 | 切换前检查清单（Go / No-Go）、拓扑图、账号与权限说明 |
| 维护责任 | 指定 owner，架构或拓扑变更后必须同步更新 |
| 验证标准 | 新值班同学照文档能独立完成一次切换演练 |
典型使用场景
- 主库宕机：值班按判定标准确认后启动切换流程
- 计划内维护：用同一份文档做 switchover 操作
- 值班交接：新同学按文档熟悉流程与工具位置
- 合规审计：证明故障处理有明确流程与责任人
- 故障复盘：对照预案检查哪一步执行不到位
预案骨架示例
预案骨架示例
1. 探测：nodeA/nodeB 两路探测失败持续 > 90 秒
2. 决策：值班确认后呼叫 DBA 负责人，明确「切/不切」
3. 执行：提升 repl-01 为新主（命令见附录 A，逐条可复制）
4. 验证：写入自测、应用探针恢复、错误率回落
5. 善后：隔离旧主、记录可能丢失的事务窗口、通知业务方
6. 复盘：48 小时内出报告，更新预案与监控阈值要素与常见缺口
| 要素 | 写清楚什么 | 常见缺口 |
|---|---|---|
| 判定标准 | 探测方式、路数、持续时长 | 只写「主库不可用」，没有量化口径 |
| 角色 | 决策人、执行人、通知对象与联系方式 | 只写岗位不写人，值班时找不到人 |
| 执行步骤 | 逐条命令与预期输出 | 写「提升从库」但不给命令 |
| 验证点 | 每步之后检查什么才算通过 | 切换完成即宣布结束，业务仍连不上 |
| 回退与善后 | 旧主处理、数据补偿、上报路径 | 没人负责数据缺口核对与通知 |
预案要与发布系统或工单系统联动：把切换清单做成工单模板，执行时逐步勾选并留下时间戳，既防漏步骤，也天然形成故障时间线供复盘使用。
预案不演练等于没有预案：第一次照着执行往往就是真实故障当天，而真实故障里还叠加了网络抖动、监控噪声与业务压力，未演练过的流程几乎必然超时。