Chaos engineering-based attack and defense drill method, device, equipment, medium and product

Abstract

Embodiments of the present application provide a chaos engineering-based attack and defense drill method, device, equipment, medium and product. The method comprises: obtaining a first chaos fault scene using a random algorithm; obtaining a to-be-tested fault matching the first chaos fault scene from a predetermined to-be-tested fault range; wherein one to-be-tested fault corresponds to one fault weight; in the process of executing the to-be-tested faults in the order of fault weights from large to small, real-time capture of system state parameters; downgrading the fault weight of the to-be-tested fault that ends execution, and re-adding the downgraded to-be-tested fault to the to-be-tested fault range; when a completion instruction is detected, effect verification and system repair are performed based on the system state parameters to obtain verification results and repair results; and a chaos test summary report is output based on the verification results and the repair results. The present application improves the comprehensiveness and accuracy of evaluation, and provides reliable support for optimization and improvement of the system.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of network security technology, and more specifically, the embodiments of the present invention relate to a method, apparatus, equipment, medium and product for attack and defense exercises based on chaos engineering. Background Technology

[0002] In today's era of rapid digital technology development, various complex information systems are widely used across industries, becoming crucial support for enterprise operations and societal functioning. The stability and reliability of these systems directly impact business continuity, data security, and user experience. System failures can lead to serious consequences such as business interruption, data loss, and reputational damage, causing significant losses to businesses and society. Therefore, effectively testing the resilience of information systems, proactively identifying potential risks, and enhancing emergency response capabilities have become critical issues that urgently need to be addressed in the field of information technology.

[0003] Chaos engineering, as an emerging technology for ensuring system reliability, has emerged to simulate various real-world anomalies by actively injecting faults into a system. It observes the system's behavior under these fault scenarios, thereby verifying the system's fault tolerance, monitoring mechanisms, and the effectiveness of contingency plans. However, current chaos simulation techniques still have many limitations in practical applications. Regarding fault injection methods, most existing chaos engineering tools only support fault injection based on preset rules. This method cannot realistically reflect the various sudden fault situations that a system might encounter in a complex and ever-changing real-world operating environment, leading to a certain deviation between the simulation results and actual conditions, making it difficult to comprehensively and accurately assess the system's reliability and resilience. Summary of the Invention

[0004] In this context, embodiments of the present invention aim to provide a method, apparatus, device, medium, and product for attack and defense drills based on chaos engineering.

[0005] In a first aspect of the present invention, a method for attack and defense drills based on chaos engineering is provided, comprising:

[0006] The first chaotic fault scenario was obtained using a random algorithm.

[0007] Obtain the faults to be tested that match the first chaotic fault scenario from the predetermined range of faults to be tested; wherein, each fault to be tested corresponds to a fault weight.

[0008] During the process of executing the fault under test in descending order of fault weight, the system status parameters are captured in real time.

[0009] The fault weight of the fault under test that has finished execution is downgraded, and the downgraded fault under test is added back to the scope of faults under test.

[0010] When a completion command is detected, the effect is verified and the system is repaired based on the system status parameters to obtain the verification results and repair results.

[0011] Based on the verification results and the repair results, output a chaos test summary report.

[0012] In one embodiment of this implementation, the method for determining the range of the fault to be tested is specifically as follows:

[0013] Identify multiple chaotic fault scenarios;

[0014] Determine the scope of components and constraints for injectable faults in each chaotic fault scenario.

[0015] Based on the component scope and constraints of each chaotic fault scenario, the fault to be tested corresponding to each chaotic fault scenario is determined.

[0016] The range of faults to be tested is constructed based on the faults to be tested corresponding to each chaotic fault scenario.

[0017] In one embodiment of this implementation, the system status parameters include at least basic availability indicators, performance degradation indicators, fault tolerance indicators, recovery capability indicators, and business impact indicators.

[0018] In one embodiment of this implementation, after adding the downgraded abnormal scenario back to the scope of the fault to be tested, the method further includes:

[0019] Check if a completion command has been received;

[0020] If the completion instruction is not received, the random algorithm is used to obtain the second chaotic fault scenario; and the fault to be tested that matches the second chaotic fault scenario is obtained from the updated range of faults to be tested; and the process of capturing system state parameters in real time during the process of executing the faults to be tested in descending order of fault weight is executed, up to the step of adding the downgraded faults to be tested back to the range of faults to be tested.

[0021] In one embodiment of this implementation, the step of verifying the effect and repairing the system based on the system state parameters to obtain verification results and repair results includes:

