聊聊数据库的DEVOPS


DevOPS这个概念变得热门也已经有4-5年了,DEVOPS不再以最初的打破开发与运维运营之间坚冰为目的,而是为了实现从研发到交付的全面流程自动化。数据库交付是一个十分复杂的IT交付过程,因此数据库交付已经成为DEVOPS里最麻烦的一个环节,这个环节上的问题不解决,DEVOPS的整个流程都无法顺畅的进行。目前很多正在开展DEVOPS工作的组织只能把数据库当成一个标准化的IT基础设施而不去直面它,从而避免在这里碰的头破血流。

另外一种做法是通过应用架构的技术创新,让数据库成为一种十分标准化和易管理的IT基础设施。在应用微服务化的基础上改良数据库架构,让每个数据库都很小,在数据库上的访问都十分简单(通过应用的开发模式优化来实现),每个生产系统数据库存储的数据都只是生产环境中的少量时间(比如最近一个月甚至最近几天),历史数据通过流式平台进入大数据中心或者数据中台,再进行分析型的应用。在这种架构下,数据库可以成为一个十分标准化和可自动化运维的基础设施,通过容器云或者RDS服务等方式实现自动化的交付与自动化的运维。这种模式下,数据库成为DevOPS中类似应用服务器的标准化基础设施,也就不难管理了。不过这种模式对于大多数企业来说,要想实现还是十分困难的。应用架构的彻底变革不是一件容易的事,新的架构需要很强的IT支撑能力来支撑,也不是中小企业能够承受的。在大多数用户的场景中,数据库的DevOPS依然是一块横在我们路上的顽石。

为什么会存在这样的事情呢?在传统的模式下,应用开发人员与DBA分别管理着应用软件与数据库,二者的交汇点仅仅在系统测试与试运行阶段,甚至是更后面的运行阶段。二者之间的工作存在一定的交叉,但是各自以黑箱的方式工作的模式是最为常见的模式。研发人员不了解DBA的工作与技能,反过来DBA也不太关注开发人员的工作。这种割裂导致了DEVOPS在数据库上出现了一道鸿沟。另外在数据库技术上来看,不同的数据库引擎之间虽然在应用接口上都遵循SQL标识,但是其个性化特征还是十分明显的,数据管理的工具与技术也各不相同。数据库监控、运维与优化的方法差异甚大。这一切都给Devops的持续集成工作带来了巨大的困难。数据库的DevOps的另一个重要障碍是所需文化和流程的变化。
在工作流结束时不进行数据库更改的审查,这表明开发团队与DBA之间的沟通不畅。如果缺乏自动化的确认手段,那么任何一个和DBA相关的工作结束后,都
需要等待DBA来检查更改,直到最后一个阶段为止。而在缺乏合理的流程管控以及流程自动化工具支撑的环境下,这一切都是十分困难的。


正是因为上述原因,在DEVOPS开展之初大部分企业是以应用为主的,在全面开展的过程中才会发现如果把数据库也纳入到devops体系中来,那么可以进一步提高应用开发交付的敏捷性。
下面我们根据应用系统开发的不同阶段来分别描述数据库DEVOPS相关的一些问题

研发阶段

目前将数据库纳入DEVOPS最大的障碍不是技术壁垒,而是团队融合,因此实施数据库的DEVOPS的第一步是让研发与DBA团队融合成为一个整体,不一定在组织架构上,至少应该在项目层面形成一个融合的整体。DBA的所有和本项目相关的工作必须与研发团队的工作纳入统一的管理。

第二个需要完成的融合工作是源代码控制管理的融合,DEVOPS最终是要实现自动化的交付,因此所有的DBA的工作都必须转换为自动化脚本,DBA应该放弃其随意性的SQL编写,让DBA的每一行代码都与项目代码一起管理,从而在交付应用系统的时候,也能把数据库的相关操作都一体化交付。

一旦DBA的所有SQL代码都能够被有效的管控,那么这些代码就可以被持续集成,并纳入统一测试中。开发人员可以把DBA编写的所有工具或者脚本当成一个普通的程序代码来使用。和应用开发的其他程序与测试数据统一进行测试。这样就能够实现DBA与应用开发的真正融合。将DBA编写的代码纳入源代码控制存储库后,CI服务会启动并运行一系列命令,这些命令执行诸如编译源代码和运行单元测试之类的任务。如果数据库是部署的一部分,则CI服务将测试并更新数据库的相关配置与数据。如果在CI和单元测试中发现DBA的代码或者数据库的自动化配置与变更代码存在问题,DBA可以修复它们并重新提交代码,从而重新启动CI流程。在这个过程中,也可能能够发现应用开发人员的代码与DBA代码之间存在不一致的问题,或者存在性能问题,这样也可以提早发现研发中存在的与数据库相关的BUG。

当CI服务处理SQL代码时,一般来说会通过一些工具将SQL代码转换为一个和DEVOPS平台融合的工作组件,其中包含更新数据库对象和静态数据所必需的部署脚本,可以用于数据库的部署以及数据的初始化。该组件中应该还包含有关部署过程的详细信息,包括一些合规性检查工具,能够自动分析部署后的环境中存在的问题,以及数据是否满足交付的要求。该组件的版本代表一个经过验证的特定版本,可以用作数据库发布过程的起点。

一旦完成工具的测试,CI编译工具和DBA编写的所有代码都作为整个应用系统的一部分统一管理。也将随着应用软件的发布版本,以统一的版本进行发布。

测试、交付与运行监控

