桌面推演是什么
在会议室里按故障剧本推演：逐条注入事件，让各角色说明「此刻我做什么、依据是什么」，全程不动生产环境。它是成本最低的预演方式，擅长把授权、沟通、资料可获取性这类软问题提前暴露出来——这些问题在真实灾难中往往比技术问题更致命。
基本信息
| 成本 | 低：不需要动生产环境，只需要剧本与人 |
|---|---|
| 参加角色 | 应急指挥、DBA、网络、应用负责人、业务代表 |
| 典型时长 | 2 到 4 小时 |
| 关键产出 | 无法回答的问题、找不到的资料、说不清的分工，以及预案修订清单 |
| 建议频次 | 每半年到一年一次，重大变更或人员变动后补做 |
| 禁忌 | 开成汇报会：重点是找问题而不是展示成绩 |
典型使用场景
- 新预案上线前的预演，先暴露明显缺口再投入演练
- 人员轮换或组织调整后重新对齐分工与授权
- 架构变更（切换方式改变）后验证预案是否同步更新
- 校验阈值定义是否被各方真正认同
- 给管理层建立故障处置的直观认知
推演组织流程
推演组织流程
# 组织流程
1) 准备：故障剧本（场景卡）+ 参加角色（指挥/DBA/网络/应用/业务）
2) 开场：宣读场景与初始状态，例如「主库所在机房断电」
3) 注入：按时间线逐条投放事件，例如「30 分钟后备库复制中断」
4) 推演：各角色说明判断依据、操作动作、需要的授权
5) 记录：无法回答的问题、找不到的资料、说不清的分工
6) 输出：预案修订清单与责任人，并约定完成时限
# 纪律：不评价个人表现，只记录预案与信息流的缺口推演输出读法
| 发现类型 | 含义 | 后续动作 |
|---|---|---|
| 空白项 | 预案里根本没有这一步动作 | 补充步骤并指定责任人 |
| 资料缺口 | 现场拿不到拓扑、账号或操作手册 | 把资料放到现场确实取得到的位置 |
| 授权不清 | 没人能批准执行切换 | 写明授权人与授权条件 |
| 分工重叠 | 两人认为同一动作归自己 | 划清边界并写入预案 |
| 判断分歧 | 对阈值理解各不相同 | 把阈值改写成可核对的数字 |
推演中暴露的「找不到人、找不到文档、没人敢决策」与技术上不了线同等重要：真实灾难里最先卡住的往往就是这三件事。
剧本要按真实故障的节奏注入，而不是按理想步骤念流程：事件之间要留出决策时间，否则推演就退化成宣读预案。