灰度发布脚本补了一行回滚

灰度脚本是 2020 年那套 Jenkins 之外单独写的，按工号尾号放量，只有 advance 一个动作：10%、30%、50%、100%，一路往前。跑了两年没出事，也就没人想过往回走。

8 月 21 号那天

切到 50% 之后半小时，客服转来两张截图：旧安卓机上按钮挤成一团。查下来是新版本一个 flex 写法在低版本 WebView 里不认，测试机的系统都太新，没覆盖到。

不复杂，退回去就行。然后发现脚本里没有退。

手动那 12 分钟

值班的人翻文档找 Nginx 配置文件位置，改 weight，reload，再核一遍日志确认流量都回旧版。前后 12 分钟，不算久，但那 12 分钟里没人敢确定「是不是全退干净了」，因为脚本平时会顺带刷一遍 Redis 里的灰度标记，手动改权重不会刷。结果有零星几个用户还停在新版，又单独清了一次标记。

问题不在慢，在退的动作跟进的动作不是同一套，中间会漏东西。

补的那行

给脚本加了 rollback，参数也是比例，可以一次退到 0，也可以退到 10% 留一小批继续观察。关键是它跟 advance 走同一段代码：改 Nginx 权重、刷 Redis 灰度标记、写一行发布日志、发一条群消息。四件事一样不少。

顺手把「当前灰度比例」做成一条能查的命令，不用去配置文件里猜。以前只能看上次谁在群里发过截图。

一并加的两条

• advance 到 100% 之后，旧版本保留 7 天不关，这条以前写在文档里没写进脚本，现在脚本会检查。
• 每次放量前跑一次那 5 条 curl 健康检查，失败就停在当前比例，不继续推。以前只在 100% 那步跑。

后来

那个 flex 的写法改了，重新走了一遍 10%、30%、50%，这回测试机里加了一台旧安卓。

脚本现在有 advance 也有 rollback，两个命令并排写在 README 第一行。有人问为什么要给一个「大概率用不上」的动作写代码，我把 8 月 21 号那 12 分钟的聊天记录翻给他看了一眼。