论文名称：AIOps Solutions for Incident Management: Technical Guidelines and A Comprehensive Literature Review

管理现代IT系统面临着独特的挑战，需要处理大量数据流时具备可扩展性、可靠性和高效性。传统方法依赖于手动任务和基于规则的方法，对IT系统产生的大量数据和警报效率低下。操作系统人工智能（AIOps）已经成为一种解决方案，利用机器学习和大数据等先进分析技术来增强事故管理。AIOps可以检测和预测事故，识别根本原因，并自动执行修复操作，提高质量并降低运营成本。然而，尽管具有潜力，但AIOps领域仍处于早期阶段，分散在多个领域，缺乏标准化约定。研究和工业贡献分散，没有一致的数据管理框架、目标问题、实施细节、需求和能力。本研究提出了AIOps术语和分类法，建立了结构化的事故管理程序，并提供了构建AIOps框架的指南。该研究还根据诸如事故管理任务、应用领域、数据来源和技术方法等标准对贡献进行了分类。旨在全面审查AIOps在事故管理中的技术和研究方面，旨在构建知识结构，识别差距，并为该领域未来发展奠定基础。

引言

背景和动机

如今的IT环境不断变得更大更复杂，随着新技术的出现和新工作方法的采用，面临着确保效率和可靠性的挑战。许多组织正在从产品交付转变为服务发布，从传统的静态基础设施转变为动态的混合部署，包括本地部署、托管、私有和公共云环境。由于设备移动性、不断演变的运行时环境、频繁的更新、升级和在线修复等因素，这些系统越来越容易发生故障[66, 73, 196, 220]。根据Lin等人的研究[153]，微软的Azure云系统每天大约有0.1%的服务器节点出现故障。这些故障可能导致系统可用性降低、财务损失和用户体验不佳[64]。国际数据公司（IDC）进行的调查显示，应用程序停机可能使企业每小时损失高达55万美元[52, 88, 108]。这些巨大的损失引发了对自主和自管理系统的需求，以解决故障的根本原因，提高IT服务的质量和响应能力[46, 89, 213]。

传统的IT管理解决方案依赖于专家系统和基于规则的引擎，经常在适应性、效率和可扩展性方面遇到问题[136, 205]。这些解决方案通常忽视系统的实时状态，导致基于当前状态的预测分析不准确。此外，它们根植于强调手动执行重复任务和个案分析的传统工程思维，通常依赖于错误重现步骤或详细日志[73]。

这些因素引发了用智能平台取代多个传统维护工具的兴趣，该智能平台能够从大量数据中学习，以主动响应事故。因此，组织正在转向AIOps以预防和减轻高影响的事故。最初，AIOps这个术语是在2017年由Gartner引入，以解决DevOps中的人工智能挑战[205]。最初，AIOps源自IT运营分析（ITOA）的概念。然而，随着AI在各个领域的日益普及，Gartner后来根据公众意见重新定义了AIOps，将其描述为操作系统的人工智能[226]。AIOps涉及应用大数据和机器学习技术，智能增强、加强和自动化各种IT运营[73, 196, 205]。AIOps从服务、基础设施和流程收集各种数据，随后自主采取行动，实时检测、诊断和纠正事故，利用这些获得的知识[66, 73, 205]。

迄今为止，由于其新颖性和横跨研究和工业的广泛范围，AIOps尚未出现普遍接受的正式定义。虽然一些定义仅关注AIOps的能力和好处，而没有深入探讨其概念框架和操作流程，但一些研究努力已经提出了全面的定义（参见表1）。这些定义通常聚焦于两个关键点[196]。首先，AIOps涉及应用人工智能来增强、加强和自动化各种IT操作系统。其次，AIOps强调为系统的过去、现在和可能的未来状态提供完整的可见性、控制和可操作见解。其他定义还强调各种方面的重要性，如强大的数据收集、数据摄入和有效的查询能力、可扩展的基础设施和实时操作。非常重要的是要注意，AIOps不仅限于事故管理和维护流程的自动化。我们赞同[196]的研究结果，即AIOps包括两个主要子领域：事故管理和资源管理，如图1所示。资源管理过程涵盖了用于IT运营的资源的最佳分配和利用技术，而我们的研究专门侧重于探索AIOps辅助事故管理过程的能力。我们的目标是通过考虑AIOps中的各种贡献，并将其与工业需求对齐，重新设计和分类与事故管理相关的整个维护工作流程。通过明确定义的阶段实现这一目标。

本综述的焦点：AIOps用于事故管理

在[205, 226]的工作基础上，我们提出，典型的AIOps系统包括六种基本能力，从而衍生出事故管理过程中的各种任务。感知。 这种能力集中在从多种来源（如网络、基础设施和应用程序）收集异构数据源，包括日志和事件数据、关键性能指标、网络流量数据等。重要的是，摄入过程要同时适应实时流和历史数据分析。此外，强大的数据可视化、查询和索引机制也是必要的元素。

预防。 这个过程涉及主动识别潜在故障并预测系统中的高严重性故障。预防事故对于保持健康和稳健的系统至关重要。因此，实施一个持续监视系统健康并及时警报管理员潜在问题的自动化系统是必不可少的。

表1. 可用的AIOps定义及相应能力。

图1. 探索AIOps子领域的研究景观，重点关注事故管理。

检测。 如果发生错误，系统必须检测相关的异常或症状。通过分析大量感知和历史数据，识别时间域或空间域中的异常内容。该过程包括发现数据中的异常模式，检测超出静态阈值的灵活异常条件，同时最小化数据中的噪音，如虚警或冗余事件。

定位。 该过程的目标是通过进行因果关系和相关性研究来识别和分析潜在的根本原因和导致基础事故的故障行为。这项研究必须在统一拓扑结构中进行上下文化，以确保其准确性。在没有拓扑结构的情况下，检测到的模式虽然有效，但可能无益且分散注意力。通过从拓扑结构中的数据中推导模式，可以减少重复和冗余模式的数量，突出数据中的异常情况，并识别隐藏的依赖关系。

行动。 这包括在检测或预测到问题后对问题进行反应性分类和优先处理事故，以及根据当前情况和已提供的过去解决方案实施一系列纠正措施。然而，需要安全地执行自动修复操作。

交互。 这被称为人机智能交互。这涉及智能模型与用户专业知识之间的双向交互分析。例如，系统可以整合人类专业知识以增强其模型，或者类似地利用模型见解来丰富和更新用户背景知识。此外，这还包括促进不同维护团队和客户之间的沟通和协作，促进有效的信息共享和问题升级。基于这些能力，近年来一些公司已经开始将 AIOps 工具作为商品推出，而一些科技巨头则采用了 AIOps 算法视角来维护他们的本地或云计算基础设施并管理事故，从而促使学术领域不断发展并提供更多巧妙和创新的解决方案。实际上，利用人工智能来改进 IT 和维护操作的概念，尽管作为一个研究领域最近才出现，但并非全新。从上世纪90年代中期开始，一些研究工作通过使用基于源代码度量的统计模型来探索源代码中的软件缺陷。自新世纪伊始，已经提出了各种技术来解决在线软件和硬件故障预测以及异常检测等问题。AIOps 的多个其他领域，如事件关联、故障分类和根本原因分析，在过去的二十年中也取得了显著贡献。事实上，硬件和软件系统的可靠性和可维护性一直是突出的研究重点。然而，我们最近看到这一领域的兴趣增加。这种现象主要受到两个主要因素的推动：首先是人工智能领域取得的显著进展，其次是许多 IT 组织从产品交付转向服务发布，同时从传统基础设施转向动态基础设施。尽管 AIOps 提供了许多有前途的好处，但作为一个研究和实践主题，它仍然是分散和无结构的。它涉及来自各种专业领域的多样贡献，涉及工业界和学术界。由于其新颖性和跨学科性质，AIOps 的贡献广泛分散，缺乏数据管理、目标领域、技术实施细节和需求的标准分类约定。因此，发现和比较这些贡献被证明是具有挑战性的。统一术语的缺乏导致缺乏解决 AIOps 最新技术差距的指导方针和清晰路线图。事实上，虽然各种数据驱动方法可能归因于 AIOps 研究领域，但来自不同领域的发现，如机器学习，不一定适用于软件分析领域，如 AIOps。因此，在 AIOps 的范围内确定必须由工业需求驱动的最佳分类法是非常重要的，这需要同时具备 IT 运营和人工智能领域的专业知识。还有一个非常重要的问题是概述构建有效 AIOps 模型的要求（desiderata），包括可解释性、可扩展性和稳健性等。此外，还必须探讨应该使用哪些指标来比较属于同一类别的 AIOps 方法，如异常检测或根本原因分析。基于机器学习的指标，如偶然性指标，在实际场景中部署时并不总是反映模型的真实准确性，因此需要情境和/或时间上的调整。还应考虑多种其他因素和特殊情况（例如，人类参与在其中）。

大纲和贡献

我们的工作旨在为 AIOps 的知识库提供一个全面的框架，包括技术和研究方面。这个框架专门设计用于解决在 IT 环境中熟练管理事故的挑战。为了实现这一目标，我们的贡献可以概括如下：

• 我们建立了一个统一且不可知的术语，以定义在事故管理领域的现有研究工作中变化多端采用的最相关术语和关键概念（例如硬件/软件故障管理、异常检测、故障分类、故障定位等）。此外，我们还详细阐述了这一过程的各个维度，包括维护协议级别。

• 这一努力使我们揭示了现有的挑战和痛点，并定义了实现智能和有效的事故管理程序的系统化 AIOps 方法所需的基本构建模块。这包括提供数据管理的技术规范，如数据收集、存储和可视化，建立明确定义的事故管理任务，并强调在采用这种方法时应考虑的关键要求。

• 在此基础上，基于提供的术语，我们建立了一个全面的分类法，用于对机器学习、数据挖掘和软件工程领域的知名会议和期刊中的重要研究贡献进行分类。这个分类法考虑到了明确定义的数据来源、具体研究领域、模型属性和评估指标。

• 所提出的分类法还通过与工业和研究的独特需求密切对齐，有别于以往的工作。它促进了各种方法和工具的发现、实施和比较，同时也解决了该领域存在的差距，从而突出了改进的潜在领域。

• 我们还提供了跨各种事故任务和应用领域的公开可用数据集。鉴于确定特定任务的最合适数据集可能是一个非平凡的任务，这是一个有价值的贡献。此外，它促进了在同一研究领域内技术的复制和比较。值得注意的是，目前没有任何现有的调查提供如此广泛的数据集覆盖。

路线图。 本文结构如下。在第2节中，我们首先概述事故管理程序，包括清晰的定义、术语、现有协议和目标维护层。接下来，在第3节中，我们深入探讨使用 AIOps 来标准化事故管理流程，强调在设计和实施 AIOps 解决方案时的重要考虑因素。随后，在第4节中介绍分类法，概述其组成部分，如数据来源和评估指标。在接下来的第5节中，我们基于提出的分类法审查了该领域中最相关的工作。此外，第6节介绍了用于评估 AIOps 方法的公开可用数据集和基准。最后，本文以讨论结束，包括结论、开放挑战和 AIOps 研究的改进领域。

简化事故管理流程

术语和定义

接下来，我们旨在提供对事故管理和 AIOps 中常用且可互换使用的各种术语的易于理解的解释。受 Salfner 等人的工作启发，我们在其术语基础上提供了正式定义，以帮助澄清这些术语在该领域中的含义和相关性。

图2. 全面的时间顺序图表，突出显示故障、错误、缺陷、异常、故障和停机之间的区别和关键联系。

与事故相关的各种术语，如故障、错误、缺陷、故障、停机和异常，在该领域被广泛使用，但往往没有对其确切含义进行深入研究。例如，文献中最常用的术语是“故障”，用于指示系统停机、硬件和软件崩溃、服务中断、网络流量干扰等。另一方面，一些其他方法使用“停机”一词来指代可能显著降低系统可用性并影响用户体验的最严重情况。然而，也有研究专注于“异常”检测，这涉及识别数据中已经存在的异常行为，通常是在系统指标中。关于根本原因分析，大多数研究属于“故障”定位类别，通常是识别源代码中的故障组件。它也可能延伸到错误操作，但人们普遍认为这可能是最终导致故障的初始点。基于故障行为、潜在原因和后果的这些术语之间的区别并没有得到足够的关注。尽管已经提出了一些尝试对这些术语进行分类和区分的方法，如[34, 220]的工作，但它们并没有提供一个全面的框架。为了建立一个准确的术语，澄清每个相关术语的含义，我们提出了一个涵盖比[220]框架更广泛概念范围的连贯词汇表。此外，我们在图2中提供了一个时间顺序图表，说明这些术语之间的关键关系。我们还确定了在系统中引发故障行为的参与者。随后，我们从我们的角度为每个术语提供正式定义。故障。 故障是指系统、组件或服务无法完成其预期主要功能并偏离预期的事件。故障通常是明显的，可以被用户或系统观察到，通常源自导致可观察问题或故障的错误或异常。需要注意的是，在系统中可能出现各种问题，但除非导致不良输出，否则不算是故障。用户通常会报告故障，这可能促使需要进行故障排除或修复以防止停机。

停机。 停机是指系统、服务或网络变得完全无法访问或对用户不可用的一段时间。停机可能源自硬件故障或软件故障等导致完全中断和所需服务不可用的故障。这些情况通常需要立即采取缓解措施恢复正常运行，然后再深入研究潜在问题进行治理维护。

错误。 错误表示系统偏离其正确和正常状态的实例，表明存在实际问题。这些错误可能并不总是立即显而易见，直到它们表现为故障，特别是如果在适当时机未被准确检测到。另外，错误可以通过专门工具或设计用于检测目的的特定算法来识别。

异常。 异常被定义为与预期状态偏离的意外或异常行为或模式。它们代表可能指示错误的不规则或异常事件，但也可能是无害或暂时的偏离，不会直接导致故障。各种因素，如异常数据模式或外部影响如网络攻击，都可能导致异常的出现。通过监控和分析系统指标，可以识别和检测这些异常。

故障和错误。 故障指的是在硬件或软件组件中发现的表现不正确的异常或缺陷，可能导致错误和故障，如果不及时检测到。这些故障通常源自系统组件内在问题或弱点。它们可能由各种因素引起，包括最终用户或管理员的人为干预、设计缺陷、系统设置或不当处理。在软件开发中，故障表现为错误，源自编码错误。识别导致错误的故障通常发生在测试阶段。相反，在硬件或设置问题的情况下，故障直接导致系统运行过程中的错误。

警报。 除了导致故障外，未检测到和检测到的错误和异常也可能导致系统偏离正常行为，作为副作用。这种情况通常被称为症状。这些症状通常表现为警报报告，指示需要关注或采取行动的特定事件或条件。警报通常基于与症状相关的预定义规则或阈值触发，特别是在异常情况下。图2说明了从内部或外部因素引起的故障或异常向故障和潜在停机的进展。为了说明这一点，让我们考虑一个存在内存泄漏问题的容错系统的情景。在这个系统中的故障是源代码中缺少的释放语句，导致内存无法正确释放。只要负责内存释放的特定部分的软件从未执行，故障就会保持休眠状态，不会影响系统的运行。然而，当应该释放内存的代码段被执行时，软件进入不正确的状态，变成错误。在这种情况下，内存被消耗但却从未被释放，尽管不再需要。最初，如果不必要分配的内存量很小，系统可能仍能提供其预期服务而不会从外部观察到任何故障。随着具有内存泄漏的代码的重复执行，随着时间的推移，可用内存逐渐减少。系统参数“可用内存”偏离预期状态的这种异常行为可以被视为错误的症状。它表明系统内部存在问题。在某个时刻，当内存泄漏消耗了大量可用内存时，可能没有足够的资源用于某些内存分配。这导致错误的检测，因为系统遇到无法在需要时分配内存的情况。在容错系统中，即使发生了内存分配失败，也不一定会导致服务故障。系统可能采用备用单元等机制来完成操作并保持服务交付。因此，单个内存分配失败本身可能不会导致服务故障或停机。但是，如果整个系统由于一系列错误或重大资源耗尽而无法正确提供其服务，就会发生故障。这表明系统不再能够履行其预期功能，影响其用户并可能导致停机。在停机期间，系统变得完全不可用，其服务无法被用户访问或利用。在给定示例的情况下，如果内存泄漏问题未能及时解决，导致资源枯竭严重，使系统无法运行，就可能发生停机。总之，故障和随后的错误的存在可以通过内存消耗或耗尽等症状来指示。异常检测和监控可以帮助识别与预期系统行为的偏差。警报可以生成通知系统管理员或开发人员有关这些异常的信息，使其能够采取纠正措施。如果错误和问题持续存在并阻止系统正确提供其服务，则会发生故障，可能导致停机。

为了提供统一的术语并避免混淆，在接下来，我们将把所有这些术语称为事件。这个术语涵盖了更广泛的范围，并普遍适用于任何干扰系统、网络或服务正常状态、行为或输出的未计划事件或发生。

事故管理中的现有维护协议

事故管理过程应遵循IT组织普遍接受的标准维护协议和策略。这些协议规定了基于发生时间和可用的物理和人力资源来处理事件的方式。它们还根据可用性、性能和质量等关键因素来衡量事件的影响。这些协议作为评估图1中所示的各种事件管理任务影响的框架。与一些将不同事件管理方法基于这些协议分类的先前作品不同，我们将它们作为实现最佳和有效策略的抽象呈现。我们不将这些协议视为事故管理过程中独立的阶段，因为我们的分类主要侧重于使用数据驱动方法以阶段方式处理报告、检测或预测的事件，从报告到缓解，无论选择的协议如何。不同的维护策略可以分为两种主要方法，即反应性和预防性维护。

