数据库智能运维探索与实践

从自动化到智能化运维过渡时，美团DBA团队进行了哪些思考、探索与实践？本文根据赵应钢在“第九届中国数据库技术大会”上的演讲内容整理而成，部份内容有更新。

背景

近些年，传统的数据库运维方式已经愈来愈难于知足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大，各类NewSQL系统上线使用，运维逐渐跟不上业务发展，各类矛盾暴露的更加明显。在业务的驱动下，美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅，也开始了智能运维在数据库领域的思考和实践。

本文将介绍美团点评整个数据库平台的演进历史，以及咱们当前的状况和面临的一些挑战，最后分享一下咱们从自动化到智能化运维过渡时，所进行的思考、探索与实践。

数据库平台的演变

咱们数据库平台的演进大概经历了五个大的阶段：

第一个是脚本化阶段，这个阶段，咱们人少，集群少，服务流量也比较小，脚本化的模式足以支撑整个服务。

第二个是工具化阶段，咱们把一些脚本包装成工具，围绕CMDB管理资产和服务，并完善了监控系统。这时，咱们的工具箱也逐渐丰富起来，包括DDL变动工具、SQL Review工具、慢查询采集分析工具和备份闪回工具等等。

第三个是产品化阶段，工具化阶段可能仍是单个的工具，可是在完成一些复杂操做时，就须要把这些工具组装起来造成一个产品。固然，并非说这个产品必定要作成Web系统的形式，而是工具组装起来造成一套流程以后，就能够保证全部DBA的操做行为，对流程的理解以及对线上的影响都是一致的。咱们会在易用性和安全性层面不断进行打磨。而工具产品化的主要受益者是DBA，其定位是提高运维服务的效率，减小事故的发生，并方便进行快速统一的迭代。

第四个是打造私有云平台阶段，随着美团点评业务的高速发展，仅靠十几、二十个DBA愈来愈难以知足业务发展的须要。因此咱们就把某些平常操做开放受权，让开发人员自助去作，将DBA从繁琐的操做中解放出来。当时整个平台天天执行300屡次改表操做；自助查询超过1万次；自助申请帐号、受权并调整监控；自助定义敏感数据并受权给业务方管理员自助审批和管理；自定义业务的高峰和低峰时间段等等；自助下载、查询日志等等。

第五个是自动化阶段，对这个阶段的理解，实际上是“仁者见仁，智者见智”。大多数人理解的自动化，只是经过Web平台来执行某些操做，但咱们认为这只是半自动化，所谓的自动化应该是彻底不须要人参与。目前，咱们不少操做都还处于半自动化阶段，下一个阶段咱们须要从半自动过渡到全自动。以MySQL系统为例，从运维角度看包括主从的高可用、服务过载的自我保护、容量自动诊断与评估以及集群的自动扩缩容等等。

现状和面临的挑战

下图是咱们平台的现状，以关系数据库RDS平台为例，其中集成了不少管理的功能，例如主从的高可用、MGW的管理、DNS的变动、备份系统、升级流程、流量分配和切换系统、帐号管理、数据归档、服务与资产的流转系统等等。

并且咱们按照逻辑对平台设计进行了划分，例如以用户维度划分的RDS自助平台，DBA管理平台和测试环境管理平台；以功能维度划分的运维、运营和监控；以存储类型为维度划分的关系型数据库MySQL、分布式KV缓存、分布式KV存储，以及正在建设中的NewSQL数据库平台等等。将来，咱们但愿打形成“MySQL+NoSQL+NewSQL，存储+缓存的一站式服务平台”。

挑战一：RootCause定位难

即使咱们打造了一个很强大的平台，但仍是发现有不少问题难以搞定。第一个就是故障定位，若是是简单的故障，咱们有相似天网、雷达这样的系统去发现和定位。可是若是故障发生在数据库内部，那就须要专业的数据库知识，去定位和查明究竟是什么缘由致使了故障。

