作者|金龙DAS（DatabaseAutonomyService，数据库自治服务）是面向研发和DBA，为用户提供数据库性能分析、故障诊断、安全管理等功能的数据库自治服务。DAS利用大数据手段、机器学习和专家经验，帮助用户消除数据库管理的复杂性和人工操作带来的服务故障，有效保障数据库服务稳定高效运行。本文主要介绍DAS的历史背景、演进策略、重要功能和实现思路，希望对从事相关开发的同学有所帮助或启发。1现状与问题1.1规模增长与运维能力发展不平衡凸显近几年随着美团业务的快速发展，数据库规模也保持快速增长。数据库作为整个业务系统的“神经末梢”，一旦出现问题，对业务的损失将非常大。同时，由于数据库规模的快速增长，问题的数量也大大增加，完全依靠人力的被动分析和定位变得不堪重负。下图是当时数据库实例近几年的增长趋势：图1数据库实例增长趋势1.2理想很丰满，但现实很骨感。平衡，主要矛盾体现在对数据库稳定性要求高，关键数据缺乏。由于产品能力不足，只能依靠专业的DBA人工排查问题，异常处理时间较长。因此，我们决定填写关键信息，提供自助服务或自动问题定位能力，缩短处理时间。我们回顾了过去一段时间的故障告警，深入分析了这些问题产生的根源，发现任何异常其实都可以按照时间分为三个阶段：异常预防、异常处理、异常复查。针对这三个阶段，结合MTTR的定义，进而调研美团内部和行业的解决方案，我们做了一个涵盖数据库异常处理解决方案的全景图。如下图所示：图2运维能力现状通过对比我们发现：每个环节我们都有相关的工具支持，但是能力还不够强，相比领先云厂商的能力大约20%到30%，短板更加明显。自助服务和自动化能力也不足。虽然工具很多，但是整个链条还没有打通，没有形成合力。那么如何解决这个问题呢？经过团队成员的深入分析和讨论，我们提出了更符合当前发展阶段的解决方案。2解决方案2.1既解决短期矛盾，又着眼长远发展从历史故障的回顾来看，80%的故障，80%的时间花在了分析和定位上。解决异常分析定位效率的短期ROI（投资回报率）最高。从长远来看，只有完善能力图，才能不断提升整个数据库的稳定性和保障能力。因此，我们当时的一个想法是解决短期矛盾，立足于长远发展（ThinkBigPicture，ThinkLongTerm）。新规划要为今后的发展留出足够的空间，不能只“头痛治头，脚痛治脚”。在宏观层面，我们希望更多的功能能够被自动定位，基于自动定位的自助服务或者变更的自动处理，能够提高异常恢复的效率，最终提升用户体验。异常处理效率提升，用户体验提升后，运维人员（主要是DBA）的沟通成本将大大降低，让运维人员有更多的时间投入到技术上，更“人肉”可以加工。异常变为自助服务或自动处理，从而形成“飞轮效应”。最终达到高效稳定保障的目的。在微观层面，我们在已有数据的基础上，通过结构化信息输出，提高可观察性，弥补关键数据缺失的短板。同时，在完善信息输出的基础上，通过规则（专家经验）与AI的配合，提供自助服务或自动定位能力，缩短处理时间。图3宏观与微观2.2夯实基础能力，赋能上层业务，实现数据库自治在明确的指导思想下，我们应该采取怎样的发展战略和路径？从当时团队的人手情况来看，没有一个同学有过类似异常自主的开发经验，甚至连数据库异常分析能力都还没有，人才结构达不到最终目标的产品。所谓“天下大事必详，天下难事必易”。我们的思路是从小功能和容易的地方做起，先完成指标监控、慢查询、活跃会话等简单功能，然后逐步深入到全SQL、异常根因分析、慢查询优化等复杂功能建议。通过这些基础工作，就是“借假修真”，不断提高团队攻坚克难的能力，同时打下良好的智力基础。下面是我们根据当时的人才结构和未来目标制定的两年路径规划（数据自治目标规划的实现要在2022年后开始，下图中省略这部分）：图4演进策略2.3建立科学的评价体系，持续跟踪产品质量美国著名管理学者卡普兰说过：“没有衡量就没有管理”。只有建立科学的评价体系，产品才能不断走向更高的高峰。如何评价产品的质量并持续改进？我们之前做过很多指标，但是这些指标是不可控的，没有办法指导我们的工作。例如，我们最初考虑使用结果指标precision和recall来进行rootcause定位，但是结果指标是不可控的，很难指导我们的日常工作。这就需要找到可控因素并不断改进。我们在研究亚马逊的时候，刚好发现他们有一个输入输出指标可控的方法论，很好地指导了我们的工作。只要我们不断优化和完善正确可控的投入指标，最终我们的产出指标也能得到提升（这也印证了曾国藩说过的一句话：“在事业上努力，在结果上随遇而安”）).下面是我们针对根因定位的指标设计和技术实现思路（在仿真环境中，可控部分不断完善，实际上线效果也会有所提升。主要包括“根因定位可控输入输出指标设计”ideas》和《根因定位获取可控输入指标的技术实现思路》）。RootCause定位可控输入输出指标设计思路图5可控输入输出指标设计RootCause定位可控输入输出指标采集技术实现思路图6可控输入输出指标技术设计图5中，我们使用场景重现方式使用技术意思是模拟一些可以低成本实现的异常（大部分）。对于复现成本比较高（很少）的异常，比如机器异常、硬件故障等，我们目前的思路是通过“人肉操作”的方式发现问题并优化，等到下一次线上异常反复出现，根据优化诊断的结果，与预期进行比较，判断是否通过验收。未来我们将建立回溯系统，将问题发生时的异常指标保存起来，并利用将异常指标输入回溯系统后的输出结果来判断系统改进的有效性，从而构建一个更轻量级和更广泛覆盖的递归方法。图6是递归系统的具体技术实现思路。有了指导思想，有了符合当前发展阶段的路径规划，有了科学的评价体系，再谈技术解决思路。3技术方案3.1技术架构顶层设计在技术架构顶层设计上，我们坚持平台化、自助化、智能化、自动化四步演进战略。首先，我们需要提高可观察性能力，通过关键信息的展示，搭建一个简单易用的数据库监控平台。然后我们根据这些关键信息对变更（比如数据变更、索引变更）进行赋能，部分高频运维工作可以通过这些结构化的关键信息（比如索引变更）监控最近是否有访问流量)确保变更安全)让用户自主决策，即自助服务。接下来，我们加入一些智能元素（专家经验+AI），进一步覆盖自助场景，逐步将一些低风险的功能自动化，最终通过系统的不断完善，达到高级或全自动化阶段。为什么我们把自动化放在智能之后？因为我们认为智能化的目标也是为了自动化，智能化是自动化的前提，自动化是智能化的结果。只有不断提高智能化，才能实现高级或完全的自动化。下图是我们的顶层架构设计（左边是演进策略，右边是技术架构的顶层设计和2021年底的现状）：图7的顶层设计架构顶层设计只是“万里长征的第一步”。接下来，我们将逐步介绍我们自下而上基于顶层设计开展的具体工作，并逐步从数据采集层的设计、计算存储层的设计、分析决策层。3.2数据采集层设计在上面的架构图中，数据采集层是最底层，也是所有环节中最重要的一环，采集数据的好坏直接决定了整个系统的能力。同时，它直接与数据库实例打交道，任何设计缺陷都可能导致大规模故障。因此，技术方案必须兼顾数据采集质量和实例稳定性。如果两者不能兼顾，不如牺牲采集质量来保证数据库的稳定性。在数据采集方面，业界采用基于内核的方式，但是美团自研内核晚，部署周期长，所以我们短期的方式是采用抓包的方式进行过渡，并且等待基于内核的集合部署到一定程度。刻度后，逐渐切换。以下是我们研究基于抓包思路的技术方案：从研究中可以看出，基于pf_ring和dpdk的方案依赖性强，短期内难以落地，前人没有经验。但是基于pcap的方法没有依赖，我们也有一些经验。美团酒旅团队此前基于抓包方式做了一个完整的SQL数据采集工具，已经验证了一年。因此，我们最终采用了基于pcap抓包的技术方案。下面是采集层方案的架构图和采集质量，以及对数据库性能的影响。图8Agent的技术设计对数据库的影响图9测试Agent对数据库快速增长趋势的影响。因此，我们的设计不仅要满足当前的要求，还要考虑未来五年及以后的要求。同时，对于数据库故障分析，数据的实时性和完整性是快速高效定位问题的关键，而保证数据实时性和完整性所需的容量成本也不容忽视。因此，结合上述需求和其他考虑，我们对这部分设计提出了一些原则，主要包括：全内存计算：保证所有计算都是单线程或单进程的纯内存操作，追求性能。最终的吞吐量。原始数据上报：MySQL实例上报的数据尽可能保持原始状态，不做或只做最少的数据处理。数据压缩：由于上报量巨大，需要保证上报数据的最终压缩。内存消耗可控：通过理论和实际压力测试，内存溢出几乎不可能发生。尽量减少对MySQL实例的影响：尽量延迟计算，不在Agent上进行复杂的计算，保证RDS实例不会受到太大影响。下面是具体的架构图：图10Agent对数据库测试的影响FullSQL（访问数据库的所有SQL）是整个系统最具挑战性的功能，也是数据库异常分析最重要的信息之一。因此，全SQL的聚合方式、聚合压缩的效果、补偿设计等会在一些关键点进行介绍。3.3.1全SQL的聚合方式由于详细数据量巨大，我们采用聚合方式。消费线程会以分钟为粒度聚合计算同一模板SQL的消息，以“RDSIP+DBName+SQL模板ID+SQL查询结束时间分钟”为聚合键。聚合键的计算公式为：Aggkey=RDS_IP_DBName_SQL_Template_ID_Time_Minute（Time_Minute的值取自SQL查询结束时间所在的“年月日时分”）图11SQL模板聚合设计图12SQL模板聚合方式3.3.2全量SQL数据聚合压缩的效果在数据压缩方面，遵循逐层降流的原则，采用消息压缩、预聚合、字典、分钟级聚合保证通过各个组件时减少流量，最终实现带宽节省。减少存储量的目的。以下为相关压缩环节及测试数据表现（敏感数据已脱敏，不代表美团实际情况）：图13FullSQL压缩设计及效果3.3.3FullSQL数据补偿机制如前所述，在数据聚合端以一分钟为单位进行聚合，并允许额外的一分钟消息延迟。如果消息延迟超过一分钟，则直接丢弃。这样一来，在业务高峰期延迟严重的场景下，就会丢失大量的数据，从而对后续的数据库异常分析的准确性造成很大的影响。因此，我们添加了延迟消息补偿机制，将过期数据发送到补偿队列（使用美团消息队列服务Mafka）。通过过期数据补偿的方式，我们可以保证长时间延迟的消息也能正常存储。通过最终一致性的可靠性保证了后续数据库异常分析的准确性。下面是数据补偿机制的设计方案：图14全SQL补全技术设计3.4分析决策层设计有了比较完整的数据后，下一步就是根据数据进行决策，推导出可能的根本原因。在这一部分，我们采用基于专家经验结合人工智能的方法。我们将演化路径分为四个阶段：第一阶段：完全聚焦规则，积累领域经验，探索可行路径。第二阶段：AI场景探索，但主要依靠专家经验，在少量低频场景上使用AI算法验证AI能力。第三阶段：专家体验与AI齐头并进，专家体验在现有场景上不断迭代延伸，AI在新场景落地，原有能力不退化，双轨制。第四阶段：完成AI对大部分专家经验的替代，以AI为主的专家经验为辅，最大限度发挥AI能力。下面是分析决策部分的整体技术设计（我们参考了华为的一篇文章：《网络云根因智荐的探索与实践》）：图15分析决策技术设计在决策分析层，我们主要采用专家经验和人工智能方法。介绍专家经验（rule-basedapproach）和AIapproach（AIalgorithm-basedapproach）的实现。3.4.1Rule-BasedApproach在专家经验部分，我们采用了GRAI（Goal、Result、Analysis、Insight的缩写）的评审方法来指导工作。通过持续的、大规模的、高频的review，我们提取了一些Spectrum规则，通过不断的迭代，准确率和召回率不断提升。以下是主从延迟规则抽取流程示例：图16专家经验回顾与改进，将离线流程的正则建模与实时流程的流量检测相结合，有助于有效当数据库实例发生故障或存在风险时，定位问题根源，及时有效解决问题。建模过程主要分为三个过程。首先，我们通过一些预处理模块对指标的历史数据进行预处理，包括缺失值填充、数据平滑和聚合的过程。随后，我们通过分类模块创建了后续不同的分支，使用不同的方法对不同类型的指标进行建模。最后，模型序列化存储后，提供Flink任务读取，实现流检测。下面是检测设计图图17基于AI的异常检测设计Rootcausediagnosis(underconstruction)订阅告警消息（基于规则触发或异常检测），触发诊断流程，收集分析数据，推断rootcause并过滤掉有效的信息，协助用户解决问题。通过大象将诊断结果通知给用户，并提供诊断详情页面，用户可以通过标记优化诊断准确率。图18基于AI的异常检测设计数据采集：采集数据库性能指标、数据库状态抓取、系统指标、硬件问题、日志记录等数据。特征提取：从各类数据中提取特征，包括通过算法提取的时间序列特征、文本特征以及利用数据库知识提取的领域特征。根因分类：包括特征预处理、特征筛选、算法分类、根因排序。根因扩展：根据根因类别深入挖掘相关信息，提高用户处理问题的效率。具体包括SQL行为分析、专家规则、索引关联、维度下钻、日志分析等功能模块。4建设成果4.1指标表现我们目前主要采用“梳理触发告警场景->模拟复现场景->根因分析诊断->改进方案->验收提升质量->梳理触发告警场景”的闭环方式》（详情请参考上篇建立科学的评价体系，持续跟踪产品质量），并不断优化迭代。通过对可控输入指标的改进，对在线输出指标进行优化和改进，确保系统持续朝着正确的方向发展。以下是rootcauserecall和precision指标的近期表现。用户告警根因反馈准确率图19用户反馈准确率告警诊断分析整体召回率图20根因分析召回率4.2用户案例在根因结果的推送中，我们打通了美团内部IM系统（大象）后问题出现，通过告警发现异常->大象推送诊断根因->点击诊断链接查看详细信息->一键预案处理->跟踪反馈处理效果->执行成功或回滚，完成异常发现、定位、验证、处理的闭环。以下是活动会话规则触发告警后根因分析案例。自动拉群，并给出根本原因图21锁阻塞导致活跃会话过高点击诊断报告查看详情图22锁阻塞导致活跃会话高脱敏原因，使用测试环境模拟案例）。图23慢查询优化建议5总结及未来展望经过两年左右的发展，数据库自治服务基本夯实了基础能力，并在部分业务场景完成了初步赋能（例如针对问题SQL，业务服务自动发布上线前识别并提示潜在风险；对于误改索引，在工单执行前自动检测近期索引访问流量，阻断误改等）。接下来，除了在已经完成的工作上继续深化和提升能力，我们的目标将是聚焦数据库自治能力。主要工作规划将围绕以下三个方向：（1）提升计??算和存储能力：随着数据库实例和业务流量的持续快速增长，以及采集信息的不断丰富，迫切需要提升计算和存储能力。现有的数据通道能力，保证能够支撑未来3-5年的处理能力。(2)少数场景实现自治能力：在数据库自治能力方面，将采用三步走的策略：第一步：建立根因诊断与SOP文档的关联，进行诊断和处理透明的;第二步：SOP文件平台化，诊断处理流程简化；第三步：一些低风险的无人干预，诊断和处理自动化，逐步实现数据库自治。（3）更灵活的异常回溯系统：在上线前或改进后验证某个场景的根因定位算法非常重要。完善验证系统，建立灵活的异常回溯系统，并根据现场信息回放不断优化，提高系统定位精度。6本文作者金龙，来自美团基础技术部/数据库研发中心/数据库平台研发组。
