一种用于测试环境下的运维方法及装置

技术领域

本发明涉及计算机技术领域，特别是关于运维监控和自愈系统技术领域，具体涉及一种用于测试环境下的运维方法及装置。

背景技术

在现有技术中的环境运维领域，在大量测试和生产环境下，少量的维护人力无法主动发现环境出现的异常情况，往往需要业务发现服务异常通知运维人员手动排查，因此无法做到环境出现异常后的实时处理。另外，一个运维人员同一时间内只能处理一个异常问题，异常处理的效率不高，无法满足环境高可用性的要求。因此需要合适的自动化运维方法来提高环境可用率，减少人工维护成本。

现有的环境监控系统，在收集监控指标的环节上需要人工去服务器上部署监控模块，对于不同类型的测试环境，测试人员需要先知道测试环境的类型，然后选择对应的监控模块去部署。这样的手工操作一定程度上增加了运维人员的工作量，在大规模测试环境下，这个过程非常的耗时耗力。而且异常处理策略只支持一个自定义策略，无法满足复杂情况下的异常处理。

发明内容

根据本发明所提供的用于测试环境下的运维方法及装置，针对大规模、多类型的测试环境，可大大提高测试环境出现问题而自愈的成功率，并且减少运维人员因环境问题分析步骤。

为了实现上述目的，提供了一种用于测试环境下的运维方法，包括：

实时获取测试环境的节点类型信息；

根据所述节点类型信息判断所述测试环境是否正常；

如果不正常，根据预生成的分级自愈模型修复所述测试环境。

优选地，所述根据所述节点类型信息判断所述测试环境是否正常包括：

根据所述节点类型信息获取指标信息；

根据所述指标信息以及第一预设阈值判断所述测试环境是否正常。

优选地，所述指标信息包括：所述测试环境中服务器的中央处理器性能指标、内存指标、磁盘指标、操作系统指标、网络IO、文件系统IO指标、服务器可用性指标、数据库性能指标、端口进程存活指标以及镜像存活指标。

优选地，所述根据所述节点类型信息获取指标信息包括：

在指标数据库中，根据所述节点类型信息获取指标信息；所述指标数据库为时序数据库。

优选地，生成所述分级自愈模型的步骤包括：

判断所述测试环境中环境类型是否正常；

如果不正常，根据预设的环境类型修复方法对所述测试环境进行修复；

如果正常，查找所述测试环境中是否存在负载超过第二预设阈值的进程；

如果存在，根据预设的负载修复方法对所述测试环境进行修复；

如果不存在，判断所述测试环境中的多个服务器是否存在同一问题；

如果存在，根据预设的服务器修复方法对所述测试环境进行修复；

如果不存在，读取所述测试环境的日志信息中的报错信息；

根据所述报错信息对所述测试环境进行修复。

优选地，所述实时获取测试环境的节点类型信息包括：

通过配置管理数据库实时获取测试环境的节点类型信息。

第二方面，本发明提供一种用于测试环境下的运维装置，该装置包括：

信息获取单元，用于实时获取测试环境的节点类型信息；

环境判断单元，用于根据所述节点类型信息判断所述测试环境是否正常；

环境修复单元，用于根据预生成的分级自愈模型修复所述测试环境。

优选地，所述环境判断单元包括：

指标信息获取模块，用于根据所述节点类型信息获取指标信息；

环境判断模块，用于根据所述指标信息以及第一预设阈值判断所述测试环境是否正常；

所述指标信息包括：所述测试环境中服务器的中央处理器性能指标、内存指标、磁盘指标、操作系统指标、网络IO、文件系统IO指标、服务器可用性指标、数据库性能指标、端口进程存活指标以及镜像存活指标；

所述指标信息获取模块具体用于在指标数据库中，根据所述节点类型信息获取指标信息；所述指标数据库为时序数据库

用于测试环境下的运维装置还包括：模型生成模块，用于生成所述分级自愈模型，所述模型生成模块包括：

类型判断模块，用于判断所述测试环境中环境类型是否正常；

类型修复模块，用于根据预设的环境类型修复方法对所述测试环境进行修复；

进程查找模块，用于查找所述测试环境中是否存在负载超过第二预设阈值的进程；

进程修复模块，用于根据预设的负载修复方法对所述测试环境进行修复；

服务器判断模块，用于判断所述测试环境中的多个服务器是否存在同一问题；

服务器修复模块，用于根据预设的服务器修复方法对所述测试环境进行修复；

