回滚
Rollback
中级通用回滚（Rollback）是上线后把某项变更恢复到先前可用状态的操作，常见做法是切回旧版本或关闭新功能。它解决的是新版本出故障时如何尽快止损的问题，比如网站更新后无法下单，先切回能正常下单的版本。
你可能会说：「刚上线的网站不能下单了，能不能先切回之前能用的版本，等查清原因再改？」
读之前建议先了解
动手看看下单故障后切回旧版
1
上线前，流量入口把下单请求送到旧版，用户可以正常完成下单。
要点回滚时，我们到底在恢复什么？
- 1
先找出造成故障的变更
你看到下单失败，不代表整个网站都要退回旧状态。我们先看故障从哪次上线开始、涉及哪些服务或功能，再决定回滚范围。范围越准确，越不容易把同期正常的改动也撤掉。
- 2
切回旧版本也要核对依赖
回滚通常不是把代码文件改回去就结束了。旧版本还得能配合当前的配置、接口和数据库工作；如果上线时改过数据结构，直接切回旧代码也可能报错。所以动手前，要确认旧版本现在还能运行。
- 3
止损之后还要验证结果
回滚的目标是恢复服务，不是证明故障原因已经找到。切回后，我们会用实际业务流程验证，例如重新走一遍下单，并观察错误日志。确认用户能正常使用后，再排查新版本的问题。
容易混淆的地方
回滚说的是让已生效的变更退回可用状态，部署可以是实现回滚的手段。它也不同于用户在编辑器里点“撤销”：撤销针对当前操作，回滚常涉及线上版本、配置或数据。尤其是用户在故障期间新建的订单，不能因为切回旧代码就假定它们也该消失。
什么时候用
适合用
- 网站上线新版结算页后大量订单提交失败，已有可用旧版本，先回滚服务恢复下单。
- AI 工具更新模型调用配置后持续报错，确认旧配置仍可用，先回滚配置减少影响。
- 后台发布新权限规则后员工无法处理工单，先回滚这次规则变更，再检查条件。
不适合用
- 新功能还没上线，只是在本地觉得实现不合适；直接修改代码或放弃这次提交，不涉及线上回滚。
- 生产环境只是少数用户看到了文案错字，且能安全地快速改正；直接发布修正通常比切回整个版本更合适。
- 用户想恢复自己刚删掉的一段表单内容；这里需要撤销操作或找回草稿，不是回滚线上版本。
练一练选一个答案，看看解释
网站上线新版结算页后，用户无法提交订单。这次上线没有修改数据库，旧版本此前下单正常且仍可部署。你会怎么处理？
让 AI 帮你做复制给 AI Agent 直接用
新版结算页上线后无法提交订单。请先确认上一个可用版本与当前数据库、配置兼容，给出回滚步骤和验证下单的检查项；不要恢复数据库备份或删除上线后产生的订单。服务恢复后再协助定位新版故障。