从智能化辅助分析到智能化诊断

智能化诊断与自动化问题发现是智能化运维的高级目标，虽然很多智能化运维方案解决商号称能实现智能化诊断分析，但是实际上真实环境的案例目前还很少见。这是因为IT系统是十分复杂的。我们以数据库智能化运维为例，数据库是IT组件中较为复杂的，这些年我们也在DBAIOPS的技术路线上做一些探索。不过目前还仅仅处于智能化辅助分析的阶段。通过对监控数据的自动化分析，自动发现一些系统可能存在的问题，推送给运维人员，由运维人员根据这些推送的结果来定位问题或者做半自动的诊断分析。

自动化诊断工具可以自动发现系统中存在的异常，但是要想真正的实现精准定位依然是具有很高的难度的。虽然智能化诊断已经自动发现了对应PG脏块写入比例异常这个问题中存在两个疑似问题，但是还是不能十分明确的告诉你根因是什么。

我们来看一个实际的案例，这是针对一个金融用户的离线数据做远程分析时发现的问题。首先我们发现了在系统中存在一个数据库健康突然下降的问题。在健康分较低位置我们可以看到操作系统维度的丢分比较多。



如果我们放大左面的时间窗口，通过一个1天的数据看，这种健康分抖动出现的频率还是挺多的（看下面的圆圈位置）：



通过查看操作系统维度的明细可以明显看到，当健康分较低的时候，I
O
延时存在问题：



I
O LATENCY
指标居然高达60毫秒，查看指标的明细情况，可以看出，这个指标抖动的十分明显，经常会出现I
O
延时比较高的时段出现。

IO延时存在一定的周期性抖动，抖动从不到10毫秒到几十毫秒。既然发现这个问题，那么我们需要分析其产生的原因。点击“智能指标分析”按钮，选择其中的“关联指标分析工具”，发现IO延时与IO吞吐量相关的指标的波动行为极为相似。

通过上面的关联分析，我们可以很容易想到，应该是有些SQL产生了较多的物理读，从而让IO的延时指标变坏了。正好“TOP SQL物理读”也是智能诊断工具推荐的一条诊断路径，于是我们通过“TOP SQL物理读”进行下钻分析。工具发现存在几条IO比较高的SQL。

这时候一些经验比较丰富的老司机可能可以看到
dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring no_substrb_pad no_expand

这些字样了，通过这些资源，我们有理由相信这些SQL都是动态采样产生的。让用户检查了一下系统，发现确实有几张核心表的统计数据缺失，导致了动态采样。

这个案例实际上是一个典型的智能化辅助诊断的案例，通过一系列的智能化分析手段来帮助运维人员更加快速和准确的定位了系统的问题。如果没有这些智能化诊断的手段配合，问题定位的过程会复杂的多，时间上也会需要更多。而在智能化分析工具的辅助下，发现问题到定位问题仅仅花费数分钟而已。

    不过这依然不是我们的终极目标，我们希望能够做到智能化溯源与根因定位。似乎上面的过程离这个目标已经很近了，不过通过对这个过程的复盘，我们发现其中还有两个重要的环节是严重依赖于运维人员的。

第一个环节是从关联分析发现的问题中自动定位到是存在“坏”SQL导致了这个问题。在这一点上，一个有经验的DBA可以很容易从问题的表象找到问题的原因，但是作为一个没有任何智能的计算机系统，如何能够根据数据推理到这一步，还是存在很大的难度的，这也是下一步D-SMART要重点突破的地方。

    第二个环节是临门一脚的问题，如何从发现的S
QL
中发现动态采样的问题。这个问题相对于上一个问题来说要简单的多，在系统中增加一个
SQL
审计规则和故障定位规则，就可以实现这个发现的自动化。

从上面的这个案例我们看到了智能化辅助分析与智能化诊断的差别，虽然从表面上看只是差了少数的几步，不过在技术上，这种差距要比你看到的大得多，这几部就像是我们攀登珠穆拉玛的时候的最后几百米，可能对于大多数人来说，这几百米永远也上不去。因为我们可以十分容易的构建出一个个的工具，来实现一些知识的自动化，但是让知识连贯起来，用于一个完整的分析是十分具有挑战的工作，目前为止，针对一些复杂的运维场景，比如数据库运维，还没有看到多少真正实用的智能化诊断工具出现。

因为要实现真正的智能化诊断有两个难点，一个是网状的知识图谱如何构建的比较完善；另外一个是在诊断时如何不断地裁剪错误的诊断路径，从而找出问题的根因。虽然我们离真正的智能化诊断还很远，不过随着这项工作的不断深入，知识的不断积累，从智能化辅助分析到智能化诊断的升华就一定能实现。