RTO，返回本地部署

Source: Dev.to

我们是如何走到这一步的

迁移到云端的优势一直很明显：无需大额资本支出（CAPEX），只需每月付费，计算、网络以及其他一切都由别人提供。随着首席技术官们开始提出“提升并迁移”（lift and shift）策略，并伴随几乎是巴甫洛夫式的响应，云采用成为默认设置，逐渐演变成一个让人麻木的流行词。我们忘记了，归根结底，我们只是把业务运行在别人的电脑上。

这种麻木感通常会在那台“共享”电脑的本质变得痛苦明显时被打破。2017 年，Cloudflare 的一个 HTML 解析器的单一 bug 将成千上万家互不相关公司的私有内存泄露到公共搜索引擎缓存中。如果说那是一次关于隐私的警告，那么最近的宕机则是一次关于可用性的明确教训。当一次针对 React 框架漏洞的防火墙调整被部署时，另一个解析器 bug 导致半个互联网瘫痪。为什么我的店铺要因为别人使用 React 而宕机？这不是任何技术领袖能够防止的。更别提那种“你的客户数据一定会泄露，但可以把责任推给别人”的保证了吧？

在集中式模型中，你用硬件的麻烦换来了一个你无法控制的冲击半径风险。幸运的是，自云迁移早期以来，格局已经根本改变。如今，Kubernetes、Terraform 以及声明式供应原则等技术让我们能够把物理机架当作云区域来对待。我们不再管理服务器，而是管理清单（manifest）。这种转变使我们能够将一个全自动、自愈的云集群打包进本地环境，几乎不需要人工干预，完全由大公司使用的同样 GitOps 工作流来控制。

我们终于具备了技术成熟度，能够拒绝在最大竞争对手的“屋子”里开设数字店铺的尴尬——这正是 AWS 与电子商务的现状。

RTO（Return to On‑premise）有点怀旧情结，想念服务器机架，但更多的是能够宣称“我出错了，我可以自行承担宕机的责任”。