上周五一个客户系统出现了性能问题，事后用DSMART做了分析，最后定位是几个GC比较严重的SQL并发出现，把三块千兆网卡组成的RAC INTERCONNECT网络打爆了，导致GC出现性能问题。
虽然通过工具定位了问题，我们也发现目前的基于知识图谱的诊断与专家诊断的差距。在专家的协助下，这个问题不难定位，只要发几份报告给专家就可以完成了，不过如果离开专家协助，仅仅通过工具并没有直接给出一个结论。通过几条诊断路径给出的问题发现，如果对RAC故障诊断有经验的运维人员也很容易定位问题，但是如果对RAC分析不那么精通的运维人员还是不太容易快速定位问题。
这是因为知识图谱把诊断路径中的点都切分为一个个知识点，这些知识点之间的关系完全依靠数据驱动来关联的，而分析一个复杂问题，是多知识联动的结果，和这个图谱的推导链并不完全相同。
专家在做诊断路径探索的同时会做十分复杂的衍生关联，并不断裁剪不可能的路径。这方面智能算法还差的很远。哪怕是根据专家经验的下钻，每条路径里也缺乏所有的关联思考，因此每条路径虽然都能发现问题，但是这些问题的归类分析却很难实现。
如果要解决这些问题，必须在诊断路径推进过程中不仅仅做简单的临近发现和社区发现，也需要具有一些正则表达式来存储更为复杂的专家经验。如果能做到这一点，那么专家经验与泛图谱推理才能融合在一个新框架中。专家知识梳理也要突破专家的思维常规，可以通过图谱加正则表达式表达出来。这本不是专家思维的本质，而是做了一定的变形，也只要进行了这种变形，专家知识才能更好的自动化。
今早在机场突然想到这些，先记录下来吧，如果能够实现这个框架，那么智能诊断能力会有较大的提升。不过我们目前的图谱离这个目标还有一定的距离，要做这个图谱，其工作量也比目前我们的2.0版本大很多。仅仅依靠我们一家企业的力量恐怕也是比较困难的。一定要借助社区的力量才能真正做好。
今早的这些想法就作为3.0的知识图谱的一个初始想法吧，所以我还是把这段有点云山雾罩的思想写下来了。
