数据库融入DevOps基因后,运维再也不用做背锅侠了!

王鹏冲 2021-03-09 14:40:03
 

本文根据〖deeplus直播第255期〗演讲内容整理而成,由dbaplus社群原创首发(文末可获取本期PPT&回放方式)。

 

点击↑蓝字【DBAplus社群】并设为星标,持续收获更多独家干货!

 


本文将会分四个章节来讲述。

 

 

一、概论

 

首先我们来看一下数据库和DevOps的关系,或者说它们是如何建立联系的?

 

 

数据库怎样融入DevOps基因?

 

可以从如下这几方面切入:

 

  • 标准化

  • 自动化

  • 监控

  • 安全

 

这些维度,包括怎么样去做监控、怎么样去保证我们的数据安全,在这些方面去考虑、去深入、去设计我们的数据库有什么样的工具,或者是有怎样的平台来支撑我们达到这方面的目的。

 

我们今天也会围绕这些方面展开讨论。

 

 

传统的数据库在开发、发布存在哪些问题呢?

 

上图为国外一家专业公司的调查结果,我们可以看出一些问题:

 

  • 第一,比较慢的开发、发布的周期是我们传统方式存在的最大的问题,它大概占比24%;

  • 第二,不能快速响应业务的需求,比如说我们的快速交付,我们数据库的实例;

  • 第三,当我们有一些变更的时候,它的失败会造成我们数据库的downtime,这个也占比较高;

  • 第四,开发和运维之间缺乏交流。

 

这是前四个原因。

 

 

我们如果说,大家认识到这些问题,我们也知道朝哪些方向去做,那么我们怎么样能把数据库集成到DevOps流水线上呢?我们会面临哪些问题呢?这值得我们去研究。

 

怎样同步应用数据库的变化?怎样能够把应用和数据库的发布,以及发布方式的不同拉平到一致?应用和发布的方式,以及所用到的工具都是不一样的,我们怎么样才能把它们集中起来?

 

这是我们可能遇到的挑战。

 

 

假设我们要在一家公司做这些事情,我们可能会遇到哪些困难险阻呢?

 

首先,我们要打破目前的流程,比如说我们以前银行发布数据库的方式,首先需要开发提交脚本到代码库,再提交发布请求到工单系统,版本审批通过后,还需要运维去下载脚本或通过邮件接收脚本去手工通过客户端或工具来执行发布,这是我们以前的方式。

 

现在全线上化方式后,我们怎么样去适应变化呢?这样一个演变,跟以前的方式是有区别的,我们怎样保持一个平滑的过渡?这都是要考虑的一个问题。包括我们讲到的缺乏开发和运维之间协调的一致,或者说一致性的认知,这些都是阻碍的因素。

 

 

那既然有这样的目的、这样的阻碍因素,那是谁说了算呢?怎样在公司践行你的数据库DevOps理念呢?

 

这里面其实是需要公司技术管理层牵头,至上而下一起去推动落实,才有可能实现。当然,我们的开发人员、DBA、架构师也要参与进来。

 

二、DevOps:面向开发

 

现在快速地进入到第二部分,就是面向开发,我们需要做到什么事情?

 

这一部分主要讲解的是面向开发提供了涵盖数据库开发设计、代码审核、部署测试、生产发布的一条龙生产流水线。

 

 
1.数据库的DevOps变得迫切、重要

 

 

刚刚也提过过,以前的开发流程,就是开发人员要将应用程序打包,并按顺序汇总、整理数据库发布脚本,DBA拿到数据库发布脚本后检查、备份、执行,以完成数据库发版;部署人员拿到应用部署包,备份、替换,已完成应用程序发版;引入DevOps后发布流程为开发人员将应用程序、DB代码在CI工具中完成打包;部署人员拿到部署任务后,直接在发布系统中完成DB发版以及应用包部署。

 

这是简化了发布的流程,而且全线上化。在有这套流程以前,我们的脚本是通过邮件,或者通过签报,一些共享的平台去完成脚本的传递的,那么有了这个流程之后,我们全部是在线上工具之间进行对接的。

 

 
2.数据库设计、开发、测试、发布流水线

 


