从一个Rac故障的分析谈起

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