灰度不是少放一点量，是把新逻辑圈在一个随时能退回的边界里。边界最好写成一句话：一条通道、一个渠道、三天。三天里不图跑得快，图问题只在小圈子里发生，发生完能被追到具体哪一笔。

一、灰度对象怎么选。通道挑一条非主力的，出问题不影响主干客流，但每天仍要有一两百单的量，完全没人走的通道测不出边界，也测不出并发。渠道挑单量不大但流程完整的：能覆盖支付回调、核销、回传、退改四段，只接了出票的渠道测不出后半段，后半段恰恰最容易掉数据。团队通道和单量最大的那两个渠道不放在第一轮，它们的问题要等口径稳了再碰。

二、开关放哪一层。按通道编号加渠道编号的组合开，两个维度各一列，配置项有名字、有生效时间、有操作人，改完记进变更记录的哪一栏要事先定死。按请求百分比随机不可用——同一个人前一次走新逻辑、后一次走旧逻辑，两边数据一定对不齐，查的时候还查不到是谁。开关也不要埋在代码分支里，埋了就没有回退记录。当前哪些通道、哪些渠道走的是新逻辑，要在一页上列全，逐条显示状态和最后操作人，别让人去翻配置目录。

三、三天各看什么。第一天只看跑不跑得通：核销成功率、回传有没有补齐、错误码分布长什么样，功能不通就不必看第二天。第二天只看数据一致：本地和渠道两边的核销逐笔比，差额追到零，追不平的先停扩面。第三天专门造边界：跨零点、断网重发、退改再核销，这三条不主动构造就等不来，等到旺季真出现时已经没人能改。这三天里每天顺手记一条错误码的变化：新增的码有没有配处置动作，缺一条补一条，不留到现场去猜。

四、放行要有量化条件。核销失败率、掉单笔数、闸机单次过闸平均耗时、两边对账差额，四项在灰度开始前就把阈值写死，不许用"看着还行"来收口。差额类指标按笔给，不按金额给，避开价格口径的争议。任一指标越线，先停扩面，保持现状取证，别一边跑一边找原因，跑两天现场就乱了。阈值只看灰度那条通道和那个渠道自己的数，混进大盘会互相盖住，看着正常，局部其实早越线了。四项阈值每天定点看两次，开园后一次、闭园后一次；灰度中途改过阈值的，改完当天重新起算三天。

五、回退预案要在灰度之前写。写清什么情况下退、退的时候动哪一层：关开关，不是删功能。新逻辑已经产生的数据要在旧口径下解释得通——多出来的字段允许空着，新增的状态位旧报表要能归到已知分类里，否则退回去了报表还是错的。退一遍要真演练一次，演练结果写进测试记录，没演练过的预案不算预案，只是文档。回退之后把灰度期产生的数据留一份快照，复盘时两边口径各算一遍，才知道差在哪一列。

先做哪一件：先把开关按通道和渠道拆成两列，并把操作人姓名记全，再定三天各自看哪一项。范围没圈住就上线的灰度，最后只会变成"全量跑了但没人说得清有没有问题"，那种状态比不灰度更难收。