数据库DBA为什么拒绝DevOps？

许多传统的DBA都不愿意接受DevOps，因为担心他们的角色会被淘汰，让我们首先消除对单个数据库的误解。DBA的作用并没有消失，而是在不断发展。DevOps虽然对大多数企业来说都是必不可少的，但必须以数据为中心点来完成。数据库将通过减少依赖于特定平台并更好地快速透明地提供数据来为业界提供最佳服务。

DBA和开发之间的中断沟通几乎就是IT的代名词，DBA不崇尚变革，因为他们注重数据一致性与稳定性。Devops开发周期就是变革。由于开发周期是持续交付的一部分，并且持续集成给稳定性带来了巨大压力，DBA可以开始向开发周期的减缓施加压力。最重要的目标是让DBA成为devops流程的一部分，尽可能消除中断或影响的可能性。

消除影响开发周期的最好方法之一是确保重现生产的开发和测试环境。使用虚拟化来提供尽可能多的开发和测试环境 - 在进程中同时进行多个开发周期所需的数量 - 应该是任何DevOps组的优先级。请注意，我已将此责任分配给DevOps组而不是DBA组。这种区别的原因是我们让DBA对此负责的时间太长了。

团队也可以考虑容器化环境。Docker之外有许多类型的容器技术。一种流行的解决方案Kubernetes可用于创建“pods”，以便识别彼此属于哪些层，以及将这些单独层组合为一个层的能力。与使用虚拟机相比，它将节省资源并最终节省资金。容器化在数据库级别也非常有用。

随着对数据库源的外壳的这种改变，可能不需要用于中央分析的辅助数据源。SQL可能在数据库平台之间具有类似的“风格”，但语句可能会导致不同的结果，具体取决于数据库平台。通过将数据库仅用作数据存储并消除大部分专有代码，将其强制到数据库层之外，数据库引擎之间的更改影响将会更小。数据库层只负责索引管理，查询优化和统计信息收集，这些也可由数据库引擎自动化实现。此时数据库只不过是一个数据存储，这就是DBA不愿意看到的地方。DBA必须超越自己的数据库平台技能或对任何产品的忠诚度；DevOps工程师必须拥抱比任何独特平台更高级别的解决方案。

最后，我们希望看到具有与数据库平台交互的能力的接口（命令行和图形），不会绑定到任何供应商如Oracle。

需要从具有中心数据库的紧密耦合的架构环境中脱离出来，解决此问题的一种方法是在数据库之上构建微服务。通过授予每个微服务自己的数据库 - 特别是数据库的虚拟化副本 - DevOps能够像任何代码一样快速地移动，并且它与其他开发周期的冲突更少，只需要最后一步就可部署。