回滚是一种恢复操作，通过撤销软件或配置更改，将系统恢复到之前已知的良好状态。在 Kubernetes 中，部署历史默认保留 10 个旧的 ReplicaSet，而 PostgreSQL ROLLBACK 会丢弃当前事务中的更新，而不是之前已提交的数据。
新版本上线，首批用户打开 App，产品团队还没庆祝完，客服工单就来了。结账页面崩溃、新的 API 响应让旧版客户端失效，或者配置变更把请求发到了错误的路径。团队需要恢复服务，而无需猜测哪些文件变了，也无需要求每位用户重新安装。
这正是回滚的用武之地。它不是预防手段，也不是万能的“撤销”按钮。新版本已经部署。回滚是在该版本引发错误、性能下降、崩溃或不安全行为时采取的受控响应。实际中，它通常会重新部署上一个应用版本，或恢复某个版本化配置，然后验证服务是否已恢复到可接受状态。这 故障分析技术 团队之后采用的做法依然重要，因为回滚能让事故稳定下来，但无法解释其原因。
目录
部署失败的现实
移动团队发布了一个包含导航变更和后端兼容性更新的新 bundle。灰度用户首先收到该版本。几分钟后，用户反馈主屏幕无法加载。监控显示错误率上升，但团队尚无法确定问题源于 bundle、API、功能开关还是依赖项。
安全的做法不是在受影响用户群体扩大的同时争论完美的诊断方案。如果团队拥有已知良好的构建产物，可以停止发布并回滚到该版本。应用将恢复到之前验证过的状态，同时工程师调查缺陷并准备修复。
回滚是恢复，不是预防
预防措施 预防是在错误变更到达用户前将其拦下。测试、code 审查、依赖检查、金丝雀发布和审批门禁都是为此。 回滚是在预防失效后，或生产环境出现意外交互后才开始的。
回滚可以针对交付系统的多个部分：
- 应用 code： 重新部署上一版可执行文件或 Web bundle。
- 配置： 恢复带版本号的设置、路由规则或功能配置。
- 资源： 回退到兼容的图片、脚本或内容文件。
- 功能开放范围： 通过 kill switch 或受众控制禁用新功能。
- 数据： 中止活动事务或从备份恢复数据，但受严格得多的约束。
最后一类需要单独处理。当 artifacts 不可变且依赖项保持兼容时，回滚应用 code 通常很简单。回滚已提交的数据可能造成数据丢失、损坏或监管问题。因此，发布回滚不应意味着所有相关数据库操作都能安全回退。
为什么频繁交付需要快速恢复
现代持续交付让发布更频繁。这带来一个实际要求：失败变更的运维成本必须保持有限。一个团队如果部署很快，但恢复需要漫长的手动流程，那它只优化了交付的一半。
手动回滚仍然可行，但它依赖于运维人员记住哪些文件发生了变化、哪些服务器被更新，以及哪些配置属于上一个版本。发生故障时，这个过程会变得很脆弱。自动化系统通过保留不可变 artifacts、监控健康信号并在满足预设条件时回滚，改善了这条路径。
实战规则： 把回滚当作经过演练的生产能力，而不是故障发生时才有人去摸索的紧急按钮。
回滚也不是永久修复方案。它能暂时恢复服务，但底层缺陷仍然存在。工程师仍需找出触发原因，评估失败发布期间写入的数据，并发布修正后的版本，或做出其他经过考量的运维决策。
现代系统如何保留发布历史
恢复系统只能恢复它能识别并取回的内容。如果构建时依赖发生漂移、二进制文件被覆盖，或原生壳不再支持该 bundle，仅保留旧的源码 commit 并不够。
现代发布系统通过保留从源码到已部署产物的证据链来解决此问题。团队标记稳定修订版本，锁定依赖图，构建可寻址的产物，并记录哪个产物到达了每个环境。这份记录给运维人员一个具体目标，而不是“回到上一版本”这种模糊指令。
以 Kubernetes 为具体模型
Kubernetes 清晰地展示了这一结构。Deployment 控制 ReplicaSets，而这些 ReplicaSets 保留部署修订版本。Kubernetes 保留 10 个旧的 ReplicaSet，团队可以更改该保留设置，只需使用 spec.revisionHistoryLimit。将值设置为 0 会完全禁用回滚，正如 Kubernetes Deployment 参考.
Operator 可以回退到紧邻的上一个修订版本，或选择某个确切的历史修订版本。回滚会更改 Deployment 的 Pod 模板配置，包括容器镜像和 labels 等字段。它不会自动还原副本数等无关字段。之后，rollout status 检查会确认目标修订版本是否已恢复健康。
这种区别对于移动端和 Web-bundle 的交付至关重要。系统应记录：
- 当前活跃版本： 每个环境、channel 或设备接收到的具体版本。
- 产物标识： 内容可寻址或其他不可变的 build，而不是可原地替换的文件。
- 依赖兼容性： 之前的 bundle 是否能与当前的 native shell、API、服务及数据 schema 协同工作。
- 恢复结果： 设备或实例是否成功采用了恢复后的版本。
“Previous” 必须指某个具体产物
例如这样的标签： previous 只有当它指向一个不可变的 release 时才有效。如果团队覆盖了该标签背后的文件，恢复目标可能会在无人察觉的情况下发生变化。如果 artifact 已从存储中过期，部署系统可能知道版本号，却缺少恢复所需的字节。
对于 Capacitor 应用，web bundle 同样运行在 native shell 中。旧的 JavaScript bundle 可能依赖当前 shell 已更改的 native 插件、权限或 bridge 行为。不检查兼容性就直接恢复，可能只是用一个故障替换另一个故障。
本指南中介绍的 Capgo 的版本控制与回滚方案 体现了一个更广泛的原则：release 历史必须明确、可检索，并与收到每个 build 的用户群体关联。只有团队能快速回答三个问题时，rollback 才会成功：当时生效的是什么？哪个版本是稳定的？现在什么版本能与周边系统安全地一起运行？
数据库与数据回滚的潜在风险
部署失败可能会让团队收到一条紧急指令：“直接恢复到上一个版本。”这对可执行的 code 或许可行，但对数据库可能不安全，因为已提交的客户操作可能无法干净地撤销。
应用回滚和数据回滚是不同的操作，失败模式也不同。 一个 code 发布版本通常可以用另一个不可变工件替换。schema 迁移可能重命名或删除了字段、转换了存储值，或改变了后续写入所依赖的假设。订单、支付、消息、记录和同意信息都是有效的用户数据。它们不应因应用发布失败而消失。
为什么 code 和 schema 会不同步
假设发布版本 A 理解旧 schema，而发布版本 B 添加了列或更改了值的存储方式。在 B 部署并运行其迁移后，回滚到 A 可能导致旧版 code 查询不再存在的字段，或错误地解释新数据。
反向操作会导致另一种故障。在 B 版本进程仍活跃时回滚数据库，可能导致写入失败或留下部分状态。同时回滚 code 和数据库看似更干净，但可能会擦除部署后产生的合法活动。 应用回滚与数据回滚之间的区别 应纳入每个发布计划，而不仅仅是数据库操作。
PostgreSQL 展示了事务回滚的作用。 ROLLBACK 它会中止当前事务并丢弃该事务内所做的更新，因此部分应用的写入组不会持久化。它无法撤销由先前事务提交的更改。在 ROLLBACK 事务块之外执行不会逆转已存储的数据。
设计向前推进的迁移
更安全的发布设计在过渡期间保持应用版本和模式变更的兼容性。团队还应记录 Capacitor 应用的 SQLite 加密实践 以及模式兼容性、访问控制和恢复程序。
扩展-收缩迁移通常遵循以下顺序：
- 扩展： 添加新的 schema 功能，同时保留旧功能。
- 采用： 部署能够读写两种表示形式的 code，或者在保留旧路径的同时引入新路径。
- 迁移： 通过受控流程迁移现有记录，并配合监控和对账。
- 契约： 仅在依赖版本不再需要旧结构时，才移除它。
这一顺序使 code 回滚更具可行性，因为旧版应用仍可使用支持其契约的 schema。但这并不意味着所有回滚都是安全的。它降低了恢复过程引入新不兼容性的概率。
金融科技、医疗和电商系统还需要可审计性、隐私控制、支付状态处理以及对账计划。向前修复可能比撤销有效交易或恢复会删除后续用户活动的快照更安全。
数据库规则： 仅当依赖项和数据契约支持该操作时，才自由回滚 code。除非有经过测试的独立恢复流程证明相反，否则应将已提交的数据视为向前推进的记录。
在部署前，根据可逆性对每个发布组件进行分类。Code、配置、功能暴露、资源、schema 和用户数据遵循不同的恢复规则。经过测试的备份可以在灾难性损坏后提供帮助，但恢复备份不能替代向后兼容的迁移设计。
做出回滚的运维决策
回滚是一项运营决策，而不只是一条部署命令。必须有人判断观察到的问题是否来自本次发布、之前的状态是否安全、受影响的用户是否多到值得回滚，以及向前修复是否能更有效地降低风险。
DORA 将变更失败率定义为需要立即干预的部署，通常涉及回滚或热修复，并单独跟踪失败部署的恢复时间。因此回滚既是可靠性事件，也是交付性能结果，正如以下内容所述 DORA 指标的历史.
在故障发生前定义触发条件
优秀的团队会在发布设计阶段就商定回滚条件。触发条件可能结合崩溃信号、错误率、健康检查失败、支持报告或金丝雀对比。单个噪声事件不一定需要回滚，但在受监控用户群中出现的明确模式应有既定的响应措施。
自动回滚仅适用于故障明确、可逆且可通过可靠信号观察到的情况。对每个异常都做出响应的自动化系统可能会在版本间来回切换、掩盖根本故障或反复引入不兼容依赖，从而加剧事故。
对于移动应用，决策需要额外的上下文：
- 离线用户： 部分设备不会立即检查更新。
- 混合版本： 新旧客户端可以长期共存。
- 分阶段发布： 渠道或金丝雀发布可以在生产环境之前暴露问题。
- 原生兼容性： 恢复后的 web bundle 必须能与已安装的 shell 协同工作。
- 数据影响： code 回滚可能无法撤销后端已接收的写入操作。
回滚与 roll-forward 的对比
Rollback 会恢复到之前的状态，Roll-forward 会发布修复性变更。两者没有绝对更安全的一方。
Rollback 通常适用于可逆的展示层缺陷、错误配置，或在更改持久化状态前就失败的发布。当迁移已经执行、用户已创建有效记录，或旧版应用不支持当前 schema 时，Roll-forward 可能更安全。如果无需替换整个发布版本就能隔离故障功能，kill switch 甚至更安全。
Runbook 应明确事故指挥官、有权执行该操作的人员、确认成功的健康信号，以及产品和支持团队的沟通路径。它还应说明团队何时停止尝试回滚，转而开始向前修复。
一份实用的 Runbook 会记录：
- 目标版本 及其 artifact 位置。
- 兼容性检查 适用于原生客户端、服务、依赖项和模式。
- 爆炸半径控制例如渠道、群组或金丝雀发布。
- 成功标准包括恢复信号和用户影响。
- 后续负责人负责修正后的发布和事故复盘。
本指南中介绍的 暂停发布与回滚的区别 在运维层面至关重要。暂停可限制进一步的影响范围。回滚则会主动更改受影响用户接收到的内容。团队在选择任一操作前，应明确自己需要哪种处理方式。
移动端与跨平台应用的即时恢复
传统移动端发布恢复依赖应用商店分发。如果缺陷存在于原生二进制文件中，团队必须准备修复版或旧版二进制文件，提交至相应商店，并等待分发到达用户。该流程适用于原生变更，但当缺陷仅限于 JavaScript、CSS、配置、文案或 Web 资源时，会带来不必要的摩擦。
OTA 交付改变了 Web 层变更的恢复路径。live update 系统可以向受控用户群发布已签名的 bundle，允许设备在下次启动或检查更新时应用该 bundle，并保留之前的 bundle 作为回退方案。但当原生 code 或平台权限发生变化时，它并不能免除应用商店审核，也无法保证数据回滚的安全。
应用商店分发与 Live Updates 解决的是不同问题
| 恢复需求 | 应用商店二进制发布 | 已签名的 live update |
|---|---|---|
| 原生插件或权限变更 | 适用 | 并非替代方案 |
| JavaScript 或 CSS 缺陷 | 恢复路径较慢 | 在政策和兼容性允许时适用 |
| 受众控制 | 商店渠道与发布控制 | 定向渠道与分阶段交付 |
| 恢复目标 | 已发布的二进制文件 | 版本化 Web bundle |
| 主要依赖项 | 应用商店分发 | 更新器、签名、兼容性与可观测性 |
例如， Capgo 支持 Capacitor 实时更新，通过向指定渠道分发签名的 Web bundle，保留版本历史，在后续启动或更新检查时应用更新，并在新 bundle 未通过配置的健康检查时提供回滚保护。差分分发可仅发送变更文件，而渠道可区分 Beta、Staging、生产环境或特定客户受众。这些功能有助于团队缩小 Web 层发布失败的影响范围，但无法绕过验证原生 Shell 兼容性或后端数据契约的需求。
自动回退需要可信的健康信号
更新器不应仅因下载完成就将 bundle 标记为健康。它应区分获取、安装、启动和实际应用健康状态。如果新 bundle 在下次启动时崩溃或未通过健康检查，设备可以回退到上一个稳定版本，而无需下载完整的应用商店二进制文件。
这种恢复仍有边界。设备可能处于离线状态，失败的更新可能已更改服务端数据，或者之前的 bundle 可能与已安装的原生 Shell 不兼容。每设备日志和版本采用数据有助于支持团队确定哪些用户接收了哪个 bundle，以及回退是否成功。
本指南中介绍的 Capacitor 更新回滚配置指南 回滚机制应与发布策略相辅相成，而非取而代之。请对每个构建产物进行签名，限制向生产环境渠道发布的人员权限，保留回退版本，并在真机上测试故障路径。只有当系统能证明恢复的 bundle 是预期版本时，快速分发才具有价值。
构建高韧性的发布策略
回滚就绪状态是整个发布系统的属性。如果团队无法识别旧构建的依赖项，无法查看哪些设备已采用该版本，或从未针对类生产数据测试过恢复流程，那么对象存储中的旧构建并不能提供有意义的保护。
从产物链开始。给稳定的源码状态打 Tag，锁定依赖，保留已签名的构建，绝不覆盖已发布的 release。然后，把每个产物关联到环境、channel 和部署事件。团队应能在不依赖开发者本地机器的情况下还原发生了什么。
降低恢复风险的四项控制措施
- 不可变产物： 为每个生产 bundle 分配唯一标识并存储。可以用“previous”指针选择 release，但绝不能修改 release 本身。
- 兼容迁移： 采用“先扩展后收缩”方法，让新旧应用版本能在受控过渡期间共存。
- 受控自动化： 仅对能区分真实发布失败与瞬时服务问题的信号执行自动回退。
- 依赖校验： 在允许目标修订版本生效前，检查 Native Shell、plugins、API、服务和 schema。
可观测性形成闭环。采集每台设备的版本、启动结果、更新状态、失败原因和采用状态。支持团队可据此判断用户仍在使用失败的 bundle、已收到回退，还是从未下载更新。
团队应使用真实数据和混合客户端版本演练恢复路径。在空开发数据库中恢复 code 的测试，可能无法发现由真实记录、旧 schema 变体、排队写入和未完成迁移引起的兼容性问题。恢复测试还应验证授权、签名、制品获取、渠道定向以及沟通计划。
恢复能力不取决于是否存在旧版本构建，而取决于团队能多精确地控制影响范围并恢复兼容状态。
发布计划应明确依赖协调的责任归属。需要更广泛框架来 管理敏捷环境中的依赖关系 的团队，可以利用这种规划纪律，在部署前对齐移动端、后端、数据库和产品变更。
实用的就绪性审查会问：
- 团队能否识别每个渠道上当前激活的确切制品？
- 能否在不更改已安装 code 的情况下暂停曝光？
- 能否恢复已签名且兼容的 bundle？
- 能否证明应用回滚后数据库依然安全？
- 能否按版本检测故障，而非仅在服务整体层面？
- 当回滚会损坏有效数据时，能否选择向前滚动（roll-forward）？
如果任何环节不够明确，发布流程就存在恢复缺口。在下次事故发生前补上这个缺口，比在用户等待时临时救火成本更低。
更安全部署的关键要点
Rollback 会撤销已应用的软件或配置更改，将系统恢复到已知良好状态。它不能预防缺陷、修复根本原因，也不会自动撤销已提交的数据库更改。
保持应用构建产物不可变且可寻址。跟踪每次发布的活跃版本、依赖项、Native Shell 兼容性和受众。将 Schema 迁移和用户数据视为独立的恢复目标，因为 code rollback 可能让数据库仍处于已变更状态，而数据库回滚可能破坏有效记录。
采用分阶段交付、可靠的健康信号、明确的授权，以及经过测试的 Runbook。对移动端团队来说，签名的 OTA bundle 可为兼容的 Web 层变更提供快速恢复，而原生变更仍需走相应的二进制发布路径。衡量恢复效果要看故障影响范围（Blast Radius）是否缩小、服务恢复是否经过验证，而不是看有没有旧 Build。
Capgo 为 Capacitor 和 Electron 团队提供签名的 Live Update bundle、定向 Channel、版本历史、单设备可观测性，以及针对兼容 Web 层发布的 Rollback 保护。检查你当前的恢复路径，看看 Capgo 如何帮助你暂停风险暴露、恢复已知良好的 Bundle，并让事件响应保持可控。
