云智慧 AIOps 社区是由云智慧发起，针对运维业务场景，提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交流社区。该社区致力于传播 AIOps技术，旨在与各行业客户、用户、研究者和开发者们共同解决智能运维行业技术难题，推动 AIOps 技术在企业中落地，建设健康共赢的AIOps开发者生态。
引言
近年来，随着IT系统监控能力的日益成熟，IT系统运行时问题的根因分析领域吸引了很多研究者的目光。本文通过调研大量运维领域根因分析的相关文献，并结合运维的实际需要，将根因分析问题进行了拆解，并对各子问题的解决方案进行了总结和分析。
一、IT系统及其稳定性的概念及抽象
IT系统，即IT基础设施。其定义千差万别，但一般认为是包括运营整个组织所必需的一系列物理设备和应用软件的集合，也包括由管理层预算所决定的组织范围内的人和技术能力的服务集合。业界经常提到的信息技术硬件、软件、服务方面的投资，其实就是IT基础设施。对于企业来说，这些设施能够为客户服务、与供应商建立联系和内部管理提供基础。IT基础设施的支出往往占到大型企业信息技术支出的25%-30%。IT系统运维的任务要尽可能保证服务运行环境的稳定性——即在有限的IT基础设施所提供的资源条件内，保证服务得以平稳运行。如图1所示，通过监控系统运行状态（状态监控），运维人员需要分析其中的故障点（故障检测），并通过回溯排查问题的源头（根因分析），进而对系统进行管理（控制策略及控制信号生成），以使系统运行恢复正常或保持平稳。
根因分析作为 IT 运行的重要组成部分，旨在找出哪些事件真正触发了 IT 系统中的现象或症状。与临床诊断类似，操作人员通过综合分析指标数据和系统日志，判断系统的主要问题在哪里，从而实现故障定位。在很多企业当中，出于对控制成本，维持服务稳定等方面的考虑，根因分析技术是有巨大需求的。良好而成熟的根因分析技术可以帮助系统的运维人员快速定位到系统问题，从而加快问题的修复速度，以尽量小的代价解决IT系统在运行过程中遇到的问题，增加系统的平稳运行时间，减少企业损失。在图1中，根因分析作为问题发现模块和问题解决模块之间的枢纽环节，起到非常重要的作用。一方面，当今的IT系统十分复杂，系统动辄上千节点，且节点之间的结构和功能高度耦合，单点的问题也往往有相当大的影响范围，使得运维人员往往无法直接确定系统的故障点。另一方面，为了化解系统故障带来的影响，运维人员修复系统需要以根因分析的结果作为依据来对症下药，使得系统得以在尽可能短的时间内恢复正常。
传统运维需要通过人工方式进行。运维人员在该阶段排查故障根因往往需要经历艰辛的过程，需要通过查看系统日志、监控指标，了解系统状态，才能推断系统故障的原因所在。而随着自动化运维的发展，系统的自动监控和信息收集日趋完善，运维人员对系统的监控越来越直观，且实时化程度大大提高。在面对小型IT系统时，自动化运维极大地加强了运维人员对系统的掌控能力，得以减少运维人员在缩小问题根因范围方面所投入的工作量。但与此同时，随着DevOps和云技术的发展，IT系统的规模变得越来越大，一个独立系统拥有上千节点已不算罕见。另外，服务的微服务化也使得IT系统的结构变化越来越迅速，系统结构对于大型系统的根因分析，由于监控数据量庞大，仅仅依靠运维人员来进行根因分析便显得捉襟见肘。
由于人工排障仍然具有诸多不足，自动化的根因分析能力便成了大家关注的热点。自动化的根因分析，是利用算法对给定的故障问题进行自动化分析，输出推荐结果来辅助运维人员排查系统问题的过程。实现自动化的根因分析，可以减轻运维人员的工作负担，减少系统问题的平均修复时间，提高系统的平均可用时长。另外，对于C端的企业来说，它更是减少客户投诉，减少运维成本，进而提高经济效益的重要手段。
二、根因分析思路与方法总结
根因分析（root cause analysis）一词本不是运维的发明。在IT领域里，根因分析起初是指分析导致程序运行异常的问题点，即我们平时所说的“找bug”。后来，随着运维与开发变得越发密不可分，开发口中的根因分析一词也逐渐拓展到了运维行业，演变成我们现在理解的IT运维中的根因分析。
顾名思义，根因分析是一个从问题现象探究到问题本质的过程。根据IT运维本身的特点，根因分析问题可以进一步分成两部分。首先，我们需要从宏观层面上确定问题发生的位置，给出相关的位置信息和大致的问题范围；这个过程我们称之为根因范围压缩。其次，我们要根据根因范围压缩的结果对单点进一步进行排查，具体定位到节点上的问题事件，为运维人员解决问题提供相关的逻辑证据；这个过程我们称之为根因事件查找。
在下面的篇幅中，我们分别介绍目前已有的针对根因范围压缩和根因事件查找的思路和方法，并对各方法的优缺点进行简单的分析。
1、根因范围压缩方法
根因范围压缩的主要目的是从IT系统庞大的监控数据当中筛查出问题的主要故障点。因此，该过程中所用的方法主要以数据驱动为主，运维逻辑为辅，通过数据的统计特征和运维经验的结合来筛选出问题源头的范围。由于数据驱动的模型和方法不可避免地会受到数据质量的影响，因此该过程也需要对结果的可信程度进行估计。
基于分类器的模型，例如决策树、支持向量机（二分类模型）、神经网络（二分类或多分类）等模型，将系统状态转换为特征，通过对系统的特征和特征之间的隐含逻辑进行学习，从而对系统所处的状态和对应的根因范围进行判断。通过统计学习或机器学习的手段，分类器模型都可以很方便地进行对系统约束关系的自动抽取，从而推断出不同情况下的根因范围，因此该类模型具有较好的适用范围：只要能对系统的特征进行提取和对数据进行标注，往往可以使用该类模型进行根因范围压缩。但随之而来的是，基于分类器的方法普遍具有结果可解释性比较差的问题，且系统知识隐含在模型结构中；对于根因分析问题，我们很难验证模型所学到的“运维知识”是否真实存在。另一方面，目前我们还未发现有较为有效的特征提取和筛选的通用方法。对于不同的运维数据，需要关注哪些特征来解决根因范围压缩的问题，也需要经过一定时间的积累。因此，此类方法对系统监控数据的数量和质量是有一定的要求的。
此外，还有一类较为常见的模型例如马尔可夫模型，随机Petri网等，通过对系统结构的模拟，利用内置在模型中的运维经验对根因范围进行估计。此类模型的特点是，以数据为导向，通过图模型搭建系统的大致框架，而后通过机器学习的手段确定模型中转移关系的概率分布，从而自动生成运维知识的概率模型。在此类模型中有现阶段比较流行的根因分析思路，即在节点或指标的关联拓扑上，利用统计学习进行系统建模，而后将运维经验设计为算法逻辑进行根因范围压缩。例如，一些方法利用故障的分布特征对根因位置进行识别，其前提假设为，如果大量异常业务经过某节点，则该节点成为根因的可能性会更大。该系列方法将系统模型与运维经验结合起来，可以起到较好的根因范围压缩效果。
总的来说，数据驱动的方法在缩小根因范围方面确实可以起到一定的作用，但其在大部分场景下依然无法对后续分析提供足够的帮助，对问题细节的展现并不充分。在更深层次上，因为“因果性”与“相关性”两个概念之间差异难以弥合，算法所抽取的相关性与系统故障传播的因果关系较难进行良好的对应。运维经验在算法中的融合可以适当地拉近根因分析中“因果性”和“相关性”的距离，但仍不足以使运维人员获取足够的信息进行问题的修复。因此，只有根因范围压缩的能力，我们仍然需要部分的人工问题排查，很难实现IT系统控制闭环的自动化。
2、根因事件查找方法
目前对根因事件查找问题的解决方法较为少见，学术界对此问题的讨论并不充分。贝尔实验室早在1999年提出了一个基于事件推理的根因分析框架。该框架提出了基于事件关系图的根因推理方法，并且考虑了不完全信息下的根因推理问题以及时序信息的引入对事件关系图建模能力的影响。该方法对现今的智能运维根因分析有很好的指导和借鉴意义，但可惜的是，后来对该方向的深入研究大部分转到了Petri Net上，渐渐地脱离了现在的运维场景——从分析运维资源占用情况的角度讲，这样的方法仍然可以解决一部分简单系统的运维问题，但随着运维系统规模越来越大，服务的数量越来越多，资源的占用情况越来越复杂，基于Petri Net的分析慢慢的开始变得无力。可以预见，直接以资源占用的细节开始进行运维故障的分析会给分析引擎带来极大的负担。另一个有趣的想法来自一篇于2012年发表在IEEE/ACM ToN上的论文。这篇论文中提到的G-RCA系统是根因分析的一种很好的思路——通过分析系统事件之间的关系来构建事件的因果图，而后利用不同的推理方法来进行根因事件分析。其中介绍的知识抽取方法，对于解决和刻画运维领域的根因分析问题也相当有借鉴意义。另外，其他一些基于SAT理论，诱导逻辑程序（概率模型或确定模型）等的根因推理的框架或模型，也在部分研究中提到过，但因推理的复杂度过高（尤其是一些非on-the-fly的方法）或与运维场景的需求相去甚远，并未有在IT运维场景落地的前景。
开源福利
云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时，飞鱼也提供了灵活的拓展能力，支持组件开发、自定义函数与全局事件等配置， 面向复杂需求场景能够保证高效开发与交付。
点击下方地址链接，欢迎大家给 FlyFish 点赞送 Star。参与组件开发，更有万元现金等你来拿。
GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish
Gitee 地址：https://gitee.com/CloudWise/fly-fish
