三种简单可行的灰度方式
第一种按用户比例放量。先让百分之五的用户看到新版，观察一段时间没问题，放到百分之二十、百分之五十，最后全量。这是最通用的做法，适合界面改版、新功能上线。
比例怎么分配要有记录。用 Cookie 或者用户 id 取模，保证同一个用户每次都落在同一组，否则用户刷新一下界面就变了，看着像出故障。这一点非常关键，随机分配而不是稳定分配，是很多人踩的第一个坑。
第二种按入口分流。比如新功能先在某个分类下开放，或者只对从某个渠道进来的用户开放。这种适合功能影响面比较明确的场景，也方便对比新旧两版的数据。
第三种按实例放量。如果站点跑在多台服务器上，先只升级一台，观察这台上的错误率和响应时间。这一台没问题，再滚动升级其余的。对单机站点不适用，但对有多机的站是最稳的方式。
上线前必须准备的东西
先准备回滚开关。这不是可选项，是硬要求。开关要能做到不重新部署就让新功能失效，最好是一个配置项或者一个开关表字段，改完立刻生效。
其次准备监控指标。至少三条：错误率有没有上升、页面响应时间有没有变慢、核心行为的数据有没有变化。没有监控的灰度不叫灰度，叫盲赌。
再准备日志。新功能里的关键步骤要打日志，出问题时能顺着日志还原用户走的路。日志别写太细把磁盘写满，也别写太粗什么都查不到。
最后把数据备份。改结构、改数据的上线，事前一定要有一份可用的备份。备份要验证过能恢复，没验证过的备份只能算心理安慰。
观察什么、看多久
第一看错误。新版本上线后错误日志有没有新增类型，接口有没有开始返回 500，这是死的指标，有问题立刻停。
第二看性能。响应时间、数据库慢查询、服务器负载，这几项在新版本上线后经常会有变化，尤其是加了新查询的功能。
第三看行为数据。用户在新版里的点击、停留、完成率，和旧版对比。行为变差不一定说明新版有 bug，也可能是设计得不好，但无论如何都要知道。
看多久取决于改动大小。小改动观察一两个小时就够，涉及核心流程的至少观察一整天，跨一个流量高峰。别在流量最低的凌晨上线然后宣布成功，那等于没测。
推进与回滚的节奏
推进要有明确的放量条件。比如错误率不超过基线、响应时间不超过基线百分之二十、核心完成率不下滑。条件写清楚，达到了才继续放，别凭感觉。
回滚要有明确的触发线。错误率翻倍、出现数据错乱、核心功能不可用，这几种情况不用讨论，直接回。犹豫的成本远高于回滚的成本。
回滚动作要演练过。第一次真回滚不应该发生在真出事的时候。提前在测试环境走一遍，知道点哪个按钮、改哪个配置、多久生效。
分阶段留时间。每一档至少留出足够的观察窗口再往下走，急着全量等于放弃了灰度最大的价值。
个人站适不适合做灰度
流量很小的站点，灰度的统计意义有限。几十个访问量分给两版，每版只有十几个样本，得出的结论不可靠。这个阶段更应该靠人工验证和逻辑判断。
但灰度里的机制部分依然值得学：稳定的用户分组、可用的回滚开关、基础的错误监控。这三件事跟流量大小无关，是对任何站点都成立的工程习惯。
流量起来之后，灰度就变成必需品。特别是有了付费用户和稳定流量，一次没测过的全量上线，可能直接损失一天的访问和信任。
一个真实的取舍
灰度的成本是时间和复杂度。为了一个小功能搭一套分流机制，可能不值得。判断标准是这次改动出错后的损失有多大：只是样式变了，直接上；涉及数据、支付、核心流程，必须灰。
别把所有东西都做成灰度。每个改动都灰度，最后没人搞得清线上到底跑的是哪个版本，这本身就成了新的风险源。
选几个关键位置做灰度就够了：改版、数据迁移、涉及金额和权限的功能。其余的小改动，靠测试和回滚预案覆盖。
灰度放量的具体实现
最简单可行的实现是用一个配置项控制放量比例。请求进来时按用户标识取模，落在范围内的走新版，其余走旧版。这个逻辑放在入口文件里，代码不多，但要有开关能随时改比例。
用户标识别用每次随机的值，要用一个稳定的东西：登录用户的 id、或者给游客打一个存本地的标识。用随机数会导致同一个人反复在新旧版之间跳，体验割裂，数据也乱。
按分类分流时，把分类作为分组依据比较自然。比如先在网站运营这个分类下上线新版文章页，观察这个分类下的阅读数据和报错，没问题再推到全部文章。
不管哪种方式，都要有一个能一眼看出版本的功能。比如在页脚加一行小字标注版本，出问题时能立刻确认用户看到的是哪一版，这个成本极低但非常有用。
灰度期间的数据怎么读
对比要控制变量。同一时间段、同一类用户、同一入口，新旧两版的数据才有可比性。拿新版昨天的数据和旧版今天的数据比，那说明不了任何问题。
样本量不够时别下结论。两组各几十个访问，差异可能纯属随机。这种时候看趋势比看具体数字更靠谱，或者干脆延长观察时间。
注意区分指标变化的原因。新版上线后访问量掉了，可能是内容的问题，也可能是这一时段本来流量就低。看数据时要对照历史同期，别孤立的看。
不合适做灰度的场景
数据结构的不可逆改动不适合灰度。新老版本同时跑，但数据表结构只有一个，容易出现新版本写入、旧版本读出错的情况。这类改动要么全量，要么做双写过渡。
影响面很小的改动也不需要灰度。改一个按钮颜色、调一段文案，直接上就行。给每个细微改动都套一层分流，复杂度会失控。
紧急修复更不需要。线上已经出问题了，需要的是立刻修好，不是分百分之五的用户先修。这种时候直接全量，快速验证。
