2.8 KiB
2.8 KiB
title, type, tags, date, sources, last_updated
| title | type | tags | date | sources | last_updated | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| RTO vs RPO: Key Differences for Modern Disaster Recovery | source |
|
2019-01-18 |
|
2026-04-19 |
Source File
Summary
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
- 问题域：灾难恢复规划、发布风险管控
- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
Key Claims
- 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：紧急关闭机制，用于快速回滚问题功能
- 渐进式发布：分阶段向用户群 rollout，减少影响范围
Key Entities
- LaunchDarkly：Feature Flag 管理平台
- HP：通过 Feature Flag 将回滚时间从小时降至分钟
- Christian Dior：通过 Feature Flag 将回滚时间从15分钟降至即时切换
Connections
- 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
- （暂无）