[0022] The system problem is obtained by analyzing the system state parameters.

[0023] The system problem was repaired, and the repair results were obtained;

[0024] The effectiveness was verified based on the system problem and the repair results, and the verification results were obtained.

[0025] In one embodiment of this implementation, the step of outputting a chaos test summary report based on the verification results and the repair results includes:

[0026] Output the chaos test results based on the verification results and the repair results;

[0027] The chaos test results are processed to obtain a chaos test summary report; wherein the chaos test results include at least the test objective, execution scenario, system response indicators, root cause analysis and improvement suggestions.

[0028] In a second aspect of the present invention, a chaos engineering-based attack and defense exercise device is provided, comprising:

[0029] The first acquisition unit is used to acquire the first chaotic fault scenario using a random algorithm;

[0030] The second acquisition unit is used to acquire a test fault that matches the first chaotic fault scenario from a predetermined range of test faults; wherein, one test fault corresponds to one fault weight.

[0031] The capture unit is used to capture system status parameters in real time during the process of executing the fault to be tested in descending order of fault weight;

[0032] The degradation unit is used to downgrade the fault weight of the fault under test after the execution is completed, and to re-add the downgraded fault under test to the scope of faults under test.

[0033] The verification unit is used to perform effect verification and system repair based on the system status parameters when a completion command is detected, and to obtain verification results and repair results.

[0034] The output unit is used to output a chaos test summary report based on the verification results and the repair results.

[0035] In a third aspect of the present invention, a computing device is provided, the computing device comprising: at least one processor, a memory, and an input / output unit; wherein the memory is used to store a computer program, and the processor is used to invoke the computer program stored in the memory to execute the method described in any one aspect.

[0036] In a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising instructions which, when executed on a computer, cause the computer to perform the method described in any one of the first aspects.

[0037] In a fifth aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0038] The attack and defense exercise method, apparatus, equipment, medium, and product based on chaos engineering according to embodiments of the present invention can utilize random algorithms to obtain a first chaotic fault scenario, simulating a highly random and complex real fault environment. This overcomes the limitations of fixed and singular fault scenarios in traditional testing, allowing the system to be tested in a wider range of more realistic scenarios, thereby comprehensively uncovering potential problems and weaknesses in the system. By executing the matched faults to be tested in an orderly manner according to fault weights, priority can be given to testing critical faults, accurately locating core factors affecting system reliability and avoiding the omission of important fault points. During execution, system state parameters are captured in real time, comprehensively recording various system reactions to faults, including performance changes and functional anomalies, providing detailed evidence for accurately assessing system resilience. Furthermore, the weight of the faults to be tested after execution is downgraded and re-included in the testing scope, forming a dynamic cyclical test of faults. This ensures that the system is continuously tested at different stages, further improving the comprehensiveness and accuracy of the assessment, and ultimately providing reliable support for system optimization and improvement. Attached Figure Description

[0039] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:

[0040] Figure 1 This is a flowchart illustrating an embodiment of the attack and defense drill method based on chaos engineering provided by the present invention.

[0041] Figure 2 A schematic diagram of the structure of an attack and defense exercise device based on chaos engineering provided in an embodiment of the present invention;

[0042] Figure 3 A schematic diagram of the structure of a medium according to an embodiment of the present invention is shown.

[0043] Figure 4 A schematic diagram of the structure of a computing device according to an embodiment of the present invention is shown.

[0044] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0045] The principles and spirit of the invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0046] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0047] According to an embodiment of the present invention, a method, apparatus, equipment, medium and product for attack and defense drills based on chaos engineering are proposed.

[0048] It should be noted that the number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0049] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0050] Exemplary methods

[0051] The following is for reference. Figure 1 , Figure 1 This is a flowchart illustrating an attack and defense exercise method based on chaos engineering according to an embodiment of the present invention. It should be noted that the embodiments of the present invention can be applied to any applicable scenario.

[0052] Figure 1 The flowchart of the attack and defense exercise method based on chaos engineering provided in one embodiment of the present invention includes:

[0053] Step S101: Use a random algorithm to obtain the first chaotic fault scenario.

[0054] In this embodiment, the random algorithm can be a numerical probability algorithm, the Las Vegas algorithm, the Monte Carlo algorithm, or the Sherwood algorithm, etc. Specifically, the method for using a random algorithm to obtain the first chaotic fault scenario can be as follows:

