2026-11-14 12:00:15 k73游戏之家 作者：testai
上周五晚上把新版本一次性推上去，十分钟后支付回调开始报错，投诉电话一个接一个打进来，回滚又花了四十多分钟，那半小时里全站没人能下单。这种事遇上一次就会明白，问题不在代码写得好不好，而在没有留出一条可以反悔的路。灰度发布就是这条退路，它把一次性的全量变更切成几批，让错误只落在很小一部分人身上，剩下的用户照常使用旧版本。这篇从怎么做分流、两台机器怎么分工、回滚要准备到什么程度讲起，顺带说说灰度期间最容易被漏掉的几项检查。
先想清楚灰度能给你什么。它最大的价值不是少出错，而是出错时可控：哪一批出问题就停在哪一批，剩余用户仍然停留在旧版本上，损失面从百分之百缩到百分之五，回滚的范围也小得多，排查的时候只需要盯那一小批用户的请求日志，不用在全量日志里捞针，这种差别在故障复盘时特别明显，损失小的时候复盘也更从容，不急着先救火。
灰度也是收集信息的过程。新版本在真实流量下的表现和小流量压测差别很大，缓存命中率、慢查询、第三方接口耗时，这些只有真实请求才压得出来，压测环境再像也替代不了，尤其第三方接口的抖动，压测里永远是理想状态。
另一项常被忽略的作用在节奏上。有了灰度机制，发版不必再挑凌晨三点，白天也能推，团队发版频率会明显提高，交付节奏和迭代速度也跟着变快，这是很多团队一开始没预料到的收益，发版窗口从每周一次变成每周三次，需求上线速度跟着提上来，产品那边的排期压力也小一些。
灰度不是万能的。数据库结构变更、消息协议升级这类不可逆的改动，灰度只能覆盖一半问题，剩下的一半要靠兼容设计来兜：新旧代码在同一份数据上都能正常工作，才谈得上安全。
也别把灰度当成流程装饰。每个比例都随手通过、没人真正看指标，这套机制就退化成了一次多等几小时的发布，白白增加复杂度。
两种切法适用的场景不一样。按流量比例切适合无状态服务，请求随机落到新旧两版，比例可以从百分之五一路调到百分之百，每次调整都只是入口层改一个权重数字，实现简单，缺点是同一个用户的体验可能前后不一致；按用户切适合有会话的业务，同一个用户始终落在同一版本上，避免中途切换造成登录态丢失、购物车被清空这类体验事故，缺点是放量速度慢，得等足够多的用户被圈进来。选哪种，先看业务有没有会话状态，再看你能接受多长的放量周期，两个问题回答完，方案基本就定了，剩下的都是配置细节，落地速度比想象中快。
按用户切需要一个稳定的分流键。常用的是账号 ID 取模或者设备标识哈希，别拿 IP 当分流键，移动网络下出口 IP 变化频繁，同一个用户会被反复切到不同版本上，问题现象看着特别诡异。真要按网络维度分，用 ASN 或者运营商更稳，别用具体 IP，也别用浏览器指纹这类会随隐私设置变化的东西。
两种方式可以叠加使用。先按用户圈出百分之五的内部账号跑通链路，稳定之后再按流量比例放大到三成，遇到异常随时缩回去，这种组合比只用一种更贴近真实运维，内部账号先踩一遍坑，外部用户再按比例接触，出问题的概率能压到很低。分流规则写进入口配置，别藏在某个人的脚本里。
最省事的做法是旧版继续扛全部流量，新版单独一台接小部分。两台机器的配置可以不同，新版这台只要够接目标比例就行，容量按目标比例的峰值再加一点余量估。
配置差异带来的隐性风险要盯住。新机器核数少、内存小的时候，性能问题会被放大，很容易误判成新版本代码有毛病，白查一整天。
建议把两台先对齐基线：同样的 CPU 型号、内存容量、磁盘类型、系统版本，这样对比才有意义，否则你无法区分是新版本慢，还是新机器本身慢。
用一台机器跑两个版本也行。容器隔离或者在两个端口上各起一份，入口层按权重转发，成本最低，缺点是两版共享资源，一方出问题会牵连另一方。这种玩法适合预算有限的小站点，云途 750 元档那台跑两个容器绰绰有余。
共享机器时把资源限额写死。CPU 份额、内存上限、磁盘 IO 权重都得限制，别让正在压测的新版把旧版的口粮吃光，那样灰度就变成了对新版的压力测试。
入口层是分流的关键位置。反向代理按权重转发、按 Cookie 粘住会话，配置改动秒级生效，比在应用代码里埋开关可靠得多，也不用为发版专门发一次配置。
数据库和缓存这一段最容易被忽略。两版连同一个库，新版多出来的查询会拖慢旧版，灰度期间给新版单独挂一个只读副本做观察，既能隔离影响，也方便对比两版的查询差异。
回滚慢通常慢在三个地方：找不到上一版镜像、配置没留备份、数据已经被改过。前两个可以提前准备，第三个必须在设计阶段就做成向前兼容，否则再快的回滚也救不回被改坏的数据。回滚预案里把这三条写成清单，发版前逐条打勾，比临时想起来靠谱。清单不用长，三五条能把关键动作固定住就够了，写到纸上贴墙比存在网盘里管用。
镜像和配置都要能一键回到上一版。镜像标签别用 latest，用版本号加日期；配置进版本库，回滚就是切一个指针，三十秒能完成，而不是登录机器手工改。手工改配置这件事，一旦赶上半夜和慌乱，漏一行就是一次事故。配置模板只在版本库里改，机器上不留手工痕迹。
数据库改动分两步走。先加字段、不删不改旧字段，等新版本稳定运行几天后再清理，这样回滚时旧代码仍然能跑，代价只是多留一段时间冗余字段，等确认稳定了再统一清理，这段时间里两张表的数据要双向写，别只顾新字段。双写带来的写入开销要提前评估，高峰期可能扛不住。
回滚也要演练。把它当成一次正式操作，在测试环境计时跑一遍，知道实际需要几分钟、谁负责决策、谁执行，比嘴上说随时能回有用得多。演练时把旧镜像和旧配置真的切一次，别只看文档。演练发现的问题往往比真实故障里的更早、更便宜。
错误率要分版本看。整体错误率可能一点没变，但新版那部分已经翻倍，聚合后的数字会把问题完整地盖住，这是灰度期间最常见的误判，看板要按版本拆开，别只放一条总量曲线。
延迟要看分位数。平均数好看、P99 却飙了的服务并不少见，灰度期间新旧两版的 P99 要放在一起比，单看平均值等于没看，P95 和 P99 各自设一条阈值，超了自动提醒。
业务指标往往比技术指标更早暴露问题。下单成功率、支付转化率、注册完成率，这些数字掉一点就说明有异常，灵敏度比 CPU 曲线高得多，灰度批次里安排人盯这几个数，比盯监控面板有效得多，指标异常时能第一时间判断要不要停，值班安排上写清谁看、看多久、什么时候交班。
日志要能区分版本。日志里打上版本标签，出问题时能立刻把新版那部分单独筛出来，不然几万行混在一起翻，等找到线索问题已经扩散了，版本标签顺手加上请求 ID 更好追，一条请求从头到尾串起来，定位范围立刻缩小。
第三方回调要单独验证。支付、短信、推送这类外部依赖，新版的地址和参数可能已经变了，灰度批次里安排一条真实链路从头走一遍，比看接口文档可靠。
用户反馈渠道要开着。灰度批次里的用户遇到问题能直接反馈，速度比事后翻日志快得多，也更容易还原当时的操作路径。
放量节奏按观察窗口定。每个比例至少观察一个完整的业务周期，只盯半小时就放大，等于没看过，夜间和白天的负载结构本来就不同，只看一个时段容易漏掉另一时段才出现的瓶颈。
遇到指标抖动先停住。暂停在当前比例，查清原因再决定继续放大还是回滚，来回横跳会让两版都处于不稳定状态，反而制造更多问题。判断标准提前定好，比如错误率超过基线两倍就回滚，别临场讨论。人一紧张容易把标准放宽，这是事故扩大的常见起点。
放满之后旧版本先别拆。保留一天到两天，确认没有延迟暴露的问题再下线，这段时间的机器成本换来的是安心，比省那点钱划算，真出事时旧版本还在，切换只要几分钟。
把这轮的经验固化下来。哪些指标先动、哪个环节卡住、回滚花了几分钟，写进发版检查清单，下一轮直接照着走，不用每次重新摸，新人上手也有一份可参照的东西，不用靠老员工口口相传，团队换人也不至于把流程丢掉，交接时这份清单就是最直接的教材，比讲一遍流程更清楚。
机器配置建议统一模板。前端入口这批机器用同一套配置和镜像基线，SixTyNet 这类洛杉矶机型也照同样口径准备，别让机器差异干扰对灰度结果的判断，性能对比要建立在同一基线之上，不然数据没法用，写进结论里的数字也会被质疑。
