灰度发布基础：概念、目的与常见策略
灰度发布（Gray Release / Canary Release）是SRE在生产环境中逐步引入新版本、验证稳定性并控制爆炸半径的核心手段。在SLO自愈剧本中，灰度发布是“执行策略”的载体——剧本通过灰度流量控制来触发、观测和回滚变更。本节从概念、目的和三种经典策略入手，建立灰度发布的知识底座。
1. 灰度发布的概念与目的
灰度发布是指将新版本的服务或功能先部署到一小部分用户或实例上，在真实流量下验证其正确性与稳定性，确认无异常后再逐步扩大范围，直至全量上线。它与蓝绿部署、滚动部署共同构成生产变更的“安”。
| 维度 | 说明 |
|---|---|
| 核心思想 | 小范围验证 → 观测指标 → 逐步放量 → 全量上线 |
| 主要目的 | 降低变更风险、缩短故障影响半径、支持A/B测试与SLO验证 |
| 与SLO自愈的关系 | 灰度期间实时监控SLO达成率，一旦SLO违规则触发自动回滚或暂停放量 |
| 适用场景 | 新功能上线、配置变更、依赖升级、模型更新等 |
关键原则：灰度发布不是“发布完成”就结束，而是“观测完成”才结束。SLO自愈剧本要求在灰度每一步都设置明确的SLO阈值，作为继续放量或回滚的决策依据。
2. 三种常见灰度策略
生产环境中，金丝雀发布、蓝绿部署和滚动部署是最常用的三种策略。它们各有优劣，适用于不同的服务架构和风险偏好。下表从核心机制、流量切换方式、回滚速度、资源成本和SLO适配性五个维度进行对比。
| 策略 | 核心机制 | 流量切换方式 | 回滚速度 | 资源成本 | SLO适配性 |
|---|---|---|---|---|---|
| 金丝雀 | 新版本部署到少量实例，逐步增加流量比例 | 负载均衡权重/路由规则 | 快（调整权重即可） | 低（复用部分实例） | 高（可精细控制流量比例） |
| 蓝绿 | 同时运行两套完整环境，一次性切换流量 | DNS/负载均衡全量切换 | 极快（秒级切回） | 高（双倍资源） | 中（全量切换，观测粒度粗） |
| 滚动 | 逐批替换旧版本实例，每批完成后再替换下一批 | 实例逐步替换 | 慢（需逐批回滚） | 低（不额外占用资源） | 中（依赖批次大小控制） |
3. 金丝雀发布详解
金丝雀发布是SLO自愈剧本中最常用的策略。它通过将新版本部署到一小部分实例（如1%～5%），在真实流量下验证SLO指标，确认无异常后再逐步增加流量比例。
实践建议：金丝雀的初始比例建议从1%开始，观测周期至少覆盖一个完整的业务高峰周期（如15～30分钟）。每次放量比例建议不超过当前流量的2倍，避免突变导致SLO抖动。
典型步骤：
- 部署新版本到金丝雀实例组（通常1～3个实例）。
- 通过负载均衡将1%～5%的流量路由到金丝雀组。
- 实时监控SLO指标（延迟、错误率、吞吐量）。
- 若SLO达标，逐步增加流量比例（如5% → 10% → 25% → 50% → 100%）。
- 若SLO违规，自动将金丝雀组流量切回旧版本，并触发告警。
4. 蓝绿部署详解
蓝绿部署维护两套完全独立的环境（蓝环境=当前生产，绿环境=新版本）。部署完成后，通过路由规则一次性将流量从蓝环境切换到绿环境。回滚时只需切回蓝环境。
注意：蓝绿部署的资源成本是其他策略的2倍，且全量切换的观测粒度较粗。如果新版本存在性能退化，全量切换后可能瞬间影响所有用户。建议在切换前先做小流量验证（如通过内部用户或影子流量）。
典型步骤：
- 在绿环境部署新版本，完成集成测试。
- 保持蓝环境继续服务生产流量。
- 通过DNS或负载均衡将流量全量切换到绿环境。
- 观测SLO指标，若达标则保留绿环境，下线蓝环境。
- 若SLO违规，立即切回蓝环境，绿环境保留用于问题排查。
5. 滚动部署详解
滚动部署通过逐批替换实例来更新服务。每批替换完成后，等待健康检查通过，再替换下一批。它不额外占用资源，但回滚速度较慢。
典型步骤：
- 从负载均衡中摘除一批实例（如10%）。
- 将摘除的实例更新为新版本。
- 将更新后的实例重新加入负载均衡，等待健康检查通过。
- 观测SLO指标，确认无异常后继续下一批。
- 若某批出现SLO违规，暂停滚动并回滚已更新的实例。
滚动部署的SLO风险：由于每批替换后流量会重新分布，可能导致剩余旧实例负载突增，引发SLO抖动。建议在滚动过程中保持最小实例数不低于服务容量的70%，并配合HPA自动扩缩容。
6. 三种策略的SLO自愈适配对比
在SLO自愈剧本中，选择哪种灰度策略取决于服务架构、SLO敏感度和资源预算。下表从自愈剧本的执行角度给出适配建议：
| 策略 | 自愈剧本适配度 | 推荐场景 | 不推荐场景 |
|---|---|---|---|
| 金丝雀 | ★★★★★ | 微服务、API网关、用户端功能 | 无负载均衡能力的单体服务 |
| 蓝绿 | ★★★★☆ | 数据库迁移、重大架构变更 | 高频迭代、资源受限环境 |
| 滚动 | ★★★☆☆ | 无状态服务、容器化部署 | 有状态服务、SLO极敏感场景 |
7. 灰度发布流程总览
下图展示了从新版本就绪到全量上线的完整灰度流程，以及SLO自愈剧本在每一步的介入点：
8. 灰度策略选择矩阵
在实际项目中，SRE需要根据服务特性、团队能力和SLO要求选择最合适的策略。以下矩阵可作为快速决策参考：
| 服务特征 | 推荐策略 | 理由 |
|---|---|---|
| 无状态、实例数多（≥10） | 金丝雀 | 可精细控制流量比例，回滚快 |
| 有状态、数据迁移 | 蓝绿 | 全量切换可保证数据一致性 |
| 容器化、Kubernetes环境 | 滚动 | 原生支持，资源利用率高 |
| SLO极敏感（如99.99%） | 金丝雀 + 蓝绿组合 | 先金丝雀验证，再蓝绿全量切换 |
| 资源预算紧张 | 滚动 | 不额外占用资源 |
进阶思考：在SLO自愈剧本中，灰度策略不是固定的。建议将策略选择参数化，通过配置中心动态调整。例如：白天使用金丝雀（精细控制），夜间使用滚动（快速迭代），重大变更使用蓝绿（安全兜底）。