[0055] Initialize the weighted random selector; verify that at least one element with positive priority exists; preprocess the weights and construct a cumulative weight list; store the total weights for subsequent calculations; perform weighted random selection; generate a random number and find the first chaotic fault scenario corresponding to the random number among multiple pre-generated chaotic fault scenarios.

[0056] Step S102: Obtain the fault to be tested that matches the first chaotic fault scenario from the predetermined range of faults to be tested.

[0057] In this embodiment, each fault to be tested corresponds to a fault weight. When a fault is executed, fault scenarios with higher fault weights are triggered first. The fault weights are assigned initial values ​​using the FMEA algorithm. Using fault weight as a crucial condition for triggering a fault avoids inefficient testing caused by pure randomness and provides more realistic scenario coverage for system resilience assessment.

[0058] As an optional implementation method, the specific method for determining the range of the fault to be tested is as follows:

[0059] Identify multiple chaotic fault scenarios;

[0060] Determine the scope of components and constraints for injectable faults in each chaotic fault scenario.

[0061] Based on the component scope and constraints of each chaotic fault scenario, the fault to be tested corresponding to each chaotic fault scenario is determined.

[0062] The range of faults to be tested is constructed based on the faults to be tested corresponding to each chaotic fault scenario.

[0063] This implementation method, which determines the scope of the fault to be tested through specific means, can greatly improve the effectiveness of attack and defense exercises. First, it identifies multiple chaotic fault scenarios to comprehensively cover all kinds of complex situations the system may encounter, ensuring no omissions in the assessment. Then, for each scenario, it defines the scope of components where faults can be injected and the constraints, accurately locating the fault's point of action, avoiding blind testing, and improving testing efficiency. Based on these conditions, it determines the corresponding faults to be tested and constructs their scope, making fault selection more scientific and targeted. This allows for in-depth exploration of potential problems in different scenarios and with different components, thereby comprehensively and accurately assessing the system's reliability and resilience, providing a strong basis for system optimization.

[0064] In this embodiment, a control layer determines various chaotic fault scenarios. This step mainly involves the basic fault layer for chaotic faults, which supports over 200 fault injection modes (network latency, service degradation, resource preemption, etc.). This step prepares for all chaotic fault scenarios.

[0065] In this embodiment of the application, the fault range selected for testing is clearly defined. In project management, this step is called scope management to avoid scope spread. The goal here is also to avoid the spread of fault range.

[0066] In addition, this step includes a range constraint on the fault scope. The fault scope constraint is set according to the chaotic fault scenario. If the middleware is being tested, then it is the chaotic fault scenario corresponding to the middleware. For the limited fault scenario, it includes, but is not limited to, defining the scope of components that can be injected with faults (such as non-core links, pre-production environment) and constraints (such as prohibiting the impact on the production database).

[0067] Step S103: During the process of executing the test fault in descending order of fault weight, system status parameters are captured in real time.

[0068] In this embodiment of the application, the system status parameters include at least basic availability indicators, performance degradation indicators, fault tolerance indicators, recovery capability indicators, and business impact indicators.

[0069] Specifically:

[0070] 1) Basic availability metrics: System / service availability (such as SLA compliance rate), error rate, request success rate, etc., which reflect the overall stability of the system.

[0071] 2) Performance degradation metrics: response time latency, throughput decrease rate, and resource utilization (CPU / memory / network) fluctuation threshold, which measure the extent of performance degradation after fault injection.

[0072] 3) Fault tolerance indicators: Fault isolation success rate, accuracy of circuit breaker triggering, and time consumption for switching redundant components, etc., to verify the effectiveness of the system's elastic design.

[0073] 4) Recovery capability indicators: Time to self-heal (MTTR), frequency of manual intervention, and data consistency recovery time, to assess the system's recovery agility.

[0074] 5) Business impact metrics: core transaction interruption rate, degree of user experience degradation (such as page load failure rate), quantifying the actual impact of failures on business.

[0075] Step S104: Downgrade the fault weight of the fault under test that has finished execution, and add the downgraded fault under test back to the scope of faults under test.

[0076] In this embodiment of the application, the fault weight of the fault to be tested after execution is downgraded, so as to avoid repeated testing of low-risk or verified fault scenarios, thereby improving the efficiency of chaos experiments.

[0077] After adjusting the weights in this stage, a second chaos test is conducted. The weight of the injected fault is reduced based on the historical execution frequency of the scenario and the monitoring effect after fault injection, prioritizing the triggering of new or high-risk faults to be tested. This ensures that more potential vulnerabilities are covered in long-term testing, while avoiding resource waste and forming an adaptive and optimized testing loop.

