RTO 实测方法
RTO 是承诺值，实测值才是事实。测量口径要覆盖全链路：从业务不可用被发现开始，经过决策与宣告、执行切换或恢复、业务验证通过，一直到最后确认可用。真实故障里最慢的一段往往不是技术操作，而是发现与决策，所以这几个阶段必须分开计时。
基本信息
| 计时边界 | 统一以『业务不可用』到『业务恢复可用』为准，各系统口径一致 |
|---|---|
| 阶段划分 | 发现故障 → 决策宣告 → 执行恢复或切换 → 数据核对 → 业务验证 |
| 记录人员 | 演练现场指定专人计时与记录，不依赖事后回忆 |
| 产出 | 实测 RTO 与目标差值、各阶段耗时、瓶颈定位与改进项 |
典型使用场景
- 季度演练：按真实流程完整计时，得到可用于对外承诺的实测值
- 预案评审：用历史实测数据判断预案中的目标是否仍然现实
- 改进验证：自动化切换上线后复测，确认耗时是否真的下降
- 故障复盘：真实故障中按同一阶段口径记录，便于与演练值对比
- 资源投入决策：把阶段耗时作为自动化与预置资源的立项依据
阶段计时记录表
阶段计时记录表
阶段 开始 结束 耗时 备注
发现故障 __:__:__ __:__:__ __m__s 监控告警时间
决策宣告 __:__:__ __:__:__ __m__s 值班→指挥确认
执行切换 __:__:__ __:__:__ __m__s 数据库+应用+引流
业务验证 __:__:__ __:__:__ __m__s 核心链路冒烟
---------------------------------------------
实测 RTO 合计 __:__:__ __:__:__ __m__s （对比目标 ____）各阶段常见瓶颈
| 阶段 | 常见耗时来源 | 缩短手段 |
|---|---|---|
| 发现故障 | 告警阈值过宽、告警被忽略、缺拨测 | 加拨测与分级告警，值班到告警的响应纳入考核 |
| 决策宣告 | 授权不清、联系不上决策人 | 预先授权 + 代理顺序，触发条件量化 |
| 执行恢复 | 备份定位慢、依赖人工逐步操作 | 目录化索引、脚本化编排、提前预置环境 |
| 业务验证 | 没有现成冒烟用例、验证靠人工点页面 | 固化冒烟脚本与判定标准，验证人提前到位 |
把实测 RTO 与目标的差值写进演练报告，作为改进投入的依据；差值大的阶段优先做自动化，而不是笼统地要求『提升容灾能力』。
只测技术恢复时间会把 RTO 说得很好看：真故障中决策与验证往往占掉大半时间，对外承诺前务必用全链路口径实测。