上线发布清单：用 AI 生成可回滚步骤并逐项打勾校验

一句话结论

可回滚的发布清单只有三条硬标准：每步有验证命令、每步有回退动作、回滚在上线前演练过一次。

这篇解决什么问题

发布前拍脑袋写几行「更新镜像、重启、观察」，真出问题时没人说得清该退到哪一步。这份清单要解决的是：把一次发布拆成能逐步验证、能逐步回退的动作序列。

适用：变更范围清楚的中小型服务发布，尤其带数据库变更的那种。不适用：纯静态资源替换，或已经由灰度平台自动覆盖回滚的场景，再写一层只是重复劳动。

开始前要准备什么

• 能跑命令的终端，加一套预发或生产环境的只读账号，公司一般已有，不用额外花钱
• 本次变更的实际内容：改了哪些文件、动了哪张表、依赖谁的新接口
• 一个能贴日志和报错的 AI 对话窗口，Claude、DeepSeek 的免费额度写一份清单够用
• 时间预算：熟悉这套系统的人，出第一版大约 30 到 60 分钟，回滚演练另算

具体怎么做

下面五步是串起来的，别跳。我在实操中发现，跳过第二步直接让 AI 出清单，出来的东西漂亮但没法执行。

第 1 步 · 把这次发布的底子摊开

AI 写不出它不知道的架构。先把服务、变更点、依赖和现有回滚手段交代清楚，让它先找信息缺口，比让它直接给方案有用得多。

你是我的发布评审搭档。下面是我这次发布的基本情况，先不要给方案，只做一件事：把信息缺口列出来。服务：order-api，Java 服务，3 个实例，跑在容器里。本次变更有三处：一是新增订单超时取消逻辑，涉及一张新表 order_timeout_log；二是修改配置项 order.cancel.window，默认值从 30 改成 15；三是依赖下游 inventory-service 的新接口 /stock/lock/v2。发布方式：滚动发布，一次替换 1 个实例。可接受停机：无。现有回滚手段：镜像回滚、配置中心历史版本回滚。数据库变更工具：Flyway。请输出两样东西：一是为写出一份能回滚的发布清单，你还缺哪些信息，按重要性排序，不超过 8 条；二是每条缺口说明缺了会导致什么后果。不要写客套话。

预期产出：一张 5 到 8 条的信息缺口清单。最常被点出来的是「新表加不加索引」和「v2 接口在老版本客户端上是否兼容」，这两条恰恰是现场最容易卡住的。

第 2 步 · 生成动作、验证、回退三列骨架

让模型按固定表头输出，缺一列就标红。格式定死了，它就没法用「确认服务正常」这种话糊弄过去。

按下面格式，为刚才那次发布生成清单骨架。每一步必须是「动作 + 验证 + 回退」三件套，缺一件就标红。格式用 Markdown 表格，列为：序号、阶段、动作、验证方式（命令或界面）、判定通过的标准、回退动作、回退后如何验证。阶段分四段：发布前、发布中、发布后观察、回滚备用。硬性要求：一，验证方式必须是可以直接执行或直接在界面上看到的东西，不要写「确认服务正常」「观察日志」这类没法判定的表述；二，回退动作要写到命令级别，例如 kubectl rollout undo deployment/order-api，或写明在配置中心回滚到哪个版本号；三，数据库相关的变更如果不可逆，单独标出来，并在发布前补一条「先备份哪张表」的动作；四，涉及 inventory-service 的那一步，要给出对方尚未上线时的处理分支；五，总步数控制在 20 步以内，超了就合并。不要写解释，直接给表。

预期产出：一张 15 到 20 行的表格，四段分明。不可逆的动作会被单独打上标记，这部分是后面第三步的输入。

第 3 步 · 单独拆不可逆和半不可逆动作

加列、改字段类型、改默认值、删数据，这几类回滚不等于撤镜像。镜像退回去了，数据退不回去，这是我在真实故障里见过最多的一种误判。

