新版本上线前，先把回滚想好

很多上线事故，问题其实不在新版本本身，而在出问题之后没法干净地退回去。服务挂了，大家手忙脚乱地找旧包、翻配置、现写回滚步骤，本来几分钟能解决的事，拖成了一两个小时。所以上线前最值得多花十分钟的地方，不是再测一遍功能，而是先把回滚想好。

第一步是确认旧版本还能不能原样跑起来。发布前先留好上一版的部署包和配置文件，别图省事直接覆盖掉。有些部署脚本默认会把旧文件删干净，等到想回滚时才发现手里什么都没有。留旧版的成本很低，就是多占一点空间；真要用的时候，它就是救命的东西。

第二步是想清楚回滚的触发条件。不要等到“感觉不对劲”才决定，而是提前定好：错误率超过多少、核心接口连续失败几次、关键流程走不通，就回滚。条件定得越具体，执行的时候越不用纠结，也不用在群里反复问“要不要回滚”。很多团队不是不会回滚，是在该回滚的时候犹豫了半小时。

第三步是把数据库的变更单独拎出来看。代码回滚相对容易，数据结构的变更最难往回走。加字段一般还好，删字段、改字段含义、做数据迁移，一旦执行就很难无损撤销。所以上线前先问一句：这一步要是想撤销，数据能不能原样回来？如果不能，就把数据变更和代码发布拆开，先上兼容的改动，等稳定了再清理旧字段。

第四步是留一个验证窗口。上线后别立刻宣布完成，先盯着核心指标跑一段时间：请求量、错误率、响应时间，还有业务上最关键的那一两个流程。确认都正常，再收尾；一旦触发了前面定好的条件，立刻按准备好的步骤回滚，不要边修边上线，那样最容易把小问题修成大事故。

最后还有一个小习惯：上线文档里把回滚步骤写在最前面，而不是附在最后。真出事的时候，没人有耐心从头翻到尾，第一眼能看到“出问题先执行这三步”，比什么都强。