一般来说，故障的轨迹是一个链，但也多是一个“多米诺骨牌”的连环。可能由于一些缘由致使SQL执行变慢，引发链接数的增加，进而致使业务超时，而业务超时又会引起业务不断重试，结果会产生更多的问题。当咱们收到一个报警时，可能已通过了30秒甚至更长时间，DBA再去查看时，已经错过了最佳的事故处理时机。因此，咱们要在故障发生以后，制定一些应对策略，例如快速切换主库、自动屏蔽下线问题从库等等。除此以外，还有一个比较难的问题，就是如何避免类似的故障再次出现。

挑战二：人力和发展困境

第二个挑战是人力和发展的困境，当服务流量成倍增加时，其成本并非以相同的速度对应增加的。当业务逻辑愈来愈复杂时，每增长一块钱的营收，其后面对应的数据库QPS多是2倍甚至5倍，业务逻辑越复杂，服务支撑的难度越大。另外，传统的关系型数据库在容量、延时、响应时间以及数据量等方面很容易达到瓶颈，这就须要咱们不断拆分集群，同时开发诉求也多种多样，当咱们尝试使用平台化的思想去解决问题时，还要充分思考如何知足研发人员多样化的需求。

人力困境这一问题，从DBA的角度来讲，时间被严重的碎片化，自身的成长就会遇到瓶颈，好比常常会作一些枯燥的重复操做；另外，业务咨询量暴增，尽管咱们已经在尝试平台化的方法，可是仍是跟不上业务发展的速度。还有一个就是专业的DBA愈来愈匮乏，愈来愈贵，关键是根本招聘不到人手。

在这种背景下，咱们必须去思考：如何突破困局？如何朝着智能化转型？传统运维苦在哪里？智能化运维又能解决哪些问题？

首先从故障产生的缘由来讲，传统运维是故障触发，而智能运维是隐患驱动。换句话来讲，智能运维不用报警，经过看报表就能知道可能要出事了，可以把故障消灭在“萌芽”阶段；第二，传统运维是被动接受，而智能运维是主动出击。但主动出击不必定是经过DBA去作，多是系统或者机器人操做；第三，传统运维是由DBA发起和解决的，而智能运维是系统发起、RD自助；第四，传统运维属于“人肉救火”，而智能运维属于“智能决策执行”；最后一点，传统运维须要DBA亲临事故现场，而智能运维DBA只须要“隐身幕后”。

从自动化到智能化

那么，如何从半自动化过渡到自动化，进而发展到智能化运维呢？在这个过程当中，咱们会面临哪些痛点呢?

咱们的目标是为整个公司的业务系统提供高效、稳定、快速的存储服务，这也是DBA存在的价值。业务并不关心后面是MySQL仍是NoSQL，只关心数据是否没丢，服务是否可用，出了问题以后多长时间可以恢复等等。因此咱们尽量作到把这些东西对开发人员透明化，提供稳定高效快速的服务。而站在公司的角度，就是在有限的资源下，提高效率，下降成本，尽量长远地解决问题。

上图是传统运维和智能运维的特色分析，左边属于传统运维，右边属于智能运维。传统运维在采集这一块作的不够，因此它没有太多的数据可供参考，其分析和预警能力是比较弱的。而智能运维恰好是反过来，重采集，不少功夫都在平时作了，包括分析、预警和执行，智能分析并推送关键报表。

而咱们的目标，是让智能运维中的“报警+分析+执行”的比重占据的愈来愈少。

决策执行如何去作呢？咱们都知道，预警重要但不紧急，但报警是紧急且重要的，若是你不可以及时去处理的话，事态可能会扩大，甚至会给公司带来直接的经济损失。

预警一般表明咱们已经定位了一个问题，它的决策思路是很是清晰的，可使用基于规则或AI的方式去解决，相对难度更小一些。而报警依赖于现场的链路分析，变量多、路径长，因此决策难，间接致使任何决策的风险可能都变大。因此说咱们的策略就是全面的采集数据，而后增多预警，率先实现预警发现和处理的智能化。就像咱们既有步枪，也有手枪和刺刀，能远距离解决敌人的，就尽可能不要短兵相接、肉搏上阵。

