CN116405412B - 基于混沌工程故障模拟服务端集群有效性验证方法和系统 - Google Patents

Abstract

本发明实施例提供了一种服务端集群的有效性验证方法和系统，其中，所述方法包括：创建待执行的混沌工程实验案例；根据混沌工程实验案例设置施压场景的运行数据，根据混沌工程实验案例预设混沌工程实验案例关注的资源信息和/或业务处理指标信息；按照施压场景的运行数据在目标服务器节点上执行与施压场景对应的混沌工程实验案例；利用系统监控平台，根据资源信息和/或业务处理指标信息获取服务端集群中除目标服务器节点之外的其他服务器节点的性能数据；根据性能数据对服务端集群进行有效性验证处理。本发明实施例基于混沌工程平台对服务端集群的有效性验证方案更加准确、可靠，能够更好地评估服务端集群的有效性。

Description

基于混沌工程故障模拟服务端集群有效性验证方法和系统

技术领域

本发明涉及互联网技术领域，特别是涉及一种服务端集群的有效性验证方法以及一种服务端集群的有效性验证系统。

背景技术

服务端集群的有效性指的是服务端集群在实际运行环境中的可靠性、稳定性、高可用性等特征。服务端集群的有效性影响到系统的性能、容错性和稳定性，因此需要通过合适的方法对服务端集群的有效性进行验证。

现有技术中，主要通过人工操作的方式对服务端集群的有效性进行验证，例如，通过在终端执行命令或者执行程序脚本来停止服务、挂起进程，又例如，手动关闭服务器，断开网络连接等。

但是，通过人工操作的方式对服务端集群的有效性进行验证可能存在人为因素导致的误差，如操作误差、误判等，对操作人员的专业性要求较高。且需要较多的时间，不能实时反应出服务端集群的有效性状况。不能完全模拟服务端集群的现实环境，需要较多资源支持，可实现场景有限，可能存在单点故障的情况。因此，通过人工操作的方式对服务端集群的有效性进行验证不够准确、可靠。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种服务端集群的有效性验证方法和一种服务端集群的有效性验证系统。

为了解决上述问题，本发明实施例公开了一种服务端集群的有效性验证方法，所述方法包括：响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例；响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息；按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例；利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据；根据所述性能数据对所述服务端集群进行有效性验证处理。

可选地，所述利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据，包括：利用所述系统监控平台，根据所述资源信息获取所述其他服务器节点的资源消耗数据，和/或，根据所述业务处理指标信息获取所述其他服务器节点的业务处理数据。

可选地，所述根据所述性能数据对所述服务端集群进行有效性验证处理，包括：分析所述资源消耗数据是否符合资源消耗指标，和/或，分析所述业务处理数据是否符合业务处理指标；当所述资源消耗数据符合所述资源消耗指标，和/或，所述业务处理数据符合所述业务处理指标时，确定所述服务端集群有效；当所述资源消耗数据不符合所述资源消耗指标，和/或，所述业务处理数据不符合所述业务处理指标时，确定所述服务端集群无效。

可选地，所述按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例，包括：利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例。

可选地，所述利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例，包括：利用数据分析工具对所述运行数据进行分析得到分析结果，所述分析结果包含以下至少之一：性能瓶颈信息、异常状态信息、系统影响信息；根据所述分析结果确定在所述目标服务器节点上待执行的目标混沌工程实验案例；利用所述混沌工具，在所述目标服务器节点上执行所述目标混沌工程实验案例。

可选地，所述响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，包括：响应于针对所述测试工具的场景设置操作，根据所述混沌工程实验案例设置所述施压场景的负载压力信息和运行时间信息。

可选地，所述响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息，包括：响应于针对所述系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的CPU利用信息、内存占用信息、输入输出性能信息，和/或，业务处理结果信息、业务响应时间信息。

可选地，所述响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例，包括：响应于针对所述混沌工程平台的实验案例创建操作，创建所述混沌工程实验案例的实验名称、实验持续时间、实验描述、实验设备、实验事件及所述实验事件的参数。

可选地，在所述根据所述性能数据对所述服务端集群进行有效性验证处理之后，所述方法还包括：利用所述混沌工具撤销执行所述目标服务器节点上的混沌工程实验案例；在所述目标服务器节点运行预设时间段之后，利用所述系统监控平台获取所述目标服务器节点的业务恢复信息；根据所述业务恢复信息判断所述目标服务器节点是否恢复至正常状态。

本发明实施例还公开了一种服务端集群的有效性验证系统，所述系统包括：实验案例创建模块，用于响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例；场景监控设置模块，用于响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息；实验案例执行模块，用于按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例；运行数据获取模块，用于利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据；有效性验证模块，用于根据所述性能数据对所述服务端集群进行有效性验证处理。

可选地，所述性能数据获取模块，用于利用所述系统监控平台，根据所述资源信息获取所述其他服务器节点的资源消耗数据，和/或，根据所述业务处理指标信息获取所述其他服务器节点的业务处理数据。

