CN110673993A - 一种故障注入方法、平台及系统 - Google Patents

Abstract

本申请实施例提供一种故障注入方法、平台及系统，涉及故障注入技术领域。该故障注入方法包括获取用户输入的故障注入信息；根据故障注入信息生成变更申请单，并将变更申请单发送给管理子系统，等待审核；接收管理子系统发送的审核结果，并将审核结果发送给用户；如果审核结果指示审核通过，则根据用户指令获取故障信息，并将故障信息注入被测试对象。本申请实施例提供的故障注入方法、平台及系统，能够对故障注入的全过程进监管和控制，不仅具有自动化、流程化、规范化的特定，而且能够减少甚至避免故障测试过程中对被测试对象造成的损害。

Description

一种故障注入方法、平台及系统

技术领域

本申请涉及故障注入技术领域，尤其涉及一种故障注入方法、平台及系统。

背景技术

随着分布式系统和微服务的兴起，系统架构变的越来越复杂，系统故障变的难以预测，传统的单元测试和集成测试已经无法完全覆盖日益复杂的软件架构。因此，需要通过故障注入去主动测量系统的弹性和健壮性，以建立系统抵御失控条件的能力。

目前，在故障注入过程中，用户通常会直接将编写的故障信息注入被测试对象。由于故障注入是在正常的系统中注入故障信息，因此，故障注入操作本身具有一定的风险性。然而，现有的故障测试过程，缺乏相应的监管和控制机制，难以保证故障测试过程中不对被测试对象造成损害。因此，亟待提供一种自动化、流程化、规范化的故障注入方法。

发明内容

本申请实施例提供了一种故障注入方法、平台及系统，用于解决现有故障测试过程，缺乏相应的监管和控制机制，易对被测试对象造成损害的问题。

第一方面，本申请实施例提供一种故障注入方法，应用于故障注入平台，所述方法包括：

获取用户输入的故障注入信息；

根据所述故障注入信息生成变更申请单，并将所述变更申请单发送给管理子系统，等待审核；

接收管理子系统发送的审核结果，并将审核结果发送给用户；

如果所述审核结果指示审核通过，则根据用户指令获取故障信息，并将所述故障信息注入被测试对象。

在第一方面的第一种实现方式中，所述方法还包括：实时从监控告警子系统获取并显示所述被测试对象的监控信息，其中，所述监控告警子系统用于监控所述被测试对象。

在第一方面的第二种实现方式中，根据用户指令获取故障信息，包括：获取用户输入的故障信息；或者，根据用户指令，从预设的故障信息库中调取对应的故障信息。

在第一方面的第三种实现方式中，所述故障注入信息包括：本次故障注入需要验证的假设、实验的发生组件、实验发生的范围、实验的具体操作、开始时间和结束时间。

第二方面，本申请实施例提供一种故障注入平台，包括：

获取模块，用于获取用户输入的故障注入信息；

转换模块，用于根据所述故障注入信息生成变更申请单；

通信模块，用于将所述变更申请单发送给管理子系统，等待审核；接收管理子系统发送的审核结果，以及，将所述审核结果发送给用户；

故障注入模块，用于如果所述审核结果指示审核通过，则根据用户指令获取故障信息，并将所述故障信息注入被测试对象。

在第二方面的第一种实现方式中，所述故障注入平台还包括：监控模块，用于实时从监控告警子系统获取并显示所述被测试对象的监控信息，其中，所述监控告警子系统用于监控所述被测试对象。

在第二方面的第二种实现方式中，所述获取模块具体用于获取用户输入的故障信息；或者，根据用户指令，从预设的故障信息库中调取对应的故障信息。

在第二方面的第三种实现方式中，所述故障注入信息包括：本次故障注入需要验证的假设、实验的发生组件、实验发生的范围、实验的具体操作、开始时间和结束时间。

第二方面，本申请实施例提供一种故障注入系统，包括如上述第二方面提供的故障注入平台，以及管理子系统；所述管理子系统，用于接收故障注入平台发送的变更申请单，并将所述变更申请单的审核结果发送给所述故障注入平台。

在第二方面的第一种实现方式中，所述的故障注入系统，还包括监控告警子系统，用于监控所述被测试对象。

本申请提供的技术方案包括以下有益技术效果：

本申请实施例提供的故障注入方法、平台及系统，能够对故障注入的全过程进监管和控制，不仅具有自动化、流程化、规范化的特定，而且能够减少甚至避免故障测试过程中对被测试对象造成的损害。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1中示例性示出了根据本实施例中的一种故障注入方法的流程图；

