你的数据库危机四伏

我们已经给予了数据库充分的关注，因此它们不应成为 IT 风险因素。但即便为 DRP（灾难恢复计划）准备预算、备份机制并且拥有一流的 DBA，数据库仍然造成了重大威胁。这是为什么呢？

变得敏捷

在快速发展、充满竞争的市场中，如果你的竞争对手能够更快更好地发布相关产品，那就意味着你终将失去市场份额。这也就是为什么公司需要变得敏捷。公司需要更好地掌控信息、更快地制定决策、加快软件交付以及优化质量控制。敏捷生来就是处理这些挑战的。它一方面使组织能够更快地发展，并处理不断变化的需求，另一方面又能确保最佳质量。把敏捷概念带入产品（产品环境、客户站点等）当中，并使得开发和运营紧密相连，这样的需求导致了 DevOps 的诞生。

敏捷和 DevOps 的出现并未使软件开发生命周期（SDLC）的最佳实践发生彻底的改变。因为它们是软件开发演进的步骤，而不是一次彻头彻尾的变革。然而，如果你正行驶在敏捷世界的快车道上的话，如何贯彻执行这些最佳实践将显得更为重要。此外，自动化是极其重要的，它既提升了总体效率，又减少了频繁变更和发布的固有风险。

流程的自动化、持续集成、持续交付以及持续部署的实现，这些实践已经被反复证明过了。它们确保了总体流程的高效和可靠性。

对数据库需要特别关注

基于自动化的可重复性和可持续性流程共同驱动着更安全和更少出错的部署工作。要想在频繁变更中立于不败之地，那就不能依赖于个人能力去记住所有已完成的步骤，也不能依赖于群体能力去识别出可能受到当前变更影响的所有范围。关键在于要尽可能减少人工操作。

但不同于其他软件组件和代码（或者是编译过的代码），数据库可不只是一堆文件。数据库是你最有价值的资产，它包含了需要妥善保管的业务数据。因此我们不能将它从开发环境拷贝粘贴到测试环境再到产品环境。大多数情况下，数据库的开发与应用代码（.Net 或者 Java 开发）显得截然不同：开发人员和 DBA 访问并更改共享资源，即一个中央数据库，而不是工作站上的一个本地拷贝。

数据库开发和普通应用代码开发是如此不同，最终导致了孤岛的产生。

应用开发人员正勇往直前，他们采用优秀的新开发工具、实践敏捷方法、自动化以及持续交付。相比之下，数据库开发采用的却是一个相对不受控制的流程。数据库开发与其说是工程实践，倒更像是一门与整个 SDLC 流程相隔绝的艺术。在这里，人们从未共享过开发工具、流程和最佳实践。

数据库作为有价值的资产，极易成为摇晃的车轮从而破坏了整车的平衡（即成为短板）。

数据库变更应如何进行处理？

我们不应该仅仅因为数据库构造的不同而视它为特别的事物。我们应该确保所有团队、代码开发人员、DBA 和数据库开发人员都采用相同的流程。如同在代码开发中做的那样，我们应当遵循这些已得到证明的软件开发最佳实践，并将其应用到数据库开发当中去。

在整个开发周期中，为了将数据库造成的风险最小化，我们需要按照以下方式解决问题：

• 敏捷开发——实行短小的开发周期，同时将数据库变更作为基于任务的开发工作的一部分进行管理。这样做能够确保代码变更和数据库变更同时完成，并在之后能够基于变更请求一同部署。
  ——像 Jira 这样的任务管理解决方案能够将任务（task）、问题（issue）、变更需求（change requirements）或者问题记录（trouble ticket）与实际需要完成的工作对应起来。它能帮助并引导你朝着明确定义的可交付成果方向进行努力，并在之后采用以任务为中心的视角来部署这些变更。
• 像 Chef、Puppet 和 Jenkins 这样的工具使得软件开发环境的配置变得更加高效。但是数据库方面又是如何呢？你如何配置大型数据库环境？即便是配置小型数据库环境？数据库仍然是敏捷跨不过去的槛。
  ——使用 Delphix 可以方便地创建虚拟数据库分支。创建开发环境将变得轻而易举，并行开发也变得触手可及。生产环境的虚拟拷贝允许你使用最新产品环境的真实数据来测试产品部署，而无需处理存储问题或是真实的产品风险。
