《蔡金龙-对于数据库智能运维的一些思考和实践.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成果展示客户案例选择预案处理预案32成果展示客户案例