CN115989483A - 用于大型动态过程执行系统的自动根本原因分析与预测 - Google Patents

Abstract

自动根本原因分析(RCA)系统可以提供全自动平台，该全自动平台为包括在容量配置过程中的任务、异常检测、票据关联、根本原因分析、监控和反馈以及数据可视化提供依赖性和执行顺序建模。自动RCA系统可以连续地收集和存储数据，以用于确定容量配置过程中阻塞的根本原因。可以在云计算系统生成的票据中标识阻塞。自动RCA系统可以接收票据并尝试基于与云计算系统生成的先前票据相关联的根本原因来确定阻塞的根本原因。自动RCA系统可以标识真正的根本原因，基于该真正的根本原因来推荐修复项目，标识一个或多个负责小组来推动修理，并提供估计的完成时间。

Description

用于大型动态过程执行系统的自动根本原因分析与预测

背景技术

云计算系统可以指能够被远程访问的计算设备或资源的集合。换言之，云计算可以被描述为通过互联网提供计算服务(诸如存储、数据库、网络、软件、应用、处理或分析)。客户端可以通过客户端设备访问云计算系统。云计算系统可以包括向客户端提供服务的资源。这些资源可以包括处理器、存储器、存储装置和网络硬件。

云计算系统可以包括可以位于不同地理位置的多个数据中心。每个数据中心可以包括许多服务器。服务器可以是物理计算机系统。云计算系统可以在服务器上运行虚拟机。虚拟机可以是模拟不同计算机系统的程序，但可以与其他虚拟机一起在服务器上运行。与物理计算机一样，虚拟机可以包括操作系统和应用。

云计算系统可以使虚拟机可供客户及时地托管和执行其工作负载。随着客户需求的发展和增长，云计算系统可能需要构建新的数据中心或修改现有的数据中心，以满足容量需求。增加云计算系统的容量可以被称为容量配置。容量配置可以通过需要执行一组任务的自动配置过程来完成，其中一些任务依赖于其他任务和其他云计算系统子系统。部分由于这些依赖性，单个任务可能无法及时完成。当任务被阻止时，云计算系统可以创建票据，以提醒阻塞的操作。然而，票据可能无法标识阻塞的原因。可以需要许多工时来调查和确定根本原因、标识修复并将修复分配给(多个)正确的小组。

发明内容

根据本公开的一方面，公开了一种用于自动确定与云计算系统中的容量配置过程相关联的失败的根本原因的系统。该系统包括一个或多个处理器、与一个或多个处理器电子通信的存储器和数据存储。数据存储包括历史票据和与历史票据中的一个或多个历史票据相关联的根本原因记录。该系统还包括存储在存储器中的指令。指令由该一个或多个处理器可执行以接收由与容量配置过程相关联的任务发出的事件。事件描述任务的状态。指令还由该一个或多个处理器可执行以从一个或多个外部系统接收健康状况信号。健康状况信号指示一个或多个外部系统是否可操作。指令还由该一个或多个处理器可执行以接收票据。票据标识与容量配置过程相关联的失败。指令还由一个或多个处理器可执行以基于事件、健康状况信号、历史票据和根本原因记录来确定失败的根本原因。确定失败的根本原因包括相对于历史票据，对票据进行模式匹配。指令还由一个或多个处理器可执行以将失败的根本原因与票据相关联，以及将失败的根本原因提供给操作。

基于事件、健康状况信号、历史票据和根本原因记录来确定失败的根本原因的指令可以包括如下指令，该指令由一个或多个处理器可执行以标识历史票据之中的匹配票据。匹配票据具有与票据的一个或多个相似度。指令还可以由一个或多个处理器可执行以标识与匹配票据相关联的根本原因记录。与匹配票据相关联的根本原因记录可以标识匹配票据的根本原因。指令还可以由一个或多个处理器可执行以部分地基于与匹配票据相关联的根本原因记录来确定失败的根本原因。

指令还可以由一个或多个处理器可执行以标识历史票据之中的附加匹配票据。附加匹配票据可以具有与票据的一个或多个相似度。指令还可以由一个或多个处理器可执行以标识与附加匹配票据相关联的一个或多个根本原因记录。与附加匹配票据相关联的一个或多个根本原因记录可以标识针对附加匹配票据的根本原因。指令还可以由一个或多个处理器可执行以基于时间和空间相关性来修剪一个或多个根本原因记录。

标识历史票据之中的匹配票据的指令可以包括如下指令，该指令由一个或多个处理器可执行以使用机器学习引擎来标识历史票据之中的匹配票据。

指令还可以由一个或多个处理器可执行以基于与匹配票据相关联的根本原因记录来确定针对失败的修复，针对修复标识一个或多个修复小组，以及将失败的根本原因和修复提供给一个或多个修复小组。

指令还可以由一个或多个处理器可执行以与和云计算系统相关联的其他修复相比，使该修复优先。

指令还可以由一个或多个处理器可执行以确定根本原因记录不包含失败的根本原因，基于事件或健康状况信号生成失败的根本原因，以及将失败的根本原因存储在数据存储中。

指令还可以由一个或多个处理器可执行以收集与历史票据中的一个或多个历史票据相关联的标签。标签可以包括关于历史票据的根本原因的信息并且标签可以根据定义的模式被输入。生成失败的根本原因可以部分地基于标签。

由与云计算系统的容量配置过程相关联的任务发出的事件以及来自一个或多个外部系统的健康状况信号可以根据数据契约被接收。

指令还可以由一个或多个处理器可执行以将事件存储在数据存储上，以及将健康状况信号存储在数据存储上。

指令还可以由一个或多个处理器可执行以在呈现系统上显示针对容量配置过程的执行图，以及在呈现系统上显示失败的根本原因。

指令还可以由一个或多个处理器可执行以响应于接收到健康状况信号，针对元数据查询外部系统，以及将元数据存储在数据存储上。

根据本公开的另一方面，公开了一种由计算设备执行的用于自动确定与容量配置过程相关联的失败的根本原因的方法。容量配置过程用于云计算系统。该方法包括接收票据。票据指示失败。该方法还包括标识失败的零个或更多个潜在根本原因。零个或更多个潜在根本原因在与一个或多个历史票据相关联的根本原因记录中被描述。该方法还包括将分数分配给失败的零个或更多个潜在根本原因。该方法还包括基于分数确定零个或更多个潜在根本原因是否包括根本原因。该方法还包括，如果零个或更多个潜在根本原因不包括失败的根本原因，则确定失败的根本原因是否能够在没有人为干预的情况下被生成。该方法还包括基于与一个或多个历史票据相关联的根本原因记录来确定针对失败的修复是否已知。该方法还包括如果根本原因或修复未知，寻求人为干预。该方法还包括如果根本原因已知，将根本原因附接到票据。该方法还包括，如果修复已知，标识一个或多个修复小组来完成修复。

该方法还可以包括基于从与容量配置过程相关联的任务接收的事件、从支持云计算系统的外部系统接收的健康状况信号以及与历史票据相关联的标签来生成失败的根本原因。

一个或多个历史票据可以被包括在一组历史票据中。标识针对失败的零个或更多个潜在根本原因可以包括基于比较票据与一组历史票据来标识一个或多历史票据，并且标识与一个或多个历史票据相关联的根本原因记录。

基于比较票据与一组历史票据来标识一个或多个历史票据可以包括基于执行票据与该组历史票据之间的相似度分析来标识一个或多个历史票据。

基于比较票据与一组历史票据来标识一个或多个历史票据可以包括使用机器学习引擎从该组历史票据之中标识一个或者多个历史票据。

分配给针对失败的零个或更多个潜在根本原因的分数可以基于从与容量配置过程相关联的任务接收的事件、从支持云计算系统的外部系统接收的健康状况信号以及与历史票据相关联的标签。分配给针对失败的零个或更多个潜在根本原因的分数可以基于响应于一个或多个查询而从外部系统接收的元数据。

根据本公开的另一方面，计算机可读介质包括指令。指令由一个或多个处理器可执行，以使计算系统接收由与用于云计算系统的容量配置过程相关联的任务发出的事件。事件描述任务的状态。指令还由一个或多个处理器可执行以使计算系统从一个或多个外部系统接收健康状况信号。健康状况信号可以指示一个或多个外部系统是否可操作。指令还由一个或多个处理器可执行以使计算系统接收票据。票据可以标识与容量配置过程相关联的失败。指令还由一个或多个处理器可执行以使计算系统访问存储云计算系统的历史票据的数据存储。历史票据中的一个或多个历史票据具有相关联的根本原因记录。这些指令还由一个或多个处理器可执行以使计算系统基于事件、健康状况信号、历史票据和相关联的根本原因记录来确定失败的根本原因。确定失败的根本原因可以包括对票据与历史票据执行模式匹配。确定失败的根本原因可以包括针对与健康状况信号相关的元数据查询外部系统(诸如通过使用图3中的元数据收集模块354)。指令还由一个或多个处理器可执行以使计算系统基于相关联的根本原因记录来确定针对失败的必要修复，以及确定用于完成必要修复的估计时间。

计算机可读介质还可以包括由一个或多个处理器可执行以使计算系统执行必要的修复的指令。