反应性维护是针对最终用户或内部维护人员检测或报告的事件而执行的（见图2中的检测和跟踪区域）。另一方面，预防性维护旨在防止潜在问题的发生，并通过审计和测试主动干预以纠正问题，通常通过审计和测试（如图2所示）。图3提供了我们研究中分析的维护策略的不同模式的可视化表示。在反应性维护中，通常存在时间限制，导致部分或完全解决问题的缓解措施，使受影响的活动能够继续进行（特别是在停机的情况下）。例如，可以实施临时技术配置。然而，必须进行治理性维护以实施稳定解决方案并防止问题对同一或其他客户再次发生（在故障和/或停机的情况下）。另一方面，预防性维护采用一系列措施，包括定期维护例程和条件维护协议。这些协议评估系统功能，识别异常和错误，并减轻潜在的性能下降和故障（见检测、审计和监控区域）。这种方法严重依赖AIOps，并利用先进的机器学习算法和大数据挖掘来通过分析历史数据模式预测潜在的系统故障。预测性维护通过采取积极的方式智能地安排和计划资产维护，超越了预测性维护。与仅依赖历史数据的预测性维护不同，预测性维护结合了当前设备状态，为维修或更换提供精确的指导。此外，预测性维护具有推荐最佳缓解或治理措施的能力。

目标维护层

对主动维护和反应性诊断的方法都涉及跨多个层面对其组件进行全面检查。

• 技术或物理层。 这一层侧重于机器及其各种组件。例如，技术层将涉及监视应用服务器机器、数据库以及诸如 RAM、SWAP、处理器和磁盘使用率、网络标识和连接器等元素。它还涉及监视和分析系统的硬件和基础设施方面（例如，物理组件的剩余寿命）。此层内的检查示例包括分析 CPU 利用率以确保其保持在可接受范围内，监视磁盘空间以防止潜在的存储问题，以及检查网络连接以确保各组件之间的顺畅通信。

• 应用层。 这一层围绕软件应用的关键组件展开。它包括应用服务器、数据库服务器和用户工作站。例如，应用层的检查将涉及分析诸如堆利用率、缓存代码性能、资源消耗、启动配置控制和转储文件等因素。这有助于识别内存泄漏、缓存利用不足或配置不当的启动设置等可能影响应用性能的事件。

• 功能层。 这一层侧重于评估软件应用执行的过程，以确保数据交换高效顺畅、延迟最优、统计执行准确等。例如，维护团队可能分析数据检索的响应时间或应用执行的统计计算的准确性。

• 业务层。 这一层评估关键业务参数的控制。它涉及评估系统的关键指标和与业务相关的方面，以确保其与整体目标和目标保持一致，例如处理的交易数量、数据传输成功率或遵守预定义的服务级别协议。

迈向自动化的 AIOps 解决方案以管理事件

将 AIOps 应用于革新事件管理是一个复杂的过程，需要从传统和常规实践转变为完全自动化的流程。在实际软件系统场景中设计、实施和部署机器学习模型并非易事，需要仔细考虑。要释放完全智能解决方案用于事件管理的全部潜力，并将知识从 AI 模型转移到操作系统领域，需要对当前情况进行彻底评估。这种评估应该预见到在实施过程中可能出现的人力、资源或知识因素引发的潜在障碍。同时，还需要确定改进的领域，并确定从旧实践过渡到新方法论所涉及的成本，同时考虑反馈、审查和从业者的信任。接下来，我们将概述在构建 AIOps 解决方案以管理事件之前需要解决的一系列痛点和挑战。

痛点和挑战

在软件行业中，AIOps 解决方案的开发和采用正在持续进行，但仍处于早期阶段。在实际场景中构建和实施 AIOps 解决方案继续从技术和非技术角度提出挑战。为了进一步阐述，我们概述了构建 AIOps 解决方案涉及的重要挑战。

AIOps 的新颖性。 AIOps 仍然是一个相对新领域，缺乏明确和全面的定义。它涉及各种研究领域，如系统和模式设计、软件工程、大数据、机器学习、分布式计算和信息可视化等。由于其新颖性和跨学科性质，AIOps 的贡献和方法广泛分散，缺乏数据管理、目标领域、实施细节和需求的标准化约定。因此，选择最适合的技术来实现特定目标已被证明具有挑战性。因此，有必要根据明确定义的目标确定适当的方法和工具，并建立一个客观的过程来进行比较。此外，这些方法应与 IT 组织的政策保持一致，例如可解释性和可信度，同时考虑可用资源和可扩展性问题。根据 Dang 等人的研究，AIOps 领域存在几个独特挑战，需要全面了解整体问题空间，包括业务价值、数据、模型以及系统和流程集成等方面。

数据管理。 高效的数据管理是成功实施 AIOps 框架的最关键组成部分。为了实现高可观测性和实时分析，必须集成和处理来自不同来源的大量数据。然而，这种集成提出了几个需要解决的挑战。最主要的挑战是确保实时或准实时数据收集不会对被监视应用程序的性能产生不利影响。必须防止过度消耗这些应用程序的内存或网络资源。因此，所采用的数据管理系统在数据存储、摄入、压缩和查询能力方面必须表现出最佳性能，以适应不同数据类型。

数据规范化。 AIOps 模型具有与通常用于一般机器学习模型的数据要求不同的特定数据要求。尽管主要云服务收集了大量遥测数据，每天或每月的数据量可达到几 TB 甚至 PB，但可用数据的质量和数量仍不足以满足 AIOps 解决方案的需求。Dang 等人、Levin 等人和Chen 等人的研究强调了使用来自各种来源的多样数据所涉及的挑战，这些数据通常以不同的格式和结构呈现，使规范化和清理变得复杂。这些数据可以是非结构化或半结构化的，包括日志、执行跟踪、源代码、分层和图数据以及网络流量，需要特定的预处理技术。此外，严重依赖监督机器学习算法的 AIOps 模型需要用于训练的标记数据。然而，数据通常包含噪声或缺失值，获取标记数据可能具有挑战性。这使得构建准确和稳健的 AIOps 模型变得困难。在许多 AIOps 场景中，由于数据质量问题，构建监督机器学习模型存在挑战，例如缺乏明确的地面真实标签、需要手动努力获取高质量标签、数据不平衡以及噪声水平较高。克服数据质量限制和管理噪声和不平衡数据集是构建 AIOps 模型时需要关注的关键领域。

人类与 AIOps 的互动。 在这一背景下，主要挑战之一是将 IT 从业者的思维方式转变为放弃旧的维护例行程序，采用全新方法。面向 AIOps 的工程仍处于非常早期阶段，行业中对 AIOps 的最佳实践和设计模式的确立尚未完成。经验丰富的从业者很难放弃基于适应性和审计任务的手动活动。与此同时，AIOps 解决方案的基本方法围绕着从历史数据中学习以预测未来。另一方面，传统的工程思维涉及调查个别案例，并基于日志数据重现事件步骤，在大规模服务场景中效率低下甚至不切实际。

实际上，在涉及 AIOps 时，从业者之间存在两种截然不同的观点和看法。一方面，有人认为 AI 可以解决所有挑战，但这种期望并不现实。另一方面，一些人对行业中机器学习模型的效率表示怀疑。这种怀疑源于 AIOps 解决方案主要依赖于从过去经验中学习，利用大型数据集预测未来趋势。然而，经验丰富的 IT 专业人员对这些模型的有效性提出质疑，即使在认识到数字转型的必要性之后。他们可能会认为，过去的经验并不总是提供足够的覆盖范围来准确预测系统状态，因此需要始终进行人工干预和检查。他们还可能举例说明，类似的过去经验产生了不同的结果。因此，企业需要额外的时间来建立对 AIOps 建议的可靠性和可信度的信心。因此，在两个方向上投入大量努力以简化这一过渡是至关重要的。确保信任、让人类参与决策过程，并为 AIOps 解决方案提供可解释性和可解释性对于增强对这些方法的信心至关重要。此外，设定现实期望并清晰定义 AIOps 的范围和目标也是至关重要的考虑因素。AI模型的实施与集成。 为AIOps应用构建机器学习模型面临着独特的挑战，这些挑战在其他ML/AI场景中并不常见[73]。例如，自然语言处理模型，通常用于机器学习，根据Menzies [174] 和 Ray等人 [207] 的说法，在应用于软件工程相关数据时往往会产生不准确的结果。另一方面，构建监督式机器学习模型面临与数据质量和可用性相关的挑战，正如前面提到的那样。这些挑战包括数据集不平衡和缺乏明确的基准标签。为了解决这些问题，可以探索无监督或半监督的机器学习模型。然而，由于系统行为的动态性和客户需求以及基础设施的变化，获取足够的标签以理解“什么是异常”模式是困难的。此外，由于组件和服务之间错综复杂的依赖关系和关系，开发高质量的无监督模型是困难的[46, 61, 161]。Lou等人 [161] 认为，服务故障的诊断不能仅仅依赖于学习模型，而是需要对服务系统有相当的了解。然而，在实践中，这种类型的知识通常组织混乱或记录不足。此外，频繁模型更新和在线学习的需求对DevOps/MLOps实践提出了挑战，尤其是在复杂的特征工程工作中。

另一个挑战是确保模型在训练阶段的行为与测试阶段的性能一致。用于评估模型的传统指标容易受到污染区域现象的影响[91]，这可能导致错误的评估。事实上，Fourure等人 [91] 指出，通过参数化训练集和测试集之间的数据比例，异常检测模型的F1分数可以被人为地增加。

最后，机器学习模型的有效性往往与其复杂性成正比。高度准确的模型，即黑盒模型，缺乏透明性，无法提供其决策过程的解释[98, 182]。这种缺乏透明性显著阻碍了它们被行业从业者采用，后者需要清晰了解维护流程和工具行为。虽然利用强大的模型进行成本优化和任务自动化具有价值，但这是以透明性为代价的。AIOps领域的最新研究表明，可解释的模型，即使性能略低，也优于性能高但不可解释的模型[165]。因此，成功地自动化事件管理流程需要通过为模型决策提供解释来建立从业者的信任，这符合可解释人工智能（XAI）的概念[98]。

用于数据和事件管理流程的AIOps框架

实施智能解决方案以进行事件管理程序是一项复杂的任务，不仅仅依赖于在广泛数据集上实施和训练机器学习模型以发现可操作模式。在采用AIOps中的一个重要挑战是从依赖于独立模块和执行脚本的现有架构平台过渡[73, 208, 226]。这种过渡涉及采用和集成各种数字技术，以根本性地改变维护和事件管理服务向最终客户或内部维护人员的交付。为实现这一转变，需要设计一个可靠、可扩展和安全的基础架构架构。这样的架构应能够有效地收集、摄入和管理来自不同来源、格式各异的大量数据。然后，利用人工智能方法从这些数据中提取有意义的见解，遵循将在第3.3节中讨论的迭代和标准化过程。此外，这种架构需要促进用户交互，迎合数据科学家和工程师、MLOps工程师和最终用户。其目的是通过提供纠正或预防性措施、预测性警报和其他有价值的见解来帮助事件管理。因此，成功实施智能事件管理解决方案需要解决许多因素，包括架构转型、数字技术集成、强大的数据管理和用户友好的界面，以充分利用AIOps在管理事件、提高运营效率和推动更好业务结果方面的潜力。

图4. 事件管理流程的综合AIOps参考架构[13, 205]

图4展示了一个分层AIOps参考架构的概述，旨在支持智能事件管理程序并无缝集成关键工具和模块。这种架构适用于传统的内部和基于云的应用环境，为实施AIOps解决方案提供了灵活的框架。接下来，我们将简要介绍这个框架的基本模块，同时涵盖可能可用的和现有的开源工具，这些工具可以用来执行底层任务。

数据收集和摄入。 动态基础设施生成大量的运营和性能数据，包括基础设施健康、应用性能、活动日志、事件通知、网络流量、用户交互等。在这种情况下，了解各种数据源使用的不同格式、协议和接口至关重要。提取监控数据通常涉及在被监视的服务器上安装和配置收集代理。基础设施中的许多组件可以被有效地监视，包括硬件组件、应用服务器、相关数据库、操作系统、虚拟机和业务趋势。这些组件与前面在第2.3节中讨论的维护层相一致。

已经推出了许多开源的收集代理来促进监控任务。例如，InfluxData提供了Telegraf [20]，这是一种多功能工具，能够连接超过300个流行应用程序。ELK堆栈提供了Beats套件 [6]，它可以收集和传输指标到ElasticSearch。另一个值得注意的代理是Fluentd [10]，它提供了收集数据事件并将其发送到各种目的地（如文件或数据库管理系统）的能力。这些开源工具具有几个优点，包括它们的普及度和部署配置的便利性。它们在行业中获得了显著的关注，因为它们广泛可访问和可定制。然而，在某些情况下，开发自定义收集代理可能是有益的。这使组织能够收集特定用例数据，利用预构建的数据处理库，并在其基础设施中利用现有的BI工具 [43]。此外，自定义代理提供了根据特定要求定制配置的灵活性。

为了处理来自不同来源的不同格式的数据，实施数据摄入模块至关重要。该模块确保接收到的数据被高效可靠地捕获和聚合到一个系统易于理解的统一格式中。该过程涉及规范化数据结构、解决数据不一致性，并确保无缝的互操作性。在某些情况下，会执行适当的转换以确保在持久化之前跨不同数据源的一致性和兼容性。这可能包括数据解析、规范化、过滤和丰富化。数据摄入可以通过各种工具和技术实现，包括ETL（提取、转换、加载）过程、API集成或专门的数据摄入平台。在AIOps系统中，有许多工具和技术可用于辅助数据摄入。开源平台如Kafka [2]、Apache NiFi [3]、RabbitMQ [18]或RocketMQ [19]提供了数据流处理、消息排队、数据路由和可靠数据摄入来自不同来源的功能。此外，还有专有/托管服务工具，如AWS Kinesis [1]、Azure Event Hubs [5]和Google Cloud Pub/Sub [11]等，提供类似的数据摄入功能。数据存储与组织。 在 AIOps 环境中收集的数据可以分为结构化、半结构化和非结构化数据。这包括各种数据类型，如代表系统指标或性能指标的时间序列数据、事件日志、顺序模板、可视化为图形的网络流量以及以文本形式报告的用户故障票据。由于数据特征的多样性，使用“一刀切”的方法将所有数据存储在单个数据仓库中变得具有挑战性。为了解决这一挑战，组织需要在将数据输入到 AI 模型之前了解并组织数据。根据具体要求和使用情况，可以采用不同的方法来存储和查询数据。在历史上，数据持久性有两种主要选择：用于结构化数据的数据库管理系统（DBMS）和用于未处理数据的数据湖。DBMS 解决方案，如关系数据库，专为具有预定义模式的结构化数据而设计。它们提供预定义的结构，通过表、列和关系强制执行数据完整性，并提供 ACID 特性（原子性、一致性、隔离性、持久性），确保事务一致性。另一方面，数据湖作为存储库，存储着大量原始和未处理数据，以其原生格式存在，适应半结构化和非结构化数据。数据湖和 DBMS 之间的选择取决于数据量、种类、速度、查询需求、数据治理需求以及组织的具体使用情况和目标。

在 AIOps 环境中，为了支持商业智能、机器学习和大数据挖掘技术，同时维护两种数据结构并将系统连接在一起通常是有益的。采用结合数据湖和数据仓库的混合方法更可取，这被称为数据湖仓架构。这种方法允许组织利用每种方法的优势来满足其数据管理需求的不同方面。图 5 展示了数据湖仓架构，并突出了其关键组件和工作流程。数据湖仓是一种集中、强大且灵活的大数据存储架构，集成了来自多个来源的各种数据类型，假定这些数据以不同格式存在。它结合了数据仓库和数据湖的最佳特性。最初，数据湖仓作为包含原始数据的数据湖开始，没有对账户大小或文件施加任何约束。稍后，这些原始数据根据需要进行处理、转换和结构化，以供分析和查询，创建数据集存储库。为实现这一目标，数据湖仓利用像 Delta Lake（构建在 Apache Parquet 和 Apache Avro 上）[7] 这样的技术，提供诸如模式演变、ACID 事务和高效数据索引等功能。此外，它们维护数据目录和元数据存储库，其中包含有关可用数据集、它们的模式和其他相关细节的信息，确保数据治理并帮助用户发现和理解数据。数据相关人员以及其他用户可以通过 SQL 或其他查询语言访问数据。数据湖仓通过优化数据以供查询而实现快速高效的数据检索和分析，同时保留原始数据以供探索。

图 5. 数据湖仓参考架构

已经提出了各种工具，以有效地存储和组织数据，满足不同的需求和使用情况。例如，Elasticsearch [9] 是一款分布式开源全文搜索引擎。具有 HTTP 网页界面和无模式 JSON 文档，Elasticsearch 提供强大的搜索和索引功能。它擅长管理 AIOps 系统中的日志和事件数据。同样，InfluxDB [14] 是一款设计用于处理带有时间戳数据的高写入和查询负载的时间序列数据库。在 AIOps 系统中存储和分析指标和传感器数据的热门选择。这些数据库配备了自己的领域特定语言（DSL）。InfluxDB 使用 Flux 语言，而 Elasticsearch 使用 ESQL。另外，Clickhouse [8] 最近作为一款开源列式数据库管理系统崭露头角。它以针对在线分析处理（OLAP）工作负载的特定优化脱颖而出，非常适合实时分析和报告。Clickhouse 以其高性能、可扩展性和低延迟查询能力脱颖而出。此外，它的 SQL 支持对许多数据分析师和工程师来说很熟悉，使其更容易与现有数据仓库存储库（如 PostgreSQL 和 Oracle）集成。在最近的一项研究中[43]，作者提供了选择最适合特定情境的解决方案的具体标准。这些标准包括许可证、知名度和流行度、适应性和性能。

数据可视化与监控。 在数据管理中，无论数据是组织在数据集存储库中还是保留在数据湖中，通过数据可视化仪表板获取有价值洞察的潜力是必要的。这些工具在促进对数据的全面理解、支持深入检查以及支持数据驱动的决策过程方面发挥着关键作用。这些可视化工具之所以突出在于它们提供用户友好的界面，配备一系列可视化面板，包括多样化选项，如时间序列图、仪表、动态拓扑等，满足从事监控活动的 IT 专业人员多样化需求。通过利用这些工具，我们获得了持续监控基础设施、诊断潜在问题、熟练识别各个组件之间的复杂关系、导航到事件根本原因以及导致更快解决问题的能力。此外，这些工具在异常检测方面表现出色，通过直观地表示异常行为，从而实现对潜在问题和威胁的早期识别。在众多可用的数据可视化工具中，一些值得注意的开源选项包括 Grafana [12]、Kibana [15]、Metabase [17] 和 Apache Superset [4]。

