上周帮南京的一个电商朋友排查的事故，我现在想起来还冒冷汗。
他们做新的商品推荐页灰度，拍脑袋按用户ID尾号切了10%流量。结果大促当天进来的新用户全被导到了新版本，旧版本的老客反而看不到新的满减入口，当天整体转化率直接掉了8个点。
没人背锅。因为所有人都觉得“切10%流量”是个标准操作。
别把流量切分当成简单的百分比拆分
我见过太多团队刚上灰度平台，第一反应就是“先切5%试试水”。
切的是什么流量？没人说。
是全量用户随机抽5%？是新用户5%？还是年付百万的核心客户5%？
最离谱的一次，我在某互联网公司的分享会上，听一个架构师说他们灰度测试新的支付接口，切的5%流量全是公司内部的测试账号。测了三周没任何问题，一上线直接炸——内部人谁会真的凌晨三点蹲点抢限量秒杀商品啊？谁会真的用这个接口付十万块的货款啊？
流量切分的核心从来不是比例，是你要把新版本暴露给“能承受风险，且愿意给你反馈”的人。
你要是把新版本扔给最核心的付费用户，人家用着出问题，直接要求退款不说，转头就去竞品家买东西了。
很多人忽略了，用户的属性是分层的。你可以按活跃度分，按付费等级分，按设备类型分，甚至按用户所在的城市分——比如你要测新的江浙沪专属满减活动，总不能把流量切给新疆的用户吧？人家根本享受不到包邮，看了活动也没用。
不同业务线的切分逻辑根本不能照搬
我之前跟做To B SaaS的朋友聊，他们灰度新的报表导出功能，切分逻辑完全跟To C的电商反过来。
第一步先切自己公司的运营、产品、技术，所有人每天用这个功能导报表，出问题当场就提。
第二步切三个年付十万以上的老客户，都是合作了三四年的老熟人，就算出了bug，人家也愿意等你修，不会直接发律师函。
第三步才切所有付费客户，最后才开放给免费试用的用户。
要是你把这个逻辑搬到电商业务上试试？先把新版本给免费试用用户？不对，电商的新用户本来就是来薅羊毛的，你给人家看个bug百出的新版本，人家直接把APP卸了，再也不回来。
做内容社区的更不一样。绝对不能先切核心KOL的流量。人家要是刷首页刷到一堆乱七八糟的推荐，转头就发微博吐槽，半个圈子都知道你产品出问题了。我见过最稳的内容平台，灰度新的推荐算法，先切的是日活时长低于30分钟的低活用户，就算算法给人推的全是猫视频、美食视频，人家本来就刷的少，根本不会在意。
支付类系统就更不用说了。谁敢先切新用户的支付流量？人家第一次用你家APP，付钱的时候直接报错，这辈子都不会再打开。做支付的灰度，永远是先切内部员工的1分钱小额支付，跑两周没问题，再切老用户的10块以下小额订单，慢慢放大比例，每一步都要盯着成功率，差0.1个点都要回滚。
最容易被漏掉的两个落地细节
第一个是会话一致性。
别觉得这是小事。我之前用过一个外卖APP，用户第一次打开，走了新版本，看到有个新的满减按钮，点了之后提交订单，突然跳回旧版本，满减直接没了。用户当场就给客服打了三个电话骂。
你得保证同一个用户，在同一次访问会话里，要么全走新版本，要么全走旧版本。甚至最好是，这个用户只要被分到了灰度组，接下来一周都走同一个版本，别来回横跳。来回横跳的体验，比直接给用户看bug还糟糕。
第二个是毫秒级回滚能力。
很多团队的灰度系统，切流量是改配置，配置推送到各个节点要等5分钟。大促的时候5分钟是什么概念？可能几百万的营收就没了。
我见过最稳的团队，切流量的规则直接存在Nginx的本地内存里，改完规则敲一行命令，所有流量秒级切回旧版本。有时候监控告警都还没弹出来，流量已经切完了，用户根本感知不到任何问题。
说实话，很多人把灰度发布吹得特别玄，又是Service Mesh又是服务网格的，好像不用个高端技术就不算做灰度。
哪有那么复杂。
本质上就是别上来就把所有用户扔到没经过真实场景验证的版本里。
对吧？
上次帮那个南京的电商朋友改完切分逻辑，他们后来按新老用户分层切灰度，新推荐页上线一周，转化率比旧版本高了3个点。他特意给我寄了两盒雨花茶，说要不是当时提醒，大促那波损失可能连下半年的服务器钱都赚不回来。
哦对，去年1024程序员节在南京，我还跟几个做运维的老哥在会场外面聊了半小时灰度的坑，大家踩的都差不多，没什么新鲜的。技术这东西，踩的坑多了，自然就知道怎么绕着走了。