灰度发布中的流量切分策略实战避坑指南

去年618前一周，我们组把新的结算页灰度给1%用户，结果财务下午冲过来拍桌子，说当天的客单价数据比前三天掉了12%。我当时蹲在服务器旁边啃包子，汗直接滴到键盘上。

查了半小时才找到原因。

负责切流量的实习生，把“按用户ID尾号切”写成了“按请求随机切”。同一个用户点三次结算，两次进旧版一次跳新版，支付的时候直接懵了。

真的疼。

你以为的切分，其实根本没绑住用户

很多团队刚接触灰度的时候，对流量切分的认知还停留在“配个百分比就行”。10%的请求转新版本，90%留旧版，听着逻辑通顺，实际跑起来全是窟窿。

最基础的切分逻辑从来不是“按比例放流量”，而是“让同一个用户在一次完整的操作链路里，永远落到同一个版本上”。

灰度发布会话粘滞流量切分示意图

你想想，用户打开商品页是旧版，点结算跳新版，填完收货地址点提交又跳回旧版——这哪是灰度，这是故意给用户添堵。上次那个随机切分的事故，我们当天就把所有的切分规则全部加了会话粘滞的逻辑，同一个用户的cookie过期之前，不管发多少请求，都会被固定路由到同一个版本上。

别觉得这是多余的。我见过太多团队，切完流量没做会话保持，跑了两天发现数据乱七八糟，还以为新版本的功能有问题，折腾半天才找到根因。

我最烦那种上来就给你扔一套通用切分方案的文章。你一个做内部OA的团队，和做日活千万的电商平台，能用一样的切分规则？

做内部工具的，直接按员工邮箱前缀切就行，根本不用搞什么复杂的用户分层。反正都是自己人，就算新版本出问题，喊一声就能改，用户容忍度极高。

但做To C核心交易的业务，绝对不要用无差别的随机切分逻辑。我之前认识的一个支付团队，新的风控版本上线，直接切了5%的随机流量，结果把一批经常走境外消费的用户给拦了，当天客服的投诉电话直接被打爆，连夜回滚才把问题压下去。

靠谱的做法是什么？先把新版本的流量，切给过去3个月有过3次以上消费记录的老用户。这批人对平台熟悉，容忍度高，就算遇到点小问题，也不会直接卸载跑路。等这批用户跑了三天没出问题，再慢慢把比例提到新用户群体里。

不过话说回来，也不是所有场景都要搞复杂的分层。比如做内容推荐的业务，你按用户标签切，先给喜欢看科技内容的用户推新的推荐算法版本，反而能更快拿到真实的效果数据。别上来就抄大厂的方案，大厂的切分逻辑是给亿级DAU的业务用的，你一个日活不到1万的小工具，搞那么多规则纯属给自己加活。

说真的，我见过太多团队把灰度发布做成了玄学。配完切分规则就不管了，根本不知道实际有多少流量真的落到了新版本上。

上次我们就踩过这个坑。网关层配了10%的流量转新版本，结果因为路由规则的本地缓存没刷新，实际只有0.3%的流量进去了，我们盯着监控面板等了三天，数据一点变化都没有，还以为新版本的转化率比旧版差，差点直接把方案毙了。

还有两个细节，没人会在入门教程里写。

第一，切分规则一定要支持一键回滚。别等出问题了，还要找运维登服务器改配置，改完还要重启服务，等你弄完，用户都跑光了。我们现在所有的切分规则都存在配置中心里，改完点个发布，十秒就能全量回滚。

第二，不同版本的请求日志，一定要打专属的版本标记。不然你等下查问题，根本分不清哪个请求是旧版处理的，哪个是新版的，翻日志翻到天亮都找不到原因。

上周我们组新上的会员折扣功能，切了5%的老用户流量，跑了三天没出问题，才慢慢把比例提到20%。昨天产品还说，这批老用户给的反馈比之前找的付费测试用户靠谱多了。

哦对，刚才那个写随机切分的实习生，现在已经是我们组的切分规则负责人了。毕竟踩过最疼的坑，才能把规则摸得最透。