一句话：灰度不是「小心一点地上线」，是用小范围失控换取大范围的稳定。上线前把风险量清楚，比上线后祈祷顺利有用一万倍。
上线节奏：第 1 周 1 家经销商门店 → 第 2 周 2 家 → 第 3 周 4 家 → 第 4 周全量。为什么不能一次全上：LumenX 平台近 2 天 pm2 重启 482 次（约 6 分钟一次），这种稳定性下全量上线就是灾难。
回滚预案里最容易翻车的是数据兼容——代码回滚了但数据已经写进去。延伸：模块 12 · 稳定性与监控、基础 17 · 并发锁事务。
先讲一个我自己踩过的反面例子，就明白「全量上线」在什么状态下等同于灾难。
LumenX 平台（部署在 124.222.108.196）当时的状态是：近2 天内 pm2 重启 482 次——平均每 6 分钟崩一次。在这个稳定性下把系统推给全部用户，等于把客户的日常经营押在一个每6 分钟重启一次的服务上。
| 如果全量上线 | 会发生什么 |
|---|---|
| 用户正在录单 | 每 6 分钟被踢出去一次，正在填的订单内容全丢 |
| 问题出在 P1 引擎 | 但用户看到的是整个页面打不开，分不清是谁的锅，注意力全在「这系统不能用」 |
| 你想回滚 | 回滚代码需要时间，而这 6 分钟一轮的重启可能在你操作之前又崩了一次 |
| 客户信任 | 一次就毁了，后面再说什么「这是灰度阶段」都没人信 |
德莉玛的灰度范围是4 家经销商门店。选哪 4 家，不是随便挑，也不是挑关系最好的。
最常见的选错方式：挑最配合的那家。最配合的门店数据规整、反馈积极、店长懂电脑——你在它上面跑通了，换一家真实的门店照样崩。试点要选「最像大盘的」，不是选「最好的」，也不是选「最差的」。
| 试点应满足的条件 | 为什么 |
|---|---|
| 业务结构像大盘 | 接的订单类型、经销商数量、型号种类要接近全量比例。如果试点门店只做标准品，测不出异形单的坑 |
| 店长/一线愿意配合但不特殊照顾 | 要有反馈意愿，但不能额外培训。试点要验证的是「产品能不能让一线自己用起来」，一上手就配人教，就测不出真实可用性 |
| 有可对照的历史数据 | 能用它过去的单据量、返工记录做基线，否则放量后你无法证明「有没有变好」 |
| 出问题时能被隔离 | 这家门店的数据和操作不能影响其他门店；出问题后业务能退回原来的流程继续跑，不至于停摆 |
这一步必须在写代码之前做完。指标分两类：技术指标（错误率、响应时间、进程重启次数）和业务指标（单据量、返工率、录入耗时）。两类都要，理由见下一节。指标没定就上线，等于没有上线标准，只能凭感觉说「还行」。
只开 1 家经销商门店。放出的是完整可用的功能，不是半成品——半成品会让一线形成错误习惯，后面改起来更痛。同时必须准备好随时回滚的动作，不是「到时候再说」。
每天固定时间对一次账：技术侧看错误率/响应/重启次数，业务侧看单据量和录入耗时。连续 3 天各项指标稳定，才允许进入下一步放量。只跑一天就放量，是把灰度当形式。
按下面的节奏表推进。每一档之间都要留出观察期，出问题的第一步动作永远是回滚，不是修——线上时间比修复时间贵得多。
| 时间 | 范围 | 进入下一档的条件 |
|---|---|---|
| 第 1 周 | 1 家经销商门店 | 连续 3 天技术指标无异常 + 一线能独立完成完整单据 |
| 第 2 周 | 2 家经销商门店 | 业务指标不低于旧流程基线，且返工率无上升 |
| 第 3 周 | 4 家经销商门店（全部试点） | 数据核对无差异，录入耗时相比旧流程确有下降 |
| 第 4 周 | 全量放开 | 回滚预案仍保持可用，且已实测过一次完整回滚 |
只看「功能能不能点开」是灰度里最典型的自欺欺人。功能全都能点，流程照样走不通——单据量没涨、录入耗时没降、返工率反而更高，系统就是个摆设。
| 技术指标 | 业务指标 | |
|---|---|---|
| 看什么 | 页面错误率、接口响应时间、进程重启次数 | 单据量、返工率、录入耗时 |
| 谁关心 | 开发本人 | 客户方店长、一线员工 |
| 说明什么 | 系统稳不稳。进程重启次数是最硬的信号——它只要在涨，就说明系统还没到能全量的水平 | 系统有没有真的被用起来、有没有让人干活更快 |
| 容易骗人吗 | 容易。页面看着正常、后端悄悄重启，你只看页面发现不了 | 不容易。这是一线每天的真实体感，骗不了人 |
回滚不是「出问题再说」，是上线前就写好、上线前就演练过的东西。这一节没有商量余地。
下面这些条件任一命中，立刻回滚，先恢复业务再讨论原因。现场讨论「再观察一下」是事故扩大的标准动作：
| 触发条件 | 为什么不容讨论 |
|---|---|
| 一线无法完成一笔完整单据 | 业务停摆是最大的事故，其他问题都可以等 |
| 数据核对出现差异（且无法当场解释） | 数据错了继续跑，错的数据会扩散到更多门店，回溯成本翻倍 |
| 错误率高于旧流程基线 | 说明新系统比原来还差，继续放量是放大损失 |
| 进程重启次数持续上涨 | 参照 LumenX 那 2 天 482 次的前例，这是稳定性已经崩了的信号 |
先把用户挡在流程外，别让半截数据继续写进来。
必须是已知可用的上一个版本，不是「最近一版」。上线前就把上一个版本固定下来并留好包。
目标是1 小时内恢复。这是对 MVP 判定标准第 3 条的兑现动作。
说清现在该走哪条流程。不要让人对着一个回滚后的页面自己猜。
原因没查清之前不重新放开。急着「再试一次」是同一个坑踩两遍。
| 坑 | 表现 / 对策 |
|---|---|
| 只测 happy path | 演示的时候一切正常，一线真实用起来处处是坑：单据类型不全、型号是异形、尺寸缺失、经销商重复下单。对策：测试用例必须来自真实历史数据里的「脏样本」，尤其是那 400 单里没尺寸的那类场景 |
| 把灰度当责任转移 | 出了问题第一反应是「这是试点的问题」「他们不按规范用」。对策：灰度期的目标是发现问题，发现问题是成功的，不是甩锅。找原因的方法是查数据和流程，不是查人态度 |
| 灰度期没做回滚演练 | 预案写得很漂亮，真出事时发现回滚脚本跑不通、备份取不到。对策：放量前真的退一次，把时间记下来。演练过一次的回滚，和没写过的回滚，是两种东西 |
| 指标只看技术侧 | 页面全正常、单据量零增长，还以为灰度成功。对策见第 04 节：业务指标才是最终答案 |
| 放量节奏抢时间 | 「第2 周看起来没问题，提前全量吧」。往往是没观察到第 3 周才暴露的差异。对策：观察期一天都不压缩，出问题就退到上一档而不是全量 |
| 试点店被特殊照顾 | 派专人常驻、单独开小灶、提前补好数据。灰度效果全部失真。对策：试点要有，但不迁就 |
我的思路是先量风险再放量。上线不是把东西推出去就完事，是分四步走的：定观察指标 → 小范围放开 → 每日核对 → 逐步放量。每一步都有进入下一步的条件，不达标就停在那儿，甚至退回上一档。
我负责的是德莉玛的灰度上线，范围是 4 家经销商门店。选这 4 家的时候我有个原则：不选最好的也不选最差的，选最像大盘的。因为最配合的门店数据规整、店长懂电脑，在它上面跑通了，换一家真实门店照样会崩。而且试点不做额外培训——一上手就配人教，测出来的就不是真实可用性了。
放量节奏是按周推的：第 1 周 1 家，第 2 周 2 家，第 3 周 4 家，第 4 周全量，每一档之间留观察期，连续 3 天各项指标稳定才允许往下走。指标我看两套：技术侧看错误率、响应时间和进程重启次数；业务侧看单据量、返工率、录入耗时。只看技术指标会骗自己——页面全正常、单据量零增长，系统就是个摆设。技术指标决定能不能继续放量，业务指标决定值不值得放量。
为什么这么谨慎，我有真实的反面例子：LumenX 平台部署在 124.222.108.196，近 2 天内 pm2 重启了 482 次，平均每6 分钟崩一次。在那种稳定性下把系统全量推给用户，等于让客户每天被踢出去几十次，正在填的单子全丢，用户还分不清是自己操作错还是系统崩了。所以我还把回滚做成了硬性要求：触发条件写死到不现场讨论，一步是在线不行的哪怕降级也不能让业务停；回滚目标 1 小时内恢复；最关键的一点——代码能退，数据退不回去，灰度期写进库的新字段旧代码不认识，静默算错比直接报错更危险，所以数据兼容方案必须在放量前定好，我选的是灰度数据隔离、全量前整体迁移。另外放量前我真的退回过一次，把耗时记下来，否则预案写得再漂亮也只是纸上的。