灰度发布是留余地的工程活

上周跟几个在互联网公司做了五六年的老SRE吃饭，聊到这几年见过最没必要的线上故障。有个哥们说上个月他们团队新上的支付路由逻辑，为了赶月底的版本窗口，直接全量推了。结果华南区三个地市的通道直接堵了俩小时。最后算下来，损失够买半套新的可观测系统。 说真的，这事根本没必要发生。但凡他当时多花半小时搭个最基础的灰度发布链路，都不至于踩这么大的坑。

先搞清楚，你要躲的到底是什么

很多人对灰度的第一反应，就是把10%的用户流量导到新版本，跑两天没问题就全量。 太浅了。 麻烦在于，你切的根本不是冷冰冰的流量，是每个用户带着完整上下文的请求——他的登录态、他之前的交易记录、他和老系统攒了好几年的交互习惯。灰度发布要防的，从来不是新版本本身跑不跑得起来，是你那些根本没在测试环境覆盖到的、和老系统缠了好几年的暗坑。 比如你新版本改了商品详情的接口返回结构，前端有个三年前写的老H5页面，还在抓那个已经被你删掉的字段。测试环境你测了新前端的所有页面，谁会闲着没事去点开那个半年没更新过的老入口？全量推出去的瞬间，那部分老用户的页面直接白屏。

很多团队第一次做灰度的时候，只盯着新功能的逻辑校验，忘了算兼容成本。数据库字段加了新的索引，旧版本的查询会不会走偏？消息队列发了新格式的事件，旧版本的消费者解析会不会直接报错？这些东西，你在测试环境根本模拟不出来所有的组合场景。 说白了，灰度就是给你留了个试错的小窗口。你不用把整个用户群都拉进来当小白鼠，只要在小范围里把这些藏在角落的暗坑踩一遍，就算疼，也疼不到骨头里。

别被按用户切流量的教程骗了

网上一搜灰度教程，十篇有九篇会告诉你，按用户ID尾号切10%，按地域选一个省份当试点。 别信。 你想啊，要是那10%的用户，刚好全是平台里付费最高的一批核心用户？刚好赶上大促的流量峰值？你新版本一上去，出了点小问题，这些用户直接对平台失去信任走了，你花多少补贴都拉不回来。 我之前见过团队图省事，直接把所有内部员工的流量导过去当第一批灰度用户，觉得自己人出问题了能兜住。听起来很合理对吧？实际上呢？员工打开APP，都是点”我的””设置”，谁会天天去点你新上的那个拼团砍价功能？你拿员工测半个月，日志全绿，全量推出去，真实用户一上来就把你新接口打挂了。

真正要算的，从来不是你切多少比例的流量最”科学”，是你得先搞清楚，单次故障你能承受的最大影响范围是多少。 比如你整个系统一天有一百万笔交易，你能承受的最大故障是影响一千笔交易，那你的灰度比例就从最开始的0.1%慢慢往上爬。每爬一步，别盯着俩小时的日志就急着往下走，得覆盖至少两个完整的业务周期——工作日早高峰、晚高峰，甚至周末的流量峰值，确认没有异常了，再往上加1%，再加5%，最后全量。 我见过太多团队，为了赶版本上线的deadline，灰度跑了10分钟没报错，直接点全量。之前听同行聊过，有个做电商的团队，大促前一天上新的优惠券逻辑，灰度跑了5分钟，看监控曲线没波动，直接全量。结果大促当天，优惠券的核销逻辑算错了，用户领的10块无门槛券，实际能抵100。一晚上亏了小几十万。 真的亏。

灰度发布从来不是零成本的事

很多人对灰度还有个误解，觉得只要做了灰度，就等于给线上系统上了保险，再也不会出故障。 想多了。 你要维护两套甚至三套并行的线上服务版本，你的配置中心要支持不同版本的配置隔离，你的监控系统要能把不同版本的指标分开统计——不然你出了问题，根本不知道是新版本的锅，还是老版本的流量飘了。这些能力，没有一个是凭空长出来的，都要花开发时间去搭。 很多中小团队一开始算不过来这笔账，觉得自己人少，业务量也不大，没必要搞这么复杂的流程。那你就要坦然承受全量上线可能出故障的风险。要是你的系统就是个内部办公OA，那全量上也就上了，出问题了大家忍忍就过去了。但要是你的系统是面向C端的，涉及交易、涉及用户隐私的，你省那点搭灰度的时间，最后出了问题，要花十倍的时间去擦屁股。 之前接触过的中小团队里，很多一开始根本不做灰度，每次上线都是半夜爬起来，全量推，出问题了就急急忙忙回滚。等用户量上来了，有一次新版本上线把用户的头像缓存搞坏了，三分之一的用户打开APP看不到自己的头像，客服电话被打爆了，才咬着牙搭了最基础的灰度能力，最开始就是先把1%的内部测试用户导过去，跑顺了再往外放。前前后后折腾了快一个月，才把这套流程跑通。 值不值？至少后来他们再上线，再也不用定凌晨三点的闹钟，守在电脑前面等系统崩了。 这事没那么玄。没有什么完美的灰度方案。你要做的，从来不是找一个能覆盖所有场景的黄金比例，是在你上线新功能的时候，给自己留个能踩刹车的余地。 别等车冲出去了，才想起你没装刹车。