昨天在机场候机的时候，突然有了一些想法，写了一些莫名其妙的话。其实也不是莫名其妙。对于从事运维知识图谱的朋友来说，可能还是能理解我在说什么。专家在分析故障时，是根据积累的经验和知识发现问题的。发现的依据是系统运行状态、指标、日志等数据。因为人同时具有记忆思维和逻辑推理能力，解决问题的方法大多来自于以往案例的积累和基于知识的逻辑推理。多年来，对于OracleRAC的性能问题和故障，大家研究得很透彻。下面是RAC常见??问题分析的思维导图。以上思维导图是专家整理的RAC性能分析的一些常见分析路径。根据专家头脑中相似的思维导图，人们的思维可以根据实际情况发散和收敛，非常灵活，而且不同的专家有不同的想法，发散和收敛的方法也不一致。不管怎样，只要高手们分析RAC问题的功力足够，定位到我说的用户RAC故障还是比较容易的。从事后分析可以看出当时的故障模型告警中有明显的RAC性能告警，因为如果问题出现后不解决问题，系统会反复告警严重的告警事件，所以告警时间在上图只是记录了最后一次告警的时间，不能作为根据时间判断告警发生的依据。对于gcblocklost告警，也可以使用诊断工具对这个问题进行下钻分析。通过点击“诊断分析”按钮，可以进行相应的分析。用户当时最渴望得到的是一个结论。D-SMART还提供了一系列用于分析的诊断工具。现场DBA点开几个工具，发现系统存在一些问题，包括TOPSQL、全局热块冲突、私网流量过大、PING延迟过高等问题。但是以他的经验，无法判断是SQL问题还是系统其他问题导致的问题。其实领导等的不是分析这些问题，而是决定是否重启应用来解决问题。如果你想清楚地回答这个YESORNO，你确实需要一定的经验，所以现场DBA不能直接根据这些分析结论来回答这个问题。事实上，专家在从某条诊断路径下钻分析时，并不一定会根据这张脑图遍历问题的可能路径，会在中间跳转，甚至重新启动一张新的脑图。自动化运维工具要么使用一般的异常检测进行分析，要么只能沿着知识图谱扫描各种可能性，通过就近发现。如果分析工具写得好，那么覆盖整个分析的逻辑就会非常复杂，不灵活。一旦系统状态稍有不同，就可能无法完成完美的分析。但是，如果考虑到足够的灵活性，将分析过程划分为多个知识点，通过知识点之间的关联发现自动发现下钻路径，实现遍历，这将完全打乱整个分析过程，非常难的。以达到最终准确的根本原因归纳。这是因为我们最终是要定位根源来辅助决策，而不是找问题。如果现场有专家支持，或者专家可以随时快速响应，那么找到问题点就可以定位到根本原因，但如果仅仅依靠现场运维人员，那么工具就需要更多准确的结论。有两种方法可以解决这个问题。最简单的就是我前几天说过，把智能运维的最后一公里交给专家，这样会大大降低智能运维工具的技术难度。只要能统一指标标准，让远程专家与现场运维人员、被运维的数据库系统用同一种语言进行交流，就可以构建完善的运维系统。专家无需到现场采集分析数据，仅通过智能运维工具生成的报表，帮助现场人员快速定位问题，实现7*24专家快速介入，实现高质量和低成本的分析位置。当然，我们还有更高的目标，就是提升运维诊断工具的智能分析能力。需要通过灵活的组合来实现对知识点的分析，同时保证问题收敛和推理得到合理的结论。在软件实现上，我们不能完全采用树状发散结构。必须将影响RAC性能的因素拉平，分解为同级的多个检测点。如果把运维知识分解到这个粒度，那么每个检测点都会发现一些标准的状态异常，比如热块冲突，比如网络故障等等，最后根据这些异常的总结，组合问题可以获得发现。然后根据这个组合对问题进行收敛分类，进一步定位问题的根源。目前D-SMART中智能指标分析的实现与此类似，但是智能指标分析的范围太广，根因收敛只能达到一定范围，不能很精准。针对具体问题的根因分类要简单得多，发现的问题类别也会更集中、更具体，因此根因定位也能更准确。比如今天的RAC问题无非就是网络过载、网络故障、TOPSQL、事务和锁冲突、数据维护、数据库参数配置等方面。要采用这种方法，对某个问题的分析必须非常透彻，主要的分析要素已经很好地总结出来。相当于对专家头脑中的分析模型进行高度采样，然后辅助一些验证算法，使最终的诊断结论接近专家分析。要实现这样的分析，首先需要构建一个分析某个问题的指标集，然后构建一个分析该问题的知识点集合，定义一组问题发现的类型。以及根本原因收敛的规则图。有了这些基础，自动化的根本原因定位就准备好了。对于一些关键问题，采用上述方法实现精准分析还是可以实现的。但是算法的设计需要运维专家参与，一个专家不可能知识面广。因此，要构建覆盖面广、分析准确的运维自动化系统，必须依托生态。通过生态可以发现更多的故障模型，通过生态可以更快的完成知识图谱的构建。依托生态，可以对工具进行验证，从而更快地迭代提升工具的能力。