这套流水线的设计思想是这样的:首先会有一个建模工具,建模工具会生成我们的数据模型,生成数据模型后会转化成数据库的DDL、DML的语言,然后经过审核之后会上传到代码库,然后发布平台会读取代码库的发布请求,然后发布请求会传递给我们执行发布的数据库发布工具,我们给它起了个名字叫DBgo,那么它就会在测试环境执行发布任务,测试环境测试完成后会经过我们的集成测试平台进行测试、验证,然后会进行移交,到生产环境的发布环节,然后最终是发布到生产环境。

 

其实这个流水线流程是非常直观明了的,思路也是比较简单的。

 

 
3.数据建模工具

 

数据建模工具(1)


 

那现在我们一个一个环节往下看。

 

我们的建模工具的目标是解决这些问题的,就是从建模开始讲,缺少统一的工具支持、建模与数据标准脱节、数据模型无法共享,公司的数据标准无法落地,这都是我们目前这个建模工具所要解决的问题。

 

那么我们的目标实现了什么呢?就是我们通过这个东西实现了快速建模,比如逻辑模型、物理模型,可视化建模,可以快速地编辑我们的表、字段等等,并且可以跟你的数据标准落地。因为现在很多大型公司都流行数据治理,那你的数据标准库、词根库拉通,可以实现数据标准智能发现以及数据标准引用,提升建模质量。还有一个是模型共享,也就是说很多标准化模型都是可以跨团队、跨系统共享,一个大公司可能它的很多业务的模块都有可能是可以复用的,那你的底层模型肯定是可以共享的,那只有我们存在这样平台,才可能达到这样的目的。最后一个就是设计驱动开发,很多时候我们这个程序开发跟数据库开发就比较的粗犷,就直接开盖,没有设计,直接就编写程序编写表,我需要什么样的数据存储,我就去建什么样的表,就没有在最开始的时候把整套模型给设计出来。因此,我们可以通过这个建模工具把我们的数据库开发规范给落地。

 

数据建模工具(2)

 

下面大概阐释跟建模工具相关的一些细节。


 

大概的过程是这样的:新建模型、设计表、设计字段、设计索引、模型发布、生成DDL,大概是这几个过程。这里面可能会有一些不一样的场景,就不一一叙述了。在不同的场景下怎么样去进行数据库建模,步骤都是类似的,按照我们上图右边的“步骤列表”都可以做。

 

数据建模工具(3)

 

我们的建模工具支持数据库的逆向,就是我已有的数据库可以通过建模工具连过去,然后生成模型,把已有的数据库模型生成出来,这叫逆向工程。跟大家演示一下(如下图),这就是我们已有的数据库,经过一系列的步骤,最后生成表的模型展示。


 

数据建模工具(4)

 

那模型除了可以逆向工程生成模型之外,也可以去导入。由于我们很多的传统工程都是基于EXCEL去建模的,可以把EXCEL导入进来,这样也可以生成我们的模型。(如下图)

 

 
4.DB发布流程总览


 

下面就进入到我们的发布阶段。就是我们的模型建完之后,我们数据库的脚本是怎么发布的?刚才我们提到,我们的脚本会传到一个平台上,这个平台会调用我们的工具去做发布,那我们DBA所涉及到的工具就在这个环节起到作用了。我们会对脚本文件、SQL文件进行解析,就是语法、语义规范、性能、空间进行检查,这里面可能会分为两部分,就是叫做静态检查和动态检查。

 

所谓的静态检查,指的是比如说你的DDL写得合不合规范,比如说你的create table有没有带comments、有没有加主键索引,再比如oracle新建索引有没有按照规范设置initrans大小等,工具先解析出DDL/DML的语法,然后根据预定义的规则做出是否符合规范的检查判断,这就是静态检查。

 

而动态检查就是,工具会连到数据库里面去检查:例如你将要创建的对象跟已有的对象命名是否冲突,如果已经存在,我就没必要在执行的时候再告诉你,这叫动态检查。如果通过的话就会进入到测试环节至应用环节,如果执行通过的话就会进入到生产执行环节,如果不通过的话就会将本次提交的脚本打回去。

 

 
5.数据库发布工具DBgo

 

数据库发布工具DBgo(1)


 