提供本发明内容是为了以简化形式介绍概念的选择，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在标识所要求保护的主题的关键特征或基本特征，也不旨在用作确定所要求保护主题的范围的帮助。

附加特征和优点将在下面的描述中阐述。本公开的特征和优点可以通过所附权利要求中特别指出的系统和方法来实现和获得。通过以下描述和所附权利要求，本公开的特征将变得更充分明显，或者可以通过下文所述的公开主题的实践来了解。

附图说明

为了描述可以获得本公开的上述和其他特征的方式，将通过参考附图中所示的具体实施例来进行更具体的描述。为了更好地理解，在各个附图中，相同的元件用相同的附图标记表示。理解到附图描绘了一些示例实施例，将通过使用附图以附加的具体性和细节来描述和解释实施例，其中：

图1示出了包括根本原因分析系统的示例云计算系统。

图2示出了示例根本原因分析系统。

图3示出了根本原因分析系统的示例基础层。

图4示出了根本原因分析系统的示例决策引擎层。

图5示出了用于确定失败的根本原因的示例方法。

图6示出了可以包括在计算设备内的特定组件。

具体实施方式

云计算平台(可称为云计算系统)可使计算资源(例如虚拟机)可供客户及时托管和执行其工作负载。客户可以通过在云计算平台的服务器上部署虚拟机来部署应用。客户可以根据他们的业务需求向上或向下扩展这些虚拟机。随着客户需求的发展和增长，云计算平台可以需要建设新的数据中心或修改现有数据中心以满足容量需求。增加云计算平台的容量可以被称为容量配置。替换容量(诸如，升级硬件)或减少容量也可以是容量配置。容量配置可以通过自动化过程来完成，该过程可以被称为容量配置过程。容量配置作业可以是过程实例。容量配置过程可以需要执行一组任务，其中一些任务依赖于其他任务和其他云计算平台子系统。部分由于这些依赖，作业中的单个任务可能无法及时完成。当任务被阻止时，云计算平台可以创建一个票据以提醒操作人员阻塞。然而，票据可能无法确定阻塞的原因。可能需要许多工时来调查和确定原因和需要的修复。本公开提供了一种用于在容量配置期间处理这些票据、建立真正的失败原因(其可被称为失败的根本原因或RCF)、应用补救措施以及利用反馈回路从这些失败中学习的综合自动化系统。失败的根本原因可以是初始原因或因果链。消除失败的根本原因可以防止再次发生失败，并可以使过程向前推进。所公开的系统和方法改进了整体云计算系统操作和容量配置。

容量配置中出现的各种情况可以导致需要进行自动根本原因预测/确定。作为第一示例，容量配置作业可以包括用于在数据中心中安装服务器的手动任务。一项任务可以是数据中心操作员拧紧机架并为机架通电，以准备服务器配置。任务可以受制于服务级别协议中规定的预期完成时间。容量配置作业及其相关任务可以需要在特定时间框架内完成，因为机架位于数据中心但不占用流量的任何一天都会导致收入损失和容量损失。如果机架的螺栓连接和通电未按时完成，则后续任务可以延迟。

假设任务未在截止日期前完成。确定任务未完成的原因(为什么的根本原因)可能需要咨询来自多个源的数据。手动收集和分析数据可能是昂贵且耗时的。确定原因的一些潜在步骤可以包括确定数据中心(DC)假期时间表(是假期还是数据中心关闭？)；查询内部数据中心票据队列(是否存在影响此容量配置过程实例的票据？)；检查DC备件数据库(所需部件是否可用？)；查询DC维护日志(DC中是否有计划的维护？)；验证关键环境(主机代管(colocation)DC中是否有票据？)；从提供资源系统查询元数据(将资源可用性与每个位置的活动部署相比较)；以及检查供应商系统中的元数据(承包商时间表是否已更改或未签入)。这种场景要求从许多子系统中标识正确的根本原因，并将问题分配给合适的所有者以进行缓解的操作。本公开描述了用于以自动化和可重复的方式执行该分析的系统和方法。

作为第二示例，任务可能无法访问其所需的特定文件，因为区域中的权限配置错误。所需的权限可以不正确地被设置。因此，可以需要将权限与成功作业的权限相比较。这样做可以需要多个步骤，例如查找类似作业、检查其权限，并将其与存在问题的容量配置作业的权限相比较，以确定正确的根本原因和所有者。所描述的系统和方法可以以自动化和可重复的方式执行这些多个步骤。

作为第三示例，容量配置场景中的一些任务可以取决于其他上游设备在它们完成之前准备就绪。例如，设置服务器可能需要网络设备提供的网络连接。如果此依赖性未被明确设置，则任务可能提前开始并失败。查找问题可以涉及检查来自外部系统的信号，诸如指示网络设备的状态和包含历史信息的信号，用于将来自此失败作业的数据与成功作业的数据相比较，以将正确的信号标识为必要的依赖性。所描述的系统和方法可以标识必要的依赖性并通知(多个)适当的小组以自动和可重复的方式解决问题。

如这些示例场景所示，容量配置可以是一个复杂的过程，涉及许多在时间和空间上相互依赖的组件和小组。完成特定容量配置作业所需的任务的目标状态、运行上下文和专业知识可以单独存储，并且可以彼此隔离。当在完成容量配置作业的过程中发生阻塞时，例如在上述场景中，对阻塞原因进行根本原因分析并解除阻塞，以便作业能够继续进行，可以需要大量的手动干预和跨多个系统和小组的取证。自动化根本原因分析(RCA)系统简化了自动确定阻塞的根本原因、谁应该拥有阻塞以及如何解决和缓解阻塞的过程，可以改善容量配置过程，最终改善云计算系统。

自动化RCA系统是完全自动化的平台，可以为包括在容量配置作业中的任务、异常检测、票据关联、根本原因分析、监控和反馈以及数据可视化提供依赖和执行顺序建模。自动RCA系统可促进云容量配置作业的有效完成。自动RCA系统可以使用在数据契约中定义的模式下收集的数据来执行自动根本原因分析，确定修复所有者，并解决作业中遇到的障碍。自动化RCA系统可以包括多个层，例如基础层、决策引擎层以及监控和动作层。

基础层可以收集和存储数据，以用于确定容量配置作业上阻塞的根本原因。可以在云计算系统生成的票据中标识阻塞。基础层可以根据一个或多个数据契约从各种源和服务持续地接收和拉取数据。基础层可以处理向基础层和彼此发出事件的任务。基础层可以迅速地高速缓存和聚合所收集的数据，以供下游和稍后由决策引擎层使用。基础层可以接收或生成针对容量配置作业的执行图，该执行图指示包括在容量配置作业中的任务的执行顺序、任务之间的依赖性以及任务对云计算子系统的依赖性。基础层可以存储足以为先前的容量配置作业生成执行图的信息。

基础层可以包括数据收集/聚合系统。数据收集/聚合系统可以使用用于信号收集的公共契约。数据收集/聚合系统可以通过定义良好的标准化模式来收集多种类型的数据，该模式允许自动化RCA系统通过可扩展和自动化的过程来丰富数据。数据收集/聚合系统可以将收集的数据存储在数据存储中。数据收集/聚合系统可以从任务接收注册的事件。注册的事件可以详细描述任务进度，例如达到中间状态或完成特定动作。外部系统可以向数据收集/聚合系统发送在公共模式中定义的健康状况信号。数据收集/聚合系统可以使用元数据查询来拉取关于外部系统状态的深入信息。数据收集/聚合系统可以拉取由系统生成的根本原因记录和用户手动输入的结构化标签(注释)。根本原因记录可标识事故的RCF和事故的必要修复。

决策引擎层可以接收票据，并尝试基于与云计算系统生成的先前票据相关联的根本原因以及潜在地基于基础层收集和存储的数据来确定阻塞的根本原因。决策引擎层可以使用异常检测和基于相似度的相关性来从存储在云计算系统中的根本原因创建高级根本原因列表。决策引擎可以评估根本原因列表以标识真正的根本原因，基于真正的根本理由推荐修复项目，标识一个或多个负责修复的小组，并提供估计的完成时间。此根本原因分析(RCA)方法的准确性可通过从外部系统中拉取并保存在数据存储中的元数据和相关依赖的证实来评估。这些输入可以允许决策引擎层确定决策引擎层是否具有足够的信息来自动分配修复项目并应用缓解步骤以允许作业在执行中进行。如果修复项目已知，决策引擎层可以生成根本原因。备选地，如果决策引擎层无法自动标识问题的根本原因，决策引擎层可以声明根本原因为“未知”，并请求用户干预以手动调查和解决问题。决策引擎层可以是混合推拉系统，因为它可以在需要的时候和地方拉取数据并生成新数据。

监控和动作层可以丰富阻塞上下文，重新确定优先级并从票据中恢复。监控和动作层可以标识如何使用数据，以便了解如何在未来缩短根本原因评估时间。监控和动作层还可以包括数据可视化组件，用户可以通过该组件查看由自动RCA系统生成的信息并与之交互。