[0078] As an optional implementation, after step S104, the following steps may also be performed:

[0079] Check if a completion command has been received;

[0080] If the completion instruction is not received, the random algorithm is used to obtain the second chaotic fault scenario; and the fault to be tested that matches the second chaotic fault scenario is obtained from the updated range of faults to be tested; and steps S103 to S104 are executed.

[0081] This implementation method, after re-adding the downgraded abnormal scenario to the test fault range, flexibly controls the exercise process by detecting whether a completion command has been received. If no completion command is received, a second chaotic fault scenario is obtained using a random algorithm. This design allows the system to continuously face diverse chaotic fault challenges, breaking the limitations of single and fixed fault scenarios in traditional exercises. This greatly expands the breadth and depth of system testing, ensuring that the system can be fully trained under different types and combinations of fault scenarios. Matching faults to be tested are obtained from the updated test fault range, and subsequent operations are performed, including execution according to fault weight order, real-time capture of system status parameters, downgrading the weight of completed faults, and re-adding them, forming a dynamic and cyclical testing mechanism. This mechanism can continuously uncover potential problems in the system under different fault interactions, accurately locate system weaknesses, provide strong support for a comprehensive and in-depth evaluation of the system's reliability and resilience, and also provide rich and accurate evidence for continuous system optimization and improvement.

[0082] In this embodiment of the application, the system status is captured in real time and the experimental hypothesis is verified to ensure that the system behavior can be fully observed after fault injection; and the observation results are used as the basis for the observation.

[0083] Step S105: When a completion command is detected, the effect is verified and the system is repaired based on the system status parameters to obtain the verification result and the repair result.

[0084] As an optional implementation, step S105 verifies the effect and repairs the system based on the system state parameters. The methods for obtaining the verification results and repair results may include:

[0085] The system problem is obtained by analyzing the system state parameters.

[0086] The system problem was repaired, and the repair results were obtained;

[0087] The effectiveness was verified based on the system problem and the repair results, and the verification results were obtained.

[0088] This implementation method, through meticulous analysis of system state parameters, precisely locates system problems, avoiding omissions that may occur in traditional methods due to incomplete or inaccurate parameter analysis. It delves into various potential defects exposed by the system under chaotic fault scenarios, providing a clear direction for subsequent repairs. Repairing the identified system problems ensures targeted efforts, improving efficiency and quality, effectively restoring normal system operation, and reducing the impact of faults on system services. Finally, effectiveness verification based on system problems and repair results comprehensively evaluates the effectiveness of the repair measures, determining whether the system has truly solved potential problems and improved its fault-resistance capabilities. This provides a reliable guarantee for continuous system optimization and stable operation, enabling the system to possess stronger reliability and resilience in complex and ever-changing operating environments.

[0089] In this embodiment, the focus is on closed-loop verification after fault repair to ensure that the root cause of the problem has been completely resolved without introducing new risks. Based on the chaos test results, the team implements repairs on the identified vulnerabilities and verifies the effectiveness of the repair measures.

[0090] Step S106: Output a chaos test summary report based on the verification results and the repair results.

[0091] In this embodiment of the application, after the repair and verification are completed, the chaos test results will be output in a structured manner at this stage to objectively assess the system's resilience and guide subsequent optimization.

[0092] The chaos test summary report covers test objectives, execution scenarios, system response metrics (such as fault recovery time, error rate, and business fluctuation range), root cause analysis, and improvement suggestions. Based on the comparison between monitoring baseline data and fault injection results, it quantitatively verifies the system's resilience (such as the percentage improvement in availability).

[0093] As an optional implementation, step S106, which outputs a chaos test summary report based on the verification results and the repair results, may include:

[0094] Output the chaos test results based on the verification results and the repair results;

[0095] The chaos test results are processed to obtain a chaos test summary report; wherein the chaos test results include at least the test objective, execution scenario, system response indicators, root cause analysis and improvement suggestions.

[0096] This implementation method, which outputs chaotic test results based on verification and repair results, comprehensively integrates key information from the system's chaotic engineering attack and defense exercises. It covers multiple dimensions, from the achievement of test objectives to the system's actual response performance, providing a rich and accurate data foundation for subsequent analysis. The chaotic test results are processed to generate a summary report, clearly including core elements such as test objectives, execution scenarios, system response indicators, root cause analysis, and improvement suggestions, making the report complete and well-organized. This not only facilitates relevant personnel in quickly understanding the overall test situation and accurately grasping the system's performance and problems under complex fault scenarios, but also enables targeted improvement strategies based on root cause analysis and efficient system optimization and upgrades based on improvement suggestions. Ultimately, this comprehensively improves the system's reliability and resilience, ensuring stable operation under various uncertain environments.