可选地，所述有效性验证模块，包括：分析模块，用于分析所述资源消耗数据是否符合资源消耗指标，和/或，分析所述业务处理数据是否符合业务处理指标；确定模块，用于当所述资源消耗数据符合所述资源消耗指标，和/或，所述业务处理数据符合所述业务处理指标时，确定所述服务端集群有效；当所述资源消耗数据不符合所述资源消耗指标，和/或，所述业务处理数据不符合所述业务处理指标时，确定所述服务端集群无效。

可选地，所述实验案例执行模块，用于利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例。

可选地，所述实验案例执行模块，包括：运行数据分析模块，用于利用数据分析工具对所述运行数据进行分析得到分析结果，所述分析结果包含以下至少之一：性能瓶颈信息、异常状态信息、系统影响信息；实验案例筛选模块，用于根据所述分析结果确定在所述目标服务器节点上待执行的目标混沌工程实验案例；目标实验执行模块，用于利用所述混沌工具，在所述目标服务器节点上执行所述目标混沌工程实验案例。

可选地，所述场景监控设置模块，包括：施压场景设置模块，用于响应于针对所述测试工具的场景设置操作，根据所述混沌工程实验案例设置所述施压场景的负载压力信息和运行时间信息。

可选地，所述场景监控设置模块，包括：监控平台设置模块，用于响应于针对所述系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的CPU利用信息、内存占用信息、输入输出性能信息，和/或，业务处理结果信息、业务响应时间信息。

可选地，所述实验案例创建模块，用于响应于针对所述混沌工程平台的实验案例创建操作，创建所述混沌工程实验案例的实验名称、实验持续时间、实验描述、实验设备、实验事件及所述实验事件的参数。

可选地，所述系统还包括：节点恢复模块，用于在所述有效性验证模块根据所述运行数据对所述服务端集群进行有效性验证处理之后，利用所述混沌工具撤销执行所述目标服务器节点上的混沌实验案例执行；业务恢复模块，用于在所述目标服务器节点运行预设时间段之后，利用所述系统监控平台获取所述目标服务器节点的业务恢复信息；状态判断模块，用于根据所述业务恢复信息判断所述目标服务器节点是否恢复至正常状态。

本发明实施例还公开了一种电子设备，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述电子设备执行如上所述的服务端集群的有效性验证方法。

本发明实施例还公开了一种计算机可读存储介质，其存储的计算机程序使得处理器执行如上所述的服务端集群的有效性验证方法。

本发明实施例包括以下优点：

本发明实施例提供的服务端集群的有效性验证方案，基于混沌工程平台。响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例。而且，响应于针对测试工具的场景设置操作，根据混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据混沌工程实验案例预设混沌工程实验案例关注的资源信息和/或业务处理指标信息。在服务端集群的目标服务器节点上按照施压场景的运行数据执行与施压场景对应的混沌工程实验案例。然后，利用系统监控平台，根据资源信息和/或业务处理指标信息获取服务端集群中除目标服务器节点之外的其他服务器节点的性能数据。最终，根据性能数据对服务端集群进行有效性验证处理。

本发明实施例基于混沌工程平台对服务端集群的有效性进行验证，无需专业人士对服务端集群进行手动操作，降低了人工成本。可以模拟出现实环境下的故障，更准确地评估服务端集群的有效性。可以实时反应出服务端集群的状况，比人工验证更加有效率。验证服务端集群的有效性过程可以自动完成，避免因人为因素导致的误差。可以根据实际需要调整故障类型和故障数量，从而更好的验证服务端集群的有效性。因此，基于混沌工程平台对服务端集群的有效性验证方案更加准确、可靠，能够更好地评估服务端集群的有效性。

附图说明

图1是本发明实施例的一种服务端集群的有效性验证方法的步骤流程图；

图2是本发明实施例的一种基于混沌工程的分布式系统服务端集群的有效性验证方案的流程示意图；

图3是本发明实施例的一种服务端集群的有效性验证系统的结构框图；

图4是本发明实施例的一种电子设备的结构示意图_。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明实施例通过混沌工程平台实现验证服务端集群有效性的方式，即在确定目标服务器节点、系统监控平台和施压场景后，由混沌工程平台发起混沌工程实验案例，在目标服务器节点执行相应的实验案例，以注入停止服务、进程挂起、宕机、宕网卡、网络丢包等故障类型，模拟相应的故障。与此同时，还可以通过混沌工程平台模拟网络延迟、CPU占用高、内存不足等现有技术很难复现的故障，进行服务端集群的有效性验证。

参照图1，示出了本发明实施例的一种服务端集群的有效性验证方法的步骤流程图。该服务端集群的有效性验证方法具体可以包括如下步骤：

步骤101，响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例。