图2中示例性示出了根据本实施例中的一种故障注入平台的结构示意图；

图3中示例性示出了根据本实施例中的一种故障注入平台的结构示意图。

具体实施方式

为使本申请示例性实施例的目的、技术方案和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施例中的技术方案进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

故障注入包括基于硬件的故障注入和基于软件的故障注入。其中，基于硬件的故障注入是在物理级完成的，通过改变硬件的环境参数(如电磁干扰、电源干扰等)，或者通过改变集成电路芯片管脚输入等方式来达到故障注入的效果。而基于软件的故障注入，是通过在软件级生成错误，从而造成硬件级的故障。例如，通过修改内存数据造成系统故障。

本申请实施例提供一种基于软件的故障注入方法，该方法应用于UFIP(UnifiedFault injectionPlatform，统一故障注入平台)，通过统一故障注入平台将故障信息注入容器云、业务服务器等承载具体业务的基础硬件设施，以对其所搭载的具体软件(例如视频播放应用)进行测试。具体可以用于测试IASS(Infrastructure-as-a-Service，基础设施即服务)、PASS(Platform-as-a-Service，平台即服务)和SAAS(Software-as-a-Service，软件即服务)等多个层面的软件。

请参阅图1，本申请实施例提供的故障注入方法具体包括如下步骤S101-S110。

步骤S101，根据用户名和密码，登录统一故障注入平台。

由于故障注入是要将故障信息主动注入到被测试对象中，以测量被测试对象的弹性和健壮性，具有一定的风险性。因此，在一些实施例中，统一故障注入平台上设置有使用权限，能够根据每个用户(如运维工程师)的权限，实现分权分域管理。用户需要根据特定的用户名和密码登录之后才能正常使用，其中该特定的用户名为授权登录的用户名，该密码为与该用户名匹配的密码。

具体地，统一故障注入平台在获取到用户输入的用户名和密码之后，会将其与预设的用户信息表进行比较，该用户信息表中存储有所有授权登录的用户名，以及与这些用户名一一对应的密码。如果统一故障注入平台在用户信息表中查找到用户输入的用户名和密码，则认为鉴权通过，登录成功。

在另一些实施例中，该统一故障注入平台没有权限设置，任何用户不执行步骤S101都可以直接进入统一故障注入平台，执行故障注入的相关操作。

步骤S102，统一故障注入平台获取用户输入的故障注入信息。

用户进入统一故障注入平台后，首先需要在主页面录入业务信息，随后点击Attack图标(即故障注入图标)即可进入故障注入申请页面。其中，业务信息包括IP信息、端口号等被测试对象的配置信息。其中，主页面是指登录统一故障注入平台之后，该平台首先显示的页面。

在故障注入申请页面，用户需要输入故障注入信息，示例性的，该故障注入信息可以包括：

a.本次故障注入的场景或需要验证的假设。例如，磁盘满会导致视频播放业务宕机。

b.实验的发生组件。例如，服务器、容器、应用框架等。

c.实验发生的范围，即实验所影响的机器或者集群等。

d.实验的具体操作。例如，磁盘满、网络异常、CPU(Central Processing Unit，中央处理器)满等。

e.开始时间和结束时间。开始时间和结束时间具体根据用户需求确定，例如，开始时间可以为2019年09月01日00:00，结束时间可以为2019年09月01日01:00。在开始时间和结束时间之间，用户可以执行故障注入操作。

步骤S103，统一故障注入平台根据故障注入信息生成变更申请单。

由于故障注入本身具有的风险性，每一次故障注入操作都需要得到上层管理人员的批准。因此，统一故障注入平台在获取到故障注入信息之后，会自动根据该故障注入信息生成变更申请单，该变更申请单中包括上述故障注入信息，主要用于审核人员对本次故障注入实验的可行性进行审核。

步骤S104，统一故障注入平台将变更申请单发送给管理子系统，等待审核。

在本实施例中，管理子系统用于对企业的各个IT(Information Technology，信息技术)系统进行管理，其中包括统一故障注入平台、监控告警子系统等。示例性的，该管理子系统可以为ITSM(IT Service Management，IT服务管理)系统。管理子系统在接收到变更申请单之后，将其存储于待处理列表中，等待审核人员审核。

步骤S105，统一故障注入平台接收管理子系统发送的审核结果。

