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

wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md

@@ -1,51 +1,52 @@
 ---
 title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
 type: source
-tags: [DevOps, 灾难恢复, SRE]
-date: 2025-07-26
+tags: [灾难恢复, 业务连续性, 持续交付, 特性管理]
+sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
+last_updated: 2025-07-26
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]]
 
 ## Summary
-- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）在现代持续交付中的差异与应用
-- 问题域：传统灾难恢复规划与现代高频部署场景之间的错配
-- 方法/机制：基于业务影响的三级分层体系、Feature Flag 即时回滚、渐进式发布
-- 结论/价值：Feature Flag 将 RTO 从小时级降至秒级，是现代软件交付的 RPO/RTO 保险策略
+- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
+- 问题域：灾难恢复规划、发布风险管控
+- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
+- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
 
 ## Key Claims
-- RTO 衡量系统从故障到恢复的速度，RPO 衡量可接受的数据丢失量（从故障时刻往前计算）
-- 传统灾难恢复聚焦"稀有大事"（火灾/硬件故障），现代 DevOps 最大风险是代码变更引入的缺陷
-- Feature Flag 将部署（deploy）与发布（release）解耦，实现秒级 RTO
-- RTO 和 RPO 必须同时优化：快速恢复但大量数据丢失，或缓慢恢复但零数据丢失，都是不完整的策略
-- 三级分层系统：Tier 1 关键系统（RTO<5分钟，RPO<1分钟）、Tier 2 重要系统（<1小时，<15分钟）、Tier 3 可选系统（<4小时，<1小时）
-- 渐进式发布（1%→5%→25%→100%）将影响范围控制在局部，将 RTO 从小时降至秒级
-- 成本收益原则：不要为防止 $10K/小时停机损失而花 $100K/年基础设施
-- HP 将回滚时间从小时级降至分钟级；Dior 将 15 分钟回滚降至即时开关
+- RTO 衡量系统恢复速度：允许的最大停机时间
+- RPO 衡量数据保护：可接受的最大数据丢失量
+- 传统灾备聚焦硬件故障，现代风险更多来自代码变更
+- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
+- 应用分层策略：Critical（<5分钟 RTO，<1分钟 RPO）、Important（<1小时 RTO，<15分钟 RPO）、Nice-to-have（<4小时 RTO，<1小时 RPO）
+
+## Key Quotes
+> "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users." — 部署与发布分离的核心价值
+
+> "The best approach is to build both into your deployment process. Feature flags enable you to resolve issues in seconds (a great RTO) while preserving user state and data integrity (a great RPO)." — Feature Flag 双重优势
+
+> "Prevention beats cure. Your RPO stays low because you're not losing data during rollbacks. Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — 预防优于恢复
 
 ## Key Concepts
-- [[RTO]]：Recovery Time Objective，系统可容忍的最大停机时间
-- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量（从故障时刻往前回溯）
-- [[Feature Flag]]：将代码部署与用户可见性解耦，支持即时回滚和渐进式发布
-- [[Kill Switch]]：Feature Flag 的紧急关闭能力，RTO 保险策略
-- [[渐进式发布]]：分阶段（1%→5%→25%→100%）控制影响范围
-- [[Blameless Post-Mortem]]：无责复盘，从失败中提取改进而不追责
-- [[连续数据保护]]（CDP）：持续备份而非定时快照，实现更小 RPO
+- [[RTO (Recovery Time Objective)]]：系统允许的最大停机时间
+- [[RPO (Recovery Point Objective)]]：可接受的最大数据丢失量
+- [[Feature Flag]]：特性开关，控制代码路径而不需要重新部署
+- [[Kill Switch]]：紧急关闭机制，用于快速回滚问题功能
+- [[渐进式发布]]：分阶段向用户群 rollout，减少影响范围
 
 ## Key Entities
-- [[LaunchDarkly]]：Feature Flag 管理平台，86% 客户可在一天内从事故恢复
-- [[HP]]：通过 LaunchDarkly 将回滚时间从小时级降至分钟级
-- [[Christian Dior]]：通过 LaunchDarkly 将 15 分钟回滚降至即时开关
+- [[LaunchDarkly]]：Feature Flag 管理平台
+- [[HP]]：通过 Feature Flag 将回滚时间从小时降至分钟
+- [[Christian Dior]]：通过 Feature Flag 将回滚时间从15分钟降至即时切换
 
 ## Connections
-- [[RTO]] ← 必须与 [[RPO]] 协同优化，不可偏废其一
-- [[Feature Flag]] ← 改变 [[灾难恢复]] 范式：从部署回滚变为配置变更
-- [[Kill Switch]] ← 是 [[Feature Flag]] 的紧急应用场景
-- [[灾难恢复]] ← 已从基础设施层延伸到应用代码层（Feature Flag 角色）
-- [[渐进式发布]] ← 是 [[RTO]] 控制的核心工程实践
+- [[RTO (Recovery Time Objective)]] ← 核心指标 ← [[持续交付]]
+- [[RPO (Recovery Point Objective)]] ← 核心指标 ← [[持续交付]]
+- [[Feature Flag]] ← 实现工具 ← [[RTO (Recovery Time Objective)]]
+- [[Feature Flag]] ← 实现工具 ← [[RPO (Recovery Point Objective)]]
+- [[持续交付]] ← 适用场景 ← [[RTO (Recovery Time Objective)]], [[RPO (Recovery Point Objective)]]
 
 ## Contradictions
-- 与传统灾难恢复观点对比：传统认为"回滚 = 重新部署代码"，本文认为"回滚 = 改变 Feature Flag 配置"
-  - 当前观点：Feature Flag 实现秒级 RTO，无需重新部署
-  - 对方观点：代码变更仍需要完整回滚机制作为最后手段
+- （暂无）