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

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 的应急保障。

实践要点

监控先行：每次放量前确保监控仪表盘就绪
定义回退标准：什么指标触发停止放量或回退？
自动化放量：避免手动操作带来的错误
跨团队对齐：产品、工程、运营需要共同定义放量节奏

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

3.9 KiB Raw Blame History Unescape Escape