[0097] In this embodiment, the completion of the above steps marks the official conclusion of this special test, and closed-loop test management must be completed simultaneously. Core tasks include: terminating all fault injection operations and reclaiming resources, cleaning up temporary configurations; generating a test summary report; archiving test data to the knowledge base; and updating the fault scenario case set. Simultaneously, it is necessary to ensure the system fully recovers to a stable state, avoiding residual anomalies from affecting business operations, and ultimately forming an iteratively reusable test baseline.

[0098] For example, actual test data shows (based on the production system of a joint-stock bank) that after adopting random scenarios and dynamic weight adjustments:

[0099] 1. The time from fault detection to recovery has been reduced by 83% (from an average of 8 minutes and 12 seconds to 1 minute and 24 seconds);

[0100] 2. During system recovery after fault injection, errors caused by human negligence or defects in automated mechanisms are reduced by 67%;

[0101] 3. By combining random scenario algorithms with dynamic weights in scheduling, the system resource utilization rate is improved by 29%.

[0102] Existing chaos tests all use fixed-scenario testing and have never adopted a randomized fault selection model. In previous chaos tests, the weights of faults were not adjusted after the test, so the fault scenarios selected were basically the same every time. By adopting the dynamic weight adjustment combined with random fault triggering mode of this invention, the weights of fault scenarios that have been executed and have no problems can be reduced. Then, in the next iteration, these fault scenarios that have no problems do not need to be executed again, and other necessary fault scenarios are selected for execution.

[0103] This invention ensures the system is continuously tested at different stages, further improving the comprehensiveness and accuracy of the evaluation, and ultimately providing reliable support for system optimization and improvement. Furthermore, this invention can uncover potential problems in different scenarios and with different components, thereby comprehensively and accurately assessing the system's reliability and resilience, providing a strong basis for system optimization. In addition, this invention can continuously uncover potential problems under different fault interactions, accurately locating weak points in the system, providing a strong guarantee for a comprehensive and in-depth assessment of the system's reliability and resilience, and also providing rich and accurate evidence for continuous system optimization and improvement. Furthermore, this invention can comprehensively evaluate the effectiveness of remedial measures, determining whether the system has truly solved potential problems and improved its ability to cope with faults. Moreover, this invention allows relevant personnel to quickly understand the overall testing situation, accurately grasp the system's performance and problems under complex fault scenarios, and formulate targeted improvement strategies based on root cause analysis, efficiently promoting system optimization and upgrades based on improvement suggestions, thereby comprehensively improving the system's reliability and resilience.

[0104] Exemplary device

[0105] After introducing the method of exemplary embodiments of the present invention, the following references are made. Figure 2 An exemplary embodiment of the present invention provides a chaos engineering-based attack and defense exercise device, which includes:

[0106] The first acquisition unit 201 is used to acquire the first chaotic fault scenario using a random algorithm;

[0107] The second acquisition unit 202 is used to acquire a test fault that matches the first chaotic fault scenario from a predetermined range of test faults; wherein, one test fault corresponds to one fault weight.

[0108] The capture unit 203 is used to capture system status parameters in real time during the execution of the fault to be tested in descending order of fault weight; the system status parameters include at least basic availability indicators, performance degradation indicators, fault tolerance indicators, recovery capability indicators, and business impact indicators.

[0109] The downgrade unit 204 is used to downgrade the fault weight of the fault under test after the execution is completed, and to re-add the downgraded fault under test to the scope of faults under test.

[0110] Verification unit 205 is used to perform effect verification and system repair based on the system status parameters when a completion command is detected, and obtain verification results and repair results;

[0111] Output unit 206 is used to output a chaos test summary report based on the verification results and the repair results.

[0112] As an optional implementation method, the specific method for determining the range of the fault to be tested is as follows:

[0113] Identify multiple chaotic fault scenarios;

[0114] Determine the scope of components and constraints for injectable faults in each chaotic fault scenario.

[0115] Based on the component scope and constraints of each chaotic fault scenario, the fault to be tested corresponding to each chaotic fault scenario is determined.

[0116] The range of faults to be tested is constructed based on the faults to be tested corresponding to each chaotic fault scenario.

