数据库自动化：DBA 和 DevOps 的双赢

本文要点：

• 为使数据库与敏捷开发与生产相匹配，DBA 付出了极大的努力，但是该工作需要一种新的方法。新方法实现的关键在于更大程度上的系统化和自动化，确保不间断的一致性贯穿整个 DevOps 工作流，即从任务定义直至应用部署。
• 为使数据库成为整个开发中的单一可信数据源，必须对数据库做自动的、强制的版本控制，以避免破坏开发的不稳定性因素。
• 对于开发人员而言，在编码和集成阶段应避免与数据库有关联的错误，在 SDLC 的早期就应标识出潜在的冲突和非政策性变更，这种方法可以使开发人员的响应更为迅速与高效，同时降低了 DBA 成为开发团队中瓶颈的可能性。
• 对于 DBA 而言，为缓解开发人员需检查代码中所有细微之处的问题，需对影响数据库的存疑编程实践做出自动阻止或是触发告警。该方法中包括识别未做文档的热补丁。在开发中的任何一点上，都可在目标模式中实现热补丁。如果并未对热补丁做文档，那么将会导致配置漂移。该方法可使 DBA 专注于维护、规划部署及提供所需的指导等工作。
• 对于管理而言，这种端对端的、渐进的开发过程，加之开放的交流、直接的汇报以及改进的内部协作，优化了从开发到生产的循环周期，并降低了该周期的代价。

数据库管理员担任开发过程中的“交警”

数据库是软件产品开发中的核心组件，它必须是安全的、稳定的，并实现预期的行为。确保数据库达到此要求、规划数据库并解决开发和故障问题，这是数据库管理员（DBA）的职责所在。DBA 与多个开发团队同时打交道，为数据库开发人员提供帮助和指导。此外，一些 DBA 还必须做代码合并工作，这些代码是由不同的团队提交的，在必要的情况下还可能是由第三方软件提供商给出。监控数据库的活动也是 DBA 的工作。总而言之，DBA 的工作目标在于确保相互关联的团队间不发生重写和冲突。

大多数情况下，DBA 的大量时间与努力都花费在手动检查开发人员编写的代码以及准备部署脚本上。有时 DBA 的工作完全不是做细微的调整，事实上可能会涉及到重写全部的代码段，这可能仅是因为他对数据库有了更好的理解和整体看法。同样，当在开发或生产中出现了与数据库相关的问题时，被召唤到现场的往往是 DBA，而非最初开发系统的人员。为解决问题，DBA 需要对他并不熟悉的代码做变更。

无论存在多少开发团队，以及这些团队间纵横交错的潜在需求，DBA 的任务都是保护数据的完整性和可用性。为了实现幕后的“交管职能”，DBA 必须在各个开发团队的需求与数据库维护的日常工作和管理责任间取得平衡，其中包括为相关的运营团队定义数据库管理和维护的过程。

令人吃惊的是，当前数据库的部署方法依然非常易于出错，这可导致高代价的工作重做、宕机时间甚至是数据丢失，这在一定程度上决定了 DBA 工作的成功与否。导致问题的原因是总所周知的，列举如下：

• 在团队的数量在不断增加时，以及存在第三方的“黑箱”模块时，让数据库去支持多位开发人员是一个挑战。由于存在多名可以变更过程的贡献者，质量变得愈发地不可预测，导致数据库配置漂移成为固定存在的风险。在这样的环境中，审计跟踪通常不足以达成法规遵从。
• 合并开发代码意味着要处理不同团队间的依赖管理，同时要维持一定的灵活性，使得足以对变化的部署计划做出响应。
• 与开发人员和生产人员打交道并不时地充当两者间的仲裁，这十分耗费 DBA 的精力。每种角色都需要不同的心态。
• 考虑到开发和部署中存在不少需人工完成的数据库工作，人为错误是不可避免的。数据库中的错误通常会导致跨应用的错误、意外覆盖或者全系统宕机。

当前对上市时间的要求越来越快，客户满意度也要求达成一致，这种情况下上述挑战变得愈发尖锐。企业出于战略业务上的考虑，时常会需要对多个特性同时开发。多个开发团队会同时变更同一个数据库对象，最终会在部署中存在很多耦合问题。当必须在部署过程中或完成部署后回滚特性时，问题就变得更为尖锐和代价高昂。

