回滚

Rollback

也常被叫作：退回去还原撤回上线

验收与证据通常止于「生产」约 1 分钟读完

你可能会这么说

「改完之后更糟了，能不能变回原来的样子？」

回滚 Rollback

把系统退回到上一个已知可用的状态，是所有高风险操作的入场券。

回滚不是失败的补救，是动手之前就要备好的退路。判断一个操作该不该做，很多时候不看它能带来多少好处，而看它出错时能不能退回来。

所以顺序是反的：先问怎么退，再决定要不要上。 「旧版本还在不在、怎么切回、要多久」——这三个问题在部署前答不出来，就不该按下那个回车。

说一个我们每天在用的笨办法。往线上发布页面时，每次覆盖之前先复制一份，文件名带上时间和用途，像 index.html.rollback_20260818_005030_pre_v23_update。覆盖完再把新旧两个文件的 SHA256 都算出来记下，然后从公网重新抓一遍线上页面，抓回来的哈希和服务器上的一致，才算真的发上去了。这套动作全程不到一分钟，至今救过我们不止一次——有一次发布漏刷了几处版本号，就是靠回滚点退回去重发的，而不是在线上硬修。

最贵的教训通常出在数据上：数据库结构一改，旧代码就读不了新数据，往往真的回不去。数据的回滚永远比代码的回滚难，涉及数据的备份要在动手之前做。

还有一条实战经验：出问题时先回滚，再排查。在线上一边调试一边让用户看着白屏，是最贵的调试方式。

长什么样真实可交互，不是截图

出问题→先回滚→服务恢复→再慢慢排查

✓ 有退路回滚点 index.html.rollback_时间戳_pre_版本
覆盖前已备份，公网抓回哈希和服务器一致才算发上
数据改动前已导出

✕ 没退路「直接覆盖了，应该没问题」
「数据库结构已经改了」
「旧文件删掉腾空间了」

右边那三句在事故复盘里出现的频率非常高，而且往往是同一次事故里一起出现的。

拆开看，里面有这几块

1
已知可用点 Known-good state
退回去的目标。它必须真实存在且完整，「大概是上周那版」不算。
2
回滚方式 Rollback method
具体怎么切：换目录、切分支、重启旧进程、还原数据库。
3
耗时 Time to recover
从决定回滚到服务恢复要多久。这个数字决定你能承担多大风险。
4
数据兼容 Data compatibility
代码退回去了，数据能不能配合。这是最容易被忽略、也最难补救的一环。

常见的有哪几种

换目录 / 切软链Swap directory

静态站最简单的回滚：把指向改回旧目录。秒级完成。

用在：静态网站、纯前端产物

版本回退Revert commit

用版本控制退回上一个提交并重新部署。

用在：有 Git 且部署流程完整时

蓝绿切换Blue-green

两套环境并存，回滚就是把流量切回去，几乎无停机。

用在：对可用性要求高

数据还原Data restore

从备份恢复数据。慢、可能丢中间数据，所以要尽量避免走到这一步。

用在：结构或数据被改坏

容易搞混？这样区分

回滚 ≠ 撤销 Undo / git revert

撤销通常发生在你自己的工作区，代价很小；回滚发生在已经生效的环境，要考虑用户、数据和时间。判断方法：有没有别人已经受到影响。

回滚 ≠ 备份 Backup

备份是存下来的那份东西，回滚是用它换回去的动作。有备份不等于能回滚——很多人有备份，但从没试过恢复，真要用时才发现恢复不了。

什么时候用得上

部署之前

先让对方回答：旧版本在哪、怎么切回、多久。答不出就先不部署。

改数据结构之前

先导出一份数据。这一步花几分钟，能省掉一场无法挽回的事故。

线上出问题时

先回滚恢复服务，再排查原因。顺序反了会让损失翻倍。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

在执行 [这个改动/部署] 之前，请先回答回滚方案，我确认之后你再动手：

1. 这次会改动 / 覆盖哪些位置（文件、目录、数据库表）？
2. 这些位置现在的内容是什么？备份放在哪、什么时候做的？
3. 如果出问题，具体的回滚步骤是什么（把命令写出来）？大概多久能恢复？
4. 这次改动涉及数据结构吗？如果代码退回去，旧代码还能读现在的数据吗？
5. 回滚会丢失什么（比如回滚期间产生的新数据）？

注意：不要为了让流程看起来顺利而说"风险很低不用回滚方案"。如果确实无法回滚，请直接说明「这一步不可逆」，我需要知道。

第 4 问是专业和业余的分水岭：代码能回滚但数据不能兼容，是最常见的「回滚失败」原因。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「生产」这层：线上真实环境有效，有回滚和观测。

要亲眼看到这些，才算数

