用于将故障注入分布式系统的装置和方法

技术领域

本发明涉及分布式系统的软件测试和验证。更具体地，本发明涉及一种用于将故障注入分布式系统的装置和方法以及这种分布式系统。

背景技术

故意将故障注入分布式系统是测试分布式系统是否能够处理和从已知或未知故障中恢复的重要工具。换句话说，故障注入是一种可靠性测试方法，用于确保分布式系统在故障条件下继续工作。分布式系统是由多个组件组成的系统，多个组件即在相同或不同的电子机器或设备上运行并通过网络进行通信的处理节点。任何组件或连接这些组件的通信通道都可能发生故障。

故障注入技术主要有两种类型，即白盒故障注入方法(也称为编译时故障注入方法)和运行时故障注入方法。在白盒故障注入方法中，故障注入原语通常直接注入软件代码中。运行时故障注入方法通常标识正在运行的分布式系统的状态，并依靠触发器动态注入故障。

这两种技术在实现成本和故障注入精度方面都有局限性。白盒方法的实现成本较高，因为分布式系统的原始源代码需要被理解、更改，并可能重新编译。另一方面，由于故障注入原语直接添加到软件代码中，因此精度较高，因为可以在指令级别准确地注入故障。这使得实验是可重复的。另一方面，运行时故障注入方法通常实现成本较低，因为所分析的分布式系统不需要检测。外部系统负责监控所研究的分布式系统的状态。尽管如此，这一优点伴随着一个缺点，即与白盒方法相比，精度较低，因为使用现有工具检测分布式系统的状态是复杂和不精确的。状态监控通常通过检查和检测何时触发某个操作来实现，例如当分布式系统创建文件、打开某个端口、进程开始执行或将记录添加到日志文件中时。状态检测与故障注入之间的延迟可能较高，这意味着故障不会始终在相同的状态下注入，从而难以再现场景。

发明内容

本发明的目的是提供一种用于将故障注入分布式系统的改进的装置以及对应的方法。

上述和其它目的通过独立权利要求请求保护的主题来实现。其它实现方式在从属权利要求、说明书和附图中是显而易见的。

公开了一种基于模型的方法，用于使用软件实现的故障注入来测试分布式系统的可靠性。分布式跟踪基础设施可以用于决定在哪里注入故障，故障类型可以根据分布式系统的组件(例如分布式系统的一部分，例如微服务应用程序中的服务)之间的相互关系来选择。通过使用分布式跟踪来标识分布式系统的重要状态，并通过暂时阻止转换直到故障被注入，在注入故障时，可以实现高精度水平。分布式系统被视为包括多个处理节点(即相互通信的组件)的状态机。分布式系统的组件可以在微服务架构中表示为服务。组件之间的通信通道可以使用远程过程调用(remote procedure call，RPC)、超文本传输协议(hypertext transfer protocol，HTTP)和进程间通信(inter-process communication，IPC)等技术实现。

更具体地，根据第一方面，提供了一种用于将故障注入分布式系统的装置。该装置包括跟踪观察器，用于采集关于分布式系统的多个处理节点(例如处理服务请求的多个网络节点)的操作的执行的跟踪信息。该装置还包括模型构建器，用于根据跟踪信息生成分布式系统的状态机的模型(本文也称为分布式系统的状态机模型)，其中，分布式系统的状态机的模型定义了分布式系统的多个不同状态。该装置还包括计划引擎，用于根据分布式系统的状态机的模型生成执行计划，其中，对于分布式系统的多个不同状态中的至少一个状态，执行计划标识在至少一个状态下待注入的故障的类型。该装置还包括故障注入器，用于例如在操作的进一步执行期间将具有在执行计划中标识的类型的至少一个故障注入分布式系统。

因此，有利地，白盒故障注入方法的优点(即高精度和可预测性)和运行时故障注入方法的优点(即，较低的实现成本)被结合在一起，同时不表现出它们相应的缺点。因此，根据第一方面的装置具体提供了以下主要优点：

(i)较高精度：故障可以精确地注入分布式系统的明确定义的状态，评估是可重复的；

(ii)降低成本：实现成本较低，因为不需要对源代码进行更改(遵循黑盒范式)；

(iii)无监督操作：可以自动决定在何处注入故障。

在第一方面的另一种可能的实现方式中，跟踪信息包括关于多个处理节点的操作的执行的顺序的信息。

在第一方面的另一种可能的实现方式中，该装置还包括断点管理器，用于在分布式系统的多个不同状态中的至少一个状态下设置断点，其中，故障注入器还用于在多个处理节点的操作的执行期间断点达到时将至少一个故障注入分布式系统。

在第一方面的又一种可能的实现方式中，该断点管理器还用于在至少一个故障被注入分布式系统时阻止任何进一步的状态转换。换句话说，在故障注入期间，系统被“暂停”。

在第一方面的又一种可能的实现方式中，执行计划针对分布式系统的多个不同状态中的一个以上的状态标识在相应状态下待注入的故障的相应类型，其中，故障注入器还用于按顺序或基于状态概率的顺序注入由执行计划标识的多个故障。因此，有利地，该装置可以实现不同的执行策略，例如“顺序”、“频繁第一”或“长尾”执行策略。

