我很幸运，今年再次来到英国伦敦。如果你曾到过伦敦，乘坐过"地铁"，那么你就熟悉"请小心空隙"这句话。对于那些可能不熟悉这句话的人来说，在火车/地铁的每一站都会重复这句话，以提醒出发的乘客不要踩到火车和人行道之间的空间。而且，就像大多数不断重复的好建议一样，我们倾向于第一次听到，然后就把它淹没了。而且，不折不扣地说，忽视这些建议最终往往会反咬我们。这就是今天我几乎发生的事情，因为"差距"是平时的两倍。我从来没有这么感激有这么大的脚。在我返回酒店的剩余旅程中，这些事件在我脑海中反复出现。然后我突然想到：这正是在我们的SDLC中发生的事情（尽管通常会有更不幸的结果）。我们已经学会了在日常生活中忍受旧的、过时的、细分的或纯合成的数据（数据差距）的危险，完全忘记它的存在……直到它比我们想象的大得多，几乎要杀死我们（或者至少给我们带来一些尴尬和挫伤）。我们已经认识到我们的SDLC中的数据差距，并设法解决它。。。也就是说，直到我们没有这样做。我们所有人都经历过项目数据差距造成的伤害。以下是一些典型的伤害：我们计划两周的数据库提供时间，但之后需要4周。项目延误和成本超支。我们计划三天刷新一次数据库，但需要5天。团队等待，功能下降。测试周期减少。我们不计划刷新，所以我们的项目不会出现宕机；但是6周/月前的数据导致我们错过了P1缺陷的检测。我们编写了回退脚本/步骤来重置我们的开发/测试环境，以避免5天的刷新；但是它们在不知不觉中失败了，引入了错误和生产力损失。我们不屏蔽非生产拷贝，因为掩蔽是困难的，而且耗时太长。德夫受到威胁。我们只是在非prod中运行纯合成数据，但是我们忽略了一些角落的情况；将bug引入到后期开发或prod中。在细分和中断修复活动等过程中，我们都面临着更多的数据缺口问题。就像我在地铁上的经历一样，我们知道有空隙。事实上，我们指望差距会存在，但在那些时候，差距远远大于我们的计划。我们原计划在数据到位的情况下继续前进，但结果却陷入了深渊。虽然Delphix无法治愈SDLC中的所有风险，但让我们来看看Delphix可以补救的几个地方：调配新数据今天，如果您像大多数传统商店一样，您需要等待几天或几周才能获得新的环境，而需要额外的几天/几周才能为这些新环境配置数据。如果您是一家更现代化的DevOps/自动化商店，您可以在几分钟内获得环境，但您仍然需要等待数小时或数天的数据。毕竟，即使您将请求自动化，复制/传输60TB的数据也只会这么快（谢谢，物理）。使用Delphix，您可以消除"天"、"周"和"小时"作为等待数据的描述符。是的，对于60TB的数据库也是如此。这可以由开发人员/测试人员/DBA通过Delphix自助服务工具即席完成，也可以直接集成到您的自动化/DevOps过程中，而不需要太多的努力。在下面的图中，我描述了一种情况，您已经在使用配置自动化，例如Ansible、Puppet、Chef或Salt Stack来构建基础设施和支持应用程序。在这种情况下，您可以很容易地告诉这些工具在基础设施处于就绪状态后自动调用Delphix来提供数据。使用和不使用Delphix提供数据的流程图此处显示全屏图像刷新数据在您的环境中影响数据供应的约束可能会影响环境中的数据刷新，不过在某些情况下，这些约束可能会有所减轻（几天，而不是几周）。Delphix用于调配环境的相同技术也可以应用于刷新。这意味着刷新所需的秒/分钟与设置第一个副本所需的时间相同。提供的自助服务和自动化功能也可以刷新。此外，Delphix与生产保持近乎实时的同步。这意味着您可以在几分钟内随意刷新3秒前生产的非生产拷贝。在通常情况下，您需要向友好的DBA发送电子邮件请求刷新，但您可能已经拥有了数据。这对你的项目时间表有什么影响？如果每次从git中执行一次pull，或者在TFS上触发一个commit gate，等等，它会自动刷新数据库（包括应用需要发生的任何DDL/DML），那么这对您的质量有何影响？下图描述了一个华尔街金融客户的真实账户。因为将生产数据交付给非prod是很麻烦的，所以开发将在几个月前的环境中进行。由于热修复程序等原因，生产变更发生在开发之外。随着时间的推移，这将增加生产和开发数据之间越来越多的不一致性，从而导致越来越多的bug进入生产。在开发过程中定期刷新数据会导致在SDLC中尽早修复更多的缺陷，而这些缺陷更容易修复。在这里，我展示了在每周计划中进行的刷新，但是它们可以设置为任意间隔，或者由其他工具（比如git钩子）触发。使用和不使用Delphix提供数据的流程图此处显示全屏图像重置数据有些测试是故意破坏性的，有些测试是无意破坏性的。无论哪种情况，都需要一种方法来达到"测试就绪"状态。这实际上只剩下几个选择：要么刷新数据，要么退出更改。但是，退出这些变化意味着有几个非常重要的常量。首先，你必须意识到你的数据发生了变化。如果您的开发或测试不是设计成破坏性的，那么您是否仔细检查表234中的A2354字段现在指向表XYZ中的另一列？你根本不知道你不知道什么。但是，如果您有意运行破坏性测试，您确定您正在退出所有更改吗？您在退出/重置程序上花费了多少时间和精力？您是否将这些脚本/过程置于与您正在开发的应用程序相同的QA级别上？如果你是，我推荐你。但是，还有更好的方法。在你的Kindle环境中，你的应用程序可以像在Netflix上一样轻松地翻阅你的应用程序。您已经在几分钟内为Delphix提供了数据。你做了一些没有产生你想要的结果的开发。只需点击"倒带"就可以回到你想要的时间点。这可以是一个文字时间戳，也可以是更规范的东西，比如一个名为"Step5 complete"的书签。这个过程所需的时间与重启应用程序/数据库所需的时间差不多。如果您不再需要开发、测试和维护重置脚本，并且重置在几分钟内完成，那么您的项目将获得什么样的生产率和质量收益？在下面的图表中，我描述了一个典型的过程，在这个过程中，您将测试包更新到具有多个数据源的复合应用程序或ERP系统（如SAP）的应用程序。在传统的测试中，如果您正在应用一系列SAP包，而其中一个包发生了灾难性的失败，那么您可能必须从零开始擦除并从头开始。这个过程需要数周时间。使用Delphix for SAP的客户可以在几分钟内恢复上一个成功步骤，并准备好通过单击按钮继续进行测试。使用和不使用Delphix重置测试环境的流程图此处显示全屏图像数据屏蔽和匿名化安全对于保护我们的业务、任务、患者和消费者至关重要。除少数例外，非生产拷贝不应包含敏感数据。我知道我们都知道这一点；但我们都曾（或正在）工作过，在那里银行/病人/客户信息散落在许多地方。如果掩蔽很容易的话，每个人都会这样做，在任何地方，任何时候。使用Delphix，掩蔽很容易。此外，使用Delphix，非产品拷贝的敏捷屏蔽可以自动化，从而消除了过程崩溃的可能性，从而开发人员可以获得无掩码的产品拷贝。利用基于角色的访问控制，每当开发人员单击"供应"、"刷新"或"回放"时，他的请求都会从预先屏蔽的产品副本中提供。是的，预先蒙面。所以，当你的开发人员早上8点进入办公室时，已经为8小时的屏蔽工作支付了税款，他们有了前一天收盘时的新的屏蔽数据。DelphixAgileMasking易于设置和使用，不需要编程专业知识，甚至可以分析数据中可能存在的敏感信息。你又怎么能从复杂的面具中解脱出来呢？在下面的图表中，我展示了一个典型的过程，在这个过程中请求一个新的屏蔽数据副本，以及在数据交付之前所需的时间和手动接触点。在Delphix场景中，安全性可以建立并检查由Delphix自动应用的屏蔽策略。Delphix会在指定的时间间隔自动更新产品的屏蔽副本。在任何时候，在不影响数据交付链的情况下，安全性可以审查任何自动屏蔽的副本，以确保法规遵从性并满足审核要求。请求者只能访问经过认证的屏蔽副本中的请求数据，并且可以通过自助服务在几分钟内将其交付。这个蒙版数据传递的应用程序也可以应用于上面我描述的任何场景。流量d