智能事件管理流程。 AIOps 洞见建立在智能算法的基础上，这些算法在历史数据和实时数据上运行，旨在提供可操作的模式和建议。这些洞见旨在优化运营绩效、增强情境意识并改进事件管理程序。具体而言，事件管理程序可以被视为一种系统化方法，包括一系列预定义的步骤和流程，无论事件是否突发发生或是可预见的，都要一贯遵循。其主要目标是确保一致和协调的响应，无论事件报告的来源如何。该程序涉及使用强大的人工智能算法来辅助事件的报告、分类、优先级确定、分配、诊断和解决。在整个过程中，建立清晰的沟通渠道至关重要，以使利益相关者了解事件的状态、解决进展和采取的任何相关行动。时间敏感性也至关重要，每一项努力都自然而然地致力于最小化各种与时间相关的指标，包括检测时间（TTD）、参与时间（TTE）、确认或诊断时间（TTA）以及修复或缓解时间（TTR）。此外，在成功解决事件后，将启动重要的事后审查阶段，记录针对特定事件采取的纠正或预防措施。这一阶段还在识别宝贵的经验教训和主动预防未来类似事件方面发挥关键作用。

智能事件管理流程任务

借助 AIOps 的事件管理能力，我们的提议旨在将维护例行程序组织在一个标准化方法中，从创建到诊断再到解决事件。这一重新设计的流程涉及一个顺序工作流程，引导事件通过四个明确定义的阶段，从最初报告开始，最终导致缓解和事后分析。事实上，目标是尽可能自动化尽可能多的维护任务，以优化报告时间、诊断和分级时间以及解决时间。这样的协议不仅应有助于解决事件，还应有助于记录维护背景。图 6 提供了这种分类的清晰可视化表示。值得注意的是，一个事件通常会在所示的工作流程中经历许多子阶段，但在某些情况下，某些阶段可能不必要。在这种情况下，如果认为某个阶段是不必要的或不有助于解决报告的问题，则可以跳过该阶段。例如，如果一个事件被分类为已经经历过先前调查的方式，那么可能不需要进行根本原因分析阶段。在接下来的内容中，我们从我们的角度提供了对事故管理程序中基本子类别的广泛审查。我们的目标是检查针对每个阶段提出的最相关方法。值得一提的是，一些先前的工作已经定义了与事故管理相关的某些术语。例如，Chen等人[66]将事故管理程序定义为涉及事故报告、分类和缓解的三个步骤过程。然而，他们的定义仍然是通用的，并没有深入探讨这些阶段的子类别，比如解决事故分类和相关性问题。另一方面，Notaro等人[196]专注于研究故障并基于积极和反应性方法开发了一个分类法，重点放在了报告阶段。然而，他们的研究似乎忽视了其他重要阶段。此外，Zhang等人[286]提供了一个包括任务分配、优先级确定、故障定位和缓解等详细阶段的正式定义。然而，这项调查仅集中在软件缺陷上，并不普遍适用于其他特定领域。在这项工作中，我们的目标是在统一的分类法下涵盖所有这些用例，无论使用的术语是故障、错误、异常等，还是具体的行业重点。

图6. 在AIOps环境中提出的事故管理标准端到端流程。

图7. 在线故障预测中的时间关系。

事故检测。 事故检测是指识别和识别与正常运行有偏差的过程，表明存在异常行为或故障事件可能表明事故发生（例如，错误或异常）。这个过程涉及监视和分析各种数据源（例如，KPI指标、系统日志和用户报告）。例如，异常检测 研究领域属于这个子类别。

事故预测。 事故预测是指在事故发生之前，对潜在事故（主要是故障）的发生可能性进行预测、估计或评估的过程。它涉及利用可用的历史数据以及其他相关因素，积极地识别和评估潜在风险和漏洞。通过使用先进的分析技术分析历史和当前数据中的模式、趋势、异常事件和异常，事故预测旨在采取预防措施，减少未来事故的影响。事故预测可以分为离线和在线方法。离线类别包括软件缺陷预测（SDP）[79, 137]，它通过执行特定功能单元或分析源代码的部分来评估故障风险。该类别中的另一种技术是故障注入[190, 227]，通过压力测试向正常运行的系统引入故障，以评估其容错能力水平。相反，在线预测发生在系统运行时。它涉及技术，如软件复原[26, 246]，它解决资源耗尽并防止由软件系统中的老化或累积故障引起的意外系统故障。此外，在线预测还涉及估计系统的剩余有用寿命。该类别还涉及硬件和软件故障的实时预测，考虑到时间限制，如图7所示。为了使预测被视为有效，必须在最小警告时间（Δ?? ）之前做出具有领先时间（Δ?? ）的预测。此外，只有在特定时间段内发生故障时，预测才被视为有效，该时间段称为预测期（Δ?? ）。为了进行这些预测，使用了一定时间范围内的数据（Δ?? ），称为数据窗口大小。

事故优先级确定。 事故优先级确定是根据其紧急性、影响和业务优先级对事故进行分类和排名的过程。它涉及评估事故的严重程度，考虑到受影响的系统、服务以及潜在的业务影响因素。事故优先级确定还确保资源得到适当分配，相对关键的事故得到立即关注和资源。

事故分配。 事故分配涉及将事故分配给负责调查和解决它们的相关个人或团队。这个过程涉及分析事故报告中包含的信息，考虑因素如事故的性质和复杂性，以及被分配人员的技能和可用性。这个过程在一些工作中通常被称为事故分类[60, 290]。然而，从一般意义上讲，分类不仅仅指分配，还包括其他任务，如分类和识别重复事故。

事故分类。 事故分类涉及根据其独特特征、症状或影响对事故进行系统分组或分类。这种分类过程建立了一个结构化框架，增强了对事故的理解和有效管理。这个过程可以看作是对分配程序的一个细化。事实上，有必要对事故进行分类，并根据各自的主题将其分配给特定团队。例如，IT组织中的技术服务团队可能负责解决与资源饱和、对CPU和SWAP施加重大需求的进程、安全漏洞等相关的事故。为了有效地管理这些问题，技术团队应该为每个主题指定了解该主题的工作人员。因此，一旦将事故分配给负责团队，迅速确定适当的主题作为程序的初始步骤将是最佳选择。令人惊讶的是，尽管在优化事故管理时间响应方面起着至关重要的作用，但事故分类并没有得到足够的关注。虽然一些研究，如[27, 203]，通过将其视为内容优化问题来处理这个问题，其他研究将其包括在优先级确定的范围内[131, 242]。一些研究人员甚至将其视为重复检测的一部分[36, 112]。然而，我们认为这些类别之间存在固有差异。事故分类主要侧重于将事故与特定主题或类别相关联，而不考虑分配人员、事故优先级、是否存在类似事故或是否是新事故等。

事故去重。 近似重复事故检测是一种有效识别密切相关或具有显著相似性的事故，并将它们分组到对应于不同问题的特定桶中的过程。这个过程涉及对传入事故进行实时分析，以确定它们与历史事故的相似性、重叠和共同点，这些历史事故涉及相同主题。通过识别重复事故，事故去重减少了冗余和事故管理工作，并防止不必要的资源分配。事实上，Anvik等人[28]使用来自Eclipse和Firefox的错误存储库进行了一项全面的实证研究，结果显示开发人员将相当大比例（20%-40%）的错误报告标记为重复。这项研究提供了检测重复事故的必要性的具体证据。这个过程也可以被视为事故分类问题的进一步细化。

图8. 根本原因分析、异常检测和故障预测之间的区别。

根本原因分析。 根本原因分析（RCA），也称为根本原因诊断，在事故管理程序中发挥着关键作用。这是一个系统性的过程，旨在调查和识别事故的潜在原因和影响因素，我们通常称之为故障。如图8所示，RCA深入研究导致事故发生的基本故障，认识到这种故障不一定源自错误操作或有缺陷的源代码。它的目标不仅仅是解决症状。相反，它寻求揭示和理解根本原因，即使它源自外部因素。在相关研究中，这个过程通常被称为故障定位[261]。这些研究侧重于确定与导致或可能导致特定故障的一组特定组件（如设备、网络链接、主机、软件模块等）。然而，根本原因分析超越了组件定位，并将其调查扩展到可能导致系统内异常行为的故障行为或风险外部因素。事件关联。 事件关联研究涉及分析多个事件，旨在识别它们之间的关系、依赖性或共享特征。通过这一过程，可以实现对事件景观的整体视角，从而揭示潜在的隐藏模式或趋势。事件关联与根本原因分析一起工作，评估潜在原因以及故障组件或行为如何影响其他事件。这有助于促进更高效的事件解决。由于软件系统中组件之间的固有复杂性和相互依赖性，这项任务被认为具有挑战性 [31]。

事件缓解。 事件缓解，也称为补救，指的是最小化事件影响和严重性的过程。它涉及采取积极主动和自动化措施来遏制、解决或减少事件的影响。事件缓解可以包括实施临时解决方案、应用修复程序或补丁、激活备份系统，或者启动专门资源或团队来恢复正常运营。正如[196]中提到的，与事件预测、检测、分类和诊断任务相比，与补救行动相关的贡献相对较少。这可能归因于一旦通过诊断确定了潜在问题，必要的恢复步骤就变得容易识别和实现。在许多情况下，可以参考具有类似解决方案的历史事件，从而消除使用复杂模型的需要。

有效智能事件管理的期望

为事件管理创建智能、数据驱动的策略是一项复杂的工作，远远超出了设计有效的机器学习技术的范畴。仅仅依赖高性能的机器学习或大数据挖掘模型是无法成功采用AIOps解决方案的。为确保这些解决方案的有效性，它们必须符合一组既定的标准，我们称之为期望。从包括[73, 143, 161, 165, 296]在内的众多研究中汲取经验，我们已经编制了一个全面的要求清单，构建AIOps解决方案时应该考虑这些要求，无论是完全还是部分。

• 可信性和人在回路中。 文献声称，随着AIOps的引入，员工技能和心态的要求发生了变化[208]。手动活动往往转向适应和审计任务，而处理AI则需要一种专注于从原始数据中识别模式的不同方法，偏离了传统的开发者思维方式。这种转变引发了关于对AI能力的信任以及它能提供什么的问题。因此，采用的AIOps方法应该将经过多年现场测试的工程师信任的领域专业知识迭代地和交互地整合到基于原始数据构建的复杂机器学习模型的学习、更新和解释阶段中。IT专业人员拥有通过多年管理和故障排除IT系统积累的宝贵领域知识和见解。虽然并非所有他们的最佳实践都适用于AIOps趋势，但他们的专业知识往往超越了原始数据分析。他们对基础技术、基础设施、应用程序和业务需求有着深刻的理解。因此，充分利用并将这种专业知识建模到AIOps解决方案中至关重要。这可以通过提供将人类纳入回路的机制来实现，允许在必要时进行交互、更新和更正模型。主动学习[214]在这种情况下可能特别有益。

• 可解释性。 AIOps解决方案应优先考虑可解释性，即使这可能会牺牲模型性能。在AIOps的背景下，当高性能模型缺乏可解释性时，可解释模型更受青睐。模型透明度使用户能够充分理解、与之交互并推理模型提出的建议，这有助于获得高层管理对遵循这些建议的支持。然而，解释AIOps模型也有一定的约束和要求。在[165]的一项研究中，调查了影响AIOps模型解释的不同因素，跨越了三个关键维度。(1) 内部一致性 评估了在相同设置下训练的AIOps模型得出的解释之间的相似性。它检查了当模型在多次执行中使用相同数据和实现进行训练时，从AIOps模型获得的解释是否在多次执行中是可重现的。(2) 外部一致性 侧重于在给定数据集上从表现相似的AIOps模型得出的解释之间的相似性。直观地，从表现较差的可解释模型得出的解释只有在可解释模型在给定数据集上与其他机器学习模型具有相同解释时才可信赖。 (3) 时间一致性 捕捉了在不同时间段内从AIOps模型得出的解释之间的相似性。AIOps模型不仅应反映最近训练数据中观察到的趋势，还应捕捉和反映长时间内观察到的趋势。值得注意的是，一些先前的工作，比如[38]中的缺陷预测，已经表明在一个时间段上训练的模型在另一个时间段上测试时可能泛化能力不佳。此外，训练数据的规模可能会影响模型的解释。

• 可扩展性。 AIOps解决方案必须有效处理复杂IT环境中的大规模数据，在这些环境中预期会有大量的监控和日志数据。这些环境可能包括数千到数百万个组件，包括服务器、网络设备和应用程序。为了超越有效建模和准确结果，AIOps解决方案必须在能够高效摄取、存储和处理大数据的强大架构中实施。可扩展的架构和数据处理框架在分发工作负载和有效处理大量数据方面发挥关键作用。此外，在考虑采用的方法时，AIOps解决方案应利用可扩展的计算技术，如分布式和联邦学习，以实现并行处理和分布式数据分析，如[41, 83, 191]中所讨论的。可扩展性还涉及优化计算资源的利用。AIOps解决方案应具备根据数据量和处理要求动态分配和分发资源的能力。

• 可维护性和适应性。 在AIOps中，可维护性和适应性的概念至关重要，因为它们旨在最小化对持续维护和重复微调的需求。这一考虑是至关重要的，因为负责管理和维护这些解决方案的DevOps工程师往往有多项责任，可能并不具备机器学习方面的广泛专业知识。因此，AIOps解决方案应致力于高度自动化和自我管理常规任务，如数据预处理和定期模型训练，以减少对持续手动干预的依赖。为实现这一目标，可以采用自调整算法和自动化流程[43]。此外，利用先进的机器学习技术，如迁移学习[199]和一次学习[249]，可以极大地有益于AIOps解决方案。与从头开始训练模型不同，可以利用由机器学习专家开发和微调的预训练模型来处理新的数据模式。

• 稳健性。 AIOps解决方案需要建立在稳健和稳定的机器学习模型之上，这些模型能够处理各种情况，并对真实IT环境中常见的嘈杂和不完整数据表现出韧性[73]。为确保建模过程的可靠性，可以采用稳健的预处理技术，如系统性数据清洗和有效的插补方法。此外，AIOps解决方案必须能够检测和适应概念漂移，指的是在动态IT环境中发生的基础数据分布变化[164]。可以利用基于在线学习的稳健算法和模型来处理概念漂移，并在数据模式不断演变的情况下保持最新的见解[51, 53]。此外，AIOps解决方案应该在不同的IT环境中具有良好的泛化能力。为实现这一目标，它们应该在多样化和具有代表性的数据上进行训练，捕捉适用于各种场景的基础模式和关系。

• 上下文评估。 与传统的机器学习评估场景（如交叉验证）不同，由于实际IT环境的独特特征，这些传统方法通常不适用于AIOps，因此上下文评估的概念强调需要在与实际生产使用情况密切相似的环境中评估解决方案的性能。传统的评估方法通常假定用于评估的数据是相同分布的，而在IT环境中这种假设可能不成立。实际数据通常表现出时间依赖性、概念漂移和动态模式，这需要考虑这些因素的专门评估技术。进行上下文评估时，重要的是创建捕获生产环境特异性的评估框架。这涉及使用包括正常运行、各种类型的事件以及不同的环境和时间条件在内的广泛场景的数据集。除了数据集选择，对AIOps解决方案进行上下文评估还需要定义与期望结果和目标一致的适当评估指标和基准。 (详见第4.2节)

表2. 提出的用于对事件管理中的AIOps方法进行分类的分类法。

提出的分类法

在本文中，我们提出了一个全面的分类法，用于对与事件管理相关的AIOps研究工作进行分类。我们的分类法包括主要群组，涵盖了在评估所审查方法的必要性、设计、实施和可重复性时需要考虑的各种因素。精心选择这些类别使我们能够分析许多显著影响事件管理AIOps的维度。这些维度包括上下文，代表着推动和环绕所提出方法的环境因素。此外，我们还研究了与数据特征及其表示相关的因素。此外，我们探讨了使数据可操作以进行高效分析和解释所需的措施。最重要的是详细探讨方法的设计和实施。我们澄清了采用的方法论、学习范式或研究领域以及如何评估方法。此外，我们还强调了所提出方法展示的特异性和验证的有趣要求。为了确保全面性并以结构化方式汇集所有相关方面，表2中详细解释了每个类别。关于为每种方法突出显示的特定属性，这些属性对应于构建AIOps模型所概述的要求，我们的重点仅放在方法明确解决论文中这些标准的情况上（例如，对噪声的鲁棒性或包含解释机制）。举例来说，只有当实验研究明确符合评估协议中概述的时间要求时，才能确定方法是否符合上下文评估标准（详见第4.2节）。一个例子是确保测试集中的异常严格晚于训练集和验证集中观察到的异常。

接下来，我们将深入探讨对我们研究领域具有独特相关性的主要因素。我们的重点是专门探讨不同数据来源并概述所提出AI方法所采用的评估方法。

数据来源和类型

数据在事件管理中起着至关重要的作用，作为指导用于识别其中的预测或描述性模式的方法设计的基本构建模块。主要目标是利用这些数据有效地完成手头的任务。在工业环境中，数据来自多种来源，包括物理或软件组件，并且也可以由人类生成或编辑。这些数据的一个关键特征是其非结构化的性质，缺乏标准化格式并显示出非均匀性。因此，来自不同来源的数据需要进行预处理阶段以进行后续分析。此外，来自同一来源的数据可以以各种方式表示。我们根据以下约定对数据来源进行分类。

源代码。 它代表软件的基本构建模块，包括各种单元，如函数、文件代码、类和模块。它反映了软件系统中不同功能和服务的设计、结构和逻辑。在先前的工作中，源代码已以多种方式表示，包括代码度量，这些度量是直接从源代码中导出的手工制作的特征。代码度量通过量化可能影响软件质量的代码库的不同方面，在软件缺陷预测中发挥关键作用。这些度量涵盖了广泛的范围，从静态模块级度量[172]（如代码行数（LOC）、对象间耦合（CBO）、方法间缺乏内聚性（LCOM）和继承树深度（DIT））到类级度量[67]（如方法数（NOM）、类的加权方法数（WMC）和类的响应（RFC）），提供了有关模块复杂性和潜在缺陷倾向的见解。机器学习算法使用这些度量进行训练，以识别代码质量和缺陷之间的模式和关系。源代码的另一种表示形式是抽象语法树（AST）[253]，它通过将代码分解为表达式、语句、函数、类和变量等组成元素来捕获代码的句法结构（见图9）。源代码已使用程序频谱[22, 55]进行建模，程序频谱从特定视角提供执行信息，例如条件分支或无循环内过程路径，也作为一系列标记[193, 282]在许多研究工作中特别是在软件故障定位中。

