---
title: "RTO (Recovery Time Objective)"
tags: [devops, disaster-recovery, sre, reliability]
created: 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]] — 实现配置级热修复的核心机制

## Sources

- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]