[0117] This implementation method, which determines the scope of the fault to be tested through specific means, can greatly improve the effectiveness of attack and defense exercises. First, it identifies multiple chaotic fault scenarios to comprehensively cover all kinds of complex situations the system may encounter, ensuring no omissions in the assessment. Then, for each scenario, it defines the scope of components where faults can be injected and the constraints, accurately locating the fault's point of action, avoiding blind testing, and improving testing efficiency. Based on these conditions, it determines the corresponding faults to be tested and constructs their scope, making fault selection more scientific and targeted. This allows for in-depth exploration of potential problems in different scenarios and with different components, thereby comprehensively and accurately assessing the system's reliability and resilience, providing a strong basis for system optimization.

[0118] As an optional implementation, the degradation unit 204 is also used for:

[0119] After adding the downgraded abnormal scenario back to the scope of the fault under test, check whether a completion command has been received.

[0120] If the completion instruction is not received, the random algorithm is used to obtain the second chaotic fault scenario; and the fault to be tested that matches the second chaotic fault scenario is obtained from the updated range of faults to be tested; and the capture unit 203 captures system state parameters in real time during the execution of the faults to be tested in descending order of fault weight; and the downgrade unit 204 downgrades the fault weight of the fault to be tested after execution and adds the downgraded fault to be tested back to the range of faults to be tested.

[0121] This implementation method, after re-adding the downgraded abnormal scenario to the test fault range, flexibly controls the exercise process by detecting whether a completion command has been received. If no completion command is received, a second chaotic fault scenario is obtained using a random algorithm. This design allows the system to continuously face diverse chaotic fault challenges, breaking the limitations of single and fixed fault scenarios in traditional exercises. This greatly expands the breadth and depth of system testing, ensuring that the system can be fully trained under different types and combinations of fault scenarios. Matching faults to be tested are obtained from the updated test fault range, and subsequent operations are performed, including execution according to fault weight order, real-time capture of system status parameters, downgrading the weight of completed faults, and re-adding them, forming a dynamic and cyclical testing mechanism. This mechanism can continuously uncover potential problems in the system under different fault interactions, accurately locate system weaknesses, provide strong support for a comprehensive and in-depth evaluation of the system's reliability and resilience, and also provide rich and accurate evidence for continuous system optimization and improvement.

[0122] As an optional implementation, the verification unit 205 performs effect verification and system repair based on the system state parameters, and the specific method for obtaining the verification results and repair results can be as follows:

[0123] The system problem is obtained by analyzing the system state parameters.

[0124] The system problem was repaired, and the repair results were obtained;

[0125] The effectiveness was verified based on the system problem and the repair results, and the verification results were obtained.

[0126] This implementation method, through meticulous analysis of system state parameters, precisely locates system problems, avoiding omissions that may occur in traditional methods due to incomplete or inaccurate parameter analysis. It delves into various potential defects exposed by the system under chaotic fault scenarios, providing a clear direction for subsequent repairs. Repairing the identified system problems ensures targeted efforts, improving efficiency and quality, effectively restoring normal system operation, and reducing the impact of faults on system services. Finally, effectiveness verification based on system problems and repair results comprehensively evaluates the effectiveness of the repair measures, determining whether the system has truly solved potential problems and improved its fault-resistance capabilities. This provides a reliable guarantee for continuous system optimization and stable operation, enabling the system to possess stronger reliability and resilience in complex and ever-changing operating environments.

[0127] As an optional implementation, the output unit 206 may output a chaos test summary report based on the verification results and the repair results in the following specific ways:

[0128] Output the chaos test results based on the verification results and the repair results;

[0129] The chaos test results are processed to obtain a chaos test summary report; wherein the chaos test results include at least the test objective, execution scenario, system response indicators, root cause analysis and improvement suggestions.

[0130] This implementation method, which outputs chaotic test results based on verification and repair results, comprehensively integrates key information from the system's chaotic engineering attack and defense exercises. It covers multiple dimensions, from the achievement of test objectives to the system's actual response performance, providing a rich and accurate data foundation for subsequent analysis. The chaotic test results are processed to generate a summary report, clearly including core elements such as test objectives, execution scenarios, system response indicators, root cause analysis, and improvement suggestions, making the report complete and well-organized. This not only facilitates relevant personnel in quickly understanding the overall test situation and accurately grasping the system's performance and problems under complex fault scenarios, but also enables targeted improvement strategies based on root cause analysis and efficient system optimization and upgrades based on improvement suggestions. Ultimately, this comprehensively improves the system's reliability and resilience, ensuring stable operation under various uncertain environments.

