在从自动化向智能运维转型的过程中，美团DBA团队进行了哪些思考、探索和实践？》网站演讲内容整理，部分内容已更新。背景近年来，传统的数据库运维方式越来越难以满足业务对数据库稳定性、可用性、灵活性的要求。随着数据库规模快速膨胀，各种NewSQL系统上线，运维逐渐跟不上业务发展，各种矛盾暴露得更加明显。在业务驱动下，美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型历程，也开始在数据库领域思考和实践智能运维，本文将介绍整个运维的演进史美团点评的数据库平台，以及我们的现状和我们面临的一些挑战，最后分享我们从自动化向智能运维转型的思考、探索和实践。数据库平台的演进我们数据库平台的演进大概经历了五个大的阶段：第一个是脚本阶段。这个阶段我们人少，集群少，服务流量也比较小。脚本模型足以支持整个服务。二是模具阶段。我们将一些脚本打包成工具，围绕CMDB管理资产和服务，完善监控系统。这时候，我们的工具箱逐渐丰富起来，包括DDL变更工具、SQLReview工具、慢查询收集分析工具、备份闪回工具等等。三是产品化阶段。仪表阶段可能仍然是单个工具，但是当完成一些复杂的操作时，需要将这些工具组装起来形成一个产品。当然，这并不是说这个产品一定要做成web系统，而是把工具组装成一套流程后，可以保证所有的DBA都以同样的方式操作，了解流程，并且有对线路的影响相同。.我们将在易用性和安全性方面继续打磨。工具产品化的主要受益者是DBA，其定位是提升运维服务效率，减少事故，便于快速统一迭代。四是私有云平台建设阶段。随着美团点评业务的快速发展，仅靠十几二十个DBA越来越难以满足业务发展的需求。所以我们把一些日常的操作开放授权，让开发者自己去做，把DBA从繁琐的操作中解放出来。当时整个平台每天要进行300多次表修改操作；自助查询超过10000次；自助账户申请、授权和调整监控；自助定义敏感数据，授权业务管理员自行审批和管理；自定义业务高峰和低峰时间等；自助下载、查询日志等五是自动化阶段。这个阶段的认识其实就是“仁者见仁智者见智”。大多数人理解的自动化是通过网络平台进行某些操作，但我们认为这只是半自动化，所谓的自动化应该是完全不需要人参与的。目前我们很多作业还处于半自动阶段，下阶段需要从半自动过渡到全自动。以MySQL系统为例，从运维的角度，包括主从高可用、服务过载自我保护、容量自动诊断评估、集群自动扩缩容等.CurrentStatusandChallenges下图展示了我们平台的现状。以关系型数据库RDS平台为例，集成了主从高可用、MGW管理、DNS变更、备份系统、升级流程、流量分配与切换系统、账号管理、数据归档等管理功能、服务和资产流转系统等。此外，我们在平台设计上进行了逻辑划分，如按用户维度划分的RDS自助服务平台、DBA管理平台、测试环境管理平台；运维、运维和监控按功能维度划分；按存储类型划分的关系类型数据库MySQL、分布式KV缓存、分布式KV存储、正在建设的NewSQL数据库平台等，未来希望打造“MySQL+NoSQL+NewSQL，一站式服务平台”用于存储+缓存”。挑战一：RootCause难以定位即使我们搭建了一个非常强大的平台，我们仍然发现有很多问题难以解决。首先是故障定位。如果是简单故障，我们有天网、雷达等系统可以发现定位。但如果故障发生在数据库内部，则需要专业的数据库知识来定位并找出故障原因。一般来说，断层的运动轨迹是一条链条，但也可能是一连串的“多米诺骨牌”。由于某些原因，SQL的执行可能会变慢，导致连接数增加，进而导致业务超时，而业务超时又会导致业务不断重试，从而产生更多的问题。当我们接到报警的时候，可能已经过去了30秒或者更长时间，当DBA再次检查的时候，已经错过了处理事故的最佳时机。因此，我们需要在出现故障后制定一些应对措施，比如快速切换主库，自动屏蔽离线问题从库等等。除此之外，还有一个比较棘手的问题，就是如何避免类似的故障再次发生。挑战二：人力与发展的困境第二个挑战是人力与发展的困境。当业务流量翻倍时，其成本不会以相同的速度增加。当业务逻辑越来越复杂时，每增加一元收入，其背后对应数据库的QPS可能会翻倍甚至五倍。业务逻辑越复杂，服务支撑起来就越困难。此外，传统的关系型数据库很容易在容量、延迟、响应时间和数据量方面遇到瓶颈。这就需要我们不断的拆分集群，同时也有各种各样的发展诉求。我们在尝试用平台思维解决问题的时候，也要充分考虑如何满足研发人员多样化的需求。从DBA的角度来说，人力困境的问题是时间严重碎片化，我们自身的成长会遇到瓶颈。比如，我们经常做一些枯燥的重复操作；我正在尝试平台化的方式，但还是跟不上业务发展的速度。另一件事是，专业的DBA越来越稀缺，而且越来越昂贵。关键是根本就没有新兵。在此背景下，我们不得不思考：如何突破困境？如何向智能化转型？传统运维的苦难在哪里？智能运维能解决哪些问题？首先，从故障原因来看，传统运维是故障触发的，而智能运维是隐患驱动的。也就是说，智能运维不需要报警，看报表就知道可能出事了，可以把故障排除在“萌芽”阶段；第二，传统运维是被动接受，而智能运维是主动攻击。但是，主动攻击不一定是通过DBA来完成的，可能是系统操作，也可能是机器人操作；第三，传统运维由DBA发起解决，而智能运维由系统发起和RD自助解决；第四，传统运维属于“人肉救火”，而智能运维属于“智能决策执行”；最后，传统运维需要DBA亲临事故现场，而智能运维DBA只需要“幕后”。从自动化到智能那么，如何从半自动化到自动化，再到智能运维呢？在这个过程中我们会面临哪些痛点？我们的目标是提供高效、稳定、快速的存储服务，这也是DBA的价值所在。业务不关心背后是MySQL还是NoSQL，只关心数据是否不丢失，服务是否可用，出现问题后需要多长时间恢复等等。所以我们尽量让这些东西对开发者透明，提供稳定、高效、快速的服务。从公司的角度来说，就是在有限的资源下，尽可能地提高效率，降低成本，尽可能长时间地解决问题。上图是对传统运维和智能运维的特点分析。左边属于传统运维，右边属于智能运维。传统运维在采集方面做的不够，所以没有太多的数据可供参考，分析预警能力也比较弱。而智能运维正好相反，以采集为主，平时做很多工作，包括分析、预警和执行、智能分析和关键报表的推送。而我们的目标是让“告警+分析+执行”在智能运维中的比重越来越少。如何执行决策？众所周知，预警重要但不紧急，而报警才是紧急且重要的。如果不及时处理，事态可能会扩大，甚至给公司带来直接的经济损失。预警通常是我们定位到了问题，它的决策思路非常清晰，可以通过规则或者AI的方式来解决，难度相对较小。告警依赖现场环节分析，变数多、路径长，决策难度大，任何决策都可能间接增加风险。因此，我们的策略是全面收集数据，然后增加预警数量，率先实现预警发现和处理的智能化。就像我们有步枪、有手枪、有刺刀一样，如果我们能从远处对付敌人，就尽量不要进行白刃战。数据收集，从数据库的角度，我们产生的数据分为四块，GlobalStatus、Variable、Processlist、InnoDBStatus、Slow、Error、GeneralLog和Binlog；从应用端来看，包括端到端成功率、响应时间95行、99行、错误日志和吞吐量；从系统层面，支持秒级采样和操作系统指标；从变更端看，包括集群拓扑调整、在线DDL、DML变更、DB平台运行日志和应用发布记录等。数据分析，首先是集群分析，其次是实例、库，最后是表，其中每个对象都可以在多个指标上进行同比比较和环比比较。具体对比项目请参考上图。通过以上步骤，我们基本可以得到数据库的画像，帮助我们整体做资源规划和服务治理。例如，如果某些集群的实例数非常多，并且有持续增加的趋势，那么就需要对服务器进行扩容；读增加很快，读写比变大，就要考虑存储KV；使用和分配会影响服务器的采购和预算制定；哪类告警最多，特殊处理，各断。从本地的角度来看，我们可以根据分析出来的一些数据来做集群的健康检查，比如数据库的某些指标是否超标，如何调整等等。数据库预警，通过分析发现隐患，变报警为预警。上图是我们实际情况下对告警的统计分析结果，其中主从延时占比最大。假设load.1minPerCPU比较高，我们怎么解决呢？那么，可能需要购买一台CPU单核性能更高的机器，而不是使用更多的核心。另一个例子是磁盘空间。当我们发现3T的磁盘空间普遍不够时，下次可以购买6T或更大的磁盘空间。对于空间警告问题，什么时候需要拆分集群？在MySQL数据库中，拆分或迁移数据库可能需要很长时间。因此，需要根据当前的增长速度来评估当前集群能维持多久，然后逆向计算什么时候开始分裂、扩容等操作。对于慢查询的预警，我们会统计红黑名单。上图是统计数据，还有使用率和出轨率数据。假设这是一个金融业务集团的数据库，假设有一个业务需要访问并且是直连的，那么这时候会出现几个问题：第一，是否有数据拥有者的授权；第二，如果不是通过服务发生故障，可能会导致整个金融数据库挂掉。如何降级？因此，我们会统计出轨率和慢查询。如果某个数据库正在被非法访问，那么我们就会扫描出来，然后进行服务管理。从运维的角度，我们实现了快速故障转移，包括自动生成配置文件、自动判断是否开启监控、切换后自动重写配置、自动从库返回在线等。告警的自动处理。目前，大部分的处理工作还是基于规则。规则是在后台制定的。触发后，根据满足的先决条件触发动作。随着库中规则定义的逐步完善和丰富，很多问题都可以逐步得到解决。简单的问题，这部分不再需要人工参与。展望未来，我们还将搭建类似“扁鹊”的故障诊断平台，实现日志采集、入库和分析，提供全链路故障定位和分析接口，服务化治理。展望智能运维，应该是自动化和智能化的重叠演进，以及ABC（AI、大数据、云计算）三个方向的深度融合。在数据库领域，NoSQL和SQL的界限越来越模糊。软硬件结合、存储计算分离的架构也被越来越多地使用。智能运维恰逢其时，我们也面临着更多新的挑战。我们的目标是通过DB平台的不断建设和加固，让平台能够自己发现问题，自动定位问题，智能解决问题。作者简介应刚，美团点评研究员，数据库专家。曾就职于百度、新浪、去哪儿等，拥有10年数据库自动化运维开发、数据库性能优化、大型数据库集群技术支持和架构优化经验。精通主流SQL和NoSQL系统，现专注于公司业务在NewSQL领域的创新与落地。