此外还应考虑到用户的总是期望宕机会尽量少乃至没有，很明显这对于身处集成和部署最前线的 DBA 压力很大。对于这些 DBA 职责内的事情，问题在于如果他们在这些事情上付出更多的关注，那么做其它工作的时间就会相应地减少，其中包括做适当的维护、研究新的技术、为数据库开发人员提供帮助（尤其是在开发生命周期的前期，那时做数据库改变的代价不大），以及实际去做数据库的管理。

数据库上的新方法是如何使 DevOps 取得成功的（并让 DBA 生活得更轻松）？

我们需要一种使数据库管理可以完全贡献于 DevOps 工作流的新方法，规避易于破坏部署的陷阱。新方法的关键在于迁移到更为系统化和自动化，并为确保无中断的一致性而通过应用部署定义任务。

具体说，版本一致问题是最为令人烦恼的数据稳定性和安全性问题之一，对数据库做全自动的强制版本控制的方法可以解决该问题。该方法类似于在代码部署中所采用的方法，确保了整个开发中事实的单一来源，并建立了一种自动的过程，该过程可防止代码覆盖和冲突、配置漂移，以及其它导致不稳定性的因素，这些不稳定性会对部署产生破坏。

检入 / 检出过程和数据库对象锁是有效的控制机制。它们可防止员工偏离明确定义的修订过程，无论是出于心不在焉或是习以为常。当不再存在可同时被多个用户检出的对象（表、模式等）时，所有的修订就得到了管理，并且是有序的。

使用基线可感知分析可降低配置漂移的风险。基线可感知分析基于对象是维护在源文件控制代码库中的，据此检查发生变更时的对象结构（或内容）。代码库保存了每个对象所定义的基线并与每次的检入保持一致，允许做三路比较（Three-way Comparison）。即当开发人员要提交并部署变更时，版本控制解决方案应自动比较开发人员的拷贝、对象基线（在开发人员检出时的对象）和目标环境（例如集成或是 QA）三者中的最新对象变更。如果检测到基线与最新变更间存在着差异，这意味着对象已被其他的人修改了。修改者可能来自于其他的团队，或是项目工作中的不同开发分支。这时，在没有解决开发人员的本地拷贝与目标环境中的新更新间的差异前，开发人员不可以部署他的变更。

上述安全自动化的实现可借助于对开发人员所生成的代码和变更的自动分析。安全自动化确保了不好的实践和非政策的行为被自动阻止或是发出警告，而不是依赖于DBA 自身的能力或责任去逐字节地走查开发人员提交的代码，对此方法DBA 的确具有兴趣。删除索引、重构索引之类的实践应先于它们直达生产环境前就触发警告。

所有这些自动化技术导致了革命性的数据库发展，确保任何环境中的零宕机、高可用、可扩展性和自动防故障的持续交付。

对开发人员意味着什么？

对于开发人员，一个可靠的、即时响应的数据库在增加生产力和有效性的同时，提供了敏捷和灵活性，并完全消除了与DBA 的冲突。对于运营团队，这样的数据库确保了部署配置中的安全、稳定性、可重复性和正确性。

为使得响应更为快速和有效，开发人员应在编码和集成阶段预防与数据库相关联的错误，并在SDLC 的早期阶段对潜在的冲突和非政策变更做告警。实现更好部署过程的关键在于尽早降低错误和冲突数量，离部署到生产环境越远越好。这样，DBA 将不会成为开发团队的瓶颈，宕机时间也减少了，并且部署也更快，所有这些都会转化为更好的客户体验。

更进一步，许多与数据库相关联的问题可以通过开发团队领导者与DBA 的先期协商得到解决。如果有详细的数据库版本日志，很多情况下领导者甚至也能自行解决这些问题。自动数据库版本管理的结果在于整体改进了开发团队间的自足（self-sufficient），降低了错误数量并增进了团队效率。在为自动数据库版本管理添加安全和控制时，应配置数据库管理解决方案实现精确的人员角色和责任定义。这种职责的有效分割，加之增强的版本控制，是防止未授权的或是意外的版本覆盖的关键所在。

