企业 AI 项目 Wiki · 环境、版本与上线

回滚

也常写作Rollback · 版本回退 · 部署回滚 · 系统回退

定义

回滚是发现一次变更造成不可接受结果后，按照预先确认的目标基线和顺序执行新的受控变更，将受影响组件恢复到已知可运行且经过验证的兼容状态，并核对变更期间产生的数据与外部影响。回滚的完成条件不是旧版本重新启动，而是服务、数据、权限、业务流程和观察指标达到事先规定的恢复状态。

回滚本身也是一次变更

可靠的回滚不是删除新版本或把标签指回 `previous`。交付系统通常会选定一个早期的已知良好 release，再创建一次新的 rollout 把它部署到同一目标。这样才能留下新的执行、审批和验证记录，也能处理环境在两次部署之间已经发生的变化。

“上一个版本”不一定是正确目标。它可能从未在当前区域、当前数据库状态或当前配置下成功运行，也可能存在已经修复的安全问题。回滚前应选择明确版本和完整配置基线，并核对它是否能够读取变更后产生的数据。

平台的回滚范围通常有限。例如 Kubernetes Deployment 的 revision 主要保存 Pod template；回退该 revision 不会自动恢复数据库、外部配置、Secret 内容、消息、文件或已经调用的第三方系统。项目必须把平台动作和完整业务恢复分开。

变更前怎样写出可执行的回滚方案

明确触发条件
定义自动停止、人工评估和必须立即回滚的指标或事件，包括安全、数据、业务和可用性硬条件。
告警规则、阈值、判定窗口和例外
指定目标基线
记录要恢复的应用制品、配置快照、基础设施版本、数据库兼容点、模型与知识状态，不能只写“上一版”。
版本清单、摘要、快照和最后已知良好记录
逐组件说明动作
为流量、应用、配置、Schema、数据、队列、缓存、定时任务和外部依赖分别写恢复或补偿步骤及先后顺序。
组件级回滚矩阵与依赖图
规定数据策略
说明是否停止写入、怎样保留回滚窗口内的新交易、旧版本是否能读新数据，以及采用兼容迁移、反向迁移、复制、恢复还是人工对账。
数据切点、RPO、备份与对账方案
分配权限和责任
确定谁触发、谁批准、谁操作数据、谁确认业务恢复、谁通知用户，以及自动回滚可以执行到什么范围。
责任表、紧急权限和升级路径
设定恢复目标
给出停止影响、恢复核心能力、处理积压和完整关闭的目标时间，避免只写一个模糊的“尽快恢复”。
恢复时限、业务优先级和降级目标
准备失败后的下一步
回滚也可能失败或让问题更严重。预先规定何时中止回滚、隔离流量、进入降级、从备份恢复、向前修复或启动事故响应。
二级恢复方案和事故 Playbook

什么时候回滚，什么时候暂停或向前修复

处置	适用判断
先停止扩大	渐进部署或发布刚出现异常时，先暂停新实例、Traffic 或功能暴露，保存现场并确认信号；这是控制影响，不等于回滚完成。
撤回用户暴露	功能开关、路由或权限可快速切回旧体验，而新制品暂留环境中。适合先保护用户并为技术判断争取时间。
执行回滚	已知良好基线可取得、与当前数据和依赖兼容、恢复步骤经过测试，且回滚风险低于继续运行或现场修复时采用。
向前修复	变更已经产生旧版本无法读取的数据、外部协议已经切换、回滚窗口已关闭，或一个小而确定的补丁比回退更安全时采用；仍需审批、测试和恢复计划。
降级或隔离	回滚路径不确定、关键依赖同时故障或影响正在扩大时，先关闭高风险功能、切换只读、停止消费者、隔离区域或转人工，保持核心能力。
备份恢复或灾难恢复	数据或基础设施已损坏，不能靠重新部署旧版本恢复时，进入单独的恢复流程；这通常涉及 RPO、RTO、数据丢失评估和更高授权。

不同组件为什么不能用同一种回滚方法

应用与运行镜像

重新部署经过验证的旧制品，优先使用摘要和不可变仓库；确认旧版本需要的运行时、Secret、接口和依赖仍可用。

流量与功能状态

切回旧环境、旧Deployment或关闭Feature Flag通常最快，但要处理Session黏性、缓存、长连接、区域传播和仍在执行的请求。

配置与Secret

应用旧版Code却保留新配置可能继续故障。使用不可变配置Snapshot或明确差异清单恢复；Secret轮换通常不应简单恢复已经泄露或撤销的旧值。

基础设施

通过受控IaC版本重新应用资源状态，先评估删除、替换、地址变化和有状态资源影响；不要用无记录的手工操作拼出“看起来像旧环境”。

数据库Schema

旧应用必须能读取当前Schema。优先采用扩展—迁移—收缩等向后兼容步骤；删除列、改变语义或重写格式后，反向Migration可能昂贵、缓慢或不安全。

业务数据

回滚Code不会消除变更窗口内的新订单、审批、付款或用户修改。直接恢复旧Backup可能丢失正确交易，需要停止写入、复制回流、选择性修复、补偿交易或人工对账。

队列、任务和缓存

旧消费者可能无法理解新消息，正在运行的Job可能继续产生副作用。需要暂停生产者/消费者、处理版本化消息、清理或重建缓存，并决定积压怎样重放。

外部动作

已发送邮件、短信、付款、工单、文件、WebHook 或实体操作不能靠技术回滚撤销。必须登记实际结果，并执行取消、冲正、通知或其他业务补偿。

一次回滚怎样安全执行

