上周跟做电商的老陈撸串，冰啤刚喝了半瓶，他把手机往桌上一摔，说上个月大促前的灰度差点把他送走。
当时他们要上新版的结算页，技术组图省事，直接在网关配了10%的流量权重切到新集群。
谁知道刚好那10%的随机流量里，凑了七成是华南区的高净值用户——这些人用的旧版安卓APP，刚好和新版本的结算接口没做兼容，支付直接报错。
半天时间赔了快十万的优惠券，还被用户投诉到平台总部。
这坑我太懂了。
别上来就按百分比切流量
很多团队对灰度的理解，就是“切10%流量试试看”，完全不管这10%的流量到底是谁。
随机切的流量，本质上就是抽奖。你永远不知道这次抽中的是只看一眼就走的新用户，还是每天刷八小时的重度核心用户。
我之前在资讯平台做的时候，刚开始也这么干。切了5%的流量到新版本的推荐系统，本来想着小范围测测效果。
结果刚好抽中的全是凌晨刷资讯的重度用户，新版本的推荐模型还没调优，把用户常看的科技内容全换成了娱乐八卦。
投诉邮箱爆了三天，后台的卸载率直接涨了两个点。
说白了，按百分比切的唯一作用，就是测试新集群能不能扛住流量。真要测功能，这方法根本不靠谱。
你以为你测的是10%的平均用户，实际上可能测的是10%的极端用户。出了问题你连根因都找不到——你根本不知道那批用户有什么共性。
别偷懒。
按用户标签切才是真的稳
后来我们踩多了坑，才慢慢摸出了门道。切流量的核心不是切多少，是切谁的。
我们现在的灰度流程，第一步永远是切内部人员的流量。
所有测试、产品、运营的账号，请求头里直接打个内部标签，网关直接把这批请求全导到新版本。跑个三天，连内部人都觉得没问题了，再往下走。
第二步切种子用户。就是之前主动填问卷报名参加产品测试的用户，这些人本来就对新功能有期待，就算出点小bug，也不会直接卸载，甚至会主动给你提意见。
等这批人跑一周没问题，再切1%的非核心用户——注册超过半年，从来没消费过，也没在平台发过内容的那种。就算出问题，对平台的影响也微乎其微。
对了，这里有个必须注意的细节：用户标签的透传要贯穿全链路。
不能用户刚进首页是新版本，点个商品详情就跳回旧版本了。这种跳来跳去的体验，比直接上新版还招人烦。
我们之前就踩过这个坑，标签只在前端做了判断，跳转到第三方支付的时候，请求头里没带标签，用户付完款直接跳回旧版本的订单页，以为自己付的钱没了，投诉了好几个。
还有静态资源的问题。新版本的JS、CSS一定要和旧版本的路径分开，别图省事直接覆盖原来的文件。不然CDN缓存没清干净，用户拿到旧的JS调新的接口，直接报跨域错误，你查半天都找不到问题在哪。
这坑我踩过。真的疼。
留好一键回滚的后路
做灰度最忌讳的就是，出了问题还要改代码发版本回滚。
等你代码改完发上去，用户早就跑光了。
我们现在的灰度，所有切分规则全放在网关层。要切流量、要回滚，直接在后台改个配置，几秒钟就能生效。
而且每次改完切分规则，我们都会专门测一遍回滚——别等真出问题的时候，才发现回滚的开关是坏的。
监控也不能只盯着错误率。很多时候新版本的错误率没涨，但是接口耗时从200ms涨到了800ms，用户等半天刷不出来页面，就算没报错，也会直接关掉APP。
还有个不成文的规矩：大促前的灰度，绝对不要碰核心链路。
支付、下单、订单查询这些模块，大促前半个月绝对不要动。要测新功能，最多测测首页推荐、商品详情页的装修模块这些非核心的地方。
毕竟老陈上次的教训摆在那。
上周跟老陈再撸串，他说现在搞灰度，先把所有客服的账号导到新版本，跑三天没问题再切种子用户。
大促前再也没出过事。
说实话，哪有什么完美的流量切分策略。无非就是别拿核心用户当小白鼠罢了。
不过话说回来，也不是所有业务都适合按用户标签切。要是你做的是工具类APP，用户量本来就少，标签分层也没必要，那就按地域切。先切个三四线城市的小流量，出问题也不影响核心盘。
对吧。