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

数据库怎样融入DevOps基因？

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

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

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

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

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

这是前四个原因。

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

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

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

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

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

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

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

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

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

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

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

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质量审核工具拿过来之后，融入到我们现有的开发测试管理流程里面，而且能够跟我们现有的系统做一个对接，完成整个流程的闭环，我认为这就是我们在银行做数据库管理所带来的价值，不是所有的东西都要自己开发建设，这是我个人的理解。

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

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

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

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

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

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

如上就是我们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都支持。

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

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

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

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

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

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

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

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

这是一些调用的日志。

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

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

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

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

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

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

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

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

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

• 变更必须要有回滚方案

• 生产必须要有应急预案

• 容量必须要有预测机制

   

Q&A

Q1：为什么不用Zabbix?

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