AIOps代表运维操作的人工智能(Artificial Intelligence for IT Operations)， 是由Gartner定义的新类别，Gartner的报告宣称，到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，远远高于2017年的10%。
Gartner在为AIOps作出如下定义：AIOps平台是结合大数据、人工智能（AI）或机器学习功能的软件系统，用以增强和部分取代广泛应用的现有IT运维流程和事务，包括可用性和性能监控、事件关联和分析，IT服务管理以及运维自动化。AIOps 可以被看作是对核心 IT 功能的持续集成和部署 (CI/CD)
国内对AIOps有深入研究的清华大学裴丹教授对AIOps的解释：是将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维没办法解决的问题。AIOps 不依赖于人为指定规则。
早期的运维工作大部分是由运维人员手工完成的，这被称为手工运维或人肉运维。这种落后的生产方式，在互联网业务快速扩张、人力成本高企的时代，难以维系。
- 行业领域知识：应用的行业，如互联网、金融、电信、物流、能源电力等，并熟悉生产实践中的难题；
- 运维场景领域知识：包括异常检测、故障预测、瓶颈分析、容量预测等；
- 机器学习：把实际问题转化为算法问题，常用算法包括如聚类、决策树、卷积神经网络等。
二、AIOps 目标、原则及能力框架
AIOps，通俗的讲，是对规则的AI化，即将人工总结运维规则的过程变为自动学习的过程。
具体而言，是对我们平时运维工作中长时间积累形成的自动化运维和监控等能力，将其规则配置部分，进行自学习的“去规则化”改造，最终达到终极目标：“有AI调度中枢管理的，质量、成本、效率三者兼顾的无人值守运维，力争所运营系统的综合收益最大化”。
2.1、AIOps 目标
利用大数据、机器学习和其他分析技术，通过预防预测、个性化和动态分析，直接和间接增强IT业务的相关技术能力，实现所维护产品或服务的更高质量、合理成本及高效支撑。
2.2、AIOps 能力分级
AIOps的建设可以先由无到局部单点探索、再到单点能力完善，形成解决某个局部问题的运维AI“学件”，再有多个具有AI能力的单运维能力点或学件组合成一个智能的运维流程，如智能化的监控预测及告警，免干预的自动化扩缩容，免干预的性能调优、免干预的成本组成调优等。
- 开始尝试应用AI能力，还无较成熟单点应用
- 具备单场景的AI运维能力，可以初步形成供内部使用的学件
- 有由多个单场景AI运维模块串联起来的流程化AI运维能力，可以对外提供可靠的运维AI学件
- 主要运维场景均已实现流程化免干预AI运维能力，可以对外提供可靠的AIOps服务。
- 有核心中枢AI，可以在成本、质量、效率间从容调整，达到业务不同生命周期对三个方面不同的指标要求，可实现多目标下的最优或按需最优。
2.3、AIOps 能力框架
学件：亦称AI运维组件类似程序中的API或公共库但API及公共库不含具体业务数据只是某种算法，而AI运维组件或称学件则是在类似API的基础上兼具对某个运维场景智能化解决的“记忆”能力，将处理这个场景的智能规则保存在了这个组件中。
- “可重用”的特性使得能够获取大量不同的样本；
- “可演进”的特性使得可以适应环境的变化；
- “可了解”的特性使得能有效地了解模型的能力。
三、AIOps 平台能力体系
AIOps 工作平台的能力体系主要功能是为 AIOps 的实际场景建设落地而提供功能的工具或者产品平台，其主要目的是降低 AIOps 的开发人员成本，提升开发效率，规范工作交付质量。AIOps平台功能与一般的机器学习(或者数据挖掘)平台极为类似此类产品国外的比如Google的AutoML(https://cloud.google.com/automl/)，AIOps平台功能模块图如下：
AI建模服务能力示意图如下:
- 交互式建模功能：该功能支持用户在平台上交互式的进行模型的开发调试，通过简单的方法配置完成模型的构建。
- 算法库：用户可以在算法库中找到常见常用的算法直接使用，算法按照用途分类，以供用户方便的使用。
- 样本库：样本库用于管理用户的样本数据，供用户建模时使用，支持样本的增删改查等基本操作。
- 数据准备：该功能支持用户对数据进行相关的预处理操作，包括关联、合并、分支路由、过滤等。
- 灵活的计算逻辑表达：在基本常用的节点功能之外，用户还需要自由的表达一些计算逻辑，该需求主要是通过让用户写代码或表达式来支持。
- 可扩展的底层框架支持：平台本身要能够灵活的支持和兼容多种算法框架引擎，如Spark、TensorFlow等，以满足不同的场景以及用户的需求。
- 数据分析探索：该功能是让用户能够方便快捷的了解认识自己的数据，用户只有基于对数据充分的认识与理解，才能很好的完成模型的构建。
- 模型评估：对模型的效果进行评估的功能，用户需要依据评估的结论对模型进行调整。
- 参数以及算法搜索：该功能能够自动快速的帮助用户搜索算法的参数，对比不同的算法，帮助用户选择合适的算法以及参数，辅助用户建模。
- 场景模型：平台针对特定场景沉淀的解决方案，这些场景都是通用常见的，用户可以借鉴参考相关的解决方案以快速的解决实际问题
- 实验报告：模型除了部署运行，相关挖掘出来的结论也要能够形成报告，以供用户导出或动态发布使用。
- 模型的版本管理：模型可能有多个不同的版本，线上运行的模型实例可能分属各个不同的版本，版本管理支持模型不同版本构建发布以及模型实例版本切换升级等。
- 模型部署应用：模型构建完成后需要发布应用，模型部署应用功能支持模型的实例化，以及相关计算任务的运行调度管理。
四、AIOps 团队角色
AIOps作为一个团队，由不同角色组成，一般有三种不同角色，他们是运维专家、数据科学家、智能运维研发工程师，以下介绍三种角色分工：
- 特征：具有丰富的运维领域知识、熟悉较为复杂的运维问题、具备解决运维难题能力。
- 职责：运用机器帮助运维人员完成基础性和重复性的基层运维工作；人工处理机器还不能处理好的运维难题；基于经验对于较为复杂的运维问题给出最终决策—不断训练机器。
- 特征：具备编程、数学、统计学、数据可视化、机器学习等能力。
- 职责： 致力于智能运维平台架构、模型标准、数据分析方法；不断应用最新的机器学习技术设计优化智能运维算法；监督智能运维系统性能并实施优化和改进。
- 特征：良好的开发语言基础、大数据处理技术能力。
- 职责：数据采集、自动化处理、实现和运用算法等。
角色协同关系如下图：
五、AIOps 常见应用场景
AIOps 围绕质量保障、成本管理和效率提升的基本运维场景，逐步构建智能化运维场景。
- 在质量保障方面，细分为异常检测、故障诊断、故障预测、故障自愈等基本场景；
- 在成本管理方面，细分为指标监控，异常检测，资源优化，容量规划，性能优化等基本场景；
- 在效率方面，分为智能变更、聊天机器人等基本场景。
（注：三者之间不是完全独立的，是相互影响的，场景的划分侧重于主影响维度。）
无论是效率提升，质量监控，还是成本优化，都离不开最基础的数据采集，它是整个AIOp的基石。 AIOps提高运维生产力的一种方式就是把质量处理流程中的人力部分尽可能的都替换成机器来做。在机器的分析过程中系统运行过程中的每一个部件都需要数据支持。无论是海量数据采集、还是数据提取方面都离不开大数据技术。
从数据采集的层面来看，运维数据的采集往往是实时的，数据采集端需要具备一定分析能力，综合考虑用户流量、隐私服务器压力等多个因素，尽可能的降低无效数据的采集，增加有价值信息的上报。
从数据提取的层面来看，运维的数据是多样化的，历史数据、流数据、日志数据、网络数据、算法数据、文本和NLP文档数据，以及APP数据、浏览器数据、业务系统运营指标数据等，从这些海量的数据中提取出正真有价值的指标化数据并可视化是进一步分析决策的前提条件。
而成本优化和效率的提升同样离不开数据的支撑。例如，开始实施成本优化的AIOPS前，需要尽可能多的收集目前的服务器、网络设备、应用服务、数据库等的性能信息，应用日志信息，tracing信息，以便对成本优化的效果进行评估。例如在搭建智能客服机器人的时候，就需要提供充足的问题库和相应的答案才能够建立好一个较优的模型。
三大方向的各阶段能力描述如下所示。
5.1、质量保障方向
异常检测：
- 运维系统中常见的两大类监控数据源是：指标和文本。前者通常是时序数据，即包含指标采集时间和对应指标的值；后者通常是半结构化文本格式，如程序日志、Tracing等。随着系统规模的变大、复杂度的提高、监控覆盖的完善、监控数据量越来越大、运维人员无法从海量监控数据中发现质量问题。智能化的异常检测就是要通过AI算法，自动、实时、准确地从监控数据中发现异常，为后续的诊断、自愈提供基础。异常检测的常见任务包括对数据源的异常检测，保证数据质量，以及对指标和文本的异常检测。
- 数据源异常检测：数据源会因为一些不可避免的原因存在一些异常数据，这些异常数据占比虽然很低，但是往往会引起整个指标统计值的波动，使得统计结果偏离真实的用户体验。AIOps需要自动、实时的动态设置阈值，去除数据源中的异常数据干扰，并能够区分系统真正发生异常时候的故障数据和数据源本身的异常数据，这种判断依赖于一些外部信息。
- 指标异常检测：包括单指标异常检测及多指标异常检测。
- 单指标异常检测：时间序列指标的异常检测是发现问题的核心环节，传统的静态阈值检测为主的方式，阈值太高，漏告警多，质量隐患难以发现；阈值太低，告警太多引发告警风暴，干扰业务运维人员的判断。AIOps通过机器学习算法结合人工标注结果，实现自动学习阈值、自动调参，提高告警的精度和召回率，大幅度降低人工配置成本。
- 多指标异常检测：运维过程中有些指标孤立来看可能并没有异常，但是综合多个指标来看，可能就是异常的。有些单指标表现是异常的，但是综合多个指标来看可能又是正常的。AIOps需要能够综合多个指标综合评判系统指标异常，提高告警的准确性。
3. 文本异常检测：文本日志常是在特点条件下触发生成的，并遵循一定的模板，即半结构化文本。传统的日志检测有两种方式：
- 根据日志级别：如Info、Warning、Critical进行报警，但由于其设定不准确或不满足实际需要，导致准确性差
- 通过设置规则：匹配日志中特定字符串进行报警，但该方法依赖依赖人工经验，且只能检测已知和确定模式的异常。
- AIOps需要通过自然语言处理、聚类、频繁模式挖掘等手段，自动识别日志出现的反常模式，结合人工反馈和标注，不断进行优化、完善。
故障诊断：
- 异常检测实现了运维人员对数据的感知，有了数据之后，智能分析可以进一步解放运维人力，提高运维效率，故障诊断是智能分析的核心部分，主要包括基于人工故障库的故障诊断和基于数据挖掘的故障诊断。
- 基于人工故障库的故障诊断：日常运维过程中，运维人员积累了大量的人工经验，运维过程中的大部分故障都是重复的、人工能够识别的异常。重复问题的定位浪费了大量的人力而且人工确认过程往往是比较滞后的。AIOps把人工专家经验固化下来，对常见问题实现分钟级内自动诊断，运维人员收到的告警信息中就需要包括故障定位的结果信息。
- 基于数据挖掘的故障诊断：人工经验可能存在偏差，人工认为的原因可能并不是问题的根因，当有些故障首次发生没有人工经验可以借鉴的时候故障根因也难以定位。尤其随着微服务的发展，业务的组网变得更加复杂，模块多带来的消息路由多、依赖多，问题的定界定位分析更为困难；人工故障决策效率挑战巨大。 对于已知故障，AIOps能够综合故障数据和人工经验自动提取故障特征，生成故障特征库，自动匹配、自动定位故障、对于未知故障AIOps需要根据故障特征推演出可能的故障原因，并在人工确认后加入的故障特征库。
故障预测：
- 故障的出现一般不是突然的，就比如网络故障来说，往往从丢包开始到网络不可用是有一个演变的过程，依据海恩法则，每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患，开展主动健康度检查，针对重要特性数据进行预测算法学习，提前诊断故障，避免服务受损；常见场景：磁盘故障预测、网络故障预测（根据交换机日志的交换机故障预测）、内存泄露预测等等。
故障自愈：
- 智能分析实现了故障的诊断和预测，智能执行根据智能分析的结果实现故障自愈。传统的故障自愈的决策主要靠人的经验，人的经验能够覆盖的故障范围是有限的，而且人工无法保证7*24随时可以立即决策与处理。AIOps能够提供完善的自动化平台在故障智能分析之后自动决策，实现自愈；常见场景：版本升级回退、DNS自动切换、CDN智能调度、智能流量调度等。
- 故障自愈是根据故障诊断的结果的输出（问题定位和根因分析），进而进行影响评估决定“解决故障”或“恢复系统”的过程。影响评估是对故障之后所产生的影响范围（系统应用层面、业务执行层面、成本损失层面等等）输出评估结果，并根据这个评估来决定要采用什么解决手段，甚至生成解决手段的执行计划。
5.2、效率提升方向
效率提升是运维的基本场景之一，随着业务的发展，运维系统的整体效率的提升就成为了运维系非常重要的一环。在这样的背景下，除了增加人力是远远不够的，还需要AIOps提供高质量，可维护的效率提升工具。
智能问答：
- 运维的目标是为了支持稳定，可靠的业务运行，而业务与业务之间既可能有相似性，又可能有差异性。但由于知识背景和对业务的认知差异往往出现以下情况
- 不同的业务人员或开发人员往往会询问运维人员一些相似的问题，运维人员的答案也是非常类似的，但人力被重复消耗。
- 面对同一个问题，运维人员的回答可能会出现差异，例如表达方式、措辞等，缺乏标准化可能造成误解。
- AIOps智能问答系统通过机器学习、自然语言处理等技术来学习运维人员的回复文本，构建标准问答知识库从而在遇到类似问题的时候给出标准的统一的回复。这样不仅可以有效地节省运维人员的人力成本还能够使得提问得到更加及时的回复。
智能决策：
- 许多运维管理工作都需要各种各样的决策，包括扩容、缩容、制定权重、调度、重启等内容。那么可能面临如下问题
- 运维人员可以根据自己的业务经验制定相应的决策。但是不同的业务有着各自的特点，不同的运维人员也有着自己的业务经验。如何将运维人员的这些经验有效地传承是个问题。
- 人的认知局限性，运维场景的复杂性可能导致最有经验的运维人员遗漏掉某些“不起眼”的“重要细节”，显然准确的决策还依赖足够充足的细节。
- AIOps智能决策一方面可以将运维人员的决策过程数据化，构建决策支持知识库，从而实现经验积累。另一方面由于系统掌握了从全局到细节的数据，再结合决策支持知识库，可以为更加准确的决策提供最有力的支撑。
容量预测：
- 运维工作不仅仅包含对当下的决策和处理，往往还需要根据业务的诉求对未来做出合理的规划，包括扩容的预测，缩容的预测等。由于对未来的规划时常存在不确定性那么规划过程往往需要大量的数据来支持，还需要大量的推演来确定。而人工预测的方式，一方面需要投入大量人力；另一方面运维人员的能力可能存在差异，使得推演的结果品质不尽一致。
- AIOps智能预测借助大数据和机器学习能力，结合运维人员的有效评估经验，甚至业务发展模式以及政策等，对目标场景实现高效的推演过程，最终使预测结果趋近合理范围。这样一来，不但是人力得以节省，关键在于由于预测效率的提升，使得过去难以重复耗时耗力的人工预测过程变得可以应需而变，不断修正预测结果，最终使业务诉求获得最佳预测收益。
5.3、成本管理方向
成本优化：
- 在成本优化方向，需要采取高可用的设计，提供更加合理的服务，包括接入层、业务层、存储层等。
- 在接入层需要提供合理的健康检查机制，更加智能的负载均衡算法，限定流量等工作。
- 在业务层不仅需要去除DB的强依赖，使用合理的降级，还要进行合理的压测、监控以及动态的负载均衡。
- 在存储层需要做的事情是容灾等关键工作。这样的话，可以使得内部数据的质量得到大量提升，外部数据的优先接入和动态选择。
- 对于设备采集的周期控制这个问题来说，过晚的设备采购可能会影响到业务的正常上线或扩展，而过早的采购也可能造成成本的浪费。于是AIOps 需要建立合理的模型并建立更好的规划，并据此计算更准确的设备采购计划，也能对成本进行更好的控制。
资源优化：
- 公司的运营成本优化项目一直是公司成本预算的关键一步。优化问题包括设备的优化、带宽、码率的优化等等。只有进行了合理的资源优化，才能够使得公司的成本得到有效的控制。不同的服务的资源消耗类型是不一样的，包括计算密集型，包括存储密集型等等；而对于同一个服务在不同的时间点资源消耗也是不一样的。
- 对于一个企业来说，识别不同服务的资源消耗类型，识别每个服务的资源瓶颈，实现不同服务间的资源复用是降低成本的重要环节。根据资源应用的性能指标可以大致分类成以下类别：
- 计算密集型：CPU使用率较高，常见于需要大量计算资源的搜索、推荐、数学计算等场景中
- 内存密集型：占用的内存使用率较高，如缓存服务
- IO密集型：网络IO繁忙或者磁盘IO操作繁忙，常见于爬虫、消息管道、分布式存储等服务中。
- 大型互联网公司里动辄上千上万的应用数，很容易有应用因为业务变化已经访问量不断缩减甚至已经下线，但是线上还占用着大量的资源，通过对应用的性能指标分析，筛选出各项性能指标都很低的应用，就可以识别出这些“被遗忘” 的应用，就可以跟业务负责人进行核对进行缩容或者下线。
- 目前大部分公司都已经使用了虚拟化或者docker技术，同一个物理机上的不同虚拟机或容器已经进行了很好的细粒度资源分配和隔离，所以对于同一台物理机可以进行混合部署不同类型的应用，如计算密集型应用、存储密集型应用、IO密集型应用混部在同一台物理机上，以提高更大的资源利用率，甚至一定量的“超卖”（通过共享部分资源，实现分配的总的资源数超过物理机的资源数）。对于一些灵活的计算任务：如Spark、Storm等计算类任务，还可以使用按时分配的策略，如白天运行在部分服务器上，而且夜间需要运行大批量计算的报表等任务时，利用业务应用夜间资源使用率低的特点把部分任务分配到业务应用所在的服务器上运行，充分利用这些业务应用的服务器的计算资源，提高整体利用率。
- AIOps通过密度管理、特性管理、碎片管理、木桶管理等方法，优化企业不同服务器的配比，发现并优化资源中的短板，提供不同服务的混合部署建议，最终实现智能化降成本方案分析服务。
性能优化：
- 性能的调优一直是运维的重要一环。如果性能优化得当则会减少实际的运算量，减少内存方面的滥用，提升服务器的性能。运维人员在其中并不能保证及时发现所有潜在的性能问题，很多时候也不知道什么的系统配置才是最优的系统配置，什么时候的权重配比才能够达到最佳的效果。AIOps 能够根据现网的实际情况，进行智能地调整配置，智能发现性能优化策略，提供智能化的优化服务。
六、AIOps 实践路径建议
6.1、未实现自动化运维时
AIOps的开展，受限于自动化数据采集，网络、磁盘、成本方面的工作难以深入发展。建议聚焦质量保障的原子场景。
6.2、已经实现自动化运维时
6.2.2、效率提升方向
6.2.3、成本管理方向
七、AIOps 实施及关键技术
为了实现成本管理、效率提升、质量保障的场景，根据Gartner的定义，AIOps产品或平台应包含下图所示的要素：
- 数据源：大量并且种类繁多的IT基础设施
- 大数据平台：用于处理历史和实时的数据
- 计算与分析：通过已有的IT数据产生新的数据例如数据清洗、去除噪声等
- 算法：用于计算和分析以产生IT运维场景所需要的结果
- 机器学习：这里一般指无监督学习，可根据基于算法的分析结果来产生新的算法
7.1、数据采集
- 数据采集：负责将智能运维所需要的数据接入至AIOps平台，所接入的运维数据类型一般包括(但不限于)日志数据、性能指标数据、网络抓包数据、用户行为数据、告警数据、配置管理数据、运维流程类数据等。
- 数据采集方式可分为无代理采集以及有代理采集两种：
- 无代理采集为服务端采集：支持SNMP、 数据库JDBC、 TCP/UDP监听、 SYSLOG、 Web Service、消息队列采集等主流采集方式。
- 有代理采集：用于本地文件或目录采集、容器编排环境采集、以及脚本采集等。
7.2、数据处理
- 针对采集数据进行入库前的预处理，数据从非结构化到结构化的解析、数据清洗、格式转换以及数据（如性能指标）的聚合计算，处理工作主要体现在几个方面：
- 数据字段提取：通过正则解析、KV解析、分隔符解析等解析方式提取字段
- 规范化数据格式：对字段值类型重定义和格式转换
- 数据字段内容替换：基于业务规则替换数据字段内容，比如必要的数据脱敏过程，同时可实现无效数据、缺失数据的替换处理
- 时间规范化：对各类运维数据中的时间字段进行格式统一转换
- 预聚合计算：对数值型字段或指标类数据基于滑动时间窗口进行聚合统计计算，如取1分钟CPU平均值
7.3、数据存储
- 数据存储是AIOps平台的数据落地的地方，可以根据不同的数据类型以及数据的消费和使用场景，可选择不同的数据存储方式。数据主要可分为如下几类：
- 数据需要进行实时全文检索、分词搜索：可选用主流的ElasticSearch引擎
- 时间序列数据：性能指标，主要以时间维度进行查询分析的数据, 可选用主流的rrdtool、graphite、influxdb等时序数据库
- 关系类数据以及会聚集在基于关系进行递归查询的数据可选择图数据库
- 数据的长期存储和离线挖掘以及数据仓库构建，可选用主流的Hadoop、Spark等大数据平台
7.4、离线和在线计算
- 离线计算：针对存储的历史数据进行挖掘和批量计算的分析场景，用于大数据量的离线模型训练和计算，如挖掘告警关联关系，趋势预测/容量预测模型计算，错误词频分析等场景。
- 在线计算：对流处理中的实时数据进行在线计算，包括但不限于数据的查询、预处理和统计分析，数据的实时异常检测以及部分支持实时更新模型的机器学习算法运用等。主流的流处理框架包括Spark Streaming, Kafka Streaming, Flink, Storm等。
7.5、面向 AIOps 的算法技术
- 运维场景通常无法直接基于通用的机器学习算法以黑盒的方式解决，因此需要一些面向AIOps的算法技术，作为解决具体运维场景的基础。有时一个算法技术还可用于支撑另外一个算法技术。 常见的面向AIOps的算法技术包括：
- 指标趋势预测：通过分析指标历史数据，判断未来一段时间指标趋势及预测值，常见有Holt-Winters、时序数据分解、ARIMA等算法。该算法技术可用于异常检测、容量预测、容量规划等场景。
- 指标聚类: 根据曲线的相似度把多个KPI聚成多个类别。该算法技术可以应用于大规模的指标异常检测，在同一指标类别里采用同样的异常检测算法及参数，大幅降低训练和检测开销。常见的算法有DBSCAN, K-medoids, CLARANS等应用的挑战是数据量大曲线模式复杂。
- 多指标联动关联挖掘：多指标联动分析判断多个指标是否经常一起波动或增长。该算法技术可用于构建故障传播关系，从而应用于故障诊断。常见的算法有Pearson correlation, Spearman correlation, Kendall correlation等应用的挑战为KPI种类繁多关联关系复杂。
- 指标与事件关联挖掘: 自动挖掘文本数据中的事件与指标之间的关联关系， 比如在程序A每次启动的时候CPU利用率就上一个台阶。该算法技术可用于构建故障传播关系，从而应用于故障诊断。常见的算法有Pearson correlation, J-measure, Two-sample test等。应用的挑战为事件和KPI种类繁多，KPI测量时间粒度过粗会导致判断相关、先后、单调关系困难。
- 事件与事件关联挖掘：分析异常事件之间的关联关系把历史上经常一起发生的事件关联在一起。该算法技术可用于构建故障传播关系，从而应用于故障诊断。常见的算法有FP-Growth、 Apriori、随机森林等，但前提是异常检测需要准确可靠。
- 故障传播关系挖掘：融合文本数据与指标数据，基于上述多指标联动关联挖掘、指标与事件关联挖掘、事件与事件关联挖掘等技术、由tracing推导出的模块调用关系图、辅以服务器与网络拓扑，构建组件之间的故障传播关系。该算法技术可以应用于故障诊断，其有效性主要取决于其基于的其它技术。
参考资料