监控和动作层可以使从决策引擎层生成的信息经由用户接口可访问。监控和动作层可以被包括在监控和动作层中，诸如，监控和动作层226。监控和动作层可以显示票据已解析，以及为解析票据所做的操作。例如，监控和动作层可以在用户界面中显示添加了设置以解决容量配置作业中的失败，并显示容量配置作业的当前状态，诸如沿着执行图的进度。

监控和动作层还可以将信息记录到票据管理系统中。票据管理系统内的各种票据属性可以被添加(诸如，根本原因标签)或更新(诸如，票据优先级)。例如，如果另一子系统不健康，则监控和动作层可以将显示健康状况信号的图表附加到票据。对于阻止给定作业的关键路径执行的任务，被视为严重的问题将被设置为更高的严重性，以便用户对解决方案进行优先级排序。此外，在已知给定作业的当前状态以及类似类型的先前作业执行进度的情况下，自动RCA系统可以生成任务和票据的ETA预测。用户可以查看这些估计并标识需要进一步改进的领域，以缩短根本原因评估时间。对于系统自动应用恢复操作的问题，用户界面可以显示所采取的动作以及这些动作的基本原理。

例如，考虑如下示例，其中作业阻止验证服务器的接线是否正确，并且需要更换线。假设服务级别协议要求在八小时内更换线。假设八小时内没有发生任何动作。自动RCA系统可以查询数据存储以确定是否存在阻止技术人员完成修复的障碍。自动RCA系统可以存储来自数据中心关键环境系统的信号。如果数据中心楼层出现任何故障，技术人员可能无法完成修复。RCA系统可以查询描述员工可用性的数据库。如果是假日，技术人员可能不会立即进行修复。自动RCA系统可以查询库存系统以查看是否有任何所需的部件不可用。自动RCA系统可以快速确定失败的根本原因以及快速解决失败的可能性。自动RCA系统可以避免就阻塞问题向数据中心致电的需要。自动RCA系统可以推断出修复失败或修复延迟时修复的状态。监控和动作层可以包括闭环反馈层。闭环反馈层可以从决策引擎层接收输出。决策引擎的结果可以指导从失败中恢复。在某些情况下，闭环反馈层可以采取自动动作，例如更改配置并将票分配给其他负责小组。例如，如果闭环反馈层检测到作业配置中导致失败的新变化，则闭环反馈层可以回滚到先前已知的良好配置。当用户需要手动干预以解决问题时，用户可以将RCF添加到数据存储中以供将来使用。此外，用户可以在票据中引入结构化标签来描述问题，并提高自动RCA系统自动根本原因未来回归的能力。闭环反馈层可以将结构化标签添加到票据管理系统中的票据或RCA存储中的根本原因记录。如果同一问题发生在不同的作业上，决策引擎层可以有更好的机会确定根本原因并与现有RCF相匹配。闭环反馈层可以包括在监控和动作层中，例如监控和动作层226。

图1示出了示例云计算系统100。云计算系统100可以通过网络118使计算资源和应用对用户(例如用户120a–n)可用。用户120a–n可以包括将应用上载到云计算系统100的服务器上的云计算系统的客户端。用户120a–n可以包括访问托管在云计算系统100的服务器上的应用的个人。

云计算系统100可以包括大量物理计算资源，包括处理核心、存储空间和存储器。这些物理计算资源可以用于托管虚拟机。虚拟机可以托管应用。用户120a–n可以远程访问这些应用。可以根据特定结构来组织物理计算资源。例如，物理计算资源可以被组织成节点(也称为服务器或刀片)。一组节点可以形成机架。一组机架可以形成集群。数据中心可以容纳多个集群。集群可以跨越多个数据中心。并且云计算系统100可以包括位于世界不同区域的多个数据中心。

图1示出了可以在云计算系统中组织的计算资源的一种方式。云计算系统100可以包括数据中心102a和数据中心102n。数据中心102a、102n可以是容纳物理计算资源的物理结构。每个数据中心可以具有特定的位置。数据中心可以被组织成区和/或区域。数据中心102a、102n可以包括多个集群。例如，数据中心102a可以包括集群104a-1和集群104a-n。数据中心102n可以包括集群104n-1和104n-n。集群104a-1、104a-n、104n-1、104n-n可以包括多个机架。例如，集群104a-1可以包括机架106a1-1和106a1-n。集群104a-n可以包括机架106an-1和机架106an-n。集群104n-1可以包括机架106n1-1和机架106n1-n。集群104n-n可以包括机架106nn-1和机架106nn-n。每个机架可以包括多个服务器。例如，机架106a1-1可以包括服务器108a1-1a和服务器108a1-1n。机架106a1-n可以包括服务器108a1-na和服务器108a1-nn。机架106an-1可以包括服务器108an-1a和服务器108an-1n。机架106an-n可以包括服务器108an-na和服务器108an-nn。机架106n1-1可以包括服务器108n1-1a和服务器108n1-1n。机架106n1-n可以包括服务器108n1-1a和服务器108n1-1n。机架106nn-1可以包括服务器108nn-1a和服务器108nn-1n。机架106nn-n可以包括服务器108nn-na和服务器108nn-nn。

云计算系统100可以包括云计算子系统114。云计算子系统114可以包括支持云计算系统100的系统。云计算子系统114的示例可以是电源系统、空调系统和网络系统。其他云计算子系统114可以是存储关于数据中心的维护时间表、数据中心的员工的工作时间表以及数据中心可用的备件的信息的数据库。云计算子系统114可以包括云计算系统100的系统，包括管理服务器/节点健康状况和监控网络连接状态的系统。

随着时间的推移，云计算系统100可能需要附加的计算资源来满足客户端和客户的需求。容量配置可以是增加云计算系统100可用的物理计算资源量的任何过程。例如，容量配置可以包括向集群104a-1添加附加的机架。构建新的数据中心也可以是容量配置的示例。容量配置也可以是减少云计算系统100可用的物理计算资源量的过程，诸如在停止使用的情况下。容量配置还可以是修改云计算系统100可用的物理计算资源的过程，诸如在升级硬件的情况下。作业可以是用于实现容量配置的工作流。该作业可以包括必须完成以实现容量配置的一个或多个任务(诸如，软件和硬件任务)。硬件任务可以包括人工驱动的任务，诸如布线和用螺栓固定。例如，将机架添加到集群104a-1的作业可以涉及如下任务，诸如气候调节、将机架移动到DC楼层的瓦片、用螺栓固定和通电、为机架走线、将机架连接到网络、将安全软件添加到机架中包括的节点、以及将主机操作系统部署到这些节点。

操作116可以包括被指派执行作业以完成容量配置的个体。操作116可以包括执行包括在作业中的硬件和软件任务的技术人员和工程师。操作116可以包括软件开发和IT操作小组。云计算系统100可以在没有来自操作116的协助的情况下完成或尝试完成作业中包括的一些任务。

在完成作业的过程中，作业中包含的一个或多个任务可能无法完成或失败。云计算系统100可以包括票据管理系统112。每当作业或任务未能完成时，票据管理系统112可以为其他系统提供创建票据的服务。当作业或任务未能在指定的截止日期前完成时，其他系统可以创建票据。其他系统可以响应于指示操作116不能完成特定作业或任务的操作116来创建票据。当云计算系统100确定任务或作业已经失败、在指定的期限之前未能完成或在指定期限之前未被操作116标记为完成时，其他系统可以使用票据管理系统112自动创建票据。票据可以标识问题，并包含与问题中的作业或任务有关的附加信息。票据可能无法确定问题的根本原因。票据管理系统112可以基于严重性来管理票据的升级。票据管理系统112可以将票据路由到所属球队。

服务级别协议可以定义容量配置作业及其所有底层任务的指定截止日期或预期完成时间。例如，作业可以包括机架、检查网络连接、更新软件和执行检查等任务。这些任务中的每一个可以具有在服务级别协议中规定的定义的完成时间线，使得该作业可以在服务级别协定中定义的时间段内完成。因此，可以跟踪作业的关键路径中的每个任务(例如构建集群)。并且任何未能完成的任务都可以导致票据管理系统112针对该失败发出票据。

响应票据的一种方式是操作116手动调查票据中标识的问题的根本原因。这样做可以需要操作116检查多个不同的系统并与多个不同小组协商。手动调查根本原因可以是一个耗时且昂贵的过程。

为了更有效地确定票据中标识的问题的根本原因并加快修复和缓解过程，云计算系统100可以包括根本原因分析(RCA)系统110。RCA系统110可以提供用于监控作业执行并将根本原因和必要的修复分配给作业阻塞(包括由票据管理系统112发出的票据中标识的阻塞)的全自动平台。RCA系统110可以对作业、作为作业一部分的任务的执行顺序以及任务之间的依赖进行建模。RCA系统110可以包括异常检测、监控和反馈以及数据可视化。

RCA系统110可以包括基础层。基础层可以包括事件驱动的编排系统和数据收集/聚合系统。

容量配置作业及其任务可以引发事件。事件可以提供关于作业和任务的信息。例如，事件可以指示任务进行了多远、任务的状态以及任务是否完成。事件可以指示任务具有的任何依赖性。事件驱动编排系统可以从任务接收事件。事件可促进生成执行图以跟踪容量配置作业的进度。执行图可以表示容量配置作业的实际执行路径。任务之间的依赖性可以在单独的依赖图中定义。在备选中，执行图可以定义作业的计划执行，并描述作业中包含的任务的依赖性。

