转载

数据库自动化：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可有更多的时间侧重于优化、维护、规划部署过程等任务，并提供专家指导。