09 · 运维与发布 · 灰度
八个仓一起换，回退时不知道先救谁
发布经理安排谁先用新版本、怎样回退，禁止八个仓库同一分钟一起换。流水线怎么打包，交给 DevOps 工程师。
一次全上：晚上十点所有仓库同时换版本。出问题只能全部退回，业务已经各收了一小时的货。
先一个仓：一个仓走完早高峰再扩大。回退只影响这个仓，制品号写在公告里。
发布经理对窗口和回退负责
测试放行说明版本可以候选，DevOps 工程师提供有构建号的制品。发布经理决定何时、对哪些仓库、以什么顺序放开，以及什么信号出现就回退。岗位特点是拒绝「今晚全部换完」。全部换完的回退成本是所有仓库的在途单据。他要求先选择一个有代表性、又不是唯一高峰的仓库，跑完一个班次，再扩大。
发布说明用业务语言：这一版修了重复收货，不包含新的导出。说明里有构建号、开始时间、观察人和回退负责人。没有回退负责人的窗口不开。回退演练过，不是只写一句「必要时回退」。
和观察指标
放开后的三十分钟看 SRE（可靠性） 的业务错误和待回写，而不是只看服务启动成功。启动成功但双记，要回退。回退后他确认下一班用的是旧构建号，并通知支持如何解释已经产生的单据。已经双记的单走修复清单，不假装回退能自动把账抹平。
八仓同时的教训
有一次八个仓同一分钟切换，其中一个仓的打印机模板不兼容，收货还能做，单子打不出来。因为是全量发布，回退会影响已经正常的七个仓。发布经理此后把打印这种现场依赖列入先遣仓检查，先遣仓打出一张真实送货单才允许第二个仓。那天的模板问题在先遣仓被发现，其他仓保持旧版到第二天。影响范围是一个仓的一个班次。
扩大发布的决定写下来，不在群里说一声就算数。发布经理在扩大范围前核对先遣仓的打印、回写和权限，不只核对服务是否启动。启动成功而单子打不出来，对仓库就是失败。扩大的仓库名单由他发布，其他人不能在群里自行加上第八个仓。自行加上的仓没有回退负责人。紧急修复也要走先遣，只是窗口可以缩短。跳过先遣的理由必须写清：不修会停线，且风险小于全仓故障。写不出这两句，就不叫紧急，叫着急。发布当天他把业务联系人、先遣仓、回退负责人和制品号写在同一页，发给支持和实施。支持不知道制品号，就无法判断现场问题属于新版还是旧版。实施不知道先遣仓，就会把别的仓的异常也归因到发布。
信息少一项，发布后的一小时会花在确认谁现在跑的是哪一版。他把不发布也当成决定写清楚：这一版只进测试，不进生产，原因是没有通过先遣打印。公开写下不发布，团队才不会在晚上偷偷替换。偷偷替换一次，灰度名单就再也没有意义。他把扩大发布的间隔写死，至少覆盖一个完整班次。间隔被压缩到十分钟时，先遣仓还没来得及暴露回写延迟。延迟一旦到了第二个仓，回退就涉及两批在途单据。
发布说明用业务语言写构建号、开始时间、观察人和回退负责人。没有回退负责人的窗口不开。回退演练过，不是只写「必要时回退」。已经产生的错单走修复清单，不假装回退能自动抹平。不发布也写成决定：这一版只进测试，原因是先遣打印没过。公开写下不发布，团队才不会晚上偷偷替换。制品从哪条流水线来，看 DevOps；放开后业务伤没受伤，看 SRE。本岗只排窗口和回退。