任务还可以从其他任务接收事件。容量配置任务可以使用事件进行编排和协调。例如，第二任务可以在满足其所有依赖性之后才开始。第二任务可以取决于第一任务。当第一任务达到目标状态时，第一任务可以发出为目标状态注册的对应事件。目标状态可以是任务或作业通过必要验证检查的状态。第二任务可以从第一任务接收对应的事件。如果第二任务没有其他依赖性，则第二任务可以在从第一任务接收到对应事件时执行。

任务可以有两种类型的依赖性。依赖性可以在执行图、依赖图、事件或任务中明确描述。依赖性也可以是隐式的，但没有明确记录。如果依赖性存在但尚未在任务、执行图或依赖图中明确声明，则RCA系统110可以必须基于事件以及来自其他类似作业的潜在事件和执行图来推断依赖性。

数据收集/聚合系统可以连续地从多个源收集和记录数据，以供RCA系统110在执行根本原因分析时使用。数据收集/聚合系统可以在数据存储中记录数据。数据收集/聚合系统可以记录由容量配置任务发出的事件以及基于事件生成的对应执行图。数据收集/聚合系统可以从诸如云计算子系统114的外部系统接收和存储健康状况信号。健康状况信号可以指示外部系统是否正常工作。当接收到指示外部系统不健康的健康状况信号时，数据收集/聚合系统可以发出预定义的元数据查询以从外部系统拉取附加上下文。数据收集/聚合系统可以将附加上下文保存在数据存储中。数据收集/聚合系统可以从RCA数据存储和用户在票据管理系统112中输入的结构化标签收集根本原因记录。RCA数据存储中的根本原因记录可以描述由票据管理系统112发出的票据中标识的一个或多个失败的根本原因和修复。结构化标签可以是用户已经输入的与由票据管理系统112发布的票据相关联的元数据(并且可以指示根本原因)。

RCA系统110可以包括决策引擎层。决策引擎层可以被表征为RCA系统110的大脑。决策引擎层可以使用由数据收集/聚合系统收集和存储的数据来确定票据的RCF。决策引擎层可以扫描存储在数据存储中的票据和根本原因记录，以生成候选RCF列表。决策引擎层可以向候选RCF列表中包括的RCF分配分数。分数可以基于基础层存储在数据存储中的数据。该分数可以基于RCF是否具有相关联的已知修复。

决策引擎层可以从候选RCF列表中标识RCF作为票据的根本原因。如果RCF被分配了高于阈值的分数，则决策引擎层可以将RCF标识为票据的根本原因。如果候选RCF列表不包括分数高于阈值的RCF，则决策引擎层可以确定候选RCF清单不包括票据的根本原因。如果决策引擎层没有在候选RCF列表中标识票据的根本原因(如果票据中标识的问题是新的，则可以发生这种情况)，则决策引擎层可以分析数据存储中的信息并尝试标识根本原因。决策引擎层可以生成新的RCF。决策引擎层可以在检查相关健康状况信号和事件、从可以影响或影响报告问题的区域的系统拉取附加数据、或扫描与相关票据相关联的标签之后生成新的RCF。决策引擎层可以将新的RCF添加到数据存储。决策引擎层可以确定它在没有人为干预的情况下不能生成新的RCF。在这种情况下，决策引擎层可以寻求人类的帮助，以提供元数据来标识RCF。由人员创建的根本原因记录可以添加到数据存储中。

决策引擎层的输出可以是问题的根本原因。如果RCF已经存在，决策引擎可以将RCF附加到票据上。如果RCF不可用，但决策引擎层可以使用数据存储的信息和从其他系统拉取的信息来导出RCF，则决策引擎层可生成RCF，将RCF分配给票据，并将RCF添加到RCA数据存储中以备将来使用。基于RCF，决策引擎层可以将修复分配给操作116中的一个或多个拥有小组。当决策引擎层运行分析并且没有确定根本原因时，决策引擎层可以为操作116生成分析报告。该报告可以标识所检查的内容，从而操作116可以以快速的方式执行进一步的调查。操作116可以为票据创建标签。标签可以描述票据中标识的事件的根本原因。

RCA系统110可以包括监控和动作层。监控和动作层可以通过聚合来自所有相关系统的数据来向票据添加更多信息。监控和动作层可以重新确定票据的优先级，并将票据发送给正确的负责小组。如果票据需要软件回滚或配置更改，则RCA系统110可以修改作业以执行该更改而无需人工干预。

监控和动作层可以包括仪表板。异常值、关键路径和RCA动作可以被传递到仪表板，以呈现云计算系统100的状态以及正在进行的票据。仪表板可以包括活动作业的配置状态、汇总与云计算系统100相关的度量和趋势。仪表板还可以包括优先级作业运行，并显示被阻止作业的操作成本。

图2示出了示例RCA系统210。

RCA系统210可以包括基础层222。基础层222可以从多个不同的源接收和请求数据，并将收集的数据存储在数据存储中。基础层222可以在将所收集的数据存储在数据存储器上之前对其进行格式化。

基础层222可以包括事件驱动编排系统和数据收集/聚合系统。

容量配置作业可以由一系列任务232组成，任务232具有要发出的预定义目标状态事件。任务232可以监听彼此发出的事件。任务之间可以存在多对多的依赖性映射。当作业开始时，事件驱动的编排系统可以创建执行图。执行图可以定义任务和相关目标状态的列表。执行图可以描述任务执行的顺序和依赖性。在备选中，可以在相关联的依赖图中描述依赖性。当作业内的任务执行时，任务可以发出和监听事件，并通过定义良好的数据契约发送执行上下文信息。事件驱动编排系统还可以从任务232接收事件。当所有任务都处于目标状态时，工作可以被视为完成。

数据契约可以是系统中的两个实体(或子系统)或系统中的一个实体与系统外的实体之间的理解。数据契约可以管理实体之间的数据交换。数据契约可以确保实体知道何时需要数据以及数据的格式。换句话说，数据契约可以包含第一实体向第二实体提供数据或从第二实体请求数据的条款。数据契约可以定义第一实体将向第二实体提供数据或从第二实体请求数据的特定格式。数据契约可以定义提供或请求数据的频率。数据契约可以是服务级别协议的形式。数据契约可以定义第一实体何时期望来自第二实体的数据、期望的格式和期望的延迟。例如，健康状况信号数据契约可以需要来自节点的周期性信号，该周期性信号指示该节点当前是否正在拉取流量。健康状况信号可以是二进制“0”或“1”信号。或者，健康状况信号可以包含数据集列表，以及ping传输节点状态、节点健康状况、节点容纳的虚拟机数量、节点支持的工作负载类型以及节点的正常运行时间。

数据契约可以为任务232定义用于将事件推送到彼此和事件驱动编排系统的模式。示例模式如下：

{

″TaskId″：″F84CE76A-BE07-442F-808E-F1913DB8A074″，

″EventName″：″ConfigurationComplete″，

″Scope″：″Cluster″，

″Timestamp″：″04-23-2020 13：19″，

″Region″：″uswest″，

″Cluster″：″Clusterl″，

}

数据收集/聚合系统可以收集和接收多种类型的数据。数据收集/聚合系统可以从事件驱动编排系统或任务232接收事件。这些事件可以详细描述相关联任务的进度，例如达到中间状态或完成特定动作。

数据收集/聚合系统可以从外部系统214接收健康状况信号。外部系统214可以包括RCA系统210中未包括的任何系统，包括云计算子系统114和云计算系统200的其他系统。例如，外部系统214可以包括数据中心或部件库存系统的节点。外部系统214可以使用数据契约中定义的公共模式将健康状况信号推送到数据收集/聚合系统。健康状况信号可以根据外部系统214的状态更新RCA系统210。健康状况信号可以指示外部系统214是否正在运行。健康状况信号可以包括附加信息。例如，对于节点，健康状况信号可以包括节点状态、节点健康、节点所托管的虚拟机数目、所支持的工作负载类型以及正常运行时间。

当数据收集/聚集系统接收到不健康信号时，数据收集/聚合系统可以发送预定义的元数据查询以从外部系统214拉取附加上下文。预定义元数据查询的模式可以在数据契约中定义。外部系统214可以将元数据存储在数据存储或SQL数据库中。外部系统214可以将元数据存储为结构化或非结构化数据。元数据可以是外部系统214的度量。

数据收集/聚合系统可以从外部系统214拉取信息，而不响应不健康的信号。例如，数据收集/聚合系统可以从包括在外部系统214中的人员管理系统中拉取假日计划。

数据收集/聚合系统可以拉取由RCA系统210生成的根本原因记录。根本原因记录可以与票据管理系统212可以已经发出的一个或多个票据相关联。票据可以标识云计算系统遇到的事件、问题或作业阻塞。根本原因记录可以描述票据中标识的事件的根本原因。根本原因记录可包括与事件根本原因相关联的缓解措施的详细信息。根本原因记录可以包括解决问题或作业阻塞的修复。数据收集/聚合系统可以存储与根本原因记录相关联的票据。

