这是学习笔记的第 1769篇文章
巡检的工作其实是比较枯燥和乏味的,在某种程度上,他的工作和监控是有很多交集的,其实在很多公司里面,巡检方向的落地情况其实不容乐观,采用脚本和被动触发的方式效率不高,同时巡检中发现的潜在业务问题和业务部门是隔离的,也就是你在做的事情,业务部门不知道,自然就没法给予充分理解了,所以在问题的处理效率和响应上会是一个黑盒的状态,我觉得这也就是运维方向比较苦逼的一个原因。
我想把巡检的事情改进一下,首先巡检要划分大类,监控巡检,系统巡检和数据库巡检三个维度,然后巡检的意义怎么体现,那就是让业务同学能够体验到,有所帮助,所以是推荐把巡检模块集成到公共平台的,开放给业务部门使用,巡检数据就透明化了,当然可以根据时间范围灵活提取;系统巡检信息和数据库巡检信息可以从业务角度出发,提出更符合业务特性的建议;在展现形式上,需要深度定制巡检报告,可以灵活提取,在问题处理和协作方式上有所改善。
当然我也想了另外几个新的主题方向,也是后续要着力去做的内容。
整体的计划和结构如下,欢迎大家提出建议。
巡检项目规划和设计方案 | 巡检项目对接监控巡检,系统巡检和数据库巡检三个部分,对于巡检任务会采用任务调度的触发方式。 |
---|---|
监控巡检模块开发 | 开发监控巡检接口,对接MySQL和Redis的系统巡检信息,对于部分数据库巡检指标信息,可以根据时间范围来提取数据。 |
任务调度对接 | 完善已有的celery调度,能够通过API的方式对接批量的巡检任务,通过队列方式下发异步执行,提供队列中任务信息的管理 |
数据库巡检梳理集成 | MySQL方向的sys schema模块进行梳理和信息定制 |
系统巡检模块集成 | 系统巡检信息梳理,对接SQL r巡检信息至监控系统,系统巡检涉及密码巡检,服务可用性巡检等 |
巡检报告定制 | 基于开源项目MySQL_Watcher项目,对于巡检报告进行定制和梳理,生成报告,提供邮件发送功能 |
对接公共平台提供自助化服务 | 对接公共平台系统,开放给研发团队,可以根据时间范围抽取信息,报告内日用已邮件形式发送 |
时间序列故障预测 | 基于时间序列的数据分析,能够根据历史沉淀数据和当前问题,对问题做同比和环比分析,能够根据数据变化趋势预测问题和问题周期 |
监控数据图模型分析 | 对于已发生的历史,抓取常见的场景,基于图模型进行问题的分析,能够得到根因,通过关联树形方式得到更清晰的结构 |
基于机器学习的故障自愈 | 对于已监控的问题,将解决问题和过程和方法进行沉淀,基于大量的案例分析进行方案的提取,基于已有的模型形成流程化的自动任务,能够对执行结果进行控制和建议 |