在本发明的实施例中，混沌工程是一种研究系统复杂性的工程方法，它使用数学模型和方法来分析和控制复杂的动力系统的行为。该方法用于研究物理系统，生物系统，社会系统等的复杂性，并寻找控制和优化这些系统的方法。混沌工程是一种跨学科的研究领域，结合了物理学、数学、计算机科学和工程学等学科。混沌工程平台为混沌工程的应用平台，通常，混沌工程平台上可以安装有混沌工程相关的软件，如Chaos Toolkit(一个开源的混沌工程工具包，它提供了一个简单的方法来实现、自动化和管理混沌工程实验。它允许开发人员定义混沌实验，并在生产环境中进行测试，以评估系统的可靠性和弹性)或ChaosMonkey(一种自动化的混沌工程工具，可以在生产环境中对分布式系统进行随机故障测试。它的目的是验证系统的容错性和可靠性，并在系统发生故障时确保其能正常工作。通常用于在云计算环境中验证自动故障转移等高可用性功能)。在创建混沌工程实验案例时，可以定义混沌工程实验案例的目的，如验证服务端集群的自动恢复能力。定义混沌工程实验案例的范围，例如随机关闭某些服务器。设置混沌工程实验案例的参数，如随机关闭服务器的概率。执行混沌工程实验案例，监测服务端集群的性能和状态。分析实验结果，评估服务端集群的有效性。混沌工程平台的核心功能在于模拟基础资源类、系统级、各类中间件、应用等多种系统故障场景，如操作系统故障(涉及：CPU、磁盘、进程、网络等)、应用场景故障(涉及技术栈：Spring家族产品(一个Java平台的生态系统，由许多独立的、但是又高度协作的项目组成)、MySQL(一个关系型数据库管理系统)、Servlet(小服务程序或服务连接器)等)，以主动对系统进行故障注入的方式，发现系统薄弱环节，以达到检测、验证、分析系统的健壮性，弥补系统漏洞的目的。

在实际应用中，用户可以在混沌工程平台中输入实验名称、描述、版本号等基本信息，由混沌工程平台基于用户输入的基本信息创建混沌工程实验案例。一个创建好的混沌工程实验案例一般包含以下内容：实验目的：明确实验的目标和目的。实验场景：描述实验的场景，包括操作系统、应用程序、硬件配置等信息。实验步骤：按照先后顺序描述实验的具体步骤，包括操作、设置参数、运行命令等。实验预期结果：明确实验的预期结果和效果，以便于后续的验证和评估。实验环境：描述实验所需的环境，包括软件、硬件、网络等方面。实验数据：记录实验所产生的数据，以便后续分析和统计。实验评估：对实验结果进行评估，包括实验目标是否达成、实验效果如何等。实验报告：撰写实验报告，记录实验的过程、结果、分析和总结，以便后续参考和借鉴。

步骤102，响应于针对测试工具的场景设置操作，根据混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据混沌工程实验案例预设混沌工程实验案例关注的资源信息和/或业务处理指标信息。

在本发明的实施例中，在设置施压场景的运行数据时，可以定义施压场景的目的，例如模拟服务端集群的高负载状态。定义施压场景的范围，例如选择所有的服务器或者部分服务器。选择施压的方式，如利用JMeter(一款基于Java的开源性能测试工具，可用于模拟大量用户同时访问网络应用，以检测其稳定性和吞吐量。)生成负载请求。设置施压的参数，例如并发请求数量和请求频率。执行施压场景，监测服务端集群的性能和状态。分析场景结果，评估服务端集群的稳定性和可用性。

在本发明的实施例中，预设混沌工程实验案例关注的资源信息和/或业务处理指标信息时，可以先了解组成服务端集群的组件，并识别对其运行至关重要的组件。评估服务端集群支持的流程，并确定对业务至关重要的流程。确定服务端集群及其关键组件和过程的正常性能特征。使用监控和日志记录工具收集关键指标的数据，如资源利用率、响应时间、错误率和可用性。

步骤103，按照施压场景的运行数据在服务端集群的目标服务器节点上执行与施压场景对应的混沌工程实验案例。

在本发明的实施例中，服务端集群是由多台服务器组成的集合，可以共同协作处理大量的数据或者请求，提高系统的可用性、可扩展性和容错性。可以为服务端集群的每一个服务器节点安装和配置必要的软件工具，如：混沌工具、监控工具、系统指标采集工具。根据混沌工程实验案例的预设设置施压的目标资源和指标，如：CPU、内存、网络带宽、数据库响应时间等。可以使用混沌工程实验工具，在目标服务器节点上执行配置好的混沌工程实验案例，模拟出不同的故障场景，例如模拟网络故障、模拟节点宕机等。

步骤104，利用系统监控平台，根据资源信息和/或业务处理指标信息获取服务端集群中除目标服务器节点之外其他服务器节点的性能数据。

在本发明的实施例中，系统监控平台是通过在服务端集群中部署代理和采集器等组件，从服务端集群中获取各种性能数据，如CPU使用率、内存使用率、网络延迟等等，同时通过这些数据来监控服务端集群的运行状态，发现潜在的问题并进行预警。通常需要使用系统监控平台中的监控和管理工具来收集性能数据。例如，可以使用操作系统的内置工具或第三方监控工具来收集服务器的状态信息，包括但不限于：CPU使用率、内存使用情况、磁盘空间使用情况、网络流量等。

步骤105，根据性能数据对服务端集群进行有效性验证处理。

在本发明的实施例中，上述服务器集群的性能数据，包括但不限于：资源使用情况、响应时间、错误率等。对收集的性能数据进行分析，识别出哪些服务器节点表现较差。评估性能数据的正常范围，并确定是否存在性能问题。对于识别出的性能问题进行调查，以确定问题的根本原因。通过修复识别出的性能问题来提高服务端集群的效率。定期对服务端集群的性能数据进行监控，以确保服务端集群的有效性。通过上述步骤，可以评估服务端集群的性能是否满足预期，从而验证服务端集群的有效性。