在第一方面的又一种可能的实现方式中，该装置还包括故障库或数据库，故障库或数据库包括多个不同故障类型，并且故障注入器还用于根据执行计划从故障库中选择至少一个故障。

在第一方面的另一种可能的实现方式中，该跟踪观察器包括一个或多个通信库，用于采集关于多个处理节点的操作的执行的跟踪信息。

在第一方面的又一种可能的实现方式中，分布式系统的状态机的模型还定义了多个不同状态之间的多个转换概率。该装置可以用于通过计数分布式系统的多个不同状态的状态之间的转换的发生来估计这些转换概率。

在第一方面的又一种可能的实现方式中，该模型构建器还用于根据有向图或加权马尔可夫链生成分布式系统的状态机的模型。

在第一方面的又一种可能的实现方式中，模型构建器还用于当检测到新的状态时，更新分布式系统的状态机的模型。

在第一方面的又一种可能的实现方式中，故障注入器还用于根据执行计划将第一故障和第二故障注入分布式系统，其中，第一故障使分布式系统被设置为不同状态，并且其中，第二故障在不同状态下被注入。

在第一方面的又一种可能的实现方式中，该故障注入器还用于：

根据执行计划将多个故障注入分布式系统；

在达到指定的覆盖水平之后，终止执行计划的执行。

如本文所使用的，所指定的覆盖水平可以定义为操作已经覆盖的状态数量与状态机的模型的状态总数之间的比率(或百分比水平)。

在第一方面的又一种可能的实现方式中，在至少一个状态下待注入的故障的类型仅取决于分布式系统的当前状态、分布式系统的当前状态和一个或多个先前状态，或分布式系统的当前状态和一个或多个未来预测状态。

第二方面，提供了一种将故障注入分布式系统的方法。该方法包括以下步骤：采集关于分布式系统的多个处理节点的操作的执行的跟踪信息；根据跟踪信息生成分布式系统的状态机的模型，其中，分布式系统的状态机的模型定义了分布式系统的多个不同状态；根据分布式系统的状态机的模型生成执行计划，其中，对于分布式系统的多个不同状态中的至少一个状态，执行计划标识在至少一个状态下待注入的故障的类型；例如在操作的进一步执行期间将具有在执行计划中标识的类型的至少一个故障注入分布式系统。

根据本发明第二方面的故障注入方法可以由根据本发明的第一方面的故障注入装置执行。因此，根据本发明的第二方面的故障注入方法的进一步的特征直接来自根据本发明的第一方面的故障注入装置的功能以及上面和下面描述的其不同实现方式。

根据第三方面，提供了一种计算机程序产品，包括用于存储程序代码的非瞬时性计算机可读存储介质，当程序代码由计算机或处理器执行时，程序代码使计算机或处理器执行根据第二方面的方法。

以下附图和说明书详细阐述了一个或多个实施例。其它特征、目的和优点在说明书、附图以及权利要求中是显而易见的。

附图说明

下面结合附图对本发明实施例进行详细描述。

图1是根据实施例的三种传统故障注入方法以及由故障注入装置实现的故障注入过程的示意图。

图2是根据实施例的用于将故障注入分布式系统的故障注入装置的示意图。

图3是根据实施例的用于将故障注入分布式系统的方法的不同步骤的流程图。

图4是根据实施例的故障注入装置的组件在学习阶段与分布式系统之间的交互的信令图。

图5是根据实施例的故障注入装置的组件在执行阶段与分布式系统之间的交互的信令图。

图6是由分布式系统的两个处理节点执行的示例性操作的示意图。

图7是示出根据实施例的用于将故障注入分布式系统的故障注入装置的方面的示意图。

图8示出了根据实施例的故障注入装置的模型构建器组件的方面的示意图。

图9示出了根据实施例的故障注入装置的模型构建器组件的方面的示意图。

图10是根据实施例的用于将故障注入分布式系统的装置的方面的示意图。

图11是根据实施例的用于将故障注入分布式系统的方法的流程图。

在下文中，相同的附图标记是指相同或至少在功能上等效的特征。

具体实施方式

在以下描述中，参考构成本发明一部分的附图，附图通过说明的方式示出了本发明实施例的具体方面或可以使用本发明实施例的具体方面。应当理解，本发明的实施例可以用于其它方面，并且包括未在附图中描绘的结构上或逻辑上的变化。因此，以下具体实施方式不应以限制性的意义来理解，并且本发明的范围由所附权利要求书限定。