图9. Java方法及其抽象语法树（AST）示例。

图10. 日志解析示例[276]。

拓扑结构（环境特征）。 拓扑结构指的是IT环境的结构，无论是物理的还是逻辑的。它包括有关系统内部组件、连接和空间关系的信息。这个数据源提供有关整体架构的宝贵见解，提供有关服务器、网络设备、数据库等的详细信息。此外，拓扑数据可能包括配置设置、软件版本和系统的其他相关特征。拓扑的存在很重要，因为它为识别数据中的可操作和上下文化模式提供了必要的背景。如果没有拓扑提供的约束和上下文，检测到的模式，虽然有效，可能会具有误导性或分散注意力[205]。拓扑在各个领域得到了广泛应用，例如确定因果关系和本地化故障[154, 210]，排名事件[153]，事件预测[143]以及增强模型的可解释性[212]。

事件日志。 日志由软件应用程序、操作系统或设备生成的可读语句组成，用于描述事件或操作。它们作为宝贵的记录，提供有关系统活动、错误、警告和其他相关事件的信息。通常，日志中包含时间戳，以及事件的来源、严重程度和描述等详细信息。分析日志对于理解导致事件的事件序列、识别异常行为、调试问题以及最终查找根本原因至关重要。一般来说，日志是由源代码中的日志语句（例如printf()、logger.info()）生成的半结构化文本。一旦收集了日志，就需要对其进行解析，以便在各种下游日志挖掘任务中使用，例如事件检测。

解析日志消息是使日志可用于不同分析任务的关键步骤。这个过程旨在通过提取常量部分和变量来将半结构化的日志消息转换为结构化的日志事件[104]。在图10中给出的示例中，展示了一个日志解析场景，展示了从Hadoop分布式文件系统（HDFS）[276]获得的日志消息，一个日志消息包括两个主要组成部分，消息头和消息内容。消息头由日志框架确定，相对容易提取，包括诸如详细信息（例如INFO）之类的详细信息。另一方面，从消息内容中提取关键信息则更具挑战性，因为其非结构化性质，主要由开发人员编写的自由形式自然语言组成。通常，消息内容包括常量和变量。常量代表开发人员提供的固定文本（例如单词“Received”），描述特定系统事件。另一方面，变量对应于程序变量的动态运行时值，携带上下文信息。常量集形成事件模板。许多日志解析技术已被提出，包括基于聚类的方法（例如，LKE [93]，LogSig [241]），基于启发式的方法（例如，iPLoM [170]，SLCT [245]），进化算法，如MoLFI [177]，以及频繁模式挖掘技术，如Logram [71]。这些算法根据离线或在线解析模式、覆盖范围以及与领域知识的对齐等因素进行评估。解析后的日志已被用于具有不同方法的日志挖掘算法，包括结构化特征 [106, 276]、日志序列 [85, 173]、图 [189]和有限状态自动机（FSA）[160]。更多细节，请参考 [104, 106] 的工作。

关键绩效指标（KPIs）。这些指标用作评估IT基础设施和服务健康状况的绩效指标。它们提供定量测量，为系统性能、可用性、可靠性和响应时间提供见解。这些指标的示例包括服务响应时间、错误率、磁盘读取、资源利用率（如CPU、交换空间和内存消耗）等。通常，这些指标被表示为单变量或多变量时间序列，用于各种目的，如检测异常趋势 [150, 256]，通过监测某些指标预测故障 [138, 162]，估计物理部件或存储容量的剩余寿命 [298]，识别经常发生和未知的性能问题 [151]，以及进行根本原因分析和事件相关性 [115, 223]。

网络流量。这种类型的数据涉及计算机网络内数据包流量的分析，包括源和目标IP地址、端口、协议和数据包大小。这种数据源为通信模式、网络拥塞、异常情况和潜在安全威胁提供宝贵见解。通过分析网络流量，可以识别和解决与网络相关的问题，找出性能瓶颈，并检测可能导致重大事件的恶意活动迹象。已采用不同方法对网络流量数据进行建模。例如，在一项研究中 [129]，SNMP数据被用于监视网络链接并诊断网络流量中的异常。作者将流量测量视为随时间收集的多变量时间序列，使流量分为正常和异常子空间。

图11. Eclipse中关于缺少XML文件节点的错误报告示例。此错误报告涉及Product Web Tools Platform [277]中的一个bug。

在同一作者的后续工作中 [130]，静态特征，如源和目标目的地地址或端口，被纳入流量数据中，以检测和诊断安全威胁和服务中断。另一种方法，如 [255] 中所述，涉及使用IDX文件格式将网络流量表示为类似图像的结构，用于加密流量分类。该过程涉及将网络流量数据映射到2D网格，其中每个网格单元代表特定的流量属性，如数据包大小、源IP地址或目标端口。图像中每个像素的强度或颜色反映了该特定位置对应的网络流量属性的值或频率。此外，网络流量已被 [35] 表示为图，以定位网络中性能问题的源头。从网络基础设施中交换的数据包观察构建了概率推理图。推理图的节点分为根本原因节点（对应内部IP实体）、观察节点（对应客户端）和元节点，用于模拟前两种节点之间的依赖关系。每个节点还与一个分类随机变量相关联，该变量模拟当前状态（正常、故障、停机），受其他节点通过依赖概率的影响。

事件报告。事件报告是全面记录事件细节、影响、讨论和解决方案的宝贵信息来源。这些报告通常由开发人员、测试人员或最终用户发起，捕获关键信息以帮助事件管理。如图11所示，事件报告通常包括一个标识号和标题，以及诸如事件报告和修改时间轴、受影响系统或服务的拓扑结构、事件的严重性或重要性、负责解决问题的程序员、事件解决状态（例如，新建、未确认、已解决）等上下文特征。事件报告中最重要的部分是详细描述问题，包括如何重现问题、堆栈跟踪（在出现错误时）、期望的行为等信息。报告中的额外评论可能包括关于潜在解决方案、诊断和根本原因分析以及采取的缓解措施的讨论。附件，如建议的补丁、测试用例或截图，也可能包括在内，以提供更多背景和支持。此外，事件报告应提供历史背景，以利用类似事件的过去知识。标记来自先前事件的相关信息使得可以在当前解决过程中应用宝贵的经验教训。

