Auto-sync: 2026-04-24 00:02

wiki/concepts/RTO.md

@@ -1,81 +1,55 @@
 ---
-title: "RTO (Recovery Time Objective)"
-tags: [devops, disaster-recovery, sre, reliability]
-created: 2026-04-25
+title: "RTO"
+type: concept
+tags:
+  - AWS
+  - Disaster Recovery
+  - High Availability
+  - Cloud Architecture
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-23
 ---
 
-# RTO (Recovery Time Objective)
-
-**RTO (Recovery Time Objective)** 是指系统发生故障后，业务能够容忍的最大停机时间。它衡量的是恢复速度——从系统下线到用户可以重新使用系统的时间窗口。
+## Overview
+RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。
 
 ## Definition
+- **RTO**：系统从故障中恢复的时间目标
+- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标
 
-> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — LaunchDarkly
+## AWS Database RTO 对比
 
-RTO 是灾备规划的核心指标之一，与 [[RPO]]（恢复点目标）共同构成灾备目标体系。
+| 数据库服务 | AZ 故障 RTO | 架构特点 |
+|-----------|------------|----------|
+| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 |
+| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 |
+| **传统自建** | 数小时 | 需手动恢复 |
 
-## Key Characteristics
+## RTO vs RPO
 
-| 维度 | 说明 |
-|------|------|
-| **衡量对象** | 停机时间（Downtime Duration） |
-| **起点** | 系统故障发生的时刻 |
-| **终点** | 用户可以重新使用系统 |
-| **关注点** | 速度（How Fast） |
+| 指标 | 定义 | 衡量内容 |
+|------|------|----------|
+| **RTO** | 恢复时间目标 | 系统不可用的最大时长 |
+| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 |
 
-## 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."
+## Key Insights
+- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据
+- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接
+- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面
+- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例
 
 ## Related Concepts
+- [[RPO]]：Recovery Point Objective，恢复点目标
+- [[Disaster Recovery]]：灾备策略
+- [[High Availability]]：高可用性
+- [[Amazon Aurora]]：Aurora 的 RTO 优势
+- [[Amazon RDS]]：RDS 的 RTO 特点
+- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略
 
-- [[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]]
+## Aliases
+- Recovery Time Objective
+- 恢复时间目标
+- RTO
+- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值）