网易数据库运维自动化演进与 AIOps 探索

Posted 2021-04-24 高效运维

作者简介

倪山三

网易数据库运维专家

对于数据库来说分为四个阶段，首先介绍一下数据库自动化平台需求和功能设计目标。然后介绍一下网易的实践经验，最后介绍一下 AIOps 数据库平台的主要关系。

一、数据库自动化平台需求和功能设计目标

数据库平台的功能和需求出发点是非常类似的，在各个厂家之间，DBA 面临很多困难都相同。数据库与运维平台建设到最后架构设计、方案设计都有相似的地方，今天主要介绍一下网易内部技术实现和技术选型。

首先看一下DBA工作中的难点。

第一是我们线上运维环境的服务量是相当的庞大的，它的环境相当的复杂，拿网易内部来说，我们有 3000 家的服务和集群，这是数量上的庞大，它的技术特点也相当于有一些复杂性，包括分布式数据库地区。以及这些数据库分布物理机、私有云。业务库需要涉及多地、多机方、多地多活的架构。

第二，除了数量和复杂性之外，DBA 在企业当中数量不是特别多，DBA 会面临很多的业务和开发的同学。因此 DBA 在工作中对接产品和数量工作量有很大的压力，需要有系统来辅助。

第三，是 DBA 的工作种类和内容相当的繁多。不知道大家是不是都是 DBA 同学，看到这些工作都很熟悉，部署、变更、权限、调数、导出导入、备份、扩容、迁移、升级和排障。

DBA 这边技术是有自己的多样性和复杂度在里面。最后一点是 DBA 工作职责非常重大，数据是信息企业、互联网企业生命的生命线。数据库的运维工程师也是专业程度非常高的职位。

DBA它的职责重大包括两方面，它维护服务重要性非常高，数据库出现了严重的问题，对整个服务和站点的影响是致命的。第二点，由于数据库是有状态和有数据的，数据库做正常的线上操作，很有可能造成IO、吞吐量的稳定性，造成了一些人为的故障，所以说它是风险敏感度很高的。

为了应对这样的局面，我们数据库平台设计主要有这些方面设计的目标，首先提高自动化率，这是最基本的目标。自动化率不但帮助 DBA 简单操作，更帮助 DBA 在大数据环境下实现难度比较大的操作，或者对 256 个节点的集群进行串型的重启来获取内存碎片。

看到操作的量级对人手工来说非常难做到，并且做到操作过程中的规范细节，人类很难保证是可以正确做下去的。因此，自动化运维平台帮助 DBA 完成人力难以操作的，并且帮助我们提高在机械操作的规范性和细致程度，避免人的不确定因素造成线上的故障。

同时第二点，我们 DBA 平台希望统一和落实技术方案，也就是公司内所有数据库主层架构、机房分布、数据导出导入的方案。如果不统一的话，包括架构变化和技术调整，我们中间有差异性的东西很难做交界和规范化。

下一个是提高流程和规范效率，我们希望一个 DBA 面向好几十个开发同学，希望能从容应对工作和沟通。

环境流程规划这一点也是很容易被忽视，我们一个数据库上线之后必须要有监控报警，我们一个礼拜部署240个节点，这十个是非常重要的，出去问题怎么怎么办？流程规范化也是非常核心的功能。

最后一点就是提升，这是我们演进过程中逐渐加进去的功能，提升DBA对全局的掌控能力。当我们运维十个数据库、一百个数据库里，你在脑海里会聚一个 Top 图，当一万多个、四万多个数据库的时候你如何全局的东西？这也是全局应该做的东西。

这里分为三个大模块，我个人认为是必须具备的标红了，企业公司要运转起来你的数据库运维必须具备这样的功能，也是我们必须要做的。后面是我们添加进去的功能帮我们更好去运维，这后面都会去讲。

二、工具化运维阶段

第二个我们讲一讲看网易如何做的，自动化运维都是相同的过程，首先是人力运维、搅拌运维、百皮运维，然后再是 AIOps 和 DevOps，实际上网易这部分做的比较滞后，我们到2014年、2017年还是用半自动、脚本化去做运维，标红的功能我们当时怎么做的？利用什么样选型做的？我们有自己的CMDB，也就是原数据管理，但是它全靠手工录入的。