图12. 左] 来自[[295]的内存消耗警报示例。[右] 警报模板提取的解释。

处理事件报告的挑战在于数据类型的多样性，包括结构化、半结构化和非结构化数据。例如，环境特征通常以结构化或表格格式呈现 [66, 202, 277]，而堆栈跟踪、问题SQL查询和用户跟踪属于半结构化数据类别 [202, 286]。另一方面，问题描述和评论部分专门用于问题分析和诊断的部分包含非结构化自然语言文本 [60, 132, 277]，需要数据规范化。已采用各种方法对这些不同数据类型进行编码。例如，陈等人 [60] 和范等人 [202] 均利用FastText算法 [47] 进行文本编码。在 [132] 中采用的另一种方法是使用Word2Vec [179]，它基于外部语料库构建预训练的子词向量，然后使用历史事件数据进行微调。另一方面，范等人 [202] 的工作中使用指数族嵌入来处理上下文化数据。此外，一些研究人员探索事件报告中的分配信息，创建所谓的Tossing Graph，旨在减少将事件重新分配给其他开发人员的需求 [45, 114, 266]。

警报信号。警报信号是由监控系统或工具生成的通知，当时间序列指标上的特定阈值或事件发生条件违反时产生。这些信号作为异常行为、潜在问题或违反已建立阈值的迹象。触发事件的示例包括高CPU使用率、低磁盘空间、高延迟时间或应用程序错误。警报信号充当早期警报系统，允许在问题升级为故障之前主动识别和解决新问题。值得注意的是，警报信号不是直接从监视系统收集的原始或未经处理的数据，如KPI指标或事件日志。相反，它们是基于一组预定义规则从指标或事件派生的经过精炼的数据。例如，图12（左）展示了AlertRank Framework [295] 生成的一个警报示例，指示当前内存利用率已超过79%的阈值，导致P2错误严重性。此警报是通过对时间内存消耗的分析生成的，并使用源代码中的警报模板生成，类似于图12（右）中显示的日志事件。警报信号通常用于识别和优先处理系统中的关键问题 [295]。它们还可用于将类似或相同的问题分类到特定类别 [292]，以及推断多个同时事件之间的相关性 [180]。

表3. 事故表格。执行跟踪。 除了上述提到的主要数据源外，这些数据源在事故管理过程中用于开发基于数据的方法来进行事故检测、诊断、分类和解决，还有其他数据源特别与某些任务相关。一个例子是代码跟踪，它提供了一个层次化描述，描述了为满足用户请求而调用的模块和服务，并在诊断任务中使用。这些跟踪捕获了控制流、方法调用、输入/输出数据以及与外部依赖项的交互。执行跟踪对于诊断复杂或间歇性问题尤为重要，这些问题很难重现。例如，堆栈跟踪是提供有关在崩溃期间执行的方法及其关联包的详细报告。它们可以通过各种编程语言中的系统调用获得。堆栈跟踪主要用于崩溃去重，这涉及识别指示相同错误或错误的近似重复报告。堆栈跟踪已经被建模为使用图形表示[127]、基于序列的方法[50, 82]或矢量化技术，如 n-grams 和 TF-IDF 用于信息检索目的[135, 219]。另一种重要类型的执行跟踪包括执行的 SQL 查询，以检索服务或重要数据。高效解析 SQL 查询对于将其馈送到分析模型以提取诸如表、谓词和投影等基本组件至关重要。这使得它们可以作为静态特征用于识别数据库中数据模型的模式问题并提高性能，例如推荐和选择索引、检测反模式和识别内部威胁。另外，一些方法将 SQL 查询视为自然语言，采用 Query2Vec 等技术来捕获其语义含义。在 Java 内存分析中，堆转储是另一种可考虑的数据类型。它们是在特定时间点拍摄的 Java 堆内存的快照。Java 堆是在 Java 应用程序执行期间分配和释放对象的内存区域。堆转储捕获了 Java 堆的完整状态，包括所有对象及其属性，如实例变量和引用。这提供了对 Java 应用程序内存使用情况的详细视图。堆转储对于分析与内存相关的问题特别有用，比如内存泄漏[119, 273]。在相关文献中，堆转储通常被表示为树[133]、图[171]或层次结构[209]。

表 4. 从列联表获得的度量。

评估指标

为了全面评估基于数据的方法在事故管理任务中的质量和性能，至关重要的是使用适当的度量标准，也称为评估指标。虽然机器学习度量标准通常用于评估预测模型，但值得注意的是，仅依赖这些度量标准，如列联度量，可能无法准确反映模型在现实场景中的性能，特别是考虑到时间限制时。例如，在事故预测的情况下，目标是在最小化虚警和最大化实际事故覆盖的情况下预测事故。然而，在指定的预测期间 (Δ?? ) 后预测事故不被认为是准确的，因为事故已经发生，导致时间和资源的次优分配。因此，我们介绍了一组已建立的度量标准，主要关注两个主要任务：检测和预测事故。值得一提的是，这些度量标准也可以适应其他任务，并已提出了几种其他度量标准来评估分类、诊断和自动修复操作的有效性，这将简要介绍。为了有效组织这些度量标准，我们根据模型输出的性质对它们进行分类。

分类度量标准。 分类度量标准通常源自四种情况，如表 3 所示。如果在预测期间发生事故并发出警告，则将预测分类为真正例。相反，如果没有发生事故但发出了警告，则将预测视为假正例。如果算法未能预测真实事故，则被归类为假负例。最后，如果没有发生真实事故且没有发出事故警告，则将预测标记为真负例。为了计算精度和召回率等度量标准，列联表中填入真正例 (TP)、假正例 (FP)、假负例 (FN) 和真负例 (TN) 的数量。预测算法应用于未用于确定预测方法参数的测试数据。这允许将预测结果与事故的实际发生进行比较。这四种可能情况如图 13 所示。值得注意的是，预测期间 (Δ?? ) 对于确定是否计算为预测事故至关重要。因此，Δ?? 的选择也对列联表产生影响，并应与事故管理过程中后续步骤的要求保持一致。

图 13. 显示真实事故和所有四种预测 TP、FP、FN、TN 的时间线。

表 4 中呈现的度量标准源自列联表 (见表 3)。它们通常成对使用，如精度/召回率、真正例率/假正例率、灵敏度/特异性和阳性预测值/阴性预测值。不同的研究领域可能对相同的度量标准使用不同的名称，因此，最左侧的列显示常用术语，而最右侧的列列出替代名称。值得注意的是，提高精度 (减少假正例) 往往会导致召回率的降低 (增加假负例)，反之亦然。为了平衡精度和召回率之间的权衡，F-度量被用作两者的调和平均数，假定权重相等。精度和召回率的一个局限是它们不考虑真负预测。因此，需要结合其他度量标准来考虑精度和召回率。假正例率是错误预测事故与非事故总数的比率。较低的假正例率是可取的，前提是其他度量标准不恶化。

由于事故的罕见性，准确性似乎是事故预测的适当度量标准。通过始终将系统分类为非故障来实现高准确性可能是误导性的，因为它未能捕获任何事故，导致召回率为零。然而，在评估事故预测技术时考虑真负例是重要的。让我们考虑 [220] 中的一个例子。两种预测方法在真正例 (TP)、假正例 (FP) 和假负例 (FN) 方面表现一样好，导致相同的精度和召回率。然而，其中一种方法的预测次数是另一种方法的十倍，因为它在更频繁的测量上运行。这些方法之间的差异仅在于真负例 (TN) 的数量，这在包含 TN 的度量中变得明显。通过考虑在没有事故迫在眉睫且没有发出警告时进行的预测来计算真负例。

值得注意的是，预测的质量不仅取决于算法，还取决于诸如数据窗口大小 (Δ?? )、提前时间 (Δ?? ) 和预测期间 (Δ?? ) 等因素。在确切时间点预测事故是非常不可能的，因此通常在特定时间间隔内进行预测 (预测期间)。真正例的数量受 (Δ?? ) 的影响：较长的预测期间捕获更多事故，增加真正例的数量并影响召回率等度量标准。事故预测器通常使用可调节的决策阈值。当阈值设置较低时，容易发出事故警告，增加捕获真实事故的机会 (导致高召回率)。然而，较低的阈值也会导致许多虚警，导致精度降低。相反，如果阈值设置得非常高，则情况将反转。为了可视化这种权衡，通常使用精度/召回率曲线，绘制不同阈值水平下的精度与召回率。类似地，接收者操作特征 (ROC) 曲线绘制真正例率与假正例率 (灵敏度/召回率与 1-特异性)。该曲线评估模型区分事故和非事故的能力。曲线越接近 ROC 空间的左上角，模型的准确性就越高。曲线下面积 (AUC) 定义为 ROC 曲线与 x 轴之间的面积，衡量了数据点从事故易发情况中获得比非事故易发情况中的数据点更高分数的概率。通过总结预测算法区分事故和非事故的能力，AUC 将 ROC 曲线转换为一个数字。随机预测器的 AUC 为 0.5，而完美预测器的 AUC 为 1。

表 5. 用于事故管理任务中回归任务的度量标准。

回归指标。 回归指标通常用于诸如剩余寿命估计或异常检测等任务，尤其在应用于时间序列度量数据以识别异常值时。与分类指标不同，用于回归器的指标在传统机器学习模型中保持一致，如表5所示。平均绝对误差（MAE）是一个指标，代表预测值 ?ˆ? 与实际值 ?? 之间的平均绝对差异。它提供了误差平均幅度的度量。一些研究已经利用了MAE进行回归任务 [197]。均方根误差（RMSE）类似于MAE，但它取预测值和实际值之间的平均平方差的平方根。RMSE更严厉地惩罚较大的误差。例如，在异常检测中已经使用了RMSE [134]。平均绝对百分比误差（MAPE）衡量了预测值和实际值之间的平均百分比差异。在评估相对于目标变量规模的预测准确性时特别有用 [146]。R平方（R2）是一个用于表示目标变量中被预测值解释的方差比例的指标。R2的范围从0到1，其中数值1表示完美拟合，数值0表示与天真基线相比没有改进 [227]。最后，解释方差分数类似于R2，衡量了目标变量中被预测值解释的方差比例。然而，它基于残差的方差，可以作为替代度量进行评估 [227]。

其他指标。 除了常用的回归和分类指标外，还存在一组专门针对评估特定事件管理任务效果和性能的专业指标，例如故障定位、事件关联和事件去重。这些指标通常专门为事件管理目的而设计，可能在该领域之外的适用性有限。其中一些指标是根据特定研究开发的，而另一些则是事件管理领域独有的。例如，Wang等人 [251] 提出了用于检测网络流量序列中异常的“正常性”指标。

在故障定位研究中，有几个特定的指标用于评估不同技术的有效性。其中一个指标是T-Score，它估计了程序员在识别程序中第一个错误位置之前可以忽略的代码百分比 [157, 215]。另一个常用的指标是EXAM（开销指标），它衡量了在遇到第一个错误语句之前需要检查的程序语句的百分比 [116, 118]。除了这些指标，其他研究工作还使用了Wilcoxon符号秩检验 [258, 259] 作为统计评估方法。当无法假设人口正态分布时，该检验可用作一种替代性方法，用于比较两种技术的效果，分别表示为 ? 和 ?。该检验检验了一个单尾的备择假设，即 ? 需要检查的语句数量等于或大于 ?。

在软件缺陷预测中，有时更有用的是根据它们在排名方式下预测的缺陷数量来评估类。评估预测模型性能的一种方法是计算Spearman相关系数 [232]，正如[72]所展示的研究所示。在这种情况下使用的另一种方法是累积提升图，它通过绘制累积增益与案例数量的关系来比较两种不同模型或策略的性能。这种方法也被[86]采用。

在实际网络设置中的入侵检测系统中，Mirheidari等人 [180] 进行了一项关于警报关联算法的全面比较。该研究旨在使用定量和定性措施评估这些算法的性能。定量评估侧重于准确性，而定性评估则涉及额外方面，如可扩展性和灵活性。这些方面指的是算法的适应性、可定位性以及适应新条件的能力。此外，评估考虑了算法并行化任务的能力以及相关的内存需求。这种评估与第3.4节中强调的AIOps解决方案在事件管理中所需特性一致。

在事件分类和去重方法的背景下，已经采用了特定的性能指标来改进这些过程的评估。这些指标包括平均倒数排名 [70, 211]、第k阶召回率 [125, 222, 248] 和平均命中率 [23]。值得注意的是，有一些指标专门设计用于评估过程，而不是特定算法或数据驱动方法。虽然我们之前讨论过像平均修复时间（MTTR）、平均参与时间（MTTE）和平均检测时间（MTTD）这样的指标，但其他研究工作 [66, 205] 引入了替代术语。例如，MTTR可能被称为平均修复时间，MTTD可能被称为平均检测时间。此外，还考虑了其他有价值的度量，如平均故障间隔时间（MTBF）[48]，用于评估连续事件或故障之间的平均持续时间以评估系统可靠性。

基于AIOps的数据驱动方法的全面审查

在接下来的章节中，我们将对围绕AIOps驱动的数据中心方法专门针对事件管理进行的研究工作进行审查。我们首先提供了相关和类似研究的深入概述，为那些对特定事件阶段或应用领域感兴趣的人提供了宝贵的指引。我们还审查了一些值得关注的调查，这些调查提供了针对领域特定方面的有针对性的见解。随后，我们深入研究了在事件管理文献中找到自己位置的开创性技术。我们根据我们的分类法描述了事件管理任务的每个方面，通过专用表格中的摘要和评估提供了描述。这些表格作为高效的参考点，为读者提供了每个任务的清晰简洁的概述。此外，我们评估了审查论文是否符合必要标准的程度。

AIOps和事件管理中的先前研究工作

表6. 事件管理相关论文的总结和分类

在过去的二十年里，已经有大量的研究工作致力于有效应对自动化事件管理程序。这在IT系统的扩展和基础设施规模不断扩大的背景下变得尤为重要。这些进展导致了涵盖多个目标领域的各种事件类型的产生，需要快速报告、理解和缓解。许多研究倡议，受工业要求驱动，致力于构建事件管理程序。这些努力涉及制定分类法或全面框架，深思熟虑地考虑各种要求和挑战，同时包括审查现有方法以适应提出的框架的特定方面 [46, 140, 185, 195, 208, 286, 290]。其他则将焦点放在从真实工业场景中获得的实际见解上，通过经验论文和用例研究提供有效的实施细节、专业技术和研究创新 [66, 73, 165]。

随着AIOps成为一个涉及多个领域和应用的新颖跨学科研究前沿，值得注意的是早期工作 [140, 161, 185, 286, 290]，特别是2018年之前的工作，尽管与其概念框架和范围相符，但并未明确引用术语AIOps。此外，其中一些作品可能介绍非数据驱动的方法，因此超出了AIOps领域的范围。在接下来的内容中，我们将对与我们在事件管理中的AIOps的全面审查密切相关或具有一定相似性的相关研究进行比较分析。目标是确定关键的差异标准，包括它们的焦点领域、是否提出分类法、显著发现以及提供实际见解以促进有效实施。此外，我们还将深入研究关于事件管理特定阶段的调查和评论，例如故障预测或根本原因分析，而不对整个过程进行详尽审查 [23, 44, 57, 75, 86, 94, 104, 109, 109, 113, 121, 180, 220, 230, 231, 251, 261, 296]。此外，我们还探讨了针对特定数据源的作品，例如对日志事件数据中异常检测的研究。

表7. 针对特定事件管理阶段的特定数据驱动调查和评论的总结和分类

表6汇编了最重要的AIOps和事故管理研究论文的概述。我们的目标是帮助读者找到与其特定问题和研究主题相关的作品。此外，我们旨在找出研究中的空白并从现有文献中得出创新的想法。我们将所选研究分类为不同因素。这种分类有助于读者采用各种方法，包括提供当前最新技术整体概况的调查论文、深入分析文献并根据客观标准进行技术比较的文献综述，以及提供实践见解的研究，如工业经验论文和使用案例。值得注意的是，自2018年以来，事故管理方面的开创性研究越来越多地纳入了AIOps首字母缩写。对于这些论文中的每一篇，我们评估它们在覆盖事故管理各个阶段方面的程度，如第3.3节所定义。尽管这些作品大多集中在报告阶段（检测和预测）以及根本原因分析和缓解方面，但在排名、分配和去重等方面存在明显的空白。值得注意的是，一些研究论文在涉及事故这一广泛概念时范围有限。例如，Zhang等人[286]仅涉及软件缺陷管理，因此忽略了其他领域，如剩余有用寿命估计。我们的分析还延伸到对AI模型在现实场景中的实施见解。我们报告这些论文是否提供了相关挑战、需求的全面描述，并阐明了潜在未来研究的空白。Notaro等人进行的研究[196]与我们的工作密切相关。然而，它在解决某些方面，如分配和去重方面存在空白。此外，它缺乏对在生产场景中建立AIOps的挑战和需求进行深入技术探讨。

在表7中，我们提供了关注事故管理程序中特定阶段的最相关调查和综述的概述，而不是对整个过程进行全面分析。这些调查深入研究特定方面，如异常检测[57, 251]、在线故障预测[220]等。我们根据它们的主要焦点和范围将这些研究组织成不同类别。例如，某些调查将其范围缩小到特定行业，比如[75]的工作仅集中在预测铁路部门内的故障。与此同时，Mirheidari等人[180]讨论了关于相关警报的问题，用于网络入侵检测系统。重要的是，这并不排除所审查方法在其他实际领域中的潜在适用性。此外，我们概述了这些调查中使用的目标维护水平、可用数据来源和数据驱动方法。其中一些研究还强调了用于评估所审查方法的评估指标。在特定情况下，比如[230]进行的关于根本原因分析的研究中，采用了领域特定的度量标准，如第4.2节所讨论的（例如，这些特定的度量标准评估了同时定位多个故障、识别未知故障等方面）。

事故检测方法

事故检测方法是事故管理的一种反应性方法，旨在跟踪和识别系统中的异常状态或行为。它们的目的是在故障发生之前预测故障或在故障发生后减轻后果。这是基于这样的理解，即尽管采用了先进的预测技术，但完全消除故障的发生是不可能的。这些方法还有助于理解导致事故的因果关系，以及了解导致事故的时间特征。事故检测方法通常利用无监督学习方法，主要是因为获取高质量、充足和平衡的数据标签存在重大挑战。在这个背景下，常见的技术包括聚类方法、降维技术和自动编码器。此外，还有其他方法，如图挖掘和统计模型，在这个背景下被应用。

在网络层面，Lakhina等人[129]提出了一种使用SNMP数据进行网络流量分析的异常检测方法。作者应用主成分分析（PCA）将随时间收集的流量测量链接到正常和异常子空间。通过使用异常组件重建新观测数据来识别异常。如果重建误差超过基于解释方差的预定义阈值，则将数据点视为异常。在随后的作品[130]中，同一作者认为通过分析流迹中数据包特征（IP地址和端口）的分布，可以揭示网络流量中各种异常的存在和结构。他们使用熵作为一个总结工具，来量化这些特征分布的随机性或不规则性。该方法已经证明其能够适应新类型的异常。然而，Ringberg等人[217]对[129]中PCA的应用提出了担忧，指出其对小正常子空间噪声的误报率敏感。因此，Pascoal等人[200]提出了另一种方法，该方法结合了具有鲁棒特征选择技术的弹性PCA检测器，以适应不同的网络环境和情况。此外，这种方法在训练过程中消除了对完美基准数据的需求，解决了[129]中传统PCA方法中存在的局限性。Karami和Guerrero-Zapata[120]引入了一种用于识别攻击和异常的聚类方法，范围从拒绝服务（DoS）到侵犯隐私，在内容中心网络中。该方法通过两个不同阶段运行。首先，在训练阶段，采用粒子群优化（PSO）和K均值算法的独特混合，以准确确定最佳聚类数，并避免陷入局部最优解。在随后的检测阶段，通过结合两种基于距离的方法，采用模糊方法，有效地识别新监测数据中的异常，其中通过可靠地检测入侵活动来降低误报率。

表8. 回顾的AIOps事故检测方法摘要。

表9. AIOps事故检测方法的特殊性研究。

在这个背景下，统计方法也被应用。例如，Pena等人[201]提出了一种使用非经典的不一致逻辑（PL）结合两种无监督流量特征化技术的相关一致机器（CPM）。这些技术涉及用于数字签名的蚁群优化（ACODS）和自回归积分滑动平均（ARIMA）。这些方法的目的是分析历史网络流量数据并生成两种不同的网络配置文件，称为使用流量分析的网络段的数字签名（DSNSF），描述正常流量行为。异常的检测与不一致逻辑产生的确定度和矛盾程度相关联，当将两个预测配置文件与实际流量测量相关联时。在另一项研究中，Bang等人[37]提出了一种利用隐藏半马尔可夫模型（HsMM）的入侵检测系统（IDS），专门用于检测无线传感器网络（WSNs）上的LTE信令攻击。作者认为传统的隐马尔可夫模型（HMM）在表示各种潜在转换行为方面存在局限性，而HsMM克服了这一限制，因为它具有任意状态逗留时间，使其更适合分析时间序列行为。HsMM被有效地用于对服务器唤醒数据包生成过程的时空特征进行建模。然后，检测器将观察到的服务器唤醒数据包的时空特征与HsMM建立的正常标准进行比较。随后，每当发生显著偏差时，就会触发警报。Xie等人[270]提出了一种算法，用于检测WSNs中的长期异常，其中一组相邻节点在相当长的时间范围内一直受到这些异常的影响，特别是在DoS和汇聚点攻击的情况下。为了实现这一点，作者采用Kullback-Leibler（KL）散度来衡量连续时间间隔内全局概率密度函数之间的差异。由此函数导出的时间序列经过基于自适应阈值的分析，以识别与正常情况有显著偏差的情况。最近，Deng 和 Hooi [80] 解决了在网络安全攻击背景下检测异常事件的挑战，通过分析高维时间序列数据，特别是传感器数据。作者提出了一种结合结构学习和基于注意力的图神经网络的方法，该方法学习传感器之间的依赖关系图，并识别和解释这些关系的偏差。为了为异常提供有用的解释，采用了基于预测的方法，根据过去的数据预测每个传感器在每个时间点的预期行为。这使用户能够轻松识别与预期行为差异很大的传感器。此外，用户可以比较每个传感器的预期行为和观察到的行为，以了解模型为何将传感器视为异常。该方法还具有高度的灵活性，可在不仅仅是网络安全攻击的广泛用例中进行扩展。

另一个关注点是检测边缘流中的异常，这些边缘流具有一些特定性，因为它们通常用于捕获动态和演化网络中的交互。Yu 等人 [283] 提出了 NetWalk，这是一种用于实时检测动态网络中结构异常的新方法，这种网络在社交媒体、安全和公共卫生等领域中很常见。与为静态网络设计的传统方法不同，NetWalk 专注于需要不断更新网络表示的动态环境。所提出的方法采用了一种新的嵌入方法，将顶点编码为向量表示。该过程通过将从动态网络遍历中得到的顶点表示之间的成对距离最小化，并利用深度自动编码器重构误差作为全局正则化。向量表示是通过一种需要恒定内存空间的采样技术高效计算的。基于学习到的低维顶点表示，NetWalk 使用基于聚类的技术来增量和实时地检测网络异常，随着网络的演变。这种方法可以应用于各种类型的网络，使其适用于不同的应用领域。在同样的背景下，Yoon 等人 [281] 提出了 AnomRank，专门解决在动态图流中检测突发异常模式的挑战，如链接垃圾邮件和粉丝增长，采用独特的双重方法，引入了用于衡量异常性的新颖指标。这些指标跟踪节点分数或重要性函数的导数，从而实现对节点重要性突变的检测。AnomRank 通过实验证明了其可伸缩性，在短短几秒内处理数百万条边，同时通过为其双重方法提供保证，证明了其理论上的合理性。F-Fade [58] 是另一种检测边缘流中异常的方法，它提出了一种频率分解技术，用于建模节点对之间交互频率的时间演变分布。然后基于每个传入交互的观察频率的概率来检测异常。这种方法还被证明在在线流设置中有效运行，同时需要恒定内存。许多替代方法涉及分析关键绩效指标和度量观察，以有效识别发生在技术、应用和功能层面的异常。通常，这些方法采用在单变量或多变量时间序列数据上训练的无监督模型。例如，CloudPD [225] 是云环境中异常检测的故障管理框架，引入了传统的机器学习技术，解决了云环境中的异常检测问题，涉及虚拟机（VM）和应用程序机器级别的各种度量，包括操作系统变量和应用程序性能指标。该论文建议结合三种无监督机器学习方法：k-最近邻（k-NN）、HMM 和 K-均值聚类。类似地，Vallis 等人 [247] 解决了在 Twitter 上检测云计算环境中长期异常的挑战。作者提出了一种使用广义极端学生化残差检验（ESD）的新统计学习方法，并结合时间序列分解和鲁棒统计学来识别异常，例如对基础长期趋势的分段逼近，减少假阳性的数量，同时考虑每日内和每周内的季节性，以进一步减少假阳性。所提出的技术适用于各种类型的时间序列数据，包括应用指标如每秒推文数和系统指标如 CPU 利用率。另一方面，Liu 等人 [158] 提出了一种名为 Opprentice（操作员学徒）的新型监督方法。在这种方法中，操作员需要定期使用用户友好的工具标记性能数据中的异常。然后，将多个现有检测器并行应用于数据，以提取异常特征。这些特征连同标记数据用于训练随机森林分类器。该分类器自动选择合适的检测器参数组合和阈值。在 [228] 中，作者提出了一种利用极值理论识别流式单变量 KPI 中异常值的新方法。所提出的方法消除了手动设置阈值的需要，并不假定任何特定的数据分布。该方法中的关键参数是风险水平，它控制假阳性的率。除了异常值检测，该方法还可以自动设置阈值，使其适用于各种场景，包括入侵检测。

Donut [274] 解决了在大型互联网公司的 Web 应用程序中检测季节性关键绩效指标（KPIs）异常的挑战。作者提出了一种基于变分自动编码器（VAE）和窗口采样的无监督方法。重要的是，该论文还介绍了一种用于在 Donut 中重建异常的核密度估计（KDE）的新颖解释，为其提供了坚实的理论基础，并使其成为第一个具有明确定义的理论解释的基于 VAE 的异常检测方法。在 [150] 中，作者提出了一种基于 KPI 聚类的策略，其中数百万个 KPI 被分组到较少数量的簇中，允许选择并基于每个簇进行模型选择和训练。这种方法解决了由于 KPI 的独特性质（如其延长长度和易受噪声、异常、相位偏移和幅度差异的影响）而产生的各种挑战。因此，该论文提出了一个名为 ROCKA 的框架，其中包括时间序列预处理、基线提取、基于密度的带噪声应用空间聚类（DBSCAN）与动态时间规整（DTW）距离和分配步骤。Ren 等人 [213] 在 Microsoft 开发了一个复杂的时间序列异常检测服务，强调其在持续监控和事件警报中的作用。该论文详细介绍了服务的基础管道和算法，突出了三个关键模块：数据摄入、实验平台和在线计算。值得注意的是，该论文介绍了一种结合了谱残差（SR）和卷积神经网络（CNN）技术的新算法，用于处理单变量 KPIs。

在略有相似的背景下，Zhao 等人 [294] 利用一家知名商业银行的真实数据进行了研究，量化了软件变更对事件（包括代码缺陷、配置错误、资源冲突和软件版本差异）的重大影响。这种定量分析得到了定性见解，揭示了当前检测实践的局限性，特别是在处理软件修改中固有的异构多源数据时。基于这些见解，该论文介绍了一种名为 SCWarn 的方法，利用 LSTM 模型进行多模态学习，以识别有害变更并生成可解释的警报。作者还定量展示了他们的方法在减少检测有害变更所需的平均时间方面的效率。Wang 等人 [256] 通过引入 Kontrast 解决了类似的问题，这是一种自监督和自适应方法，采用对比学习。该方法专注于比较软件变更前后的 KPI 时间序列，以确保系统在变更后的稳定性。为了促进对比学习，提出了一种受自监督学习启发的独特数据增强技术，生成带有伪标签的数据。通过论文中进行的实验，所提出的模型显示出令人印象深刻的处理速度和跨数据集的适应性。近年来，出现了大量方法来解决多变量时间序列数据中异常检测的挑战。进行多维分析的两个好处包括能够描绘不同指标之间的相互关系，以及生成可理解的结果以进行根本原因调查 [196]。OmniAnomaly [233] 专注于使用随机循环神经网络框架捕获多变量时间序列中的正常模式，通过学习稳健的表示，采用随机变量连接和平面归一化流等技术。该方法涉及基于这些表示重建输入数据，并利用重建概率识别异常。此外，OmniAnomaly通过分析组成单变量时间序列的重建概率，为检测到的异常提供了有见地的解释。多尺度卷积循环编码器-解码器（MSCRED）[285] 构建多尺度签名矩阵，以表示不同时间步的不同系统状态。它利用卷积编码器捕获传感器之间的相关性，并利用基于注意力的卷积长短期记忆（ConvLSTM）网络通过捕获时间模式来识别异常时间步。利用残差签名矩阵有助于异常检测和诊断。USAD [33] 在自动编码器架构中采用对抗训练，以有效地隔离异常，同时保持快速训练速度。实验结果还关注该方法的可扩展性和稳健性。Li 等人 [149] 提出了 InterFusion，采用具有两个随机潜变量的分层变分自动编码器来捕获正常模式，学习低维度的指标间和时间嵌入。该论文还提出了一种马尔可夫链蒙特卡洛（MCMC）方法，用于获得用于解释异常的有意义重建。

基于日志的方法已经成为检测应用、功能和业务服务中异常的有效手段。Fu 等人 [93] 提出了一种基于聚类的技术，将日志条目映射到它们对应的模板版本，从而实现线模板的识别。随后，他们学习了一个有限状态机，根据日志证据来建模程序工作流程。这种基于有限状态机的模型有助于验证正确的程序执行并检测软件问题。在另一项研究中，[276] 应用文本分析和信息检索技术来检测大规模数据中心中的异常，从控制台日志和源代码中自动提取状态变量和对象标识符，并利用主成分分析（PCA）和词项逆文档频率（TF-IDF）分析它们在不同文档中的频率。通过基于重建误差的阈值规则检测异常。Lou 等人 [160] 首次探索了从日志消息中挖掘不变量以进行系统异常检测。他们确定了两种捕获不同日志消息之间关系的不变量类型：在描述等价关系的文本日志中的不变量，以及表示线性独立关系的线性方程式中的不变量。Log3C [105] 提出了一种级联聚类算法，通过利用日志序列和系统关键绩效指标（KPIs）来有效检测重要的系统问题。该方法涉及迭代采样、聚类和匹配日志序列。随后，利用日志序列簇和系统 KPIs 之间的相关性，通过应用多元线性回归模型来指出和优先处理有影响的问题。

人们已经付出了大量努力来探索顺序循环神经网络（RNNs）及其变体。DeepLog [85] 引入了使用 LSTM 网络从日志中学习模式，并根据先前日志键的观察来预测下一个日志键的概率分布。当出现异常日志键未出现在按概率排名的前 k 个键中时，就会识别出异常日志键。此外，该研究引入了基于用户反馈的在线学习方法，并尝试使用有限状态机提供解释。LogAnomaly [173] 是一个语义感知表示框架，采用语言模型方法，并使用模板嵌入（template2vec）自动组合相似的日志键。这种方法消除了对人工输入的需求。同时解决了日志特定词嵌入和词汇表外问题。Zhang 等人 [291] 发现日志数据经常包含以前未遇到的日志事件或序列，表明日志处理中存在不可预测性和噪音。为解决这一问题，他们引入了 LogRobust，一种利用现有词向量提取日志事件含义的方法。随后，他们采用双向 LSTM 模型和注意机制直接计算异常分数，而不是预测下一个可能的日志键。Xia 等人 [267] 提出了 logGAN，一种基于 LSTM 的生成对抗网络框架，结合置换事件建模用于日志级别的异常检测。该方法既解决了日志的顺序特性，又解决了日志的无序问题，生成对抗网络组件抵消了类别不平衡，从而提高了异常检测性能。最近，引入了一种名为 LogBERT [99] 的新型自监督框架，利用双向编码器表示来自变压器的表示（BERT）的力量。这种方法引入了两种创新的自监督训练任务：掩码日志消息预测和超球体体积最小化。这些任务使 LogBERT 能够捕获正常日志序列中固有的模式。因此，LogBERT 通过检测与这些已建立模式的偏离来识别异常。

事件预测方法

事件预测方法是一种积极主动的方法，旨在通过处理静态方面（如源代码）和动态方面（如计算资源的可用性）来预防故障（在极端情况下是停机）。最终目标是尽早建议预防措施或立即采取行动。这些策略在我们提出的分类法（即使用的数据、应用领域等）方面存在广泛的差异。

软件缺陷预测。 SDP 是一种用于估计在代码的功能单元（如函数、类、文件或模块）中遇到软件缺陷的可能性的方法。将 SDP 与故障发生联系起来的核心假设是有缺陷的代码会导致执行过程中的错误和故障。传统上，使用代码度量来识别易出现缺陷的软件，并构建缺陷预测器，如 4.1 中所述。Nagappan 等人 [187] 提出了一种基于代码复杂度度量的 SDP 方法。然而，他们强调这些度量之间的多重共线性是一个更复杂的问题。为了解决这个问题，他们采用主成分分析（PCA）来获得一组减少的不相关特征，并使用线性回归模型进行发布后的缺陷预测。他们还尝试在不同项目上测试时，从一个项目学习的模型在另一个项目上的应用性。这产生了不同的结果，导致断言项目相似性是成功转移学习的关键因素。Menzies 等人 [175] 将注意力从静态代码度量转移到预测模型的选择，主张使用具有对数特征的朴素贝叶斯。在 [87] 中，作者检验了 SVM 在预测易出现缺陷软件模块方面的有效性，包括过程软件中的函数和面向对象软件中的方法。他们依赖于代码度量，特别是 McCabe 度量[172] 和 Halstead 度量[101]，并将其预测性能与四个 NASA 数据集上的八个著名统计和机器学习模型进行比较。Dejaeger 等人 [79] 探讨了 15 种不同的贝叶斯网络分类器，以确定替代朴素贝叶斯的方法，这些方法可以导致具有更少节点和弧的简化网络，同时保持或改善预测性能。该研究还检验了在 BN 框架内使用马尔可夫毯的原则进行特征选择的适用性。通过进行的评估，该论文表明这些替代的 BN 分类器可以产生简单但可理解的网络，其预测性能与朴素贝叶斯分类器相比具有竞争力。研究结果还强调了在这些模型的解释性和预测能力之间取得平衡的重要性。

表 10. 回顾的 AIOps 事件预测方法摘要。

虽然前面提到的软件缺陷预测（SDP）贡献主要集中在单个发布视角，另一组研究，被称为变更日志方法，强调软件历史作为预测缺陷密度更具影响力的要素。例如，代码年龄或先前缺陷数量等因素可以作为估计新 bug 发生的指标 [96]。Ostrand 等人 [198] 深入分析了庞大软件系统中的变更及其与先前故障的相关性，旨在预测即将发布的版本中的缺陷数量。他们采用泊松广义线性模型，利用模型参数的最大似然估计来评估各种指标的重要性。该模型在内部库存系统的发布周期内进行评估，包括各种新的文件级指标，如编程语言、编辑标志和年龄。研究结果表明，具有最高预计故障计数前 20% 的文件包含随后识别的故障的平均 83%。Moser 等人 [184] 对 Eclipse 项目存储库进行了两组 SDP 指标（代码和变更指标）的比较评估。他们采用了三种不同的机器学习方法，包括朴素贝叶斯、逻辑回归和决策树。分析表明，单独使用变更指标比仅依赖代码指标更有效地识别有缺陷的源文件。此外，综合方法显示出对变更指标导向方法的适度增强或可比较的结果。

（图片链接：Ostrand et al.，Moser et al.）

Nam 等人 [188] 解决了跨项目缺陷预测挑战，特别关注涉及新项目或资源有限项目的情况。在这种情况下，作者试图利用来自已建立源项目的训练数据，并将其调整到目标项目。为实现这一目标，他们采用了一种名为 TCA（Transfer Component Analysis）的尖端迁移学习技术，以协调源项目和目标项目之间的特征分布。此外，他们引入了一个名为 TCA+ 的扩展版本，将这些对齐的特征整合到逻辑回归模型中，以准确预测有缺陷的模块文件。该方法已在由 D’Ambros 等人 [86] 提出的基准 SDP 数据集 AEEM 上进行了评估。对传统代码指标的批评指出其手工制作和简单性质。另一种方法涉及使用 AST 对源代码进行解析。Wang 等人 [253] 质疑代码指标捕捉语义和区分具有相同结构但不同语义的代码区域的能力。他们建议使用潜在语义表示，并在 AST 解析的代码上训练深度信念网络（DBN）以无监督方式学习语义特征。Li 等人 [137] 提出了 DP-CNN，一种名为 Convolutional Neural Network 的新颖框架，用于缺陷预测。该方法涉及提取在解析过程中捕捉多样语义操作的 AST 节点子集。然后，通过映射和词嵌入过程，将这些节点转换为数值特征。随后，将转换后的特征输入到一维卷积架构中，以自动学习语义和结构程序特征。

（图片链接：Nam et al.，Wang et al.，Li et al.）

与现有技术不同，这些技术操作于模块、类或文件等粗粒度单元，Majd 等人 [169] 提出了一种名为 SLDeep 的新方法，旨在在更细粒度的语句级别识别代码的易出错区域。SLDeep 定义了一套全面的 32 个语句级指标，包括语句中二元和一元运算符的使用等因素。他们选择的实现学习模型是 LSTM 模型。实验在来自 Code4Bench 基准测试的 119,989 个 C/C++ 程序的多样集合上进行了。在另一项研究中，Xu 等人 [275] 提出了一种利用 AST 中缺陷子树来表征软件缺陷的方法。该方法整合了来自修复诱发变更和代码概念的信息。首先，开发了一个主题模型，用于总结与缺陷相关的功能概念。缺陷子树中的每个节点都丰富了类型、修复诱发变更和代码概念等属性。随后，采用 GNN 分类器，其中子树被表示为有向无环图结构。最近，Uddin 等人 [244] 结合使用 BiLSTM 模型和基于 BERT 的语义特征方法（SDP-BB）来预测软件中的缺陷。这种组合通过从 BERT 模型学习的令牌向量中提取上下文信息来捕获代码的语义特征，BiLSTM 用于提供关于剩余有用寿命的额外信息，并作为一种排名方法。这些方法通常在离线训练步骤后的在线设置中使用。然而，整合额外数据并在新故障发生时更新有缺陷磁盘的特征等问题是一个挑战。为解决这个问题，[269] 提出的方法提出了在线随机森林的使用，这是一种可以通过在线标记适应性地随着数据分布变化而演变的模型。

（图片链接：Majd et al.，Xu et al.，Uddin et al.）

软件老化和复苏。 软件老化描述了软件系统随着时间推移逐渐性能和可靠性下降的现象。已知导致软件老化的原因包括内存泄漏、膨胀、未释放的文件锁、数据碎片化和数值错误的积累 [54, 196]。相反，软件复苏涉及采取积极或纠正性措施来消除累积的错误条件并释放系统资源。这些措施可能包括垃圾回收、刷新内核表、重新初始化内部数据结构等策略。Garg 等人 [95] 提出了一种估计各种系统资源耗尽时间的方法，包括空闲内存、文件和进程表大小以及使用的交换空间。他们利用回归技术和季节性测试来识别趋势并量化耗尽时间。在相关研究中，Vaidyanathan 和 Trivedi [246] 探讨了由当前系统工作负载导致的软件老化的影响。他们基于可用工作负载和资源数据开发了一个基于半马尔可夫奖励模型，其中不同的工作负载场景被表示为模型状态。使用 k-means 聚类确定与特定状态的关联。为了估计内存和交换空间的耗尽时间，分别为每个工作负载状态采用了非参数回归技术。通过使用基于决策树的线性回归模型集成来解决非线性和分段线性资源消耗的挑战。这些模型是根据与回归模型相同的输入特征（包括组合的硬件和软件主机指标集）使用的决策树选择的。在 Sudhakar 等人 [235] 的研究中，作者主张利用神经网络架构来捕捉云系统中资源使用和故障时间之间的复杂非线性关系。

硬件故障预测。 在大规模计算基础设施中，确保硬件可靠性对于实现服务可用性目标至关重要。然而，由于涉及的组件数量庞大，以及在数据中心中必须使用通用硬件，硬件故障构成了一个重要挑战。例如，Google 报告称，在 4-6 年的时间内，20-57% 的磁盘至少出现一个扇区错误 [178]。硬盘是大型云计算系统中最经常更换的组件，也是服务器故障的主要原因 [250]。为解决这个问题，硬盘制造商在其存储产品中实施了自我监控技术，如 SMART 指标。Zhao 等人 [297] 提出了使用隐马尔可夫和半马尔可夫模型来基于 SMART 指标观察估计可能的事件序列的方法，数据集中约有 300 个磁盘（其中约三分之二是健康的）。使用从健康磁盘序列和有故障磁盘序列训练的两个模型，在测试时估计序列对数似然，类别由最高分确定。Wang 等人 [257] 提出了一种基于相似性的检测算法，使用最小冗余最大相关性（mRMR）选择相关的 SMART 特征，并将输入数据投影到由健康磁盘群体构建的马氏空间中。该方法旨在检测与分布差异较大的有故障磁盘。Xu 等人 [272] 引入了使用 RNN 来建模 SMART 数据中长期关系的方法。与二元分类方法不同，他们的模型训练用于预测磁盘的健康状态，提供有关剩余寿命的额外信息，并作为一种排名方法。这些方法通常在离线训练步骤后的在线设置中使用。然而，整合额外数据并在新故障发生时更新有缺陷磁盘的特征等问题是一个挑战。为解决这个问题，[269] 提出的方法提出了使用在线随机森林，这是一种可以通过在线标记适应性地随着数据分布变化而演变的模型。

（图片链接：Zhao et al.，Wang et al.，Xu et al.）关于其他硬件组件，FailureSim [76] 提出了一种评估云数据中心硬件状态的方法，该方法同时利用了多层感知器和循环神经网络。所提出的方法主要集中在评估与特定组件（如 CPU、内存和 I/O）相关的 13 种不同主机故障状态。另一方面，针对数据中心网络中的交换机故障，Zhang 等人 [288] 提出了一种名为频繁模板树（FT-tree）的新型模型。该模型识别历史系统日志中的频繁词组合，并将其用作消息模板，然后将其与故障行为相关联。随后，使用识别的模板训练隐藏半马尔可夫模型以预测故障。Sun 等人 [237] 提出了一种基于深度学习的主动硬件故障预测方案。该方案主要关注磁盘和内存故障，利用 SMART 数据和系统日志。克服了有效处理离散时间序列数据的挑战，该方案从不同供应商那里规范化属性分布。作者引入了一种专门设计用于处理时间噪声的专业化时间卷积神经网络（TCNN）模型，结合了用于训练高度不平衡样本的定制损失函数。另外，Khalil 等人 [123] 提出了一种旨在预测由老化或不同条件引起的开路故障的方法。该方法利用快速傅立叶变换（FFT）捕获故障频率特征，利用主成分分析（PCA）提炼关键数据并降低维度，利用卷积神经网络进行故障学习和分类。这项值得注意的工作是首次针对硬件系统的晶体管级别故障预测，包括老化、短路和开路故障。

剩余使用寿命估计。 剩余使用寿命（RUL）是操作系统在其运行寿命内的一个关键实时性能指标，表示系统停止运行之前剩余的时间。类似于软件老化技术，精确的 RUL 估计在规划基于条件的维护任务中具有重要意义，旨在最小化系统停机时间。已经出现了大量数据驱动方法来建模系统组件的复杂行为。正如 [44] 中所强调的，LSTM 出现为处理 RUL 问题中的动态数据的高度合适工具。例如，Zheng 等人 [298] 提出的 LSTM 模型熟练地利用传感器序列信息来揭示与各种操作条件、故障和退化模型相关的潜在模式。吴等人 [265] 的另一项研究探讨了一个传统 LSTM 模型，这是 LSTM 的一种常见变体，通常应用于语言处理，用于预测飞机发动机的 RUL。马和毛 [166] 进行了一项名为基于卷积的长短期记忆（CLSTM）的新型混合方法。该方法将 CNN 与 LSTM 网络结合起来，旨在预测旋转机械的 RUL，这是预测和健康管理（PHM）的关键方面。CLSTM 结构保留了 LSTM 的优势，同时集成了时频特征。这使得模型能够同时捕获长期依赖关系并提取时频域特征。通过堆叠多个 CLSTM 层并创建编码-预测架构，形成了一个用于 RUL 预测的深度学习模型。值得注意的是，强化学习也被应用于通过从经验中学习来增强模型的适应性，即使在错误决策的情况下也是如此。模拟环境在这方面特别有优势。例如，[42] 中开发的迁移学习方法利用状态、动作和奖励生成最佳奖励策略。这些算法专门针对顺序预测特定类型泵系统的 RUL。Li 等人 [142] 解决了关于剩余使用寿命的初始预测时间确定的挑战，引入了一种 GAN 方法，该方法从健康机器状态中学习数据分布。健康指标用于确定初始预测时间，并采用对抗训练来对齐来自各种机器的数据，从而提取广义的预测知识。

软件故障预测。 从应用角度预测系统故障涉及探索可能在各个维度（包括作业、任务、进程、虚拟机、容器或节点）出现的故障。现有的方法主要依赖于系统指标、服务状态、跟踪和拓扑。例如，Cohen 等人 [69] 提出了一种以树增强贝叶斯网络（TANs）为中心的方法，以建立观察变量和抽象服务状态之间的联系。该策略有助于预期和预防三层 Web 服务背景下的服务级别目标（SLO）违规和故障。系统监视关键系统指标，如 CPU 时间、磁盘读取和交换空间，构建一个捕获它们之间复杂依赖关系的模型。通过采用启发式选择过程，确定包含最相关输入指标的最佳图结构。一项用于预测数据中心系统可用性的方法在一项研究中被介绍 [56]。该框架采用 ARMA 模型和故障树分析。该框架识别组件级别的症状，如升高的 CPU 温度、故障的磁盘扇区和内存耗尽，这些症状作为故障树的终端点。通过将这些症状和底层树结构结合起来，一个包含组合逻辑依赖的模型确定性地建立可用性状态。这使得在故障升级为故障之前能够主动检测错误。

在 [92] 中，作者通过日志文件分析方法解决了预测系统故障的任务。这涉及使用随机索引技术处理日志文件，该技术有效捕获嵌入在日志消息序列中的复杂上下文信息。随后，实施了一种加权支持向量机（SVM）方法来对这些序列进行分类，将它们分配到即将发生故障的情景或非故障实例中。值得注意的是，该方法考虑了常见的不平衡数据集挑战，特别强调了保持强大真正正例率的必要性。同样，Zhang 等人 [287] 的工作揭示了一种通过实时分析控制台日志来预测系统故障的方法。这种新颖方法通过聚类引入了日志模式提取，将共享相似性的日志格式和内容组合在一起。将日志模式视为类似于单词，并将它们组织成离散时间间隔的文档，这种方法显著简化了特征空间，为系统当前状态提供了宝贵的见解。然后，将识别的状态用作 LSTM 模型的输入，促进潜在故障的预测。LSTM 网络还在 Islam 和 Manivannan [110] 进行的一项关于从 Google 获取的工作负载跟踪数据集的广泛特征研究中得到应用。在这项研究中，重点是在作业和任务级别预测故障。一个作业包括多个任务，其中每个任务对应于单机命令或程序。通过利用资源使用情况、性能指标和任务细节来预测故障，包括完成状态以及与用户、节点和作业相关的属性。

表 12. 回顾的 AIOps 事件优先方法摘要。

采用一种全面的策略，HORA 预测系统 [204] 利用架构知识和实时 KPI 数据来预测分布式软件系统内潜在的服务质量（QoS）违规和服务中断。贝叶斯网络在这种方法中起着关键作用，用于构建描述组件相互依赖性和故障传播的模型。这些模型建立了通过系统指标的自回归预测器推导出的预期组件故障之间的联系，并揭示了更大规模的系统挑战。Lin 等人 [153] 提出了一种名为 MING 的方法，用于预测云服务系统内潜在的节点故障，该方法集成了 LSTM 和随机森林模型以结合时空数据。此外，该技术采用了排名模型和成本敏感函数来有效评估和排名节点的故障易感性。该方法在工业场景中取得了成功应用，特别是在 Microsoft 服务的背景下。eWarn [293] 是一种专为在线服务系统量身定制的方法，利用历史数据和实时警报信息来预测即将发生的事件的可能性。通过结合创新技术：有效的特征工程来表示相关警报模式，集成多实例学习以减轻无关警报的影响，并使用 LIME 解释技术生成可解释的预测报告。

事件优先方法

由于大量事件可能同时发生，处理所有事件可能会耗费大量时间和资源。然而，某些事件由于其重要性或严重性而需要立即关注。为解决这一问题，提出了各种基于数据驱动的方法来根据优先考虑因素对事件或警报进行排名。其中一些技术也可应用于其他场景，因为它们不仅仅专注于排名，还涉及检测或诊断机制。

表13. AIOps事件优先级排序方法的特殊性研究。

在他们的工作中，田等人[243]引入了DRONE框架，为优先处理错误报告提供建议。通过考虑多种因素，包括时间信息、文本内容、作者详细信息、相关报告、严重性和产品信息，实现了这一目标。这些因素从事件报告中提取为特征，随后用于训练一个擅长处理序数类标签和不平衡数据的判别模型。该模型采用线性回归来捕捉特征与优先级水平之间的关系，然后采用阈值方法来校准类标签（即优先级水平）。为了应对从异常检测系统中对各种分类警报进行特征化和排序的挑战，林等人[156]引入了协作警报排序（CAR）。CAR既处理挖掘警报模式，又减少误报。首先，构建了一个分层贝叶斯模型，以捕捉警报序列中的短期和长期依赖关系。然后设计了一个基于实体嵌入的模型，以揭示警报之间基于其分类属性的内容相关性。通过在统一的优化框架内集成时间和内容依赖关系，CAR为单个警报及其相关模式提供排名。同样，为了减轻威胁警报疲劳并优先处理真实攻击而不是误报，哈桑等人[102]引入了NODOZE。这一排序系统利用上下文和历史信息为警报事件构建因果依赖图。基于事件频率为边分配异常分数，并使用一种新颖的网络扩散算法进行传播。

AlertRank，由赵等人[295]提出，是一个用于识别严重警报的自动自适应框架。该方法利用各种可解释特征，包括文本和时间警报特征，以及基于领域知识的单变量和多变量KPI。采用XGBoost排序算法来识别严重警报，并利用连续标记来获取训练和测试的基本真实标签。陈等人[61]对来自真实在线服务系统的大规模事件进行了实证分析。他们的研究结果突出了一类被标记为“偶发事件”的事件，通常被认为不太重要，不会被立即优先解决。为了解决这一问题，作者提出了DeepIP（基于深度学习的事件优先级排序），它利用基于注意力的CNN来使用历史事件描述和拓扑信息识别和优先处理偶发事件。另外，古普塔等人[100]采用了一种独特的方法，将多标准模糊TOPSIS技术与细菌觅食优化算法（BFOA）和Bar系统（BAR）优化相结合。这种融合旨在对软件错误进行排名，并同时选择合适的开发人员。

事件分配方法

已提出了许多基于数据驱动的方法来优化事件分配（也称为路由或分类）的过程，通过自动将事件分配给适当的服务团队和个人。通常，这些方法涉及使用包含文本信息、拓扑数据或优先级评分的历史事件报告来训练分类器。然后使用训练过的分类器来分配新事件。

表14. AIOps事件分配方法综述。

前述工作主要依赖于文本预处理方法和传统机器学习和统计框架中的监督分类模型。例如，Murphy和Cubranic[186]采用贝叶斯学习方法处理事件报告，将其表示为预定义词汇表中的词袋，这方便地适应多类分类。然而，发现该方法在预测报告分配给开发人员方面的准确性有限，仅达到30%的正确预测。在[224]中，通过仅利用事件解决序列而不访问事件工单内容，采用了一种独特的视角。通过开发一个捕捉成功问题解决路径背后决策过程的马尔可夫模型来实现。模型的顺序是根据从工单数据中导出的条件熵精心选择的。为了解决有限标记的事件报告挑战，Xuan等人[278]提出了一种半监督文本分类技术。他们将朴素贝叶斯分类器与期望最大化相结合，利用标记和未标记的事件报告。一个迭代过程涉及使用标记的错误报告进行初始分类器训练，然后迭代标记未标记的错误报告以增强分类器训练。在分类器训练过程中，利用多个开发人员权重进一步细化推荐列表以提高性能。

Bhattacharya和Neamtiu[45]通过采用各种技术来处理任务，包括使用附加属性进行精细分类、训练过程中的内部折叠更新、用于在抛掷图中推荐开发人员的精确排名函数以及多特征抛掷图。结果不仅表现出显著的准确性，还展示了抛掷路径长度的显著减少。类似地，Alenezi等人[24]采用了一系列选择术语技术将软件错误分配给经验丰富的开发人员。该过程始于应用传统文本处理方法，将文本数据转换为连贯且有意义的表示。随后，制作了一个错误术语矩阵，包括术语频率权重。然后采用各种术语选择方法，有效地减少数据的维度和稀疏性问题。这些方法包括Log Odds Ratio、Term Frequency Relevance Frequency和Mutual Information等技术。随后，在生成的表示上训练了一个朴素贝叶斯分类器。王等人[254]引入了FixerCache，这是一种无监督方法，利用开发人员特定组件的活跃性来为每个产品组件创建动态开发人员缓存。当出现新的错误报告时，FixerCache会从开发人员缓存中推荐高活跃的修复者参与解决错误。每个错误报告的验证和解决后，开发人员缓存会动态更新。席等人[266]强调了在预测适合处理软件错误的服务团队或个人时抛掷序列路径的作用。他们的提议iTriage采用序列到序列模型，共同捕捉来自文本内容和抛掷序列的特征，通过编码器-解码器分类模型将它们整合在一起。

近年来，重点已转向结合先进的自然语言处理技术和复杂的深度学习方法。例如，李等人[132]首创使用卷积神经网络和预训练的Word2Vec嵌入来进行事件分配。DeepCT[60]提出了一种将事件分类视为涉及工程师之间密集讨论的连续过程的方法。它采用基于GRU的模型，配合基于注意力的掩码策略和修订的损失函数，从讨论中学习知识并逐步更新分类结果。DeepTriage[202]旨在解决事件分配挑战，如不平衡的事件分布、多样化的输入数据格式、可扩展性和建立工程师的信任。该方法采用CNN模型为每个事件推荐负责团队。着重于可解释性，Remil等人[212]提出了一个框架，其中包括使用预训练的转换器模型进行词形还原的预处理步骤。事件文本信息使用TF-IDF进行向量化，并输入到基于LSTM的注意力模型中，以预测适当的服务团队。此外，子群发现方法将预测的事件工单和标签分组为支持模型决策过程相同解释的子群。

事件分类方法

正如前文所述，事件分类的主要目标是增强事件的诊断，从而集中维护团队的努力。然而，这一类别在审查过程中经常被忽视，通常与去重、分类或优先级相关联。然而，存在一些研究工作完全符合这一类别，提供了将大量事件组织成代表性问题或主题集合的方法。

表16. AIOps事件分类方法综述。

杨等人[280]利用隐含狄利克雷分布（LDA）从故障报告中提取主题，并识别与每个主题相关的故障报告。他们的方法首先确定新故障报告的主题，然后利用多个特征（如组件、产品、优先级和严重性）来识别具有共享特征的报告作为新故障报告。另一个值得注意的贡献是由[151]提出的，他们提出了一种基于隐马尔可夫随机场（HMRF）的方法，用于自动识别大规模软件系统中的重复性性能问题。他们的方法将问题表述为基于HMRF的聚类问题，涉及学习度量离散化阈值和优化聚类过程。夏等人[268]引入了一种创新的故障分类框架，利用一种名为多特征主题模型（MTM）的专门主题建模算法。MTM通过将故障报告中的产品和组件信息纳入LDA中，有效地将术语空间映射到主题空间。此外，他们还引入了一种名为TopicMiner的增量学习方法，该方法利用新故障报告的主题分布来分配适当的修复者，基于他们与主题的关联性。

在另一个背景下，曾等人[284]开发了一种方法来从工单描述中识别IT问题的潜在类别。为实现这一目标，他们采用了一种用于对监控工单进行分类的分层多标签分类技术，引入了一种新颖的上下文层次结构。他们采用了一种名为GLabel的新贪婪算法来解决优化挑战。

表18. AIOps故障事件去重方法综述。

表19. AIOps故障事件分配方法的特殊性研究。

该方法还利用领域专家知识以及工单实例来指导分层多标签分类过程。在解决警报风暴问题时，赵等人[292]提出了一个两阶段方法：警报风暴检测和警报风暴摘要。在警报风暴摘要阶段，一种警报去噪方法通过从系统的正常状态中学习模式来过滤掉不相关的警报。随后，基于文本和拓扑相似性对指示服务故障的警报进行聚类。从每个聚类中选择最具代表性的警报，从而形成一个简明的警报集以供进一步调查。

故障事件去重方法

故障事件去重旨在识别一组历史事件中最相似的事件，这些事件存在细微差异，但主要涉及相同问题。这项工作可以分为两个主要类别。第一类研究集中在基于描述和特征识别重复事件报告的技术上。

在[107]中，首次尝试使用文本信息识别重复的故障报告。他们的方法涉及构建一个模型，将相似报告（表示为TF-IDF的文档向量）聚类到代表性质心中。当提交新的故障报告时，该方法计算与每个质心的余弦相似度，寻找高相似度的实例以识别潜在重复项。Runeson等人[218]采用了类似的方法，通过考虑额外的文本特征，如软件版本、测试人员和提交日期，加以改进。还包括了有效的预处理步骤，如词干提取和停用词去除。Sureka和Jalote[239]提出了一种独特的基于N-gram的模型，与先前基于单词的方法有所不同。该研究探讨了低级字符特征的实用性，提供了诸如对抗嘈杂数据和有效处理领域特定术语变化等好处。Sun等人[236]引入了一种检索函数（REP），包括总结和描述字段的文本内容相似性以及非文本属性（如产品、组件和版本）的相似性。该论文扩展了信息检索中常用的BM25F相似度度量。

鉴于基于单词的方法的局限性，可能会将讨论不同问题的报告因共享常见词而误认为重复，Banerjee等人[36]引入了FactorLCS方法，该方法在计算故障报告之间的文本相似性时采用了常见序列匹配。Zhou和Zhang[299]引入了BugSim，利用学习排序概念，结合文本和统计特征。基于这些特征建立了故障报告的相似性函数。该模型使用一组重复和非重复报告对模型进行训练，并利用随机梯度下降算法调整特征权重。使用这个训练过的模型检索新故障报告的候选重复报告。

最近，深度学习技术备受关注。谢等人[271]引入了DBR-CNN，利用CNN模型和词嵌入技术评估故障事件报告对之间的语义相似性。这种方法不同于先前主要依赖常见词或词序列进行词汇相似性计算的方法。同样，何等人[103]在引入CNN的同时，引入了一种名为双通道矩阵的独特故障报告对表示。这个矩阵是通过连接两个单通道矩阵形成的，每个矩阵代表一个故障报告。然后将这些对输入到名为DC-CNN的CNN模型中，旨在捕捉相互关联的语义关系。在Messaoud等人[176]中，提出了BERT-MLP。该方法利用预训练语言模型BERT处理非结构化的故障报告数据，并捕捉上下文关系。然后将BERT模型的输出输入到多层感知器分类器中，以预测重复的故障报告。

第二类主要依赖设计能够反映执行报告之间语义崩溃相似性的相似度度量，特别是针对堆栈跟踪的情况，我们简要讨论如下。Lerch和Mezini[135]采用了Lucene库[16]中基于TF-IDF的评分函数。Sabor等人[219]提出了DURFEX系统，该系统使用子例程的包名称，然后将生成的堆栈跟踪分成N-gram，通过余弦相似性进行比较。一些替代技术建议使用Needleman-Wunsch算法的导数计算相似性[192]。在[50]中，作者建议根据匹配子例程的频率和位置调整相似性。Dang等人[74]在他们的框架Rebucket中提出了一种称为PDM的新相似度度量，该度量基于匹配帧之间的偏移距离和距离顶部帧的距离进行计算。最近，提出了TraceSim[248]，该方法考虑了帧位置及其全局逆频率。Moroo等人[183]提出了一种方法，将TF-IDF系数与PDM相结合。最后，我们概述了一些早期使用编辑距离的方法，因为它等同于最佳全局对齐。

根本原因分析方法

根本原因分析方法旨在确定导致软件错误、故障、异常或硬件故障的潜在故障。更具体地说，根本原因分析是在报告事件时需要进行的诊断任务，无论是在故障处理过程之后还是与之并行进行。在复杂系统中，首先需要将分析隔离并限制在故障组件或功能上，这个过程在许多研究社区中被称为故障定位。具体来说，故障定位涉及识别一组组件（设备、主机、软件模块等），这些组件在系统内部首次触发错误。值得注意的是，故障定位可以在不同层面进行操作，包括技术、应用、功能和业务层面。简单来说，我们可以区分两种故障定位。第一种是技术和应用故障定位或故障排除，涵盖网络、硬件和应用层（例如云环境中的故障组件）（例如云环境中的故障组件）。第二种是软件故障定位，围绕功能和业务层展开，主要解决导致故障的缺陷。在软件故障定位的背景下，中心焦点在于分析源代码，无论软件是部署在多台机器上还是在更有限的一组机器上。

表20. AIOps根本原因分析方法综述。

表21. AIOps根本原因分析方法的特殊性研究。技术和应用故障排除。 由 Bahl 等人进行的研究 [35] 提出了 Sherlock 方法，专注于定位企业网络中的性能问题。这是通过基于网络基础设施中的数据包交换观察构建概率推理图来实现的。这些图包括三种节点类型：根本原因节点（代表内部 IP 实体）、观察节点（代表客户端）和捕获这些类型之间依赖关系的元节点。每个节点都与表示其状态（正常、有问题、宕机）的分类随机变量相关联。状态受其他节点通过概率依赖关系的影响。推理图的学习过程涉及在正常网络运行期间监视节点之间的数据包交换。一旦建立，该图使得可以利用观察节点的数据推导出反映预期网络运行状态的状态-节点分配向量集。X-Ray [31] 解决了通过提供关于性能异常期间特定事件背后原因的见解来解决性能问题排查的挑战。其关键贡献是通过在应用程序执行时对二进制文件进行仪器化来实现的性能总结技术。该技术将性能成本归因于每个基本块，并利用动态信息流跟踪来估计由于每个潜在根本原因而执行每个块的可能性。然后，通过将每个潜在根本原因的每个基本块成本乘以特定原因的可能性在所有基本块上进行汇总来总结每个潜在根本原因的总成本。这种技术还可以差异化应用以解释两个类似活动之间的性能差异。

FChain [194] 是一种用于识别在线云环境中故障组件的故障定位系统。它作为黑盒解决方案运行，利用低级系统指标来检测性能异常。异常根据表现时间进行排序，并使用离散马尔可夫模型依次检查这些组件。采用分析组件之间的相互依赖关系和研究传播趋势等技术来过滤虚假相关性。类似地，CauseInfer [62] 是一种黑盒原因推断系统，它构建了一个两层分层因果关系图，以帮助识别性能问题的根本原因。该系统采用统计方法，包括一种新颖的贝叶斯变点检测方法，来推断图中存在的因果路径上的潜在原因。

Lin 等人 [155] 提出了 LogCluster，其中使用知识库加快与经常性问题相关的日志的检索，从而简化问题识别过程。该方法将日志视为由离散日志事件组成的序列，然后通过应用逆文档频率（IDF）将这些单独事件视为术语进行初始转换为向量格式。随后，采用凝聚层次聚类技术对这些日志进行分组，从而选择每个群集的代表性实例。在系统的运行阶段，查询被定向到这个压缩的代表集，显著减轻了基于相似性进行日志检索所需的工作量。

Lin 等人 [154] 提出了 iDice，一种基于频繁模式挖掘和时间序列数据内变化检测的模式挖掘方法。该方法被应用于识别拓扑数据中与新问题相关的有效属性组合。在一段时间内给定的客户问题报告数量，目标是识别将多维时间序列数据集划分为两个分区的属性组合：一个分区中问题数量显著增加，另一个分区没有这种增加。类似地，Sun 等人 [238] 推出了 HotSpot，它利用蒙特卡洛树搜索（MCTS）高效探索属性组合并衡量它们与页面浏览指标突然变化的相关性。该方法提出了一个基于涟漪效应的潜在分数，量化异常是如何通过不同属性组合传播的。采用分层修剪策略来缩小搜索空间，重点关注具有最高潜力成为根本原因的属性组合。另一种类似方法，Li 等人的 Squeeze [147]，应用了一种结构化日志的模式挖掘方法，用于识别导致异常行为的属性组合。Squeeze 利用自下而上，然后自上而下的搜索策略，通过首先识别可能相关的属性，然后确定根本原因来高效地探索多维搜索空间。

由 [221] 进行的另一项工作采用了分层隐马尔可夫模型（HHMM）来将资源异常与集群资源环境中的根本原因关联起来。马尔可夫模型在不同层次上构建，并使用 Baum-Welch 算法以响应时间序列作为观察进行训练。Jeyakumar 等人 [115] 推出了 ExplainIt，这是一种用于复杂系统（如数据中心）中无监督根本原因分析的方法，利用 KPIs 数据。该系统使操作员能够系统地提出排名靠前的因果假设，以识别重大事件背后的根本原因。使用类似 SQL 的声明性语言，ExplainIt 促进生成假设，探究系统中的复杂概率图因果模型。Ma 等人 [167] 提出的 iSQUAD 框架解决了云数据库中间歇性慢查询（iSQs）的检测和诊断问题。这些查询由外部间歇性性能问题引起，可能对用户造成重大风险。与典型的慢查询不同，iSQs 不太可预测，并且提出更复杂的诊断挑战。iSQUAD 利用基于机器学习的方法，利用异常提取、依赖清理、类型导向模式集成聚类（TOPIC）和贝叶斯案例模型组件。在他们的工作中，Remil 等人 [210] 关注于用于识别架构问题并自动定位具有特定属性共享的查询子集的 SQL 工作负载分析。这些措施涵盖了执行时间慢、并发问题、高 I/O 通信等。该方法涉及解析查询以提取关键属性（如表、字段和谓词），并利用相关信息（如性能指标、环境特征和异常警报）来增强查询。利用称为子群发现的模式挖掘方法，作者揭示了在由这些属性条件的连接形成的模式中表现异常的查询子集。此外，集成了可视化工具允许从获得的结果中进行迭代和交互式学习。

Li 等人 [148] 提出的方法介绍了 DejaVu，一种可解释的方法，旨在定位在线服务系统中的重复故障。这些重复故障表现为同一类型在不同位置重复出现的实例。工程师可以为每种故障类型识别指示性指标，有助于识别潜在问题并根据领域专业知识指导减轻行动。这些指示性指标集有助于识别与经常性问题相关的候选故障单元。为了捕获复杂的系统依赖关系，建立了一个故障依赖图（FDG），将故障单元与相互依赖关系联系起来。当发生故障时，监控系统会触发 DejaVu，DejaVu 在历史故障上进行训练。然后，DejaVu 利用最新的 FDG 和指标数据从候选故障单元集中推荐可疑故障单元，简化故障定位过程。Li 等人 [139] 提出了基于因果推断的根本原因分析（CIRCA），它将根本原因分析挑战框定为新颖因果推断任务中的干预识别。核心原则围绕着监控变量作为根本原因指示器的充分条件。这涉及到在因果贝叶斯网络（CBN）中对父节点条件的概率分布变化。专门针对在线服务系统，CIRCA 根据系统架构知识和一组因果假设构建了一个监控指标图。软件故障定位。 传统的软件故障定位策略通常会产生一系列可能与错误相关联的语句或源代码块。与SDP策略不同，这种方法依赖于在生产运行和单元测试期间观察到的故障模式，而不是关于代码组件转变为错误状态的概率的预测。已经开发了许多方法来解决软件故障定位问题。一个突出的类别是基于程序频谱的技术，它依赖于从执行跟踪中获取的程序执行概况之间的相似性。这些概况代表程序的成功运行和故障运行。例如，Renieres和Reiss [215] 使用最近邻搜索来比较失败的测试和类似成功的测试，使用汉明距离作为相似性的度量。另一种著名的技术是Tarantula [117]，利用覆盖率和执行结果来计算每个语句的可疑分数。这个分数基于覆盖该语句的失败和成功测试用例的数量，以及总的成功和失败测试用例的数量。该领域的后续研究提出了对可疑性评分的改进，也被称为排名度量，如Ochiai [21]，Crosstab [260] 和DStar [259]。Xuan和Monperrus [279] 通过结合多个现有度量提出了找到最佳排名度量以用于故障识别的挑战。这种名为MULTRIC的方法涉及学习和排名的两阶段过程：它从有故障和无故障的代码元素中学习以构建排名模型，然后将该模型应用于计算程序实体的可疑分数，当新的故障出现时。还探索了统计调试方法。Liu等人 [157] 提出了一种名为SOBER的统计调试方法，该方法分析失败和通过运行中的谓词评估。通过估计观察到特定谓词的失败的条件概率，该方法识别具有更高概率的谓词，表明它们可能涉及软件错误或与之接近。Abreu等人 [22] 后来提出了一种名为BARINEL的贝叶斯推理方法，该方法结合了用于估计组件健康概率的概率框架。这个基于命题逻辑的模型捕捉了成功和失败组件之间的交互。此外，数据挖掘技术由于能够揭示大数据样本中的隐藏模式而显示出故障定位的潜力。

Denmat等人 [81] 提出了一种重新解释Tarantula为数据挖掘挑战的方法。

在这种方法中，使用覆盖信息和测试套件执行结果提取表示个别语句与程序故障之间连接的关联规则。通过两个著名的经典数据挖掘指标，即置信度和提升度来评估这些规则的重要性。这些值可以被理解为语句可能具有可疑性的指标，暗示着错误的存在。Cellier等人 [55] 讨论了一种依赖于关联规则和形式概念分析（FCA）的数据挖掘方法，作为辅助故障定位的手段。该技术旨在识别将语句覆盖与相应执行失败相关联的规则，测量每个规则的频率。设定一个阈值来确定所选规则覆盖的失败执行的最小数量。生成的规则然后通过规则格局部分排名，并检查排名以定位故障。在[289]中，作者提出了一种利用多关系数据挖掘技术进行故障定位的方法。具体来说，该技术利用马尔可夫逻辑，将一阶逻辑和马尔可夫随机场与加权可满足性测试相结合，用于高效推理，同时使用投票感知器算法进行判别学习。当应用于故障定位时，马尔可夫逻辑整合了各种信息源，包括语句覆盖、静态程序结构细节和先前的错误知识，以增强故障定位工作的准确性。

AIOps事故相关方法综述表。

最近，人们开始倾向于采用机器学习和深度学习方法来解决软件故障定位问题。例如，Sohn和Yoo [229] 扩展了基于频谱的故障定位方法，使用代码和变更指标，以增强故障定位精度。他们应用遗传编程（GP）和线性排名支持向量机进行学习排名，利用可疑性值和额外指标。Li等人 [141] 提出了DeepFL，一种专为基于学习的故障定位设计的深度学习方法。它通过自动识别有效的现有和潜在特征，解决了先进故障定位技术中特征维度增加的挑战。DeepFL使用从故障定位、缺陷预测和信息检索领域收集的基于可疑性值、基于故障倾向性和基于文本相似性的特征进行演示。DeepRL4FL [144] 是另一种将故障定位视为图像模式识别问题的深度学习方法。它通过引入代码覆盖表示学习和程序语句的数据依赖关系表示学习，定位语句和方法级别的错误代码。代码覆盖矩阵中的这些动态信息类型与可疑源代码的静态代码表示学习相结合。受犯罪现场调查启发，该方法模拟分析犯罪现场（失败的测试用例和语句）、相关个体（具有依赖性的语句）和常犯罪嫌疑人（相似的错误代码）。DeepRL4FL组织测试用例，标记出现错误的语句，并利用数据依赖性进行全面的故障识别。采用卷积神经网络分类器，利用来自多个来源的融合向量表示有效地检测错误语句/方法。

AIOps事故相关方法特殊性研究表。

AIOps事故缓解方法综述表。

事故相关方法

事故相关研究通常集中在分析警报信号之间的相关性，发生的事故，或警报信号与事故之间的关联。现有的相关算法主要评估原始关键性能指标，或将这些KPI转换为事件，然后分析它们之间的相关性。

Luo等人 [163] 关注将事件与KPI数据相关联。他们将相关问题形式化为一个双样本问题，以评估在线服务系统中KPI时间序列和事件序列之间的相关性。他们采用最近邻方法来评估相关性的存在，并分析时间关系和单调效应。CoFlux [234] 是一种用于在互联网服务运营管理中相关KPI的无监督方法。它引入了KPI流量相关性的概念，通过波动识别KPI之间的相互作用，特别是在异常情况下。该研究强调了在具有各种结构特征的KPI中准确区分波动和正常变化的挑战。所提出的方法自动确定两个KPI之间的流量相关性，包括波动的时间顺序和方向，无需手动算法选择或通过强大的特征工程和交叉相关性进行参数调整。

Tan等人 [240] 提出了一种用于攻击检测的多变量相关分析系统，通过提取网络流量特征之间的几何相关性。他们的解决方案利用马氏距离来衡量流量记录之间的相似性。Bateni和Baraani [40] 提出了一种基于滑动时间窗口分析的增强随机定向时间窗口（ERDTW）警报选择策略。ERDTW根据数学逻辑规则描述的属性将时间间隔分类为相关（安全）和不相关（危险）。例如，如果一个时间间隔包含许多具有相同IP地址的警报，那么更有可能被标记为危险。

事故缓解方法

通过事故管理的分类和诊断步骤，可以获得宝贵的知识，包括确定事故范围、检索历史重复项和分析根本原因。这些知识使得可以启动自动修复操作，称为缓解或补救操作。与报告和诊断任务相比，事故缓解受到的关注较少，因为它通常是这些过程结果的后果。一旦通过诊断澄清了潜在问题，恢复步骤就变得容易识别和实现，无需复杂的模型。然而，我们致力于提供一系列专注于解决任务的研究作品，即使涉及分类或诊断。

AIOps事故缓解方法特殊性研究表。

在一项由[300]进行的研究中，提出了基于相似性的算法，用于根据事件工单建议解决方案。该方法使用k-NN方法检索工单解决方案的k个建议。通过使用数值、分类和文本数据的组合评估工单之间的相似性，定义了个体和聚合相似性度量。该解决方案进一步扩展以解决历史数据和新数据中的误报工单。这是通过使用二元分类器对工单进行分类，并根据预测结果对工单重要性进行加权来实现的。最终的解决方案建议考虑了重要性和相似性。该论文还探讨了改进特征提取的想法，如主题发现和度量学习。Wang等人[252]提出了一个基于本体论的认知框架，用于构建领域特定知识并为IT服务管理工单建议恢复操作。该方法涉及分析工单摘要和解决方案描述中的自由文本。使用语言处理技术提取领域特定短语，并开发本体模型来定义关键词、类别、关系和层次结构。然后利用该模型通过匹配从新数据和历史数据中提取的概念模式来推荐解决方案操作，使用Jaccard距离等相似性函数。Lin等人[152]采用自然语言处理技术，根据关闭的事件工单预测硬件故障的修复操作。通过分析原始文本日志，最多推荐五种修复操作。Ding等人[84]提出了一种基于自动化挖掘的方法，用于建议适当的治疗操作。该方法涉及使用事务日志生成问题的签名，根据这些签名检索历史问题，并通过调整用于类似过去问题的操作来建议合适的治疗操作。

用于AIOps方法的公开可用数据集和基准

在本节中，我们全面概述了与AIOps领域相关的关键公开可用数据集和基准，特别是在各种应用领域的事件管理流程中。表26作为一个宝贵的资源，不仅列出了先前研究方法中使用的数据集，还突出了先前研究中尚未开发的其他数据集，但对于各自的研究应用领域具有重要意义。我们按事件任务或应用领域组织这些数据集，指定它们的数据来源，将它们与它们所使用的方法进行交叉引用，并且提供访问数据集的直接链接以及详细描述。值得注意的是，为事件分类设计的数据集也可以用于事件优先级确定以及分配、分类和去重等子类别。

表26. 用于AIOps方法的公开可用数据集和基准。

我们认识到这些信息的重要性，无论是对于初入AIOps领域的新手，还是对于寻求复制现有研究结果、在同一研究领域内进行类似技术的比较以及评估自己贡献的从业者。虽然一些先前的调查提供了针对特定领域量身定制的数据集列表，但据我们所知，我们的贡献是首次全面汇编跨多个应用领域的数据集。

图14. 在事件任务及其子类别中分析的AIOps论文分布。

结论和未来挑战

正如在介绍中所述，近年来AIOps领域在研究和工业领域都引起了显著的兴趣。然而，必须承认，这一领域仍然缺乏集中和结构化的框架。这源于需要结合涵盖软件工程、机器学习、大数据分析、优化等多样化专业学科的需求。AIOps以其新颖性和跨学科性质而闻名，尚未建立作为一个清晰定义的研究领域的独特和连贯身份。这给从业者和研究人员充分理解现有技术水平、确定潜在限制和空白提出了重大挑战。对于数据管理、问题定位、重点领域、实施细节、需求和能力等方面缺乏标准术语和约定进一步加剧了这种情况。这种缺乏不仅导致缺乏有效AIOps解决方案的技术指南和一致的实施路线图，还使新研究人员难以发现和比较来自各个学科解决相同问题的贡献。因此，本调查作为AIOps领域的入门资源，专门针对事件管理流程。我们的主要目标是为AIOps建立一个基础知识库，这对于希望过渡到AIOps基础设施的行业和未来的研究工作都有益处。除了呈现基础知识外，还包括在智能和有效的事件管理中所需的基本构建模块，同时解决痛点和期望结果，我们还对旨在处理定义的事件管理过程中的各种任务的现有方法进行了全面探讨。

在图14中，我们分析了本调查中审查的AIOps论文在事件任务及其子类别中的分布。显然，某些研究类别比其他类别受到更多关注，导致每个阶段的贡献不平衡。这种差异可以归因于几个因素。例如，事件预测和检测阶段共同占据了本调查中分析的论文的一半以上，这些论文来自知名会议和期刊。相比之下，事件分类、关联和缓解等类别受到的关注相对较少。这种不平衡与AIOps框架的基本要求逻辑一致，其中检测、预测和根本原因分析至关重要。此外，正如前面讨论的，某些类别可能不那么重要。例如，如果可以通过参考过去的重复事件有效地识别根本原因，则可能不需要自动化缓解技术。同样，根据特定用例，某些类别可能变得不那么重要。例如，如果事件已经路由到一个没有竞争性优先级的合格个人，那么排名过程可能变得不那么重要。然而，鼓励采用各种技术和最新算法的多样化贡献仍然是有益的，以确保在需要时可以准确快速地执行任务。

针对每个事件任务，我们观察到吸引了相当多研究关注的特定方面。这包括在相关研究中识别出的普遍背景、为这些背景广泛使用的数据，以及最常用的模型类型和学习范式等因素。例如，在检测事件方法时，主要关注于解决技术方面，包括硬件和网络层，以及应用层。通常通过分析关键绩效指标（KPI）、系统指标、网络流量数据和事件日志来实现。主导模型往往是无监督的，重点放在统计模型、降维方法和像循环神经网络（RNN）这样的通用自编码器上。在事件预测任务中，研究工作还解决了发生在功能层的故障。这些方法中许多是受监督的，并利用过去故障或停机的模式。它们经常使用预测方法，特别是对于时间序列数据，特别是在软件老化和估计剩余有用寿命等情况下。

当涉及事件优先级确定时，拓扑和警报信号数据发挥着重要作用，通常使用监督技术。相比之下，事件报告是与分配和去重等任务相关的主要信息来源。然而，对于这两个任务，大多数方法主要集中在解决与软件相关的问题，特别是软件错误。在根本原因分析方法方面，可解释性是一个关键考虑因素。对于软件故障定位，主要涉及通过监督方法分析源代码。另一方面，技术故障定位方法往往是无监督的，并借鉴模式挖掘中的描述性模型，通常结合拓扑数据来对故障进行情境化。

除了本调查中解决的重大挑战之外，我们还确定了其他几个需要关注的问题、痛点和未来挑战，包括与AIOps模型的设计、独特特征、可用性和可重现性相关的方面。首先，我们的初始观察突显出，尽管预测模型面临着诸多挑战，包括缺乏明确的基准标签、需要手动获取高质量数据、极度不平衡的数据集，以及组件和服务之间复杂的依赖关系和关联，AIOps 仍然着重于发展预测模型，特别是用于事件检测和预测。然而，存在一种鲜为人知但极具价值的方法却被低估了。这种方法涉及采用描述性模型，比如一般的模式挖掘，特别是像监督规则发现和形式概念分析这样的技术。这些模型利用数据挖掘的力量从数据中提取信息模式，这些模式在检测、诊断和解决问题方面至关重要。描述性模型在处理与数据多样性、复杂性和质量相关的挑战时具有明显的优势。这使得它们在涉及事件去重和处理复杂依赖关系等任务的场景中尤为宝贵。因此，我们迫切需要将注意力转向增强描述性模型，同时认识到它们为 AIOps 领域带来的独特优势。

此外，强调演进这些模型的评估方法的重要性至关重要。尽管本调查中所研究的大部分研究集中在列联表指标上，但只有少数考虑了第4.2节和第3.4节中概述的上下文和时间方面。例如，挑战也在于确保模型在训练阶段的行为与其在测试和生产阶段的性能一致。用于评估模型的传统指标容易受到污染区域现象的影响，这可能导致错误的评估。事实上，Fourure 等人指出，通过参数化训练集和测试集之间的数据比例，异常检测模型的 F1 分数可以被人为地增加。

在解决可解释性问题时，许多研究利用黑盒模型执行任务时都承认将解释层纳入其方法的重要性。他们声称，他们模型的输出附带有关其预测背后原因的解释。然而，在这方面仍存在一些关键问题。目前尚不清楚这些解释在模型遇到新数据时如何保持内部一致，或者在不同模型产生相同结果但解释不同的情况下如何进行外部比较。此外，模型解释随时间的稳定性，特别是在更新和改进时，引发了重要问题。此外，在这个过程中只有有限数量的方法涉及人类专业知识。事实上，从业者的见解可以极大地指导这些模型的学习和实施。有趣的是，在模式挖掘方法的背景下，一些技术，比如主观趣味性，可以促进用户随时间更新对最有趣数据的知识。可伸缩性是另一个主要关注点。在 AIOps 环境中，不仅需要关注模型的效率，还需要关注其整体性能。虽然优化（TTx）时间（包括检测、参与和缓解）至关重要，但这方面受到的关注相对较少，对于成功实施自动化事件管理程序至关重要，但在比较解决同一研究领域的不同模型时，性能评估经常被忽视。在实际场景中，一个执行时间较短但在检测方面保持 90% F-Score 的模型可能会优于执行时间较长但 F-Score 达到 95% 的模型。这强调了在现实世界的 AIOps 应用中需要在模型性能和效率之间取得平衡的必要性。

最后，要显著推进这一领域，迫切需要倡导学术界和工业界之间更紧密的合作伙伴关系。此外，应鼓励开源倡议。虽然可以理解发布数据集可能会引起潜在的权利或保密问题，并且分享在生产场景中使用的模型可能容易受到逆向工程的影响，但在研究社区中找到共同点尤为重要。促进某些结果的可重现性可以成为推动该领域研究的重要推动因素。学术界和工业界共同努力，并为开源倡议做出贡献，可以为更健壮和有影响力的 AIOps 解决方案的发展铺平道路。