报错读取模块，用于读取所述测试环境的日志信息中的报错信息；

报错修复模块，用于根据所述报错信息对所述测试环境进行修复；

所述信息获取单元具体用于通过配置管理数据库实时获取测试环境的节点类型信息。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现用于测试环境下的运维方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现用于测试环境下的运维方法的步骤。

从上述描述可知，本发明实施例提供的用于测试环境下的运维方法及装置，首先实时获取测试环境的节点类型信息；接着，根据节点类型信息判断测试环境是否正常；如果不正常，根据预生成的分级自愈模型修复测试环境。针对大规模、多类型的测试环境，本发明可大大提高测试环境出现问题而自愈的成功率，并且减少运维人员因环境问题分析步骤。

附图说明

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

图1为本发明实施例中提供的用于测试环境下的运维方法的流程示意图一；

图2为本发明的实施例中用于测试环境下的运维方法步骤200的流程示意图；

图3为本发明的实施例中用于测试环境下的运维方法步骤201的流程示意图；

图4为本发明实施例中提供的用于测试环境下的运维方法的流程示意图二；

图5为本发明的实施例中用于测试环境下的运维方法步骤400的流程示意图；

图6为本发明的实施例中用于测试环境下的运维方法步骤100的流程示意图；

图7为本发明的具体应用实例中用于测试环境下的运维系统的结构示意图；

图8为本发明的具体应用实例中用于测试环境下的运维方法的流程示意图；

图9为本发明的具体应用实例中用于测试环境下的运维方法的思维流程图；

图10为本发明的具体应用实例中分级自愈策略流程示意图；

图11为本发明实施例中用于测试环境下的运维装置的结构示意图一；

图12为本发明实施例中环境判断单元的结构示意图；

图13为本发明实施例中用于测试环境下的运维装置的结构示意图二；

图14为本发明实施例中模型生成模块的结构示意图；

图15为本发明的实施例中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本发明的实施例提供一种用于测试环境下的运维方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：实时获取测试环境的节点类型信息。

可以理解的是，一套测试环境包括多个节点，环境节点分为不同的类型，包括应用服务器、Oracle数据库、Mysql数据库、批量服务器等。每个环境节点包含了该节点的类型信息、操作系统信息、服务器ip地址、服务器用户信息、类型要素信息等。

步骤200：根据所述节点类型信息判断所述测试环境是否正常。

具体地，根据节点类型信息，查询指标数据库中的环境指标，并根据设置的阈值判断环境是否正常可用。

步骤300：如果不正常，根据预生成的分级自愈模型修复所述测试环境。

参见背景技术，由于现有技术中，测试环境问题的种类较多，原因较复杂。用户自定义脚本无法满足特定问题的需求，步骤300采用一种分级自愈策略作为补充，使用此策略可以完成测试环境深度自愈。具体地，对于监控中发现的问题，采用分级策略完成测试环境深度自愈。策略支持配置、开关控制、自愈过程记录、过滤环境正常不可用、重复自愈、自愈后验证等功能。解决了大规模、多类型环境下的监控部署和处理异常问题。

从上述描述可知，本发明实施例提供的用于测试环境下的运维方法，首先实时获取测试环境的节点类型信息；接着，根据节点类型信息判断测试环境是否正常；如果不正常，根据预生成的分级自愈模型修复测试环境。针对大规模、多类型的测试环境，本发明可大大提高测试环境出现问题而自愈的成功率，并且减少运维人员因环境问题分析步骤。

一实施例中，参见图2，步骤200进一步包括：

步骤201：根据所述节点类型信息获取指标信息。

步骤201中的指标信息包括所述测试环境中服务器的中央处理器性能指标、内存指标、磁盘指标、操作系统指标、网络IO、文件系统IO指标、服务器可用性指标、数据库性能指标、端口进程存活指标以及镜像存活指标。

步骤202：根据所述指标信息以及第一预设阈值判断所述测试环境是否正常。

具体地，判断指标信息与其对应的预设阈值之间的关系，以判断测试环境是否正常。

一实施例中，参见图3，步骤201进一步包括：

步骤2011：在指标数据库中，根据所述节点类型信息获取指标信息。