上图是我们数据库发布的背景说明,就是为什么有这样一个东西,就是去规避人工执行的错误;然后环境混乱就是,我们可能有多套测试环境,可能会连错,甚至生产环境也会连错这种情况;如果版本发错回退的话,没有工具支持的话时间也会很长;有了这个工具后我们可以把整个发布过程记录下来,事后去追溯或者达到一个审计的目的都可以做得到。

 

数据库发布工具DBgo(2)


 

数据库发布工具DBgo(3)


 

我们的发布工具从刚开始设计的时候是从易到难的,因为刚开始想做一个大而全的东西是比较困难的,比如说我们刚开始是只发DDL不发DML,当然我们现在是做到了可以发DML。有一些同学可能会觉得我们比如说发布完一个代码后,比如一个对象,失败后是否可以自动回滚。那我们目前也是这样,比如我可以做备份,但是我们不做自动回滚的,可以帮你生产回本语句,但我不会帮你做执行,这些都是为了控制这个工具的风险。然后还有一个原则是只做新增,不做删改。比如说我制作增加字段,我不做drop字段,类似这样的理念,也是为了规避一些风险。所以我们分了几期,逐渐达到这样的目的。

 

数据库发布工具DBgo(4)

 

 

在文件命名里面,我们对于整个发布脚本文件的命名有一些约定,比如说有序号、有发布的用户属主,有发布的类型,比如你是做什么,有执行人的账号,通过这种格式化的配置文件名,我可以得到很多有用的信息。比如说我可以根据序号去编排发布的顺序,比如哪个先执行哪个后执行,就是根据序号来的。

熟悉oracle的小伙伴都知道,我还要指定每个脚本执行的用户schema(模式)从哪里来,就是从这里来。另外,通过这个脚本的开发人员名称知道是谁提交的,我们还可以做到精准的审计。

 

  • 文件编码要统一成utf-8,不然会有乱码。

 

DDL/DML我们尽量不要放在一个文件里,因为我们发布的原子的粒度,我们定义为一个SQL文件,这个SQL文件你可以写多条语句,但是我们的最佳实践是把DDL/DM分开,因为我们是一个SQL作为一个事务。比如说对于我的发布工具来讲,你的这个SQL文件里的语句要么全部执行成功,要么全部执行失败,这样一个设计理念,才能保证你的发布过程每一个步骤都是自包含的,不会产生一些关联的影响。

 

事务提交。我们这里也讲到,你的SQL文件里面不能发commit,是我们的工具帮你做commit。

 

这就是一些细节设计中我们自己考虑的一些点。

 

数据库发布工具DBgo(5)

 

 

我们这个工具其实它的原理也比较简单。我们是用了开源的组件。首先解析SQL类型,然后把SQL拆分出来,拆分成不同的小的模块,然后组成利于理解的开发程序JSON串,然后根据我们刚才讲的静态规则去做一些检查,然后把检查的结果反馈出来。动态检查其实也一样,就是连到数据库里面,根据你查到的信息,把数据库里面的信息跟你解析出来的信息和JSON串做一个解析和对比,然后返回检查结果。其实原理很简单,我相信大家去设计这样的一个发布工具,应该也是同样的思想。

 

数据库发布工具DBgo(6)

 

 

这是一个过程,大家看看就可以了。就是说真正执行的时候,做一个pre_check看看是否需要备份,然后按照顺序去执行,执行完之后要么成功、要么失败、要么回滚,然后最后做一个check,就是去确定你的这个语句是否执行成功了。

 

数据库发布工具DBgo(7)

 

 

上图就是我们的规则的展示,供大家参考。比如说我的静态规则,刚才讲到比如说我会判断你这个表的字段字数是否会超过50个字段,如果超过50个字段,我们就认为这是个宽表,我们会有提示。当然,这些规则有些是强制的,有些是建议的,会做一定的区分。

 

 
6.审核

 

SQL代码审核流程

 

 

