一次平稳回滚背后，往往在发布前就已经做完了准备

真正让人安心的发布，不是“出了问题再想办法”，而是在上线前就把退路摆好。

有一次我们上线一个接口改造，功能本身不算大，真正花时间的是把回滚条件写清楚。谁来执行、退到哪个版本、数据库有没有反向脚本，这些都要提前定好。等线上波动真的出现时，执行的人只需要照着预案走。

我会提前写下来的三件事

  • 触发回滚的信号是什么，比如错误率、超时、支付回调积压
  • 回滚动作由谁执行，谁负责盯日志和指标
  • 回滚后要做哪些二次确认，别把服务拉回来了，数据却还停在中间态

很少被写进去的一段

我现在会把“不会回滚的部分”单独列出来。像缓存预热、外部回调、定时任务状态，这些经常不是把代码切回去就结束了。

pm2 reload codenest
sqlite3 data/blog.db ".backup data/backups/pre-release.sqlite"
curl -fsS https://codenest.one/health

这几行命令不复杂，真正有用的是它们背后那套顺序：先保底，再切换，再验证。

回滚文档什么时候算合格

当一个不在场的同事也能照着它把事情做完，这份文档才算真的写好了。