58云DB平台自动化运维建设实践

58云DB平台自动化运维建设实践

简介

58云DB平台是由58集团总部DBA团队打造的云数据库平台，为集团各业务线提供高可靠、高性能的MySQL、Redis和MongoDB云服务，助力与赋能业务发展，提高效率。

通过云DB平台，在用户端开发人员不仅可以基于工单进行数据库资源申请和变更操作，还可以通过自助管理功能实现数据库自助运营,如实时监控数据库状态和集群访问趋势、自助查询数据、慢SQL统计与追踪等，充分满足了开发人员对数据库基本性能查询、常见问题诊断的需求，提升工作效率；在管理端，DBA可以一键自动化完成绝大部分日常重复、复杂的运维工作，极大提高需求的交付效率，保障数据库的稳定、高效运行。

诞生背景

58集团业务这几年发展迅猛，随着先后合并赶集网、安居客、中华英才网、驾校一点通等众多业务，各对应的数据库运维工作陆续并入集团DBA团队统一负责管理，随之也给DBA团队带来了很大的挑战，主要体现在：

各家子公司数据库运维标准规范不一致，管理复杂；数据库日常工单众多，提交方式多样化且人工处理，效率低下；服务器和数据库数量众多，无管理平台，EXCEL手工维护。

面临越来越多的数据库需求，急需要一个数据库自动化运维平台来释放DBA的人力，58云DB平台也就是在这种情况下诞生。在云DB平台的建设过程中，初期核心为自动化，后期开始考虑智能化运维，本文将会重点介绍这两面的实践及遇到的一些问题。

整体架构

上面是我们平台的整体架构，主要分为Web服务、接口代理服务、自动化服务、机器学习服务等。各服务的功能如下：

Web服务：由nginx和Web应用，提供基本的HTTP服务。其中前端用React编写，由webpack2打包后发布到nginx服务器上。后端接口由python开发，放在Web应用服务器中。为了数据的安全性，Web应用只能对用户的数据库作读取操作，所有的变更操作都交由自动化服务处理。下载服务：主要为用户从DB中数据导出和binlog提取等提供下载服务。接口代理服务：平台与其他公共服务的交互都是尽量走Restful协议，对于一些不支持的接口，我们搭建了代理服务，将其转为Restful协议。自动化服务：自动化服务是云DB平台的核心服务，主要将DBA日常运维操作拆解组合成一系列的自动化任务，为了保证这些运维任务能安全执行，我们将一部分MySQL日常工单需求交由Inception来处理，这样既能最大限度的降低运维操作对线上环境的影响，又兼具数据备份功能，为以后数据恢复的需求提供便利。机器学习服务：为了提高运维效率、降低运维成本，我们在自动化的基础上，对智能化运维进行了探索，孵化出了像服务器的智能优选功能和告警智能合并功能，极大的提高了运维体验。

运维自动化

随着公司业务的发展，运维团队的自动化进程是必然要经历的阶段。提高运维效率，降低运维成本，排除人工操作带来的不稳定性等，是自动化与生俱来的优势；但我们在实现的过程中遇到下面几个问题：

第一个问题，涉及面广：数据库的运维操作不仅是对数据库本身做一些操作，还要在服务器层面上做一些配置，此外还要对接其他系统，如监控、虚拟IP、高可用等，基本涉及到各个层面上的操作。

第二个问题，操作多样：对数据库的运维操作有很多，而且彼此差异很大。比如说：数据库初始化，操作步骤多，执行时间长；MySQL改表，操作步骤相对简单，但执行时间有时很短，有时非常长；MySQL建表，操作步骤简单，执行时间很短。如何平衡衔接好这些自动化的执行，还要保证高速路不塞车，这就是一个需要考究的问题。

第三个问题，日志显示：要想实时显示出日志，就要实时捕获日志，而且还要实时显示在Web页面上，就需要一套消息推送机制，保证整个流程最后一环的用户体验。

上面就是平台上自动化需要解决的问题，我们原先是想用Ansible来处理，相中它主要是因为其轻量的特点，因为数据库对性能要求很高，我们不想再部署agent来占用系统宝贵资源，同时部署agent本身也是成本较高的事情。但经过研究发现Ansible并不能完全满足我们对自动化操作的要求，它对服务器层面的操作很擅长，但其他的操作可能就需要自己写脚本或插件来实现，而且还要获取它的日志输出给Web服务，这势必要在其外面再加一层，于是我们选了Celery，就行成了平台自动化的基本架构:

上面就是我们对整个自动化架构的设想，整个架构以Celery作为整个自动化的核心任务调度系统，Ansbile最后成为其中的一个子任务类型。完整的自动化处理流程如下：

任务下发平台发出一个自动化任务到Celery的管理服务(CeleryMain)中，这部分是用Flower作了Celery的服务封装。Celery Main会生成一个任务，并将此任务放到对应的Redis任务队列中，同时返回给平台对应的任务号，平台拿这个任务号跳转到任务显示页面。任务显示页面会启动Websocket与平台的Web服务建立一个长连接，等待服务返回任务日志进行展示。主任务分解Celery Worker与Redis上自己对应的任务队列建立一个消息管道，当有任务进入队列后，就会立即接收并开始执行对应的任务。这时运行的任务，我们称之为主任务。主任务不做具体的自动化操作，它的工作是根据程序编排好的逻辑对任务进行分解，然后将分解的子任务串成任务链。子任务会一个接一个的串行执行，如果其中任何一个执行失败，则整个任务链中断执行，整个任务失败。运行子任务子任务和主任务一样也是通过Redis的消息队列传递给CeleryWorker。但子任务是执行具体自动化操作的。其中分为三类：Ansible类子任务——这类子任务是通过执行Ansible的Playbook来对服务器进行配置操作；DB类子任务——这类子任务是通过Python中对应数据库的连接驱动库，直接连上数据库执行数据库操作；Http类子任务——这类子任务是通过Python的Http库，调用第三方业务系统的http接口，来做相关业务操作。子任务执行结束后，会将执行日志传递给平台Web服务。日志显示平台Web服务在接收到自动化任务执行日志后，会以时间轴的方式展示出来。输出日志的粒度是子任务，也就是子任务执行完后，才会显示出来，可能有的子任务执行时间比较长，等待的时间可能会久一些。严格来讲这只能算是准实时，要想做到真实时日志显示，成本会高很多，目前这种准实时方案，目前是可以满足需求的。

智能化探索

服务器智能优选

服务器智能优选针对的是数据库集群初始化场景，上线自动化部署后，集群初始化的运维操作被大大简化，但在自动化执行前需要DBA提供部署的服务器列表，而目前服务器数量多达上千台，所以人工来筛选服务器成为了一个高成本的操作，最后只能做局部最优解。

针对此问题，我们并没有使用通过业务类型的划分来做为选择服务器的标准，因为58的服务器是混部部署。我们采取的策略是让DBA教AI来选服务器，也就是机器学习中的监督学习。由于没有数据方面的积累，我们采用在线学习，通过在平台中埋点，实时生成训练数据进行训练，不过这需要一定时间的积累，刚开始的效果不是很理想。但在上线跑了大概一个多月，训练了不到一千套集群的数据后，已经可以辅助DBA来选择全局最优的服务器了。

上图中推荐度部分就是机器学习给出的参考值，从图上中可以看到给出的分值对Redis的实例数和内存这两个指标有了很好的权衡，符合我们之前的预期。

告警智能合并

告警是每个运维人员工作过程中很重要的一部分，针对告警我们做了一些优化工作，其中最主要就是告警的智能合并功能。合并后的告警内容仅更加清晰，关联性更强，而且对于短信风暴也能起到一定的预防作用。

上面就是告警内容在改进前后的对比，其中告警合并的核心算法是用无监督学习算法中的层次聚类实现的。层次聚类算法能够给出数据在每个维度上的相似度。那么核心问题是如何从一堆相似度中进行分组呢？我们的算法是，如果两个向量相似，向量的夹角和距离都应该较小，那就将小于其平均值的划为一组。

还有一个问题是，一个数据可能隶属于多个维度中的不同分组，那这样的数据该如何分组？我们的原则是最大分组原则，优先将在多个维度下有相同的数据划分为一组，然后再对剩下的数据按此原则进行分组，直到数据都被划分了分组为止。

最后就可以根据分组的相似维度选取对应的告警内容模板，渲染出告警内容。

总结

本文只是58云DB平台在自动化、智能化运维建设过程的一些小总结，实际上58云DB平台已经整合实现了MySQL、Redis以及MongoDB数据库运维管理的多个功能模块，比如高可用管理、监控系统、备份系统、一键运维管理等各个子系统。目前我们平台的各个功能仍然在快速迭代中，在未来将会探索更多的用户自助管理和智能化运维功能，欢迎感兴趣的同学和我们一起交流。