数据库运维新思路：解读甜橙金融自动化运维平台亮点

Posted 2021-05-01 DBAplus社群

作者介绍

梁宝利，甜橙金融数据库高级研发工程师，多年数据库运维研发经验，目前主要负责甜橙金融数据库自动化运维设计与开发工作。

随着甜橙金融业务的不断增长，技术架构不断更新迭代，底层数据库架构和数据容量也在快速增长，给数据库运维带来了很多挑战。

甜橙金融的数据库团队在迎接挑战的过程中逐渐形成了独特的自动化运维体系，下面我们简单介绍一下自动化运维的心路历程，同时对自动化过程中碰到的问题给出我们的解决思路，希望能够互相借鉴。

接下来将从以下几个方面对公司的自动化运维进行介绍：

• 日常工作——知道DBA是做什么的；

• 数据库运维三个历程——知道自动化运维是做什么的；

• MOZIS平台架构——整个平台的自动化架构；

• 自动化运维设计实例篇——基本设计思路；

• 未来展望与总结。

一、DBA日常工作

DBA日常工作范围很广，远没有部分开发同学想象的仅仅是执行工单、搭建数据库这么简单。按照工作内容可分为下图所示的三大工作体系：

• 业务对接部分，主要是和研发同学直接对接，进行表结构设计、SQL优化、数据订正以及版本发布相关的工作；

• 数据库管理部分，主要保障数据库的稳定进行，并且保障数据库的高性能，这需要对数据使用形成规范、定期备份和数据迁移；

• 技术架构部分保证公司的底层架构、技术核心跟上公司的发展以及时代的步伐，不至于一直停止不前。

公司做自动化的目的就是为了能够实现日常工作的平台化，把重复的手工来动转变为自动化的程序运行；把DBA从繁琐的劳动中解放出来，投身于更有价值的工作。接下来介绍一下我们在自动化过程中经历的几个阶段。

二、数据库运维

1、人肉运维

这个阶段是公司最初的运维模式，靠人工来解决遇到的所有数据库问题。当时公司的运维状态基本上是每个DBA管理三到四套数据库，涉及到数据库的所有工作都由相关负责DBA进行操作。每天定时巡检相应的数据库，没有相关的监控系统，数据库的问题大部分是通过应用的反馈发现的。

当时公司规模较小，且数据库体量和数据压力不大，因此这种方式勉强可以维持公司业务的正常运转。

但随着公司业务的不断发展，数据体量和数据库压力显著增高，这种运维方式给DBA的压力也越来越大。不断的增加人手也只是暂时性缓解，并不能从根本上解决问题。因此运维团队开始慢慢引入各种开源工具，有针对性的解决运维面临的问题。

2、工具运维

随着各种开源工具的引入，公司的运维开始转向工具运维时代。工具运维主要针对工作通过使用一些开源或者购买相关的商业产品来解决某一个特定的问题。并且在此基础上，DBA也不断开发自研一些自动化脚本，辅助自己的日常工作，减轻重复性的劳动。

这个阶段公司引入的平台大体可分为下图所示的几类：流程把控、数据库监控告警、数据库慢SQL、批量部署和一些自研的自动化脚本。

工具的使用，解决了日常工作面临的很多难题。Zabbix的引入解决了数据库的监控问题，JIRA的引入打通了整个公司从上到下的通道，可以说每一个工具都还加了一个模块的工作，但是工具解决的大部分是如何发现问题，如何解决问题却很少涉及。而且工具之间的壁垒也使得整个运维体系零零散散。

3、平台运维

基于工具化的运维思路只是“头疼医头，脚疼医脚”，虽然缓解了一部分的工作压力，但是没有一个体系化的构建。在此基础上，公司开始了自动化运维平台的建设。

自动化运维的目标如下图所示：

把DBA日常工作抽离出来进行平台化、流程化，并且希望能打破工具间的壁垒，实现从流程到运维的一体化架构。

平台初期希望承载的业务包括：元数据管理（CMDB）、数据订正流程、版本发布流程、服务部署、数据迁移、批量任务执行等操作。这些都是DBA日常最繁重也急切希望能够解决的问题，只有这些最基本诉求得到实现，才能缓解DBA大部分的工作压力，并把节省的时间精力投入到更高层次的工作中。

针对上述的平台设计思路，接下来将会详细介绍整个平台架构，并对实现过程中遇到的问题，给出自己的分析。

三、MOZIS平台整体架构

1、技术结构

平台后台采用Python3.6开发，基本的前后端架构如下图所示：

技术结构的选型主要秉承平台可扩展性强以及快速搭建这两个特点。接下来简单介绍一下图中的各个模块：

