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

从自动化到智能化运维过渡时，美团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平台操作日志和应用端发布记录等等。

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