例如，应当理解的是，与描述方法有关的公开内容可以对用于执行方法的对应设备或系统也同样适用，反之亦然。例如，如果描述了一个或多个具体的方法步骤，则对应的设备可以包括一个或多个单元，例如用于执行所描述的一个或多个方法步骤的功能单元(例如，执行一个或多个步骤的一个单元；或者多个单元，每个单元执行多个步骤中的一个或多个)，即使这样的一个或多个单元在附图中未明确描述或示出时也是如此。此外，例如，如果一个或多个单元(例如功能单元)来描述具体装置，则对应的方法可以包括用于执行一个或多个单元的功能的一个步骤(例如执行一个或多个单元的功能的一个步骤；或多个步骤，每个步骤执行多个单元中的一个或多个单元的功能)，即使这样的一个或多个步骤在附图中未明确描述或示出时也是如此。此外，应当理解的是，除非另外明确说明，本文中描述的各种示例性实施例和/或方面的特征可以相互组合。

在下文中，将在用于介绍详细实施例的示例性故障注入场景的上下文中描述一些背景材料。在该示例性故障注入场景中，评估以下示例性代码对服务A与B之间发生的通信故障的恢复能力：

#服务A

服务A具有函数A.getObjByName(name)，其根据名称查询对象。服务B提供：函数B.search(name)，其支持根据名称搜索对象id；函数B.getObject(ObjId)，其支持根据id查询对象。可靠性测试可以通过阻止服务A与B之间的连接来模拟故障。例如，通过禁用提供服务A和B的组件之间的网络交换机来阻止。在这个具体示例中，注入分布式系统的故障对应于禁用交换机。故障可能会给分布式系统带来多种形式的中断，例如进程终止、进程减慢或网卡中的数据包丢失。对于该示例，有两种场景(代码路径)需要测试。如果在执行的早期阶段禁用了交换机，则对B.search(ObjId)的调用可能会失败，异常将产生，并通过返回空值来正确处理。如果在执行B.search(ObjId)之后和B.getObject(ObjId)开始执行之前禁用交换机，则函数A.getObjByName(name)可能无法处理可能导致整个应用程序崩溃的错误。

为了测试这种示例性故障注入场景的可靠性，可以使用以下描述的三种故障注入方法中的一种。

在传统的白盒方法中，必须更改分布式系统的源代码，以添加钩子(hook)来触发交换机故障。新函数可以放在B.search(name)之前和B.getObject(ObjId)之前，以标记待注入故障的精确状态。这种传统的白盒方法有两个主要限制：(1)需要更改源代码，这通常是成本高昂的；(2)标记故障应注入位置的状态需要根据关于分布式系统的信息提前知道，该信息并不总是现成的。

第二种传统故障注入方法被称为混沌工程。它由在随机的时刻将故障注入分布式系统的随机组件组成。这种方法很容易应用于作为黑盒的任何分布式系统，但由于分布式系统的状态通常是未知的，所以注入精度较低。此外，其重现性也较低，因为每次注入故障时，系统可能处于不同的状态。

在被称为基于时间的故障注入的第三种传统故障注入方法中，观察分布式系统的状态，并且当达到需要注入故障的预定义状态之前的状态时，使用时间模型来计算何时应该注入故障。虽然这种方法因将分布式系统视为黑盒而很容易实现，但使用概率时间模型可能需要许多实验，直到故障在所需的状态下被注入。

图1示出了以上所描述的三种传统的故障注入方法，即图1左上角具有高精度、高再现性和高成本的白盒故障注入方法，右上角具有低精度、低再现性和低成本的混沌故障注入方法，以及左下角的具有中等精度、中等重现性和低成本的基于时间的故障注入方法。另一种故障注入方法，本文称为基于模型的故障注入方法，通过本发明的实施例实现，并在图1的右下角示出。该方法具有以下主要特点：高精度、高再现性、低实现成本。如下面将更详细地描述的，本发明的实施例采用分布式跟踪基础设施和跟踪检测点，这些基础设施和跟踪检测点被重用来标识分布式系统的重要状态。使用分布式跟踪可以通过观察分布式系统的状态来自动创建分布式系统的运行时模型。故障类型可以根据分布式系统的当前状态自动选择。分布式系统在故障注入期间可能会暂停，以确保其保持在所需的状态。

本发明的实施例可以用于分析由分布式系统提供的外部操作的可靠性(例如，对于基础设施即服务(infrastructure as a service，IaaS)，其可以是例如启动新虚拟机的操作)。典型的分布式系统由多个组件组成，即服务等处理节点。在一个实施例中，通信库可以用于实现分布式跟踪技术。这支持捕获分布式系统组件之间的调用，例如对数据库的RPC调用或SQL查询。通常，存在的检测点越多，故障注入就越精确。检测点支持跟踪操作的执行的当前状态。如本文所使用的，检测是程序代码被扩展以捕获状态信息的过程。分布式跟踪检测是向跟踪库添加一个调用，其中，库负责表示状态(即它可以捕获堆栈状态和请求变量)。检测点是代码中调用跟踪库的特定位置。

实现跟踪技术的通信库(本文也称为跟踪库)可以用于从检测点进行外部同步调用。调用可以包括明确表示分布式系统内的执行的属性。例如，属性可以包括运行代码的计算机的地址、分布式系统的组件的名称、远程过程调用或HTTP端点的名称。通常，属性集可能取决于分布式系统的架构，例如，在基于容器的环境中，它也可能指容器或pod。