数据采集，从数据库角度来讲，咱们产生的数据分红四块，Global Status、Variable，Processlist、InnoDB Status，Slow、Error、General Log和Binlog；从应用侧来讲，包含端到端成功率、响应时间95线、99线、错误日志和吞吐量；从系统层面，支持秒级采样、操做系统各项指标；从变动侧来看，包含集群拓扑调整、在线DDL、DML变动、DB平台操做日志和应用端发布记录等等。

数据分析，首先是围绕集群分析，接着是实例、库，最后是表，其中每一个对象均可以在多项指标上同比和环比，具体对比项可参考上图。

经过上面的步骤，咱们基本能够得到数据库的画像，而且帮助咱们从总体上作资源规划和服务治理。例如，有些集群实例数特别多且有继续增长的趋势，那么服务器须要scale up；读增长迅猛，读写比变大，那么应考虑存储KV化；利用率和分布状况会影响到服务器采购和预算制定；哪几类报警最多，就专项治理，各个击破。

从局部来讲，咱们根据分析到的一些数据，能够作一个集群的健康体检，例如数据库的某些指标是否超标、如何作调整等等。

数据库预警，经过分析去发现隐患，把报警转化为预警。上图是咱们实际状况下的报警统计分析结果，其中主从延迟占比最大。假设load.1minPerCPU比较高，咱们怎么去解决？那么，可能须要采购CPU单核性能更高的机器，而不是采用更多的核心。再好比说磁盘空间，当咱们发现3T的磁盘空间广泛不够时，咱们下次能够采购6T或更大空间的磁盘。

针对空间预警问题，何时须要拆分集群？MySQL数据库里，拆分或迁移数据库，花费的时间可能会好久。因此须要评估当前集群，按目前的增加速度还能支撑多长时间，进而反推什么时候要开始拆分、扩容等操做。

针对慢查询的预警问题，咱们会统计红黑榜，上图是统计数据，也有利用率和出轨率的数据。假设这是一个金融事业群的数据库，假设有业务须要访问且是直连，那么这时就会产生几个问题：第一个，有没有数据全部者的受权；第二个，若是不经过服务化方式或者接口，发生故障时，它可能会致使整个金融的数据库挂，如何进行降级？因此，咱们会去统计出轨率跟慢查询，若是某数据库正被以一种非法的方式访问，那么咱们就会扫描出来，再去进行服务治理。

从运维的层面来讲，咱们作了故障快速转移，包括自动生成配置文件，自动判断是否启用监控，切换后自动重写配置，以及从库可自动恢复上线等等。

报警自动处理，目前来讲大部分的处理工做仍是基于规则，在大背景下拟定规则，触发以后，按照知足的前提条件触发动做，随着库的规则定义的逐渐完善和丰富，能够逐步解决不少简单的问题，这部分就再也不须要人的参与。

展望

将来咱们还会作一个故障诊断平台，相似于“扁鹊”，实现日志的采集、入库和分析，同时提供接口，供全链路的故障定位和分析、服务化治理。

展望智能运维，应该是在自动化和智能化上交叠演进，在ABC（AI、Big Data、Cloud Computing）三个方向上深刻融合。在数据库领域，NoSQL和SQL界限正变得模糊，软硬结合、存储计算分离架构也被愈来愈多的应用，智能运维正当其时，咱们也面临更多新的挑战。咱们的目标是，但愿经过DB平台的不断建设加固，平台能本身发现问题，自动定位问题，并智能的解决问题。

做者简介

应钢，美团点评研究员，数据库专家。曾就任于百度、新浪、去哪儿网等，10年数据库自动化运维开发、数据库性能优化、大规模数据库集群技术保障和架构优化经验。精通主流的SQL与NoSQL系统，现专一于公司业务在NewSQL领域的创新和落地。