【IT168 评论】本文根据赵应钢2018年5月11日在【第九届中国数据库技术大会】上的演讲内容整理而成。

　　讲师介绍：

　　赵应钢，曾就职于百度、新浪、去哪儿网等，10年数据库自动化运维开发、数据库性能优化、大规模数据库集群技术保障和架构优化经验。现为美团点评运维研究员，DBA团队(北京)负责人，负责MySQL、KV服务的平台建设和技术保障工作。

　　演讲大纲：

　　● 数据库平台的演变;

　　● 现状和面临的挑战;

　　● 从自动化到智能化;

　　文章摘要：

　　传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大，各种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，存储+缓存的一站式服务平台。

　　即使有了这个系统，但我们还是发现有很多问题难以搞定。第一个就是故障定位，如果是简单的故障有类似天网、雷达这样的系统去发现和定位。但是如果故障发生在数据库内部，就需要专业的数据库知识去定位和查明到底是什么原因导致了故障。

　　通常来说，故障的轨迹是一个链式的，但也可能是一个多米诺骨牌的连环。可能因为一些原因导致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平台的不断建设加固，平台能自己发现问题，自动定位问题，并智能的解决问题。谢谢大家。