宣布并控制变更
指定 Incident 或 Rollback负责人，冻结无关部署和配置修改，记录触发时间、症状、受影响范围和当前状态。
限制新增影响
暂停Rollout和Release，按需要停止写入、高风险功能、队列消费者或外部动作，同时保留诊断日志和证据。
确认目标与兼容性
比较当前与目标制品、配置、Schema、数据格式、依赖和Security修复，确认回滚顺序、所需容量及已关闭的一次性门。
建立恢复点
在进一步变更前保存当前配置、数据库、队列、Traffic、实例和关键日志的Snapshot或备份，便于调查及回滚失败后的第二方案。
按组件顺序恢复
先处理兼容前置和Traffic保护，再用正常部署路径应用目标制品与配置；Database、Writer、Reader和异步组件按协议兼容顺序执行。
分层验证
检查实例Ready、依赖、Schema、读写、消息、缓存、权限、关键业务流程和外部结果，并与回滚前基线及目标状态比较。
逐步恢复服务
先向内部或少量Traffic恢复，观察稳定后再扩大；处理积压、补偿外部动作和用户沟通，不在验证前直接恢复全部负载。
记录并关闭
记录每步结果、人工偏差、数据影响、最终运行基线和遗留事项。回滚成功后仍建立问题单、根因分析、修复版和再次发布条件。

怎样证明回滚有效，以及回滚失败怎么办

验证恢复而非命令成功

部署工具完成只证明操作结束；还要验证用户任务、数据正确性、安全控制、告警、容量、积压和外部依赖。

进行升级—降级测试

在生产相似环境中让新旧版本并存，先完整升级，再按真实顺序降级；覆盖 API、序列化、Batch、任务和失败依赖，确认前后兼容。

保留观察窗口

低频Job、缓存失效、异步回调或逐步传播的问题不会立即出现。按系统周期规定观察时间，并避免同时开始下一项变更。

识别回滚新故障

如果错误率、数据不一致或权限问题在回滚中上升，立即暂停后续步骤，保留当前状态，执行二级恢复或向前修复，而不是机械继续。

区分技术恢复与业务修复

服务恢复后仍可能需要补单、重发、冲正、重新索引、权限重算、客户通知和监管报告；这些工作必须有独立Owner和关闭证据。

复盘回滚能力

记录发现、决定、开始、核心恢复和完全关闭时间，评估目标是否明确、Artifact是否可取、权限是否够、步骤是否有效，并把改进纳入下一次变更门槛。

企业 AI 系统回滚还要处理什么

恢复完整AI组合

Model Route、Prompt、Guardrail、Knowledge Index、Embedding/Reranker、Tool Schema、权限和应用编排要恢复到相互兼容的清单，不能只切回旧Model。

模型Traffic可以先切回

保留旧Deployment时可先把Endpoint Traffic转回已知良好Model，确认Session和Fallback后再决定是否删除新Deployment；切流是影响控制，完整回滚仍需核对配置。

Knowledge使用别名或指针

新Index验证后再切换Alias，并保留旧Index到观察期结束。回切时核对文档增删、租户权限、引用、Cache和新Index期间产生的Feedback或标注。

会话与记忆可能跨版本

旧Prompt或Tool可能无法理解新版本写入的Conversation State、Memory或Plan。需要版本标识、兼容读取、清理或隔离，不能让错误状态继续驱动Action。

智能体副作用要补偿

AI已经发送的消息、修改的Record、创建的Order或触发的Workflow不会随Model回滚消失。暂停Tool权限，按Audit逐项确认、撤销或人工处理。

质量恢复要重新评测

技术指标恢复不证明回答质量恢复。对触发回滚的Scenario、固定评测集、高风险样本和真实问题重跑并比较Grounding、拒答、工具与人工接手。

Hosted Model未必可回到旧行为

供应商若不提供固定Snapshot，Alias行为可能无法回退。预案应包含备用Model、Route关闭、功能降级、人工服务和供应商事件处理，而不是假设旧名称可恢复。

回滚容易与什么混淆

相关概念	与回滚的区别
撤回发布	撤回通过Flag、Route、权限或Channel停止新增用户暴露；回滚把技术组件恢复到目标基线。撤回可以先于或替代部分回滚。
Git revert	Git revert创建一个新Commit反向应用某次源码变化；它不自动构建、部署、恢复配置、数据库或生产流量。
备份恢复	备份恢复把Data或系统恢复到一个时间点，可能产生RPO内Data损失；回滚可以只重新部署旧制品而不恢复Data。
故障切换	Failover把服务转移到备用实例、区域或系统，目标通常是维持可用性，软件Version可能不变。
向前修复	Fix forward在当前状态上部署新的修复，而不是恢复旧基线；用于回滚不兼容或小修复更安全的情况。
灾难恢复	Disaster Recovery处理站点、区域、基础设施或大范围Data不可用，范围和恢复目标通常大于单次变更回滚。
业务补偿	补偿撤销或抵消已经发生的订单、付款、通知等业务后果；技术回滚无法自动完成这些动作。

依据与适用边界

本文解释软件系统发生不良变更后，把明确的技术状态恢复到已确认基线的回滚。回滚不是一个能自动倒转所有后果的按钮：应用、基础设施、配置、数据库、流量、队列、缓存、模型、知识和外部业务动作具有不同的可逆性。它也不等于撤回用户暴露、Git revert、备份恢复、故障切换、灾难恢复或向前修复，尽管实际处置可能组合这些方法。具体目标、时限、数据处理和授权必须按变更逐项确定。