二、演练组织架构：各小组的职责与协作

演练组织架构这件事，说实话，我见过太多团队栽跟头了。

有一次，某城商行做核心系统切换演练，结果领导小组没到场，执行小组不知道找谁拍板，硬生生把演练拖成了「事故复盘会」。嗯，从那以后，我每次做灾备演练方案，第一件事就是把组织架构画清楚。

说白了，演练不是技术活，是管理活。人没到位，职责不清，再好的技术方案也是白搭。

2.1 演练领导小组：定方向、拍板子

领导小组是演练的「大脑」。我习惯叫它「决策层」。

这个组通常由分管副行长或CIO挂帅，成员包括科技部总经理、业务连续性管理负责人。为什么这么配？因为演练过程中一旦出现异常，需要有人能拍板——是继续演练、回退、还是切换为真实灾备？

• 审批演练方案：包括演练目标、范围、时间窗口、风险预案。我个人习惯，方案必须经过领导小组签字，否则不启动。
• 启动与终止演练：演练开始前，由组长下达启动指令。演练中如果出现不可控风险，组长有权立即终止。
• 资源协调：比如临时需要调拨带宽、申请停机窗口、协调业务部门配合，这些都需要领导小组出面。
• 对外通报：如果演练涉及监管报备或客户告知，由领导小组统一口径。

2.2 执行小组：动手干、盯细节

执行小组是演练的「手脚」。说白了，所有技术操作都是他们干的。

这个组通常由系统管理员、数据库管理员、网络工程师、存储工程师组成。我建议每个岗位至少配A、B角，防止有人中途掉链子。

• 执行演练脚本：按照预定的操作步骤，逐条执行。比如停止生产数据库、启动灾备数据库、切换DNS解析等。
• 记录操作日志：每一条操作的时间、操作人、操作结果，必须实时记录。我见过太多演练结束后「忘了刚才做了什么」的情况。
• 异常处理：执行过程中如果遇到脚本报错或环境异常，执行小组要第一时间判断能否自行解决，不能解决则上报领导小组。
• 回退操作：如果演练需要回退，执行小组负责按回退脚本操作。注意，回退脚本必须提前写好，不能现场编。

2.3 技术保障组：兜底、救火

技术保障组是演练的「保险丝」。他们不直接参与操作，但随时准备救场。

这个组通常由厂商工程师、资深架构师、运维开发人员组成。为什么需要他们？因为演练过程中可能遇到意想不到的问题——比如存储链路中断、数据库日志爆满、网络延迟异常。这些问题的排查和修复，需要更专业的人。

• 环境巡检：演练开始前，技术保障组要对所有基础设施做一次全面巡检，确保硬件、网络、存储都在健康状态。
• 故障排查：演练中如果出现技术故障，技术保障组负责定位原因、给出修复方案。注意，他们只负责「诊断」，具体操作由执行小组完成。
• 工具支持：比如需要临时写一个监控脚本、调整一个参数配置，技术保障组要能快速响应。
• 事后复盘：演练结束后，技术保障组要输出故障分析报告，说明问题根因和改进措施。

2.4 观摩评估组：挑刺、打分

观摩评估组是演练的「裁判」。他们不参与操作，只负责观察和记录。

这个组通常由内部审计、风险管理、外部专家组成。你想想看，如果演练自己干自己评，那还有什么意义？

• 评估演练效果：比如RTO（恢复时间目标）是否达标、RPO（恢复点目标）是否满足、数据一致性是否验证通过。
• 记录问题：观摩评估组要记录演练过程中所有「不符合预期」的地方。比如某个步骤耗时过长、某个操作顺序不合理、某个沟通环节出现延误。
• 输出评估报告：演练结束后，评估组要给出书面报告，内容包括演练是否成功、存在哪些风险、改进建议。
• 监督合规性：确保演练流程符合监管要求和内部制度。比如是否按规定进行了数据备份验证、是否保留了操作日志。

2.5 四个小组的协作关系

这四个组不是各干各的，而是有明确的协作流程。我画了一张图，方便你理解：

这张图展示了几个关键协作关系：

• 领导小组向下达指令给执行小组和技术保障组，执行小组遇到问题向上汇报。
• 技术保障组为执行小组提供技术支持，但不直接操作。
• 观摩评估组全程观察，向领导小组输出评估报告，同时向执行小组和技术保障组记录问题。

2.6 各小组的文档输出

演练结束后，每个小组都要输出对应的文档。我列了一个表格，方便你对照：

小组	必须输出的文档	内容要求
领导小组	演练总结报告	包含演练结论、资源消耗、改进方向
执行小组	操作日志、回退记录	精确到分钟，记录每一步操作和结果
技术保障组	故障分析报告	说明故障根因、处理过程、预防措施
观摩评估组	演练评估报告	量化评分、问题清单、整改建议

嗯，文档这东西，平时觉得烦，真出了事就知道有多重要了。我见过一家券商，演练结束后发现数据不一致，翻了一个星期的日志才找到问题。如果当时执行小组的记录做得细，半天就能定位。

好了，组织架构这部分就讲到这里。记住一句话：人对了，演练就成功了一半。

---