[0131] This invention ensures the system is continuously tested at different stages, further improving the comprehensiveness and accuracy of the evaluation, and ultimately providing reliable support for system optimization and improvement. Furthermore, this invention can uncover potential problems in different scenarios and with different components, thereby comprehensively and accurately assessing the system's reliability and resilience, providing a strong basis for system optimization. In addition, this invention can continuously uncover potential problems under different fault interactions, accurately locating weak points in the system, providing a strong guarantee for a comprehensive and in-depth assessment of the system's reliability and resilience, and also providing rich and accurate evidence for continuous system optimization and improvement. Furthermore, this invention can comprehensively evaluate the effectiveness of remedial measures, determining whether the system has truly solved potential problems and improved its ability to cope with faults. Moreover, this invention allows relevant personnel to quickly understand the overall testing situation, accurately grasp the system's performance and problems under complex fault scenarios, and formulate targeted improvement strategies based on root cause analysis, efficiently promoting system optimization and upgrades based on improvement suggestions, thereby comprehensively improving the system's reliability and resilience.

[0132] Exemplary media

[0133] After introducing the methods and apparatus of exemplary embodiments of the present invention, the following references are made. Figure 3 A computer-readable storage medium according to exemplary embodiments of the present invention will be described, please refer to... Figure 3The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it implements the steps described in the above method implementation, such as: using a random algorithm to obtain a first chaotic fault scenario; obtaining a fault to be tested that matches the first chaotic fault scenario from a predetermined range of faults to be tested; wherein, one fault to be tested corresponds to one fault weight; during the execution of the faults to be tested in descending order of fault weight, system state parameters are captured in real time; the fault weight of the fault to be tested after execution is downgraded, and the downgraded fault to be tested is added back to the range of faults to be tested; when a completion instruction is detected, effect verification and system repair are performed based on the system state parameters to obtain verification results and repair results; and a chaos test summary report is output based on the verification results and the repair results. The specific implementation methods of each step will not be repeated here.

[0134] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0135] Exemplary computing device

[0136] After introducing the methods, apparatus, and media of exemplary embodiments of the present invention, the following references are made. Figure 4 A computing device for attack and defense exercises based on chaos engineering, according to an exemplary embodiment of the present invention.

[0137] Figure 4 A block diagram is shown of an exemplary computing device 40 suitable for implementing embodiments of the present invention. The computing device 40 may be a computer system or a server. Figure 4 The computing device 40 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0138] like Figure 4 As shown, the components of computing device 40 may include, but are not limited to: one or more processors or processing units 401, system memory 402, and bus 403 connecting different system components (including system memory 402 and processing unit 401).

[0139] The computing device 40 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device 40, including volatile and non-volatile media, and removable and non-removable media.

[0140] System memory 402 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 4021 and / or cache memory 4022. Computing device 40 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, ROM 4023 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 4 (Not shown in the image, usually referred to as "hard drive"). Although not shown in... Figure 4 The diagram illustrates that disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disc drives for reading and writing to removable non-volatile optical discs (e.g., CD-ROMs, DVD-ROMs, or other optical media) can be provided. In these cases, each drive can be connected to bus 403 via one or more data media interfaces. System memory 402 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0141] A program / utility 4025 having a set (at least one) of program modules 4024 may be stored, for example, in system memory 402, and such program modules 4024 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment. Program modules 4024 typically perform the functions and / or methods described in the embodiments of the present invention.

[0142] The computing device 40 can also communicate with one or more external devices 404 (such as a keyboard, pointing device, display, etc.). This communication can be performed via the input / output (I / O) interface 405. Furthermore, the computing device 40 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 406. Figure 4 As shown, network adapter 406 communicates with other modules of computing device 40 (such as processing unit 401) via bus 403. It should be understood that, although... Figure 4 As not shown, it can be used in conjunction with computing device 40 with other hardware and / or software modules.

[0143] The processing unit 401 executes various functional applications and data processing by running programs stored in the system memory 402. For example, it uses a random algorithm to obtain a first chaotic fault scenario; it obtains a fault to be tested that matches the first chaotic fault scenario from a predetermined range of faults to be tested; wherein, each fault to be tested corresponds to a fault weight; during the execution of the faults to be tested in descending order of fault weight, it captures system state parameters in real time; it downgrades the fault weight of the faults to be tested after execution and adds the downgraded faults to the range of faults to be tested; when a completion instruction is detected, it performs effect verification and system repair based on the system state parameters to obtain verification results and repair results; and it outputs a chaos test summary report based on the verification results and the repair results. The specific implementation methods of each step will not be repeated here. It should be noted that although several units / modules or sub-units / sub-modules of the attack and defense exercise device based on chaos engineering are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of a unit / module described above can be further divided into multiple units / modules for specificity.

