Agile Consortium International and Unicom组织机构在2016年2月于荷兰阿姆斯特丹举办2016 DevOps阿姆斯特丹首脑会议。InfoQ不间断报道了此次活动。
在DevOps阿姆斯特丹首脑会议上，Dan North将在演说中探讨资料库管理什么样适应自然环境DevOps而此捷伊课堂教学。InfoQ与North展开了一次采访，内容主要包括资料库管理员的日常生活组织机构工作，和那些组织机构工作与合作开发相关人员和网络管理相关人员的组织机构工作间的关连；资料库管理是什么样组织机构的；资料库什么样适应自然环境DevOps或持续交货课堂教学；和North对实施了DevOps的组织机构资料库管理未来的变化有什么样的期待。
资料库管理的日常生活组织机构工作DBA而此角色一般而言会接触多种类型自然环境、合作开发项目组、技术和业务好下场人。也许他们在上五分钟还在展开资料库调优，下五分钟就要安装某一固件，和对生产自然环境中遇到的难题展开积极响应，或者回答合作开发相关人员们的难题。他们须要确保存储与递送的正确实用性，控制系统与用户对相应的资料库（因此仅指那些资料库！）有着适当的访问职权，因此还要前述参与异常的控制系统行为的诊断组织机构工作。
DBA的前述商业价值体现在对资料库本身、运转时优点与实用性等机制和细节的理解上，并在撰写查阅功能的合作开发相关人员与负责管理各种工作台的运转的网络管理相关人员间起到公路桥的作用。娴熟的DBA能指出什么样加快运转较快的查阅的方法，主要包括发生改变查阅逻辑、调整资料库schema、或者更动资料库运转时的参数。例如发生改变连接的顺序、引入检索（有些情况下还须要删掉某一检索！）、对资料库的查阅执行计划器给出提示、或者更新资料库的分析方法优点，那些组织机构工作对操控性可能会带来极大的影响。
重新加入一名DBA，商业价值无以诚然关于数据库与合作开发相关人员或网络管理相关人员的组织机构工作交互，这方面有一个不幸的事实，只有少数的合作开发相关人员能真正了解亲密关系型资料库背后的运转机制。Hibernate或谷歌的Entity Framework这样的框架提供更多了一种态射层，它向一般的企业合作开发相关人员掩饰了内部的运转机制，因为对那些合作开发相关人员而言最重要的专业技能在于C#或Java的程式设计，此种作法显然是一把长弓。一方面，此种态射层能在资料库schema与对应的程序语言计算机程序间生成态射亲密关系，从而精简合作开发一般插件的过程。但假如你所期许的领域模型与资料库schema间产生了较大的分歧，或者是对操控性、易用性与可扩展性有较高需求的情况下，此种方式很快就会让应用非常复杂起来。在此种情况下，假如在合作开发项目组中能重新加入一名DBA以提供更多帮助，此种作法的商业价值是无以诚然的。从网络管理的角度而言，DBA一般而言须要负责管理实现业务上的递送或易用性的策略。监控控制系统、诊断难题及“保持控制系统始终正常运转”等组织机构工作属于网络管理相关人员的职责，但DBA也须要深入参与与资料库相关的监控组织机构工作与难题诊断。他们还须要为网络管理项目组定义资料库管理与维护的流程。
谈谈资料库管理的组织机构一般而言而言，DBA而此角色的组织机构工作主要来自于请求或工单控制系统，这形成了另一种技术壁垒。此种方式意味着DBA往往接触不到宏观的业务或技术方面的需求与限制的上下文，他们往往只能在信息的真空中尽力把组织机构工作做好。从我的经验来来看，DBA经常会扮演一种随时提供更多支持服务的角色，因此假如某一合作开发相关人员的查阅超过了阀值，那么DBA很可能在半夜里被电话吵醒。也正因如此，DBA对来自合作开发相关人员的资料库变更往往选择谨慎的、甚至是非常质疑的态度。
有时候，DBA可能会分为“生产自然环境DBA”与“合作开发DBA”这两种不同的角色。前者一般而言都坐在一起，展开我之前所描述的各种生产自然环境的维护组织机构工作。而后者将帮助合作开发项目组展开schema的设计与查阅，让他们能以正确的方式与资料库展开交互。此种方式可以带来很好的效果，尤其是生产自然环境DBA与合作开发DBA间已经建立了一种信任亲密关系的前提下。生产自然环境DBA知道合作开发DBA会确保schema的设计与资料库的查阅具有一定程度的质量与合理性，而合作开发DBA也相信生产自然环境DBA会以正确的方式对各种资料库实例展开实用性与维护。
适应自然环境DevOps的困难在许多组织机构中，他们间确实是无法适应自然环境的。无论是将资料库变更通过一个独立于应用代码变更的额外流程展开发布，还是将资料库与应用的变更统一发布至生产自然环境中，两者都面临着很多困难。
某些组织机构会采取“资料库即代码”的策略，通过某些自动化流程，利用变更脚本将变更部署至资料库中。那些脚本与应用代码一起在源代码控制控制系统中展开管理，这可以精简变更的追踪与分析组织机构工作。那些变更脚本一般而言叫做迁移脚本，或者就直接叫做迁移，他们已经是最近于“资料库即代码”此种策略的形态了，但仍然包含大量不必要的复杂性。
未来的变化与准备对DBA而言，最理想的模式是让他们成为合作开发及网络管理项目组这个整体中的一分子。DevOps的目标是将敏捷合作开发中的各种技术优势，例如持续集成、自动化和版本控制整合到一个网络管理的上下文中，同时依旧保持让控制系统持续运转的各种严格的纪律。
我希望未来的资料库变更能像代码变更一样简单。我不希望手动撰写迁移脚本，或者不断记录有哪些脚本已经运转过了、哪些还没有运转等等。我应当能选择在某一合作开发资料库上展开的任何变更，然后像代码一样展开“签入”。我不须要在版本控制控制系统中手动展开差异比较操作，而是可以在软件中直接操作，让VCS来找出那些变更。
资料库工具应当能指出自上个“版本”以来，资料库一共产生了哪些变化，并生成相应的迁移脚本。像Red Gate等几家软件商在这方面已经取得了一些进展，但前方的路似乎还很漫长。目前大多数的“敏捷型”资料库工具主要作用还是创建、应用和管理迁移脚本，而不是真正将资料库视为代码展开处理。
英文原文发布于：http://www.infoq.com/news/2016/01/database-administration-devops。感谢邵思华翻译。
高效合作开发网络管理加群啦！