审核人员通过管理子系统，能够对变更申请单中的故障注入信息进行审核，并将审核结果发送给统一故障注入平台。该审核结果包括审核通过和审核不通过两种情况。在一些实例中，无论该审核是否通过，管理子系统都会向统一故障注入平台发送本次故障注入信息的审核结果。

步骤S106，统一故障注入平台将审核结果发送给用户。

示例性的，每一个用户的账户信息中都包括用户的联系方式，例如电话号码、邮箱地址等。统一故障注入平台在接收到审核结果之后，可以通过短信、邮件等方式将审核结果发送给用户，以告知用户审核是否通过。

步骤S107，如果审核结果指示审核通过，则统一故障注入平台根据用户指令获取故障信息。

其中，故障信息是指用于控制被测试对象发生具体故障的信息，例如，控制被测试对象的磁盘满、CPU满、网络异常的信息。

如果审核通过，用户需要根据故障注入信息中约定的故障注入开始时间和结束时间内，例如2019年09月01日00:00-01:00之间，登录统一故障注入平台，将故障信息注入被测试对象。

在一种可能的实现方式中，用户可以直接在统一故障注入平台中输入或者导入故障信息。

在另一种可能的实现方式中，统一故障注入平台中预先设置有一个故障信息库，该故障信息库中存储有不同故障对应的故障信息。用户可以根据故障测试需求(即本次故障测试所需要验证的假设)，在故障注入界面中选择对应的故障。统一故障注入平台根据该故障，即可从故障信息库中调取对应的故障信息。

示例性的，故障信息库中的故障信息可以为：针对服务器的重启、关机，针对CPU的占用率增高20％、占用率增高50％、CPU满等，磁盘满等故障对应的故障信息，以及针对Kubernates的kill Pod方法。

以本次故障注入实验需要验证“磁盘满会导致视频播放业务宕机”为例，本次要注入的故障为：磁盘满。同一故障注入平台根据该故障，即可从故障信息库中调取使视频播放业务磁盘满的故障信息。

步骤S108，统一故障注入平台将故障信息注入被测试对象。

本实施例提供的统一故障注入平台中存储有可执行的多种技术组件和代码库。通过这些技术组件和代码库，统一故障注入平台能够与不同的被测试对象适配，并对其进行故障注入。

统一故障注入平台在进行故障注入时，首先需要向被测试对象发送一个故障注入请求，被测试对象在接收到故障注入请求之后，做好故障注入准备，并向统一故障注入平台发送一个响应消息。统一故障注入平台在接收到响应消息之后，便开始将故障信息发送至被测试对象。示例性的，故障注入平台可以通过一些开源的工具，例如Chaos Blade、ChaosToolkit、Kubemonkey等，执行故障注入操作。

步骤S109，统一故障注入平台实时从监控告警子系统获取并显示被测试对象的监控信息。

监控告警子系统能够对故障注入过程的全流程进行监控，例如CPU使用率、磁盘使用率等。此外，监控告警子系统还能够对被测试对象的健康情况进行评估，其中包括故障注入前、故障注入过程中以及故障注入之后的健康状况。

当统一故障注入平台通过监控告警子系统，监控到被测试对象存在意外或者紧急情况时，可以生成风险提示信息，例如，提示用户停止故障注入操作。故障注入平台内设有不同的应用程序接口和检测实现方式，以满足对不同的被测试对象的监控。

步骤S110，生成故障测试报告。

在故障注入结束之后，统一故障注入平台会自动生成故障测试报告，该故障测试报告包括：故障注入信息及故障测试结果。并且，该测试报告支持以Word、Excel等格式导出。

对于故障测试中发现的问题，统一故障注入平台会将其发送至研发系统，以便研发人员去研究解决该问题，形成“发现问题、分析问题和解决问题”的实验闭环。

此外，在本申请实施例提供的故障注入方法中，该故障注入平台还能够通过ELK(Elasticsearch、Logstash、Kibana)日记分析系统对本次故障注入进行全流程的日志记录，并将其存储以供后续使用。

故障注入平台还能够进行操作的回滚，对于故障注入过程中的程序或数据处理错误，将程序或数据恢复到上一次的正确状态。

本申请实施例提供的故障注入方法，能够对故障注入的全过程进监管和控制，不仅具有自动化、流程化、规范化的特定，而且能够减少甚至避免故障测试过程中对被测试对象造成的损害。

请参阅图2，本申请实施例提供的一种故障注入平台，用于执行上述本实施例提供的一种故障注入方法，该平台包括如下部件。

获取模块201，用于获取用户输入的故障注入信息。

