在真正需要之前演练回滚

概述

多数团队是在最糟糕的时刻才发现回滚不可用：镜像标签被覆盖、旧版本依赖一个已被迁移删除的列、或者没人记得必须同时切换某个开关。回滚演练把这些发现提前到预发环境的平静下午，失败只损失一小时而不是一次事故。演练的产出不是一句“通过”，而是一份记录了真实执行过的命令与实际耗时的发布手册。

步骤

1. 部署候选版本前记录当前 revision：

kubectl rollout history deployment/payments -n staging

2. 部署候选版本，并计时回滚到记录的 revision：

kubectl set image deployment/payments api=ghcr.io/acme/payments:1.5.0 -n staging
time kubectl rollout undo deployment/payments -n staging --to-revision=41
kubectl rollout status deployment/payments -n staging --timeout=180s

3. 验证旧版本能读取新版本写入的数据：

curl -fsS https://staging.example.com/api/orders/12345 | jq -r '.status'

4. 把实测命令、耗时与决策人写进发布手册。

验证

从做出回滚决定到流量恢复的总时长应落在目标窗口内，例如三分钟以内；Pod 应全部 Ready，读取新数据应成功。若旧版本能启动但读不到金丝雀期间写入的记录，说明回滚并未真正完成。回滚后仍持续报错，通常意味着问题在数据或外部依赖，而不是代码版本。

注意事项

• 预发无法复现生产的数据量与第三方状态，演练结论需要留有余量。
• 回滚代码不会撤销迁移，只有 expand/contract 设计才能保证安全。
• 必须保留至少两个历史镜像 digest，保留期长于发布窗口。
• 每次演练至少产出一项具体改进，例如调整保留策略或拆分迁移。
• 部署机制变更后应重新演练，未验证过的回滚只是计划而非能力。