我们认知中的巡检设计大多是一种被动的方式，即你希望做什么，按照这个思路和流程来设计，如果希望巡检能够发挥出强有力的支撑，那么我们需要转化被动为主动，即思考巡检数据对我们有什么用处？
有的同学可能还不大理解，我们来举个例子，比如我们会每天收集数据库中的表信息（数据库，表名，表数据大小，索引大小，表结构变更时间，碎片情况等），这样一份看起来简单的数据如何发挥余热的，我来给出一个列表：
1）冷数据，一些长时间未操作的数据，可以通过数据量和时间维度进行权衡
2）库中的表过多，可以通过统计的方式得知哪些环境是属于不规范环境，这类问题通常感受不到，但是一出问题哪里都是问题
3）一些没有用到的表，临时表和备份表，这些表像牛皮癣一样，我们要对数据库做下清理。
4）周期表探测，如果一些业务存在周期表需求，那么通过反向的方式可以很轻松找出那些日报，月表等周期表
5）数据库的特性和业务类型不匹配，如果表数据写入过多，很可能是日志型业务，可以根据一个或多个维度来评估是否和现有的业务类型匹配
6）预测数据量变化，可以通过历史数据的变化建立模型预测近一段时间的数据量变化
7）数据生命周期管理，有了时间维度的信息，我们可以建立数据生命周期管理模型，来通过多个维度来进行表结构变更的追溯。
8）权限和安全隐患管理，我们可以通过全局的方式来评估现有环境存在的隐患，比如那些流程外创建出的表，流程外删除的表，可以做得统筹的管理。
以上只是抛砖引玉，主要想表达的就是巡检在一定阶段之后会产生数据分析的更大价值，让我们对更多的问题具有主动的管理方式，而从一开始就希望想全，想好也是不切实际的。
此外，我需要补充的就是运维体系的建设中需要深入融合巡检。
在我们的运维体系中，其实一直有一块短板，那就是单纯依靠监控和报警模块，工作效率和质量是一种被动的方式。
我们可以假设一个场景，你在节假日的时候在外面游玩，刚在高速路上的时候，收到了一条报警，一个关键业务系统的磁盘空间超出阈值（假设是80%），这对你的旅游兴致来说是大受影响，虽然这样一件事情处理的难度不高，但是我们总是需要花费那么些额外的时间和精力去处理，这个代价对于个人来说是很高的。
如果我们能够有一种机制去缓解这个问题，比如我们马上收到巡检信息提示的一封邮件，可以看到这个磁盘空间的增长是平缓的，而不是那种业务增长导致的尖峰，那么这个问题处理的时间就可以适当后延，对于正常的生活和工作是收益很大的，按照这种机制，在不影响业务的前提下，我们可以把很多干扰我们的大量碎片时间，作为一种延迟处理的方式，这是一种运维信仰和工作理念。
以下是一个监控，报警，巡检的三体一体集成方案。
我们来对这个图做下解释：
1）监控和报警，这是常规的运维体系，监控达到阈值触发报警
2）报警和巡检，通过报警能够异步调用巡检接口，对已有的数据库业务进行巡检，比如发送巡检可视化报告或者巡检提示信息，让巡检工作不再被动，而是因需而动
3）巡检和监控，通过巡检机制的完善，能够发现更多的问题，然后建立新的监控指标
4）监控和巡检，如果监控指标未达到报警阈值，并不一定意味着没问题，但是通过一些监控指标来触发巡检就可以把这块空白补上，比如一个系统的磁盘空间80%为阈值，在1:00~2:00，磁盘空间使用率从20%增长到70%，虽然不会触发报警，但是短时间的增量较多，我们可以设定70%的阈值为巡检模型所用，就可以通过巡检模型来识别出这类问题
