1. 先统一语言：发布策略 vs 灰度 vs A/B

这几个词经常被混用，导致“听起来都对、做起来全错”。最清晰的拆法是：

• 发布策略（Rollout strategy）：版本如何在基础设施层面逐步替换（蓝绿/滚动/金丝雀）。
• 灰度（Gradual exposure）：用户/流量逐步暴露到新版本（可以配合任何发布策略）。
• A/B：两个方案同时在线，通过受控实验比较指标（通常是产品/业务实验，也可用于技术验证）。

2. 四种常见策略，一次讲透（适用场景 / 优劣 / 回滚路径）

2.1 蓝绿（Blue-Green）：一刀切切换，最像“开关电源”

蓝绿本质上是两套完全独立的生产环境：旧版本在 Blue，新版本在 Green。 切换时只改变入口路由（DNS/LB/Ingress），把流量从蓝切到绿。

• 适合：需要快速切换、回滚要极快、环境可双份承载。
• 优势：回滚极快（切回入口）；验证更接近“真实生产”。
• 代价：成本高（两套产能）；状态与数据一致性要特别小心。

2.2 滚动（Rolling）：逐个替换，最像“换轮胎”

滚动发布通过逐步替换实例（Pod/VM），让新旧版本短时间共存。它是最普遍、成本最低的默认策略。

• 适合：无状态服务或状态被外置（DB/Cache），对瞬时混跑可接受。
• 优势：无需双份产能；实现简单；平台原生支持（K8s Deployment）。
• 风险：新旧共存时的兼容性（接口、数据、缓存 key）；回滚可能比蓝绿慢。

2.3 金丝雀（Canary）：先给一小群“真实用户”试吃

金丝雀发布强调“按比例放量 + 指标判定”，不是简单的“先发 1 台机器”。它要配合指标与自动止损。

• 适合：风险较高变更；需要用真实流量验证；有完善观测与回滚能力。
• 优势：风险可控；能捕捉 staging 发现不了的生产行为。
• 风险：指标噪声、误判、观察窗口选择；路由能力与标记能力（sticky session）要求更高。

2.4 A/B：不是发布策略，而是实验框架

A/B 关注的是“两个方案同时在线，比较结果”。它常用于产品实验，但在工程上也能用于： 新缓存策略、新算法、新限流策略的风险验证。

• 关键点：随机化、分层（避免样本偏差）、指标定义、实验结束与回收。
• 陷阱：把 A/B 当作“发布策略替代品”，结果是版本与实验纠缠，回滚与追溯变复杂。

3. 金丝雀与灰度的“正确打开方式”：流量曲线 + 观察窗口

金丝雀最容易犯的错是：把它当成“逐步扩容”。真正的金丝雀是逐步扩流 + 指标判定。 你需要三样东西：流量切换能力、发布标记、自动止损。

3.1 一个可复用的扩流节奏

• 比例：1% → 5% → 10% → 25% → 50% → 100%（按系统风险调整）
• 观察窗口：每一步至少覆盖一个“典型周期”（例如 5-15 分钟/1 小时），让指标稳定。
• 保护窗口：刚切流的一段时间，允许短暂波动，但必须有上限。

4. 发布判定与自动止损：让系统帮你“踩刹车”

发布失败不可怕，可怕的是你没有刹车：错误率升高、延迟飙升、资源饱和，但仍然照流程继续扩大。 一个成熟的发布系统必须把“继续/停止/回滚”做成可判定的控制面。

4.1 判定三件套

1. 指标：error rate、latency（P95/P99）、saturation（CPU/内存/队列）
2. 阈值：对比基线（上一版本/同区域/对照组），而不是拍脑袋绝对值
3. 窗口：足够长以抵抗噪声，但足够短以快速止损

5. 最小落地清单（避免“看起来在灰度，实际在赌命”）

1. 回滚先行：回滚脚本/按钮必须比发布脚本更可靠；回滚对象是上一套 bundle。
2. 指标基线：定义对照（上一版本/对照组/同区域），别用“单点绝对值”拍脑袋。
3. 观察窗口：每个扩流台阶至少覆盖一个典型周期；设保护窗口避免冷启动误判。
4. 兼容性设计：滚动/金丝雀都会短暂混跑，接口/数据/缓存 key 必须向后兼容。
5. 秒级止损：关键路径必须有 kill switch（开关/降级/回滚），并演练。