发布失败后，先确认失败发生在哪个阶段：候选配置尚未推广、正式副本正在更新，还是更新完成后业务才出现问题。不同阶段对应不同处理方式。
选择处理方式
| 当前情况 | 首先考虑 |
|---|---|
| Guardian 候选检查失败 | 查看候选日志，重试或取消候选发布 |
| 更新暂停或失败 | 检查更新状态、失败动作及可用回滚配置 |
| 新版本已运行但业务异常 | 评估上一份配置是否兼容当前数据，再决定回滚 |
| 数据库或外部数据已改变 | 使用相应数据恢复方案，不能仅依赖应用回滚 |
取消候选发布与撤销已运行版本不是同一个操作。不要仅看到“失败”就重复执行所有恢复按钮。
执行回滚
- 以 Operator 或 Admin 打开应用概览。
- 记录当前镜像、错误和关键业务状态。
- 确认界面存在可用回滚操作，并阅读确认提示。
- 提交后观察回滚状态、实际副本和日志。
- 验证业务入口、关键功能和 XHealth 结果。
平台使用当前可用的上一份部署配置，不提供任意历史版本浏览器。没有可用上一份配置时，需要使用保存好的镜像版本和配置重新部署。
回滚策略
当前回滚会并行处理全部副本，失败动作是继续；更新顺序、观察时间和失败比例来自应用更新设置。
回滚不会恢复哪些内容
- 数据库写入、迁移和数据格式变化。
- 外部 API 调用及其他系统的副作用。
- 被你另外删除的数据卷或外部文件。
- 任意久远的历史配置或镜像。
旧程序可能无法读取新程序已修改的数据。执行前需要明确这种兼容性，尤其是有状态应用。
回滚后仍异常
先确认回滚是否真正完成，而不只是请求已接受。检查原先的问题是否来自镜像以外的因素，例如服务器故障、资源不足、仓库连接或外部依赖。
回滚配置本身也可能无法运行。此时保留错误和事件记录，按更新与重启修正配置，或按数据恢复流程处理。不要把反复回滚当作长期修复方法。