数据库管理工作如何适应DevOps实践

North：DBA这一角色通常会接触多种产品环境、开发团队、技术以及业务干系人。也许他们在上一分钟还在进行数据库调优，下一分钟就要安装某个安全补丁，以及对于生产环境中遇到的问题进行响应，或是回答开发者们的问题。他们需要确保备份与分发的正确配置，系统与用户对于相应的数据库（并且仅限于这些数据库！）有着适当的访问权限，并且还要实际参与异常的系统行为的诊断工作。

DBA的实际价值体现在对于数据库本身、运行时特性与配置等机制和细节的理解上，并在编写查询功能的开发者与负责各种作业的运行的运维人员之间起到桥梁的作用。熟练的DBA能够指出如何加快运行较慢的查询的方法，包括改变查询逻辑、调整数据库schema、或是更改数据库运行时的参数。例如改变连接的次序、引入索引（有些情况下还需要删除某个索引！）、对数据库的查询执行计划器给出提示、或是更新数据库的启发式特性，这些工作对于性能可能会带来极大的影响。

North：这方面有一个不幸的事实，只有极少数的开发者能够真正了解关系型数据库背后的运行机制。Hibernate或微软的Entity Framework这样的框架提供了一种映射层，它向普通的企业开发者掩盖了内部的运行机制，因为对于这些开发者来说最重要的技能在于C#或Java的编程，这种做法显然是一把双刃剑。一方面，这种映射层能够在数据库schema与对应的面向对象数据结构之间生成映射关系，从而简化开发普通应用程序的过程。但如果你所期望的领域模型与数据库schema之间产生了较大的分歧，或者是对于性能、可用性与可伸缩性有较高需求的情况下，这种方式很快就会让应用变得复杂起来。在这种情况下，如果在开发团队中能够加入一位DBA以提供帮助，这种做法的价值是无可估量的。

从运维的角度来说，DBA通常需要负责实现业务上的分发或可用性的策略。监控系统、诊断问题及“保持系统始终正常运转”等工作属于运维人员的职责，但DBA也需要深入参与与数据库相关的监控工作与问题诊断。他们还需要为运维团队定义数据库管理与维护的流程。

North：通常来说，DBA这一角色的工作主要来自于请求或工单系统，这形成了另一种技术壁垒。这种方式意味着DBA往往接触不到宏观的业务或技术方面的需求与限制的上下文，他们往往只能在信息的真空中尽力把工作做好。从我的经验来来看，DBA经常会扮演一种随时提供支持服务的角色，因此如果某个开发者的查询超过了阀值，那么DBA很可能在半夜里被电话吵醒。也正因如此，DBA对于来自开发者的数据库变更往往选择谨慎的、甚至是非常质疑的态度。

有时候，DBA可能会分为“生产环境DBA”与“开发DBA”这两种不同的角色。前者通常都坐在一起，进行我之前所描述的各种生产环境的维护工作。而后者将帮助开发团队进行schema的设计与查询，让他们能够以正确的方式与数据库进行交互。这种方式可以带来很好的效果，尤其是生产环境DBA与开发DBA之间已经建立了一种信任关系的前提下。生产环境DBA知道开发DBA会确保schema的设计与数据库的查询具有一定程度的质量与合理性，而开发DBA也相信生产环境DBA会以正确的方式对各种数据库实例进行配置与维护。

North：在许多组织中，他们之间确实是无法适应的。无论是将数据库变更通过一个独立于应用代码变更的额外流程进行发布，还是将数据库与应用的变更统一发布至生产环境中，两者都面临着很多困难。

某些组织会采取“数据库即代码”的策略，通过某些自动化流程，利用变更脚本将变更部署至数据库中。这些脚本与应用代码一起在源代码控制系统中进行管理，这可以简化变更的追踪与分析工作。这些变更脚本通常叫做迁移脚本，或者就直接叫做迁移，他们已经是最近于“数据库即代码”这种策略的形态了，但仍然包含大量不必要的复杂性。

North：对于DBA来说，最理想的模式是让他们成为开发及运维团队这个整体中的一分子。DevOps的目标是将敏捷开发中的各种技术优势，例如持续集成、自动化以及版本控制整合到一个运维的上下文中，同时依旧保持让系统持续运转的各种严格的纪律。

我希望未来的数据库变更能够像代码变更一样简单。我不希望手动编写迁移脚本，或者不断记录有哪些脚本已经运行过了、哪些还没有运行等等。我应当能够选择在某个开发数据库上进行的任何变更，然后像代码一样进行“签入”。我不需要在版本控制系统中手动进行差异比较操作，而是可以在软件中直接操作，让VCS来找出这些变更。

数据库工具应当能够指出自上个“版本”以来，数据库一共产生了哪些变化，并生成相应的迁移脚本。像Red Gate等几家软件商在这方面已经取得了一些进展，但前方的路似乎还很漫长。目前大多数的“敏捷型”数据库工具主要作用还是创建、应用以及管理迁移脚本，而不是真正将数据库视为代码进行处理。