wiki-ingest batch 4: DevOps Culture + RTO/RPO + 三种云模型 (2026-04-16 03:02)

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

@@ -0,0 +1,51 @@
+---
+title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
+type: source
+tags: [DevOps, 灾难恢复, SRE]
+date: 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 保险策略
+
+## 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 分钟回滚降至即时开关
+
+## 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
+
+## Key Entities
+- [[LaunchDarkly]]：Feature Flag 管理平台，86% 客户可在一天内从事故恢复
+- [[HP]]：通过 LaunchDarkly 将回滚时间从小时级降至分钟级
+- [[Christian Dior]]：通过 LaunchDarkly 将 15 分钟回滚降至即时开关
+
+## Connections
+- [[RTO]] ← 必须与 [[RPO]] 协同优化，不可偏废其一
+- [[Feature Flag]] ← 改变 [[灾难恢复]] 范式：从部署回滚变为配置变更
+- [[Kill Switch]] ← 是 [[Feature Flag]] 的紧急应用场景
+- [[灾难恢复]] ← 已从基础设施层延伸到应用代码层（Feature Flag 角色）
+- [[渐进式发布]] ← 是 [[RTO]] 控制的核心工程实践
+
+## Contradictions
+- 与传统灾难恢复观点对比：传统认为"回滚 = 重新部署代码"，本文认为"回滚 = 改变 Feature Flag 配置"
+  - 当前观点：Feature Flag 实现秒级 RTO，无需重新部署
+  - 对方观点：代码变更仍需要完整回滚机制作为最后手段