灾难恢复复盘与改进
演练或真实事故结束后还原时间线、定位根因、产出可验证的行动项。根因分析要区分直接原因与系统性原因：直接原因是触发点（某次误操作、某个进程挂了），系统性原因是防线缺失（没有校验、没有自动化、没有告警）。改进应针对系统与流程，而不是要求人『下次更细心』。
基本信息
| 参与范围 | 执行团队、指挥者、业务方代表，必要时含第三方 |
|---|---|
| 输出物 | 时间线、根因分析、行动项清单、预案修订 |
| 基调 | 对事不对人：鼓励暴露问题而非追责表演 |
| 跟踪 | 行动项纳入任务系统，定期回顾直至关闭 |
典型使用场景
- 真实故障后复盘：还原从首个异常信号到业务恢复的完整过程
- 演练后改进：把暴露的问题转成有期限的行动项
- 跨团队对齐：让网络、应用、DBA 各方对根因达成共识
- 预案修订：根据实际执行情况更新切换步骤与判定条件
- 复盘文化建立：用无指责讨论换取更真实的输入
复盘输出框架
复盘输出框架
# 时间线：从首个异常信号到业务恢复，逐条记录（含决策点与等待时间）
# 根因分析：连续追问『为什么』直到系统性原因
# 例：为什么恢复慢 -> 步骤靠手工 -> 为什么没自动化 -> 改进从未排期
# 行动项：动宾结构 + 负责人 + 期限 + 验收方式
# 例：12 月底前把数据库提升步骤脚本化，演练复测 <= 3 分钟
# 验证：下轮演练逐项复核行动项是否生效
# 记录归档：复盘结论写入知识库，供后来者查阅根因层次对照
| 层次 | 示例 | 改进方向 |
|---|---|---|
| 触发点 | 误执行了清理脚本 | 防误操作设计（二次确认、权限分离） |
| 防线缺失 | 清理没有影响面检查 | 增加预演与影响面评估步骤 |
| 流程缺失 | 没有变更审批与窗口安排 | 把高风险操作纳入变更管理 |
| 组织缺失 | 无人负责备份与演练 | 明确责任人与定期演练排期 |
高质量的复盘会修改系统与流程；低质量的复盘只留下『下次注意』。判断标准很直接：行动项是否能被验收、是否有人在跟踪。