这是学习笔记的第 1779篇文章
很早就计划做一个系统的巡检项目,我所说的这个巡检和咱们通常意义上理解的巡检完全不一样。这个巡检是面向业务同学的,简而言之,目标就是让业务同学看得懂的巡检。
为什么要这么做?其实也是对目前的运维现状做一些改变,一般来说,运维巡检都是系统层面的,偏向于技术方向的,会出来一些很抽象的报告和一大堆的数据。对于业务同学来说,这种互动很不友好,对于绝大多数同学来说,我们看一个偏理本行业内容的报告时,潜意识里是排斥的。而系统巡检方向的内容是更加底层的,有些信息其实对于业务同学来说压根不重要,但是我们的报告反而把这些放在了最前面,最醒目的地方,最终导致的结果就是报告有,但是难以消化。
从另外一个维度上来说,运维中的很多操作都是手工式,脚本化,或者平台化的,这些操作对于开发同学来说是一种黑盒的操作,技术方向的代沟势必会使得业务同学不能理解我们在做的事情,包括巡检也是如此。对于他们来说,这可能就是DBA份内的事情。 其实恰恰不是,我们巡检后的很多问题,如果开发同学能够提早了解和介入,在问题的处理流程和改进上效果会更好。
我们在和业务同学沟通的时候,我们期望得到这些答案。
应用最关注的问题:
但是从实际的沟通来看,业务同学其实也没有一个很明确的想法,所以我们开始做一些引导。我们把应用常见的一些问题罗列一下:
应用常见的问题:
1. 服务要上线,现有的服务器压力能不能支撑
2. 业务自增列溢出,一部分原因是字段类型设置,还有过量的数据写入
3. 是否有冗余的索引
4. 数据缓存是多大,能够支撑多大的并发能力?
5. 应用的数据变化情况
6. 数据写入,存储容量,是否需要调整
7. 哪个表上的IO请求压力最大?
8. 哪些表走了全表扫描
9. 应该建立哪些索引,但是没有创建
10. SQL执行频率,比如ops,tps等指标
11. 从库是否提供读请求,vip信息和主从信息集群的关联关系
12. 连接数的分布情况
13. 后续要扩容的时候,是需要在新服务器上扩展,还是可以应用已有的服务器
14. 系统可用性,实例可用性
15. MySQL慢日志的需求
从整个沟通的情况来看,业务同学对于这些需求还是很迫切的,但是如果你不去问,可能他们也不知道该找谁,或者这些信息谁能提供,有很多需求就是这样不了了之。
顺着这个脉络往下聊,发现他们自身其实还是存在一些疑问的,他们其实也是希望能够通过团队力量来达到共赢。
在技术细节上,他们也存在一些疑惑,那就是接入可视化的一个原因,比如监控数据为例。
比如CPU监控指标,我们设定阈值是30%,则在业务查看的时候能够显示出这个阈值线,让业务知道这种指标是有问题的
对于不同业务的指标信息,可以根据具体的业务场景来定制,不能一概而论。但是目标是对于业务同学来说,通过阈值来知道哪些指标是可以参考的,高还是低,通过阈值线来知道。