刚才讲的是DDL/DLM的发布,那我们在程序里面SQL代码要怎么审核呢,我们也有一个审核流程。以上是我们整个的审核流程。就是说我们在开发阶段的代码会提交到我们叫做SQM的平台,在SQL质量管理系统里面去进行审核优化,如果审核通过就会进入到审核记录,然后去进行测试和生产发布;如果审核不通过,就会返回到开发处理,开发处理的时候会做一个判断和分析,那我只要修改为SQM建议的这种写法,或者是它觉得它的写法就是最优的,它就可以提交DBA审批,当然这是线上的。

 

这里面在生产环境和测试环境分别有一个控制点,控制什么呢,我会在测试环境和生产环境去扫描有问题的语句,然后跟审核记录做比对,比如说我真的在数据库里面抓到了有问题的语句,但是你又没有审核记录,那么我们就会变成违规记录。意思是你的程序没有经过审核就提交发布了,然后又产生了问题。

 

所以这个流程看似简单,实际上它穿插了很多东西,而且它涉及到的人员和角色也比较多,而且我们底层依赖的系统也比较多,比如说你首先得有一个开发过程管理系统,它才能把我们的审核违规单和开发的缺陷版本关联起来,那我们生产上也必须要有一个监控系统,它才能去发现这些问题,而且这个监控的语句能够跟我们这个SQM系统审核的语句建立关联,它才能做成这样的一个闭环。相当于说我们通过这个平台,对我们的SQL代码质量从开发、测试到生产完成一个闭环。

 

SQL审核规则举例

 

 

这是我们的一个审核规则,比如说就是一些常见的SQL语句上可能会存在的一些问题。

 

SQL审核工具:支持多种格式的SQL导入

 

 

这是一个大致的界面演示,就是你可以把自己要审核的语句,包括.SQL文件格式、excel文件格式,甚至可以直接把MyBatis和xml格式直接导进去,也就是说它可以支持多种格式文件的导入。

 

SQL审核工具:隐患SQL监控

 

 

导入之后会有一些报告反馈给你,包括你执行这个计划,缺少VR条件等等一些内容,然后你就可以看到导出SQL的详情报告。

 

刚才是我们第二章节,是我们面向开发,无论是数据建模、版本发布,包括SQL审核等一系列的面向开发,或是面向应用程序等跟数据库相关的涉及到上线的一个流程达到的工具。银行也不是全部东西都自己做,有些模块是外购的,像我们的建模工具、还有SQM审核工具,也都是我们外购的。但我认为这个是合理的。因为银行不是靠IT去盈利的,IT在银行的使命是维持系统的稳定,我们把专业公司在做的东西拿过来,比如建模工具、SQM质量审核工具拿过来之后,融入到我们现有的开发测试管理流程里面,而且能够跟我们现有的系统做一个对接,完成整个流程的闭环,我认为这就是我们在银行做数据库管理所带来的价值,不是所有的东西都要自己开发建设,这是我个人的理解。

 

三、DevOps:面向运维

 

下面我们进入到面向运维,在这一方面,我们打造融合不同DB类型的一站式数据库自动化运维平台。

 

 

上图是我们DB整个自动化运维的生态圈,可以看到我们有监控报警、配置信息管理、容量管理、数据库自动化交付、发布工具、日常运维工具、数据库查询发布工具、数据库切换工具等等,组成了我们DBA自动化运维生态圈,下面我们可以再简单了解一下。

 

 

上图是我们围绕数据库系统打造的一个自动化系统的概览图,围绕我们的数据库的配置信息,汇总到我们整个系统中心的CMDB里面,我们的数据库相当于我们被管理的目标,在这个目标上我们会做一些数据采集,我们的数据采集一共有两种,一种是基于数据开源的Prometheus,它负责的是我们所有OS层面的指标采集,以及我们开源数据库的指标采集。我们自己研发的这个产品叫做EasyDB/xall它主要面向的是Oracle,面向Oracle数据库各种指标的采集和展示。采集了数据之后,我们就会有一个监控告警的系统,基于我们采集到的数据,经过我们的程序的判断,我们有各种告警的指标,然后每个指标有不同的阀值,不同的阀值有不同的报警级别,我们大概分了三个告警级别:

 

  • warning

  • Info

  • critical

 

几个不同的级别,不同的告警级别告警发送的方式也不太一样,有的会发邮件,比较重要的会发短信;然后我们内部也有这种即时通讯的手机端的系统,叫作快乐平安,就像我们微信一样,更加关键的会自动外呼电话,外呼发到给我们的值班人员,这是告警。

 

