Auto-sync: 2026-04-16 17:30

wiki/concepts/RTO.md

@@ -1,36 +1,29 @@
 ---
-title: "RTO"
+title: "RTO (Recovery Time Objective)"
 type: concept
-tags: [DevOps, SRE, 灾难恢复]
-last_updated: 2026-04-16
+tags: [灾难恢复, 业务连续性, 指标]
+sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
+last_updated: 2025-07-26
 ---
 
-## 定义
-Recovery Time Objective（恢复时间目标）：系统从故障发生到完全恢复可用的最大可容忍时间。
+## Definition
+RTO（Recovery Time Objective，恢复时间目标）是指系统允许的最大停机时间。是从系统下线到恢复上线的最大可接受时间窗口。
 
-## 计算方式
-从系统故障时刻开始计时，到用户可以再次正常使用系统为止。
+## Key Characteristics
+- 衡量恢复速度，而非数据丢失
+- 时钟从系统下线时刻开始计时
+- 与业务影响直接相关
+- 需要与 RPO 共同规划，不能只优化其中一个
 
-## 典型场景与目标
-| 场景 | RTO 目标 | 原因 |
-|------|---------|------|
-| 电商支付系统 | <5 分钟 | 停机直接损失收入 |
-| 实时聊天 | <30 秒 | 用户期望即时响应 |
-| 用户分析仪表盘 | <30 分钟 | 停机影响有限 |
-| 内部 CRM | <4 小时 | 可人工 workaround |
-| 博客/营销站点 | <2 小时 | 业务影响相对较小 |
-
-## 与 RPO 的关系
-- RTO 是速度指标，RPO 是数据完整性指标
-- 两者必须协同优化：快速恢复但丢大量数据，或缓慢恢复但零数据丢失，均不完整
-
-## 与 Feature Flag 的关系
-- Feature Flag 将 RTO 从"部署回滚时间"（小时级）降至"配置变更时间"（秒级）
-- Kill Switch 是实现秒级 RTO 的核心机制
+## Tiered RTO Targets (from this source)
+| Tier | Examples | RTO Target |
+|------|----------|------------|
+| Critical | Payment processing, user auth | < 5 minutes |
+| Important | Admin dashboards, reporting | < 1 hour |
+| Nice-to-have | Internal tools, dev environments | < 4 hours |
 
 ## Connections
-- [[RPO]] ← 协同指标，共同构成灾难恢复策略
-- [[灾难恢复]] ← RTO 是其核心衡量指标
-- [[Feature Flag]] ← 实现秒级 RTO 的工程手段
-- [[Kill Switch]] ← RTO 保险策略
-- [[LaunchDarkly]] ← 企业级 RTO 改善工具
+- [[RPO (Recovery Point Objective)]] ← 配对指标 → [[RTO (Recovery Time Objective)]]
+- [[灾难恢复]] ← 应用领域 → [[RTO (Recovery Time Objective)]]
+- [[持续交付]] ← 现代上下文 → [[RTO (Recovery Time Objective)]]
+- [[Feature Flag]] ← 降低工具 → [[RTO (Recovery Time Objective)]]