• 假如你尝试去构造一个良好的开发、测试、UAT（用户接受性测试）或是产品预发布环境，那么内容屏蔽确确实实是一个挑战。测试数据越真实，你对质量保障也就越充满自信。但是如果开发人员可以不加约束的访问产品拷贝，那会怎样呢？你的信用卡号码是否有可能正好留在其中一台笔记本上？它会泄露出去吗？另一方面，如果采用模拟数据或是根本不用任何数据，那将无法营造一个良好的测试环境，同时性能测试也会不准确。
  ——像 DMsuite 这样的解决方案能够用逼真、但也是虚构的数据来替换机密数据，而不需要任何编码。如果为了达到某种目的（健康保健亦或是财务方面的内容）或者正好存在一些敏感信息而使得你需要这样做的时候，它会通过在非产品环境中替换机密数据的方式从而减少你的“可侵入的足迹”。
• 数据库变更管理——运用数据库工具以确保数据库变更能够作为 SDLC 的一部分妥善管理，而不是隔绝在主要开发流程之外。另外，确保每一次变更都和一个变更请求关联起来。这有助于将数据库管理工作作为通用开发或变更工作的一部分。 <

  • 通过使用 DBmaestro 可以加强版本控制并同时追踪所有变更。一切尽在你掌控之中：谁在做什么事，在哪里，为什么这样做。它将消除流程外的变更。一旦开发周期结束， DBmaestro 会将相关的变更自动部署到集成环境中去，识别出变更冲突并且合并它们，如果没有冲突则直接推送到产品环境中去。

• 测试自动化——建立合适的自动化测试需要巨大的投资。你需要将之视为长远目标，而非一次性项目，并开始为每次新的开发活动或是主要变更创建并积累自动化测试。
  单元测试：建立坚固的安全网络需要采用以变更为重点的测试方法，同时确保那些变更没有造成破坏。
  ——通过采用 Oracle SQL Developer 或者 Microsoft 平台的 tSQLt 这样的单元测试工具就可以引进数据库单元测试，而无须任何花费。
  回归测试：另一种测试方法，它将数据库和应用代码作为一个整体来进行测试。
  ——使用 TestComplete 验证那些常见的场景，之后也可以加入对不太常见的场景的验证，这将使你自信满满地交付发布。
• 发布自动化——缓解风险的关键角色。自动化的部分越多，你就越能做到精确掌控：重现开发中引入的变更，并在测试环境中测试，最终安全地应用到产品环境中去。一旦你自动化了 SDLC 的流程并且成功解决日常工作中的挑战，那么一个健康的 SDLC 就水到渠成了，它能同时兼顾最小风险和最高效率。
  ——使用 IBM Urbancode 部署工具能够帮助你管理发布活动和配置，并精心策划总体流程。

最好的消息是，这些不同类型的解决方案完全可以合作无间。因而可以使用 Delphix 创建虚拟开发分支，使用 DMsuite 屏蔽机密内容，使用 Jira 管理开发任务，使用 DBmaestro 对变更和发布进行版本控制，使用 tSQLt 或者 SQL Developer 进行自动化测试发布，以及使用 uDeploy 来策划发布流程，以上所有都能汇总成一个精巧的、自动化的并且安全的流程。

总结

当着手采用最佳实践的时候，数据库才展现出真正的挑战。这也正说明了孤岛是如何产生的。开发部门或许会采用不同的流程来分别对待代码开发和数据库开发，或仅在部分变更工作中采用最佳实践。

消除主要风险的最佳方法是，不要以技术眼光去看待这些差异，同时找到解决方法——流程或者工具——去采用并实施最佳实践和自动化。

作为一份具有如此高价值的资产，数据库不应成为你的业务的短板。

关于作者

Yaniv Yehuda是 DBmaestro 公司的联合创始人兼 CTO。DBmaestro 是一家以数据库开发和部署技术为重点的企业级软件开发公司。Yaniv 同时也是 Extreme Technology 公司的联合创始人兼开发部主管。Extreme Technology 是一家面向以色列市场的 IT 服务供应商。Yaniv 曾是以色列国防军队计算机中心的上尉。他在那里担任软件工程经理。

查看英文原文： Your Database: The Threat That Lies Within