数据库自治服务DAS：云数据库高效运维的最佳拍档
内容介绍：
一、产品简介
二、产品家族
三、实战案例
本次分享的主题是数据库自治服务DAS：云数据库高效运维的最佳拍档，由阿里云智能集团数据库产品事业部高级产品专家王斌分享。
本节将介绍数据库自治服务DAS产品，共分为三个部分，分别是产品的简介、产品家族以及实战案例。
一、产品简介
1、云数据库的应用挑战
根据网上的一些公开资料，当前数据库的引擎类型有350多种，参数的数量有700多个，这么多、这么复杂的数据库类型，会面临应用中很多的运维问题。比如空间管理的问题:存储容量不足，表空间的碎片，重复索引、容量的评估、性能的测试、数据库版本升级、大促的压力测试等。有时候会遇到一些复杂的问题，比如缓存击穿、事物的悬挂死锁等。还有自己本身写的一些SQL，比如搜索索引缺失，SQL写的不够好需要去改写，优化器执行错误的一些情况。最后还有一些安全问题，高危的SQL以及SQL注入和账号的风险等。阿里云基于数据统计，发现在数据库运维方面的工单，基本上平均处理时长在195分钟左右，并且数据库上的运维问题是很重要的。
我们在购买了一些数据库硬件之后，进一步的要做的事情是把数据库给用好，这部分的成本跟基础设施来比如何呢？我国当前的算力基础设施的市场规模大概是3000多亿，其中第三方运维服务市场的规模有1,600亿，所以这部分的投入也非常大。为了减少业务的损失，我们在数据库的投入必不可少，当前因为AI等一系列的发展，正面临着两个数据库运维方面的变革。第一是从人工到产品，因为业务增长的速度超过了DBA的增长速度，所以需要有一些产品化的能力来帮助DBA完成数据库运维。第二是从经验到智能，行业里面有经验的，面对大规模复杂场景的运维的专家人数是很稀缺的，希望能够借助AI来探索一些智能化,自动地帮助大家完成数据库的运维。由此引申出我们的产品DAS。
2、DAS产品简介
DAS全称叫Database Autonomy Service，它是一种基于机器学习和专家经验来实现数据库自修复、自防护、自优化的运维类云服务，它提供了自助式、主动式以及智能自动化的运维能力，能够帮助用户降低数据库的复杂度以及人工的误操作可能引发的一些故障，从而有效的保障数据库的稳定、安全和高效。DAS的产品架构，底层的是支持的数据库模型，等会会再展开来讲。并会通过一些内核或者探针获取数据库的日志，包括metrics、日志、参数、锁、事件等一些数据进来。另一方面，也会集成很多专家经验，既包含阿里集团多年来数据库运维的经验，也包含客户应用了阿里云的数据库产品，给我们的一些工单，这些工单中所带来的运维的过程和方法。基于这些我们沉淀出一些工具，包括检测工具、分析工具和优化工具，比如说异动检测、趋势检测、毛刺检测等的一些检测能力。分析工具包含常见的慢日志、SQL洞察、锁分析、会话、空间分析等。这一系列的分析会引导为最后对数据库的优化，比如说最基础的限流、扩容、会话管理、索引的优化，甚至于SQL改写的建议，帮助用户完成SQL的一些调整。基于这些工具基础之上，我们把运维问题从发生到诊断到最后完成治理进行了一个串联，这个串联包含了监控告警、诊断应急止血和深度优化。日常没发生问题的时候还要去做一些健康体检，完成一些主动的优化。因为大模型非常的火热，我们也考虑应用大模型去帮助大家完成智能化的运维，我们把专家经验结构化的输入到大模型里面，把技术文档包括故障复盘的资料、工单，甚至是各个工具上DB操作的一些埋点数据来得到“针对什么样的问题，用什么方式去完成”的一个诊断和优化，从而使大模型通过agent能够自动智能的去调用各项工具来实现大模型的运维。
3、发展历程
DAS从2014年开始到今年已经10多年了，整体分为4个主要的阶段，早期我们的品牌叫CloudDBA,2018年以后是SDDP数据自治平台，2020年升级为数据库自治服务，接下来会推出第5个阶段，产品形象与结合了AI以后去完成智能化的一个数据治理。关于DAS阿里云在很多顶会上发表了不少论文啊。DAS上线10多年带来了许多业务价值，包括整体的价值，比如自动的SQL优化，阿里云累计优化了4900万条SQL，全网的慢SQL下降了92%。异常的愈合能力，90%的故障都可以在一分钟内发现，5分钟定位并诊断，10分钟内完成它的恢复。DAS在这10年来自动优化的空间达到了27PB，这就是为客户所节省下的数据库的空间。智能调参覆盖了10万+的实例，在全网上节省了约12%的内存。通过下面的典型用例，对上述整体数据进行深度认识。阿里云的一个客户有60多个TP的数据库实例，其中有46个开通了DAS企业版，他们使用一年以来，SQL优化达到了700多条慢SQL，90%的异常都能在9分钟内就完成自愈合，通过大致产品输出的一些建议，完成了20TB左右的空间的优化。
4、产品特点
主要分成4个部分，一个是多源数据库的支持，第二是丰富的应用场景，第三是端到端的运维能力，第四是通向智能化的演进之路。
（1）数据库的支持
基本上三分钟接入数据库就能实现统一的监控与管理，它支持的类型比如MySQL、RDS SQL Server、PolarDB MySQL等,以及noSQL部分的Redis和mango。接下来我们也会把ap的部分纳入到监控和运维管理的部分。另一块是环境，当前支持公共云上的以及本地的运营管理，或者在ECS上自建的，甚至是其他云厂商的弹性计算的产品。
（2）丰富的应用场景
应用场景基本上分为6个大类，第1类是合规审计，依据各地的法规在云上的活动需要去做日志记录，并根据数据的重要性确定不同的存储期限。第2类是稳定性的运维，DAS提供了7×24小时的异常检测与根因分析，特别是大促的期间，会进一步的去保障业务的正常运行。第3类是性能优化，提供单条或全局SQL的诊断与自优化的服务，提供索引建议，SQL改写，数据库表结构优化与参数配置的优化。第4提供数据库成本的管理，提供关于数据库的资源，无流量表，无效索引的识别和一些优化建议。举个简单例子，前不久有个客户反应业务的响应比较慢，DAS诊断发现是一条update的SQL跑的特别慢，进一步探究根因发现那张数据表签了很多的索引，实际上一些索引已经半年多没用了，相当于无效的索引，那么就给出他一些建议，把无效的索引给删除掉，update的速度就会变快起来，既是性能的优化，也是成本的管理。第5个点是一些安全监控，数据库的安全很重要，DAS可以实时的记录数据库的异常操作和风险事件，比如像拖库、SQL注入、异常的查询包括异常的ip做了一些下载查询的一些行为等，都会有相应的监控能力。第6点是流量回放和智能压测，基于全量的SQL日志，我们能够实现的是比如说出现了故障，进行了优化以后，拿故障期间的SQL认知去重新跑一遍去重现当时的故障是怎么发生的，以及优化方案能否去很好地解决这个问题。另一方面对于自建上云，数据库产品的迁移这些性能的稳定性的测试也可以基于这样的一些功能提前发现问题。
（3）场景化自治闭环
下面讲的是一些场景化的自治闭环和当前一些功能的具体价值参数，DAS从最早的工具型产品演进到现在，把数据库的运维整体串成从监控到诊断到优化的过程。这个过程中我们在各个环节都做了很多的事情，比如异常的检测，DAS现在提供5000万次/天的指标变化的感知，前面介绍的一系列的工具，对于一些实例的告警。我们发现异常以后就去诊断根因，这么多的工具比如锁分析、事故分析、会话分析的工具，人工会比较麻烦，我们会把它串在一起，基于异常去使用各种不同的工具，去看它对根因的贡献度，对于贡献度比较高的，认为可能是一些主要的原因，定位到数据库的异常最终的原因是什么。通过工具系统化会比人工单的耗时会降低99%左右。一些空间优化性能力等都会结合在我们深度优化的能力之内。我们现在也开始用一些智能大脑去串工具，DAS会基于云数据库、历史的运维的数据去构建一个数据库的大模型来实现智能诊断和自适应的一种优化，并且它可以提供持续的自研性的能力，也就是用的多了以后，用户的反馈会反哺模型。安全审计能力和数据库安全合作，可以识别900多种的访问风险，也会基于机器学习模型去识别异常行为，比如一些全新的ip或者平时使用比较少见的ip，过来查询或者下载数据库等，相应的一些行为都会作出监控和告警。
（4）从辅助自治到自动驾驶
我们从客户的一些痛点，比如SQL问题、负载问题、空间问题等构建了各种工具，这些工具和问题都有相应的一些关联关系，分别用什么工具解决什么问题，这是第最早的工具化可以提供给大家的。场景化自治是DAS当前要提供给大家的能力，日常的突发异常的自治，从告警到诊断止血和深度优化以及主动的巡检，就像日常的体检一样去完成一个主动式的优化，进一步往下发展到自动驾驶的能力。
像我们开车一样，首先需要一个自动驾驶的大模型，这个大模型会有工具调用、运维风格、语义理解、自动换挡几个特性。关于语义理解，我们在运维的过程中，日常的情况和大促的情况，数据的抖动或者说容许的范围不一样，这时候基于传统的模式就需要去做告警配置。可能日常cpu是从20%到30%，超过比如浮动50%以后就要告警，但大促的时候允许度会更高一点，到百分之七八十认为也还正常，因为业务流量变大了。这种情况下需要去简化配置，可以通过语义的方式跟客户交互，提示要开始进行大促，这段时间数据库的监控可以稍微宽一点。另一个角度，比如进一步的要去查某个特定的实例和指标，因为一个客户他的DBA要去维护的实例数有几十个甚至上百个，有些特定的实例，可能有些特定业务的用途，要去把它找出来，这些都可以通过语义理解去完成。当找到这个实例、看到这个指标以后，可能会去想这个实例有什么问题，是不是cpu高了或者io有负载上的异常等。大模型通过学习各种经验去完成对于诊断工具以及分析工具的调用。它的能力是怎么实现的呢？先看DAS的自治能力，我们针对的不同的问题对应的各种工具的使用，会先用规则化的方式做一个关联，基于这样的关联相当于是兜底的，比如说慢SQL怎么办、会话异常怎么办、怎么去诊断确定是哪个SQL慢、怎么去限流等，这部分相当于是已有的经验的输入，但是已有的经验不能代表未来可能要发生的事情。基于基础的运行参数和审计日志，我们会有一个小模型去识别数据库到底发生了什么问题，这部分的识别能力会突破趋势检测、异动检测、周期性检测等一些简单的检测能力。发现这些异常以后，还有一个小模型会去读取各种以运维工单为代表的经验。实际上还会更多地扩展到集团里面的故障复盘，包括系统的操作等一些数据，将阿里资深的DBA的运维经验给到我们的模型，告诉这个模型一般遇到这种情况，资深的DBA是怎么解决的。这部分的能力被模型学习了以后，就形成了自动驾驶的底座，在这个底座上我们知道基本常见问题如何解决。我们还会做行业特性，不同的行业在做数据库运维的时候风格是不一样的。比如企业是金融政务服务的企业，那么服务的可用性是最要紧的，当出现一些异常的时候，扩容消费问题不是特别大，主要要先保证服务可用。但是对于中小企业，就会去考虑性能和成本的平衡，这时候就不能给客户推荐无脑扩容了，要根据实际情况确认扩容扩大多少，以及是否限流来实现业务的基本可用。不同的行业有自己的运维风格，这部分就依赖于我们云数据库下面的小模型，客户在用了DAS产品以后会有很多不同行业的工单，我们会根据客户在不同的行业里面把工单进行分类，识别不同行业运维风格的一些差异，来形成这部分的知识输入。
另一部分之所以叫自动驾驶，就像开车一样，有一个特性叫做换挡，比如日常的业务中和大促的时候，对一些指标异常的容忍度是不一样的，以及采取的优化或者止血方案也是不一样的。比如大促的时候，要先扩容，不管这个扩容是不是特别合理，但是要先保证业务进来，因为大促是一年中最重要的时候。所以它就像开车一样，有低速档和高速档，这些东西都会基于三个小模型，从集团的运维经验和不同行业以及不同实际中的运维经验，整体输入到大模型里面来完成数据库基于不同行业、不同阶段、不同场景或者不同诉求的智能运维能力。
二、产品家族
1、基础版
产品家族主要分成两个部分，一个是基础版，另外一个是企业版。基础版会提供一个普惠的数据库运维服务，当客户开通了阿里云数据库引擎的时候，自动就会为客户开通DAS基础版提供基础的监控、限流、扩容的能力。比如慢SQL、锁分析等。
2、企业版
如果要更进一步的全面进阶的数据和保障，可以开通DAS的企业版，它会采集并且分析全量的日志,应用ai的能力,智能定位问题并提供优化的方案。比如AI运维、SQL洞察、全局的workload，以及安全审计，我们有967条告警规则和基于机器学习的一些行为判断，还有流量回放和智能压测。智能压测方面，阿里往年做双11的时候都会做类似的一些压测，双11会有一些订单、交易、客户、营销活动的系统，不同的时间段各个模块的流量是不一样的，通过类似智能压缩能力把各个板块的流量进行一个不同倍速的播放，然后整合在一起去看整体的系统，它的稳定性和响应是否符合预期。
三、实战案例
1、案例演示
通过一个实战的案例直观的去感受DAS智能运维的能力所带来的体验。RDS数据库具备自动sql限流、自动sql优化功能，高可用版本下更可支持自动空间扩展、自动性能扩展功能，当达到上述自定义场景时，RDS自治能力启动。实力活跃会话，cpu等性能指标正常，数据库正常运转。21时47分，数据库实例开始出现异常，cpu开始飙高并逐渐达到100%，活跃会话，慢查询数量急剧飙升，数据库处理能力急剧下跌，业务已处于不可服务状态。21时48分，RDS检测到了该异常,并自动进行了根因分析，迅速定位到异常SQL。21时50分，RDS采取了自动限流干预。21时51分，慢查询、活跃会话数量下降，RDS数据库处理能力恢复,业务恢复正常。至此RDS通过自动限流完成了实例的自我修复，保证了业务的正常运转。RDS对sql进行自动优化分析，给出诊断结果与优化建议，慢查询限流后，业务虽恢复，但此时流量仍持续加大，实例承载了原流量数倍压力后，cpu超过安全范围。22时05分，RDS根据cpu负载情况自动完成实例升配，适应新的业务负载流量。RDS基于实例负载完成规格的自适应推荐，实现容量的动态规划。RDS第2阶段实例自适应负载规格完成。凌晨2时0分，实例进入变更窗口期，RDS完成慢查询自动索引优化。RDS进入持续24小时的优化效果跟踪评估，慢查询优化效果显著，查询时间由十秒级提升至毫秒级，性能提升超8000倍，同时查询执行频次也大大提升。至此RDS第3阶段完成针对异常查询的自动优化，最终实现了问题的标本兼治。
2、自治服务的系统消耗
从9时左右，一分钟内发现它的异常，cpu负载的升高，两分钟左右定位到异常的SQL，并对异常的SQL发起限流。限流生效以后，持续不到5分钟业务就基本恢复了，再进一步对异常的SQL发起根因的诊断，确认优化方案应该增加一个索引。在大概10分钟左右的时候优化索引变更上线，上线以后再进一步完成24小时的跟踪，把限流解除，整体达到从治标到治本的全过程。
3、人工运维的消耗
如果人工来做，可能消息通知数据有异常就需要10分钟左右，接下来要依次检查会话、事务直至各条SQL清单，确认异常原因以后，进一步要去考虑是应急止血还是在一些优化的方案上选择做哪个action，而评估参数保证扩容的有效性以及平衡成本，应急处理完以后进一步还要考虑最终的优化方案是什么。比如要在SQL运行的资源、数据表以及性能负载等方面综合的做一个分析和判断，确定优化方案。之后还要履行一些变更的程序，还需要进行监控、跟踪等效果变化。而整体过程下来一般至少是几个小时到几天的时间，才能把它给完成。在DAS的自动运维上，从问题发生到整体的解除限流，11分钟时间就可以把问题完全解决。这是DAS在自动运维能力上给客户带来的业务价值。
