根据2018年Gartner对SaaS迁移的调查显示，97%的参与者表示他们的组织已经应用了至少一款SaaS应用程序。这并不意外，现今几乎每个企业都有不少关键业务系统依赖于云应用的支持，缺少这些系统，企业的正常运作将受到严重影响。
因此，像CRM、支持、ERP以及电子商务工具等云应用已经成为DataOps团队追踪数据变化的重要目标。想象一下，一款CRM系统中聚集了多少业务数据，尤其是当它与其他系统集成时，这简直是数据的宝库。
DataOps团队通常会识别到某个高价值的目标应用，如CRM系统，然后寻找通过系统API捕获和提取数据的方式。以Salesforce为例，他们可能会考虑变更数据捕获和批量API。不同团队因数据消费需求各异，可能会各自使用这些API提取特定用例的数据，这无疑会导致数据冗余和合规风险的显著增加。
当API限制或应用程序性能问题出现时，DataOps团队便会开始将数据复制到近处的数据湖。这使得他们能够为SaaS数据创建一个集中消费点，存储成本更低且访问更为便利。在这一阶段，团队通常会重新审视需求，首先考虑“谁需要什么数据，以及原因何在？”
与此同时，IT团队也在为相同的云应用实施数据备份策略，以确保在数据损坏等不良事件发生时，关键业务系统能够迅速恢复并保持正常运转。通常，备份过程是通过DIY脚本或SaaS备份工具进行定期增量数据快照。在大多数情况下，备份数据会被储存在冷库中，因为它的主要目的是在出现问题时充当“保险单”。
由于各个团队都在同一个组织内使用相同的数据，成本和维护周期迅速失控。根据ESG的研究，通常每TB的生产数据会产生额外的9TB辅助数据，这使得公共云存储成本节约的好处大打折扣。
那么，我们为何要自我施加如此巨大的9倍数据冗余呢？
一个原因是为了便利。直接获取所需数据的方式显得更加简便，但这种便利往往以数据质量、安全性和风险为代价。您获取的数据是否是组织在特定实体上所能拥有的最佳数据集？这一问题在拥有严谨数据控制计划的组织中显得尤为重要。如果您的数据副本包含敏感信息，而这些信息被存放在一些不被知晓的地方，是否会扩大组织的攻击面？您的数据是否遵循治理或合规规定？
另一个原因是“我们一直这样做”。将备份数据视作保险政策的传统观念与其他场景的SaaS数据提取无关，这可以追溯到SaaS应用程序出现之前的时代，当时数据备份和提取是在数据库级别完成的两个独立过程。
我们如何实施操作以及最初的做法同等重要。变革现有的操作模式并不容易，首先需要意识到现行做法已不再适用。在这种情况下，我们认识到云应用程序允许完全不同的数据消费模式，备份工具能够帮助我们重新获得云应用数据的所有权和控制权，同时将备份数据重新用于公司其他数据消费需求。