图2示出了根据实施例的用于将故障注入分布式系统230的装置200的架构的示意图。分布式系统230包括多个处理节点，即用于执行操作的组件。如图2所示，多个处理节点定义分布式系统230的基础设施233，其还可以包括应用编程接口(applicationprogramming interfac，API)231以及分布式跟踪框架235，具体是用于在分布式系统230的基础设施233内执行跟踪操作的分布式跟踪库235。如下面将更详细地描述的，图2中的实线示出了在学习和执行阶段故障注入装置200的模块之间的交互，而虚线仅示出了执行阶段的交互。

故障注入装置200包括跟踪观察器和通知器215，通知器215用于例如通过从分布式系统230的分布式跟踪框架235获得关于跟踪事件的信息来采集关于分布式系统230的多个处理节点233的操作执行的跟踪信息。在一个实施例中，跟踪信息可以包括关于分布式系统230的多个处理节点的操作的执行的顺序的信息。在一个实施例中，跟踪观察器和通知器215可以包括一个或多个通信库，以用于采集关于分布式系统230的多个处理节点的操作的执行的跟踪信息。

此外，故障注入装置200包括模型构建器207，该模型构建器207用于根据由跟踪观察器和通知器215采集的跟踪信息生成分布式系统230(即分布式系统230的多个处理节点233)的状态机的模型(也称为“执行模型”)，如将在下面进一步详细地描述的。分布式系统230的状态机的模型定义了分布式系统230的多个不同状态。在一个实施例中，分布式系统230的状态机模型还可以定义分布式系统的多个不同状态之间的多个转换概率。如下面将更详细地描述的，在一个实施例中，模型构建器207可以用于根据有向图或加权马尔可夫链生成分布式系统的状态机模型。此外，例如当检测到新状态时，模型构建器207可以用于根据进一步的跟踪信息更新分布式系统230的状态机的现有模型。

装置200还包括计划引擎205，用于基于由模型构建器207生成的分布式系统230的状态机的模型生成执行计划。如下面将进一步详细地描述的，对于由分布式系统230的状态机的模型定义的分布式系统的多个不同状态中的至少一个状态，执行计划标识待在该状态下注入的故障类型。故障类型可以取决于分布式系统230的当前状态、分布式系统230的当前状态和一个或多个先前状态，或分布式系统230的当前状态和一个或多个未来预测状态。计划引擎205可以用于生成和管理多个不同的执行计划。

此外，如图2所示，装置200包括故障注入器211，该故障注入器211用于根据由计划引擎205生成的执行计划将至少一个故障注入分布式系统230。在一个实施例中，故障注入器211用于按顺序或基于状态概率的顺序注入由执行计划标识的多个故障。在一个实施例中，故障注入器211用于根据执行计划将第一故障和第二故障注入分布式系统230，其中，第一故障的注入使分布式系统230进入不同状态，第二故障在不同的状态下注入。在一个实施例中，故障注入器211用于根据执行计划将多个故障注入分布式系统230，其中，故障注入器211用于在达到指定的覆盖水平之后，终止执行计划的执行。如本文所使用的，所指定的覆盖水平可以定义为操作已经覆盖的状态数量与分布式系统的状态机的模型的状态总数之间的比率(或百分比水平)。

在图2所示的实施例中，故障注入装置200还包括用户界面201，用于使用户220能够指定要通过故障注入分析的分布式系统230的操作及其参数。此外，用户界面201可以用于显示或提供关于故障注入的结果的最终评估报告。

故障注入装置200还可以包括操作适配器213，操作适配器213用于创建跟踪上下文并调用分布式系统230的外部API 231，如下面将更详细地描述的。

如图2所示，故障注入装置200还可以包括断点管理器209，用于处理断点并在断点被触发时调用故障注入器211。更具体地，断点管理器209可以用于在由执行计划标识的分布式系统230的多个不同状态中的至少一个状态下设置断点，其中，故障注入器211用于在多个处理节点233的操作的执行期间达到断点时，将至少一个故障注入分布式系统230。如下面将更详细地描述的，在一个实施例中，断点管理器209还可以用于在至少一个故障被故障注入器注入分布式系统230时阻止任何进一步的状态转换。

在一个实施例中，故障注入装置200还可以包括故障库203，该故障库203包括多种不同的故障类型，即故障动作或操作，其中，故障注入器211用于根据由计划引擎205生成的执行计划从故障库203中选择待注入分布式系统230的至少一个故障。

图3是从高级角度示出的根据实施例的由装置200的不同组件执行的用于将故障注入分布式系统230的过程的主要步骤300的流程图：

步骤301-模型引导：根据来自用户220的输入(例如，用户220可以通过用户界面201指定要评估分布式系统230的可靠性的操作，即测试)，执行模型引导(即分布式系统230的状态机的(初始)模型被引导)，并生成(初始)执行计划(即操作被执行“引导迭代”次)。模型是根据观察到的轨迹构建的。执行计划是从模型推导的，它可以由语句组成。

