跨地域容灾演练在很多企业已经不再是新鲜事。资源切换路径、带宽评估、应用恢复顺序都能写进计划，时间表也往往排得很清楚。可真正开始细化演练内容时，最容易陷入拉扯的反而是一个看似基础的指标：RPO 到底该定多少。业务希望数据几乎不丢，运维担心链路和成本承受不了，应用团队又会补充不同系统的数据重要性并不一样。计划已经排好，指标却还在反复争论，说明容灾目标写下来了，但责任边界并没有一起落定。
RPO 之所以总在演练前被重新打开，不是因为大家不懂这个概念，而是因为它同时牵动业务承诺、基础设施能力和数据治理规则。不同系统对数据丢失的容忍度本来就不同，订单、库存、日志、影像、主数据各有自己的恢复要求。如果企业只给出一个统一的“分钟级目标”，却没有说明哪些业务必须达到、哪些可以接受批次补偿、哪些数据只需留存归档，演练就一定会在最后阶段回到抽象争论。
很多团队会把这个分歧理解成“业务要得太高，运维做不到”，其实更常见的问题是 RPO 没有被拆到对象层。运维讨论的是复制链路和同步成本，业务讨论的是交易连续性，数据团队讨论的是一致性和补偿机制。三方说的都对，但不是同一个维度。只要系统分级、恢复点对象和补偿方式没有放进同一张清单，任何一次演练都会重新回到讨价还价。
更稳妥的做法，是在演练前把 RPO 从抽象指标变成业务对象清单。至少要同时明确三项内容：哪些系统或数据对象适用哪个恢复点目标、达到该目标依赖哪些基础设施条件、以及一旦达不到时由谁启动补偿或例外审批。这样演练讨论的就不再是一个泛化数字，而是一组有责任归口的恢复承诺。
在云服务与数字基础设施服务场景里，跨地域容灾真正难的不是把链路搭起来，而是让业务、运维和数据治理对同一套恢复点目标拥有相同理解。尤其多区域、多应用协同环境，RPO 如果没有对象化和责任化，演练次数再多，临场争议也不会减少。
建议企业检查下一次演练前的准备材料：是否已经把关键业务对象、对应恢复点目标和补偿责任写成统一清单。如果仍只是一个总目标数字，说明方案已经排期，但真正的 RPO 治理还没有进入解决方案和新闻栏目的执行闭环。