甲方说先上线再改，灰度发布怎么排

「先上线，有问题再改」，这句话我们听过很多次。它本身没毛病，真等所有细节都想清楚，项目可能半年出不来。怕的是另一头：上线等于全量切，改的时候没有退路。

所以每次听到这句话，我们接的是「行，那把灰度和回滚先定下来」。

四步，不是两步

很多人以为灰度就是「先给 10% 的人用」。10% 给谁、看什么、看多久，比 10% 这个数重要。

第一步，内部账号 2 天。只有我们和客户项目组几个人的工号能进新版，专门跑那些自动测覆盖不到的路径：填一半退出、重复提交、用旧书签进新页面。

第二步，按工号尾号放 10%。挑一个尾号，比如 3，这批人固定，不会今天在新版明天回旧版。看错误日志和客服记录，不看「感觉」。

第三步，按门店放 3 家。这一步是给有线下场景的项目留的。同一个功能，总部办公室用着顺，门店那台共用电脑、那套扫码枪、那个网络，可能完全是另一回事。3 家里我们特意挑了一家网络最差的。

每步之间留一个观察日，不连着放。周末不放量，没人盯。

第四步才全量。

分流怎么做

不复杂。Nginx 前面按 cookie 里的一个标记分流，带 gray=on 的走新版本 upstream，其余走旧。标记由登录接口按工号下发，不用改前端路由。两套代码在两台机器上同时跑，数据库共用一套，所以表结构变更必须向后兼容，新版本加字段可以，删字段、改字段含义不行，这条我们写进了上线检查单。

回滚是一行配置

全量之后旧版本至少留 7 天不关。真出问题，把 Nginx 的权重调回 0 就退回去了，不重新打包、不重新发版、不用等人半夜改代码。那次真用过一次，是个只在 IE 下出现的样式问题，从发现到退回 4 分钟。

一句大白话

「先上线再改」能成立，前提是「改」这个动作成本足够低。低到什么程度？低到值班的人不用请示就能点回滚。做不到这个，就先别急着全量。