数据收集/聚合系统可以拉取用户手动输入的结构化标签。标签(也可以称为注释)可以是用户手动创建的记录。如果RCA系统210遇到RCA系统210未能标识根本原因的问题、事件或作业阻塞，则用户可以创建描述问题、事件、作业阻塞或问题的特征的标签。标签可以描述未来如何对此类问题进行分类。标签可以链接或与一个或多个票据相关联，以标识问题、事件、作业阻塞或问题。

RCA系统210可以包括决策引擎层224。决策引擎层224可以尝试确定票据的根本原因和票据的必要修复。决策引擎层224可以是混合推拉系统。决策引擎层224可以基于给定场景摄取以及生成数据。决策引擎层224可以包括数据存储。数据存储可以包括从外部系统214持久化的分布式事件驱动信号。可以使用公共模式来开发数据存储，外部系统214根据定义的数据契约将事件和数据发布到公共模式中。这些信号可被高速缓存并可用于决策引擎层224以提高RCA系统210的速度。

决策引擎层224可以接收票据。票据管理系统212可以发出票据。票据可以标识问题(诸如事件、问题、或作业或任务阻塞)。票据可以包括来自作业的信息。票据可以标识拥有的组成小组和一个或多个受影响的组成小组。票据可以标识问题产生的环境，诸如区域、区或控制平面。决策引擎层224可以扫描存储在数据存储中的历史票据(可以称为存档票据)，以尝试和标识与从票据管理系统212接收的票据类似的匹配票据。历史票据可以是票据管理系统212先前发行的票据。历史票据中的每个历史票据可以有零个或更多个与其相关联的根本原因记录。根本原因记录可以标识历史票据的根本原因。根本原因记录可标识针对历史票据的根本原因的必要修复。决策引擎层224可以将票据与一个或多个历史票据相比较，以标识匹配票据。决策引擎层224可以使用相似度分析来标识匹配票据。匹配票据可以是与票据具有一个或多个预定义相似度的历史票据。匹配票据可以是与该票据具有超过基于预定义算法的阈值的相似度的历史票据。

如果决策引擎层224标识匹配票据并且匹配票据具有相关联的RCF(其可以在与匹配票据相关联的根本原因记录中被标识)，则决策引擎层224可以将相关联的RCF附加到票据，将所需的修复(可以在包含RCF的根本原因记录中被标识)附加到票据，标识一个或多个负责小组来解决票据，将RCF发送给一个或多个负责小组，然后关闭票据。决策引擎层224可以使用包含在数据存储中的信息来验证相关联的RCF是票据的根本原因。

如果决策引擎层224标识了多个匹配票据，并且多个匹配票据具有不止一个相关联的RCF，则决策引擎层224可以从不止一个相关联的RCF之中标识有效的RCF，将有效的RCF和所需的修复附加到票据，标识一个或多个负责小组来解决票据，将RCF发送给一个或多个负责小组，然后关闭票据。决策引擎层224可以使用数据存储中包含的信息来标识有效的RCF。

如果决策引擎层224没有标识匹配票据(如果票据呈现新问题，则可以发生这种情况)，则决策引擎层224可以使用数据存储中包含的信息，并从外部系统214拉取附加信息，以生成票据的根本原因。为了标识根本原因，决策引擎层224可以检查相关的健康状况信号和事件，从可以影响或影响报告票据中描述的问题的区域的系统(诸如外部系统214)拉取附加数据，分析与票据相关联的作业相关联的执行图和依赖图，并扫描人类提供的任何标签。决策引擎层224还可以将当前容量配置作业的执行图与先前的容量配置作业执行图相比较，以确定问题是否由执行图之间的任何变化引起。决策引擎层224可以基于该评估生成具有新RCF的新根本原因记录。

例如，作业可以包括执行一段软件。该段软件可以依赖于部署基础设施，诸如尚未被设置的DNS服务。决策引擎层224可以确定作业被阻止，因为作业已经到达具有尚未满足的依赖性的任务。决策引擎层224可以确定尚未满足依赖性，因为数据存储不包括指示依赖性完成的事件。决策引擎层224可以基于该确定来生成新的RCF。作为另一示例，在任务开始执行之前可以已经满足了依赖性，但在任务正在执行时依赖性可能失败。决策引擎层224可以基于数据存储中的事件确定不再满足依赖性，并基于该确定生成新的RCF。

在决策引擎层224生成新的根本原因记录的一些情况下，决策引擎层222可以需要人为干预来确定必要的修复。人类可以将修复添加到新的根本原因记录，并且可以将新的根本起因记录添加到RCA存储230。

如果决策引擎层224确定决策引擎层224不能标识票据的现有RCF或生成新的RCF，则决策引擎层224可以请求人为干预以提供所需的元数据来确定RCF。决策引擎层224还可以请求人为干预，以提供票据所需的修复。决策引擎层224可以将票据分配给发出失败的组件的拥有小组，以确定根本原因。

为了提高速度和准确性，决策引擎层224可以包括机器学习引擎，以用于创建可能描述票据的根本原因的RCF列表。机器学习引擎可以使用基于相似度的分析来标识与票据匹配的先前票据。机器学习引擎还可以包括定制的启发式法、基于正则表达式、基于规则，包括文本分析或包括自然语言处理。决策引擎层224可以使用与匹配票据相关联的RCF来创建可能描述票据的根本原因的RCF列表。决策引擎层224可以使用RCF列表来确定实际RCF和修复项目，以发送给负责必要修理的一个或多个小组。

决策引擎层224还可以包括修剪模块，以细化潜在地匹配票据的RCF的列表。修剪模块可以通过基于影响分析修剪匹配票据来修剪RCF列表。修剪可以基于时间和空间相关性。如果一组事件被定位到特定区域，则修剪模块可以得出该组事件与另一位置的事件无关的结论。结果，修剪模块可以修剪与该组事件相关联的RCF。作为另一示例，修剪模块可以分析问题是仅局限于一个DC还是全局问题。修剪模块还可以分析是否存在导致该问题的时间事件。例如，修剪模块可以分析特定事件是否仅因为特定软件配置改变发生而发生。

机器学习引擎和修剪模块对于决策引擎层224来说不是必需的，但是可以提高信息检索的准确性和速度。

作为确定票据的RCF的一部分，决策引擎层224可以向RCF分配分数，决策引擎层224将该分数标识为票据的可能根本原因(例如与票据类似的票据相关联的根本原因)。如果票据存在RCF，并且票据已知修复项目，则分数可以是可用的并且较高。在这种情况下，决策引擎层224可以向票据分配RCF，标识修复项目和一个或多个负责小组，并关闭票据。修复项目的结果可被其他系统用于应用/缓解并采取动作。

如果分数较低，决策引擎层224可以确定关闭票据所需的修复项目，但精确的RCF可以不可用。在这种情况下，决策引擎层224可以生成新的RCF并为将来的情况丰富RCA存储230。在备选中，决策引擎层224可能无法生成新的RCF，并且可以寻求人工帮助。

如果分数低，决策引擎层224可以能够确定RCF，但不能确定关闭票据所需的修复项目。在这种情况下，决策引擎层224可以寻求人工帮助以确定所需的修复。

如果分数不可用，决策引擎层224可以确定RCF不可用，并且修复该问题的修复项目和责任小组是未知的。在这种情况下，决策引擎层224可以确定数据存储不具有确定RCF所需的信息，并且需要人为干预来确定根本原因并标识修复项目。决策引擎层224可以将票据分配给发出失败的组件的拥有小组，以确定根本原因。来自人工干预的反馈可以流入数据存储，以允许RCA系统210学习和改进未来的情况。为了重用和分类目的，可以使用结构化标签来创建该反馈。结构化标签可以链接到票据。结构标签可包含RCA系统210可用于标识与标签所链接的RCF相匹配的未来票据的指示符(例如引起问题的特定硬件类别)。

对于决策引擎层224使用评分系统的设计，来自决策引擎层224的潜在输出可以包括以下项。

第一，RCF和修复均已知(场景：分数可用)。例如，任务可能无法访问区域中任务所需的特定文件。返回的错误消息是已知的。云计算系统此前可能已经遇到过此错误消息，并有补丁来修复它。因此，RCA存储230可以包括与此错误消息相关联的RCF。决策引擎层224可以找到具有该失败码和相关联的RCF的先前票据。缓解层(诸如监控和动作层226)可以应用补丁并将票据与RCF相关联。

第二，修复已知，但RCF不可用(场景：分数差)。例如，可能有这样的情况：由于相同的问题以不同的方式表现出失败。与格式化硬盘驱动器相关的故障可能在希捷驱动器和三星驱动器上显示为不同的异常。三星可能已经创建了修复。但是，如果希捷驱动器发生事故，则可能没有相关联的RCF。作为另一示例，用于设置服务器的任务失败，因为该任务对上游网络设备具有依赖性，但在作业场景中并未设置该依赖性。决策引擎层224可以查看此作业场景的先前运行。决策引擎层224可以发现执行图中的差异。上游网络设备可能在先前作业场景中在该任务之前运行，但被设置为在当前作业场景中在该任务之后运行。决策引擎层224可以使用来自外部系统214的关于网络设备的状态的元数据来将上游网络设备标识为问题。RCA系统210可以为该任务添加正确的依赖性。因为RCF之前没有被看到，所以RCA系统210(诸如通过监控和动作层226)可以在RCA存储230中创建并保存新的RCF。