转换模块202，用于根据故障注入信息生成变更申请单。

通信模块203，用于将变更申请单发送给管理子系统，等待审核；接收管理子系统发送的审核结果，以及，将审核结果发送给用户。

故障注入模块204，用于如果审核结果指示审核通过，则根据用户指令获取故障信息，并将故障信息注入被测试对象。

可选的，故障注入平台还包括监控模块205，用于实时从监控告警子系统获取并显示被测试对象的监控信息，其中，监控告警子系统用于监控被测试对象。

可选的，获取模块201具体用于获取用户输入的故障信息；或者，根据用户指令，从预设的故障信息库中调取对应的故障信息。

可选的，故障注入信息包括：本次故障注入需要验证的假设、实验的发生组件、实验发生的范围、实验的具体操作、开始时间和结束时间。

可选的，故障注入平台还包括报表生成模块206，用于在故障注入结束之后，自动生成故障测试报告。

可选的，故障注入平台还包括日志记录模块207，用于对本次故障注入进行全流程的日志记录，并将其存储以供后续使用。

可选的，故障注入平台还包括回滚模块208，用于将故障注入过程中错误的程序或数据恢复到上一次的正确状态。

本申请实施例提供的故障注入平台，能够对故障注入的全过程进监管和控制，不仅具有自动化、流程化、规范化的特定，而且能够减少甚至避免故障测试过程中对被测试对象造成的损害。

请参阅图3，本申请实施例还提供一种故障注入系统，包括上述本申请实施例提供的故障注入平台，以及管理子系统和监控告警子系统。其中，管理子系统用于接收故障注入平台发送的变更申请单，并将变更申请单的审核结果发送给故障注入平台。监控告警子系统，用于监控被测试对象。

本申请实施例提供的故障注入系统，能够对故障注入的全过程进监管和控制，不仅具有自动化、流程化、规范化的特定，而且能够减少甚至避免故障测试过程中对被测试对象造成的损害。

基于本申请中示出的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整技术方案。

应当理解，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

本申请中使用的术语“模块”，是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种故障注入方法，其特征在于，应用于故障注入平台，所述方法包括：

获取用户输入的故障注入信息；

根据所述故障注入信息生成变更申请单，并将所述变更申请单发送给管理子系统，等待审核；

接收管理子系统发送的审核结果，并将所述审核结果发送给用户；

如果所述审核结果指示审核通过，则根据用户指令获取故障信息，并将所述故障信息注入被测试对象。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

实时从监控告警子系统获取并显示所述被测试对象的监控信息，其中，所述监控告警子系统用于监控所述被测试对象。

3.根据权利要求1或2所述的方法，其特征在于，根据用户指令获取故障信息，包括：

获取用户输入的故障信息；或者，

根据用户指令，从预设的故障信息库中调取对应的故障信息。

4.根据权利要求1或2所述的方法，其特征在于，所述故障注入信息包括：本次故障注入需要验证的假设、实验的发生组件、实验发生的范围、实验的具体操作、开始时间和结束时间。

5.一种故障注入平台，其特征在于，包括：

获取模块，用于获取用户输入的故障注入信息；

转换模块，用于根据所述故障注入信息生成变更申请单；

通信模块，用于将所述变更申请单发送给管理子系统，等待审核；接收管理子系统发送的审核结果，以及，将所述审核结果发送给用户；

故障注入模块，用于如果所述审核结果指示审核通过，则根据用户指令获取故障信息，并将所述故障信息注入被测试对象。

6.根据权利要求5所述的故障注入平台，其特征在于，还包括：

监控模块，用于实时从监控告警子系统获取并显示所述被测试对象的监控信息，其中，所述监控告警子系统用于监控所述被测试对象。

7.根据权利要求5或6所述的故障注入平台，其特征在于，

所述获取模块，具体用于获取用户输入的故障信息；或者，根据用户指令，从预设的故障信息库中调取对应的故障信息。

8.根据权利要求5或6所述的故障注入平台，其特征在于，所述故障注入信息包括：本次故障注入需要验证的假设、实验的发生组件、实验发生的范围、实验的具体操作、开始时间和结束时间。

9.一种故障注入系统，包括如权利要求5-8任一项所述的故障注入平台，以及管理子系统；所述管理子系统，用于接收故障注入平台发送的变更申请单，并将所述变更申请单的审核结果发送给所述故障注入平台。

10.根据权利要求9所述的故障注入系统，其特征在于，还包括监控告警子系统，用于监控所述被测试对象。

Images