1. 从「全量上线」到「渐进交付」：心智模型
Continuous Delivery（CD）解决的是“随时可发布”——流水线、制品、门禁齐备。 Progressive Delivery（PD）在此基础上回答“这一版该不该继续推向更多用户”——把风险切片，用实时信号驱动决策。 二者不是替代关系：CD 管交付能力，PD 管发布节奏与风险暴露面。
2. 金丝雀、蓝绿与特性开关：分工不打架
Canary：按流量比例把新版本暴露给一小撮用户，观察错误率与延迟再扩容权重或回滚。 Blue/Green：两套环境瞬时切换，适合兼容迁移或整站回滚，但瞬时爆炸半径可能更大，需要就绪探针与预热。 Feature flag：在同一二进制内开关代码路径，常与 canary 叠加——先小流量验证基础设施，再用 flag 控制业务功能。
| 机制 | 控制面 | 典型风险 |
|---|---|---|
| Canary + mesh / ingress weight | traffic split per route | metric blind spots · long warm-up |
| Blue / Green | switch entire cutover | large blast if health checks lie |
| Feature flag | code path / audience | flag debt · inconsistent state |
3. Golden signals 与 SLO：别把仪表盘当壁纸
Google 的 Four Golden Signals（延迟、流量、错误、饱和度）是通用起点。生产上还要对齐业务 SLO：例如“下单 API 在 99.9% 的请求中 p99 < 300ms”。 错误预算（error budget）被耗尽时，发布应自动收紧甚至冻结——否则 PD 只是在更快地把事故铺全站。
4. 分析阶段（Analysis）：如何把“感觉不错”变成“可证明”
工具链上常见模式：Argo Rollouts 的 AnalysisRun、Flagger 的 metric templates，或自研任务轮询 Prometheus / Thanos / Datadog。 核心是可重复的规则：成功条件、失败条件、连续成功次数、最大失败次数、查询区间。
# Illustrative Prometheus-style expressions (adjust labels & job names)
# Error ratio over 5m window for the canary ReplicaSet
sum(rate(http_requests_total{status=~"5..", rollout="canary"}[5m]))
/
sum(rate(http_requests_total{rollout="canary"}[5m]))
# p99 latency — compare against baseline or fixed SLO
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{rollout="canary"}[5m])) by (le)
)5. 自动回滚与人工接管：谁按红色按钮？
自动回滚应在策略里写清：触发阈值、持续时间（避免瞬时毛刺）、冷却时间（避免震荡）。 人工批准（manual gate）适合法规、财务或“不可逆副作用”场景——但门开太久会让金丝雀半死不活，需要超时策略与告警。 回滚成功后，流水线应留下可查询记录：哪一版、哪条 query 失败、谁点了 approve。
6. 与 GitOps / CD 控制器协作
声明式 Git 仓库里改镜像 tag，Argo CD / Flux 同步到集群；Rollout 对象接管 Deployment 行为，分段推进 ReplicaSet。 Flagger 常与 Ingress、Gateway API、Istio、Linkerd 等集成，把权重变更与指标检查绑在一起。 下一章将深入 Argo CD 的应用模型；本章只需记住：PD 发生在集群数据面 + 观测面，Git 仍是期望状态的来源。
# Rollout (conceptual) — single service, stepped weights, analysis between steps
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: payments-api
spec:
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 5m }
- analysis:
templates:
- templateName: success-rate
- setWeight: 40
- pause: { duration: 5m }
- setWeight: 1007. 反模式与专业底线
指标虚荣：选容易绿的 KPI，却对用户无感。无基线对比：金丝雀与 stable 的硬件、缓存热度不同，需要同期对照或归一化。 静默失败：分析任务挂了却显示 green。组织层面：没人对 SLO 负责，PD 工具只是更快的甩锅接口。 专业团队会把演练（game day）写进日历：故意注入延迟、验证 rollback 是否在承诺时间内完成。
8. 本章清单
- 为关键路径定义 SLI/SLO 与错误预算；确认指标与用户旅程一致。
- 为金丝雀编写可重复的 analysis 规则：阈值、窗口、连续次数、失败上限。
- 接通自动回滚与告警；为 manual gate 设置超时与升级路径。
- 与第 52 章的配置与开关策略对齐：回滚流量后，flag 状态是否一致？
- 下一章进入 Argo CD：把 Git 期望状态与集群收敛讲透。