灰度发布的工程闭环：从百分比放量到流量标记

「灰度发布」这个词被说烂了，但很多团队的灰度其实只有半截：上了灰度比例，没有闭环。真正的灰度是「放量 → 观察 → 判断 → 收敛」的完整回路，缺任何一环，灰度就退化成「慢性自杀」——问题版本慢慢放给全部用户。这篇把闭环的四个环节逐一拆开。

环节一：放量策略——百分比是最粗糙的刀

按请求百分比放量（1% → 10% → 50%）是默认姿势，但它有个盲区：流量不是均匀的。1% 的随机流量可能全是爬虫和健康检查，真实用户一个没进来。更可控的放量维度：

• 按用户 ID 哈希：同一用户稳定命中或不命中新版本，避免「一个用户一半请求新一半旧」的状态混乱
• 按白名单 → 内部员工 → 种子用户 → 全量的阶梯，前两档几乎是零成本的验证
• 按流量特征：先放开非关键路径（读接口），再放开关键路径（写接口、支付）

环节二：观察——指标要带基线

灰度期的核心指标（错误率、延迟、业务转化）必须新旧对照组同时看，而不是只看新版本的绝对值。原因：大盘本身有波动（午高峰错误率天然比凌晨高 3 倍），没有对照组，你分不清「新版本的问题」和「时间的波动」。工程上把灰度流量和基线流量打上不同的版本标签，监控面板按标签分列——这一步很多人没做，做了的人都说香。

环节三：判断——规则前置，不靠临场发挥

放量到下一档的条件要在灰度开始前写死：错误率相对基线抬升 <0.1% 且 P99 延迟劣化 <10% 持续 30 分钟 → 放下一档；任一触红线 → 自动回滚或冻结在当前档位。判断规则事前定，是灰度纪律的核心——凌晨三点的事故现场，没有人能做出好决策，只有自动化规则靠得住。

环节四：收敛——灰度要有终点

两个常见烂尾：一是灰度停在 50% 再也不动（新版本长期半信半疑地跑着，配置分裂成两套）；二是全量之后灰度开关忘关（残留的流量标记影响后续排查）。收敛动作清单：全量确认 → 关闭灰度开关 → 清理流量标记 → 灰度配置归档（下次发布复用模板）。

一个容易被忽略的前置条件

灰度发布的前提是可回滚：数据库变更向前兼容（新旧版本能共存于同一 schema）、特性开关（feature flag）独立于部署存在。不满足这两条的「灰度」是伪灰度——发现问题你只能紧急修，不能回，灰度就失去了意义。

灰度不是发布策略里的一个选项，是发布体系的成熟度标志。闭环四环节里最弱的那个，就是你下次事故的入口。

（发布工程系列：熔断降级 → 配置治理 → 本文：灰度闭环）