应用交付前最重要的环节是测试。在发布到准生产环境之前,对数据库的部署与所作的所有变更都应经过严格的测试,特别是DBA编写的自动化脚本。以前DBA虽然已经验证过这些脚本,但是这些脚本并没有和应用系统以及准备上线的数据进行严格的联调,这里可能存在一些BUG。通过测试,不仅DBA可以发现代码中的BUG,还可以有效的帮助开发人员发现SQL语句中的一些BUG。开发人员可以在开发过程中尽早地了解问题,发现问题后,会立即向他们发出警报,以便他们可以将修复检查到源代码管理中并保持开发工作的进行。开发人员和DBA应该投入必要的时间来编写全面的测试用例,以提供尽可能多的方案。

单元测试为发现SQL代码的问题提供了第一道防线,不过以往DBA不会介入到这一环节,而且这一环节的生产数据准备还没有完成,因此想在这个环节发现问题十分困难。由于DBA早期介入项目开发,因此在单元测试环节也可以具备一定的问题发现能力,SQL审计工具与一些SQL自动化分析工具的引入,可以让开发人员也能够快速的发现与定位SQL的问题,而DBA早期介入可以让单元测试获得与生产环境相似的测试数据,从而提高单元测试的问题发现率。

DevOps中的应用程序交付方式与传统方式也不同,不再是集成测试、系统测试、性能测试、试运行这样的瀑布式的流程,取而代之的是一系列连续的反馈循环,该循环为参与者提供有关交付过程的持续详细信息。例如,当持续集成服务发现代码中存在的BUG的时候,会立即反馈给开发人员,这些信息反馈就是这个循环的一部分。开发团队,不论是应用开发团队还是DBA,应该在整个过程中具有完全的可见性,可以随时通过工具平台获得所有的反馈,而不能像传统的模式下通过沟通和文档来实现信息交互。这些可视化工具不仅有助于在交付周期的早期识别应用程序和数据库的问题,而且还有助于监视交付过程本身,以找到改进和简化操作的方法。在这个过程中,对数据库的监控十分重要,不仅仅是监控数据库的运行状态和性能,更重要的是监控应用相关的数据本身。通过持续集成产生的自动化代码将研发过程中的所有变更部署到生产环境后,DBA必须密切监视所有相关系统从而发现可能存在的问题。从而确保在严重影响用户或数据之前,问题能够被发现和解决,从而让系统能正常运行。开发人员和DBA都应该对可能需要立即关注的问题或在可预见的将来应解决的问题具有实时了解,并能在第一时间介入处置。为实现这个环节的DevOPS,必须引入具有深度问题发现能力的自动化监控工具来确保问题能够在影响系统运行之前被发现,同时还必须具有可贯通整个流程的自动化管理工具,用于支撑整个过程的持续集成与部门间的协同。
在DevOPS的交付阶段

测试和
数据库监控
在确保数据库的整体安全性方面也起着至关重要的作用。
开发人员,IT管理员、DBA必须在整个应用程序生命周期中持续关注数据库的安全问题,解决从SQL、服务器可用性与安全、数据库高可用与安全等的一系列的问题,以确保在应用程序交付过程的每个阶段都对数据进行保护。这些内容也必须通过自动化的手段加入到整个应用的全生命周期中。

从上面老白谈的数据库DevOPS的一些工作要点上看,似乎数据库的DevOPS在传统企业的系统上也不是不能实现的,似乎每个环节都有解决方案。不过问题真的如此简单吗?答案是否定的。在上述的过程中,都有大量的和数据库相关的工作需要自动化的问题。

最初的数据管理、数据拷贝、复制、数据升级变更等的工作需要自动化。这个自动化工作就十分困难,因为我们现在开发的任何一个系统往往都不是空系统,都已经需要初始化导入部分的现有生产数据。如果这些数据的量不大还好说,如果是一个已经运行了十多年的业务系统的2.0版本,那么你可能面对的是几十万张表和数个TB的数据。在这个环节里,CDM等技术平台的引入有时候是十分必要的。通过CDM你可以快速获取到当前的生产数据并快速的用于各种测试与数据处理过程。

数据库的自动化部署于自动化调优也是数据库DevOPS中十分重要的自动化工具,如果你的企业的RDS服务已经十分完备,那么恭喜你,把这部分工作集成到DevOPS的整个流程里的难度并不大。如果不幸的是这一切都还不具备,那么低代码实现自动化部署就是空中楼阁了。那么DBA将会面临巨大的挑战。购买一个这样的工具或者改造你的云平台,实现高效能的RDS自动化供给是你要做的第一件事。你说没钱,那就洗洗睡吧。如果这个钱也花不起,那么你的组织也很难雇得起写得出这种自动化代码的DBA吧。

在测试、交付运行监控阶段提供能够持续集成的自动化分析与自动化协同能力同样需要工具平台的支撑,这些工具更为复杂,往往市面上也很少能够买到,即使买到后还需要与你的平台进行整合。这些都是十分花钱的工作,不是一般中小企业所能够支撑得起的。

总结一下今天想表达的观点,首先数据库Devops是可实现的,但是确实是不容易实现的。如果能够在应用微服务化的时候让数据库成为一个可控可管的普通IT基础设施,那么是最好的。如果不能,那么你必须让DBA的工作前移,成为应用开发工作的一部分,才能真正实现完整版本的Devops,并且需要投入巨资完成支撑持续集成的各种自动化工具,才能让整个流程都顺畅起来。否则你就不要去做数据库的Devops,把数据库作为应用中使用的一个独立的基础设施去管理好了。换句话说,如果你的企业只有十来套数据库系统,那么数据库的Devops也是一种得不偿失的工作了,没有量的自动化是很浪费的。在这种情况下,不要做数据库的Devops,单独完成“数据”的Devops就完全够用了。

聊聊数据库的DEVOPS》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/548.html