新功能上线十分钟，客服消息量翻了三倍，全在问支付不了。开发在测试环境跑得好好的，一到线上就出幺蛾子——这是微信公众号开发项目里最经典的剧本，而解药其实早就摆在手边：测试号和灰度验证，只是多数项目舍不得花这一两天。
测试号的正确用法
公众平台提供的测试号几乎全接口开放，不需要认证，不用担心把正式号搞出事故。它适合做三件事：新接口的首次联调、异常场景的模拟、开发环境的长期练兵。测试号还能模拟不少正式号测不了的场景：关注事件、扫码事件、异常消息格式，都能手动触发，异常路径的覆盖靠它最方便。但它和正式号有差异，配额、部分权限、真实用户行为都对不上，所以测试号过了不等于上线稳了，它只是第一道滤网，滤掉的是低级错误。
灰度怎么灰
- 内部期：员工和家属先用一周，支付走小额真实订单
- 白名单期：拉一批老客户内测，收集第一轮反馈
- 放量期：按百分之十、五十、全量的节奏逐步放开
- 每期灰度之间留观察间隔，问题常有滞后性
每一期都要有明确的观察指标：报错日志、支付成功率、页面加载时间、客服咨询量。指标异常就停在当前比例排查，别硬推全量。每期之间留两三天的观察间隔，问题有滞后性，当天看着没事不代表真没事。灰度期间保留上一版本的回滚能力，出问题十分钟切回去，比抢修体面。
上线后头三天最关键
安排人盯日志和客服反馈，每天的异常汇总出来，小问题当天修，大问题评估要不要回滚。客服话术也要同步准备，新功能上线后用户最常问的十个问题，提前写好答案贴在客服工作台。有家做鲜花电商的客户坚持这个流程，第一次大促的支付成功率稳定在九成八以上，同行普遍卡在九成出头，差别就在这些不起眼的流程上。
回滚预案要写成文档：触发条件是什么、谁有权拍板、回滚步骤几步、预计耗时多久，四个问题都有答案才算有预案。临时现想步骤的回滚，十次有八次出二次事故，预案的价值就在把慌乱变成照单执行。微信公众号开发的交付质量，一半看代码，一半看上线节奏。比格网络的项目习惯是里程碑里预留灰度期，客户觉得慢了两天，实际上省下的是上线后一个月的救火时间，灰度流程一旦跑顺，可以固化为模板，后续每个新功能都照此执行，这笔账怎么算都划算。上线稳不稳，看的就是这些笨功夫。