例如，一个应用服务部署在一个具有3台服务器的服务端集群上，通过混沌工程平台，在目标服务器节点上执行混沌工程实验案例，以实现将故障注入到目标服务器节点上，比如注入网络延迟、宕机、进程杀死等故障。此时，关注的是这个应用服务是否会受到该故障注入的影响。如果通过系统监控平台发现指标(如每秒交易数(Transaction PerSecond，简称TPS))在故障注入后出现瞬间下降，并且在规定的时间内(如2分钟内)没有拉起来恢复到正常区间，那么就说明3台服务器中的另外2台正常的服务器，没能有效的接管这一应用服务，可以认为服务端集群无效，或者效率低；相反，如果指标能在2分钟内拉起来，就说明服务端集群有效。

本发明实施例提供的服务端集群的有效性验证方案，基于混沌工程平台。响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例。而且，响应于针对测试工具的场景设置操作，根据混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据混沌工程实验案例预设混沌工程实验案例关注的资源信息和/或业务处理指标信息。在服务端集群的目标服务器节点上按照施压场景的运行数据执行与施压场景对应的混沌工程实验案例。然后，利用系统监控平台，根据资源信息和/或业务处理指标信息获取服务端集群中除目标服务器节点之外的其他服务器节点的性能数据。最终，根据性能数据对服务端集群进行有效性验证处理。

本发明实施例基于混沌工程平台对服务端集群的有效性进行验证，无需专业人士对服务端集群进行手动操作，降低了人工成本。可以模拟出现实环境下的故障，更准确地评估服务端集群的有效性。可以实时反应出服务端集群的状况，比人工验证更加有效率。验证服务端集群的有效性过程可以自动完成，避免因人为因素导致的误差。可以根据实际需要调整故障类型和故障数量，从而更好的验证服务端集群的有效性。因此，基于混沌工程平台对服务端集群的有效性验证方案更加准确、可靠，能够更好地评估服务端集群的有效性。

在本发明的一种示例性实施例中，利用系统监控平台，根据资源信息和/或业务处理指标信息获取服务端集群中除目标服务器节点之外的其他服务器节点的性能数据的一种实施方式为，利用系统监控平台，根据资源信息获取其他服务器节点的资源消耗数据，和/或，根据业务处理指标信息获取其他服务器节点的业务处理数据。其中，资源消耗数据包含但不限于：各其他服务器节点的CPU利用率、内存占用率、输入输出繁忙程度等等。业务处理数据包含但不限于：各类业务的成功率、各类业务的失败率、响应时间是否快速恢复等等。由于性能数据包含的种类繁多，在实际应用中不需要获取每种性能数据，因此，可以结合实际情况获取资源消耗数据和/或业务处理数据。在本发明实施例中，利用系统监控平台获取其他服务器节点中的性能数据，需要进行以下步骤：安装并配置监控代理：监控代理是一个运行在服务器节点上的软件，负责收集节点上的性能数据并发送给系统监控平台。在安装监控代理之前，需要先选择合适的监控代理软件，并按照文档进行配置。配置监控指标：监控指标是指要收集的性能数据，不同的监控代理软件支持的监控指标可能不同，需要根据实际情况进行选择和配置。在系统监控平台中创建主机：创建主机是指将要监控的服务器节点添加到系统监控平台中。在创建主机时，需要指定主机的IP地址或域名、监控代理的地址等信息。在系统监控平台中配置主机：配置主机是指设置主机的监控指标、告警规则等信息。在配置主机时，需要指定要监控的指标、设置阈值、设置告警方式等。查看性能数据：在主机添加完成并且监控指标和告警规则配置好之后，就可以在系统监控平台上查看服务器节点中的性能数据了。可以通过系统监控平台提供的图表、报表等功能来查看性能数据，并进行性能分析和故障排查。需要注意的是，不同的系统监控平台可能具有不同的界面和操作方式，具体的操作步骤可能有所差异。

在本发明的一种示例性实施例中，根据性能数据对服务端集群进行有效性验证处理的一种实施方式为，分析资源消耗数据是否符合资源消耗指标，和/或，分析业务处理数据是否符合业务处理指标。当资源消耗数据符合资源消耗指标，和/或，业务处理数据符合业务处理指标时，确定服务端集群有效；当资源消耗数据不符合资源消耗指标，和/或，业务处理数据不符合业务处理指标时，确定服务端集群无效。在本发明实施例中，利用性能数据对服务端集群进行有效性验证，具体步骤如下：收集性能数据：可以利用系统监控平台收集服务器节点的CPU使用率、内存使用率、网络流量等性能数据。分析性能数据：根据混沌工程实验案例中设置的业务处理指标和资源消耗指标，分析服务器节点的性能数据是否符合预期，是否存在异常情况。判断服务器节点的有效性：根据分析结果，判断服务器节点的有效性。如果服务器节点的性能数据符合预期，没有异常情况，可以认为该服务器节点是有效的。反之，如果服务器节点的性能数据异常，需要进一步分析原因，并对服务器节点进行相应的调整或排除。