[0144] In the description of this invention, it should be noted that the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0145] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0146] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0147] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0149] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0150] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0151] Furthermore, although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0152] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

Claims

1. A method for a chaos engineering-based attack-defense drill, characterized by, The method comprises the following steps: obtaining a first chaotic fault scene by using a random algorithm; obtaining a to-be-tested fault matched with the first chaotic fault scene from a predetermined to-be-tested fault range, wherein one to-be-tested fault corresponds to one fault weight; capturing system state parameters in real time in a process of executing the to-be-tested fault in an order based on fault weights from large to small; downgrading the fault weight of the to-be-tested fault whose execution is completed and re-adding the downgraded to-be-tested fault to the to-be-tested fault range; detecting whether a completion instruction is received; if the completion instruction is not received, obtaining a second chaotic fault scene by using the random algorithm, obtaining a to-be-tested fault matched with the second chaotic fault scene from the updated to-be-tested fault range, and performing the steps of capturing system state parameters in real time in the process of executing the to-be-tested fault in the order based on fault weights from large to small to the step of re-adding the downgraded to-be-tested fault to the to-be-tested fault range; when the completion instruction is detected, performing effect verification and system repair based on the system state parameters to obtain verification results and repair results; outputting a chaotic test summary report based on the verification results and the repair results.

2. The chaos engineering based red teaming method of claim 1, wherein, The to-be-tested fault range is determined in the following manner: determining a plurality of chaotic fault scenes; determining a component range and a constraint condition of each chaotic fault scene in which a fault can be injected; determining a to-be-tested fault corresponding to each chaotic fault scene based on the component range and the constraint condition of each chaotic fault scene; constructing a to-be-tested fault range based on the to-be-tested faults corresponding to each chaotic fault scene.

3. The chaos engineering based red teaming method of claim 1, wherein, The system state parameters at least include a basic availability index, a performance degradation index, a fault tolerance capability index, a recovery capability index, and a business impact index.

4. The chaos engineering based red teaming method of claim 1, wherein, The effect verification and system repair based on the system state parameters to obtain verification results and repair results comprise the following steps: analyzing the system state parameters to obtain system problems; performing system repair on the system problems to obtain repair results; performing effect verification based on the system problems and the repair results to obtain verification results.

5. The chaos engineering based red teaming method of claim 4, wherein, The output of the chaotic test summary report based on the verification results and the repair results comprises the following steps: outputting chaotic test results based on the verification results and the repair results; processing the chaotic test results to obtain a chaotic test summary report, wherein the chaotic test results at least include a test target, an execution scene, a system response index, root cause analysis, and improvement suggestions.

6. A chaos engineering-based attack-defense drill apparatus, characterized by, The method comprises the following steps: a first obtaining unit is configured to obtain a first chaotic fault scene by using a random algorithm; a second obtaining unit is configured to obtain a to-be-tested fault matched with the first chaotic fault scene from a predetermined to-be-tested fault range, wherein one to-be-tested fault corresponds to one fault weight; a capturing unit is configured to capture system state parameters in real time in a process of executing the to-be-tested fault in an order based on fault weights from large to small; The degradation unit is configured to degrade the fault weight of the to-be-tested fault whose execution ends, and re-add the degraded to-be-tested fault to the to-be-tested fault range; the degradation unit is further configured to, after re-adding the degraded abnormal scenario to the to-be-tested fault range, detect whether a completion instruction is received; if the completion instruction is not received, obtain a second chaotic fault scenario by using the random algorithm; and obtain a to-be-tested fault matched with the second chaotic fault scenario from the updated to-be-tested fault range; and the execution capture unit is configured to capture the system state parameter in real time in the process of executing the to-be-tested fault in the order from large to small based on the fault weight, and the degradation unit is configured to degrade the fault weight of the to-be-tested fault whose execution ends, and re-add the degraded to-be-tested fault to the to-be-tested fault range; The verification unit is configured to, when the completion instruction is detected, perform effect verification and system repair based on the system state parameter, to obtain a verification result and a repair result; The output unit is configured to output a chaotic test summary report based on the verification result and the repair result.

7. A computing device, comprising: The computing device comprises: at least one processor, a memory and an input / output unit; wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program stored in the memory to execute the method of any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, It includes instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1-5.

9. A computer program product, characterised in that, It includes a computer program, characterized in that the computer program is executed by a processor to implement the method of any one of claims 1-5.

Images