灰度.md

什么是灰度

灰度是指让软件逐步地、可控地发布到线上的过程。通过灰度过程，我们有机会可以观察变更对系统的影响，从而判断当前的上线过程是否健康，是否需要回滚。最终确保整个变更的过程稳定性。

灰度核心能力

灰度的核心能力包括三个部分：

• 可控
• 可验证
• 可回滚

可控

可控指通过分阶段发布、功能开关和容量预估等手段，确保发布过程中的影响范围受控，风险最小化，便于快速检测和回滚问题。

• 阶段性发布要求：避免一次性全盘发布，而是采用分阶段方式。每个发布阶段完成后进入暂停状态，由人工或自动化验证决定是否继续。每个灰度发布阶段都需包含明确且经过验证的变更操作步骤、验证检查、回滚步骤及回滚验证检查。

  例如，某系统的日志分析模块升级，可分三阶段进行：

  1. 第一阶段：仅对日志采集部分进行灰度发布，验证日志采集功能是否正常。
  2. 第二阶段：灰度发布日志解析模块，验证日志内容解析是否正确。
  3. 第三阶段：全量发布新版本，确保整体功能正常运行。

  此外，还可以通过发布的影响区域、影响客户来进行阶段划分。例如：

  1. 用户分流：首先将变更应用到测试用户或内部账号。
  2. 业务分流：随后逐步扩展到低优先级业务实例（如冷存储）。
  3. 物理分流：最后推广到核心集群或高优先级业务。
  4. 区域分流：在个区域（region）变更完成并观察、测试无误后，再逐步变更其它区域。

• 功能开关要求：将"部署"和"发布"解耦，在现网环境中安全地发布新功能，支持在不进行新版本部署的情况下动态启用或关闭功能。例如对文件压缩服务增加新格式支持功能：

  1. 部署代码到现网，但通过配置保持新功能关闭。
  2. 使用动态开关逐步启用新功能，先启用部分用户。
  3. 若出现问题，及时关闭功能开关，快速回滚。

• 容量预估要求：发布前应充分评估灰度部分的服务容量，避免因流量分配不当而引发服务故障。例如对搜索服务增加新索引字段的变更：

  1. 模拟真实流量进行性能测试，确保索引查询的延迟可接受。
  2. 灰度发布时，逐步调整流量，避免因资源不足导致查询超时。

可验证

• 检查列表：变更过程中的每个操作都需要配备检查列表，确保操作执行成功且业务效果符合预期。仅在当前操作通过检查后，才能执行下一步。例如在灰度发布支付系统时，检查列表可包括：

  1. 数据库连接是否正常。
  2. 支付接口是否可用。
  3. 核心业务流程是否正常运行。

  对于关键的代码改动点，可能需要提供更准确的验证手段。例如在用户订单服务中新增优惠券功能时：

  1. 为测试用户下发特定优惠券。
  2. 通过日志验证优惠券逻辑被正确触发。

• 自动化：将验证流程尽可能自动化并集成到 CI/CD 系统中，减少重复性人工操作和人为错误。例如发布新版本时：

  1. 自动化测试覆盖新增功能逻辑。
  2. 使用 CI/CD 平台自动触发回归测试。

• 压力测试：灰度验证需要有足够强度以充分验证变更效果。优先使用现网自然流量，当流量不足时，可通过离线任务补充压力。例如对缓存系统的变更进行验证：

  1. 使用现网查询流量进行验证。
  2. 通过脚本模拟高频查询，观察系统稳定性。

• 人工确认：对于难以量化或自动化的验证标准，需要人工介入确认。

可回滚

• 回滚能力要求：所有变更操作必须支持回滚，且回滚后的效果应与变更未发生时一致。例如对存储系统的元数据格式升级：
  1. 升级前备份元数据。
  2. 若升级失败，通过恢复备份数据完成回滚。
• 自动化回滚要求：回滚过程可能涉及多种资源（如二进制文件、配置项、数据文件等），需要能自动化地按正确顺序恢复所有相关资源。例如对 API 网关升级失败时：
  1. 自动切换到上一版本的二进制。
  2. 自动恢复配置文件和日志。
• 原子化操作要求：回滚过程必须具备原子性，避免出现"回滚失败需再次回滚"的复杂场景。例如升级服务时使用事务机制：
  1. 确保所有回滚操作在事务内完成或全部回滚。
• 检查列表要求：回滚操作应与变更操作一样配备完整的检查列表，确保每一步操作成功执行。
• 无法回滚的预案要求：对于无法回滚或回滚代价极高的变更，必须提前制定应急预案。

2. 灰度发布示例