有了告警之后,我们就要去分析定位了,助力我们分析定位的有,基于Grafana去把我们所有数据库的指标,比如你的TPS、QPS、会话数、等待事件、锁堵塞信息等等这些指标都展示出来,然后把OS层面的CPO、memory、IO、网卡流量等等这些指标都展示出来,这样你就能迅速定位出来你的问题瓶颈在哪里,是不是有一些热块竞争、有一些慢查询,是不是有一些业务量的并发、高并发突然涌入进来,或者是主机CPU队列等待,存储度有没有慢,都会通过我们的这个可视化提供的监控信息能够实时的定位分析。

 

定位分析之后要去处理解决,比如我们常见的几板斧,比如你要重启数据库、切换数据库、杀会话、去优化绑定执行计划等等,就需要一个运维工具,通过工具定位处理解决,实现了一些刚刚讲的那些常规动作。这种思路看似简单,其实是把我们运维经常要做的几件事情串起来了。基于这个我们还做了AIops的一些探索,后面简单介绍一下。

 

 
1.配置信息、监控报警

 

 

如上就是我们DBA的监控大屏,大家可以看得到,我们的DBA类型,基本上我们常见的数据库类型这里都包含了,大概有十种,像Oracle、MySQL、MongoDB、Redis、PG、DB2、Sqlserver等都涵盖,然后大屏上的每一行DB都是一个实例,这些实例我们都会监控它的状态,我们有几个关键的指标灯,比如说数据库是否连通,主从是否同步,数据库的连接数是否超过最大连接数、有没有产生数据库的拥堵、数据使用率等等。

 

这个就是我们一个集中的、而且可以cover所有数据库类型的监控告警平台。那我们的DBA平时只需要看这个监控就可以了,我们的值班人员只要有亮红灯的就通知处理,没有被处理掉的话这个灯就会一直亮着。

 

除了这个监控告警之外,我们也做了一些巡检,因为大家知道监控告警是一条一条的,当这条过去之后有些会遗漏,比如你的短信报警、邮件报警,如果你没看到的话就会错过,那我们就做了第二层的监控,叫巡检,各种指标的巡检报表,比如表空间使用率、FRA使用率、ASM使用率、CPU使用率、费用分析表等等。这个巡检就是我们的第二层防线,就是我们根据指标、根据实例、根据每个指标的监控告警之外我还有一个巡检和预测,做第二套保障,确保不会有潜在问题或风险被遗漏,影响生产。

 

 

 

这里展示了我们基于这个平台去处理一次生产实际问题的过程。发现有一个数据库CPU告警了,我们通过点击这个数据库的IP右键,这里有几个菜单,OS可视化、DB可视化、TOPSQL可视化。

 

这里就是OS可视化,然后这里我们发现这个数据库的CPU使用率确实很高。

 

 

然后这里是DB可视化,我们可以看到常见的几个DB指标趋势图,比如同一CPU冲高的时间点,这里的会话数也会有一个突增,或者我的数据库的等待事件里也会有一个突增等。

 

 

返回到大屏上,我们通过点击大屏上的某个红灯,比如数据库堵塞这个灯,我们就会进入到这个详情页面上:

 

 

这个页面就会展现出来当前哪些SQL在堵塞(wait)。例如这个enq:TX contention就是Oracle的行锁。

 

也就是说首先我们被通知到了有报警,然后通过查询分析资源和DB的相关监控图表,我们就定位到了问题出在哪里。我们知道这个是行锁,那么下一步的做法就是要杀掉这个行锁,也就是要处理报警了。那我这个环节也不需要人工登录到数据库里面,我可以知道这条语句的执行计划,通过点击这个SQL ID可以知道这个语句的执行计划。

 

 

我们可以知道这个语句过往按照时间排序的一个执行的次数,一个执行时间的变化等等。

 

 

