3.0 KiB
3.0 KiB
title, tags, created
| title | tags | created | ||||
|---|---|---|---|---|---|---|
| RTO (Recovery Time Objective) |
|
2026-04-25 |
RTO (Recovery Time Objective)
RTO (Recovery Time Objective) 是指系统发生故障后，业务能够容忍的最大停机时间。它衡量的是恢复速度——从系统下线到用户可以重新使用系统的时间窗口。
Definition
"RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — LaunchDarkly
RTO 是灾备规划的核心指标之一，与 RPO（恢复点目标）共同构成灾备目标体系。
Key Characteristics
| 维度 | 说明 |
|---|---|
| 衡量对象 | 停机时间（Downtime Duration） |
| 起点 | 系统故障发生的时刻 |
| 终点 | 用户可以重新使用系统 |
| 关注点 | 速度（How Fast） |
RTO vs. RPO
RTO 和 RPO 经常被混淆，但衡量的是完全不同的维度：
- RTO — 关注速度：系统多久能恢复？
- RPO — 关注数据：能承受多少数据丢失？
两者可以独立设定：快速恢复不代表数据不丢失，反之亦然。
Tiered RTO Targets
| Tier | 场景 | RTO 目标 | 说明 |
|---|---|---|---|
| Critical | 支付处理、用户认证 | < 5 分钟 | 业务立即停止，需要 3AM 告警 |
| Important | 管理后台、报表 | < 1 小时 | 业务减速但不停止 |
| Nice-to-have | 内部工具、文档站 | < 4 小时 | 仅造成不便 |
RTO in Modern CD Context
传统灾备规划假设 RTO 针对的是硬件故障（服务器宕机、数据中心断电），但现代持续交付中最大的风险来自代码变更：
- 支付流程 Bug 导致结账失败
- 数据库迁移锁死应用
- AI 模型更新产生异常响应
- 新功能在负载下性能骤降
Feature Flag 将 RTO 从小时级降至秒级：只需切换配置，无需重新部署代码。
实现手段
| 方法 | RTO 效果 | 说明 |
|---|---|---|
| 传统灾备（从备份恢复） | 小时级 | 需要重建基础设施 |
| Kill Switch（Feature Flag） | 秒级 | 配置变更，无需部署 |
| 容器化 + 自动扩缩容 | 分钟级 | 需要容器编排平台 |
| Active-Active 多活 | 近零 | 成本极高 |
RTO 与成本的关系
- 近零 RTO 需要"冗余一切"（服务器、数据库、网络、跨数据中心）
- 大多数团队无法承担如此高的成本
- 建议：按应用分层级设定 RTO，而非对所有系统一刀切
"What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it."
Related Concepts
- RPO — Recovery Point Objective，数据丢失量指标
- Disaster Recovery — 灾备策略，RTO/RPO 是其核心目标
- Kill Switch — 通过 Feature Flag 实现秒级 RTO
- High Availability — 高可用性，降低 RTO 的基础设施
- Feature Flag — 实现配置级热修复的核心机制