• VUE属于前端的架构，为了尽量避免耦合，采用前后端分离的方式，没有采用DJANGO的Jinja2主要是考虑到未来的后端框架的扩展性以及伸缩性，后台和前端的交互只通过标准的RESTful接口进行数据传输；

• 后台采用DJANGO架构，比较成熟，且能够快速搭建一个后台网站；

• Redis作为信息缓存器主要存储一些前端Dashboard以及数据库基本的信息，加快前端访问速度；

• ANTLR主要用于SQL语法解析，最终采用ANTLR也是经历了很多个版本迭代，优势很明显，它能够较为精准的进行SQL语法判断；

• CELERY用于异步任务，由于一些数据库操作：加表空间、执行大批量SQL等需要时间较长，因此采用异步任务形式完成数据库操作；

• SSH用于连接到远端数据库服务器，不可避免有些操作需要在宿主机进行操作，比如说Oracle的expdp/impdp；

• Ansible用于一些批量的数据库推送，批量的数据库搭建以及批量数据库配置都需要Ansible进行相关的处理；

• 数据连接，就是一些基本的模块能够实现不同种类数据库连接；

• 采用mysql平台数据存储；

• 采用nginx提供对外服务。

2、功能结构

下图是MOZIS的整体功能架构图：

架构中我们对整个数据库体系划分了一下基本的层次。从上到下分别是：管理界面、优化分析、基础能力、CMDB。当然CMDB中又分为3个层次。我们将在接下来的详细设计中进行相关分析。这么拆分也是因为每一个层次的能力很大程度上依赖于下层的功能或者数据。

通过上图可以看到平台基础能力包含了基本的数据库搭建等多个日常维护动作。基本上这些功能能够保证数据库的建立以及日常基本维护。接下来将对系统中比较重要的几个模块设计进行详细的论述。

四、自动化运维设计

1、元数据管理

自动化运维实现，面临的第一个挑战就是元数据管理，一个运维成员最重要的是对自己的数据库做到心中有数，一个平台更是如此。下图是基于数据库运维的工作提取出的相关运维元数据块，可以看到数据库涉及的源信息来自多个领域：

主机、网络、存储以及数据库本身，每个领域的元数据都有其各自的复杂性，且根据公司的情况不同，使用的架构，设计的思路千差万别，因此从哪个角度设计、如何设计我们基础元数据成为了自动化运维开发的头一道难关。

数据库运维中涉及到的主机网络存储等模块，既相互独立又相互关联，包罗万象而又层次分明，经历了无数的坑，我们认为进行数据库元数据设计应包含以下特性：

• 适配性：庞大的运维体系以及复杂的运维环境决定元数据结构设计应具备一定的适配性。同时在满足规范标准的前提下应兼容一定的特例。为了实现这一特性，需要对运维体系进行抽象，并在此抽象的基础上延伸出相应的特殊化结构。

• 层次性：层次性反映的是整个运维框架从下到上的分层，是从底层硬件到操作系统到网络再到数据库这一整套的层次体系。元数据的设计中只需要展现出其数据逻辑，真正的空间逻辑需要我们在业务层进行体现。

• 完整性：数据库元数据涉及多个层次、各种类型，缺失任一部分的数据都会掣肘后续的自动化功能。且作为公司整体架构而言，数据库信息完整性是保证整个运维平台正常运转的基础。完整性与其说是设计原则，不如说是元数据的基本需求。

基于上述特性和总结，我们对公司运维体系进行服务化抽象，这样能够更好地反映各个运维流程的层次化关系，抽象是为了更好的展现数据的层次性与通用性，让我们在进行元数据设计时更方便。

下图即是我们抽象出的运维服务化架构：

可以看出，我们的服务从下到上分别为：

• 存储服务，用于提供存储资源；

• 主机服务，为上层提供CPU、内存、本地路径等服务；

• 数据服务，为上层提供基本的数据管理查询处理服务；

• 集群架构服务，提供数据库的高可用服务；

• 连接服务，提供数据传输、监听响应的服务；

• 网络服务，提供网络支撑定位主机的作用；

• 域名服务，提供域名与IP的映射关系。

在抽象出相关数据库服务的基础上，完成元数据结构基础设计，就相对简单了。特殊化的信息可在这个基础上进行拓展。

上述的抽象分析是从数据库运维的角度进行的，实际中对于不同的运维体系如主机运维、网络运维可能会抽象出更多的相关层次。而且从整个运维体系来讲还有应用运维的相关服务，最优化的方式其实不是针对每个服务设计一套数据结构，而是直接针对每个服务设计一套微服务架构。每个微服务针对的是不通的运维体系。

不过这种形式的设计将是一个复杂的过程，而且涉及的领域众多，不可能一蹴而就。但是运维体系的微服务框架必然是未来自动化运维的趋势。

2、订正发版流程设计演进

