1. 回滚基础：什么是镜像回滚、回滚的触发条件、回滚的原子性保证

镜像回滚，说白了就是「把容器或虚拟机从当前有问题的版本，快速切回上一个已知正常的版本」。我刚开始接触容器化部署时，觉得回滚不就是重新部署一遍旧版本吗？后来线上出过一次事故，才发现事情没那么简单。

你想想看，生产环境里跑着几百个实例，如果回滚操作本身出了问题，那可就雪上加霜了。所以这一章，我们先打好基础。

1.1 什么是镜像回滚

镜像回滚的核心动作，就是将运行中的实例（Pod、容器、虚拟机）的镜像版本，从当前版本切换到上一个稳定版本。它不是一个简单的「重新拉取旧镜像」，而是一套完整的版本切换流程。

我习惯把镜像回滚分为三个层次：

层次	说明	典型场景
容器级回滚	单个容器的镜像版本切换	Kubernetes Pod 中某个容器出问题
应用级回滚	整个应用所有实例统一回退	Deployment 回滚到上一个 Revision
基础设施级回滚	虚拟机或裸机上的镜像回退	OpenStack 实例回滚快照

我在项目中遇到过一种情况：开发同学以为回滚就是改一下镜像标签，结果因为镜像仓库里旧版本的 tag 被覆盖了，回滚后拉下来的还是新版本。嗯，这里要注意——镜像回滚依赖的是不可变镜像和版本追溯能力，不是简单的标签覆盖。

1.2 回滚的触发条件

回滚不是随便就能触发的。我一般把触发条件分为三类：自动触发、手动触发和策略触发。

1.2.1 自动触发

系统检测到异常指标后，自动执行回滚。常见的指标包括：

• 健康检查失败：Liveness/Readiness 探针连续失败超过阈值
• 错误率飙升：HTTP 5xx 比例超过 5%（这个阈值我一般设 1%，看业务容忍度）
• 延迟异常：P99 延迟超过基线的 3 倍
• 资源耗尽：OOM、CPU 持续 100% 等

1.2.2 手动触发

运维或开发人员通过控制台或 API 主动发起回滚。常见场景：

• 灰度发布后发现新版本有逻辑缺陷
• 数据库迁移脚本执行失败（需要先回滚应用层）
• 安全漏洞紧急修复后需要快速回退

手动触发有个坑——权限控制。我建议回滚操作必须经过审批，或者至少要有操作审计。否则，一个手滑就能把整个集群搞崩。

1.2.3 策略触发

基于发布策略的自动决策。比如：

• 金丝雀发布：新版本实例的错误率超过阈值，自动回滚金丝雀
• 蓝绿部署：切换后流量验证失败，自动切回蓝环境
• 滚动更新：更新过程中新 Pod 启动失败，暂停并回滚

1.3 回滚的原子性保证

原子性保证，是回滚机制里最容易被忽视的部分。说白了就是：回滚要么全部成功，要么全部失败，不能出现「一半新一半旧」的状态。

为什么重要？我给你举个例子：

假设你有 10 个实例，回滚过程中第 5 个实例失败了。如果系统不保证原子性，那就会出现 4 个新版本 + 6 个旧版本混跑的情况。这时候如果新版本有数据格式变更，那数据就全乱了。

1.3.1 原子性实现的三种模式

模式	原理	优点	缺点
全量替换	一次性创建所有新实例，再切换流量	原子性最强，切换瞬间完成	资源消耗翻倍
分批回滚 + 事务补偿	按批次回滚，失败时回退已成功的批次	资源占用少	实现复杂，补偿逻辑容易出 bug
快照回滚	基于存储层的快照整体回退	速度快，一致性高	依赖存储能力，不支持部分回滚

我个人习惯在关键业务上使用全量替换模式。虽然成本高一点，但原子性有保障。非关键业务可以用分批回滚，但一定要做好补偿逻辑的测试。

1.3.2 原子性保证的实践要点

• 状态检查：回滚前必须确认所有实例的当前状态一致
• 版本锁定：回滚过程中禁止其他变更操作
• 超时机制：设置合理的回滚超时时间，超时后自动触发补偿
• 审计日志：记录每一步操作，方便事后排查

1.4 回滚流程全景图

下面这张图展示了镜像回滚的完整流程，从触发条件到原子性保证，一目了然。

从这张图可以看出来，回滚不是简单的「切版本」。它是一套完整的流程：从触发条件开始，经过决策、执行、验证，最后到结果处理。每一步都要有原子性保证。

1.5 小结

镜像回滚的基础，说白了就是三件事：知道什么时候该回滚、知道怎么回滚、保证回滚不出岔子。触发条件要设得合理，原子性保证要做得扎实。我见过太多因为回滚本身出问题导致的事故了——回滚比发布更考验系统的健壮性。

嗯，这一章就到这里。记住一句话：回滚不是救命稻草，而是最后一道防线。防线如果本身有漏洞，那就真的没救了。