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

1、数据库管理员担任开发过程中的“交警”数据库是软件产品开发中的核心组件， 需要的是安全、稳定、并实现预期的 行为。确保数据库达到此要求、规划数据库并解决开发和故障问题，这是数据库 管理员（DBA）的职责所在。DBA同时与多个开发团队同时打交道，为数据库 开发人员提供帮助和指导。然后，许多 DBA还必须做代码合并工作，这些代码 是由不同的团队提交的，在必要的情况下还可能是由第三方软件提供商给出。监控数据库的活动也是DBA的工作。总而言之，DBA的工作目标在于确保相互关 联的团队间不发生重写和冲突。大多数情况下，DBA投入大量的时间与努力在手动检查开发人员编写的代 码以及准备部署脚本上。有时 DBA

2、的工作完全不是做细微的调整，事实上可能 会涉及到重写全部的代码段，这可能仅是因为他对数据库有了更好的理解和整体 看法。同样，当在开发或生产中出现了与数据库相关的问题时，通常是调用DBA来解决，而非最初开发系统的人员。为解决问题，DBA可能被要求在没有获得原开发商固定不熟悉的代码解决。无论开发团队的数量及其团队间纵横交错的潜在的重叠需求， DBA的任务 都是保护数据的完整性和可用性。为了实现幕后的“交管职能”， DBA必须在 各个开发团队的需求与数据库维护的日常工作和管理责任间取得平衡， 其中包括 定义相关运营团队的数据库管理和维护的过程。考虑到数据库管理员成功的有多少，令人吃惊的是，当前数据库

3、的部署方法 依然非常易于出错，这可导致高代价的工作重做、停机时间甚至是数据丢失，这 在一定程度上决定了 DBA工作的成功与否。导致问题的原因是总所周知的，列 举如下：支持多个开发人员，在团队的数量在不断增加时，以及存在第三方的“黑 箱”模块时，让数据库去支持多位开发人员是一个挑战。 数据库配置漂移是一个 固定存在的风险，由于存在多名可以变更过程的贡献者，质量变得愈发地不可预 测。在这样的环境中，审计跟踪通常不足以达成法规要求。合并开发代码用于部署意味着要处理不同团队间的依赖关系，同时要维持 一定的灵活性，使得足以对变化的部署计划做出响应。与开发人员和生产人员打交道并不时地充当两者间的仲裁，这十

4、分耗费精力。每种角色都需要不同的心态。由于开发和部署中存在不少需手动完成的数据库工作，人为错误是不可避 免的。数据库中的错误通常会导致跨应用程序的错误、意外覆盖或者整个系统停 机。当前对上市时间的要求越来越快，客户满意度也要求达成一致，这种情况下 上述挑战变得愈发尖锐。企业出于战略业务原因，时常会需要对多个特性同时开 发。由于所有开发团队都对同一个数据库对象进行更改， 最终会在部署中存在很 多耦合问题。当必须在部署过程中或完成部署后回滚特性时， 问题就变得更为尖 锐和代价高昂。此外还应考虑到一般客户期望的最小到零停机时间，明显这对于身处集成和部署最前线的DBA压力很大。问题在于如果他们在这些事

5、情上付出更多的关注， 那么做其它工作的时间就会相应地减少，其中包括做适当的维护、研究新的技术、 为数据库开发人员提供帮助（尤其是在开发生命周期的早期，当数据库修改成本 更低），以及实际去做数据库的管理。如何使用数据库上的新方法让 DevOps取得成功的（并让DBA生活得更轻松）？我们需要一种使数据库管理完全贡献于 DevOps工作流的新方法，规避易 于破坏部署的陷阱。新方法的关键是移动到更大的系统化和自动化， 并确保无中 断的一致性而通过应用部署定义任务。具体的说，一个对完全自动化的执行版本控制的数据库可以解决最为令人烦 恼的数据库的稳定性和安全性的问题： 版本一致。该方法类似于在代码部署中所

6、 采用的方法，这确保了整个开发中真实的单一来源，并建立了一种自动的过程， 该过程可防止代码覆盖和冲突、 配置漂移，以及其它导致不稳定性的因素， 这些 不稳定性会对部署产生破坏。一个有效的控制机制包括检入/检出过程和数据库对象锁定。它们可防止员 工偏离明确定义的修订过程，无论是出于心不在焉或是习以为常。 当不再存在可 同时被多个用户检出的对象（表、模式等）时，所有的修订就得到了管理，并且 是有序的。为了降低配置漂移的风险。基线感知分析是用于针对对象是维护在源文件控 制代码库中的，据此检查发生变更时的对象结构（或内容）。代码库保存了每个 对象所定义的基线并与每次的检入保持一致， 允许做三方比较。即

7、当开发人员要 提交和部署他的变更时，版本控制解决方案应自动比较开发人员的拷贝、 对象基 线（在开发人员检出时的对象）和目标环境三者中的最新对象变更 （例如集成或 是QA ）。如果检测到基线与最新变更间存在着差异，这意味着对象已被其他的 人修改了。修改者可能来自于其他的团队，或是项目工作中的不同开发分支。 这 时，开发人员将无法部署其更改，直到其本地副本和更新的更新到目标环境之间 的冲突得到解决。通过自动分析开发人员生成的代码和更改的自动分析。 这样的安全自动化可 以实现，DBA具有一个明显的兴趣是确保不良实践或非策略动作被自动阻止或 触发警告，而不是依赖于他的能力或责任审查开发人员提交的每一个