这边写的脚跟都会用 fabric 的框架，这是处理的框架。因为我们数据库很早以前有一个非常历史久远的 CMDB，我们要做结构变更的时候是所有的节点一起变更的，我们的操作都是分布式的操作，因此我们分布式不可能去编程去做。所以 fabric 会有很多。

高可用切换也是 MHA 的方案，由于 MHA 的部署，MHA 是异定义的状态。慢日志收集也很重要，本质就是 cron 查找上的机制，所以这一块显得非常重要。

我们慢日志分析都是框脚本，然后用 Query-digest 去做报警和处理。数据导入和导出工具我们用 DataX，它可以做数据传出。我们从文本导入都是从 DataX 在做。同时 DataX 也是做数据 ETL 的主要工具。

我们看实际上几个最核心的关键点，数据库运维工具非常丰富。我们在数据库运维的各个环节已经有很靠谱的开源方案解决这些问题，工具方案也就是上层做一些管理、控制、分发的脚本去做。

在服务规模小，这件事不多的情况下完全是够用的，数据库一条龙的服务，开源一定能够找到合适的方案。但是这样的东西随着业务的发展，也逐渐遇到了很多瓶颈，这些瓶颈是促使我们去在现在这个基础上做进一步的提升，做平台化、自动化。

什么问题呢？工作量太大，大到什么程度？我们一天比较忙的时候有500单数据库变更的请求。每个工单涉及十个表、几十个库的变更。我们当时最夸张的时候一个业务线DBA 对接开发人员是 200 个，不但的业务压力即使调参数也很难忙过来，沟通效率其实是很低的，就跟数据库里是一样的。

我们另外一方面，我们的 zabbix 也好，MHA它遇到很多这样的瓶颈，Zabbix 它的性能也是比较垢病的地方，但不是说不能结构，我们有方案，复杂性会比较高一些，高到我们可以再写一套监控系统。

MHA呢？随着我们机器越来越好，单机的时候MHA怎么办？其他的一些问题，VIP不能跨机房，其他的原因就是MHA基于MHA，使我们MHA也不是那么的方便了，这也就必须要靠技术手段突破改变我们的工具符合我们的需求。

另外一方面由于人的一些确实或者操作不规范引发的问题。我刚才说过我们上线的服务忘配监控了怎么办？在线上做了变更怎么办？我们经常会遇到这样的问题。

我们网易是在2016年开始运维部组建了自己的开发团队，然后专门去做运营基础设施，由于 DBA 是有自己特殊性的，也就是专业程度比较高，我们的一些运维平台都是自己开发的，我们 DBA 也是基于自己开发设施，所以我们取名叫 OWL。

最初建设目标 就要是改良工具、解决技术瓶颈。我们谈一下自动开发的运维平台主要的架构。这是我们运维平台大致技术的架构。大家可以看一下我们这里有三层模块。第一个是前端模块，我们会把各种DBA分到开发种类，比如说前端比较好的DBA我们会做前端开发。

三、打造DBA自动化运维平台

对数据库比较了解、工具脚本比较熟悉的同学会做自动化开发。最终基于 CMDB 做了自动维护的报警去做 DBA 自动化平台。前台分为 DBA 管理平台和用户工单系统，再加上用户查询数据的 Web 的平台。

然后CMDB有这样的流程，DBA通过我们的管理平台自动化部署数据系统，部署完的系统会对原数据管理模块收到原数据管理中，然后添加到 DBA 管理中，这样不会有报警确实、原数据漏洞。

这一块DBA我们会提供一些指导，我们的各种模块去对线上的数据库进行管理和掌控。开发同学的话通过工单系统去提交正规的任务，经过一系列检查之后由自动化变更去操作，这样不需要由开发去进行线上变更，以及自主的变更。