我们进入到数据库里面去杀会话,以前先要登录数据库。在银行登录数据库还要经过几道堡垒机,这个过程很漫长,那么现在就不用做这个工作,可以直接通过监控平台的链接直接跳转到一个运维操作工具上,我们可以看得到这个SQL ID有两个执行计划,一个plan value 是311,另一个plan value是163,这两个执行计划我们可以看得到,一个走的是日期的索引,一个指的是number的索引。当然啦,它还有一些辅助的性能指标判断,就是那个执行时间、buffergets等,这里没有贴出来。这两个执行计划有一个是最优的,那我们可能要绑定这个执行计划,我们可以用工具一键直接生成oracle的profile,迅速地去绑定。当然也有可能不是执行计划的问题,就是短时间的并发会话拥堵产生的问题,我可能要临时去杀一些会话,那我们也可以提供批量去杀会话的功能。

 

 

这个oracle、MySQL都支持。

 

 
2.自动化运维

 

 

这个就是刚刚讲的运维工具的展示。用户管理、批量授权、会话处理、参数调整、表空间扩容等,oracle、MySQL、MongoDB都支持。

 

 

这是我们的主从切换工具,就是我们可以在这上面去执行我们数据库的批量切换、主动切换,因为会有些场景用到这样的工具。大家可能会问,我们的数据库切换不应该自动的吗?比如Oracle RAC、MySQL MHA都是自动切换的,为什么还需要这种切换工具呢?那如果你想要批量切换的时候就需要了,举两个场景,比如你一个物理机上面好多个实例,物理机要做主动维护;或者你是要多做容灾切换,同城容灾、远程容灾、异地切换,你可能一切切几十个、上百个,你可能就需要工具。我们现在已经做到Oracle、MySQL可以在这个平台上批量切换。

 

 

3.自愈-AIops

 

 

那就再进入到AIOps,当然我们的DBA他并不希望每天都在处理报警,那我们能不能探索出一条道路就是,如果出现一些简单的问题,我们运用一些人工智能的运维思想去自动地解决这些问题,这是我们的背景。这个就是主要的过程,是我们在AIOps在数据库上面一些简单的探索。如果大家学过一些AI的算法的话,比如说傅里叶、决策树、KNN、近邻算法这些,有了基本算法的基础理论后,实现AIops的方法论其实是一样的(起码在常规的系统运维场景),就是首先你要形成你的知识库,就是你要把你的场景提炼出来,然后形成这种常见的决策表,然后根据决策表来建立模型并提供样本让机器学习,不断训练,去优化你的模型,然后根据你的决策树生成你的解决方案,再对告警对象进行干预,实现告警消除。大概是这样一个过程。

 

 

这个是我们以空间为例所探讨的一个AIOps的场景,就是这个归档区报警了,这个是FRA区,然后是Oracle的,我们的场景有几个,我们的判断条件有几个,比如说报警了,这个使用率是在什么水位,是否还有磁盘空间,日志有没有备份等等。

 

举个例子,比如说当前已经报警了,然后还有剩余空间,备份没有成功,那我们的策略是什么?就是加大FRA区。换句话说,就是FRA区报警了,磁盘还有空间,你的归档日志还没有完成备份,没有备份就不能清理,那你的策略就是加大FRA区。

 

那还有一个就是,报警了没有剩余空间,但是我备份成功了,而且我监控到有大量的数据更新,那我的策略就变了,变成了调一次归档日志的备份,备份后的日志直接清理掉,这就是我另外的一种策略,其实策略就是一样。假如你是一个DBA ,面对这样的问题,你需要判断哪些因素,判断完之后你的动作是什么,这些东西需要整理起来。

 

 

这个东西就是决策树的一种算法,有了这种算法之后,你去把它写成程序,然后调用接口去把它执行就完事了。

 

 

这个就是我们自愈的简单的统计,而触发量,就是触发了多少次,触发自愈的一个统计。它确实在我们的生产线上已经上线了,减少了很多DBA在这个环节上的一个工作。

 

 

这是一些调用的日志。

 

 
4.一站式查询DB

 

最后就是一站式查询的DB。就是有十几个数据库,数千名开发人员,他们也有访问DB的请求,但是我们银行的访问是非常受控的,他们有一个物理的房间,要进去,然后再登Teminal、再授权、再去查,但很多时候这个效率是比较低的,而且操作间空间比较有限,所以在这个背景上,我们提供了一个基于外部页面的查询的一个工具。

 

 