优选地，根据配置管理数据库中登记的环境信息，查询指标数据库中的环境指标。另外，步骤2011中的指标数据库为时序数据库。时序数据库用于指处理带时间标签(按照时间的顺序变化，即时间序列化)的数据，带时间标签的数据也称为时间序列数据。基于时间序列数据的特点，关系型数据库无法满足对时间序列数据的有效存储与处理，因此需要一种专门针对时间序列数据来做优化的数据库系统，即时间序列数据库。对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理，但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式，使得时序大数据可以高效存储和快速处理海量时序大数据，是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式，极大提高了时间相关数据的处理能力，相对于关系型数据库它的存储空间减半，查询速度极大的提高。

一实施例中，参见图4，用于测试环境下的运维方法还包括：

步骤400：生成所述分级自愈模型。参见图5，进一步地，步骤400包括：

步骤401：判断所述测试环境中环境类型是否正常；

步骤402：如果不正常，根据预设的环境类型修复方法对所述测试环境进行修复；

步骤403：如果正常，查找所述测试环境中是否存在负载超过第二预设阈值的进程；

步骤404：如果存在，根据预设的负载修复方法对所述测试环境进行修复；

步骤405：如果不存在，判断所述测试环境中的多个服务器是否存在同一问题；

步骤406：如果存在，根据预设的服务器修复方法对所述测试环境进行修复；

步骤407：如果不存在，读取所述测试环境的日志信息中的报错信息；

步骤408：根据所述报错信息对所述测试环境进行修复。

下面以一更为具体的实例来阐述步骤401至步骤408。

步骤401以及步骤402：一级策略(自定义策略)：由用户根据环境类型自定义设置对应的修复脚本。当检测到该环境类型的问题时，采用该脚本执行自愈，若自愈失败则执行二级自愈策略。

步骤403以及步骤404：二级策略(服务器级别策略)：由系统设置。首先探测服务器对应的负载，返回超过阈值的进程名和进程号，若此进程是在系统预先设置的白名单中，则忽略，否则kill此进程后，每隔15秒监控负载。恢复正常则探测服务器磁盘空间，若负载仍然较高，则通知对应环境维护人，手工介入。再探测服务器磁盘，若磁盘空间超过阈值，则启动该磁盘的自动清理策略。清理完成后，重新执行一级策略。若一级策略仍然失败，则启动三级策略。

步骤405以及步骤406：三级策略(关联环境策略)：在CMDB系统中查找该服务器关联的其它服务器，并探测是否存在相关服务器是否存在问题。是否可以通过一级策略和二级策略修复。若没问题或者修复后，当前环境仍存在问题，则启动四级策略。

步骤407以及步骤408：四级策略(日志分析策略)：读取环境上对应的启动日志，分析对应日志信息。

一实施例中，参见图6，步骤100进一步包括：

步骤101：通过配置管理数据库实时获取测试环境的节点类型信息。

