短评：灰度发布不只是“按 10% 放流量”

很多团队把灰度发布理解成“先放 10% 用户，没问题再全量”。但真正决定灰度有没有用的，是你能不能判断这 10% 出了问题。

如果灰度期间只看错误率，那只能发现“服务挂了”这类硬故障。模型输出质量下降、推荐效果变差、页面变慢 200ms，错误率都不会动。灰度要有对应的质量指标，并且这些指标要能按灰度组对比。

另一个常被忽略的点是灰度组和对照组的可比性。按用户 ID 哈希分流是常见做法，但如果新功能只对某类用户有意义，随机分流会导致两组行为差异很大，指标不可比。更稳的做法是按业务维度分层分流，确保两组在关键维度上分布接近。

还有一个工程细节：回滚要快。灰度发现问题时，关开关应该秒级生效，而不是等发布系统重新部署。功能开关和部署解耦，是灰度能真正起作用的工程前提。

灰度不是发布流程里的一个步骤，是一套“可观测 + 可对比 + 可回滚”的能力。没有这三样，按比例放流量只是心理安慰。