这个就是我刚刚讲的一些问题。就是这个流程非常繁琐,开发人员想要去直接去查数据库里面的东西,因为涉及到一些敏感性意义,涉及到一些安全的审计,要有好多个步骤,大家可以看到蓝色的步骤大概有七八个,这样我们才能得到他需要的数据。

 

 

我们的需求非常简单,就是我可能简单地去查,又能够在安全可控的基础上。

 

 

现在我们已经可以做到这种白色底色的数据库的查询。

 

 

这个步骤很简单,第一步选择数据库,阅读说明、执行语句,然后查看查询结果,这里面还可以查看它的表结构,索引信息。这里的功能虽然做起来简单,但是我们其实做了一些事情。

 

首先我们会在背后解析你跑的SQL语句,如果发现你不符合我们的要求,或者你有一些查询隐患,比如说你没有输入VR条件,我们都会提醒你甚至拒绝执行。

 

还有一个就是刚刚讲的性能上的,还有就是第二点安全上面,我们这套系统会对接安全平台,某些数据库、某些表、某些字段含有敏感信息,那么我们的程序会自动把这些敏感信息过滤掉。

 

第三,哪些人、什么时间、查了什么表,我们后台都有审计。这个审计会对接到安全平台,就是说它会对员工的行为做控制等等。实际上,我们也通过这个达到了我们对数据库的一些规范或者运维安全的一些目的。

 

 

这个是我们的调用量。这个我们目前这个开发运维使用最多的一个工具,每天可以大概看得到有一万三千次的访问。

 

四、展望:AI+DevOps

 

最后就是我们的一个宣言:就是运维不做背锅侠。

 

  • 变更必须要有回滚方案

  • 生产必须要有应急预案

  • 容量必须要有预测机制

     

所有的这些你光靠口头是不能实现的,我们的宗旨就是能够做到工具自动化的就绝不让它手动去做。工具要有防灾机制,我们曾经有一些工具设计得不够完美,当然这个是需要一点点去迭代完善的。可能也会产生一些问题,甚至产生一些生产事件,所以我们的工具一定要有防灾。比如说,你的工具要去重启,要去重启一个数据库实例的时候,你是不是首先要看这个数据库是不是有连接。你不能不管三七二十一就上去重启了,一定要看这个数据库有没有连接,有没有活动连接。如果有活动连接,说明这个数据库还在提供服务,就不能随便重启,这又是简单的防灾机制。

 

开发其实是运维的友军。

 

践行DevOps不是一句口号,我们运维需要更多、更密切地跟开发并肩战斗,才能够达到这个目标。像前面讲到的数据库的建模、开发、设计、发布的一套平台,我们是跟开发团队架构团队密切合作才能做出来这样的东西。

 

 

>>>>

Q&A

 

 

Q1:为什么不用Zabbix?

 

A1:Zabbix其实我在上一家公司也用过。Zabbix的好处是它已经设计好一些框架,包括一些插件,它有它的优点,但是它对于我们来讲不太灵活的是我们的数据库类型太多。我们的自定义的指标,报警的阀值调整的指标又很多。另外一个,我们的发送渠道也很多,我们要发内部的即时通讯的信息,运维的统一的平台系统,这些功能完全叠加起来,如果要用一个完全成熟的工具的话,对我们来讲可能不那么灵活,所以我们选择了自己开发。另外,Zabbix在我们的上万实例的时候,其实它的性能也是一个问题。

 

Q2:老师你们这行做数据库和其他工具选型时主要考虑的点有哪些?

 

A2:我们其实对数据库有选型,对工具其实真的没有那么多选型。数据库选型其实是个比较大的话题,我们先不聊,我们先聊工具选型。工具选型其实我们最大的考虑是它要流行,我认为现在Prometheus是最流行的。除了我们DBA团队在用以外,我们其它团队也都在用Prometheus去做各种数据的采集,然后再加上Grafana做监控的,我们认为其实还是比之前我们用Zabbix的时候要好很多的。当然,我们不是把这些工具拿过来之后就停留在这里,比如说普米采集的数据我们会二次分析,二次分析之后我们会形成报警收敛后的输出,包括我们的配置信息也可以,比如说我们的静态信息来自于我们的交付系统,那么动态信息来自于我们监控系统的采集,但是最终我们配置信息的消费、展示也是我们要去开发的。所以我们基本上就会拿一个开源的系统过来去帮我们做一些它已经做好的东西,但是我们会基于它来做封装。

 