我们先谈到运维开发部的同学，开发最重要的基础设施就是我们的运维基础工具。监控系统的话我们网易内部叫哨兵，它是非常轻服务端的，服务端只有配置和下发，本地是通过 Kafka，它的 Kafka 会存储到 HBASE 里，会被我们的模块去做历史归档和逻辑算法。

这个系统对我们来最重要的三点，第一点它的 HBASE 吞吐量非常好，我们在 TSDB 时代不敢有这么多的报警数据接受。

第二点我们网络环境相对比较复杂，我们机房有上海、杭州、北京、广州等，很多机房网络有平台出现，它做各种各样的代理服务器方式做周转，这样通过同一个系统做操作。

另外一点报警的维护自动化程度非常高，是按照我们要求设计的，我们可以通过一些接口调用增加修改和监控和报警，这也比 zabbix 好用得多。

我们还有一个运维客户端，我们的监控肯定是要有客户端，我们客户端对我们来说有几个非常重要的意义。客户端在本地维护了集中配置的nagent，我们这个系统就是客户端做的。第二点，这个客户端可以做实时操作，可以把数据通过各种方式反馈给我，也可以帮我数据塞到Kafka。

我们在网易内部SSA的要求，我们完全靠这个客户端来替代SSH。我们同步调目标服务器的运维客户端，它传输非常简单的指令，也就是STA服务器上把我实际的脚本下载下来，然后再去调曲复杂脚本，我们都是这样去做运维操作的调用。

有了这样的工具之后，实际上我们很容易去做一些可靠CMDB是自动化运维的根本前提，CMDB如何可靠？它可靠的前提是必须全自动。

如何全自动？我们每个服务器上都有了一个定时任务，也就是一刻不停的扫描本地有没有一些其他的因素，这里任何数据库相关的服务都会把所有信息上报上来，不管是手动部署、私有云部署、Data部署都会收集上来，收集上来以后呢，DBA会把数据上报上来，上报上来一方面写入CMDB，这样保证所有原数据的采集和报警添加是完全自动化的。

我们原数据分为三部分维护，第一部分是自动上报，我们会去找出自动采集服务的物理信息，比如说版本、启动时间、数据存放的路径等物理信息，通过我们的工单系统和自动化平台推动，会获取业务信息，谁申请的数据库？谁去部署数据库？在哪个租户下？DBA会维护它相关的运位信息，我的数据库重要性等级以及该什么级别去报警。

这三个数据合在一起基本上就能保证原数据的有效性和它的准确性。我们在原数据库上，单个数据库采集上来的数据只是体现一台服务器的事实，我们数据库是集群化和业务关联的，数据库是主从、数据库是集群以及多维度的不同信息和架构信息。

我们单个数据库收集上来之后我们还会从Web系统捞取不同的信息，我们会捞取域名 ，最终的效果来说这个东西实际上看似不是特别好看，这是面向维护上千分布式系统，大家有没有感觉到维护一百个集群的时候有一主多从的关系？一个报警过来，这个报警的IP是主还是从？到底是谁的业务模块？这一行都是我们的主节点。

它后面是等价同一级的从节点，在从下面两还有两个节点从，我们会把整个数据库这几组之间都是水平分布的集群关系。我可以在一个方面告诉DBA这个集群之间的一主多从的健康程度，然后告诉哪个节点是组成了业务集成，然后告诉DBA这一层级的节点在哪个机房。

我们是自动维护嘛，我们可以了解到出问题是什么样的节点，这个其实真的有用，也就是主从的Top信息维护。后面监控报警的管理实际上是比较简单的事情，无非就是做好模板，我们不是在一张大平面图里列举出几千个数据库实例，我们会把数据库细分每个产品和数据线，然后关键是报警模板的系统化。

我们数据库并不是一视同仁，实际上我们会根据DBA维护也好、智能判断也好，去把不同等级的模板添加到数据库中去。而且数据库不知道是谁的时候，默认会提到比较高的等级。备份没什么可说的，每天参与数量都在三到四千，产生的备份量都是上百T。NFS它并不是很好的集群，为了这一点我们要用HDFS也好、其他存储也好，必须大池。

