---
title: "回滚与失败处理"
description: "区分取消候选发布和恢复上一份配置，验证回滚后的副本及业务状态。"
---

> Documentation Index
> Fetch the complete documentation index at: https://cdelivery.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 回滚与失败处理

发布失败后，先确认失败发生在哪个阶段：候选配置尚未推广、正式副本正在更新，还是更新完成后业务才出现问题。不同阶段对应不同处理方式。

## 选择处理方式

| 当前情况 | 首先考虑 |
| --- | --- |
| Guardian 候选检查失败 | 查看候选日志，重试或取消候选发布 |
| 更新暂停或失败 | 检查更新状态、失败动作及可用回滚配置 |
| 新版本已运行但业务异常 | 评估上一份配置是否兼容当前数据，再决定回滚 |
| 数据库或外部数据已改变 | 使用相应数据恢复方案，不能仅依赖应用回滚 |

取消候选发布与撤销已运行版本不是同一个操作。不要仅看到“失败”就重复执行所有恢复按钮。

## 执行回滚

1. 以 Operator 或 Admin 打开应用概览。
2. 记录当前镜像、错误和关键业务状态。
3. 确认界面存在可用回滚操作，并阅读确认提示。
4. 提交后观察回滚状态、实际副本和日志。
5. 验证业务入口、关键功能和 XHealth 结果。

平台使用当前可用的上一份部署配置，不提供任意历史版本浏览器。没有可用上一份配置时，需要使用保存好的镜像版本和配置重新部署。

## 回滚策略

当前回滚会并行处理全部副本，失败动作是继续；更新顺序、观察时间和失败比例来自应用更新设置。

## 回滚不会恢复哪些内容

- 数据库写入、迁移和数据格式变化。
- 外部 API 调用及其他系统的副作用。
- 被你另外删除的数据卷或外部文件。
- 任意久远的历史配置或镜像。

旧程序可能无法读取新程序已修改的数据。执行前需要明确这种兼容性，尤其是有状态应用。

## 回滚后仍异常

先确认回滚是否真正完成，而不只是请求已接受。检查原先的问题是否来自镜像以外的因素，例如服务器故障、资源不足、仓库连接或外部依赖。

回滚配置本身也可能无法运行。此时保留错误和事件记录，按[更新与重启](/docs/zh-cn/guides/apps/lifecycle/)修正配置，或按数据恢复流程处理。不要把反复回滚当作长期修复方法。

Source: https://cdelivery.dev/docs/zh-cn/guides/release-safety/rollback/index.mdx