1. 灰度发布概述
1.1 灰度发布定义
灰度发布（Gray Release / Canary Release）是一种渐进式的软件发布策略，它将新版本先小范围推送给部分用户或流量，在验证稳定性和正确性后，再逐步扩大发布范围，直至全量覆盖。其核心思想是“先验证、后全量”，通过控制风险半径来保障生产环境的持续可用。
关键特征： 灰度发布不是一次性操作，而是一个由多个验证阶段组成的递进过程，每个阶段都包含流量切换、指标观测、决策判断三个核心动作。
1.2 核心目标
灰度发布的核心目标可以归纳为以下四个维度：
| 目标维度 | 具体描述 | 关键指标示例 |
|---|---|---|
| 风险控制 | 将变更影响范围限制在最小可控集合内，避免全量故障 | 爆炸半径、影响用户数 |
| 快速验证 | 在生产环境用真实流量验证新版本的功能正确性与性能 | 错误率、P99延迟、吞吐量 |
| 业务连续性 | 发布过程中保持服务可用，用户无感知或低感知 | 可用性SLA、零宕机时间 |
| 决策数据化 | 基于量化指标而非主观判断决定是否继续放量或回滚 | 指标置信度、统计显著性 |
SRE 视角： 灰度发布是“混沌工程”在生产环境中的轻量级实践——通过主动引入可控的变更（新版本），观测系统行为是否符合预期，从而建立对系统稳定性的信心。
1.3 与传统发布对比
传统发布（Big Bang Release）与灰度发布在多个维度存在本质差异。下表从策略编排的角度进行对比：
| 对比维度 | 传统发布（全量发布） | 灰度发布（渐进式发布） |
|---|---|---|
| 发布方式 | 一次性替换所有实例 | 分阶段、按比例逐步切换 |
| 风险暴露 | 瞬间暴露全部风险，故障影响面大 | 风险逐步暴露，可随时暂停或回滚 |
| 回滚成本 | 高，需全量回退，可能涉及数据兼容 | 低，仅回滚灰度流量，基线版本仍在运行 |
| 验证手段 | 依赖预发/测试环境，与生产有差异 | 直接在生产环境用真实流量验证 |
| 用户感知 | 所有用户同时切换，感知明显 | 仅小部分用户感知，可设置白名单 |
| 策略编排 | 无编排，一次性操作 | 需要编排多个阶段，每个阶段有独立策略 |
| 决策依据 | 发布前人工审批 | 发布中实时指标 + 自动化决策门禁 |
1.4 灰度发布在策略编排中的定位
在《策略编排灰度验证阶段划分方法》课程中，灰度发布不是终点，而是策略编排的载体。本课程将围绕以下核心问题展开：
- 阶段如何划分？ 从 1% 灰度到 100% 全量，中间应该设置多少个验证阶段？每个阶段的流量比例如何确定？
- 每个阶段验证什么？ 功能正确性、性能稳定性、业务指标、兼容性……不同阶段的验证重点有何不同？
- 如何编排策略？ 流量路由策略、观测策略、门禁策略、回滚策略如何组合成一个可执行的灰度方案？
- 如何自动化决策？ 基于实时指标自动判断是否进入下一阶段，还是需要人工介入？
常见误区： 很多团队将灰度发布简单理解为“先发 10% 再发 100%”，忽略了中间验证阶段的设计。没有明确的阶段划分和验证标准，灰度发布就退化为“分批发布”，失去了风险控制的核心价值。