步骤303-执行计划：执行计划通过执行计划定义的语句来处理，例如从执行计划中一个接一个地选择语句。对于每个语句，可以检索状态，并可以为状态设置断点(例如在状态Sb下设置断点)。

步骤305-执行操作：正在分析的分布式系统230的操作(如用户220指定的)由分布式系统230的多个处理节点233执行。

步骤307-观察状态：由跟踪观察器和通知器215观察(即采集)由分布式系统230生成的轨迹。每当观察到新状态时，模型和/或执行计划都可以更新。

步骤309：采集跟踪观察，直到分布式系统230达到在步骤303中断点定义的状态Sb。

步骤311-注入故障：当达到断点定义的状态时，执行计划中的语句指定的故障Fj被注入分布式系统230。进行观察，直到操作完成(步骤313)。

步骤315-采集结果：采集操作执行的结果。继续执行计划的执行，直到它完成或直到达到所请求的覆盖目标(步骤317)，如将在下面进一步详细描述的。

步骤319–生成报告：创建由在不同故障下执行分布式系统230的操作的所有结果组成的报告，并可以通过用户界面201提供给用户220。

图4和图5更详细地示出了上述在图3的上下文中描述的由故障注入装置200的不同组件或模块执行的步骤，即在“学习阶段”或“模型构建阶段”(图4)和“执行阶段”(图5)中。

更具体地，在图4所示的“学习阶段”或“模型构建阶段”中，装置200的不同组件用于执行以下步骤，这些步骤至少部分地已经在上面图2和图3的上下文中描述：

步骤401：用户界面201将关于待分析(即测试)的操作的信息转发到计划引擎205。

步骤403：计划引擎205生成用于待测试的操作的执行计划，并将其提供给操作适配器213。

步骤405：操作适配器213定义跟踪标识符(“Trace id”)，并将跟踪标识符提供给跟踪观察器和通知器215，以用于使用该跟踪标识符采集跟踪信息。

步骤407：操作适配器213向分布式系统230提供操作和关联的跟踪标识符。

步骤408：该操作由分布式系统230执行。

步骤409：在操作执行期间，使用分布式跟踪库235的分布式系统230生成跟踪事件。这些跟踪事件由跟踪观察器和通知器215采集，并作为跟踪对象存储在存储器中。

步骤411：操作的结果由操作适配器213记录。

步骤413：由跟踪观察器和通知器215采集的跟踪对象被转发到模型构建器207，在模型构建器207中，跟踪对象用于生成分布式系统的状态机模型。

步骤415：该模型可以用于计划引擎205，计划引擎205使用它来生成执行计划。

步骤417：为用户界面201创建具有学习阶段结果的报告。

在图5所示的“执行阶段”中(在图4所示的“学习阶段”之后)，装置200的不同组件用于执行以下步骤，这些步骤至少部分地已经在上面图2和图3的上下文中描述：

步骤501：用户界面201将关于待分析(即测试)的操作的信息转发到计划引擎205。

步骤503：计划引擎205拾取执行计划的下一步，并指示断点管理器209设置断点。断点可以被指定为分布式系统230必须处于的目标状态。

步骤505：计划引擎205将待执行的操作提供给操作适配器213。

步骤507：操作适配器213定义跟踪标识符(“Trace id”)，并将跟踪标识符提供给跟踪观察器和通知器215，以用于使用该跟踪标识符采集跟踪信息。

步骤509：操作适配器213向分布式系统230提供操作和关联的跟踪标识符。

步骤510：该操作由分布式系统230执行。

步骤511：在操作执行期间，使用分布式跟踪库235的分布式系统230生成跟踪事件。它们由跟踪观察器和通知器215采集，并作为跟踪对象存储在存储器中。

步骤513：跟踪观察器和通知器215根据来自跟踪事件的信息(如已经描述的)确定状态。该状态被转发到断点管理器209进行评估。

步骤514：断点管理器209检测到断点。

步骤515：在步骤514中检测到断点之后，断点管理器209将待注入分布式系统230的故障的故障参数提供给故障注入器211。

步骤517：根据在步骤515中由断点管理器209提供的故障参数，故障注入器211将故障注入分布式系统230。

步骤519：与步骤511类似，不同之处在于，跟踪观察器和通知器215保留在注入故障之后观察到事件的信息，因此它可能是由故障引起的。

步骤521：与步骤513相同(当存在链式故障注入并且断点管理器209设置了一个附加的断点时，需要该步骤)。

步骤523：操作结果由操作适配器213记录。

步骤525：跟踪被转发到模型构建器207，这可能导致模型更新(例如，可以观察到新状态或可以改变状态的权重)。

步骤527：计划引擎205可以根据来自模型构建器207的更新模型更新执行计划。

步骤529：操作的输出被记录，并与执行计划中的当前步骤关联。

步骤531：执行计划和操作结果被组合在可以通过用户界面201呈现给用户的报告中。

如将理解的，故障注入装置200的实施例实现了用于分布式系统230的可靠性测试的基于模型的方法，该方法适用于包括现代微服务架构的广泛分布式应用。在下文中，将更详细地描述故障注入装置200的一些其它实施例。