在本发明的一种示例性实施例中，按照施压场景的运行数据在服务端集群的目标服务器节点上执行与施压场景对应的混沌工程实验案例的一种实施方式为，利用混沌工程平台的混沌工具，按照施压场景的运行数据在目标服务器节点上执行与施压场景对应的混沌工程实验案例。在实际应用中，可以利用数据分析工具对运行数据进行分析得到分析结果，分析结果包含以下至少之一：性能瓶颈信息、异常状态信息、系统影响信息等，根据分析结果确定在目标服务器节点上待执行的目标混沌工程实验案例。再利用混沌工具，在目标服务器节点上执行目标混沌工程实验案例。在本发明的实施例中，根据施压场景的运行数据在目标服务器节点上执行与施压场景对应的混沌工程实验案例的具体实现步骤如下：获取施压场景的运行数据：根据施压场景的设置和运行，获取其产生的运行数据，比如CPU占用率、内存占用率、网络流量等指标数据。可以通过系统监控平台或者日志分析等方式来获取。分析运行数据：对获取到的运行数据进行分析，了解系统的性能瓶颈、异常状态和影响等情况。可以使用数据分析工具，如Grafana(一个开源的数据可视化与分析平台，它可以通过图形和仪表盘将各种数据源汇总为有价值的信息。它支持多种数据源，并且提供了强大的可视化功能，以及自定义布局，警报等功能)等。确定混沌工程实验案例：根据分析结果，确定需要执行的混沌工程实验案例。比如，如果发现CPU占用率过高，可以选择执行CPU满负载的混沌工程实验案例。在目标服务器节点上执行混沌工程实验案例：将确定好的混沌工程实验案例在目标服务器节点上执行。可以使用混沌工具，如Chaos Toolkit或者自行编写脚本等方式来实现。监控实验执行结果：对执行混沌工程实验案例的服务器节点进行监控，了解执行情况和效果。可以使用系统监控平台或者日志分析等方式来监控。分析实验结果：根据执行结果，对系统的性能瓶颈、异常状态和影响等情况进行分析。比如，通过混沌工程实验案例可以发现系统在高负载下的稳定性和容错性如何。

在本发明的一种示例性实施例中，响应于针对测试工具的场景设置操作，根据混沌工程实验案例设置施压场景的运行数据的一种实施方式为，响应于针对测试工具的场景设置操作，根据混沌工程实验案例设置施压场景的负载压力信息和运行时间信息。其中，测试工具包含以下至少之一：LoadRunner(一款用于负载测试和性能测试的软件工具，它可以模拟多个用户同时访问应用程序，以测试其在大规模并发访问条件下的表现。)、JMeter、APTS(高级持续性威胁)工具。负载压力信息可以为被测试系统最大处理能力的50％或者其他百分比。运行时间信息可以设定为10分钟或者其他时间段。

在本发明实施例中，根据混沌工程实验案例设置施压场景的运行数据需要考虑以下因素：性能指标，如吞吐量、响应时间、错误率等。系统硬件资源的限制，如CPU、内存、磁盘等。预计的用户负载情况，包括同时在线用户数、请求频率、数据大小等。系统的安全性、可靠性、可用性要求等。一般而言，通过以下几个步骤来根据混沌工程实验案例设置施压场景的运行数据：根据混沌工程实验案例，选择适当的施压场景，并配置相应的参数，如并发数、请求频率、数据大小等。通过性能测试工具(如JMeter、LoadRunner等)模拟用户请求，并记录各项性能指标，如响应时间、吞吐量等。对比混沌工程实验案例中预设的性能指标，判断哪些方面存在问题，进行优化和改进。需要注意的是，施压场景的设置需要根据实际情况进行调整，以保证测试结果的准确性和可信度。

在本发明的一种示例性实施例中，响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据混沌工程实验案例预设混沌工程实验案例关注的资源信息和/或业务处理指标信息的一种实施方式为，响应于针对系统监控平台的信息预设操作，根据混沌工程实验案例预设混沌工程实验案例关注的CPU利用信息、内存占用信息、输入输出性能信息，和/或，业务处理结果信息、业务响应时间信息。其中，系统监控平台包含以下至少之一：APM(即应用程序性能管理。它是一种通过监测、诊断和分析应用程序的性能以提高系统效率、可用性和用户体验的方法。通常通过收集应用程序性能数据，并通过分析这些数据以诊断性能问题来实现。它还提供了一些实用工具，如故障排除、问题诊断、监控、预警等，以帮助管理员维护和提高系统的性能)、ZABBIX(一种用于监控各种网络服务、服务器和网络硬件的开源软件。它提供了性能数据和配置的警报、报告和可视化等功能，可帮助系统管理员监控和分析It基础架构组件的性能和可用性)、Prometheus(一个开源的监控和警报系统。它旨在以灵活和高效的方式收集和存储有关各种系统和应用程序的时间序列数据，并提供一种简单而强大的方式来查询和可视化数据)、Grafana。在本发明的实施例中，可以通过在系统监控平台中配置相应的监控指标来设置混沌工程实验案例关注的资源信息和/或业务处理指标信息。具体步骤如下：在系统监控平台中选择需要关注的监控指标和参数，例如CPU利用率、内存使用情况、网络延迟等。将配置好的监控指标和参数应用到混沌工程实验案例中，用于判断系统的状态和性能。需要注意的是，不同的监控平台可能有不同的配置方式和操作步骤。同时，需要根据实际情况选择合适的监控指标和参数，以确保混沌工程实验案例可以有效地验证系统的可靠性和稳定性。

