大促前夜，一个微信小程序开发的新版本全量上线，半小时后客服电话被打爆：商品详情页全量用户都打不开。一个没测到的兼容问题，直接烧掉了整晚的销售。负责人事后说，后台其实一直有灰度发布的入口，只是从来没人用过。做版本管理，灰度是最便宜的一份保险。
版本流转的全过程
一版代码从开发版到体验版，提交审核变成审核版，通过后发布上线。全量发布是默认动作，但发布之后还有操作空间：按比例放量。一成、两成逐步放大，不同比例的用户看到的是不同版本，线上同时存在新旧两版。放量期间盯监控，没问题就加大比例，有异常立刻停，损失被框定在小比例用户里。
放量节奏怎么定
常规迭代的节奏可以简化成三步：先放一成观察一小时，看崩溃率和支付成功率有没有异动；平稳就放到五成，再观察一阵；确认无虞全量放出。大版本改版、动了支付或登录链路的，建议在低比例区间多待一阵，必要时拉内部员工真实下单走一遍。灰度期间最忌讳的是放着不管，放量是为了观察，不盯数据等于没做，出了事和全量直发没区别。
出事之后的回退
后台提供版本回退能力，线上出问题时可以退回上一个版本，不用重新走审核。回退前要想清楚数据兼容：新版本动过数据库结构的，回退后旧代码读新数据会不会出错，这类风险要在设计阶段就规避，比如新旧结构并行兼容一个过渡期。回退是止血手段，根因还是要修，修完重新提审，流程一步都不能省。
两条建议：团队里定一条铁律，动支付、登录、订单链路的微信小程序开发版本必须灰度，其余版本至少留两成观察期；没有专职运维的小团队，比格网络的发版服务可以代管这套流程，一年花不了几个钱。体验版建议固定给核心用户群，他们踩到的问题往往比内部测试更真实。观察指标除了崩溃率和支付成功率，再加一个客服进线量，异动往往最先从这里冒头。回退流程别等出事才摸，平时找低峰期演练一遍，真出事才不手忙脚乱。灰度还有个副产品价值：新功能放小比例时能收到一批真实反馈，赶在全量前调整文案和交互，等于免费做了一轮可用性测试。放量节奏写进发版文档，谁来操作、看哪些指标、异常找谁，提前定好，别让任何一头单独拍板，发布是技术加运营的共同动作。发布流程规范了，事故才有边界。
