桌面推演与实战演练适用于不同的防护目标

业务连续性防护演练并不是把所有系统同时停掉，而是根据防护目标选择合适的验证方式。桌面推演主要检验人在压力下能否判断、授权和协同；实战演练则进一步检验备用环境、技术方案和业务操作是否真的可用。两者配合使用，才能形成较完整的连续性防护能力。

先区分两类演练要解决的问题

桌面推演：验证决策链和处置规则

桌面推演通常在会议室或线上会议中进行，不改变生产系统状态。主持人按时间线发布事件，例如办公楼所在区域临时无法使用、关键审批人无法接听电话、外部通信服务出现延迟等，参与者依据预案说明下一步行动。

这种业务连续性防护演练适合检查四类问题：谁有权宣布进入应急状态，哪些岗位可以互相替代，信息通过什么渠道发布，以及何时从临时措施转回常态。它的优点是成本较低、风险可控，适合新预案发布、组织架构调整或跨部门职责不清的情况。缺点是无法证明备用系统一定能承载真实操作，也不能充分暴露权限、网络和数据配置问题。

实战演练：验证切换和恢复结果

实战演练会在测试环境、隔离区域或经批准的低风险窗口内执行实际操作。例如，对人力资源系统的备用应用进行切换，使用经过脱敏的员工档案完成查询、审批和报表导出，再将环境恢复到原状态。参与者需要操作真实的认证、数据库、应用服务和监控组件，但不得擅自触碰生产数据。

实战演练能发现桌面讨论难以暴露的故障，如备用环境版本不一致、恢复账号过期、证书未同步、数据权限缺失或批处理任务无法重启。它的成本和组织要求更高，适合关键服务已有成熟预案、变更窗口明确且回退方案经过批准的情况。

按防护目标选择演练组合

实际安排可采用“先桌面、后实战、再复盘”的顺序。桌面推演先确认边界，避免实战过程中出现无人授权或临时改变目标的情况；实战阶段只验证已经批准的范围；复盘则把发现的问题转化为负责人、完成时限和验证方法。

一套可执行的业务连续性防护演练步骤

1. 确定单一目标。例如只验证“备用身份认证服务能否支持员工登录”，不要同时加入多个无关故障。明确适用系统、参与岗位、演练窗口和停止条件。
2. 定义成功标准。可记录切换耗时、成功登录比例、关键页面加载情况、审批记录是否落库，以及恢复后抽查发现的问题数量。具体阈值应结合业务容忍度和系统规模设定，不能直接套用其他组织的数值。
3. 准备安全边界。建立测试账户和脱敏数据，备份当前配置，确认回退负责人。涉及云平台、数据库或网络策略时，应提前列出恢复命令、审批人和人工替代方案。
4. 分阶段注入事件。先模拟主服务不可用，再加入备用联系人未响应、值班人员交接或监控告警延迟等条件。每次只增加一个变量，便于判断问题来源。
5. 执行用户侧验证。由业务人员完成一项完整流程，例如登录、提交内部报销、查询审批状态、导出结果并核对字段。技术团队只证明服务在线是不够的，必须确认使用结果符合业务要求。
6. 记录并复盘。保存事件时间线、授权记录、配置变更、系统日志和参与者反馈。复盘时区分技术缺陷、流程缺陷和培训缺陷，分别指定整改方式。

如何避免演练流于形式

业务连续性防护演练最常见的问题是预先告诉所有人完整答案，导致参与者只是在朗读预案。更有效的做法是保留必要的保密范围，只提前说明安全边界、停止条件和联络方式；具体事件由主持人分段发布。

还应让不同角色分别提交记录。技术人员记录服务状态和切换动作，业务人员记录能否完成工作，管理人员记录授权和资源调配。三类记录互相对照，才能判断“系统恢复”是否真正等于“业务恢复”。

对于不能直接进行实战切换的生产系统，可使用影子环境、只读副本或经过批准的历史数据开展验证。此类方式不能完全替代真实切换，但能先检验流程、权限和数据处理逻辑，降低首次实战的风险。

常见问题

桌面推演能替代实战演练吗？

不能。它能验证组织和决策机制，却无法证明备用环境、权限配置和数据恢复结果可靠。

实战演练是否必须中断真实业务？

不必。可以在隔离环境、低峰窗口或经过脱敏的数据集上执行，但必须明确验证范围和局限。

演练多久开展一次比较合适？

没有统一周期。关键系统在重大版本、架构或人员变化后应重新验证；稳定系统也应按风险等级定期开展，具体周期由业务影响和变更频率决定。

发现问题后只修改预案可以吗？

不一定。若根因是权限、配置、人员替补或工具缺失，还需要完成技术整改、培训或资源补充，并通过后续业务连续性防护演练确认效果。

归根结底，桌面推演回答“组织是否知道怎么做”，实战演练回答“系统和人员是否做得到”。围绕不同防护目标分层设计业务连续性防护演练，才能把预案文字转化为可执行、可验证、可持续改进的能力。