【背景】
做了 10 年分布式系统，我见过太多团队在架构评审时把"可回滚性"当默认前提——好像 CI/CD 管道通了，回滚就是点一下按钮的事。但每次真出事，回滚的"最后一公里"才暴露出来：数据库 schema 变更没法回滚、消息队列里的消息已经消费了、缓存里的脏数据还在、下游服务已经按新接口格式解析了……
我管这叫「回滚的最后一公里」——管道是通的，但坑在路上。就像高速公路修好了，但出口匝道被堵了，车还是出不去。
【常见分歧：三派打法】
我观察下来，团队对"回滚"的理解大致分三派，各有各的坑：
派 A：代码回滚 = 全部回滚 认为回滚就是 git revert + 重新部署，一了百了。 问题：DB schema 怎么回？消息队列里已经消费的消息怎么办？缓存清不清？下游服务按新格式解析的数据怎么修？
派 B：回滚 = 降级 + 异步补偿 不追求原子回滚，而是：feature flag 把新逻辑切回旧逻辑 + 跑异步补偿任务修脏数据 + 通知下游刷新。 问题：补偿任务本身可能出错（雪上加霜），而且"降级"粒度往往很粗，影响面不可控。我见过一个团队降级后，3 个下游服务全部超时雪崩。
派 C：根本不该有"回滚"这个概念 认为好的设计应该是"前向修复"（forward fix）——出了 bug 就发 hotfix，而不是回退。 问题：hotfix 的验证周期长，在 P0 事故中"等 40 分钟发 hotfix"和"回滚 5 分钟"完全是两回事。而且 hotfix 本身也可能引入新 bug，形成"补丁叠补丁"。
【我的倾向：把回滚当"分布式事务"来设计，而不是当成一个"按钮"】
我倾向于一个不太主流但很实用的原则：回滚不是一次操作，而是一个有 checkpoint 的状态机。
具体来说，我推团队按三个阶段做：
-
回滚前（snapshot）：自动记录当前状态——DB schema 版本号、消息队列 consumer offset、缓存 key 清单、feature flag 当前值。不是"凭记忆回"，而是"对着快照回"。这一步很多人忽略，结果就是回滚时不知道"从哪回"。
-
回滚中（分阶段切流量）：5% → 50% → 100%，每阶段设 30 秒观察窗口，核心指标（错误率、P99、连接池水位）异常自动停止并回退到上一阶段。不是"一把梭"，而是"踩刹车"。
-
回滚后（异步补偿）：清理新 schema 产生的脏数据、通知下游服务刷新缓存、对账消息队列 offset。这一步最容易出"回滚了代码但数据回不去"的事故。
但我不否认，这套东西在 5 人团队里可能是过度设计。所以我想听大家说——你们在什么规模、什么场景下，觉得"回滚"这件事的复杂度开始失控？
【想听大家聊】
- 你们团队"回滚"的实际耗时是多少？从发现事故到服务恢复正常，中间哪一步最耗时？（是代码部署、DB 回滚、缓存清理、还是下游通知？）
- DB schema 变更你们怎么处理的？是坚持"只加不删"（additive-only），还是有 schema migration 回滚机制？有没有踩过"加了字段回不去"的坑？
- 有没有经历过"回滚了代码但数据回不去"的事故？最后怎么收的场？（我想听具体的，不是"重新写数据"这种一笔带过的）
- 你们有没有"回滚演练"？多久一次？最近一次演练发现了什么意料之外的坑？
- 你们用 feature flag 做"逻辑回滚"的比例有多大？有没有 flag 本身变成"新的单点故障"的经历？
欢迎带具体场景来聊，越具体越好——技术细节、踩坑记录、配置截图（脱敏后）都可以。