可以理解的是，配置管理数据库(Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

本发明实施例提供的用于测试环境下的运维方法采用了分级自愈策略模式，考虑了影响自愈效果的各个因素。可以大大提高自愈的成功率和减少环境问题分析步骤。同时，将监控部署作为一个自愈策略，根据环境的类型自动选择部署需要监控的类型，自愈功能包含了环境检测的部署，环境检测得到的数据又作为自愈的数据基础。这种方法既减少了环境异常的手工处理，同时也避免了监控模块的手工部署与维护。

为进一步地说明本方案，本申请提供用于测试环境下的运维方法的具体应用实例，该具体应用实例具体包括如下内容。

本具体应用实例还提供一种用于测试环境下的运维系统，测试环境由服务器集群中的服务器组成，包括不同的操作系统和操作系统版本。环境类型体现在服务器根据不同功能部署了不同的中间件。如图7所示，用于测试环境下的运维系统包括：部署在服务器上的监控模块，用于存储检查数据的时序数据库，异常检测模块，自愈模块，存储环境信息的CMDB模块。

CMDB系统上登记了环境清单。一套环境包括多个节点，环境节点分为不同的类型，包括应用服务器、Oracle数据库、Mysql数据库、批量服务器等。每个环境节点包含了该节点的类型信息、操作系统信息、服务器ip地址、服务器用户信息、类型要素信息等。

监控模块为事先编译为二进制可执行文件的python或go程序。监控模块分为系统指标监控模块和服务指标监控模块。系统指标模块为通用模块，可以获取服务器上cpu、内存、磁盘、io等信息。服务指标监控模块为针对不同环境类型，检查不同的服务指标，如应用服务器可用性指标、数据库性能指标、端口进程存活指标，镜像存活指标等。监控模块由自愈模块中的监控模块部署策略发起部署，根据不同的环境类型部署不同的监控模块，并设置定时任务发起检查。在发起检查获取到指标数据后，通过http请求，将数据和服务器信息发送到指标数据库。

指标数据库为存储环境状态指标数据的时序数据库。异常检测模块包含不同环境类型的检测子模块，根据CMDB系统登记的环境信息，查询指标数据库中的环境指标，并根据设置的阈值判断环境是否正常可用。若环境异常，则发起异常自愈请求。同时设置了获取不到指标数据时发起监控模块部署请求。自愈模块保存了系统设置的和用户配置的异常自愈策略。用户可根据实际情况配置可忽略，可报警，可自愈的策略。策略支持配置、开关控制、自愈过程记录、过滤环境正常不可用、重复自愈、自愈后验证等功能。同时自愈模块包含了监控模块部署策略，用于自动化部署监控模块。

基于用于测试环境下的运维系统，本具体应用实例所提供的用于测试环境下的运维方法包括如下内容，参见图8以及图9：

S1：在CMDB系统录入环境节点类型信息。

S2：在自愈模块定制不同类型节点的异常恢复策略。

S3：异常检测模块根据CMDB系统中的环境类型信息，获取环境状态指标数据库中当前的环境状态。根据是否能获取到指标信息和指标信息是否正常，判断是否要发起检测模块的自动部署请求和是否执行自愈策略请求。

进一步地，若获取不到指标数据则认为该服务器为新登记的服务器，发起监控模块的自动部署任务请求。若获取到指标数据且指标数据正常，则认为该服务器运行正常、不需要处理，结束。若获取到指标数据异常，则认为该服务器运行异常、发起自愈请求。

S4：自愈模块根据异常检测模块发起的请求执行相应动作。

具体地，自愈模块发起监控模块的自动部署任务请求，若未发起过监控模块部署，则往被检查服务器上部署相应的监控模块。部署好后重新发起异常检测。若已经发起过监控模块部署，则认为该服务器自动部署监控模块失败，通知运维用户手工处理。

自愈模块发起自愈任务请求。若未发起过自愈策略，则自愈模块执行对应类型的自愈策略。执行完后重新异常检测。若已经发起过自愈策略，则认为该服务器运行异常、自愈策略执行未能解决异常问题，通知运维用户手工处理。

进一步地，参见图10，步骤S4中的自愈策略具体包括：

一级策略(自定义策略)：由用户根据环境类型自定义设置对应的修复脚本。当检测到该环境类型的问题时，采用该脚本执行自愈，若自愈失败则执行二级自愈策略。

二级策略(服务器级别策略)：由系统设置。首先探测服务器对应的负载，返回超过阈值的进程名和进程号，若此进程是在系统预先设置的白名单中，则忽略，否则kill此进程后，每隔15秒监控负载。恢复正常则探测服务器磁盘空间，若负载仍然较高，则通知对应环境维护人，手工介入。再探测服务器磁盘，若磁盘空间超过阈值，则启动该磁盘的自动清理策略。清理完成后，重新执行一级策略。若一级策略仍然失败，则启动三级策略。

三级策略(关联环境策略)：在CMDB系统中查找该服务器关联的其它服务器，并探测是否存在相关服务器是否存在问题。是否可以通过一级策略和二级策略修复。若没问题或者修复后，当前环境仍存在问题，则启动四级策略。

四级策略(日志分析策略)：读取环境上对应的启动日志，分析对应日志信息。(1)若日志中有程序报错，则通报错程序名找到对应的程序修改人，通知对应人员修改。(2)若日志中有对应IP连接不通，则查找该IP对应的节点信息，并找到该节点对应的环境维护人，通知该维护人。(3)启动日志分类程序，根据离线学习得到日志模型。匹配日志是否与之前定义的日志类似，若有相同类型的日志，则启动自定义环境修复。(4)通知对应环境维护人。

从上述描述可知，本发明具体应用实例提供的用于测试环境下的运维方法，为了实现测试环境异常的自动发现、自动处理，满足测试环境高可用性、减少维护人员人工介入维护，避免运维人员手工对不同类型测试环境部署不同监控模块的问题，解决不同操作系统平台编写不同监控程序或脚本的问题。本发明提供了一种能自动部署监控模块、实现异常检测和自愈的方法。在自愈模块添加监控模块自动部署策略，实现根据不同环境类型部署不同检测模块。对于监控中发现的问题，采用分级策略完成测试环境深度自愈。策略支持配置、开关控制、自愈过程记录、过滤环境正常不可用、重复自愈、自愈后验证等功能。解决了大规模、多类型环境下的监控部署和异常处理问题。具体地，本发明具有以下有益效果：

1.通过测试环境可用性监控迅速发现异常问题，通过测试环境自愈自动对异常进行修复或通知运维人员处理，提高异常检查和处理效率，提高环境可用性。

2.运维人员无需介入检测模块的部署与维护，只需维护CMDB上登记的环境类型，自愈系统发现获取不到数据时能根据环境类型自动部署需要的检测模块，且部署是幂等性的，实现监控系统自维护。

3.监控模块由PYTHON/GO编写，一次编写在不同的系统上编译为二进制文件，以实现支持跨平台，减少运维人员为不同系统编写不同脚本的工作；监控模块由定时任务发起，数据推送成功后退出，不常驻内存，对系统性能影响小。

4.提供一种分级自愈策略，综合考虑了影响自愈效果的各个因素。可以大大提高自愈的成功率和减少环境问题分析步骤。并提供了一种可扩展、可配置的自愈方法。

基于同一发明构思，本申请实施例还提供了用于测试环境下的运维装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于用于测试环境下的运维装置解决问题的原理与用于测试环境下的运维方法相似，因此用于测试环境下的运维装置的实施可以参见用于测试环境下的运维方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现用于测试环境下的运维方法的用于测试环境下的运维装置的具体实施方式，参见图11，用于测试环境下的运维装置具体包括如下内容：

信息获取单元10，用于实时获取测试环境的节点类型信息；

环境判断单元20，用于根据所述节点类型信息判断所述测试环境是否正常；

环境修复单元30，用于根据预生成的分级自愈模型修复所述测试环境。

优选地，参见图12，所述环境判断单元20包括：

指标信息获取模块201，用于根据所述节点类型信息获取指标信息；

环境判断模块202，用于根据所述指标信息以及第一预设阈值判断所述测试环境是否正常；

所述指标信息包括：所述测试环境中服务器的中央处理器性能指标、内存指标、磁盘指标、操作系统指标、网络IO、文件系统IO指标、服务器可用性指标、数据库性能指标、端口进程存活指标以及镜像存活指标；

所述指标信息获取模块201具体用于在指标数据库中，根据所述节点类型信息获取指标信息；所述指标数据库为时序数据库

参见图13，用于测试环境下的运维装置还包括：模型生成模块40，用于生成所述分级自愈模型，参见图14，所述模型生成模块40包括：

类型判断模块401，用于判断所述测试环境中环境类型是否正常；

类型修复模块402，用于根据预设的环境类型修复方法对所述测试环境进行修复；

进程查找模块403，用于查找所述测试环境中是否存在负载超过第二预设阈值的进程；

进程修复模块404，用于根据预设的负载修复方法对所述测试环境进行修复；

服务器判断模块405，用于判断所述测试环境中的多个服务器是否存在同一问题；

服务器修复模块406，用于根据预设的服务器修复方法对所述测试环境进行修复；

报错读取模块407，用于读取所述测试环境的日志信息中的报错信息；

报错修复模块408，用于根据所述报错信息对所述测试环境进行修复；

所述信息获取单元10具体用于通过配置管理数据库实时获取测试环境的节点类型信息。

从上述描述可知，本发明实施例提供的用于测试环境下的运维装置，首先实时获取测试环境的节点类型信息；接着，根据节点类型信息判断测试环境是否正常；如果不正常，根据预生成的分级自愈模型修复测试环境。针对大规模、多类型的测试环境，本发明可大大提高测试环境出现问题而自愈的成功率，并且减少运维人员因环境问题分析步骤。

本申请的实施例还提供能够实现上述实施例中的用于测试环境下的运维方法中全部步骤的一种电子设备的具体实施方式，参见图15，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(CommunicationsInterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备、功率测量设备以及用户端设备等相关设备之间的信息传输。

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的用于测试环境下的运维方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：实时获取测试环境的节点类型信息；

步骤200：根据所述节点类型信息判断所述测试环境是否正常；

步骤300：如果不正常，根据预生成的分级自愈模型修复所述测试环境。

本申请的实施例还提供能够实现上述实施例中的用于测试环境下的运维方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的用于测试环境下的运维方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：实时获取测试环境的节点类型信息；

步骤200：根据所述节点类型信息判断所述测试环境是否正常；

步骤300：如果不正常，根据预生成的分级自愈模型修复所述测试环境。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。