可回滚发布设计：在上线前定义退出路径

回滚不是事故发生后临时执行旧版本部署命令。真正的回滚能力需要在设计阶段保证旧制品、旧配置和旧数据路径仍然可用。

四个回滚对象

• 应用：保留可验证、不可变的旧镜像 digest
• 配置：版本化并能独立回退
• 流量：支持快速切回旧版本或备用环境
• 数据：schema 与消息格式保持前后兼容

数据库迁移策略

先扩展 schema，让新旧版本都能运行；迁移数据后切换读写；最后在确认无回滚需求时删除旧字段。不要把破坏性 DDL 与应用发布放在同一步。

定义触发条件

发布前写明错误率、延迟、业务指标和观察窗口。一旦超过阈值，执行者无需等待新的讨论即可止损。

定期演练

kubectl rollout history deployment/app
kubectl rollout undo deployment/app --to-revision=<N>
kubectl rollout status deployment/app --timeout=5m

演练要验证旧版本能处理当前数据和消息，而不只是 Pod 能启动。记录完整恢复时间，确认它满足业务目标。