SaaS 公共责任：云不会永存，你的数据也不会

云不会永存，你的数据也不会

当我开启我的技术运营职业生涯（也就是现在的 DevOps），世界发生了翻天覆地的变化。那是在新千年到来之前，当时，世界上最大、最知名的软件即服务公司 Salesforce 还窝在旧金山的一间公寓里。

那个时候，本地数据中心占据了主导地位。成排的机柜填满了无数的房间。不管是从人力还是机器零部件的角度来看，这些系统的建立和维护都非常昂贵。当时，仅使用 SaaS 应用程序构建业务在技术上是可行的，但在逻辑上却是一场噩梦。在后来的几年里，本地数据中心仍然是运行软件系统的默认方式。

但科技的发展日新月异。因此，仅仅在 Salesforce 开始鼓吹“软件终结”三年之后，AWS 就上线了，彻底改变了游戏规则。

现如今，我们可以在短短几天内构建出一个新的 SaaS 工具，并部署到世界各地。企业现在正以创纪录的速度拥抱 SaaS 解决方案。中小型企业的技术栈可以包含 100 多个 SaaS 应用程序。20 年前，让一家企业运行这么多应用程序是不可想象的，而且需要花费数百万美元的运营资源。那时我在 Rewind 公司负责技术运维，一台调制解调器和一台笔记本电脑承担了我们的全部软件需求。

SaaS 为现代企业创造了一个完全不同的世界。我们可以以比以往任何时候都更低的成本和更快的速度建立和发展业务。就像大多数“好得令人难以置信”的事情一样，这里也存在一个陷阱。所有这些便利都伴随着固有的风险。在我早期作为 DevOps 工程师的时候，很少有人讨论这个风险，即使现在也很少有人讨论。然而，意识到这个风险却重要，否则的话，你每天所依赖的所有重要的 SaaS 数据可能会在眨眼之间消失。

它可能会永远消失。

SaaS 的公共责任

这可能是不言而喻的，但你租用 SaaS 应用程序，并不是拥有它们。那些巨头公司以前自己维护大型的服务器机房，现在使用 SaaS 提供的服务。你只需要通过操作系统或 API 访问他们的服务器（和你的数据）。现在，你可能在想：“我知道这些，但那又怎样”？

这就是问题所在。

如果你仔细看一下 SaaS 公司的服务条款，就会发现它们尽最大努力确保自己的应用程序始终处于启动和运行状态。无论服务器是受到火灾、流星撞击还是人为错误的影响，SaaS 公司都努力确保每次用户登录时软件都是可用的。问题是，他们的责任也仅限于此了。

作为用户，你需要自己备份和恢复你在服务中输入和保存的数据。因此才有了“共同责任模型”这一说。这个模型主要与 AWS 有关，但实际上也关系到所有的云计算。

上图对云计算元素保护的各种场景进行了划分。从图中可以看到，在 SaaS 模型中，最大的责任在软件供应商身上。但是，用户仍然需要负责一些事情——用户访问和数据。

最近几年，我和其他从事 DevOps、站点可靠性工程或 IT 工作的人聊过。我可以告诉你，他们对此存在很大的怀疑。他们通常不会相信 SaaS 供应商尽然没有实时备份他们的数据。不过我理解他们，因为我也曾经与他们处于一样的境地。因此，当我遇到这种质疑时，我就让他们去查看每个 SaaS 供应商所提供的各种服务条款。这是GitHub的，这是Shopify的，还有Office 365的，白纸黑字都写得清清楚楚。

之所以会有公共责任模型，主要与每个应用程序的架构有关。SaaS 供应商构建软件，目的是最大化利用操作系统，而不是为了给用户生成的数百万甚至数十亿个数据点创建快照或保存它们。现在，这个问题不能“一刀切”。一些 SaaS 供应商可能可以恢复丢失的数据。然而，根据我的经验，如果他们做了，通常也是旧快照，是不完整的，要恢复所有数据可能需要几天，甚至几周。

这只是因为 SaaS 供应商以一种对自己来说有意义的方式将所有用户的数据集中在一起。一旦数据被删除或泄露，想要找回来就像是大海捞针。

