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

头图.jpeg

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

背景

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

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

数据库平台的演变

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

image

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

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

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

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

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

现状和面临的挑战

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

image

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

挑战一：RootCause定位难

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

image

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

挑战二：人力和发展困境

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

image

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

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

image

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

从自动化到智能化

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

作者：美团技术团队
链接：https://www.jianshu.com/p/257fdabd968d