在各个阶段中，有效的监控和版本控制的持续应用并提供解决方案，可以在数据库和对象生命周期的中任何一点上分析数据库版本和对象变更历史。这为法规遵从和关键的质量控制环节提供了必要的审计跟踪。对于监管遵守而言，随着技术进步和消费者保护的相应进展，全面的审计跟踪能力必将愈发重要。

为了确保法规遵从是最为精简、性价比好并且文档齐备的，应将报告机制直接地、自动地连接到数据库监控系统。这使得对开发团队手工文档的需求降至最低，并减少了合规性审计中请求信息答复所需的时间。

在发生紧急情况时，可靠的源代码控制、安全自动化和监控机制为数据库提供了确凿的功能恢复点。

对DBA 意味着什么？

通过扫描代码中的非政策性变更并防止代码覆盖，在数据库中实现安全自动化和强制源控制可降低开发人员插入系统中错误的数量。完整全面的对象变更历史提供了历次的变更信息，其中包括了相对于最初的业务需求做了变更和评论的开发人员。部署脚本的标签和基线为DBA 提供了额外的、有价值的信息，同时即时高亮或阻止了有风险的更新，避免了风险扩散到生产环境中。

该过程还包括识别在其它场合中未做文档的热补丁，即配置漂移问题，它是祸害开发人员和DBA 的问题之一。在开发中的任何一点上，热补丁都可实现在目标模式中。如果每个团队工作于各自的开发环境，只是在QA 阶段才聚在一起，那么目标环境中所做变更的识别还可以防止发生代码覆盖问题。

源代码控制也可识别对数据库做变更的人，对业务需求提供变更之外的更多信息。对于DBA 在部署时解决存在问题的脚本，这些信息是无价之宝。

最小化开发和部署中的错误、提供额外的变更信息并识别潜在有害的信息，可使DBA 工作更加高效。降低“噪声”（以开发人员错误形式出现，必须得到处理）数量可降级DBA 的压力，并使开发团队更为自足（self-sufficient）。DBA 可有更多的时间侧重于优化、维护、规划部署过程等任务，并提供专家指导。

对管理意味着什么？

系统化和自动化的数据库管理方法减少了数据库运行和监控所需的资源，也将给出更为一致的结果。公司可以通过借助自动化降低人为错误的风险，引领员工去获得更大的效率，防止由覆盖所导致的权宜之计和重做，并在有害的更新被执行前就追查到它们。

数据库变更和监控也应是由清晰的业务需求驱动的，例如来自TFS、JIRA 或是类似的工作管理工具的任务。在这种方式下，数据库不仅可保持最新，而且可为达成业务目标发挥作用。

在开发过程中集成安全自动化、完全强制的数据库源控制和变更跟踪，可提供对监管要求的符合，并缓解对更多的第三方应用的需求。

这样的端到端的过程，连同开放的通信和改进的内部协作一起，优化了从开发到生产环境的循环周期，并降低了循环周期的代价。由于最终的产品变得更加地稳定、具有更好的整体质量并且通常更快地反映了前期版本中的用户反馈，该过程可加速上市时间，并导致更高的客户满意度。

引领公司前进

有效的数据库管理影响了DevOps 举措的成功，反过来会促进业务取得成功。有效管理的关键在于实现数据库的安全自动化和强制源代码控制，这可以避免很多错误延伸到部署阶段。

这样做的结果是产生了更多的独立开发团队、更快及更早的纠正措施，以及更为稳定的部署配置。DBA 可以从频繁处理和合并不同团队对数据库变更的压力中解脱出来。自动化解放了他们的时间，有助于企业在革新过程中大步前进。

关于作者

** Yaniv Yehuda ** 是 DBmaestro 的共同创始人和 CTO。DBmaestro 是一家企业软件开发公司，侧重于数据库的开发和部署技术。Yaniv 是 DevOps 专家，近两三年中致力于提高人们对数据库开发和部署的相关挑战、如何支持数据库的持续发布等问题的意识。

查看英文原文： Automating the Database: A Win-Win for DBAs and DevOps

感谢刘志勇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。