巡检服务的重要性

这是学习笔记的第 1779篇文章

很早就计划做一个系统的巡检项目，我所说的这个巡检和咱们通常意义上理解的巡检完全不一样。这个巡检是面向业务同学的，简而言之，目标就是让业务同学看得懂的巡检。

为什么要这么做？其实也是对目前的运维现状做一些改变，一般来说，运维巡检都是系统层面的，偏向于技术方向的，会出来一些很抽象的报告和一大堆的数据。对于业务同学来说，这种互动很不友好，对于绝大多数同学来说，我们看一个偏理本行业内容的报告时，潜意识里是排斥的。而系统巡检方向的内容是更加底层的，有些信息其实对于业务同学来说压根不重要，但是我们的报告反而把这些放在了最前面，最醒目的地方，最终导致的结果就是报告有，但是难以消化。

从另外一个维度上来说，运维中的很多操作都是手工式，脚本化，或者平台化的，这些操作对于开发同学来说是一种黑盒的操作，技术方向的代沟势必会使得业务同学不能理解我们在做的事情，包括巡检也是如此。对于他们来说，这可能就是DBA份内的事情。 其实恰恰不是，我们巡检后的很多问题，如果开发同学能够提早了解和介入，在问题的处理流程和改进上效果会更好。

我们在和业务同学沟通的时候，我们期望得到这些答案。

应用最关注的问题：

1. 最迫切的问题：
2. 能够支持得高效一些的问题
3. 能够支持的灵活一些的问题

但是从实际的沟通来看，业务同学其实也没有一个很明确的想法，所以我们开始做一些引导。我们把应用常见的一些问题罗列一下：

应用常见的问题：

1. 服务要上线，现有的服务器压力能不能支撑

2. 业务自增列溢出，一部分原因是字段类型设置，还有过量的数据写入

3. 是否有冗余的索引

4. 数据缓存是多大，能够支撑多大的并发能力？

5. 应用的数据变化情况

6. 数据写入，存储容量，是否需要调整

7. 哪个表上的IO请求压力最大？

8. 哪些表走了全表扫描

9. 应该建立哪些索引，但是没有创建

10. SQL执行频率，比如ops,tps等指标

11. 从库是否提供读请求，vip信息和主从信息集群的关联关系

12. 连接数的分布情况

13. 后续要扩容的时候，是需要在新服务器上扩展，还是可以应用已有的服务器

14. 系统可用性，实例可用性

15. MySQL慢日志的需求

从整个沟通的情况来看，业务同学对于这些需求还是很迫切的，但是如果你不去问，可能他们也不知道该找谁，或者这些信息谁能提供，有很多需求就是这样不了了之。

顺着这个脉络往下聊，发现他们自身其实还是存在一些疑问的，他们其实也是希望能够通过团队力量来达到共赢。

在技术细节上，他们也存在一些疑惑，那就是接入可视化的一个原因，比如监控数据为例。

比如CPU监控指标，我们设定阈值是30%，则在业务查看的时候能够显示出这个阈值线，让业务知道这种指标是有问题的

对于不同业务的指标信息，可以根据具体的业务场景来定制，不能一概而论。但是目标是对于业务同学来说，通过阈值来知道哪些指标是可以参考的，高还是低，通过阈值线来知道。