桌面演练、模拟切换和真实切换是研发平台灾备演练的三个递进层级，区别集中在是否触碰生产环境、是否实际执行切换，以及验证的是流程、技术还是业务连续性。桌面演练在会议室按脚本推演角色与决策，不触碰生产；模拟切换在隔离或仿真环境实际执行切换与回切，验证技术步骤和数据可用性；真实切换在受控窗口内把业务真正切到灾备侧运行一段时间再回切，验证端到端业务连续性。选择哪一种，取决于本次演练要回答的问题、可接受的风险和可投入的环境与人力。
要点总览（TL;DR）
- 桌面演练在会议室按脚本推演角色、决策与通报链路，不触碰生产环境，适合新预案首次验证和人员变动后统一认知。
- 模拟切换在隔离或仿真环境实际执行切换与回切，验证数据恢复、依赖服务、账号权限和流量切换等技术步骤是否可复现。
- 真实切换在受控窗口内把业务切到灾备侧运行一段时间再回切，验证端到端业务连续性，风险最高，需要回切方案、停机窗口和值守机制到位。
- 三者是递进关系：桌面演练暴露的技术疑点进入模拟切换，模拟切换通过后再评估真实切换条件，真实切换发现的问题回写预案。
- 组合节奏可按桌面演练常态化、模拟切换按变更触发、真实切换按年度周期或重大变更后执行来安排。
三种演练方式在同一口径下的差异对照
把三种方式放在同一组维度上对照，差异会更清楚：桌面演练解决“人知不知道怎么做”，模拟切换解决“技术步骤能不能做成”，真实切换解决“业务在灾备侧能不能持续运行”。三者验证的对象不同，风险等级和投入也随之不同。
| 对照维度 | 桌面演练 | 模拟切换 | 真实切换 |
|---|---|---|---|
| 是否触碰生产环境 | 不触碰，在会议室或线上推演 | 不触碰生产，在隔离或仿真环境执行 | 触碰生产，业务实际切至灾备侧 |
| 是否实际执行切换 | 不执行，只口头推演步骤 | 实际执行切换与回切动作 | 实际执行切换，并在灾备侧运行一段时间后回切 |
| 验证对象 | 流程、角色分工、决策点、通报链路 | 技术步骤、数据一致性、依赖服务、恢复指标 | 端到端业务连续性，含业务可用性与回切能力 |
| 数据与业务风险 | 低，不接触真实数据与业务 | 中，隔离环境出错不影响生产，但需防止误连生产 | 高，切换窗口内业务受影响，回切失败会延长中断 |
| 参与角色 | 预案负责人、各系统负责人、业务代表、通报联络人 | 运维、DBA、平台开发、网络与安全人员 | 上述技术角色加业务方、值班值守、决策审批人 |
| 典型时长与频率 | 半天以内，可每季度或人员变动时开展 | 数小时至一天，按技术变更触发 | 安排在停机窗口内，按年度或重大变更后执行 |
| 产出物 | 修订后的预案、角色清单、待验证技术问题清单 | 切换与回切记录、验证项结论、缺陷与整改项 | 业务连续性验证报告、回切记录、预案与保障方案修订 |
三种方式是递进关系，并非互斥选项。桌面演练暴露的技术疑点交给模拟切换验证，模拟切换通过后再评估是否具备真实切换的条件；已经完成真实切换的系统，仍需要定期用桌面演练维持人员熟悉度。一套完整的演练体系通常同时包含三者，只是各自承担的验证任务不同。
桌面演练：推演流程与决策，不触碰生产
桌面演练适合预案首次成型、关键人员变动、组织与联络机制调整这几类场景。此时最需要确认的是“谁在什么时点做什么决定、向谁通报”，技术细节可以留到后续验证。
具体做法是准备一份场景脚本，按时间线逐场景推进，每个场景停在关键决策点上，由对应角色说明自己的动作、判断依据和上报路径。主持人负责控制节奏并记录分歧，记录人把每个待确认事项写成条目。推演过程中常见的产出包括：
- 修订后的应急预案，补齐缺失的角色和联络方式；
- 角色清单与代理人安排，避免关键岗位单人依赖；
- 待验证技术问题清单，例如某依赖服务的切换顺序、某数据的恢复来源；
- 通报与升级路径的确认结果，包括对外沟通口径。
桌面演练的局限同样明确：它无法证明切换步骤真的可执行，也无法证明备份数据真的可恢复。推演中所有人说“没问题”，不代表实际操作时依赖服务能按预期启动。因此桌面演练的结论应被当作待验证假设，而不是演练终点。
模拟切换：在隔离环境验证技术可行性
模拟切换适用于技术方案变更、备份与恢复链路调整、平台新版本上线前的灾备验证。它的价值在于把桌面演练留下的技术疑点真正跑一遍，用执行结果替代口头判断。
做法是在隔离或仿真环境中完整执行一次切换与回切：按预案顺序启动灾备侧服务，恢复数据，切换 DNS 与流量，核对依赖服务、账号权限和接口连通性，再按回切步骤恢复原环境。执行过程中记录每一步的实际耗时和异常，形成可复现的操作记录。
验证项应围绕可判定的标准展开，常见清单如下：
| 验证项 | 判定标准 |
|---|---|
| 数据恢复完整性 | 恢复后的数据量与关键表记录数同备份点一致，抽样比对无缺失 |
| 恢复时间 | 从启动切换到服务可用的实际耗时，与预案设定的目标对比 |
| 恢复点 | 可恢复的最新数据时点，与业务可接受的数据丢失范围对比 |
| 依赖服务 | 认证、消息、存储、外部接口在灾备侧均可用 |
| 账号与权限 | 灾备侧账号、密钥、证书有效，权限配置与原环境一致 |
| 流量切换 | DNS 解析与负载入口切换生效，回切后原环境恢复正常 |
| 步骤可复现 | 按脚本执行无需临时补救，或补救动作已回写脚本 |
模拟切换的局限在于环境差异。隔离环境的负载规模、数据量和依赖关系通常小于生产，切换顺利不代表生产环境同样顺利。因此模拟切换通过只说明技术路径可行，业务连续性的结论仍需真实切换来支撑。
真实切换：在受控窗口验证端到端业务连续性
真实切换用于关键系统的周期性演练、重大变更后的验证，以及监管或内控明确要求的场景。它要回答的问题是：业务真正跑在灾备侧时，用户能不能正常使用，出问题时能不能按计划切回来。
开展真实切换前，需要逐项确认前置条件：
- 回切方案与回切时限已明确，回切步骤经过模拟验证；
- 业务方确认停机窗口，影响范围已提前告知相关团队和用户；
- 数据同步状态确认，切换点的数据丢失范围在业务可接受范围内；
- 值守与通报机制到位，技术、业务、决策人各有人在岗；
- 中止条件已定义，例如关键依赖不可用或业务错误率超阈值时立即停止并回切。
执行时在窗口内把业务切到灾备侧，保持运行一段时间，观察登录、核心操作、接口调用等业务可用性指标，确认稳定后再按计划回切。运行时长应足以覆盖典型业务操作，而不只是验证服务能启动。
风险控制的关键在于提前写好触发条件而不是临场判断：明确什么情况下中止切换、什么情况下提前回切、回切后如何回补切换期间产生的数据、影响范围如何对外说明。真实切换的风险最高，任何一项保障缺失都应推迟执行，改用模拟切换继续验证。
按目标与风险选择：三种方式的组合节奏
选择哪一种方式，先看本次演练要回答的问题，再看能承担多大风险。统一认知用桌面演练，验证技术可行性用模拟切换，验证业务连续性用真实切换。三者可以按下面的决策表对照：
| 演练目标 | 推荐方式 | 风险与投入 | 通过后的下一步 |
|---|---|---|---|
| 新预案首次验证、人员变动后统一认知 | 桌面演练 | 低风险，投入以人时为主 | 技术疑点进入模拟切换 |
| 技术方案或备份链路变更后验证可行性 | 模拟切换 | 中风险，需隔离环境与技术人员 | 通过后评估真实切换条件 |
| 关键系统周期性验证业务连续性 | 真实切换 | 高风险，需停机窗口、业务方与回切保障 | 输出连续性报告并修订预案 |
组合节奏上，桌面演练可以常态化开展，用于维持人员熟悉度和更新联络机制；模拟切换按技术变更触发，每次备份恢复链路或平台版本调整后执行一次；真实切换按年度周期或重大变更后执行，并确保前置条件逐项满足。
升级路径应当写进演练制度：桌面演练暴露的技术疑点必须进入模拟切换的验证清单，模拟切换未通过的项不得进入真实切换评估，真实切换发现的问题回写到预案和脚本，成为下一轮桌面演练的输入。这样三种方式形成闭环，而不是各自独立完成一次就算结束。
演练中的协作承载：从脚本到记录的管理动作
演练的效果很大程度取决于组织协作是否落地：脚本是否是最新版本、待验证项有没有人跟进、上次演练的整改是否关闭。这些动作可以借助文档与工作项工具承载，让演练从一次性活动变成可追踪的例行工作。
具体的管理动作包括三类。第一，把演练脚本、角色清单、检查项作为文档统一维护，每次修订保留版本，确保演练时使用的是当前有效版本。第二，把演练任务、发现的缺陷和待验证项登记为工作项，明确负责人、截止时间和验收标准，避免问题停留在会议记录里。第三，把演练记录与结论归档，作为下次演练的输入和预案修订的依据。
ONES 在数据安全方面通过传输加密、分布式存储、数据备份等措施保障数据安全，数据备份采用多样化备份策略适配客户场景；高可用集群部署方式下基于高可用架构运行，可实现故障转移、数据容灾和零停机服务升级。这些能力构成灾备演练的对象基础，演练脚本、任务跟踪与记录归档则可以放在 ONES 的文档与工作项中统一管理，使演练准备、执行和整改在同一条流程上流转。具体的备份策略、恢复指标与切换机制需结合部署方式和实际场景与厂商确认。
常见问题
三种演练方式必须按顺序做吗，能不能直接做真实切换？
顺序不是硬性规定，但直接做真实切换的风险明显更高。真实切换会触碰生产环境，回切失败会延长业务中断时间，因此通常要求回切步骤已经过模拟验证、数据同步状态已确认、中止条件已定义。如果这些前置条件尚未验证，先做模拟切换把技术路径跑通，再评估真实切换，是更稳妥的做法。对于已经完成过真实切换的系统，仍建议定期用桌面演练维持人员熟悉度。
模拟切换在隔离环境通过后，真实切换还需要重点验证什么？
模拟切换验证的是技术路径可行，隔离环境的负载规模、数据量和依赖关系通常小于生产。真实切换需要重点验证的是业务侧：用户能否正常登录和完成核心操作、接口调用是否稳定、灾备侧持续运行一段时间内的业务可用性，以及回切后切换期间产生的数据如何回补。这些内容在隔离环境中难以完整复现，需要在受控窗口内实际观察。
真实切换的停机窗口应该怎么定，运行多久再回切比较合适？
窗口长度要覆盖切换、灾备侧运行观察和回切三段，并预留异常处置的余量。运行时长应足以覆盖典型业务操作，例如一次完整的登录、核心业务提交和关键接口调用，而不只是确认服务能启动。窗口需要业务方确认并提前告知影响范围，同时明确中止与提前回切的触发条件，避免临场判断。
演练脚本、待验证项和整改记录用什么方式管理比较合适？
可以把演练脚本、角色清单和检查项作为文档统一维护并保留版本，确保演练时使用的是当前有效版本；把演练任务、发现的缺陷和待验证项登记为工作项，明确负责人、截止时间和验收标准；演练记录与结论归档，作为下次演练和预案修订的输入。ONES 的文档与工作项可以承载这些管理动作，使演练准备、执行和整改在同一条流程上流转。
ONES 的备份与容灾能力能为灾备演练提供什么基础？
ONES 通过传输加密、分布式存储、数据备份等措施保障数据安全，数据备份采用多样化备份策略适配客户场景；高可用集群部署方式下基于高可用架构运行，可实现故障转移、数据容灾和零停机服务升级。这些能力构成灾备演练的对象基础。具体的备份策略、恢复指标与切换机制需结合部署方式和实际场景与厂商确认。
