崩溃恢复

这是什么

崩溃恢复，就是为你上线的应用提供版本历史加即时回滚。你所做的每一次改动都会被保存为一个还原点，因此一旦某次改动出了问题，你只需一键就能回到上一个可用版本。受保护的是运行在你域名上的真实应用——而不仅仅是编辑器里的一份草稿。

为什么重要

业务系统全天候在线——订单不断进来、客户在登录、支付在运行——所以一次糟糕改动导致的宕机，会实实在在地损失金钱和信任。能够即时撤销，意味着你可以持续改进应用，而不必在每一次改动上拿整个生意去赌。安全，正是让你能安心迭代一个正在运行的系统的前提。

在 ybuild 上怎么用

ybuild 在每次改动时都会为你的应用拍下快照，并在运行版本背后保留完整的历史记录。一旦出了问题，你回滚到一个已知可用的时间点，你的域名就会在片刻之间重新提供可用的应用——无需手动去恢复任何备份。因为应用是由 ybuild 托管的，恢复只需一键，而不是一张工单。

一个还原点究竟保存了什么

回滚的价值，取决于它到底保存了什么。最幼稚的那种“撤销”只保留前端的一份副本，别的什么都不留——这对真实应用毫无用处，因为一个业务系统是四样东西在同时运行：客户看到的前端、处理订单或预约的后端逻辑、决定你记录结构的数据库表结构，以及决定谁能登录的鉴权规则。只回滚其中一样而不管其余，你会得到最糟糕的那种“坏掉”：一个能正常加载的界面，却指向一个不再匹配的后端，在客户正要完成的那一步操作上抛出错误。

这正是为什么 ybuild 的还原点会把整个技术栈当作一个整体来做版本管理。每次你改动应用，平台都会捕获一个一致的快照——前端、后端、表结构和鉴权一起——所以你回滚到的那个版本，是一个真正运行过的系统，而不是一堆彼此不匹配的零件。当你还原时，ybuild 不会从头重建任何东西；它让之前那个可用版本一直保持就绪，并把你的域名重新指回它。恢复就是一次指针切换，这正是它感觉起来是即时的原因，而不像一次完整重新部署那样要花上几分钟甚至几小时。这与大型云平台采用的思路如出一辙——它们让一个应用的两个版本同时存活，回滚时靠切换负载均衡器而不是重新部署——ybuild 只是把这一切自动化了，就在你自己的域名上，无需你做任何配置。

自己造一个撤销按钮，还是直接在 ybuild 上拥有它

自己做这件事，是一个实打实的工程项目。要安全地对生产环境做改动，传统做法意味着：在版本控制里给每一个构建打标签，好让你能识别出一个已知可用的版本；运行一个足够贴近生产、可以让你信任的预发布环境；采用蓝绿或金丝雀发布，让回滚成为一次配置更改，而不是手忙脚乱地救火；还有那个悄悄把人拖垮的部分——让数据库迁移的回滚脚本与代码保持同步，外加你真正演练过恢复的备份。一份你从未恢复过的备份不是备份，只是一个猜测。

在这一切之下，还潜藏着一种更棘手的失败模式：回滚本身也可能失败。如果一次坏掉的部署已经把你的数据库迁移成了旧代码读不了的结构，那么单单回退代码，只会让你卡在两个版本之间进退两难。把这件事做对，恰恰是把强团队和弱团队区分开来的地方。谷歌的 DORA 研究——业界被引用最多的软件交付衡量标准——发现顶尖团队能在一小时内从生产故障中恢复，而表现较差的团队要花上长得多的时间；而且最快的团队同时也是最稳定的，而不是最鲁莽的。代价在于成本：恢复目标越激进，达成它所需的基础设施通常越昂贵，这正是为什么真正的持续恢复方案长期以来对一个单打独斗的创始人或一家小店来说都遥不可及。

