3、恢复目标设定：RTO、RPO、SLA与OLA的关联
做业务连续性规划，最怕什么？
最怕你拍脑袋定目标。我见过太多团队，上来就说“我们要做到RTO=15分钟”，结果一算成本，直接傻眼。今天咱们就聊聊这几个核心指标到底怎么定，它们之间又是什么关系。
3.1 RTO与RPO：一对“冤家”
RTO（恢复时间目标），说白了就是系统挂了之后，你必须在多长时间内把它救回来。比如RTO=1小时，意味着从故障发生到业务恢复，不能超过60分钟。
RPO（恢复点目标），指的是你能容忍丢失多少数据。RPO=5分钟，意味着最多丢5分钟的交易数据。
这两个指标是矛盾的。你想想看：RTO越短，意味着你要准备越多的冗余资源，成本就越高。RPO越短，意味着你要做更频繁的数据备份，对生产系统的影响也越大。
核心原则：RTO和RPO不是拍出来的，是算出来的。我习惯用“业务影响分析（BIA）”的结果来反推这两个值。
举个例子。我在某支付公司做项目时，核心交易系统的RTO定在30秒。为什么？因为业务部门算过，每宕机1分钟，损失约12万元。30秒已经是技术极限了，再短就得换架构，成本翻三倍。
3.2 SLA与OLA：内外有别
SLA（服务等级协议），是你对客户或业务部门的承诺。比如“交易成功率不低于99.99%”。
OLA（运营等级协议），是内部团队之间的承诺。比如“网络团队保证在15分钟内恢复交换机配置”。
这里有个坑，我踩过。有一次我们对外承诺SLA是99.99%，但内部OLA根本没对齐。数据库团队说恢复需要2小时，网络团队说切换需要30分钟，结果一算，根本不可能达到SLA。后来我强制要求：所有OLA必须比SLA严格至少20%。
| 指标 | 对象 | 典型值 | 我的建议 |
|---|---|---|---|
| RTO | 业务恢复时间 | 15分钟~4小时 | 按业务等级分级设定 |
| RPO | 数据丢失量 | 0~1小时 | 核心交易系统建议≤5分钟 |
| SLA | 对外承诺 | 99.9%~99.999% | 留10%~20%余量 |
| OLA | 内部承诺 | 比SLA严格20% | 必须可量化、可测量 |
3.3 它们之间的关联：一张图说清楚
我画了张图，帮你理清这几个概念的关系。你看，SLA是顶层承诺，它决定了RTO和RPO的上限。而OLA是底层支撑，每个内部团队必须用自己的OLA来保证SLA的实现。
我的经验：设定RTO和RPO时，一定要先拿到SLA的承诺。然后反向推导：SLA要求99.99%，那RTO就不能超过30分钟，RPO不能超过5分钟。接着再拆解成各个团队的OLA。这样一层层对齐，才不会出现“对外吹牛、对内打架”的情况。
3.4 避坑指南：我曾经犯过的错
我曾经在一个项目中，把RTO定得太激进。当时业务部门说“必须30秒恢复”，我脑子一热就答应了。结果呢？
- 存储层需要全闪存阵列，成本翻倍
- 网络层需要双活数据中心，运维复杂度暴增
- 应用层需要无状态设计，重构了三个月
最后算下来，为了那30秒，多花了500万。其实业务部门真正的需求是“交易不中断”，30秒只是他们随口说的。后来我学乖了，每次先问三个问题：
- 这个RTO/RPO是业务必须的，还是技术能实现的？
- 有没有更经济的替代方案？比如降级服务、异步处理？
- OLA能不能支撑？每个团队都签字确认了吗？
警告：千万不要把SLA和OLA混为一谈。SLA是对外的，OLA是对内的。对外承诺99.99%，内部OLA必须做到99.999%。为什么？因为内部故障、变更、维护都会消耗时间。留出余量，才是成熟的做法。
3.5 实战：如何设定合理的恢复目标
我建议按以下步骤来：
- 业务分级：把系统分成P0（核心交易）、P1（重要查询）、P2（辅助功能）
- 确定SLA：P0系统SLA=99.999%，P1=99.99%，P2=99.9%
- 反推RTO/RPO：P0的RTO≤15秒，RPO=0（零丢失）；P1的RTO≤5分钟，RPO≤1分钟
- 拆解OLA：每个内部团队认领自己的恢复时间，必须比RTO短20%
- 验证：做一次混沌工程，看看实际能不能达到
嗯，这里要注意。RPO=0听起来很美好，但实现成本极高。你需要同步复制、跨机房容灾、甚至要上分布式一致性协议。我一般只在资金交易类系统上要求RPO=0，其他系统允许5~15秒的丢失。
最后说一句：恢复目标不是一成不变的。业务在发展，技术在进步，每半年重新评估一次，才是负责任的做法。
总结：SLA是承诺，RTO/RPO是技术指标，OLA是内部契约。四者必须对齐，缺一不可。记住：对外承诺要保守，对内执行要激进。