灰度发布不是上线前的走流程
上周跟几个做后端的朋友在河西的苍蝇馆撸串，啤酒刚喝了半瓶，有人开始拍桌子吐槽——他们公司的新功能灰度发了一周，最后上线之后还是炸了。
问原因。
说他们的灰度池，全是内部员工。
对，这些人对产品的容错率高到离谱。点了按钮没反应，第一反应是自己网不好，切个流量再试，根本不会触发应用的崩溃上报。碰到页面加载慢，第一反应是自己的手机太老，退出去清个缓存就回来接着用，根本不会去客诉通道留个言。
等于这一周的灰度，根本没碰到几个真实用户的真实使用场景。
别把灰度发布做成内部员工专属测试
这种操作太常见了。很多团队刚接触灰度，觉得就是“找一小部分人先用”，图省事直接把全公司的内部账号拉进灰度池，省得去配置复杂的流量切分规则。
代价是什么？
之前碰到过做电商的团队踩过一模一样的坑。新的结算页推给内部用户测了三天，所有人点的都是测试用的0元商品，连优惠券入口都没点过。全量上线之后半小时，才发现新的结算逻辑和满减券的叠加规则冲突，用户点提交订单直接跳回首页。
等他们回滚的时候，客诉已经堆了几百条。
说白了，灰度池的核心价值，就是帮你碰到那些你在测试环境、在内部使用的时候根本碰不到的边角场景。你把灰度池全换成对产品熟到不能再熟的内部员工，等于把这个核心价值直接扔了。
很多人觉得，那我不用内部员工，我直接随机切10%的真实用户放出去不就行了？
也不对。
灰度的核心从来不是比例是流量的纯度
你按10%的比例随机切流量，看起来很公平，实际上拿到的数据根本没有参考性。
举个很简单的例子，你要推新的首页推荐算法，随机切出来的10%用户里，可能有一半是刚注册的新用户，本来就对推荐内容不敏感，也可能有一小部分是平时就只刷固定分类的老用户，本来就不会因为算法调整改变行为。你最后拿这部分人的点击数据，和剩下90%的大盘数据比，就算差了两个百分点，你也说不清楚到底是算法的问题，还是这部分用户本身的行为就和大盘不一样。
最靠谱的灰度切分逻辑，从来不是按固定百分比随机切流，而是把同画像的用户分成两组，一组走老版本，一组走新版本。同样的年龄段，同样的地域，同样的使用时长，同样的历史消费记录，两组人的基础行为模型几乎一致，这时候跑出来的指标差异，才是新功能本身带来的影响。
很多团队嫌这个麻烦，觉得要打一堆用户标签，要做流量的分组匹配，太费时间。
但你想想，要是花俩小时把这个逻辑搭好，最后能省掉上线之后因为数据不准拍脑袋做决策的时间，怎么算都不亏。
我见过最夸张的团队，为了图省事，灰度的时候直接把所有VIP用户全放进灰度池。最后新功能上线之后，VIP用户的留存掉了三个点，还以为是新功能本身有问题，改了三版才发现——VIP用户本来就对产品的期待值比普通用户高，你把这部分人单独拎出来测，拿到的反馈本来就和普通用户的感受不一样，根本不能代表全量用户的体验。
很多人又会说，搞这么复杂的灰度，万一碰到问题怎么办？大不了回滚呗。
对，这是另一个常见的误区。
别把回滚按钮当灰度的安全垫
很多团队对灰度的认知，停留在“出问题了就回滚”的层面，觉得只要有回滚按钮，就算灰度放出去的流量出了问题，也能很快把服务拉回来。
但麻烦在于，很多异常根本不会触发你预设的核心告警。
比如你新推的服务逻辑，只在某几个小众的安卓机型上会触发闪退，而这部分机型的用户，在你灰度放出去的5%流量里，可能只占0.2%。算下来整体的崩溃率可能只涨了0.03%，在你盯着的大盘核心指标里，这点波动根本就是正常的噪音，没人会注意到。
等你把流量全量放开，这部分用户的总量翻了20倍，崩溃率直接跳到1%，这时候你再回滚，已经有几万用户碰到了闪退，留下了一堆应用商店的一星差评。
真的等核心指标异常到需要人工介入的程度，损失已经造成了。
灰度阶段的监控，从来不是盯着大盘的整体数据看。你得把细分的维度拆到足够细——按机型、按地域、按用户的核心操作路径、按接口的响应速度，只要某一个细分维度的异常率超过了你提前设好的阈值，系统就自动切断这部分的灰度流量，根本不用等人工发现。
说实话，这事真没那么玄。
小团队根本不需要搞什么全链路的自研灰度系统。你要是一个月才发两次版，那灰度就挑最近7天活跃的老用户，切5%的流量出去，盯着三个核心指标就行：崩溃率、核心操作完成率、客诉量。跑24小时没异常，再逐步把流量提到20%、50%、100%。
别贪多。
很多团队刚上手做灰度的时候，总想着要做一套完美的系统，从流量切分到数据看板全要自研，折腾俩月还没上线，最后干脆把灰度规则关了，直接全量发。
你要的根本不是一套能拿出去吹的技术架构，是能在出问题的时候，把影响范围控制在最小的那套机制。
上次撸串最后，那个吐槽灰度白做的朋友说，回去就把内部员工的灰度池清了，换成按用户标签切的真实流量。
我当时跟他碰了个杯。
毕竟比起上线之后熬夜回滚的痛苦，提前花点时间把灰度的逻辑理清楚，真的划算太多。