在本发明的一种示例性实施例中，响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例的一种实施方式为，响应于针对混沌工程平台的实验案例创建操作，创建混沌工程实验案例的实验名称、实验持续时间、实验描述、实验设备、实验事件及实验事件的参数等。其中，实验事件类型包含但不限于：杀进程、暂停进程、系统宕机重启、网络丢包、网络延迟、网络存储异常、CPU占用高、内存不足、本地存储异常。实验事件的参数包含但不限于：事件开始时间、事件结束时间、事件运行时间等。在本发明的实施例中，通过混沌工程平台创建混沌工程实验案例可以分为以下步骤：确定混沌工程实验案例的目标和范围，例如：验证某个应用服务在高负载情况下的稳定性。根据实验目标设计混沌工程实验方案，包括实验类型、实验场景、实验节点、实验指标、实验操作等。在混沌工程平台中创建混沌工程实验案例，包括输入实验名称、描述、版本号等基本信息，并根据设计的实验方案设置实验场景、实验指标、实验操作等参数。在混沌工程平台中选择服务器节点，并将混沌工程实验案例部署到服务器节点上。通常，一个创建好的混沌工程实验案例一般包含以下内容：实验目的：明确实验的目标和目的。实验场景：描述实验的场景，包括操作系统、应用程序、硬件配置等信息。实验步骤：按照先后顺序描述实验的具体步骤，包括操作、设置参数、运行命令等。实验预期结果：明确实验的预期结果和效果，以便于后续的验证和评估。实验环境：描述实验所需的环境，包括软件、硬件、网络等方面。实验数据：记录实验所产生的数据，以便后续分析和统计。实验评估：对实验结果进行评估，包括实验目标是否达成、实验效果如何等。实验报告：撰写实验报告，记录实验的过程、结果、分析和总结，以便后续参考和借鉴。

在本发明的一种示例性实施例中，在根据性能数据对服务端集群进行有效性验证处理之后，还可以利用混沌工具撤销执行目标服务器节点上的混沌实验案例，并且在目标服务器节点运行预设时间段之后，利用系统监控平台获取目标服务器节点的业务恢复信息，进而根据业务恢复信息判断目标服务器节点是否恢复至正常状态。其中，预设时间段可以为10分钟或者其他时间段。业务恢复信息包含但不限于：CPU利用率、内存占用率、磁盘读写量等等。

基于上述关于一种服务端集群的有效性验证方法实施例的相关说明，下面介绍一种基于混沌工程的分布式系统服务端集群的有效性验证方案。参照图2，示出了本发明实施例的一种基于混沌工程的分布式系统服务端集群的有效性验证方案的流程示意图。

步骤201，创建混沌工程实验案例。

用于可以在混沌工程平台中录入混沌工程实验案例的相关信息，利用混沌工程平台创建混沌工程实验案例。具体的创建过程包括：①填写实验名称、实验持续时间、实验描述；②选择实验机器；③添加具体混沌工程实验事件(事件类型包括但不限于：杀进程、暂停进程、系统宕机重启、网络丢包、网络延迟、网络存储异常、CPU占用高、内存不足、本地存储异常)，并配置各项参数(实验开始时间、结束时间、事件运行时间等)；④保存实验案例，等待执行。

步骤202，预设施压场景和监控体系。

通过LoadRunner、JMeter、APTS等测试工具，以被测试系统最大处理能力的50％作为负载压力，向被测试系统发送大量请求链接以进行施压，场景稳定运行10分钟。在APM、ZABBIX、Prometheus、Grafana等系统监控平台上，预设实验关注的基本资源情况、与业务处理相关的指标。

步骤203，执行混沌工程实验案例。

由底层混沌工具和预先安装在各服务器中的探针，对集群中指定的一台服务器节点执行混沌工程实验事件，进行故障注入，场景持续运行10分钟。

步骤204，观察其他集群节点接管故障节点的业务处理情况。

通过系统监控平台观察各类业务失败率、响应时间是否在短时间内恢复正常，观察各服务器节点的CPU利用率、内存占用率、输入输出繁忙程度等基本资源情况，以验证集群有效性。

步骤205，恢复故障节点，观察各业务的恢复情况。

混沌工程实验案例运行结束后，混沌工具会自动解除故障注入，恢复故障节点，场景持续运行10分钟，观察短时间内各业务的恢复情况。

步骤206，分析和记录测试结果数据。