备份真的存在：让他给出路径和大小，自己去看一眼文件在不在。
回滚命令写出来了，不是「可以恢复」这种保证。看得见的命令才是方案。
试一次。低风险时段真的回滚一次再切回来——没演练过的回滚方案不算方案。
确认回滚耗时你能接受（30 秒和 2 小时是完全不同的风险等级）。
涉及数据时，确认旧代码能读现在的数据，或者明确知道会丢什么。

它常这么糊弄你

「有备份，放心」——但备份是几周前的，或者从没验证能不能恢复。
「Git 里有历史，随时能退」——代码能退，线上进程、数据库结构和缓存不会自动跟着退。
「这个改动风险很低，不需要回滚方案」——风险低不代表不可逆。这两件事无关。
为了腾空间把旧版本删了。空间几块钱，事故很贵。
回滚方案写了但没人试过。真正需要它的时候，往往就是它第一次被执行的时候。

回滚必须验到「生产」层，因为它的价值只在真实环境里兑现。演练过一次的回滚，和纸上写着的回滚，是两回事。

考考你选一个你觉得对的

上线前，关于回滚最该确认的是哪一点？

想再深挖一点靠谱出处

git-revert（Git 官方文档）Git 官方文档 ↗git-reset（Git 官方文档）Git 官方文档 ↗Rollback（数据回滚）Wikipedia ↗

# 回滚 (Rollback)

> 把系统退回到上一个已知可用的状态，是所有高风险操作的入场券。

**你可能会这么说**：改完之后更糟了，能不能变回原来的样子？

回滚不是失败的补救，是**动手之前就要备好的退路**。判断一个操作该不该做，很多时候不看它能带来多少好处，而看它出错时能不能退回来。 所以顺序是反的：**先问怎么退，再决定要不要上。** 「旧版本还在不在、怎么切回、要多久」——这三个问题在部署前答不出来，就不该按下那个回车。 说一个我们每天在用的笨办法。往线上发布页面时，每次覆盖之前先复制一份，文件名带上时间和用途，像 index.html.rollback_20260818_005030_pre_v23_update。覆盖完再把新旧两个文件的 SHA256 都算出来记下，然后从公网重新抓一遍线上页面，抓回来的哈希和服务器上的一致，才算真的发上去了。这套动作全程不到一分钟，至今救过我们不止一次——有一次发布漏刷了几处版本号，就是靠回滚点退回去重发的，而不是在线上硬修。 最贵的教训通常出在数据上：数据库结构一改，旧代码就读不了新数据，往往真的回不去。**数据的回滚永远比代码的回滚难**，涉及数据的备份要在动手之前做。 还有一条实战经验：出问题时**先回滚，再排查**。在线上一边调试一边让用户看着白屏，是最贵的调试方式。

**也叫**：退回去、还原、撤回上线

## 你可以这样告诉 AI

```text
在执行 [这个改动/部署] 之前，请先回答回滚方案，我确认之后你再动手：

1. 这次会改动 / 覆盖哪些位置（文件、目录、数据库表）？
2. 这些位置现在的内容是什么？备份放在哪、什么时候做的？
3. 如果出问题，具体的回滚步骤是什么（把命令写出来）？大概多久能恢复？
4. 这次改动涉及数据结构吗？如果代码退回去，旧代码还能读现在的数据吗？
5. 回滚会丢失什么（比如回滚期间产生的新数据）？

注意：不要为了让流程看起来顺利而说"风险很低不用回滚方案"。如果确实无法回滚，请直接说明「这一步不可逆」，我需要知道。
```

## 怎么验证他真的做到了

通常止于层级：**生产** — 线上真实环境有效，有回滚和观测

- [ ] 备份真的存在：让他给出路径和大小，自己去看一眼文件在不在。
- [ ] 回滚命令写出来了，不是「可以恢复」这种保证。看得见的命令才是方案。
- [ ] 试一次。低风险时段真的回滚一次再切回来——没演练过的回滚方案不算方案。
- [ ] 确认回滚耗时你能接受（30 秒和 2 小时是完全不同的风险等级）。
- [ ] 涉及数据时，确认旧代码能读现在的数据，或者明确知道会丢什么。

常见糊弄：
- 「有备份，放心」——但备份是几周前的，或者从没验证能不能恢复。
- 「Git 里有历史，随时能退」——代码能退，线上进程、数据库结构和缓存不会自动跟着退。
- 「这个改动风险很低，不需要回滚方案」——风险低不代表不可逆。这两件事无关。
- 为了腾空间把旧版本删了。空间几块钱，事故很贵。
- 回滚方案写了但没人试过。真正需要它的时候，往往就是它第一次被执行的时候。

来源：https://mickerbook.com/reference/t/rollback/