灰度发布中的流量切分策略一线实战笔记

上周三凌晨两点，我被做电商的老周电话炸醒。

他说刚上的新结算页，灰度发了5%的流量，结果有个用户把截图甩到客服群，说自己的优惠券突然没了。

查了半小时才发现，他们的切分逻辑居然是按用户ID尾号随机分的——尾号3的全进了新集群，偏偏这批人上周刚领了满减券，刚好撞上新版本的优惠券缓存bug。

你说冤不冤。

别把随机切分当万能解药

很多团队刚摸灰度发布的时候，第一反应就是拿随机切分当万能钥匙，觉得按比例把流量打散，最公平也最省事。

确实，这种方式的配置成本最低，控制台拉个进度条，从0%拉到5%，点保存就完事。但问题就出在，你以为的“随机公平”，在真实业务场景里往往藏着看不见的偏差。

老周那次的坑就是典型——尾号3的用户本来就集中在华东区域，刚好是平台大促期间领券最积极的群体，随机切分5%的流量里，有近3成是这类高价值活跃用户，新版本的优惠券缓存逻辑没做兼容，直接把这部分人的券额算错了。

随机切分不是没用，只是它的适用边界很窄。如果是首页UI微调、文案修改这类完全不涉及用户核心操作的功能，随机切分怎么玩都不会出大错。但只要涉及到支付、优惠券、权限这类和用户行为强绑定的模块，纯随机切分就是给自己埋雷。

你要切的根本不是流量，是特定人群

做了快十年的发布流程优化，我越来越觉得，很多人对流量切分的理解从根上就错了。

切分从来不是为了凑够那个固定的百分比，本质上是把用户群体按“风险承受能力”分层。能扛得住试错成本的人，先接新版本的流量；碰不得的群体，哪怕占比再高，也最后再碰。

最稳妥的第一层切分，永远是内部员工。把公司所有员工的请求路由到新版本，跑满半天的日常使用，自己人踩坑的成本，比外面用户踩坑的成本低一百倍。很多团队跳过这一步，直接把流量切给普通用户，真的是省了芝麻亏了西瓜。

第二层是核心内测用户。就是那些平时愿意给你提反馈、遇到小bug不会直接流失的老用户，甚至可以给点专属的小福利换他们的容忍度。我之前做SaaS产品的时候，专门在切分规则里加了一条：注册7天内的新用户，永远不进第一波灰度范围。毕竟新用户本来就对产品没什么忠诚度，你给他个有bug的版本，他直接就卸载走了，连给你反馈的机会都没有。

说个真事，之前见过某社区团队的切分规则，按运营商把联通用户全导到新版本，结果新版本的接口在联通几个省的节点有跨域问题，页面加载直接慢了3秒，当天的发帖转化率掉了0.8个点，负责人被老板追着骂了整一周。

切分策略的兜底细节，90%的团队都漏了

很多团队把切分规则配完就觉得万事大吉，殊不知真正能防住事故的，全是那些没人在意的小细节。

先说最基础的，切分逻辑必须是无状态的。同一个用户在同一次会话里，不能一会被路由到旧版本，一会又跳去新版本。不然用户点个支付按钮，跳回旧页面，再点又到新页面，体验直接崩到姥姥家。

还有个更要命的点，切分比例的调整必须是可秒级回滚的。我之前经历过一次惊魂时刻，团队同学本来想切1%的流量到新版本，手滑把配置写成了100%，全量流量直接打在还没跑过集成测试的代码上，监控屏的错误率瞬间飙到30%，全组人都吓出一身冷汗。还好当时提前留了一键切回的开关，花了8秒把所有流量拉回旧版本，不然当月的绩效估计都要扣光。

还有个最容易漏的点，必须把灰度集群的监控指标单独拉出来看。很多人只盯着全局的错误率，觉得整体指标正常就没事，殊不知因为灰度流量占比低，哪怕灰度集群的错误率到了5%，被95%的正常流量一平均，全局错误率可能只涨了0.25%，根本看不出异常。等你发现的时候，已经有上千个用户遇到问题了。

其实哪有什么完美的切分策略啊。

所有的规则，本质都是在找那个平衡点——既想早点拿到真实用户的反馈，又怕捅出娄子擦不干净。别上来就硬抄大厂的方案，先把自己的用户分层摸清楚，知道哪部分人愿意陪你试错，哪部分人碰都碰不得，比你背十本SRE手册都有用。