攻击发生后，系统“重新启动”不等于业务已经恢复。攻击演练中业务恢复时间目标设定，关键是说清楚：从哪个时点开始计时、恢复到什么服务水平、由谁确认完成。否则，演练结束时即使报出一个时间，也难以判断它能否满足业务需要。
恢复时间目标（RTO）描述业务中断后允许的最长恢复时间；恢复点目标（RPO）则关注可接受的数据回退范围，两者不能互相替代。以下五个误区，常会让目标看似明确、实际却无法验证。
误区一：把“尽快恢复”当成目标
“尽快”没有计时起点，也没有完成标准。建议在演练方案中明确起点，例如事件指挥人员确认主要服务不可用的时刻；终点则以关键用户流程通过验证为准，而不是某台服务器显示在线。
攻击演练中业务恢复时间目标设定可以写成：“从宣布启动恢复流程起，两小时内恢复核心查询与提交功能，并由业务负责人完成验证。”具体时限应由影响评估得出，不能直接套用这一示例。
误区二：给所有业务设同一个时限
批量结算、内部报表和面向客户的身份验证，停摆后的影响不同。统一设置短时限，可能令成本和备份要求不必要地升高；统一设置宽松时限，则可能低估关键流程的风险。
先列出业务流程，评估中断对安全、收入、履约及后续积压的影响，再按优先级讨论目标。可以把“核心功能先恢复、完整功能后恢复”分开记录。分钟级、数小时或更长的目标都可能适用，取决于业务影响、技术能力与恢复成本。
误区三：只看主系统，漏掉恢复依赖
恢复应用不代表用户就能使用。身份验证、数据存储、消息队列、网络连接、密钥管理及人工审批，均可能成为前置条件。依赖顺序不清时，团队容易各自恢复组件，却无法串起完整流程。
演练前画出关键依赖清单，标注负责人、恢复顺序和验证方法；演练中记录每项等待时间。攻击演练中业务恢复时间目标设定应覆盖实际依赖，而非只计算应用启动耗时。
误区四：把服务“上线”误认为业务恢复
首页能打开，不表示订单能提交；数据可读取，也不代表新增记录可以正确写入。目标应对应最低可接受服务：哪些操作必须可用、哪些功能可暂缓、哪些数据需要核对。
设定验证用例时，至少覆盖一条关键端到端流程，并检查数据一致性、权限和错误处理。若先以只读或限量模式恢复，应明确其限制、适用对象和退出条件，避免把降级运行误报为完全恢复。
误区五：只定目标，不测量也不复盘
纸面预案中的预计时间不是演练结果。未计入发现、决策、授权、切换和业务验证，往往会低估真实耗时；只记录总时间，又难以找到瓶颈。
用一次演练校准目标
- 选定范围：写明受影响流程、攻击情境、演练边界及停止条件，优先采用可控的桌面推演或隔离环境测试。
- 统一计时：记录事件确认、决策、恢复动作开始、技术恢复和业务验收的时间点。
- 核对结果：分别比较实际耗时与RTO、实际数据状态与RPO，并记录未完成的功能。
- 改进再测：给问题指定负责人和期限；依赖、权限或操作步骤变更后，安排复测并更新预案。
避免这些误区，攻击演练中业务恢复时间目标设定就不只是填写一个数字，而是把业务优先级、恢复依赖和验收条件转成可验证的承诺。目标应随业务变化和演练证据调整，不能被误解为任何事故下都能保证的恢复时限。
常见问题
RTO从攻击发生时开始算吗？
应在预案中约定计时起点。可选择攻击被确认、业务中断被宣布或恢复流程正式启动的时刻，并在演练与实际响应中保持一致。
RTO和RPO需要设成相同数值吗？
不需要。RTO衡量恢复所需时间，RPO衡量可接受的数据回退范围；业务要求和实现方式不同，数值可能相差很大。
演练未达到目标，是否说明目标设错了？
不一定。先判断是目标不符合业务优先级，还是依赖、权限、备份或操作流程存在缺口，再依据证据修订目标或整改措施。
多久复核一次恢复时间目标？
可在关键系统、业务流程或恢复方案发生变化后复核，并结合定期演练结果调整；具体周期应由组织的风险管理安排确定。
