我眼中的业务巡检demo

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

关于业务巡检，自己也做了一些后端的设计，包括底层的通用任务设计等。

在表现形式上，自己也琢磨了很多的思路，总体的感觉是有很多信息想展示出来，但是信息太多又怕太乱，所以在纠结之中，自己给自己明确的定位了下：面向业务的巡检，于是毫不犹豫把很多系统层面的指标和数据先砍掉了。

设计的一个初版的业务巡检demo如下：

总体来说，希望是做成一类自助巡检服务，让我来评估一个数据库的整体情况，我会把信息分为三类：

1. 概要信息
2. 图表分析
3. 架构设计

如果是一个全新的数据库，其实硬件配置信息相对是次要的，对业务同学来说，最直接的一个印象就是这个数据库有多少用户连接，现在是否有主从延迟，有的话，现在延迟是多少。如果一些可以衡量的指标比如TPS,QPS可以让我对数据库的整体性能情况有一个了解，而通过对增删改查的数量进行摸底，则会对整个数据库的特征有一个明确的把握，在概要里明确提到业务的维度，是希望明确这是一个业务巡检，我们是基于业务的信息支持。

图表分析的部分我计划提取三类动态图，一类是整体的系统负载，通过这个负载可以对系统的整体情况有一个清晰把握，第二个是数据量变化，如果一个数据库有大量的日志写入，大量的数据写入，那么数据量的变化能够反映出很多的潜在问题。第三类是对于网络流量的分析，一般来说，系统曾更加关注CPU,IO，往往对网络的部分是忽略的，有了前面的一些基础数据，其实对于网络的部分可以做到心中有数。

架构部分是让业务同学对于目前的业务架构有一个概要的理解，因为是做业务支持，而且不是公有云服务，所以还是希望业务同学了解这个数据库的基本架构，这样一来，对于业务来说，就不是一个黑盒状态了，如果他看到有多个从库，而他也确实需要读写分离，那么就可以很顺畅的接入了。

同时在这个维度上，做了一些信息的补充，比如系统在线时长，数据库在线时长等，系统配置等，这些信息对于整体的把握上是需要的。但是对于业务来说，不是最需要关注的。

接下来的部分就是巡检信息提取了，这个维度算是更加深入了，需要对使用的数据库，表，索引做一些相对深入的分析和建议。这里我分了三个维度，去掉了系统维度，等待模型等，相对来说对于业务接入和了解来说还是相对平滑的。

最后是一个巡检建议列表，这里会基于多个维度把巡检建议给出来，同时对这些巡检信息进行打分模块的设计，最后给出一个分数来，这样整体来看就知道到底有没有问题，有没有明显的问题。