第3章 灰度发布流程总览与责任矩阵
灰度发布不是一次性操作，而是一个可编排、可观测、可回撤的六阶段迭代闭环。本章从全局视角定义规划→配置→监控→扩量→全量→回滚的标准流程，并给出每个阶段中各角色的具体职责边界。掌握本章内容后，读者应能独立搭建灰度发布的完整流程框架，并准确识别自身角色在其中的责任位置。
流程记忆口诀：“规配监，扩全滚；角色跟着流程走，回滚随时可调头。”—— 六阶段中，前五个是正向流程，回滚是贯穿始终的安全兜底机制。
3.1 适用场景
灰度发布六阶段流程适用于以下四类典型场景。如果业务需求符合其中任意一项，建议启用标准化灰度流程。
| 场景类别 | 典型示例 | 流程适配说明 |
|---|---|---|
| 新功能上线 | 推荐算法改版、支付流程重构 | 使用 5%→25%→50%→100% 的渐进扩量，每阶段观察 24h |
| 基础架构变更 | 数据库迁移、服务网格升级 | 重点强化监控与回滚阶段，设置自动化回滚触发器 |
| A/B 实验验证 | UI 改版对比、文案策略测试 | 在规划阶段嵌入实验假设与统计显著性标准 |
| 紧急热修复 | 安全补丁、关键 Bug 修复 | 压缩各阶段观察期，但保留完整的回滚能力 |
3.2 前置条件
进入灰度发布流程前，必须确认以下五项前置条件已全部满足。任何一项不满足，应退回规划阶段进行补全。
- 灰度平台/工具链就绪：已部署灰度发布控制平台（如 LaunchDarkly、云原生灰度发布组件、自研路由网关），支持动态调整流量比例和规则。
- 服务版本标签化：目标服务已实现容器镜像标签（Docker image tag）或 Kubernetes Deployment label，新老版本可独立调度。
- 监控告警体系到位：APM（如 Datadog、SkyWalking）、日志中心（ELK/Loki）、自定义业务指标（如订单成功率、P99 延迟）均已接入，并设定至少三级告警阈值。
- 角色与权限确认：产品经理（PM）、研发工程师（Dev）、测试工程师（QA）、运维工程师（Ops）、发布经理（RM）五类角色均已指定到人，并在流程中拥有明确的审批与操作权限。
- 灰度方案通过评审：灰度发布计划文档（含目标、比例、扩量条件、回滚预案）已完成技术评审，并由发布经理签字确认。
常见断点：很多团队在“监控告警体系”环节准备不足——仅依赖基础 CPU/内存指标，缺乏业务级指标（如转化率、错误率）。请确保监控阶段可同时观察到基础设施指标和业务核心指标，否则扩量决策缺乏依据。
3.3 操作步骤
六阶段流程按串行 + 条件分支方式执行。每个阶段完成后，由发布经理组织决策门评审，决定“继续扩量”、“维持观察”或“触发回滚”。
阶段一：规划
- PM 编写《灰度发布需求说明》，明确发布目标、受众范围、预期指标。
- Dev 进行技术影响评估，识别依赖组件与潜在冲突点。
- QA 制定《灰度验证用例集》，包含冒烟用例、回归用例和灰度专项用例。
- PM 与 RM 共同确定初始灰度比例（通常 5%–10%）、扩量阶梯（如 10% → 25% → 50% → 100%）和每个阶梯的观察窗（通常 30min–24h）。
- RM 组织发布评审，输出《灰度发布计划 V1.0》并归档。
决策门：评审通过 → 进入配置阶段；评审不通过 → 返回需求修订。
阶段二：配置
- Ops 在灰度控制平台创建发布规则：定义流量筛选条件（用户 ID 哈希、地域、设备类型、用户标签等）。
- Dev 将新版服务部署至灰度环境（Canary 环境），确保与生产环境网络隔离或通过路由规则区分。
- Ops 设置监控仪表盘和告警规则：核心指标包括错误率、P99 延迟、服务吞吐量、业务转化率。
- Dev 执行预验证：使用内部测试账号或合成流量模拟灰度请求，确认路由规则和版本响应正确。
预验证通过后，RM 确认“配置就绪”并进入监控阶段。典型的灰度路由规则示例：
# 基于用户 ID 哈希的灰度路由（Nginx Lua 示例）
local user_id = ngx.var.cookie_user_id
local hash = ngx.crc32_long(user_id)
local ratio = hash % 100
if ratio < 10 then
-- 10% 流量进入新版
ngx.var.upstream = "new_version_backend"
else
ngx.var.upstream = "stable_version_backend"
end阶段三：监控
- Ops 持续观察以下三类指标，每 5 分钟记录一次快照：
- 基础设施指标：CPU 使用率、内存占用、GC 频率、网络 I/O。
- 服务指标：请求错误率（5xx/4xx）、P99/P95 延迟、请求量波动。
- 业务指标：订单成功率、用户点击率、注册转化率（视业务定）。
- QA 执行灰度验证用例集，确认功能正确性。
- PM 对比灰度组与基线组的业务指标，评估是否存在统计显著差异。
- RM 收集各方反馈，形成《监控阶段评审报告》。
决策门：指标正常且 QA 验证通过 → 进入扩量阶段；异常或指标劣化 → 触发回滚阶段。
阶段四：扩量
- RM 按灰度计划中的阶梯逐步增加灰度比例（例如 10% → 25% → 50%）。
- 每个扩量步骤完成后，Ops 维持至少一个观察窗（通常为该阶梯的预设时间），重复阶段三的监控动作。
- 若当前阶梯指标平稳，RM 审批进入下一阶梯；若出现波动，暂停扩量并延长观察。
- 扩量至 100% 前，RM 发起《全量发布审批》。
决策门：全量审批通过 → 进入全量阶段；任一阶梯异常 → 触发回滚阶段。
阶段五：全量
- Ops 将灰度规则调整为 100% 流量指向新版（或移除灰度路由配置）。
- Dev 清理临时灰度配置和环境标记，确保版本标签统一。
- RM 发布《全量发布完成公告》，同步至相关团队。
- Ops 持续监控 24h–72h，确认稳定性后关闭灰度控制台中的发布规则。
阶段六：回滚
- 当任意阶段触发异常阈值或人工决策回滚时，RM 立即下达“回滚指令”。
- Ops 执行回滚操作：将流量 100% 切回上一稳定版本，或恢复灰度前的路由配置。
- Dev 与 QA 在回滚后环境执行恢复验证，确认服务状态与指标恢复正常。
- RM 组织根因分析（RCA），输出《灰度发布异常复盘报告》，更新灰度计划知识库。
重要：回滚完成后，流程重新回到规划阶段，将复盘结论纳入下一轮灰度计划。
3.4 输入输出物
| 阶段 | 输入物 | 输出物 |
|---|---|---|
| 规划 | 需求文档、技术设计方案 | 《灰度发布计划 V1.0》、评审纪要 |
| 配置 | 《灰度发布计划》、灰度平台配置模板 | 灰度环境部署记录、路由规则配置单、预验证报告 |
| 监控 | 灰度环境参数、监控仪表盘配置 | 《监控阶段评审报告》、指标快照数据集 |
| 扩量 | 《监控阶段评审报告》、扩量审批表 | 扩量操作日志、各阶梯指标快照、全量审批单 |
| 全量 | 全量审批单、灰度规则配置 | 全量发布完成公告、版本标签锁定记录 |
| 回滚 | 异常告警记录、回滚决策指令 | 回滚执行日志、恢复验证报告、RCA 复盘文档 |
3.5 责任边界
下表横轴为六阶段，纵轴为五类核心角色。单元格中的“R”表示该角色在该阶段承担主要执行/负责职责，“C”表示参与协作/提供输入，“A”表示审批/决策。空白表示该角色在该阶段无直接责任。
| 角色 | 规划 | 配置 | 监控 | 扩量 | 全量 | 回滚 |
|---|---|---|---|---|---|---|
| 产品经理 PM | R（需求定义） | C（确认条件） | C（业务指标评估） | C（业务风险判断） | A（确认发布） | C（影响评估） |
| 研发工程师 Dev | R（技术评估） | R（版本部署、预验证） | C（定位异常） | C（支持扩量） | C（清理环境） | R（回滚执行、RCA） |
| 测试工程师 QA | R（测试用例设计） | C（预验证参与） | R（功能验证） | C（回归测试） | C（全量后回归） | R（恢复验证） |
| 运维工程师 Ops | C（容量评估） | R（环境配置、路由设置） | R（指标监控、告警） | R（扩量操作） | R（全量操作） | R（回滚操作） |
| 发布经理 RM | A（计划评审） | A（配置就绪确认） | A（继续/回滚决策） | A（阶梯审批） | A（全量发布批准） | A（回滚指令下达） |
职责边界要点：
- RM 是六阶段中唯一的全局决策者，拥有“继续 / 回滚”的最终审批权。
- Ops 负责所有操作执行（配置、扩量、全量、回滚），但不承担业务层面的决策。
- PM 的监控重点在业务指标，Ops 的监控重点在服务与基础设施指标，二者互补不可替代。
- 回滚阶段 Dev 与 QA 的职责反转为“修复与验证”，不再推进新功能。
3.6 记录材料
灰度发布全流程需要留存以下七类记录材料，作为审计追溯和经验复用的基础：
- 灰度发布计划（含版本号、灰度比例、阶梯设置、观察窗时长）
- 评审纪要（规划阶段评审会记录，含参会人员、决策意见）
- 配置变更单（灰度路由规则、环境参数变更的详细操作日志）
- 监控指标快照（每个阶段至少三个时间点的核心指标截图或数据导出）
- 审批记录（扩量审批、全量审批、回滚指令的书面或系统审批记录）
- 异常事件报告（如触发告警、扩量暂停、回滚执行等事件的描述与处理过程）
- 复盘报告（灰度发布结束后 3 个工作日内完成的根因分析与改进措施）
3.7 异常处理
| 异常场景 | 触发阶段 | 处理措施 | 责任角色 |
|---|---|---|---|
| 灰度路由未生效，新版本无流量 | 配置 / 监控 | 1. 检查路由规则语法与分发范围 2. 验证版本标签与服务发现是否正确 3. 回退配置并重新部署 |
Dev + Ops |
| 灰度组错误率突增（≥5%） | 监控 | 1. 立即暂停扩量 2. 自动触发告警通知 RM 3. RM 决策是否立即回滚 |
Ops（告警）→ RM（决策） |
| 扩量后 P99 延迟超过基线 2 倍 | 扩量 | 1. 回退至上一扩量阶梯 2. Dev 排查性能瓶颈 3. 优化后重新申请扩量 |
Dev + Ops |
| 回滚操作失败，新版本仍持续接收流量 | 回滚 | 1. 立即切断灰度入口（如将路由指向空端点） 2. 手动摘除新版实例 3. 启动紧急恢复流程 |
Ops（主导）+ Dev（支持） |
| 监控数据延迟或缺失，无法判断状态 | 监控 / 扩量 | 1. 延长当前观察窗，等待数据恢复 2. 检查监控管道（采集→存储→展示）各环节 3. 数据恢复前不进行扩量决策 |
Ops |
回滚时效性要求：从“触发回滚决策”到“流量 100% 切回稳定版本”，必须在 3 分钟内完成。超出该窗口应视为“回滚失败”，启动紧急恢复流程。建议提前演练回滚操作并记录耗时。
3.8 验收标准
每个阶段完成后，需对照以下标准进行验收，确保流程质量：
- 规划阶段验收：灰度发布计划通过评审，包含明确的目标受众、灰度比例、扩量阶梯、观察窗、回滚预案，并由 RM 签字确认。
- 配置阶段验收：灰度环境部署完成，预验证通过（模拟灰度请求返回正确版本），监控仪表盘与告警规则配置到位。
- 监控阶段验收：至少完成一个完整观察窗的指标采集，灰度组与基线组数据可对比，QA 验证用例全部通过。
- 扩量阶段验收：每个阶梯的指标快照已记录且无异常，扩量审批单已归档，下一阶梯已获 RM 批准。
- 全量阶段验收：100% 流量已切换至新版，灰度规则已清理，全量发布公告已发送，24h 跟踪期内无异常。
- 回滚阶段验收：流量已全量切回稳定版本，恢复验证报告显示指标正常，RCA 复盘报告已输出并在 3 个工作日内归档。
整体流程验收：每一轮灰度发布（无论最终是全量还是回滚）完成后，由 RM 在灰度管理平台关闭发布单，并更新《灰度发布知识库》，将本次实践中的关键指标和异常处理经验纳入组织流程资产。