Q3:那么在没有办法快速自研的情况下,有没有开源的替代工具呢?

 

A3:这个其实有的。我们先不讲Prometheus,就讲数据库的监控软件,其实也很多。有兴趣的话可以交流一下。

 

Q4:这主要是用什么语言开发的?

 

A4:开发语言其实有很多。EasyDB大屏的后台是用JAVA开发的,前端最开始的话是用JQuery,最新版本的监控大屏使用React做了重构。后台开发也会用到Python,刚刚那个AIOps我们就是用Python Flask来做的。

 

Q5:数据建模的工具是用的什么产品,如何和数标结合?你们现在运维多少数据库?SRE有几位同事,有没有国产数据库?

 

A5:数据建模的工具是一家外购公司的产品,不过我们虽然是外购的,但是我们是用自己银行的标准,包括我们的规范,做了深度的定制。比如它的SQL建模的输出,输出之前它会调用我们DBgo的审核模块,审核通过之后它才会输出出来。

 

Q6:上万个实例的监控的话,监控工具压力比较大,对于监控软件怎么做优化呢?

 

A6:监控软件对上万的实例的优化其实是这样的,我们基本上就是分布式去做,我们的普米就是采用了联邦集群的方案,部署了很多套,不同的普米管理一部分被监控资源,你可以这样去设计,比如说这个普米集群只监控Oracle,那个普米集群只监控MySQL。或者说这个集群只监控这个网络区域的网段,那个集群只监控那个网络区域的网端。只能这样分布式,然后你这样分布式之后你怎么样去把它统一出来呢?你只能去做二次开发,你可以把这些监控系统的后台数据做一个接口,做一个组装,然后统一地输出到你的前端,我们就是这样一个思路,这样去分布式部署。你不可能用一套集群去管理所有的系统。

 

Q7:数据库表版本控制这块儿能讲讲吗?

 

A7:这块就是我们刚才谈到的细节。这个在我们的建模工具上就能对比出来,因为它对每一个版本都保留了一个version,你可以认为它保留了一个version的历史变迁详情,然后你可以在这个工具上去做一个对比,它能把差异给你展示出来。

 

Q8:普米采集的数据存到哪儿,如果量很大的话?

 

A8:我们现在普米的数据本身有存到MySQL里,然后ES也有存。当然,我认为对于我们监控数据来讲,其实它保留的时间有限,而且要做好聚合。就是说,一天之内你的数据就是秒集的,就是你是最原始的采集力度。一周之前的、或者是一天之前的,你采集的数据就是要存以小时为聚合的数据,或者说以小时为采样点的数据,超过一周的数据,你比如说就是以一个小时或者超过一天的数据,比如说你一个月也就三十个采样点,这是不一样的。比如说空间类的,表空间,你只要知道一天多大、一周多大,已经满足了你的目的。那你的绘画信息,你可能就需要秒级、分钟级,去展示它某个时间点的量,它的波动的异常。你经过针对不同的采集数据的聚合指标处理,你的数据量就不会这么大。所以一般存放到关系型数据库、ES,它也不会面临很大的压力。

 

Q9:下一步DBgo工具有什么要改进的地方吗?

 

A9:这个工具还在推广阶段,还没有完全替换现有的人工方式。在推广过程中确实会存在一些困难和阻碍。运维人员使用客户端工具发版比较灵活,比如有脚本报错,他分析诊断后,直接可以现场修改、再次执行;但是使用DBgo发版有各种规则的限制,各种给它打回,脚本出错后就要重新提交等等限制,我们也在持续改进。比如说要求我们能够支持某些如果规则不通过之后,能否转人工审核?但是人工审核也是要线上审核,我们允许它不符合我们的规范,但是也要经过人在工具上点一下,就是我们review之后,可以让它通过。

 

↓点这里回看本期直播

阅读原文

活动预告