回滚策略设计：全量回滚 vs 增量回滚、蓝绿部署中的回滚、灰度发布中的回滚、金丝雀发布中的回滚
补丁分发失败，说白了就是「上线翻车了」。这时候最考验人的不是怎么修 bug，而是怎么让系统先活过来。我见过太多团队在故障发生时手忙脚乱，最后把回滚搞成了二次事故。
回滚策略没有银弹。你得根据部署模式、影响范围、业务容忍度来选。下面我把四种常见场景拆开讲，每个都带点我踩过的坑。
全量回滚 vs 增量回滚
先搞清楚这两个概念。全量回滚是把整个服务恢复到上一个稳定版本；增量回滚只回滚变更过的文件或数据。听起来增量更优雅对吧？但实际没那么简单。
| 对比维度 | 全量回滚 | 增量回滚 |
|---|---|---|
| 操作复杂度 | 低，一键切换 | 高，需精确识别变更 |
| 回滚速度 | 快（秒级到分钟级） | 中等（依赖文件数量） |
| 数据一致性 | 强，整体切换 | 弱，可能遗留旧数据 |
| 适用场景 | 核心服务、数据库变更 | 静态资源、配置文件 |
| 风险 | 影响面大，但可控 | 容易漏回滚，导致「僵尸文件」 |
我个人习惯：数据库变更必须全量回滚。增量回滚在数据库上就是个伪命题——你回滚了表结构，但数据已经写进去了，怎么搞？
那什么时候用增量？静态资源、前端文件、配置文件。这些文件之间没有强依赖，替换回去就行。但要注意：增量回滚必须记录变更清单，否则你根本不知道哪些文件动过。
蓝绿部署中的回滚
蓝绿部署是我个人最喜欢的模式。说白了就是两套环境，一套跑着旧版本（蓝），一套部署新版本（绿）。流量切到绿环境后发现问题，直接把流量切回蓝环境。
这个回滚策略其实就一句话：切流量，不切代码。
蓝绿回滚的核心优势：
- 回滚时间 = DNS 刷新或负载均衡切换时间，通常 30 秒以内
- 旧版本环境一直在线，不存在「回滚后启动失败」的问题
- 可以并行验证，绿环境留着排查问题，不影响线上
但蓝绿部署有个隐藏问题：数据库兼容性。你想想看，蓝环境用的是旧 schema，绿环境可能已经改了数据库结构。切回蓝环境后，新写入的数据可能跟旧 schema 不兼容。
我建议的做法：
- 数据库变更必须向前兼容（只加字段，不改字段，不删字段）
- 如果必须做破坏性变更，先做数据迁移，等两个版本都兼容了再切流量
- 回滚时，数据库也要回滚到上一个兼容版本
# 蓝绿切换脚本示例（简化版）
# 假设 Nginx upstream 有两个组：blue 和 green
# 切到绿环境
sed -i 's/set $upstream blue/set $upstream green/' /etc/nginx/conf.d/app.conf
nginx -s reload
# 发现问题，切回蓝环境（回滚）
sed -i 's/set $upstream green/set $upstream blue/' /etc/nginx/conf.d/app.conf
nginx -s reload小技巧： 我习惯在负载均衡层保留一个「回滚按钮」——其实就是个脚本，一键切回旧环境。别等到出事了再现场写命令，那时候手都是抖的。
灰度发布中的回滚
灰度发布是让新版本先覆盖一小部分用户，没问题再逐步扩大。回滚策略跟蓝绿不一样——你不是整体切，而是逐步缩窄灰度范围。
举个例子：你计划灰度 10% 的用户，发现问题了。这时候不是直接回滚所有用户，而是把灰度比例降到 0%，让新版本不再接收新流量。已经在灰度中的用户怎么办？
这里分两种情况：
- 无状态服务： 直接切回旧版本，用户无感知
- 有状态服务： 需要等当前请求处理完，或者做 session 迁移
我记得有一次灰度回滚翻车了。灰度比例是 5%，但那个 bug 会导致用户登录态丢失。回滚时我们直接把灰度比例降到 0%，结果那 5% 的用户已经丢了登录态，而且因为回滚太快，连错误日志都没来得及收集。
灰度回滚的三个原则：
- 先停止灰度，再排查问题（别一边查一边让更多人受害）
- 保留灰度日志，方便事后分析
- 灰度比例越大，回滚影响越大——所以灰度初期比例要小，比如 1%
金丝雀发布中的回滚
金丝雀发布跟灰度有点像，但更精细。金丝雀节点是单独的一台或几台机器，先让它们跑新版本，跟旧版本集群一起提供服务。回滚时，直接把金丝雀节点摘掉就行。
说白了，金丝雀回滚就是把金丝雀放回笼子。
具体步骤：
- 从负载均衡中摘掉金丝雀节点
- 确认旧版本集群能承接所有流量
- 销毁或重置金丝雀节点
- 保留金丝雀节点的日志和监控数据
这里有个容易忽略的点：金丝雀节点的数据怎么处理？ 如果金丝雀节点写入了数据，回滚后这些数据就跟旧集群不一致了。我建议金丝雀节点使用独立的数据库实例，或者只读副本，避免数据污染。
金丝雀回滚 vs 灰度回滚：
| 维度 | 金丝雀回滚 | 灰度回滚 |
|---|---|---|
| 影响范围 | 极小（几台机器） | 取决于灰度比例 |
| 回滚速度 | 秒级 | 分钟级（需调整路由规则） |
| 数据风险 | 低（可隔离数据） | 中（灰度用户数据可能已写入） |
| 适用场景 | 核心服务、高风险变更 | 常规功能上线 |
我个人建议：高风险变更先用金丝雀，稳定了再转灰度。金丝雀就像先派个侦察兵，侦察兵挂了，大部队别动。
最后说一句：回滚策略不是上线后想的，是上线前就定好的。每次变更前，先问自己三个问题：
- 如果这次变更挂了，我怎么回来？
- 回滚需要多长时间？
- 回滚过程中，用户会受影响吗？
想清楚这些，再点那个「发布」按钮。