为什么要灰度

一次把新版本推给全部用户，是最刺激也最危险的发布方式。万一有个严重 bug，全量用户一起遭殃。灰度发布就是先放给一小部分人用，没事再慢慢放量，出事也只影响那一小撮。

小程序本身有版本审核和发布机制，配合后端的灰度开关，前后端一起做灰度，才完整。

灰度不是大公司专利。哪怕是小团队，先内部用、再放给几个熟客，这个习惯养成了，发布就再也不用提心吊胆。

省下来的，是事后救火的无数个通宵。

灰度的本质：把「全量赌博」拆成「逐步下注」。
本文核心知识点
  • 灰度先小流量、观察、再放量。
  • 回滚出事能快速退回去。
  • 版本治理老版本兼容怎么处理。
  • 流程发布要有规矩，别靠拍脑袋。
小程序灰度发布示意：蓝调渐变背景上分层渐变色块与发布箭头的扁平科技插画
流量一小步一小步放，出问题影响面就被压到最小。

灰度怎么分

常见分法：先内部人员、再核心用户、再小比例真实流量，最后全量。每一步都留观察时间，看监控里错误率和投诉有没有异常。

阶段范围
内测内部员工
小流量1% 到 5% 用户
全量确认无问题后放开
 
// 后端按用户白名单或比例下发灰度标记
const gray = inGrayList(uid) || uid % 100 < 5;

灰度比例要慢慢爬，别从 1% 一下跳到 50%。每一步都留够观察时间，看错误率、看投诉、看核心指标有没有掉。

灰度的用户也不是随便挑。优先挑活跃、反馈积极的，真出问题他们愿意帮你报，比沉默用户强得多。

除了按比例，也可以按地域、按渠道分灰度。有些问题只在特定地区的用户网络下才出现，分地区灰度能更快暴露。

回滚：兜底

灰度期间一旦发现问题，能立刻把流量切回老版本，这就是回滚。回滚要快，不能等审批，出事那几分钟里每一秒都在放大损失。

  • 后端开关比前端回滚快，优先做。
  • 前端版本更新有用户缓存，不能指望秒退。
  • 回滚演练要提前做，别出事才第一次试。

回滚之所以重要，是因为线上问题的暴露往往有延迟。不是一上线就炸，而是跑了几小时、碰上特定用户才出。所以观察期不能短。

前端版本的回滚慢，所以更要靠后端灰度开关扛。后端开关能秒切，这才是真正的救命手段。

版本治理

用户不会第一时间更新小程序，老版本会存在一段时间。后端接口改了，老版本还在调，就得做向后兼容，或者引导用户升级。

// 检测到用户版本过低，提示升级
if (lowVersion(cur)) wx.showModal({ content: "请更新到新版本" });

别轻易直接砍老接口，留好过渡期，等老版本用户少了再清理。

版本治理还有个动作：定期盘点还有多少用户停留在老版本。比例低到可以接受了，再安全地清理老接口，心里有数。

发布流程

把发布写成一套固定流程：谁发、什么时候发、灰度多久、观察哪些指标、出事找谁。有流程兜底，新人也能照着走，不会临场慌。

// 发布 checklist：测试、灰度、观察、放量、记录
// 每一步勾选，别跳

发布尽量避开大流量时段，半夜或工作日上午，出问题好有人处理。

发布记录要留档。这次发了什么、灰度多久、出过什么问题都记下来，下次发布就是现成的参考。

发布前的清单要养成习惯：自测过了吗、灰度开关配了吗、回滚路径通了吗，逐项打勾再发。