我们内部的话，实际上也是用HDFS，我们还用了网易内部的对象存储叫OS，比如说音乐、歌曲、视频以及商品的图片，新闻、图片存储的对象存储，我们内部也部署了一套专门传我们备份，我们的备份也是支持mydumper。

还有很关键的一点就是我们每天有几千个实例备份。我们定期会去做一些抽样恢复的测试。我们大概五分之一的量去备好之后恢复出来，因为不能保证备份百分之百的成功，这样会做定期还原的测试，来保证备份的效率。

慢查询的处理，这有两个阶段，我们后面智能化运维会提一个新的阶段。业务不提怎么办，业务用的DIO模板很乱，我们只能靠线上抓取及时反馈。我们先会调十毫秒左右的水平。这些慢查询分析模块会有些配置去做任务。

它把数据库上面下载以及上传的脚本。下载下来会把日志截断，我们RDS小的虚拟机上会处理Flush，关键是大家知道我们提到两点，我们把慢查询调的比较低，线上一定会有慢查询，我调到十毫秒很正常。怎么区分有风险和没问题的呢？

所有进入慢查询的数据资料，它的会有ID嘛，我们根据总的聚合，按天和按小时的聚合，之后再有查询都会到我们的聚合库做分析，我们会去找真正需要关心的，历时上第一次出现的慢查询，它的频率比昨天增加的慢查询，他的昨天增加、上期同期增加的慢查询，我们会做周同比分析，也会做天的环比分析。还有小时时间段内新出现，这边可能是业务的调整和用户行为以及新上线的活动在造成的波动。

这边VIP很多的弊端嘛，我们靠ZK集群的作用都是配置的下发。然后我们的服务Watch到之后会去投票和协调高可用的地方。比如说ZK节点消失之后来做的。还有比较完善的系统面向用户查询系统，这块主要是安全性和方便性。

我们查询平台是支持多种数据库的查询，用户访问很多数据库，第一他不会太用命令行的客户端，所以我们做了统一访问，这个访问做了很多的限制，比如说仅用特定用户。改斜所有的它限制每一次查询的行数，这样避免内部突破。

每人每天都有上线，所有查询都有很详细的统计，这一块会有大量的报表。我们数据库自动化扩容怎么做呢？网易内部叫NDZ，我们无非部署一个新集群，数据从老集群同步新集群，历史数据传输都好做用和就好了，我们用的是开源的，这个大家用的不是特别多，我们研究还是蛮多年的，这一块架构方面是比较完善的。

这套系统的话，实际上也除了做数据同步迁移之外，因为好用嘛，实际上也成为了网易内部数据总线的服务，不仅做集群间的服务，也把数据塞到Kafka数据消费。

变更是我们线上比较重要的系统，但是没什么特别好说的事情，从去年开始我们改成了gh-ost，它的侵略性小很多，gh-ost有同样的等级，解析回放跟不上。我们CMDB改造引入了gh-ost之外我们维护每个产品的时间窗，然后维护风险的域值，并且实时把数据中断。

我们业务流程这一块改造，我们说过了每天有几百个变更的工单，这一块变更工单里，哪怕是DVG点一个都点不过来，我们保证我们的变更系统能够判断风险，完全把业务开放出来自己来做。

把语法检查你的对不对？语意合规检查，你把一个两个BDR写了两个里面？然后经过业务审批人的审批，CMDB 判断一下这个库是否允许去做自动变更，线上的话70%以上的库是允许完全自主的，这样把DB工作量下降。

这里做了很多详细的检查，语意检查不提了，语法检查大家做过这个东西非常头大，版本差异，有些稀奇古怪的语法，甚至我们分布式集群的特殊性语法都成为啊非常重要的点。

我们把目标库的版本和拿起来，我们在空库里把变更实际上都做一边，确定能跑出才能做。虽然非常粗暴。

最后的系统是巡检平台，我们维护上千个实例的时候如何找到实例值得关心的信息？这些平台会根据集群的维度统计数据库的容量，然后挑出其中有风险的情况。比如说数据量增长的非常快，昨天的负载情况比上期特别多，我们通过报表每天发送给我们，发送给业务，回顾这样的问题，检查这样的问题。

