灰度发布的真实代价你未必算过

上周跟某厂后端聊到凌晨三点，对方刚因为灰度的配置漏了个条件，把一个还没做完的退款功能推给了三个城市的用户，赔了快二十万的券。

这事没那么玄。很多人对灰度发布的认知，还停留在“切1%流量跑两天，没问题就全量”的标准流程里，好像只要走了这套流程，就算把上线的风险兜住了。

别把灰度当万能遮羞布

错。

大错特错。

你以为切1%的流量给新功能，就算把风险兜住了？但你算过没有，那1%的用户里如果刚好有一半是每周发三次投诉的核心大R，他们碰到的bug，造成的口碑损失，可能比全量推给一百个普通用户还严重。

很多团队刚上敏捷流程的时候，把灰度当救命稻草，啥功能都先扔灰度池里，好像只要不推全量，出了事就不算正式事故。说白了，这就是把灰度当免责金牌。

我见过太多团队的灰度策略，就是后台随机切几个百分比的流量，根本不做用户分层。看起来覆盖够广，实际上根本测不到真实的边缘场景。之前碰到个做电商的团队，把新的商品搜索功能切了5%的流量，跑了三天没报错，直接全量，结果刚推完，一堆用老年机的用户反馈页面卡到动不了——原来那5%的灰度用户里，全是用最新款旗舰机的年轻用户，根本没碰到低版本安卓的兼容问题。

更麻烦的是，很多团队为了所谓的“灰度覆盖全面”，会把新功能推给全渠道的用户，包括那些刚注册的新用户、还在试用期的付费用户，甚至是已经卸载过三次APP的回流用户。你根本不知道这批人里，会有多少人刚好碰到你还没写完的逻辑分支，会给你的客服团队带来多少额外的工单。

灰度的成本从来不止服务器钱

很多人算灰度的成本，只算多搭的那几套测试环境的服务器钱，大不了多花几万块带宽。

不对。

麻烦在于，你要维护两套甚至多套并行的代码版本，数据库要做向下兼容，日志要打不同的版本标签，告警规则要单独配置，甚至连客服的话术都要单独给灰度用户做一套——不然用户碰到灰度里的bug，客服连怎么解释都不知道。

没人算过这笔隐性的人力成本。很多团队做了半年灰度，光为了兼容老版本的接口，就多写了快两千行的适配代码，到最后新功能全量了，这些适配代码删都不敢删，怕哪天切流的时候漏了老版本的入口。真的，删代码的时候手都抖，生怕碰着哪个开关，把已经下线的功能又给放出来。

不过话说回来，也不是所有团队都适合搞复杂的灰度体系。你要是做个内部用的OA系统，总共就几百个员工用，出了问题打个招呼就解决了，那确实没必要折腾什么按地域、按设备、按用户标签的切流逻辑。但你要是做面向百万级用户的C端产品，你敢把没测过的功能直接推给所有人？

没做回滚预案的灰度等于裸奔

我见过太多团队的灰度流程，只有切流的按钮，没有回滚的开关。或者说，回滚的流程写在文档里，实际上根本没测过。

上次有个团队碰到灰度里的支付接口报错，想回滚，结果发现数据库的表结构已经跟着新版本改了，切回老版本的话，读都读不出来新写的订单数据。

当场傻了。

最后只能硬着头皮把新功能全量推出去，连着熬了两个通宵改bug。灰度的核心从来不是“慢慢推”，而是“出了事能一秒撤回来”。你要是做不到秒级回滚，那你搞的那套切1%流量的灰度，本质上就是拿真实用户当测试员，跟直接全量推没什么区别。

说实话，现在很多技术分享里把灰度吹得神乎其神，好像上了灰度就能实现零事故上线，全是瞎扯。灰度只是个工具，不是什么银弹。你代码写得稀烂，测试case全是漏的，就算你切1%的流量跑一个月，该出的问题还是会出。反而因为你搞了灰度，大家放松了警惕，觉得反正有缓冲，最后出的问题可能比直接全量还大。

别上来就搞什么复杂的灰度体系。先想清楚你要测的到底是什么。是测功能有没有bug？那你就先找内部员工跑，别拿真实用户当免费测试员。是测新功能的用户转化率？那你就先切给最不敏感的那批新用户，别上来就动核心老用户的蛋糕。对吧？