蔡金龙-对于数据库智能运维的一些思考和实践.pdf

《蔡金龙-对于数据库智能运维的一些思考和实践.pdf》由会员分享，可在线阅读，更多相关《蔡金龙-对于数据库智能运维的一些思考和实践.pdf（32页珍藏版）》请在三个皮匠报告上搜索。

1、12023年07月对于数据库智能运维的一些思考和实践基础技术部/蔡金龙2解决思路背景介绍技术方案成果展示3背景介绍实例高速增长带来的稳定性问题运维效率1.分析定位难度大，以人为主，系统为辅2.工具之间联动少，单点之间来回切换3.协同沟通成本高，处理过程不透明业务稳定性1.故障处理周期长，小毛病易演变成大故障2.故障出现频次高，新业务问题持续不断发生团队口碑1.用户投诉多，产品满意度低规模增长与运维能力发展之间的不平衡问题凸显4背景介绍理想很丰满，现实很骨感异常处理（MTTR）异常预防（MTBF）异常复盘改进（MTBF）分解+逻辑转换每个环节具备10%20%的能力，能力保障短板明显自助化和自动化

2、能力不足，整个链条没有打通，未形成合力5解决思路背景介绍技术方案成果展示6解决思路既解决短期矛盾，也立足长远发展（Think Big Picture,Think Long Term）从历史故障复盘来看，有80%的故障80%的时间花在分析和定位上。因此，短期解决异常分析和定位效率ROI最高。长期来看，只有完善能力版图，才能持续不断的提升整个数据库的稳定性保障能力。7解决思路夯实基础能力，赋能上层业务，实现数据库自治欲伐大木，岂能骤折。必以斧斤伐之，渐至微细，然后能折。-雄才大略的清太祖努尔哈赤“伐树理论”8解决思路建立科学的评估体系，持续的跟踪产品质量美国著名管理学者卡普兰说过“没有度量就没有管

3、理”运营产品核心指标自治指标拆解9解决思路背景介绍技术方案成果展示10技术方案技术架构的顶层设计各层功能介绍1.业务逻辑层：根据不同场景整合已有信息，对外提供服务，包括前端接口调用以及第三方调用。2.分析决策层：根据已有数据，提供专家经验+AI算法的能力，供上层不同的场景触发调用。3.计算存储层：对原始采集的信息进行流式计算和存储。4.数据采集层：对数据库实例上的关键信息进行收集上报。11技术方案数据采集层：点、线和面多维立体，无死角信息收集魔鬼藏在细节里，故障之所以成为故障，往往是缺少对细节的掌控力。12技术方案数据采集层：提升认知并内化认知数据采集涉及的动作1.埋点：采集过程将数据存在th

4、d结构体中，在合适的地方通过埋点进入审计的主体部分。2.流控：SQL生成超过一定阈值后将过载的部分丢弃。3.存储：通过无锁循环队列存储产生的SQL。4.输出：从内存池中依次获取保存的信息，然后写入全量SQL文件或高优SQL文件。5.消费：监听日志的变化，如有新日志产生及时消费，并上报到后端大数据平台。13技术方案计算存储：大数据通道的建设与优化设计原则1.全内存计算：尽量确保所有的计算都在单线程内单进程内做纯内存的操作，追求性能跟吞吐量的极致。2.最小化对MySQL实例的影响：尽量计算后置，不在Agent上做复杂计算，确保不对RDS实例生产较大影响。3.上报原始数据：MySQL实例上报的数据尽

5、量维持原始数据状态、不做或者尽量少做数据加工。4.数据压缩：由于上报量巨大，需要保障上报的数据进行极致的压缩。5.内存消耗可控：通过理论和实际压测保障几乎不可能会发生内存溢出。14技术方案计算存储：过期数据的补偿机制，保证最终一致性15技术方案 基于数据驱动的异常分析和根因定位的顶层设计16技术方案 了解指标的分布规律，寻找合适的算法建模17技术方案 根据不同的指标规律，构建不同的模型进行异常检测18技术方案规则的提炼300+异常告警复盘，深入的内核原理分析复盘回顾分析总结提炼基于经验的规则树（以活跃会话为例）19技术方案 以铜为镜，可以正衣冠；以史为镜，可以知兴替；以人为镜，可以明得失20技术方案检验是改进的基础，持续验证，不断改进21技术方案SQL性能优化-索引建议（COST）22技术方案SQL性能优化-索引建议（XGB）23技术方案SQL性能优化-索引建议（LLM）模型训练模型推理24技术方案通过完善的验证体系，做好最后一道兜底措施，让客户放心使用25解决思路背景介绍技术方案成果展示26分析决策：指标评估（基于异常告警）成果展示27性能洞察：SQL全生命周期内的信息展示成果展示28成果展示客户案例29成果展示客户案例会话触发告警分析+拉群根因定位30成果展示客户案例延迟触发告警分析+拉群根因定位31成果展示客户案例选择预案处