SaaS 是如何丢失数据的

下一个问题是 SaaS 工具丢失数据的可能性。甲骨文和毕马威的一项研究发现，49%的 SaaS 用户曾经丢失过数据。我们的一项研究也发现，40%的用户曾经丢失过数据。有三种情况会丢失数据：人为错误、网络威胁和第三方应用集成。

人类和技术之间一直存在相互依存的关系。我们需要面对这个现实，这也是我所从事的职业能够存在的一个主要原因！因此，无论是有意的还是无意的，人类的行为都是造成数据丢失的常见原因，例如，上传会破坏数据集的 CSV 文件、意外删除产品清单或通过强制提交覆盖代码库。

还有人为的干扰，比如有权限的人进入系统，然后用核武器摧毁了一大堆东西。这听起来可能有些牵强，但我们已经看到很多案例，雇员或外包员工闯了大祸后被解雇。这虽然不常见，但确实发生过。

其次是网络威胁，这是大多数技术运营团队都已经习惯了的问题。我的大多数同行都知道，在全球新冠疫情大流行期间，网络攻击发生的频率有所增加，但其实在疫情出现之前就已经在增加了。勒索软件、网络钓鱼、分布式拒绝服务（DDoS）等攻击手段都被用来扰乱业务运作。如果遭遇了这类攻击，数据可能就会泄露或被完全删除。

最后，第三方应用集成可能是造成数据丢失的另一个令人沮丧的根源。仔细阅读一下你最喜欢的 SaaS 工具的应用程序服务条款，它们可能可以帮你节省很多时间，但它们可能对你使用这些工具创建和保存的数据有很大的控制权。我们已经看到应用程序覆盖并永久删除大量数据的案例。当团队发现问题的时候，造成的破坏已经不可挽回了。

还有其他一些情况会造成数据丢失，但以上这些是最为常见的。好消息是，你可以通过采取一些措施来减少停机时间。我将简单介绍一个常见的方法，即编写自己的 Git 备份脚本。

编写 GitHub 备份脚本的方法

有很多方法可以达到目的，比如谷歌的“git 备份脚本”等等。这些方法都有自己的局限性。下面是其中一些脚本的要领。

使用 Cron 脚本创建本地备份

实际上就是编写一个脚本，在不同的时间间隔使用 cron 作业克隆代码库（需要注意的是，你使用的 cron 作业工具将依赖你所使用的操作系统）。这种方法本质上是每间隔一段时间获取一次快照。要恢复丢失的代码库，只需要选择想要恢复的快照。要进行完整的复制，可以使用git clone --mirror来镜像你的代码库。这可以确保所有远程和本地分支、标签和引用都被包括在内。

这种方法的优点是不依赖外部工具，惟一的成本是你的时间。

这种方法也有一些缺点。实际上，你不会得到一个完整的备份。克隆的代码库中不会包含钩子、引用日志、配置信息、描述文件和其他元数据。它还涉及大量的手动工作，如果要加入错误监控、日志和错误通知，则会更加复杂。最后，随着快照的堆积，你需要考虑如何清理和归档。

使用 Syncthing

Syncthing是一个 GUI/CLI 应用程序，可用于同步多个设备上的文件。所有设备都需要安装 Syncthing，并相互连接。需要注意的是，同步和备份不一样，因为同步不是在创建一个副本，而是确保文件在多个设备上保持相同。

这种方法的优点是它是免费的，而且更加直观，因为它提供了 GUI。它的缺点是同步只适用于单个设备之间，所以你不能直接从代码托管平台备份代码库。当发生错误时，需要进行手动修复。此外，同步可能会导致代码库的损坏和冲突，特别是当有人在开发不同的分支时。因为需要持续地扫描、哈希和加密，Syncthing 会消耗大量的资源。最后，它只维护一个版本，而不是多个快照。

使用 SCM Backup

SCM Backup会创建一个 GitHub 或 BitBucket 代码库的离线副本。如果你要同时备份多个代码库，就会发现它与其他工具不一样的地方。在初始配置之后，它通过 API 获取所有代码库的列表，你也可以根据需要过滤掉一些代码库。