第三，RCF存在，但修复未知(场景：分数差)。RCA系统210(例如通过监控和动作层226)可以寻求人为干预以确定RCF的修复。RCA系统210可以将修复与RCF相关联，并将修复和RCF存储在RCA存储器230中以供将来使用。

第四，修复和RCF未知(场景：分数不可用)。例如，在给定的硬件类上，由于配置无效，硬盘驱动器可以出现失败。当作业场景包括检查硬盘运行状况或尝试格式化磁盘时，此失败可以导致问题。RCA系统210可能无法确定导致问题的原因，因为可以不存在可靠的指示符。结果，RCA系统210可以将票据分配给发出失败的部件的拥有小组，以便人为干预以确定根本原因。操作216可以审查票据并创建描述问题的手动注释(标签)，包括什么硬件类导致该问题。对于未来的车票，该标识现在可以是自动的。如果RCA系统210看到与该硬件类别匹配的作业场景上的问题，则RCA系统210可以将该票据标记为属于该RCF。当此硬盘驱动器问题已解决且不再发生时，可以手动从数据存储中删除注释。当正在跟踪的修复项目得到解决时，注释/标记可以自动删除。

RCA系统210可以包括监控和动作层226和呈现系统228。监控和动作层226可以向由票据管理系统212发出的票据添加附加信息。监控和动作层226可以通过健康状况信号或元数据查询获得附加信息，并将其添加到票据中，以便该票据对必须手动修正问题的人更有用。例如，在刀片开始启动的作业中可以存在检查点。由于错误，刀片可能无法启动。票据可以表示启动的刀片数目不足。监控和动作层226可以针对外部系统214中包括的正在监控所有刀片的健康的系统进行元数据查询。监控和动作层226可以将接收到的元数据放入票据中，使得票据更有用。元数据可以允许操作216看到一些刀片由于第一错误而没有启动，并且另一组刀片由于第二错误而没有起动。

监控和动作层226可以允许RCA系统210显示所发生的事情的结果。监控和动作层226可以向票据添加信息，该信息显示票据已被解析并且描述为解析票据所做的操作。

监控和动作层226可以将RCF添加到票据。这样，如果RCF不正确，则操作216可以修正该信息。

呈现系统228可以显示关于票据和票据中标识的失败或阻塞的信息，以供用户查看。呈现系统228还可以允许用户与所显示的信息和输入信息交互。呈现系统228可以指示票据是否具有相关联的根本原因。呈现系统228可以指示多个票据是否已经链接到相同的根本原因。呈现系统228可以指示票据不具有根本原因或不具有修复。呈现系统228可以允许用户向票据分配根本原因或修复。呈现系统228可以允许用户将票据链接到其他票据。呈现系统228可以包括在监控和动作层226中。

图3示出了示例基础层322。基础层322可以包括事件驱动编排系统336和数据收集/聚合系统334。

事件驱动编排系统336可以从容量配置任务332接收信息。容量配置任务332可以包括作为容量配置作业的一部分的活动任务。容量配置任务332可以具有相关联的目标状态。一旦任务达到其目标状态，任务就可以完成。当容量配置任务332朝向其目标状态前进时，容量配置任务322可以生成事件342a。事件342a可以包含关于容量配置任务332和容量配置任务的状态的信息。容量配置任务332可以向彼此提供事件342a。例如，任务332a可以向任务332b提供第一事件。任务332可以向事件驱动编排系统336提供事件342a。事件驱动编排系统336可以基于事件342a生成或更新作业的执行图。容量配置任务332可以根据一个或多个数据契约350将事件342a推送给彼此并推送给事件驱动的编排系统336。数据契约350可以定义事件342a的模式。

数据收集/聚合系统334可以从多个源收集、格式化和聚合信息和数据。数据收集/聚合系统334将收集的信息存储在数据存储338中。

数据收集/聚合系统334可以包括事件收集模块360。事件收集模块360可以从事件驱动编排系统336接收一个或多个事件342a。在备选中，事件收集模块360可以从容量配置任务332接收一个或多个事件342a。在备选中，事件收集模块360可以从消息队列接收一个或多个事件342a。事件收集模块360可以根据数据契约350接收事件342a中的一个或多个事件。事件收集模块360可以将一个或多个事件342a作为事件342b持久化到数据存储。

数据收集/聚合系统334可以包括健康状况信号收集模块358。健康状况信号收集模块358可以从外部系统314接收信息或数据。外部系统314可以是支持云计算系统的系统。外部系统314可以在云计算系统内，但在数据收集/聚合系统334外部。外部系统314可以在云计算系统外部。

外部系统314可以生成健康状况信号346a。健康状况信号346a可以包括关于外部系统314的健康状态的信息。例如，健康状况信号346a可以指示外部系统314中包括的特定系统是否正在运行。外部系统314可以周期性地或在系统的健康状态改变时生成健康状况信号346a。外部系统314可以向健康状况信号收集模块358提供一个或多个健康状况信号346a。外部系统314可以根据数据契约350中概述的公共模式来提供健康状况信号346a。健康状况信号收集模块358可以将一个或多个健康状况信号346a作为健康状况信号346b持久化到数据存储。

数据收集/聚合系统334可以包括结构化标签收集模块356。票据管理系统312可以包括并接收标签340a。用户可以根据公共模式生成标签340a。标签340a可以包括先前由票据管理系统312生成的关于票据的信息。例如，标签340a可以对票据中标识的问题进行分类。用户可以响应于票据管理系统312生成票据而生成标签340a。结构化标签收集模块356可以从票据管理系统312拉取标签340a中的一个或多个标签。结构化标签收集模块356可以将标签340a中的一个或多个标签作为标签340b持久化到数据存储338。

数据收集/聚合系统334可以包括元数据收集模块354。外部系统314可以包括数据存储344。数据存储344可以包括关于外部系统314和健康状况信号346a的元数据。元数据收集模块354可以查询数据存储344。元数据收集模块354可以响应于查询数据存储344来接收元数据。元数据收集模块354可以将元数据持久化到数据存储338。元数据收集模块354可以响应于健康状况信号收集模块358接收到一个或多个健康状况信号346a而查询数据存储344。例如，健康状况信号收集模块358可以从外部系统314接收第一健康状况信号。第一健康状况信号可以指示第一节点离线。响应于健康状况信号收集模块358接收到第一健康状况信号，元数据收集模块354可以向数据存储344查询关于第一节点和第一健康状况信号的元数据。元数据可以包括关于第一节点以及关于其离线的原因的附加信息。

数据收集/聚合系统334可以包括RCA收集模块352。云计算系统可以将根本原因记录348a存储在RCA存储330中。RCA收集模块352可以从RCA存储330中拉取一个或多个根本原因记录348a。RCA收集模块352可以将根本原因记录348a中的一个或多个根本原因记录持久化到数据存储338作为根本原因记录348b。根本原因记录348a可以标识问题的根本原因。该问题可在一张或多张票据中标识。根本原因记录348a还可以指示解决问题所需的修复。根本原因记录348a可以标识负责修复的一个或多个小组。

票据可以链接到根本原因记录。根本原因记录可以与一个或多个票据链接或相关联。例如，格式化硬盘驱动器的软件可能存在漏洞。硬盘驱动器可以被包括在全球多个数据中心正在安装的服务器中。修复可以正在推出过程中，但可以仅限于有限数目的数据中心。云计算系统可以开始发现五到十个数据中心出现失败。RCA系统可以将事故与单一的根本原因联系起来，而不是因为有数十个容量配置作业正在并行进行而导致操作充斥着事故。通过这种方式，操作人员可以看到所有事件都与单个根本原因相关。由于失败发生在不同区域和不同控制平面的不同位置，因此会发生多起事故。维护多个事件使云计算系统和操作能够评估错误的总体影响。

图4示出了示例决策引擎层424。决策引擎层424可以包括修剪模块472、评分模块462、数据存储438、决策模块464、和机器学习引擎466。

决策引擎层424可以从票据管理系统接收票据。票据可以标识事故。该事件可以是在尝试完成容量配置作业时遇到的问题或失败。决策引擎层424可以尝试自动确定事件的根本原因。自动标识事件的根本原因可以加快修复。

为了确定在当前票据中标识的事件的根本原因，决策引擎层424可以尝试找到与当前票据类似的先前票据(可以称为历史票据或存档票据)。先前票据可以包括活动的票据以及尚未缓解、解决或关闭的票据。数据存储438可以包括票据管理系统先前发出的存档票据。存档票据中的一个或多个存档票据可以链接到一个或多个根本原因记录。根本原因记录可以标识票据的根本原因。根本原因记录可以标识针对票据的必要修复。单个票据可以链接到单个根本原因记录。单个根本原因记录可以链接到多个票据。

