自动回滚

概述 凌晨 2 点 47 分，告警群炸了。一个支付服务新版本上线后 P99 延迟从 80ms 飙到 1200ms，值班同事第一时间按下回滚按钮。kubectl rollout undo 执行成功，旧版本 Pod 重新拉起，流量切回去。结果呢？服务彻底不可用了——因为新版本上线时跑了一个数据库迁移脚本，把订单表的 status 字段从 varchar(20) 改成了 tinyint，回滚后的旧代码根本不认识新的字段类型。 这不是杜撰。这是我在某出行项目亲历的一次故障。那次事故的 MTTR（平均恢复时间）是 1 小时 23 分钟，其中回滚操作本身只花了 47 秒，但回滚后服务不可用导致的排查时间占了 1 小时 22 分钟。 回滚不是银弹。设计不当的自动回滚比不回滚还危险——它会让你在已经出问题的窗口期再做一次变更，把"半挂"变成"全挂"。 这篇文章拆解 CI/CD 自动回滚体系的 5 层架构，给出 4 个生产级踩坑实录。不讲"什么是回滚"这种入门概念，直接上架构决策和工程权衡。如果你正在设计 CI/CD 回滚机制，或者被"回滚失败"坑过，这篇应该能帮到你。 为什么 90% 的回滚设计都是残缺的 先说一个反直觉的数据。微软对 Microsoft Teams 的 152 起生产事故做了系统研究（来源），发现超过 90% 的事故最终通过"不改代码"的方式缓解——回滚、配置变更、重启服务。但有意思的是，接近一半的事故在"缓解"阶段被延迟了，原因不是技术问题，而是"回滚决策不明确"和"修复部署太慢"。 换句话说，大多数团队不是没有回滚，而是回滚设计是残缺的。残缺在哪？看这张表： 回滚层次 常见做法 缺什么 后果 代码回滚 kubectl rollout undo 只回滚了镜像，没回滚配置 旧代码读新配置，启动失败 配置回滚 手动改 ConfigMap 没和代码版本绑定 配置漂移，下次部署带错误配置上线 数据回滚 不回滚 数据库迁移不可逆 旧代码连不上新 schema，全挂 流量回滚 切回旧版本 没考虑缓存和会话状态 用户请求打到旧版本但 session 数据在新版本里 回滚验证 不验证 回滚了就算完事 回滚本身引入新故障，无人发现 这五层里，漏掉任何一层，你的回滚机制就是残缺的。我见过太多团队，CI/CD 流水线里加了一个 kubectl rollout undo 就觉得自己有自动回滚了。实际上那只是"镜像回滚"，不是"服务回滚"。...