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

上周四在软件谷那家开了快十年的老鹅摊，跟做支付系统的老周拼桌。他灌了半瓶冰啤酒就开始骂。 说上周他们上新版的订单结算页，按老一套的用户ID尾号切了10%流量。结果切到的全是公司内部测试号的尾号段。真实用户没摸到几个，反而测试环境的脏数据把对账系统搞崩了。全组通宵到凌晨三点。 他说那通财务的问责电话打过来的时候，手里的冰啤酒都没味道了。 真的。

那些被想当然的切分规则坑过的夜晚

很多人对流量切分的认知，还停留在“随便划10%的用户到新版本就行”的阶段。别不信，我见过至少十几个团队的灰度方案，切分规则写的跟过家家一样。 最常见的坑就是按用户ID或者IP的尾号切，默认这样切出来的流量是均匀的。大错特错。 你做To C的普通产品还好，用户分散，尾号切分的偏差不会太大。但要是你做To B的SaaS，客户都是批量生成的企业账号，尾号1到10的可能全是同一家大客户的几百个员工。你切10%的流量，等于直接把这家客户的全量流量导到新版本。人家要是用着觉得不对，直接拍工单找你，你连辩解的余地都没有。 更别说很多人写切分规则的时候，压根没想过要过滤内部测试号、爬虫IP、已经标记的风险用户。老周这次踩的就是这个坑——他们的测试号全是尾号0到9的固定段，之前的切分规则没加过滤，直接把10%的流量全导去了测试池，真实用户半毛钱没碰到。

不同业务场景该选哪种切分逻辑

没有放之四海而皆准的切分规则，得跟着你的业务场景走。 要是你做的是普通内容类、工具类的C端产品，用户之间几乎没有关联性，那用用户ID哈希取模切就足够。记得先把所有内部账号、爬虫IP、风险用户从切分池里剔除干净。比如你要切5%的流量，就把所有有效用户的ID做哈希，取模20，结果为0的那部分进灰度池。这样每次切的用户都是固定的，不会今天张三在灰度池，明天又跑回老版本，用户体验不会反复横跳。 要是你做的是To B的企业服务，那就绝对不能按单个用户ID切。得按租户ID也就是客户企业的唯一标识做整体切分。比如你有100家付费客户，先找10家愿意配合测试的，全量把这10家的流量导到新版本，剩下的90家还是用老版本。这样就算新版本有问题，影响的也是提前沟通过的客户，人家有心理准备，不会突然炸锅。而且你拿到的反馈都是真实的企业场景，比你乱切一堆散客的零散反馈有用多了。 要是你做的是核心交易链路，比如支付、结算、下单这种，出一点问题都是真金白银的损失，那切分逻辑就得更保守。不能碰真实用户的常规流量，得按请求头里的灰度标记做精准透传。比如你要测试新的支付回调逻辑，就先让内部测试账号发请求的时候，在请求头里带个特定的灰度标记，网关看到这个标记就直接把请求导到灰度的服务实例，其他所有真实用户的请求一概碰都不碰。等内部测的没问题了，再找几个主动报名的商家，给他们的商户号打个标记，小流量逐步导入，绝对不能一开始就把真实用户的流量切进去。

落地前必须核对的几个细节

别觉得选对了切分逻辑就万事大吉，很多坑都是在落地的时候没注意细节踩的。 第一个要盯的是流量爬坡的节奏。别上来就切10%、20%的流量，第一次放的灰度流量最多1%，甚至0.1%，先跑24小时，看监控有没有异常，再慢慢往上加。老周上次要是先切0.1%的流量，根本不会搞出对账故障。 还有一个容易漏的，是所有切分规则必须有可秒级回滚的开关。别搞那种切了之后要改代码重新发版才能切回去的方案，遇到问题你根本来不及救。最好是在网关层做配置开关，改个数字，点一下确认，几秒钟就能把所有流量切回老版本。有这个开关和没这个开关，遇到问题的时候的状态，谁通宵谁知道。真的能少掉半条命。 另外别忘了，别光盯着后台的监控指标。比如你切了流量之后，新版本的页面加载速度快了20%，但是用户的投诉率涨了，那肯定是哪里有问题。我之前有个朋友做新版购物车，加载速度快了，但是把原来的优惠券入口藏到了三级菜单里，用户找不到，投诉率直接涨了30%。还好他们当时只切了5%的流量，赶紧切回去改了入口，没出大问题。 上周老周后来跟我说，他们把切分规则改了。先过滤所有内部测试账号，然后按租户ID切，先找了两家关系好的老客户，全量导到新版本，跑了一周没出问题，才慢慢把流量涨到20%，现在新版本已经全量了，也没什么幺蛾子。 不过话说回来，也不用把灰度发布搞的太复杂。不是说非要搞什么机器学习的智能切分，大部分业务场景，你把规则想的周全一点，比什么花里胡哨的功能都管用。