决策引擎层424可以使用任何可用的匹配算法来标识与当前票据相似的先前票据。例如，决策引擎层424可以标识与当前票据具有相同标题的先前票据。作为另一示例，决策引擎层424可以标识具有发生事故的匹配硬件类型的先前票据。作为另一示例，决策引擎层424可以确定当前票据与先前票据的接近程度的余弦值，并且如果余弦值高于阈值，则确定先前票据是相似的。

作为另一示例，决策引擎层424可以使用机器学习引擎466来标识与当前票据类似的先前票据。

机器学习引擎466可以包括异常检测系统468。异常检测系统468可以使用执行图中的每个任务的历史执行时间，以基于被配置的SKU来完成。异常检测系统468可以使用该执行时间序列通过将数据分解成其趋势、季节分量和残差来检测异常。可以基于基于数据的领域知识选择的异常检测阈值来反映所得到的异常。

机器学习引擎466可以包括基于相似度的票据检索470。基于相似度的票据检索470可以使用来自堆栈日志的非结构化数据、结构化数据和影响缓解票据的总时间的域特定特征。这可以导致引入具有相关联的根本原因的历史票据和有关历史票据是如何解决的修复详细信息，并且具有高可信度，即值班工程师可以使用根本原因和修复详细信息来解决当前票据中标识的问题。

机器学习引擎466还可以包括定制启发式，基于正则表达式，基于规则，包括文本分析或包括自然语言处理。机器学习引擎466可以使用这些技术中的任何一种(或本领域已知的任何其他机器学习技术)来标识与当前票据相似的历史票据。机器学习引擎466标识的历史票据可以具有相关联的根本原因和修复，其可以包括针对当前票据的根本原因及修复。

决策引擎层424可以使用决策引擎层422确定为与当前票据相似的先前票据(如果有的话)来标识当前票据的潜在根本原因。决策引擎层424可以创建与决策引擎层422确定为与当前票据类似的先前票据相关联的所有根本原因的列表。该列表可以是针对当前票据的可能根本原因的列表。决策引擎层424可以使用修剪模块472来修剪可能根本原因的列表。决策引擎层424可以使用评分模块462来对可能根本原因的列表上的每个根本原因进行评分。分配给可能根本原因的列表上的每个根本原因的分数可以部分地基于根本原因是否具有与其相关联的已知修复。评分模块462可以访问数据存储438中包含的信息，并从外部系统拉取信息，以对可能根本原因的列表上的每个根本原因进行评分。决策引擎层424可以使用评分模块462来对与可能根本原因的列表相关联的每个根本原因记录(其可以标识也可以不标识针对根本原因的必要修复)进行评分。评分模块462可以访问包含在数据存储438中的信息并且从外部系统拉取信息以对与可能的根本原因列表相关联的每个根本原因记录进行评分。

决策引擎层424可以使用决策模块464来确定可能根本原因的列表是否包括当前票据的根本原因。如果没有可能根本原因接收到高于最小阈值的分数(如果可能根本原因的列表为空，则可以发生)，则决策引擎层424可以确定决策引擎层424在没有人为干预的情况下无法确定当前票据的根本原因。在这种情况下，决策引擎层424可以向操作人员提供当前票据，以确定当前票据的根本原因和所需的修复。

如果决策引擎层424标识出分数高于高阈值的根本原因，则决策引擎层422可以确定根本原因应该与当前票据相关联。决策引擎层424可以确定当前票据的修复是已知的。可以在标识根本原因的根本原因记录中描述修复。决策引擎层424可以标识责任小组并将修复通知责任小组。

如果决策引擎层424标识分数低于高阈值但高于最小阈值的根本原因，则决策引擎层422可以确定当前票据的修复是已知的，但当前票据的根本原因当前不存在。例如，决策引擎层424可以确定在根本原因记录中标识的修复可以用于解决当前票据，但是在根本原因记录中标识的根本原因不是当前票据的有效根本原因。决策引擎层424可以使用存储在数据存储438中的信息来生成当前票据的根本原因。如果决策引擎层424确定它不能为当前票据生成根本原因，则决策引擎层422可以从操作中寻求帮助以确定根本原因。

如果决策引擎层424标识分数低于高阈值但高于最小阈值的根本原因，则决策引擎层422可以确定当前票据的根本原因是已知的，但修复是未知的。在这种情况下，决策引擎层424可以将当前票据和根本原因提供给操作人员以确定修复。例如，决策引擎层424可以标识针对当前票据的匹配票据。匹配票据可以与根本原因记录相关联。根本原因记录可以标识匹配票据的根本原因，但可能无法标识针对匹配票据的根本原因所必要的修复。

图5示出了用于确定失败的根本原因的示例方法500。

方法500可以包括接收502标识失败的票据。

方法500可以包括从一个或多个历史票据之中标识504零个或更多个匹配票据。零个或更多个匹配票据可以与该票据相似。标识504零个或更多个匹配票据可以使用机器学习引擎来完成。

方法500可以包括基于与零个或更多个匹配票据相关联的根本原因记录来标识506零个或更多个潜在根本原因。零个或更多个匹配票据中的每个匹配票据可以链接到一个根本原因记录。票据可以只有一个根本原因。票据可以需要一个或多个小组拥有的多个修复项目。

方法500可以包括将508分数分配给零个或更多个潜在根本原因。将分数分配508给零个或更多个潜在根本原因可以包括基于存储在数据存储中的数据来确定分数。存储在数据存储中的数据可以包括事件、健康状况信号、针对外部系统的元数据、根本原因记录和标签。

方法500可以包括确定510零个或更多个潜在根本原因是否包括失败的根本原因。确定510零个或更多个潜在根本原因是否包括失败的根本原因可以基于分数。

方法500可以包括确定512根本原因是否已知。确定512根本原因是否已知可以包括：确定一个或多个历史票据是否包括与票据充分相似的匹配票据，确定匹配票据是否具有标识匹配票据的根本原因的相关联的根本原因记录，以及基于存储在数据存储中的数据来确定匹配票据的根本原因是否是票据的有效根本原因。

如果根本原因已知，则方法500可以包括确定514修复是否已知。确定514修复是否已知可以包括确定相关联的根本原因记录是否标识修复。

如果修复已知，则方法500可以包括将根本原因分配516给票据，以及针对修复标识一个或多个修复小组。

如果修复未知，则方法500可以包括请求518人为干预以确定和分配修复。方法500还可以包括将根本原因分配516给票据，以及针对修复标识一个或多个修复小组。

如果根本原因未知，则方法500可以包括确定520是否可以生成根本原因。确定520是否可以生成根本原因可以包括尝试基于数据存储中的数据来生成根本原因。

如果可以产生根本原因，则方法500可以包括确定514修复是否已知。

如果无法生成根本原因，则方法500可以包括请求522人为干预以根据需要分配根本原因和标签，以及确定524修复是否已知。

如果修复已知，则方法500可以包括将根本原因分配516给票据，以及针对修复标识一个或多个修复小组。

如果修复未知，方法500可以包括请求518人为干预以确定和分配修复。

现在参考图6。一个或多个计算设备600可以用于实现本文公开的技术的至少一些方面。图6示出了可以包括在计算设备600内的特定组件。

计算设备600包括处理器601和与处理器601进行电子通信的存储器603。指令605和数据607可以存储在存储器603中。指令605可以由处理器601可执行以实现本文公开的方法、步骤、操作、动作或其他功能中的一些或全部。执行指令605可以涉及使用存储在存储器603中的数据607。除非另有规定，否则本文描述的模块和组件的各种示例中的任何一个都可以部分或全部实现为存储在存储器603中并由处理器601执行的指令605。本文描述的各种数据示例中的任何一个可以是存储在存储器603中并且在处理器601执行指令605期间使用的数据607。

尽管在图6的计算设备600中仅示出了单个处理器601，但是在备选配置中，可以使用处理器的组合(例如，高级RISC(精简指令集计算机)机器(ARM)和数字信号处理器(DSP))。

计算设备600还可以包括用于与其他电子设备通信的一个或多个通信接口609。(多个)通信接口609可以基于有线通信技术、无线通信技术或两者。通信接口609的一些示例包括通用串行总线(USB)、以太网适配器、根据电气和电子工程师协会(IEEE)802.11无线通信协议操作的无线适配器、

无线通信适配器和红外(IR)通信端口。

计算设备600还可以包括一个或多个输入设备611和一个或多个输出设备613。输入设备611的一些示例包括键盘、鼠标、麦克风、遥控设备、按钮、操纵杆、轨迹球、触摸板和光笔。通常包括在计算设备600中的一种特定类型的输出设备613是显示设备615。与本文公开的实施例一起使用的显示设备615可以利用任何合适的图像投影技术，诸如液晶显示器(LCD)、发光二极管(LED)、气体等离子体、电致发光、可穿戴显示器等等。还可以提供显示控制器617，以用于将存储在存储器603中的数据607转换为显示设备615上所示的文本、图形和/或运动图像(视情况而定)。计算设备600还可以包括其他类型的输出设备613，诸如扬声器、打印机等等。

计算设备600的各个组件可以通过一个或多个总线耦合在一起，总线可以包括电源总线、控制信号总线、状态信号总线、数据总线等等。为了清晰起见，各种总线在图6中被示为总线系统619。