在一个实施例中，待由故障注入装置200测试的分布式系统230的操作(operation，Op)可以是具有一组参数(例如“GET/v2/servers”)的HTTP请求，或可以是使用SDK函数的代码段，例如openstacksdk。为了简单起见，并以非限制性的方式，在以下示例中，考虑了不需要在调用前后执行设置/拆除阶段的幂等函数。对于非幂等函数，可能需要在发出操作之前/之后执行的附加代码。

在一个示例性实施例中，故障注入装置200可以用于检查OpenStack VM创建操作的可靠性。如以上所描述，待注入的故障集可以预先配置在可以针对分布式系统230执行的动作的库中，例如某个服务的重启或中断的网络连接。

在一个实施例中，可以指定故障参数，例如引导迭代、链式故障级别和/或覆盖目标。引导迭代指示将重复多少次操作来创建分布式系统230的初始状态机模型。值越高，状态概率估计的精度越高。定义链接故障级别指示支持多少级别的链式故障。链支持处理级联故障注入，例如第一故障注入将分布式系统230变成新状态，而这个新状态反过来也可以受到另一个故障注入。定义覆盖目标支持运行执行计划，直到达到指定的覆盖目标。该选项支持跳过不太可能的状态，以减少总体执行时间。下表1给出了这些类型的故障参数(其可以通过故障注入装置200的用户界面201定义)的示例。

表1：经由故障注入装置的用户界面的示例性输入

下表2示出了根据实施例的故障注入装置200在执行图3所示的步骤之后生成的输出报告。表2列出了执行的操作、注入故障的状态、状态发生的估计概率、注入的故障的列表，以及它们是否影响分布式系统230的操作的正确执行。

表2：由故障注入装置生成的示例性报告

所选择的操作(即分布式系统230的待测试的操作)由用户界面201提供给计划引擎205。如以上所描述，计划引擎205负责协调故障注入循环。其执行由执行计划定义的与分布式系统230一起执行的动作序列。

最初，计划引擎205可能不知道关于分布式系统230的任何信息。在一个实施例中，为了获得该信息，计划引擎205执行待测试的操作，并等待模型构建器207创建分布式系统230的模型。如以上所描述，由模型构建器207生成的模型表示分布式系统状态机的观察，其具有状态之间转换的估计概率。故障注入装置200可以用于多次重复执行待测试的操作。在一个实施例中，这可以通过参数“引导迭代”来控制。

在分布式系统230的状态机的模型已经由模型构建器207生成之后，计划引擎205根据状态机的模型生成执行计划。例如，在引导阶段结束之后，计划引擎205可以用于使用类似以下语句的语句将分布式系统230的状态机的模型转换为执行计划：

EXEC OPERATIONON STATEINJECT FAULT，

其中，line表示唯一的语句编号，Op表示待测试的操作，Si表示分布式系统230的状态，Fj表示待注入的故障。在一个实施例中，分布式系统230的状态Si表示分布式轨迹中的特定点。它可以包括分布式系统230的处理节点(即组件)的名称、处理节点内的功能等。在一个实施例中，每个状态正好属于分布式系统230的一个处理节点，但每个处理节点可以具有许多状态。在一个实施例中，状态不取决于运行时属性，例如进程id(process id，PID)或主机名。故障参数Fj可以是对故障注入装置200的故障库203中定义的函数的参考。在一个实施例中，故障注入装置200可以用于使用具有对分布式系统230的远程调用的脚本来实现故障Fj。

图6示出了示例性分布式系统230的两个处理节点C

当执行计划包括多个语句时，可以通过以下执行策略中的一个控制语句的执行顺序：(i)顺序执行，其中，执行计划的语句逐个执行；(ii)频繁第一执行，其中，与分布式系统230的最频繁状态对应的执行计划的语句首先执行(在一个实施例中，当达到一定的覆盖目标时，该过程可以停止)；(iii)长尾执行，其中，首先执行对应于非频繁状态的执行计划的语句，从而支持测试分布式系统230的较不可能的状态。

在一个实施例中，由计划引擎205生成的执行计划可以实现为优先级队列，其中，顺序由执行策略指定，如图7所示。

在一个实施例中，故障注入装置200执行执行计划的单个语句可以包括以下步骤中的一个或多个：(i)断点管理器209使用故障处理程序Fj为状态Si配置新的断点；(ii)操作Op被发送到操作适配器213，操作适配器213将等待，直到操作完成；(iii)断点管理器209清除断点；和(iv)结果被转发到用户界面201。

在一个实施例中，处理执行计划的结果可以以表格形式呈现，如下表3所示，其中，每行都具有以下属性：操作-所分析的操作Op；状态-故障注入的状态Si；估计状态概率(％)-观察到状态的跟踪的百分比；注入的故障-注入的故障；操作结果-操作是否成功的指示。

表3：由故障注入装置生成的示例性报告

