根据2018年Gartner关于SaaS迁移的调查，97%的受访者表示他们的组织已经部署了至少一个SaaS应用程序，这可能并不奇怪。如今，几乎每个企业都有相当数量的云应用被提升到关键业务系统的地位。没有这些系统，企业就无法有效运作。用来通知或直接采取重要行动的系统。
难怪CRM、支持、ERP或电子商务工具等云应用程序已经成为DataOps团队寻找某些事情发生的原因和原因的主要目标。毕竟，想想有多少业务数据在一个CRM系统中聚合—特别是当它与其他业务系统集成时。这是一个掌握数据的金矿！
DataOps团队通常会识别一个高价值的目标应用程序，比如CRM系统，然后探索通过系统API从应用程序捕获和摄取数据的方法。在salesforce的例子中，他们可能会探索变更数据捕获和批量API。具有不同数据消费需求的不同团队可能会使用这些API来捕获特定用例的数据，这不可避免地导致数据拷贝和法规遵从性风险呈指数级增长。
当他们遇到API限制甚至应用程序性能问题时，DataOps团队就会开始将数据复制到附近的数据湖中。这使他们能够为应用程序外部的SaaS数据创建集中的消费点。在这里，存储成本更优惠，访问无处不在。在这里，团队通常会深呼吸，开始一个更有组织的需求收集过程，首先是“谁需要什么数据，为什么？”
同时，在一个平行的世界里，IT团队为那些相同的云应用程序实施数据备份策略。如果发生了不好的事情（比如，数据损坏），这些关键的业务系统需要快速恢复并恢复到在线状态，以保持业务的正常运行。在这里，标准的做法是通过DIY脚本或SaaS备份工具以常规增量拍摄数据快照。在大多数情况下，备份数据都放在冷库中，因为好吧，这就是您对数据副本所做的，它的唯一目的是在出现问题时充当“保险单”。
由于所有这些团队都试图在同一个组织中使用相同的数据，因此成本和维护周期很快就会失控。对于每TB的生产数据，ESG发现通常会生成另外9TB的辅助数据，这很快抵消了由于公共云上存储成本不断降低而带来的任何成本节约。
那么，我们为什么要把这个9X+的数据乘数强加给自己呢？
一个原因是方便。走上去，拿着我们需要的东西，然后走开会更容易。但方便往往以质量、安全性和风险为代价：您是如何做到的？您所获取的数据是组织在特定实体上可能拥有的最佳数据集？这个问题在拥有强大的数据控制计划的组织中尤其重要。如果您的副本包含敏感数据，而您正将这些数据藏在一些通常未知的地方，那么您是否正在扩展组织的攻击面？您的数据是否有治理或法规遵从性规定？
另一个原因是因为“我们一直都是这样做的。”将备份数据视为一种保险政策的现状，这种保险政策与其他场景的SaaS数据接收无关，回溯到SaaS应用程序本身出现之前的时代—当时数据备份和摄取是在数据库级别完成的两个独立动作。
我们如何做事和一开始就做同样重要。改变我们做事的方式很难。它始于认识到现状不再适用。在这种情况下，我们认识到云应用程序允许完全不同的数据消费模式，备份工具是收回云应用程序数据的所有权和控制权，并将备份数据重新用于我们公司的所有其他数据消费需求的完美帽子戏法。