元数据结构的设计，是为数据库自动化平台打基础，接下来针对特定的功能，分析我们在自动化运维建设上的一些思考，这里拿数据订正以及版本发布为例来简单介绍内部如何不断的优化与创新最终实现真正的自动化流程。

下图是公司SQL审核的第一个版本：

由于公司对发版的数据结构有自己的规范，比如说表名、索引名、注释等等，因此人工审核费时费力。

审核1.0就是为了解决这个问题。我们从JIRA工单上下载需要执行的SQL，然后放到审核平台上进行审核，审核通过后，再手动的拿到数据库上进行执行。从原来的肉眼审核，变成工具审核；从之前的小时级的审核时间变成分钟级的审核时间，减少人为的失误，尤其是DDL语句。

审核1.0面临的最大缺陷是没有对接数据库。主要原因是SQL的正则匹配审核无法很好把控SQL可能带来的潜在风险。比如说一条Update语句，无法获取Update的数据量，也就无法起到风险把控的作用。

在1.0的基础上，我们对DML审核做了如下改造：

即通过连接数据库对DML语句进行EXPLAIN获取SQL执行计划，并通过审核执行计划完成SQL审核。这样一方面可以确保SQL的可执行性，另一方面利用执行计划的信息进行风险把控、SQL的影响行数等信息，虽然通过执行计划获取的影响行数不一定最准，但是可以一定程度上反映SQL对数据库的影响。

审核2.0出现之后，为我们日常工作节省了大量时间。几乎所有的数据订正都走审核平台。而且我们还加入了一些统计界面，用来跟进相关应用订正量大小，并要求其进行整改。

2.0基本上完美解决了DML审核问题，但是对于DDL依然只存在于正在审核，虽然不断迭代使语法规则趋于完善，但由于其复杂性依然没有对接数据库，而且审核现在存在于DBA手中依然避免不了出问题时与开发的沟通。为避免开发与DBA由于SQL规范问题导致的来回沟通，我们重新设计了整个审核流程，把审核权限下放到开发手中，如下图所示：

新版本的主要流程如下：

由运营或者开发人员提工单，当到达编写SQL这一步骤时跳转到MOZIS平台完成SQL上传并进行审核，审核成功后提交至DBA处理阶段。此时平台会把审核结果作为记录插入到当前JIRA工单的注释中，JIRA正常流转到DBA手中时，点击执行按钮可直接执行相关的SQL语句。

流程上的优化减少了沟通，缩短了整个执行过程，节省时间的同时也为之后的一体化发展打下坚实的基础。

而且为了保证DDL审核的精准性，放弃了之前的正则审核。采用ANTLR进行语法语义解析，最大的好处就是其简洁语法解析结构使得优化开发的速度更快更准。

3、自定义SQL审核规则

平台中还有一大亮点就是SQL审核的可自定义化。以往的设计中，审核规则直接是写死在程序中，每次规则的调整，都不可避免的修改代码，导致SQL审核规则的不透明化、平台的不稳定性，无法满足迫切的业务需求，因此我们设计如下图所示的可配置审核规则模式：

规则值、规则描述、规则等级以及是否启动都是可以设置的。一方面这种方式使得审核的通用性更强，另一方面可以使我们的审核更具灵活性、透明化、可视化，也能更好的普及SQL 规范。

五、总结与展望

数据库自动化于DBA而言节省的是时间，避免的是人为的误操作；于公司而言节省的是人力，避免的是人为失误导致的故障；于整个运维体系来讲它沉淀的是知识。

时间、人力和误操作都很好理解，自动化平台化，很多工作交予机器去处理，节省时间人力也避免手工操作失误。最重要的是它能把DBA的经验与知识固化到我们的程序之中，它承载的是一整套数据库运维知识体系。

运维自动化的未来必然是智能化，这是毋庸置疑的。但是如何开始，从哪里开始才是真正需要关注的，可能每个团队有自己不同见解。MOZIS平台这块从SQL优化、故障解决着手去探索智能的门槛。

为什么从这两块入手，主要是因为SQL优化以及基础的故障排查慢慢的已经形成了一套简单的排查流程，那么把这套流程体系或者说把这些DBA的经验程序化就可以完成这项工作。原理很简单，实现起来可能需要我们更多的努力。

千里之行始于足下，对于SQL优化这块前期可能也仅仅是排查一下是否全表扫描、执行计划是否变更、索引是否最优。虽然很简单，但是就像自动化设计是一个不断优化的过程，我相信智能化也是一个过程。只有从最简单的开始不断深入挖掘，才能从自动化过渡到智能化。

虽然说DBA开发自动化工具甚至是智能化工具是砸运维人自己的饭碗，但这就是趋势。我们大可积极改变和更新运维工作者的职责认知，顺势而动，在推动运维高效化的同时也使自己快速成长。

近期热文

？