改版上线当晚出问题，团队手忙脚乱地找原因，而网站一直处于半瘫痪状态。这种情况之所以常见，是因为没有提前准备回滚方案。
回滚不是认输，它是把损失控制在最小范围内的专业做法。
回滚前要准备什么
上线之前，这些东西必须已经就位：
- 旧版本完整备份：代码、数据库、上传的文件，缺一不可
- 配置文件备份：服务器配置、CDN 配置、跳转规则
- 一键回滚脚本：把切换动作写成脚本，别到时候现敲命令
- 回滚后的验证清单：确认旧版本能正常工作
- 负责人和联系方式：出问题找谁，五分钟内能联系上
其中第 3 条最实在。凌晨两点手敲命令，出错的概率远高于跑一个测试过的脚本。
几种回滚方式
- 整站切回旧版：最快最彻底，适合新版本有严重问题
- 单页面回退：某个页面有问题，只把那一页换回旧的
- 功能开关关闭：新版里某个功能出问题，用开关单独关掉
- 数据库回滚：只在数据出错时用，风险最高，要格外小心
第 4 条要特别谨慎：回滚数据库意味着丢弃回滚点之后产生的所有新数据，包括用户提交的表单。除非数据安全受到威胁，否则优先用其他方式修复。
红线怎么定
提前写清楚，达到就回滚，不要现场讨论：
- 网站整体不可访问超过十分钟
- 表单或支付等核心功能完全失效
- 发现数据丢失或被篡改
- 出现安全漏洞被利用
- 转化率断崖式下跌且找不到原因
相反，这些情况不必回滚，可以热修复：
- 个别页面样式错乱
- 某张图片显示不对
- 文案错别字
- 非核心功能的小异常
决策要快
约定一个简单的规则：发现问题后三十分钟内无法定位和修复，就先回滚。之后再从容排查。
很多团队的毛病是总觉得"再给我十分钟就能修好"，结果拖成两小时。对客户来说，网站打不开两小时和二十分钟，印象差别很大。
回滚之后
不是结束了，而是：
- 确认旧版本完全正常：走一遍核心流程
- 评估影响：这段时间损失了多少访问和询盘
- 排查根因：找到问题再重新上线，别急着再来一次
- 补上测试用例：这次漏掉的场景，下次要覆盖
- 重新安排上线窗口
事后复盘
写一份简短的记录，包含：
问题现象：发现时间：影响范围：处理过程：根本原因：改进措施：重点是根本原因和改进措施。只写"某某操作失误"没有意义，要写清楚为什么会发生这个失误——是流程缺失、检查不到位，还是没有验证手段。
演练一次
如果改版规模较大，建议在上线前实际演练一次回滚：在测试环境或者低峰期，真的切回旧版再切回来。演练一次你就会发现预案里有多少想当然的地方。
有预案的团队上线，和没预案的团队上线，遇到同一件事的结果可能差十倍。
—— 一位处理过多次线上事故的运维