SCM 可以指定备份文件夹的位置、身份验证凭证、电子邮件，等等。

它的缺点是复制的代码库不包含钩子、引用日志或配置文件，也不包含 Issues、拉取请求或版本等元数据。配置可以在不同的代码托管平台之间更改。最后，要运行它，你需要在机器上安装.Net Core。

这就是要介绍的三种备份 Git 仓库的方法。正如之前提到的，只要在谷歌输入框中输入几个单词，就会出现一连串的选项。但在让开发团队构建自己的解决方案之前，需要注意这件事情。

首先，任何 DIY 解决方案仍然需要大量的手动工作，因为它们只有克隆或备份功能，它们不能用于恢复数据。事实上，不仅内部备份解决方案是这样，大多数 SaaS 工具也是这样。因此，尽管你可能有一些快照或克隆文件，但它们可能需要被重新加载到 SaaS 工具中才能使用。解决这个问题的一种方法是构建一个备份即服务程序，但这可能会需要大量的开发资源。

这就引出了我们需要注意的第二件事，即 API 会不断发生变化。假设你开发了一个内部工具，你需要一个团队不断检查 API 更新，然后对这个工具进行必要的修改，让它始终保持可用。因此，尽管创建一个 DIY 备份脚本是可行的，但你也需要确定你希望开发团队将他们的时间花在哪里。

SaaS 的数据连续性策略

那么这一切将如何向前发展？这里需要思考几件事情。大多数技术运营团队都需要经历这些步骤。首先，弄清楚你是想要自己动手还是将备份需求外包出去。我们已经介绍了内部解决方案和它们的优缺点。因此，如果你决定寻找外部的备份和恢复服务，就要做一些功课。你有很多选择，你可用通过尽职调查、别人的评价、与同行交流、阅读技术文档来判断某公司是否值得信任。毕竟，他们最终有权限访问你的数据。

接下来，审计你所有的第三方应用程序。说实话，这可能需要做很多工作。但还记得“服务条款”吗？你总能从中发现一些惊喜，而且有些可能不是你喜欢看到的。我建议你每年做一次审计，并列出利弊清单。你从应用程序中获得的价值值得你用数据访问权限来交换吗？如果不是，你可能需要寻找其他工具。有趣的是，像 SOC2 这样的合规性标准要求有“供应商评估”，这是有原因的。当发生意外数据丢失时，外部供应商或应用程序是常见的罪魁祸首。

最后，要限制对每个 SaaS 应用程序的访问权限。大多数人承认“最少权限”的好处，但并不总是能付诸实践。因此，要确保正确的人拥有正确的访问权限，确保所有用户都有唯一的登录凭证，并安装 MFA。

我坚信 SaaS 是构建和运营业务的最佳方式。但是，我希望 DevOps、SRE 或 IT 专业人士都清楚地知道，你们需要保护好这些工具可以访问到的数据。在我的职业生涯早期，我学到了一句老话：“这个世界上有两种人——一种是丢失数据的人，另一种是即将丢失数据的人”。

你不会想要成为其中的一种人。当然，如果真的发生了的话，请把他们送到我这儿来。我肯定会一直向他们解释 SaaS 的公共责任模型，直到我的职业生涯结束！

作者简介：

Dave North 是渥太华技术部门的成员，拥有超过 25 年的经验。Dave 目前在 Rewind 工作，领导 3 个团队（DevOps、Trust、IT），担任技术运营总监。在加入 Rewind 之前，Dave 是 Signant 的成员，在该组织中担任许多角色，包括销售工程师、专业服务、技术支持经理、产品负责人和 DevOps 总监。作为一名成熟的领导者和创新者，Dave 拥有 5 项美国专利，并帮助 Signant 转向云 SAAS 商业模式。在加入 Signant 之前，Dave 曾在北电、海湾网络和 ISOTRO 网络管理公司担任多个职位，负责 NetID 产品套件。Dave 对云计算、自动化、小工具和一级方程式赛车非常感兴趣。

原文链接：

SaaS DR/BC: If You Think Cloud Data is Forever, Think Again