业务自助巡检这么玩（一）

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

通常节假日之前，DBA都会对MySQL做一些巡检工作，那么巡检工作该怎么做，当然我们可以想到内核参数，系统配置，数据库参数配置等。这些巡检工作其实对于业务同学来说，难以体现最大价值，或者说得直白一些，业务同学会认为这是DBA应该做的事情。

那么业务同学关心哪些指标，我们的巡检是不是也可以换个方式来做，既能服务于业务，也能体现我们工作的深度和广度，这样一来，我们提供的就不是一个黑盒服务，而是可以转变为更加主动的自助服务了，简而言之，目标就是让业务同学看得懂的巡检。

自助巡检设计的初衷就是基于这样的情况，如果换一个角度，在做好本职工作的前提下，让别人也提高效率，我们的服务才更有价值。

业务巡检应该关注什么

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

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

我们在和业务同学沟通的时候，期望得到体系化的信息，所以在进行沟通调研之前，我们需要了解下应用关注的问题，大体分为以下几类：

为了避免范围铺的太大，难以聚焦，我们需要做一些引导。以下是我们预设的一些问题和业务提出的问题，整理后的结果：

从沟通的情况来看，业务同学对于很多需求还是很迫切的，但是如果你不去问，可能他们也不知道该找谁，所以在信息的透明性和对等性方面还是存在较大的改进空间。比如对于系统配置和系统性能，我们可以提供相关的API或者数据查询服务来开放这些数据。

有两个指标是业务格外关注的，一个是数据延迟，一个是连接数情况，这个是和我们预设的情况偏差较大的情况，我们需要引起注意。

在技术细节上，他们也存在一些疑惑，那就是对于一些指标的量化，比如CPU监控指标，我们设定阈值是30%，现在的状态是20%，业务同学在查看的时候大多数情况是没有概念的，如果没有量化的指标其实也不知道20%是高还是低，而我们如果提供详尽的文档这些信息也不一定能够充分利用起来，所以我们可以对指标数据通过可视化来衔接，比如我们显示的CPU监控曲线图，有一条阈值线（在这里就是30%），通过阈值来作为参考，高还是低，就一目了然了。

MySQL业务巡检的维度设计

我把整体的巡检信息分为了三个维度：系统，数据库和业务，整理成了如下的脑图：

大部分数据是通过数据字典的配置信息得到，而对于业务巡检来说，更有意义的便是后面三类信息的聚合。

通过后面三类信息的提取和聚合，能够根据设定的数据模型来发现一些潜在的问题。

对于系统巡检问题，主要是面向运维同学，需要作出响应和明确的处理方法，而对于业务同学而言，就是一种透明的处理方式，比如业务同学发现某个服务产生了问题，可以通过系统的配置信息和监控报警来确认是不是服务出现了问题。在这个时候他们可以主动提取这些信息，这就是一个自助服务的初衷。

对于数据库巡检，对于业务同学来说就是一种全新的补充，比如对于业务同学开放了VIP,但是实际业务中可能是一主多从的架构，那么业务同学就需要了解目前的架构方式，比如一主多从，那么就可以使用多个从库提供读写分离的服务，而不是仅仅告诉一个VIP就完事了。通过数据库信息的补充，能够减少业务处理中的更多确认环节，最起码业务同学提出一个需求就可以明确知道你们理解问题的维度是不是基本平衡。

对于业务巡检，这是整个巡检的核心任务，对于业务同学，他能够接触到的就是数据库，表和索引了，但是绝大多数情况下，业务同学压根不知道自己所处的环境是否存在问题，是否配置得当等。在权限允许的情况下，我们可以提供这样的自助服务来明确告诉业务同学这样做是有问题的，这样做是有风险的。这样做有几个好处，一种是由被动变为主动，主动发现问题主动提示，一般来说对于业务同学是一种相对友好的方式，远比出现问题被动处理要好得多。另外一种就是如果这个问题很严重，但是不好协调，我们可以通过专业报告的方式来提前告知，在多次提醒无效的情况下，如果出了问题，对DBA同学也是一种无形的保护。