下面，举个例子，假设基于混沌工程验证一个包含5个服务器节点的服务端集群的有效性。首先，创建混沌工程实验案例并设置施压场景，如增加访问量、增加读写数据的频率等。然后，在目标服务器节点上执行混沌工程实验案例，以模拟服务器遇到压力时的表现。在执行混沌工程实验案例时，可以利用系统监控平台获取每个服务器节点的性能数据，如CPU利用率、内存占用率、磁盘读写速率等。最后，根据性能数据对服务端集群的有效性进行验证，如验证集群的可用性、容错性、负载平衡效果等。以上是一个使用混沌工程验证集群有效性的实例，实际实施过程可能会因业务场景不同而有所差别。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

参照图3，示出了本发明实施例的一种服务端集群的有效性验证系统的结构框图，该服务端集群的有效性验证系统具体可以包含如下模块。

实验案例创建模块31，用于响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例；

场景监控设置模块32，用于响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，并响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息；

实验案例执行模块33，用于按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例；

性能数据获取模块34，用于利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据；

有效性验证模块35，用于根据所述性能数据对所述服务端集群进行有效性验证处理。

在本发明的一种示例性实施例中，所述性能数据获取模块34，用于利用所述系统监控平台，根据所述资源信息获取所述其他服务器节点的资源消耗数据，和/或，根据所述业务处理指标信息获取所述其他服务器节点的业务处理数据。

在本发明的一种示例性实施例中，所述有效性验证模块35，包括：

分析模块，用于分析所述资源消耗数据是否符合资源消耗指标，和/或，分析所述业务处理数据是否符合业务处理指标；

确定模块，用于当所述资源消耗数据符合所述资源消耗指标，和/或，所述业务处理数据符合所述业务处理指标时，确定所述服务端集群有效；当所述资源消耗数据不符合所述资源消耗指标，和/或，所述业务处理数据不符合所述业务处理指标时，确定所述服务端集群无效。

在本发明的一种示例性实施例中，所述实验案例执行模块33，用于利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例。

在本发明的一种示例性实施例中，所述实验案例执行模块33，包括：

运行数据分析模块，用于利用数据分析工具对所述运行数据进行分析得到分析结果，所述分析结果包含以下至少之一：性能瓶颈信息、异常状态信息、系统影响信息；

实验案例筛选模块，用于根据所述分析结果确定在所述目标服务器节点上待执行的目标混沌工程实验案例；

目标实验执行模块，用于利用所述混沌工具，在所述目标服务器节点上执行所述目标混沌工程实验案例。

在本发明的一种示例性实施例中，所述场景监控设置模块32，包括：

施压场景设置模块，用于响应于针对所述测试工具的场景设置操作，根据所述混沌工程实验案例设置所述施压场景的负载压力信息和运行时间信息。

在本发明的一种示例性实施例中，所述场景监控设置模块32，包括：

监控平台设置模块，用于响应于针对所述系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的CPU利用信息、内存占用信息、输入输出性能信息，和/或，业务处理结果信息、业务响应时间信息。

在本发明的一种示例性实施例中，所述实验案例创建模块31，用于响应于针对所述混沌工程平台的实验案例创建操作，创建所述混沌工程实验案例的实验名称、实验持续时间、实验描述、实验设备、实验事件及所述实验事件的参数。

在本发明的一种示例性实施例中，所述系统还包括：

节点恢复模块，用于在所述有效性验证模块35根据所述运行数据对所述服务端集群进行有效性验证处理之后，利用所述混沌工具撤销执行所述目标服务器节点上的混沌实验案例执行；

业务恢复模块，用于在所述目标服务器节点运行预设时间段之后，利用所述系统监控平台获取所述目标服务器节点的业务恢复信息；

状态判断模块，用于根据所述业务恢复信息判断所述目标服务器节点是否恢复至正常状态。

对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

图4示出了本发明实施例的一种电子设备400的结构示意图。如图4所示，电子设备400包括中央处理单元(CPU)401，其可以根据存储在只读存储器(ROM)402中的计算机程序指令或者从存储单元408加载到随机访问存储器(RAM)403中的计算机程序指令，来执行各种适当的动作和处理。在RAM 403中，还可存储电子设备400操作所需的各种程序和数据。CPU 401、ROM402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

电子设备400中的多个部件连接至I/O接口405，包括：输入单元406，例如键盘、鼠标、麦克风等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许电子设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个过程和处理，可由处理单元401执行。例如，上述任一实施例的方法可被实现为计算机软件程序，其被有形地包含于计算机可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由ROM 402和/或通信单元409而被载入和/或安装到电子设备400上。当计算机程序被加载到RAM 403并由CPU401执行时，可以执行上文描述的方法中的一个或多个动作。

在本发明的实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序可由电子设备的处理器执行，以完成上述任一实施例的服务端集群的有效性验证方法。例如，所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种服务端集群的有效性验证方法和一种服务端集群的有效性验证系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种服务端集群的有效性验证方法，其特征在于，所述方法包括：

响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例；

响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据；

分析组成服务端集群的组件，识别所述组成服务端集群的组件中的重要组件，所述重要组件为对所述服务端集群的运行起关键作用的组件；

评估组成服务端集群的组件支持的流程，确定所述组成服务端集群的组件支持的流程中的重要流程，所述重要流程为对所述服务端集群支持的业务起关键作用的流程；

响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例、所述重要组件和所述重要流程预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息；

按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例；

利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据，所述性能数据用于判定所述其他服务器节点能否有效接管应用服务；