本文公开的技术可以硬件、软件、固件或其任何组合实现，除非具体描述为以特定方式实现。被描述为模块、组件等的任何特征也可以一起在集成逻辑设备中实现，或者单独地作为分立但可互操作的逻辑设备实现。如果以软件实现，则所述技术可以至少部分地通过其上存储有计算机可执行指令的非瞬态计算机可读介质来实现，当由至少一个处理器执行时，计算机可执行的指令执行本文所公开的步骤、操作、动作或其他功能中的一些或全部。指令可以被组织成例程、程序、对象、组件、数据结构等，它们可以执行特定的任务和/或实现特定的数据类型，并且可以在各种实施例中根据需要进行组合或分发。

术语“处理器”可以指通用单芯片或多芯片微处理器(例如，高级RISC(精简指令集计算机)机器(ARM))、专用微处理器(例如数字信号处理器(DSP))、微控制器、可编程门阵列等。处理器可以是中央处理单元(CPU)。在一些实施例中，处理器(例如，ARM和DSP)的组合可以用于实现本文公开的一些或所有技术。

术语“存储器”可以指能够存储电子信息的任何电子部件。例如，存储器可以体现为随机存取存储器(RAM)、只读存储器(ROM)、磁盘存储介质、光存储介质、RAM中的闪存设备、各种类型的存储类存储器、包括处理器的板载存储器、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)存储器、寄存器等等，包括其组合。

在不脱离权利要求的范围的情况下，本文描述的方法的步骤、操作和/或动作可以彼此互换。换句话说，除非步骤、操作和/或动作的特定顺序对于所描述的方法的正确运行是必需的，否则可以在不脱离权利要求的范围的情况下修改特定步骤、操作、和/或操作的顺序和/或使用。

术语“确定”(及其语法变体)可以涵盖各种各样的动作。例如，“确定”可以包括运算、计算、处理、导出、调查、查找(例如，在表、数据库或其他数据结构中查找)、查明等。此外，“确定”可以包括接收(例如，接收信息)、访问(例如，访问存储器中的数据)等等。此外，“确定”可以包括解决、选择、挑选、建立等等。

术语“包括”、“包含”和“具有”旨在具有包容性，意味着除列出的元素外，还可以有其他元素。此外，应当理解，对本公开的“一个实施例”或“一实施例”的引用不旨在被解释为排除也包含所述特征的附加实施例的存在。例如，在兼容的情况下，关于本文中的实施例描述的任何元件或特征可以与本文中描述的任何其他实施例的任意元件或特征组合。

在不脱离本公开的精神或特征的情况下，本公开可以以其他特定形式体现。所描述的实施例被认为是说明性的而非限制性的。因此，本公开的范围由所附权利要求而不是由前述描述来指示。在权利要求的含义和等效范围内的变更应包含在其范围内。

Claims (15)

1.一种用于自动确定与云计算系统中的容量配置过程相关联的失败的根本原因的系统，所述系统包括：

一个或多个处理器；

存储器，其与所述一个或多个处理器电子通信；

数据存储，其中所述数据存储包括历史票据和与所述历史票据中的一个或多个历史票据相关联的根本原因记录；以及

指令，其存储在所述存储器中，所述指令由所述一个或多个处理器可执行以：

接收由与所述容量配置过程相关联的任务发出的事件，其中所述事件描述所述任务的状态；

从一个或多个外部系统接收健康状况信号，其中所述健康状况信号指示所述一个或多个外部系统是否可操作；

接收票据，其中所述票据标识与所述容量配置过程相关联的所述失败；

基于所述事件、所述健康状况信号、所述历史票据和所述根本原因记录来确定所述失败的所述根本原因，其中确定所述失败的所述根本原因包括相对于所述历史票据对所述票据进行模式匹配；

将所述失败的所述根本原因与所述票据相关联；以及

将所述失败的所述根本原因提供给操作。

2.根据权利要求1所述的系统，其中基于所述事件、所述健康状况信号、所述历史票据和所述根本原因记录来确定所述失败的所述根本原因的所述指令包括如下指令，所述指令由所述一个或多个处理器可执行以：

标识所述历史票据之中的匹配票据，其中所述匹配票据具有与所述票据的一个或多个相似度；

标识与所述匹配票据相关联的根本原因记录，其中与所述匹配票据相关联的所述根本原因记录标识所述匹配票据的根本原因；以及

部分地基于与所述匹配票据相关联的所述根本原因记录来确定所述失败的所述根本原因。

3.根据权利要求2所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

标识所述历史票据之中的附加匹配票据，其中所述附加匹配票据具有与所述票据的一个或多个相似度；

标识与所述附加匹配票据相关联的一个或多个根本原因记录，其中与所述附加匹配票据相关联的所述一个或多个根本原因记录标识针对所述附加匹配票据的根本原因；以及

基于时间和空间相关性来修剪所述一个或多个根本原因记录。

4.根据权利要求2所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

基于与所述匹配票据相关联的所述根本原因记录来确定针对所述失败的修复；

针对所述修复标识一个或多个修复小组；以及

将所述失败的所述根本原因和所述修复提供给所述一个或多个修复小组。

5.根据权利要求4所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

与和所述云计算系统相关联的其他修复相比，使所述修复优先。

6.根据任一项前述权利要求所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

确定所述根本原因记录不包含所述失败的所述根本原因；

基于所述事件或所述健康状况信号来生成所述失败的所述根本原因；以及

将所述失败的所述根本原因存储在所述数据存储中。

7.根据权利要求6所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

收集与所述历史票据中的一个或多个历史票据相关联的标签，其中标签包括关于历史票据的根本原因的信息并且所述标签根据定义的模式被输入，并且其中生成所述失败的所述根本原因部分地基于所述标签。

8.根据任一项前述权利要求所述的系统，其中由与针对所述云计算系统的所述容量配置过程相关联的所述任务发出的所述事件以及来自所述一个或多个外部系统的所述健康状况信号根据数据契约而被接收。

9.根据任一项前述权利要求所述的系统，其中所述指令还由所述一个或多个处理器可执行以：

响应于接收到所述健康状况信号，针对元数据查询所述外部系统；以及

将所述元数据存储在所述数据存储上。

10.一种由计算设备执行的用于自动确定与容量配置过程相关联的失败的根本原因的方法，其中所述容量配置过程用于云计算系统，所述方法包括：

接收票据，所述票据指示所述失败；

标识所述失败的零个或更多个潜在根本原因，其中所述零个或更多个潜在根本原因在与一个或多个历史票据相关联的根本原因记录中被描述；

将分数分配给所述失败的所述零个或更多个潜在根本原因；

基于所述分数来确定所述零个或更多个潜在根本原因是否包括所述根本原因；

如果所述零个或更多个潜在根本原因不包括所述失败的所述根本原因，则确定所述失败的所述根本原因是否能够在没有人为干预的情况下被生成；

基于与所述一个或多个历史票据相关联的所述根本原因记录来确定针对所述失败的修复是否已知；

如果所述根本原因或所述修复未知，则寻求人为干预；

如果所述根本原因已知，则将所述根本原因附接到所述票据；以及

如果所述修复已知，则标识一个或多个修复小组以完成所述修复。

11.根据权利要求10所述的方法，还包括基于从与所述容量配置过程相关联的任务接收的事件、从支持所述云计算系统的外部系统接收的健康状况信号以及与所述历史票据相关联的标签来生成所述失败的所述根本原因。

12.根据权利要求10或11所述的方法，其中所述一个或多个历史票据被包括在一组历史票据中，并且标识针对所述失败的所述零个或更多个潜在根本原因包括：

基于比较所述票据与所述一组历史票据来标识所述一个或多个历史票据；以及

标识与所述一个或多个历史票据相关联的所述根本原因记录。

13.根据权利要求10至12所述的方法，其中分配给针对所述失败的所述零个或更多个潜在根本原因的所述分数是基于以下项的：从与所述容量配置过程相关联的任务接收的事件、从支持所述云计算系统的外部系统接收的健康状况信号以及与所述历史票据相关联的标签。

14.一种计算机可读介质，包括指令，所述指令由一个或多个处理器可执行以使计算系统：

接收由与针对云计算系统的容量配置过程相关联的任务发出的事件，其中所述事件描述所述任务的状态；

从一个或多个外部系统接收健康状况信号，其中所述健康状况信号指示所述一个或多个外部系统是否可操作；

接收票据，其中所述票据标识与所述容量配置过程相关联的失败；

访问存储所述云计算系统的历史票据的数据存储，其中所述历史票据中的一个或多个历史票据具有相关联的根本原因记录；

基于所述事件、所述健康状况信号、所述历史票据和所述相关联的根本原因记录来确定所述失败的根本原因，其中确定所述失败的所述根本原因包括相对于所述历史票据对所述票据进行模式匹配；

基于相关联的所述根本原因记录来确定针对所述失败的必要修复；以及

确定用于完成所述必要修复的估计时间。

15.根据权利要求14所述的计算机可读介质，还包括指令，所述指令由所述一个或多个处理器可执行以使所述计算系统：

执行所述必要修复。

Images