改版是件危险的事。一次全量上线，改完发现某个页面打不开、某个功能报错、某段样式在手机上错位，用户立刻就能看到，你只能一边救火一边挨骂。灰度发布解决的就是这个问题：先让一小部分人看到新版本，确认没问题再逐步放开。听起来简单，实际做的时候细节很多，做不好反而更乱。
灰度的本质是缩小影响面
很多人以为灰度就是“先上线一半”。不是。灰度的核心是有明确的放量节奏和明确的回滚条件。没有这两样，只是把一次大事故拆成几次小事故。
做灰度之前必须回答四个问题：新版本给谁看、看多少人、观察多久、什么情况下回滚。四个问题都有明确答案，才能开始。
五步走的节奏
第一步，本地和测试环境。所有页面在本地跑通，关键流程手工走一遍：注册、登录、搜索、提交、支付。这一步不做灰度，做了也白做。
第二步，内部人员。自己和几个熟悉站点的人先看，主要看功能有没有明显错误。这一步能发现八成的问题，耗时半天。
第三步，百分之一的真实流量。通过 cookie 或者 IP 哈希分桶，让一小部分访客看到新版本。观察两到四小时，重点看错误日志和监控曲线。
第四步，百分之十。这一步开始能看出性能问题，因为流量上来了。观察一天，跨过至少一个高峰时段。
第五步，全量。前面四步都稳了再放开。
每一步之间不要急。百分之一到百分之十这一跳最容易出问题，因为小流量下暴露不出来的性能瓶颈，到百分之十就显形了。
怎么分流量
三种常见方式，各有适用场景。
按比例随机分桶：给每个访客生成一个随机数或者哈希值，落在某个区间的走新版本。优点是不用改代码逻辑，缺点是同一个用户可能一会儿新一会儿旧，体验割裂。
按用户 ID 分桶：同一个用户永远走同一个版本。体验一致，但要求站点有登录体系，匿名访客没法分。
按 IP 或者地区分：适合新功能上线，比如先给某个城市的用户看。缺点是无法覆盖所有用户类型。
最稳妥的是“用户 ID 加匿名设备标识”组合，登录用户按 ID 分，匿名用户按设备标识分，保证同一个人的体验一致。
回滚必须提前准备好
灰度过程中发现问题，第一动作是回滚，不是现场修。所以回滚方案必须在上线前就准备好，并且要测一遍。
回滚要准备三样东西：旧版本的代码包、旧版本的数据库结构说明、回滚的操作步骤。第三样最容易被忽略，出问题的时候人慌，没有步骤清单容易漏步。
数据库变更要特别注意。新版本加了字段、改了索引，回滚的时候旧代码能不能兼容新结构？如果加的是新字段，旧代码不读它，通常没问题；如果删了字段或者改了类型，旧代码会直接报错。所以改版的第一原则是：数据库只做加法，不做减法和改名。
回滚的执行时间要控制在五分钟以内。写成脚本，一条命令跑完，别手工一步步操作。
灰度期看什么数据
别只看“有没有报错”。四个维度一起看。
第一，错误率。五百错误和异常日志的数量，跟灰度前对比。涨了立刻停。
第二，响应时间。新版本页面的平均响应时间、九十五分位响应时间，跟老版本对比。明显变慢就要查原因。
第三，核心转化。注册数、提交数、点击率这些关键指标，新老版本分开统计。跌了说明新设计有问题，不是技术问题，是产品问题。
第四，用户反馈。灰度期间收到的投诉、留言，有没有集中指向某个功能。
四个维度里，第三个最容易被忽略。技术上一切正常但转化跌了一半，这种改版上了全量就是灾难。
哪些改动必须灰度，哪些不用
不是所有改动都走五步。判断标准是影响面：改文案、换一张图、调间距，直接上线，出问题只是不好看。改模板结构、改 URL 规则、改数据库字段、改支付流程，必须灰度。中间地带看情况：改导航结构影响所有页面，走灰度；加一个新页面只影响新入口，直接上。
还有一类必须灰度但不能靠流量分桶：全站性改动，比如换 CDN、换服务器、换 PHP 版本。这类没法按用户分，只能按时间分：凌晨低峰期切，切完观察一小时，有问题立刻切回。
沟通也要跟上
灰度期间用户可能看到两个版本，会疑惑甚至投诉。提前准备一句说明放在页脚或者帮助页：“我们正在测试新版页面，您可能会看到不同样式，功能不受影响”。这句话能挡掉大部分困惑。
内部也要说清楚。谁负责观察数据、谁有权决定回滚、出问题找谁，这三件事定死。灰度期最怕发现问题没人敢拍板停，一步步拖成大事故。
灰度期结束之后
全量上线不等于结束。留一周观察期，每天看一眼核心指标，确认和灰度期的数据一致。
然后把这次改版的过程写下来：改了什么、灰度分了几步、每步发现什么问题、回滚了几次、最后结果如何。这份记录下次改版直接能用，比重新摸索省事得多。
还有一件事：老版本的代码别马上删。留一个月，确认没有回滚需求再清理。留着占不了多少空间，删早了要用的时候抓瞎。
灰度不是流程上的繁琐，是把风险摊开。一次改版分五步走，最坏的结果是百分之一的用户看到问题；一次全量上线，最坏的结果是所有人都看到。这个差别，值得多花两天。