在 ybuild 上，这一切都不需要你去搭建，也不需要你另外付费。平台在每次改动时都为整个技术栈做版本管理，让先前的可用版本保持热备，从而让回滚成为一次指针切换而非重建，并把这整套能力以一键的形式呈现出来。你用日常语言描述出的那个应用——运行在 ybuild 上、由你自己的域名提供服务——就能获得顶尖水准的恢复能力，无需搭建预发布环境、编写迁移回滚脚本，或手动去演练备份。

那些边界情况，以及它们对一个正在运营的生意意味着什么

最要紧的问题，都是关于你数据的问题。当你回滚一个坏掉的功能时，那些在它出问题期间进来的订单会怎样？正确的答案——也是 ybuild 为之而生的答案——是：回滚会把应用的逻辑和结构还原到一个可用版本，而你托管数据库里的实时记录会继续累积——所以撤销一次糟糕改动，是在修好应用，而不会抹掉这期间落下的客户、预约或支付。这个区别就是整场游戏的关键：你回退的是应用，而不是删掉这门生意。

了解一下普通备份的边界在哪里是值得的，因为这解释了为什么版本历史是一种不同的工具。为众多大公司运行云产品的 Atlassian 明确表示，它的基础设施备份并不用于撤销由客户发起的破坏性改动——一段覆盖数据的脚本、一个被删掉的项目——而且它的恢复目标针对的是计划外的宕机，而不是你自己的失误。换句话说，基础设施备份保护的是数据中心；它并不能为你有意做出、结果却出了错的改动提供一次干净的撤销。而那次撤销，正是逐次改动的还原点所提供的，这也是为什么 ybuild 保留了带标签的版本历史，让你可以扫一眼就找到上一个可用时间点，而不用去猜某个时间戳。

对一个正在运营的生意来说，这最好用灾难恢复规划中的两个术语来理解：你能停机多久（你的恢复时间），以及你能承受损失多少（你的恢复点）。在一个预约或结账应用上，这些都不是抽象概念——每一分钟离线，都是收入在流走、信任在实时崩塌。即时的一键回滚把这两个数字都推向零。但更深层的回报是行为上的。当撤销真正做到即时，你就不再害怕去动这个应用了。你上线那个改进、试用那个新字段、调整那个流程——因为出错的代价只是一次点击，而不是一个泡汤的周末。一个主人不害怕去改进它的生意，就是一个会不断变好的生意，而这，正是一张真正的安全网——铺在你自己域名上一个正在运行的系统之下——真正为你买到的东西。

常见问题

如果我回滚，会不会丢掉这期间进来的订单和客户？

不会。回滚会把你应用的逻辑和结构还原到上一个可用版本，而你托管数据库里的实时记录会继续累积。撤销一个坏掉的功能是在修好应用，而不会抹掉在它出问题期间落下的订单、预约或支付。

我能回退到多久以前？

ybuild 在运行版本背后保留你应用的完整版本历史，所以你可以还原到任何一个先前的可用还原点——而不只是最近的那个。每一次改动都是它自己带标签的时间点，所以你能找到那个确切的上一个可用时刻，而不用去猜某个时间戳。

恢复有多快——客户会察觉到吗？

几乎是瞬间的。ybuild 让先前那个可用版本保持热备，回滚时靠把你的域名指向它来完成，所以这是一次指针切换，而非一次重建。你的站点会在片刻之间重新提供可用的应用，而不像手动重新部署或恢复备份那样要花上几分钟甚至几小时。

这不就是备份吗？

相关，但更强。备份保护的是你的数据；版本历史加回滚保护的是整个应用——前端、后端、表结构和鉴权一起。就连大型平台也指出，基础设施备份并不能撤销一次你有意做出、结果却出错的改动。ybuild 逐次改动的还原点，正是为这种撤销而生的。

我能只撤销一次糟糕改动，而不把其他一切都扔掉吗？

可以。因为 ybuild 在每次改动时都保存一个还原点，你回滚到的是上一个已知可用的时间点，而不是某个遥远的版本。你会恢复到事情出错前的那个确切时刻，同时保留在它之前所有的成果。