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