通常业务通常比较关心哪些指标？我们的巡检是不是也可以换个方式来做，既能服务于业务，也能体现我们工作的深度和广度，这样一来，我们提供的就不是一个黑盒服务，而是可以转变为更加主动的自助服务了，简而言之，目标就是让别人看得懂的巡检。自助巡检设计的初衷就是基于这样的情况，如果换一个角度，在做好本职工作的前提下，也让别人效率提高，我们的服务才更有价值。

　　业务巡检应该关注什么？

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

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

　　我们在和业务沟通的时候，期望得到体系化的信息，所以在进行沟通调研之前，我们需要了解下应用关注的问题，大体分为这几类：问题需求、时间周期、结果预测、权重、容易衡量、重要紧急、期望支持效率提高的需求、周期较长，需要迭代优化、重新适配操作方式，周期相对较长、重要不紧急、期望支持更灵活的需求、周期较长，改动难度较大、结果难以量化、不重要不紧急等等。为了避免范围铺的太大，难以聚焦，我们需要做一些引导。以下是我们预设的一些问题和业务提出的问题，整理后的结果：

　　从沟通的情况来看，他们对于很多需求还是很迫切的，但是如果你不去问，可能他们也不知道该找谁，所以在信息的透明性和对等性方面还是存在较大的改进空间。比如对于系统配置和系统性能，我们可以提供相关的API或者数据查询服务来开放这些数据。有两个指标是业务格外关注的，一个是数据延迟，一个是连接数情况，这个是和我们预设的情况偏差较大的情况，我们需要引起注意。

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

　　巡检的维度设计

　　整体可以分成巡检信息分的三个维度：系统，数据库和业务。大部分数据是通过数据字典的配置信息得到，而对于业务巡检来说，更有意义的便是后面三类信息的聚合。通过后面三类信息的提取和聚合，能够根据设定的数据模型来发现一些潜在的问题。

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

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

　　对于业务能够接触到的就是数据库，表和索引了，但是绝大多数情况下，业务根不知道自己所处的环境是否存在问题，是否配置得当等。在权限允许的情况下，我们可以提供这样的自助服务来明确告诉业务这样做是有问题的，这样做是有风险的。这样做有几个好处，一种是由被动变为主动，主动发现问题主动提示，也是一种相对友好的方式，远比出现问题被动处理要好得多。

　　如需要了解电子巡更、巡更棒、巡更系统、巡更、巡检的可继续关注慧友安的动态，我们会随时更新，及时上传客户的使用反馈体验，无论是简单的修改，还是复杂的功能定制，我们都可以快速地为您提供合适的解决方案。我们坚持：“您提要求，我们来做”为服务宗旨。我们已为100多家公司进行OEM、ODM研发生产。