把上表里所有「回滚不等于撤镜像」的动作挑出来，逐条分析，每条回答四个问题：一，回滚方式是什么，是加反向 SQL、恢复备份，还是只能靠前滚修复；二，回退到原状态大概需要多久，给量级即可，分钟或小时；三，回退过程中会不会丢数据，会丢哪一类数据；四，发布前能做什么让它变成可回滚，比如先加列不写值、双写一段时间、用开关控制。我特别关心 order.cancel.window 从 30 改成 15 这一条：如果有用户下单正好落在 15 到 30 分钟之间，回滚配置后这批订单状态会怎样？请给出你的判断依据，说明你是基于什么假设推出来的。输出成表格，不要长篇大论。

预期产出：一张 3 到 5 行的不可逆动作表。改配置那条通常会暴露出一个事实：配置能回滚，被新配置处理过的数据回不去。

第 4 步 · 把宽表格压成能打勾的执行稿

表格在发布会上没人看得下去，尤其手机上。转成纵向任务列表，一行一件事，每条自带失败分支，打印出来拿笔划。

把上面两张表合并，转成一份发布当天照着念的执行稿。要求：一，用 Markdown 任务列表，一条一行，一行只做一件事；二，每条格式为「阶段-序号 动作｜验证：xxx｜通过标准：xxx｜失败则：xxx」；三，时间窗写进阶段标题，例如「发布前 T-30 分钟」「发布中 T-10 分钟」；四，每个阶段末尾加一条「停止条件」，写清楚出现什么现象就立刻终止发布并转入回滚；五，开头留一块空白，写发布负责人、复核人、时间窗、变更单号；六，结尾留三行复盘位，分别是实际耗时、卡住的步骤、下次要改的地方。整份稿子控制在两页 A4 以内，我要打印出来手工打勾。

预期产出：一页半左右的执行稿，两页内打印得下。每个阶段末尾都有停止条件，这条是回滚决策的触发线，比任何回滚脚本都重要。

第 5 步 · 上线前把回滚段演练一遍

没演练过的回滚只能叫设想。演练不用全流程，只练回滚段，成本通常二十来分钟，能提前把「你以为能退」的幻觉打掉。

我要在预发环境演练这份清单的回滚部分，请你当我的观察员。演练范围只包含回滚段，不演练发布段。我每完成一步会告诉你结果，你需要做三件事：一，在我每一步操作前，提示这一步最容易漏的检查点；二，在我报完结果后，判断是否满足「回滚成功」的标准，并说明依据；三，全程记录各段耗时。现在先回答一个问题：一场只回滚的演练，最少要覆盖哪几个动作才算数？给出清单并说明为什么是这几个。

预期产出：一份 4 到 6 个动作的最小演练清单，加上各段真实耗时。把这组耗时回填到第 3 步那张表里，回退时间成本那一列才算有依据。

实测记录

拿一个三个实例、带一张新表和一处配置变更的服务走了一遍，数据是这次实际记的，不是估的。

最容易错的 3 个地方

1. 把回滚等同于撤镜像。配置和数据库都不在镜像里。纠正办法：单列一张不可逆动作表，逐条写明回退方式与数据影响。
2. 验证条件写成「服务正常」。现场没人判定得了这句话。纠正办法：每条验证必须是一条能贴进终端的命令，或一个页面上能报出具体数字的指标。
3. 清单写到四十步。超过一页没人照着念，等于没写。纠正办法：压在 20 步以内，重复动作合并成脚本，剩下的才是打勾项。

可复用的东西

五条提示词其实是一条流水线：交底、出骨架、拆不可逆、压成执行稿、演练校准。可以存成一个固定模板，换服务只改第一段的事实描述，后面四段原样复用，我的做法是把它们放在同一个对话里顺序追问。清单本身也别一次用完就丢，下一次发布在同一份稿子上增删，通常十来分钟就能改出来。

回到开头那句：能回滚的清单不是写出来的，是演练出来的。你家最近的发布里，有哪一步是真的退不回去的？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接