52 lines
3.1 KiB
Markdown
52 lines
3.1 KiB
Markdown
---
|
||
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，无需重新部署
|
||
- 对方观点：代码变更仍需要完整回滚机制作为最后手段
|