8、代码被开发 商推。例如像删除索引，重建索引之类的实践应先于它们直达生产环境前就触发警口。所有这些自动化的结果导致了革命性的数据库发展，确保任何环境中的零停机时间、高可用性、可扩展性和自动防故障装置在任何环境中的持续交付。对开发人员来说意味着什么？对于开发人员，一个可靠的、即时响应的数据库提供了敏捷和灵活性， 在增 加生产力和有效性的同时，消除了与 DBA的冲突。对于运营团队，这样的数据 库是一个确保了部署配置中的安全性、稳定性、可重复性和有效性的承诺。开发人员在编码或集成阶段与数据库相关联的错误，并在软件开发生命周期 的早期阶段对潜在的冲突和非政策变更做告警。实现更好部署过程的关键在于尽 早降

9、低错误和冲突数量，这对于更好的部署过程是至关重要的。这样，DBA将不会成为开发团队的瓶颈，更少的停机时间和更快的部署，这将转化为更好的客 户体验。此外，许多与数据库相关联的问题可以通过开发团队领导者与DBA的早期协商中得到解决。甚至自己在许多情况下，如果有详细的数据库版本日志，很多 情况下领导者甚至也能自行解决这些问题。 由于自动化数据库版本化，开发团队 之间的整体改进自给自足，减少了错误的数量，提高了团队效率。为了在这种情 况下增加安全性和控制，应将数据库管理解决方案配置为细化人员角色和职责。 这种职责的有效分割，加之增强的版本控制，对于防止未经授权或意外的版本覆 盖至关重要。有效的监控和版

10、本应该被应用在所有阶段的解决方案，它可以分析数据库版 本和对象在其生命周期中的任何一点上的变化历史。 这将提供所需的审计跟踪法 规遵从性和关键的质量控制的关键方面。对于监管遵守而言，随着技术进步和消 费者保护的相应进展，全面的审计跟踪能力将对监管遵从变得越来越重要。为了确保法规遵从是最为精简、符合成本效益并且文档齐备的，应将报告机 制直接地、自动地连接到数据库监控系统。这使得最大限度地减少了开发团队的 手工文档要求，并减少了合规性审计中请求信息答复所需的时间。在发生紧急情况时，可靠的源代码控制、安全自动化和监控机制提供了一个 清晰的、功能恢复点的数据库。DBA意味着什么？数据库中实现安全自动化

11、和源代码管理强制可降低开发人员插入系统中错 误的数量，通过扫描代码中的非政策性变更并防止代码覆盖。 一个完整全面的对 象变更历史提供了历次的变更信息，每一个变化，包括开发商作出的变化和意见， 对原有的业务需求。部署脚本的标签和基线为 DBA提供了额外的、有价值的信 息，而风险立即更新强调或阻塞所以不能渗透到生产。该过程还包括识别在其它场合中未做文档的热补丁，即在开发过程中的任何时候，在目标模式中实现的配置漂移问题是开发人员和数据库管理员的一大难 题。在开发中的任何一点上，热补丁都可实现在目标模式中。如果每个团队工作 于各自的开发环境，只是在QA阶段才聚在一起，那么目标环境中所做变更的识 别还可

12、以防止发生代码覆盖问题。源代码控制也可识别对数据库做变更的人，对业务需求提供变更之外的更多信息。这是在部署期间处理有问题的脚本的 DBA的宝贵信息。最小化开发和部署中的错误、提供额外的变更信息并识别潜在有害的信息， 可使DBA工作更加高效。降低“噪声”的数量（以开发人员错误的形式处理） 可降级DBA的压力，并使开发团队更加自给自足。这样就可以让DBA有更多的时间集中在优化、维护、规划部署过程等任务，并提供专家指导。对管理的意义是什么？一个系统化和自动化的数据库管理方法减少了数据库运行和监控所需的资 源，也将给出更为一致的结果。公司可以通过借助自动化降低人为错误的风险， 公司可以引导员工提高效率

13、，防止由于覆盖而导致的变通和重做， 并在执行前就 追查有害的更新。数据库变更和监控也应是由明确的业务需求驱动的，例如来自TFS、JIRA或是类似的工作管理工具的任务。 在这种方式下，数据库不仅可保持最新，并在 履行业务目标方面发挥作用。在开发过程中集成安全自动化、全面实施的数据库源控制和变更跟踪， 集成 到开发过程中，提供了符合法规的要求，并减轻了需要额外的第三方应用程序。这样的端到端的过程，随着开放的沟通和加强内部合作，优化了从开发到生 产环境的生产周期，并降低了成本。由于最终的产品变得更加地稳定、 具有更好 的整体质量并且通常更快地反映了前期版本中的用户反馈，该过程可加速上市时 间，并导致更高