从自动化到智能化运维过渡时，美团 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 领域的创新和落地。