平台开发总结，总结自动化无非是流程控制、执行控制、工具使用，CMDB是整个核心的关键，CMDB是整个系统的关键，白瓶首先是规范化其次才是省力，最重要的一点就是开发的时候，DBA在开发的时候踩了很多的坑，模块之间都要模块化，通过APP调用。所有的接口保留API接口，能API化才能自动化。

四、网易 AIOps 探索与 DBA 平台

最后一部分就是网易 AIOps 的实践，我们还是比较务实的，我们主要是更新需求这一块，我们的系统由于模块化、微服务化的改造。

这是我们全局图的四分之一的图，小框就是这个屏幕，这个屏幕里有很多的模块，这样的情况下面一个模块出了一个点小问题，你会导致收到上万个报警，这时候靠传统孤岛式找出问题，你是不可能找出真正的问题的，我们实际上 AIOps 投入都是在寻找分析。

我们靠数据采集的完善，数据传输到 AIOps 之后再做相关的决策性分析找出模块，然后再去调用自动化的系统去做扩容、限流等问题。

绿颜色就是我们 AIOps 主要开发的场景，这个就是我们内部的分析模块，实际上根因定位加上根因模块发现加上故障定位，有了依赖图之后，依赖最底层发现问题的模块就是对应模块，这就是根因分析的结果。

知道是哪个模块出现问题故障定位也很难，我们知道是哪个模块出现了问题，这就是我们的运维数据、监控数据、智能化运维需要去解决的问题。这边我们 AIOps 是比较大的系统，讲讲我们跟数据库相关的。

数据库是有自己的特殊性，我们数据库体系很难融入到业务 AIOps 答题中，我们是合作的关系而不是包容的关系。比如说数据问题恢复手段特殊性，不能透过限流、分流。

给出的异常信息是什么原因造成的，能自愈的话怎么样自愈，这边可以告诉没关系我所有红色的线都是因为数据库的原因造成的，这就是数据的互通。数据库有些问题需要我们反馈给他们，这是我们不得不满对很现实的问题。或者数据库这边没有挂，业务还没有报出问题，这时候找不到原因的时候要把数据库的原因反推给业务，这是两点信息互通比较好的流程。

另外一点，刚才提到 AIOps 很重要的一点就是自愈，我们会自动化处理可自愈的故障，因为数据各种问题嘛，我们收到问题之后会把它对应的问题拿出来了，你不是我们就给放出去，因为是有前后项目的嘛。

你不是说我们就把删掉。另外一点刚才也提到我们线上遇到一些问题如何自愈？问题是线上90%故障的原因。我们业务开发了一个java agent的客户端，它把业务下发都打了一个标记。另外这个客户端是嵌入每个业务器的迭优层。

如果业务服务器过来了，我们通过我们的活跃性和监控也好，通过我们监控也好，找到问题。两种情况。如果说是新上线的小表，因为上线的时候审核不严没加，我们自动通过变更模块把它加了。

如果说由于业务变更，这些原因造成的问题，我们对线上核心不去做变更，我们会去通过 AIOps 平台去发出请求，AIOps 平台会判断合理性，然后把的去对应掉，这样会环节问题带来的风险。

未来也就是我们的尝试正在做，一个是服务报警治理，一个是智能客服。你一个业务是慢查讯，在这个情况下面，我们把服收敛，通过集群集合一下，把每个集群是因为什么原因的SQL，收敛完之后再去做报警有效性的检查，我们看这个是不是在这个时间和这个业务上来跑？

我们这个东西还没有完全做好，现在一直在努力做的过程中。另外就是智能客服，我们希望通过人工智能问答的方式来进行查询，这个其实难度相对来说是最高的，我们在寻求网易内部的应用。

AIOps 已来

还没有实践 AIOps 的朋友，不妨抓紧机会~

4.12-13 GOPS全球运维大会 2019 · 深圳站

AIOps 行业案例专场、AIOps 场景实践专场、AIOps 解决方案专场，场场精彩！

或点击阅读原文订票

点击阅读原文，访问 GOPS 官网