在一个实施例中，语句可以将故障与分布式系统230的一个且仅一个状态关联。但是，故障也可能与若干状态关联。例如，如果分布式系统230处于状态A，并且下一个状态是B(观察到的概率PB)，则通常希望在分布式系统230仍处于状态A的时将故障注入与状态B关联的处理节点。下表4示出了根据实施例的故障注入装置200实现的各种类型的语句。

表4：故障注入装置实现的不同类型的语句

在一个实施例中，执行计划的大小可以与分布式系统230的状态数量乘以存储在故障库203中的故障数成正比。由于非常大的执行计划可能需要很长的时间来处理，因此故障注入装置200可以用于在一定的覆盖水平达到时停止处理执行计划。下表5示出了根据实施例的故障注入装置200实现的覆盖函数(其中，“#断点状态”表示用作断点的状态数量，“#状态”表示分布式系统230的模型的状态总数)。

表5：故障注入装置实现的不同覆盖功能

如以上所描述，故障注入装置200的操作适配器213主要负责与分布式系统230通信，具体是用于错误处理和采集执行结果。每次待测试的操作Op由分布式系统230执行时，操作适配器213可以用于将其与唯一跟踪id(trace id，TID)关联，例如，表示64或128位整数的十六进制字符串。跟踪id支持故障注入装置200将跟踪事件与分布式系统230的操作的执行关联。这可以是有利的，因为分布式系统230可以具有并行运行的多个操作，其中，每个操作可以产生不同的跟踪事件，但将具有唯一的跟踪标识符。

待测试的操作可以是同步的，也可以是异步的。在后一种情况下，分布式系统230可以指示操作被接受，但其处理将在后台继续。例如，OpenStack VM创建操作是异步的，用户只在创建数据库对象之后接收到回复，但VM的生成和网络管道可能需要几秒钟的时间。为了处理异步操作，当在预定义的时间间隔内没有接收到更多的新事件时，故障注入装置200用于将待测试的操作处理为完成。在一个实施例中，待测试的操作和操作适配器213可以同步操作。当操作Op完成时，操作适配器213可以将结果报告给用户界面201。

在操作Op的执行期间，分布式系统230的检测点沿着执行路径发射跟踪事件。每个事件都具有一组属性，描述检测点的位置和执行参数。属性可以分为以下四类中的一类：(i)静态–标识代码位置(例如，组件/函数名称、RPC或DB SQL语句)；运行时–捕获运行时信息(例如，PID、容器标识符或主机名)；(iii)结构–描述跟踪事件在跟踪中的位置(例如，对调用者的参考)；和(iv)定时–指示生成跟踪事件的时间(例如，时间戳)。

示例性跟踪事件可以如下所示：

在该示例中，静态属性为“service”和“functionName”，运行时属性为“host”和“pid”，结构属性为“traceId”、“eventId”和“parentId”，定时属性为“timestamp”。与同一操作对应的跟踪事件可以分组到跟踪对象中。在一个实施例中，从数据结构的角度来看，跟踪可以被表示为具有由属性parentId和eventId设置的父子关系的树。

根据静态属性，跟踪观察器和通知器215可以用于生成状态ID。例如，通过以以下方式使用级联和哈希函数：

def get_state(event):

return hash(event[‘component’]+‘--‘+event[‘functionName’])

跟踪观察器和通知器215可以用于持久从事件到状态ID的映射。映射可以用于查找对应于事件父级的状态。

图8示出了跟踪观察器和通知器215如何用于将事件映射到相同代码段的状态的示例，例如以下代码段：

Def A.getXY(idX,idY):

X＝B.getObject(idX)

Y＝B.getObject(idY)

Return X,Y

图8示出了两种情况，即代码顺序地执行时的情况(图8的左侧)和代码并行地执行时的情况(图8的中间)。在该示例中，四对事件映射到四种状态，因为同一函数被调用两次。

对于观察到的每个跟踪事件，跟踪观察器和通知器215可以用于执行以下动作中的一个或多个：(i)生成状态ID并将事件更新为状态ID映射；(ii)将状态ID和事件的运行时属性发送到断点管理器209；和(iii)将状态ID和对先前状态ID的参考发送到模型构建器207。

如以上所描述，故障注入装置200的模型构建器207用于通过其由一组状态S

Pr(S

马尔可夫链也可以表示为有向图，其中，当从状态S

Pr(S

在一个实施例中，状态的概率可以用于对执行计划的语句进行排序。

在一个实施例中，故障注入装置200的模型构建器207最初可以从分布式系统230的状态机的空模型开始。在执行待测试的操作期间，跟踪观察器和通知器215将相应的观察状态S

图9示出了根据实施例的故障注入装置200生成的轨迹和对应的模型的进一步的示例。在图9所示的示例中，底层分布式系统230包括三个处理节点，即组件C1、C2和C3，其中，C1总是向C2发送请求，C2从C3查询数据，但将该数据存储在内存缓存中一段时间。在处理节点之间的边界处存在检测点，因此可以知道处理节点何时即将发送请求以及何时接收请求。由于来自C3的数据缓存在C2中，因此从C2到C3的请求并不总是发生。图9的最左侧示出了缓存的效果(C2从内存返回数据，不查询C3)。检索数据的情况如图9的中间所示(C2从C3查询结果并将其存储在内存中)。根据一个实施例，处理节点C1、C2和C3之间的通信可以由模型构建器207使用示出为有向加权图的马尔可夫链建模(如图9的右侧所示，即对应于组件C1、C2和C3之间的通信的马尔可夫链建模的有向加权图)。假设缓存在90％的情况下包括所请求的数据，则边缘S2->S7的权重为0.9，边缘S2->S3的权重为0.1。

当执行计划的语句已经完成时，发现的新状态可以更新由模型构建器207生成的模型，或旧状态可以更新它们的概率。当观察到新的状态S

如以上所描述，对于每个语句，计划引擎205可以指示断点管理器209在具有故障F

INJECT FAULT

因此，故障注入器211通常负责执行故障动作。在一个实施例中，故障注入器211可以用于查询故障库203以找到可以注入所需故障的特定动作(功能)。动作的实现可以取决于分布式系统230使用的技术，从普通的Bash脚本和SSH到基于代理的攻略。每个函数都可以接受一组运行时属性，描述在哪里注入错误。例如，当故障将注入进程时，它可以是PID；当服务在容器环境中执行时，它可以是容器id；或用于基于网络的故障的网卡或端口。

以下示例说明了使用主机id和PID阻止防火墙的故障的实现方式：

def interrupt_connection(host,pid):

firewall_block(host,find_connection(host,pid))

根据一个实施例，故障注入装置200可以用于使用(即注入)影响分布式系统230的处理节点的以下故障和故障类型中的一个或多个：(i)执行失败，例如进程异常终止、进程重启、进程挂起等；(ii)系统资源故障，例如磁盘空间问题、高利用率等；(iii)网络故障，例如丢包、连接丢失、消息传输问题等；

与先前故障类型相关的功能示例可以包括：(i)low_disk(host)–在特定主机上引发低磁盘条件，即处理节点；(ii)pause_process(host,pid)–在特定主机上模拟具有PID的挂起进程，即处理节点；和(iii)reject_connection(host1,pid1,host2,[pid2,port1,port2])–触发在不同主机上运行的进程之间的连接故障，即分布式系统230的处理节点。

在故障被注入之后，故障注入器211将处理转移到断点管理器209。由于服务处于暂停状态，因此应尽快注入故障。如果是基于代理的注入器，延迟可能在毫秒的范围内。

最初，执行计划可能包括只有一个故障的一个或多个语句。然而，故障的注入可以显示分布式系统230的新状态的存在。例如，在具有两个处理节点(即组件C

#组件C1

10error＝query_C2(token)

20if error！＝0then

30token＝renew_token()

40goto 10

将故障F1注入函数query_C2会暴露一个新的代码路径，即对函数renew_token的调用。为了评估这个新函数的可靠性，需要注入两个故障，即F

为了处理这些情况，模型构建器207可以用于将状态存储到分布式系统230的模型中，并具有到所得状态的链接。此外，模型构建器207可以用于用包括两个故障的新语句更新执行计划。在一个实施例中，装置200可以用于限制故障链的级别，因为每个下一个故障级别的全覆盖可能具有指数增加的成本。

图11是用于将故障注入分布式系统230的方法1100的流程图。方法1100包括以下步骤：

在1101中，采集关于分布式系统230的多个处理节点的操作的执行的跟踪信息；

在1103中，根据跟踪信息生成分布式系统230的状态机的模型，其中，分布式系统230的状态机的模型定义了分布式系统230的多个不同状态；

在1105中，根据分布式系统230的状态机的模型生成执行计划，其中，对于分布式系统230的多个不同状态中的至少一个状态，执行计划标识在至少一个状态下待注入的故障的类型；

在1107中，将具有在执行计划中标识的类型的至少一个故障注入分布式系统230。

本领域技术人员将理解，各种附图(方法和装置)中的“块”(“单元”)表示或描述本发明实施例的功能(而不一定是硬件或软件中的独立“单元”)，从而同等地描述装置实施例以及方法实施例的功能或特征(单元＝步骤)。

在本申请中提供的几个实施例中，应当理解，所公开的系统、装置和方法可以通过其它方式实现。例如，装置的所描述实施例仅仅是示例性的。例如，单元划分仅仅是一种逻辑功能划分，实际实现时可以有其它划分方式。例如，可以将多个单元或组件合并或集成到另一系统中，或者可以忽略或不执行一些特征。另外，所显示或描述的相互耦合或直接耦合或通信连接可以通过一些接口来实现。装置或单元之间的直接耦合或通信连接可通过电子、机械或其它形式实现。

作为分离部件描述的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，可以位于一个位置上，或者可以分布在多个网络单元上。可以根据实际需要选择一些或全部单元来实现实施例方案的目的。

另外，本发明的实施例中的功能单元可集成到一个处理单元中，或每个单元可物理上单独存在，或两个或更多单元可集成到一个单元中。