根据所述性能数据对所述服务端集群进行有效性验证处理；

其中，所述根据所述性能数据对所述服务端集群进行有效性验证处理，包括：

根据所述性能数据，观察所述其他服务器节点接管所述目标服务器节点的业务处理情况；

若所述业务处理情况在执行所述混沌工程实验案例时未在预定时间内恢复正常，则判定所述服务端集群无效，或，所述服务端集群效率低；

若所述业务处理情况在执行所述混沌工程实验案例时在预设时间内恢复正常，则判定所述服务端集群有效。

2.根据权利要求1所述的方法，其特征在于，所述利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据，包括：

利用所述系统监控平台，根据所述资源信息获取所述其他服务器节点的资源消耗数据，和/或，根据所述业务处理指标信息获取所述其他服务器节点的业务处理数据。

3.根据权利要求2所述的方法，其特征在于，所述根据所述性能数据对所述服务端集群进行有效性验证处理，包括：

分析所述资源消耗数据是否符合资源消耗指标，和/或，分析所述业务处理数据是否符合业务处理指标；

当所述资源消耗数据符合所述资源消耗指标，和/或，所述业务处理数据符合所述业务处理指标时，确定所述服务端集群有效；

当所述资源消耗数据不符合所述资源消耗指标，和/或，所述业务处理数据不符合所述业务处理指标时，确定所述服务端集群无效。

4.根据权利要求1所述的方法，其特征在于，所述按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例，包括：

利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例。

5.根据权利要求4所述的方法，其特征在于，所述利用所述混沌工程平台的混沌工具，按照所述施压场景的运行数据在所述目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例，包括：

利用数据分析工具对所述运行数据进行分析得到分析结果，所述分析结果包含以下至少之一：性能瓶颈信息、异常状态信息、系统影响信息；

根据所述分析结果确定在所述目标服务器节点上待执行的目标混沌工程实验案例；

利用所述混沌工具，在所述目标服务器节点上执行所述目标混沌工程实验案例。

6.根据权利要求1所述的方法，其特征在于，所述响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，包括：

响应于针对所述测试工具的场景设置操作，根据所述混沌工程实验案例设置所述施压场景的负载压力信息和运行时间信息。

7.根据权利要求1所述的方法，其特征在于，所述响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息，包括：

响应于针对所述系统监控平台的信息预设操作，根据所述混沌工程实验案例预设所述混沌工程实验案例关注的CPU利用信息、内存占用信息、输入输出性能信息，和/或，业务处理结果信息、业务响应时间信息。

8.根据权利要求1所述的方法，其特征在于，所述响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例，包括：

响应于针对所述混沌工程平台的实验案例创建操作，创建所述混沌工程实验案例的实验名称、实验持续时间、实验描述、实验设备、实验事件及所述实验事件的参数。

9.根据权利要求4所述的方法，其特征在于，在所述根据所述性能数据对所述服务端集群进行有效性验证处理之后，所述方法还包括：

利用所述混沌工具撤销执行所述目标服务器节点上的混沌工程实验案例；

在所述目标服务器节点运行预设时间段之后，利用所述系统监控平台获取所述目标服务器节点的业务恢复信息；

根据所述业务恢复信息判断所述目标服务器节点是否恢复至正常状态。

10.一种服务端集群的有效性验证系统，其特征在于，所述系统包括：

实验案例创建模块，用于响应于针对混沌工程平台的实验案例创建操作，创建待执行的混沌工程实验案例；

场景监控设置模块，用于响应于针对测试工具的场景设置操作，根据所述混沌工程实验案例设置施压场景的运行数据，分析组成服务端集群的组件，识别所述组成服务端集群的组件中的重要组件，所述重要组件为对所述服务端集群的运行起关键作用的组件，评估组成服务端集群的组件支持的流程，确定所述组成服务端集群的组件支持的流程中的重要流程，所述重要流程为对所述服务端集群支持的业务起关键作用的流程，响应于针对部署在服务端集群上的系统监控平台的信息预设操作，根据所述混沌工程实验案例、所述重要组件和所述重要流程预设所述混沌工程实验案例关注的资源信息和/或业务处理指标信息；

实验案例执行模块，用于按照所述施压场景的运行数据在所述服务端集群的目标服务器节点上执行与所述施压场景对应的所述混沌工程实验案例；

运行数据获取模块，用于利用所述系统监控平台，根据所述资源信息和/或所述业务处理指标信息获取所述服务端集群中除所述目标服务器节点之外的其他服务器节点的性能数据，所述性能数据用于判定所述其他服务器节点能否有效接管应用服务；

有效性验证模块，用于根据所述性能数据对所述服务端集群进行有效性验证处理；

其中，所述根据所述性能数据对所述服务端集群进行有效性验证处理，包括：

根据所述性能数据，观察所述其他服务器节点接管所述目标服务器节点的业务处理情况；

若所述业务处理情况在执行所述混沌工程实验案例时未在预定时间内恢复正常，则判定所述服务端集群无效，或，所述服务端集群效率低；

若所述业务处理情况在执行所述混沌工程实验案例时在预设时间内恢复正常，则判定所述服务端集群有效。