RTO 与 RPO 是什么
RTO（Recovery Time Objective）是灾难发生后恢复服务的目标时间；RPO（Recovery Point Objective）是允许丢失的数据时间窗，也就是恢复点距灾难发生时刻的最大间隔。两者由业务影响分析（BIA）结合成本权衡确定，直接决定灾备架构档次：RPO 接近 0 通常意味着同步复制，RTO 以分钟计通常意味着双活或热备。它们写在制度里只是起点，能否达成要靠演练验证。
基本信息
| RTO | 恢复时间目标：多久内必须恢复服务 |
|---|---|
| RPO | 恢复点目标：最多允许丢失多少数据 |
| 确定方式 | 业务影响分析 BIA + 成本与收益权衡 |
| 落地要素 | 切换决策权、演练频率、数据校验标准 |
| 常见盲区 | 只定目标不演练，也没有明确的切换授权链 |
典型使用场景
- 新建核心系统：先做 BIA，再定分级目标，最后才选架构
- 灾备投入论证：把目标折算成架构与带宽成本，与业务损失比较
- 切换与回切演练：验证实际能否达标，并记录真实耗时
- 云上多可用区设计：按 RPO 决定同步复制还是异步复制
- 供应商约束确认：确认云厂商的备份与恢复能力是否满足目标
- 合规与审计：为业务连续性管理体系提供可验证的恢复指标
分级示例（按业务重要性）
| 等级（示例） | RTO | RPO | 常见架构 |
|---|---|---|---|
| 核心交易 | 30 分钟以内 | 接近 0 | 同城双活 + 同步复制 |
| 重要系统 | 4 小时以内 | 15 分钟以内 | 热备 + 异步复制 |
| 一般系统 | 24 小时以内 | 24 小时以内 | 备份恢复 |
| 边缘系统 | 72 小时以内 | 24 小时以内 | 定期备份 + 离线介质 |
演练记录要素
演练记录要素
目标：RTO 30 分钟 / RPO 接近 0
实测：切换耗时 22 分钟，回切 15 分钟
数据校验：核对流水笔数、金额与关键业务表
结论：达标或不达标 + 改进项与负责人
注意：只写目标不做演练，等于没有灾备示例数值仅用于分级讨论，具体应由 BIA 与成本权衡确定；同一系统的不同业务模块也可以有不同的 RTO/RPO。
RTO/RPO 只写在制度里、没有演练与切换授权，真出事时决策链会先耗掉大半恢复窗口。