Auto-sync: 2026-04-22 04:02

wiki/concepts/Progressive-Rollout.md

@@ -0,0 +1,106 @@
+---
+title: "Progressive Rollout (渐进式放量)"
+tags: [devops, continuous-delivery, feature-management, risk-mitigation]
+aliases: [Canary Deployment, 灰度发布, Canary Release]
+created: 2026-04-25
+---
+
+# Progressive Rollout (渐进式放量)
+
+**Progressive Rollout**（渐进式放量/灰度发布）是一种通过 [[Feature Flag]] 控制新功能逐步向用户群发布的风险管理策略。与"全有或全无"的传统部署不同，Progressive Rollout 将影响范围控制在最小范围内，从而实现**可量化的 RTO**。
+
+## Aliases
+- Canary Deployment
+- Canary Release
+- 灰度发布
+- Staged Rollout
+
+## Core Mechanism
+
+> "Instead of flipping the switch for everyone simultaneously, roll out gradually."
+
+```
+1% 用户  → 观察错误率、性能指标
+5% 用户  → 监控转化率、用户反馈
+25% 用户 → 检查下游系统负载
+100% 用户 → 完成全量发布
+```
+
+## Progressive Rollout vs. Big Bang Release
+
+| 维度 | Big Bang（全量发布） | Progressive Rollout（渐进式放量） |
+|------|---------------------|----------------------------------|
+| 影响范围 | 全部用户 | 受控小群体 |
+| 问题发现 | 事后 | 事中（1% 阶段即可发现） |
+| RTO（如果出问题） | 小时级（紧急回滚） | 秒级（关闭开关） |
+| 回滚风险 | 可能丢失新事务 | 无数据损失 |
+| 团队压力 | 高（2AM 部署） | 低（白天放量） |
+| 反馈收集 | 事后分析 | 实时监控 |
+
+## RTO 重新定义
+
+> "If something breaks at the 5% mark, you've contained the damage. Your RTO is measured in seconds (flip the flag off) instead of hours (emergency rollback deployment)."
+
+| 场景 | RTO（Big Bang） | RTO（Progressive Rollout） |
+|------|-----------------|---------------------------|
+| 发现问题 | 全量发布后 | 1% 阶段即可监控到 |
+| 止血时间 | 小时级（回滚部署） | 秒级（关闭开关） |
+| 受影响用户 | 100% | 最多 5%（当前阶段） |
+
+## 放量策略
+
+### 基于用户群体的定向放量
+
+| 策略 | 说明 | 适用场景 |
+|------|------|----------|
+| 随机抽样 | 随机选取 X% 用户 | 通用场景 |
+| 地区定向 | 先在特定地区放量 | 法规合规、时区测试 |
+| 用户分层 | 优先向付费用户放量 | 降低高价值用户风险 |
+| 设备类型 | 先桌面后移动 | 移动端兼容性风险 |
+| Beta 用户 | 先向内部/Beta 用户开放 | 需要早期反馈 |
+
+### 基于指标的自动 gates
+
+```yaml
+rollout_stages:
+  - percentage: 1
+    gates:
+      - error_rate < 0.1%
+      - p95_latency < 500ms
+  - percentage: 5
+    gates:
+      - conversion_rate > baseline - 5%
+      - support_tickets < 10
+  - percentage: 25
+    gates:
+      - downstream_api_latency < 200ms
+      - no_critical_errors
+```
+
+## 与 [[Kill Switch]] 的关系
+
+Progressive Rollout 和 Kill Switch 是同一机制的两面：
+
+- **Progressive Rollout**：控制功能如何到达用户（渐进式）
+- **Kill Switch**：在发现问题时紧急切断（防御性）
+
+两者结合 → 既有渐进放量的可控性，又有 Kill Switch 的应急保障。
+
+## 实践要点
+
+1. **监控先行**：每次放量前确保监控仪表盘就绪
+2. **定义回退标准**：什么指标触发停止放量或回退？
+3. **自动化放量**：避免手动操作带来的错误
+4. **跨团队对齐**：产品、工程、运营需要共同定义放量节奏
+
+## Related Concepts
+
+- [[Feature Flag]] — Progressive Rollout 的技术基础
+- [[Kill Switch]] — Progressive Rollout 的应急保障
+- [[RTO]] — Progressive Rollout 将 RTO 从小时降至秒级
+- [[Deployment-vs-Release]] — Progressive Rollout 实现部署与发布的解耦
+- [[Micro-Recovery]] — Progressive Rollout 支持 feature 级别的精准恢复
+
+## Sources
+
+- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]