Software system detection method and device, equipment, medium and product

Abstract

The embodiment of the invention discloses a software system detection method, device and equipment, a medium and a product, and relates to the technical field of cloud computing and financial science and technology. The method comprises the following steps: determining a virtual system matched with a target software system, and determining at least one fault scene matched with the virtual system; in response to an execution instruction of a target service in the virtual system, determining a target fault scene matched with the target service, and injecting the target fault scene into the virtual system; obtaining performance data of the virtual system and business index data of the target business before and after injection of the target fault scene; and determining a detection result of the target software system based on the performance data and the business index data, and determining an optimization strategy of the target software system. According to the scheme provided by the embodiment of the invention, the software system can be quickly and accurately detected, and the stability and the fault-tolerant capability of the software system can be improved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing and financial technology, and in particular to a detection method, device, equipment, medium and product for a software system. Background Art

[0002] With the continuous development of computer technology, software systems such as financial software systems, educational software systems, development software systems, and application software systems have been widely used in the industry; with the advent of the big data era, the amount of data processed by software systems has increased dramatically, placing extremely high demands on software systems.

[0003] How to quickly and accurately test software systems to improve their stability and fault tolerance is a key research issue in the industry. Summary of the Invention

[0004] The present invention provides a software system detection method, device, equipment, medium and product to quickly and accurately detect the software system, so as to improve the stability and fault tolerance of the software system.

[0005] According to one aspect of the present invention, a method for detecting a software system is provided, the method comprising:

[0006] Determining a virtual system that matches the target software system, and determining at least one failure scenario that matches the virtual system;

[0007] In response to an execution instruction of a target service in the virtual system, determining a target failure scenario that matches the target service, and injecting the target failure scenario into the virtual system;

[0008] Acquire performance data of the virtual system before and after injection of the target fault scenario and business indicator data of the target business;

[0009] Based on the performance data and the business indicator data, a detection result of the target software system is determined, and an optimization strategy for the target software system is determined.

[0010] According to another aspect of the present invention, a software system detection device is provided, the device comprising:

[0011] A first determination module is configured to determine a virtual system that matches the target software system and to determine at least one failure scenario that matches the virtual system;

[0012] a second determining module, configured to determine, in response to an execution instruction of a target service in the virtual system, a target fault scenario matching the target service, and inject the target fault scenario into the virtual system;

[0013] An acquisition module is used to acquire the performance data of the virtual system before and after the target fault scenario is injected and the business indicator data of the target business;

[0014] The third determination module is used to determine the detection result of the target software system based on each of the performance data and each of the business indicator data, and determine the optimization strategy of the target software system.

[0015] According to another aspect of the present invention, an electronic device is provided, comprising:

[0016] at least one processor; and

[0017] a memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the software system detection method described in any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the software system detection method according to any embodiment of the present invention when executed.

[0020] According to another aspect of the present invention, a computer program product is provided, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the software system detection method according to any embodiment of the present invention.

[0021] The technical solution of the embodiment of the present invention determines a virtual system that matches the target software system and determines at least one fault scenario that matches the virtual system; in response to the execution instruction of the target business in the virtual system, determines the target fault scenario that matches the target business, and injects the target fault scenario into the virtual system; different fault scenarios can be determined in advance, and the fault scenarios that need to be injected can be clearly identified and injected when executing specific businesses, providing a basis for accurate detection of the target software system; the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business are obtained; the detection result of the target software system is determined based on each of the performance data and each of the business indicator data, and the optimization strategy of the target software system is determined, so that the software system can be detected quickly and accurately, and the stability and fault tolerance of the software system can be improved.

[0022] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 This is a flowchart of a software system detection method provided in accordance with the first embodiment of the present invention;

[0025] Figure 2 This is a flowchart of a software system detection method provided in accordance with the second embodiment of the present invention;

[0026] Figure 3 This is a flowchart of a software system detection method provided in accordance with the third embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of the structure of a detection device of a software system provided according to a fourth embodiment of the present invention;

[0028] Figure 5 The figure is a schematic diagram of the structure of an electronic device for implementing the detection method of the software system according to the embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] Example 1

[0032] Figure 1 This is a flow chart of a software system detection method provided in accordance with the first embodiment of the present invention. This embodiment is applicable to detecting software systems. The method can be executed by a detection device for a software system. The detection device for the software system can be implemented in the form of hardware and / or software. The detection device for the software system can be configured in electronic devices such as computers, servers, or tablet computers. Figure 1 As shown, the method includes:

[0033] Step 110: Determine a virtual system that matches the target software system, and determine at least one fault scenario that matches the virtual system.

[0034] Among them, the target software system can be a financial software system, such as a cross-border payment system, a financial management system or a securities trading system; it can also be an educational software system, such as an online teaching system; it can also be a development software system, such as an online software development platform or a cloud laboratory, etc., which is not limited in this embodiment.

[0035] Optionally, in this embodiment, during the detection (also referred to as testing) of a target software system, for example, a target financial system, a virtual system matching the target software system may be determined first. For example, all parameters of the target software system may be copied, and a virtual system matching the target software system may be created in a virtual space.

[0036] Furthermore, it is possible to determine each fault scenario that matches the created virtual system; in an optional implementation of this embodiment, each fault scenario can be determined based on the different businesses that the target software system can handle; for example, if the business handled by the target software system is a third-party payment business, then the fault scenario can be a simulated bank or third-party payment gateway occasional failure or a simulated extreme load failure during holidays, etc., which is not limited in this embodiment.

[0037] It can be understood that, in this embodiment, a service in the software system may match one or more failure scenarios.

[0038] Step 120 : In response to an execution instruction of a target service in the virtual system, determine a target fault scenario that matches the target service, and inject the target fault scenario into the virtual system.

[0039] In this embodiment, the target business in the virtual system can be any business that the target software system can handle. For example, if the target software system is a financial software system, then the target business can be a payment business, an interest settlement business, or a loan business, etc., which is not limited in this embodiment.

[0040] Optionally, in this embodiment, after receiving the execution instruction of the target business in the virtual system, a target fault scenario matching the target business may be further determined, and further, the determined target fault scenario may be injected into the virtual system.

[0041] In an optional implementation of this embodiment, after receiving the execution instruction of the target service, the target service can be further parsed to determine the specific content, execution purpose, or execution time of the target service. Furthermore, based on the determined information, each fault scenario matching the target service can be determined, and each fault scenario can be determined as a target fault scenario. Furthermore, the target fault scenario can be injected into the virtual system. For example, the fault scenario can be written into the configuration file of the virtual system.

[0042] Step 130: Acquire the performance data of the virtual system before and after the target fault scenario is injected and the business indicator data of the target business.

[0043] Optionally, in this embodiment, the performance data of the virtual system and the business indicator data of the target business can be obtained in real time within a period of time before the target fault scenario matching the target business is determined and injected into the virtual system, for example, five minutes, or ten minutes; and the performance data of the virtual system and the business indicator data of the target business can also be obtained in real time within a period of time after the target fault scenario matching the target business is determined and injected into the virtual system, for example, three minutes, five minutes, or ten minutes.

[0044] Step 140: Determine a detection result of the target software system based on the performance data and the business indicator data, and determine an optimization strategy for the target software system.

[0045] Optionally, in this embodiment, after obtaining the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business, the performance data of the virtual system and the business indicator data of the target business obtained before and after the injection of the target fault can be compared respectively. Furthermore, the impact of the injected target fault scenario on the virtual system can be determined based on the comparison results, that is, the detection results of the target software system can be determined based on the differences in the performance data of the virtual system and the business indicator data of the target business obtained before and after the injection of the target fault. Furthermore, the optimization strategy adapted to the current target software system, that is, the software system with the target fault, can be determined based on the detection results.

[0046] The technical solution of this embodiment is to determine a virtual system that matches the target software system and at least one fault scenario that matches the virtual system; in response to the execution instruction of the target business in the virtual system, determine the target fault scenario that matches the target business, and inject the target fault scenario into the virtual system; different fault scenarios can be determined in advance, and the fault scenarios that need to be injected can be clearly identified and injected when executing specific businesses, providing a basis for accurate detection of the target software system; obtain the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business; determine the detection result of the target software system based on each of the performance data and each of the business indicator data, and determine the optimization strategy of the target software system, so that the software system can be detected quickly and accurately, and the stability and fault tolerance of the software system can be improved.

[0047] Example 2

[0048] Figure 2 This is a flow chart of a software system detection method provided according to the second embodiment of the present invention. This embodiment is a further refinement of the above technical solution. The technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 2 As shown, the method includes:

[0049] Step 210: Obtain system data of the target software system, perform modeling based on the system data to obtain the virtual system; and determine each fault scenario based on the performance indicator range of the target software system.

[0050] The system data includes at least one of the following: configuration data, operation data, log data, and sensor data.

[0051] Optionally, in this embodiment, during the detection of the target software system, system data of the target software system can be obtained, for example, configuration data, operation data, log data of the target software system or sensor data connected to the target software system (for example, image sensor data, signature pen or mouse, etc.) can be obtained. Furthermore, the target software system can be modeled based on the obtained system data. For example, a virtual system can be built in a virtual space based on the obtained system data.

[0052] Furthermore, each fault scenario can be determined based on the performance indicator range of the target software system; illustratively, the performance indicator range of the target software system can be the normal range of performance indicator parameters such as transaction success rate, TPS (Transactions Per Second), and response latency.

[0053] In an example of this embodiment, a system steady-state hypothesis can be established based on business requirements to determine the normal range of key performance indicators (such as transaction success rate, TPS, response delay, etc.); further, experimental trigger scenarios can be set, which can include, for example, high-risk scenarios such as sudden increase in transaction volume (simulating extreme load during holidays, etc.), interface dependency anomalies (simulating internal service interface return delays or errors), and third-party payment channel instability (simulating occasional failures of banks or third-party payment gateways) to cover failure scenarios that the financial system may encounter in a real environment.

[0054] The advantage of this setting is that various fault scenarios can be quickly obtained, which helps in the subsequent detection of the target software system.

[0055] Step 220: parse the execution instructions of the target business to determine the execution content of the target business, and determine the target fault scenario based on the execution content; determine the target location area to be injected into the virtual system based on the fault information of the target fault scenario, and write the target fault scenario into the target location area.

[0056] The target location area includes: application layer, database layer, network layer, file system or external dependency.

[0057] Optionally, in this embodiment, after determining each fault scenario, if an execution instruction of the target business in the virtual system is received, the execution instruction can be parsed to determine the execution content of the target business (for example, interest calculation, profit analysis, or financial product recommendation, etc.). Further, the target fault scenario can be determined based on the execution content; for example, the target fault scenario can be determined from the preset fault relationship between each business and the fault scenario based on the execution content.

[0058] Furthermore, the target location area for injecting the target fault scenario into the virtual system can be determined based on the fault information of the target fault scenario (for example, extreme load, extended response time, or high memory usage, etc.); for example, if the fault information of the target fault scenario is extended response time, then the target location area can be the network layer; if the fault information of the target fault scenario is high memory usage, then the target location area can be the application layer or the file system; further, the target fault scenario can be injected into the target location area.

[0059] The advantage of this setting is that it can quickly determine the fault scenario that matches the target business being executed and inject it, which can help with subsequent detection of the target software system.

[0060] Step 230: Acquire the performance data of the virtual system before and after the target fault scenario is injected and the business indicator data of the target business.

[0061] Optionally, in this embodiment, obtaining the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business may include: determining a data collection point in the virtual system, and obtaining, at the data collection point, first performance data of the virtual system and first business indicator data of the target business within a first preset time period before the injection of the target fault scenario; and obtaining, at the data collection point, second performance data of the virtual system and second business indicator data of the target business within a second preset time period after the injection of the target fault scenario.

[0062] The data collection points may be matched with the target location area. For example, a data collection point may be deployed in each location area of ​​the virtual system; data collection points may also be deployed at key nodes of business response in the virtual system, which is not limited in this embodiment.

[0063] In this embodiment, the first preset time period can be one minute, three minutes or ten minutes before the target fault scenario is injected into the virtual system; the second preset time period can be one minute, three minutes or ten minutes after the target fault scenario is injected into the virtual system, etc., which is not limited in this embodiment.

[0064] It should be noted that the first performance data, the first business indicator data of the target business, the second performance data, and the second business indicator data of the target business involved in this embodiment are only for distinguishing the performance data and business indicator data obtained before and after fault injection, and are not a limitation of this embodiment.

[0065] In an optional implementation of this embodiment, the first performance data of the virtual system and the first business indicator data of the target business within a first preset time period before the injection of the target fault scenario can be obtained through a data collection point; the second performance data of the virtual system and the second business indicator data of the target business within a second preset time period after the injection of the target fault scenario can be obtained through a data collection point.

[0066] The advantage of this setting is that the detection results of the virtual system, that is, the detection results of the target software system, are determined by comparing the performance data before and after the target fault scenario is injected and the business indicator data.

[0067] Step 240: Determine the detection result of the target software system based on the performance data and the business indicator data, and determine the optimization strategy of the target software system.

[0068] Optionally, in this embodiment, after obtaining the first performance data, first business indicator data, second performance data and second business indicator data before and after the injection of the target fault scenario, the first performance data and the second performance data can be further compared to obtain a first comparison result, and the first business indicator data and the second business indicator data can be compared to obtain a second comparison result; if it is determined that the first comparison result and the second comparison result are both within the preset range, then it can be determined that the target fault scenario has little impact on the virtual system, that is, the target software system has passed the test under the target fault scenario; if it is determined that the first comparison result or the second comparison result is both outside the preset range, then it can be determined that the target fault scenario has a greater impact on the virtual system, that is, the target software system has failed the test under the target fault scenario.

[0069] The solution of this embodiment can compare the first performance data with the second performance data to obtain a first comparison result, and compare the first business indicator data with the second business indicator data to obtain a second comparison result. Furthermore, based on the first comparison result and the second comparison result, it is quickly determined whether the target software system detection in the target fault scenario is qualified.

[0070] Example 3

[0071] Figure 3 This is a flow chart of a software system detection method provided according to the third embodiment of the present invention. This embodiment is a further refinement of the above technical solution. The technical solution in this embodiment can be combined with various optional solutions in one or more of the above embodiments. Figure 3 As shown, the method includes:

[0072] Step 310: Determine a virtual system that matches the target software system, and determine at least one fault scenario that matches the virtual system.

[0073] Step 320: In response to an execution instruction of a target service in the virtual system, determine a target fault scenario that matches the target service, and inject the target fault scenario into the virtual system.

[0074] Step 330: Acquire the performance data of the virtual system before and after the target fault scenario is injected and the business indicator data of the target business.

[0075] Step 340: pre-process each of the performance data and each of the business indicator data, and input the pre-processed data into the pre-trained target machine learning model to obtain a fault detection result, and determine the fault detection result as the detection result of the target software system; determine an optimization strategy that matches the detection result, and optimize the target software system based on the optimization strategy.

[0076] The fault detection result may be qualified or unqualified; or may be a numerical value such as "0" or "1", which is not limited in this embodiment.

[0077] Optionally, in this embodiment, after obtaining the performance data and business indicator data before and after the injection of the target fault scenario (for example, the first performance data, first business indicator data, second performance data and second business indicator data obtained in the above embodiment), the obtained performance data and business indicator data can be further preprocessed, for example, the above data can be processed for outliers, missing values ​​or normalized, etc. Furthermore, the preprocessed data can be input into the pre-trained target machine learning model to obtain a fault detection result, and the fault detection result can be determined as the detection result of the target software system.

[0078] Furthermore, an optimization strategy that matches the detection result can be determined, and the target software system can be optimized based on the optimization strategy; for example, if the detection result is unqualified and the memory consumption is large, then the optimization strategy can increase the memory to overcome the problem of insufficient memory when the target software system encounters the fault.

[0079] Optionally, in this embodiment, the target machine learning model can be trained through the following steps: injecting each preset fault scenario into the virtual system respectively, and obtaining the performance data of the virtual system and the business indicator data of each business before and after the injection of each preset fault scenario in real time; preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a feature data set; inputting the feature data set into the first machine learning model for iterative training, and obtaining the target machine learning model when the condition for stopping the iteration is met.

[0080] In an optional implementation of this embodiment, after determining the virtual system that matches the target software and the various fault scenarios (preset fault scenarios) that match the virtual system, each preset fault scenario can be injected into the virtual system respectively, and the performance data of the virtual system before and after the injection of each preset fault scenario and the business indicator data of each business can be obtained in real time; further, the obtained data can be preprocessed, for example, outlier processing, missing value processing or normalization, etc., so as to obtain a feature data set; further, the feature data set can be input into the first machine learning model for iterative training, and when the iteration stop condition (for example, accuracy condition or number of iterations condition, etc.) is met, the target machine learning model is obtained.

[0081] Among them, the first machine learning can be any machine learning model or a multimodal large model, which is not limited in this embodiment.

[0082] In a specific example of this embodiment, ensemble learning methods such as random forests can be used to classify and regress fault types, and unsupervised anomaly detection algorithms such as isolation forests and clustering can be used to mine abnormal patterns. During the model training process, cross-validation, multi-fold cross-validation and other means are used to improve generalization performance, and parameters are tuned in combination with methods such as grid search to ensure the accuracy and stability of the model on experimental data.

[0083] This example identifies key bottleneck modules and potential risk points that impact system stability by studying indicator changes under different failure scenarios. For example, the model may reveal that response delays in a risk control service are the primary factor in declining transaction success rates, thereby locating the service's throttling or insufficient resource allocation.

[0084] The advantage of this setting is that the machine learning model obtained through training can quickly identify the deficiencies of the target software system, thereby improving the detection efficiency of the target software system.

[0085] The solution of this embodiment, after obtaining the performance data and business indicator data before and after the injection of the target fault scenario, can further preprocess the obtained performance data and business indicator data. Furthermore, the preprocessed data can be input into the pre-trained target machine learning model to obtain a fault detection result, and the fault detection result is determined as the detection result of the target software system. The detection result of the target software system can be determined quickly and accurately, providing assistance for the optimization of the target software system.

[0086] Based on the above technical solution, the solution of this embodiment may also include: updating the virtual system to obtain an updated virtual system, and redetermining at least one fault scenario that matches the virtual system; injecting each re-determined fault scenario into the virtual system respectively, and obtaining the performance data of the virtual system before and after the injection of each fault scenario and the business indicator data of each business in real time; preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a first feature data set; inputting the first feature data set into the target machine learning model for iterative training to update the target machine learning model.

[0087] Optionally, in this embodiment, the virtual system can be updated based on the update of the target software system, or can be updated directly based on the fault detection results. Furthermore, based on the updated virtual system, the fault scenarios that match it can be re-determined; further, the fault scenarios can be re-injected into the virtual system, and the performance data of the virtual system before and after the injection of each fault scenario and the business indicator data of each business can be obtained in real time; further, the performance data of the virtual system and the business indicator data of each business can be preprocessed to obtain a first feature data set; further, the first feature data set can continue to be input into the target machine learning model for iterative training, thereby updating the target machine learning model.

[0088] The benefit of this setup is that it allows the target machine learning model to be updated, continuously improving its predictive capabilities. Through iterative cycles, the fault experiment plan and digital twin model are continuously refined, making the experimental process automated and systematized, thereby building a data-driven stability optimization closed loop.

[0089] To better understand the software system detection method involved in this embodiment, the following example illustrates it: an online payment system (target software system) can include modules such as a user access layer, order services, core payment services, a risk control engine, a third-party payment gateway, and a database. The digital twin model deploys these components as virtual containers and configures the corresponding network topology and service dependencies. User behavior is generated through a simulated client, including common operations such as registration, login, order placement, and payment, and injected into the system at a certain concurrent rate.

[0090] Furthermore, a system steady-state assumption can be set before testing: Under normal circumstances, the system's transaction success rate is stable at over 99.9%, and TPS remains near the baseline value. Chaos fault injection scenarios are divided into the following categories: sudden increase in transaction volume: simulating a major promotion scenario, suddenly initiating several times the normal number of concurrent payment requests in a short period of time to test the system's stress tolerance; interface dependency anomalies: randomly introducing artificial delays or errors (such as risk control service call delays until timeout) when sending risk control queries or third-party payment requests to check the system's fault tolerance strategy; third-party channel instability: simulating network jitter or downtime of the external payment gateway, such as regularly closing or delaying the network connection of the payment gateway container; database connection failure: pausing the database connection for 1-2 seconds when executing a payment transaction to observe the transaction's rollback and retry mechanism.

[0091] Furthermore, fault scenarios can be designed, such as injecting CPU saturation and memory leak faults into the payment consumer node, and injecting network partition faults into the service registration center node. These faults can then be triggered in sequence according to the entire payment process, and changes in TPS, transaction success rate, and response delay of each node can be continuously observed. In specific implementation, by injecting network, disk, process and other faults into the quick payment link and monitoring indicators such as transaction success rate, TPS, and delay, the stability of the system under different fault conditions can be quantified. For example, if it is found that the response delay of a risk control engine increases, resulting in a decrease in transaction success rate, the concurrent current limiting strategy of the service can be adjusted and verified again.

[0092] Furthermore, the collected monitoring data can be fed into the machine learning analysis module; illustratively, features can be extracted for each test scenario, such as the decrease in transaction success rate, the change in the average risk control response delay, the number of database connection failures, etc.; further, the random forest model is used to analyze the relationship between these features and the fault type, which can automatically identify the factors that cause system bottlenecks; at the same time, the isolation forest is used for anomaly detection to find outliers in the data, such as unknown failure modes of a certain component. Based on the analysis results, the system can be further improved: an automatic expansion mechanism for risk control services is added, the database connection pool parameters are optimized, and the digital twin model is updated to reflect the latest system architecture. In the solution of this embodiment, in subsequent detection cycles, new detection data is continuously used to update the machine learning model to cope with business changes and new fault fields.

[0093] The solution in this embodiment enables comprehensive testing and optimization of software system stability. The use of digital twins for integrated virtual-real fault injection more fully considers the system's external environment and real-world business scenarios. In-depth analysis of experimental data using machine learning models significantly improves the efficiency and accuracy of risk location. By establishing a closed-loop injection-analysis-optimization process, this embodiment of the present invention enables continuous iterative improvement of system design, effectively reducing the probability and impact of system failures and improving business continuity.

[0094] Example 4

[0095] Figure 4 FIG. 1 is a schematic diagram of a detection device for a software system according to a fourth embodiment of the present invention. Figure 4 As shown, the device includes:

[0096] A first determination module 410 is configured to determine a virtual system that matches the target software system and to determine at least one failure scenario that matches the virtual system;

[0097] A second determination module 420 is configured to determine a target fault scenario matching the target service in response to an execution instruction of the target service in the virtual system, and inject the target fault scenario into the virtual system;

[0098] An acquisition module 430 is configured to acquire performance data of the virtual system and business indicator data of the target business before and after the target fault scenario is injected;

[0099] The third determination module 440 is configured to determine a detection result of the target software system based on the performance data and the business indicator data, and determine an optimization strategy for the target software system.

[0100] The solution of this embodiment is to determine a virtual system that matches the target software system through a first determination module, and determine at least one fault scenario that matches the virtual system; determine a target fault scenario that matches the target business in the virtual system in response to an execution instruction of the target business through a second determination module, and inject the target fault scenario into the virtual system; obtain the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business through an acquisition module; determine the detection result of the target software system based on each performance data and each business indicator data through a third determination module, and determine the optimization strategy of the target software system, so that the software system can be detected quickly and accurately, and the stability and fault tolerance of the software system can be improved.

[0101] In an optional implementation of this embodiment, the first determining module 410 is specifically configured to:

[0102] Acquire system data of the target software system, and perform modeling based on the system data to obtain the virtual system; wherein the system data includes at least one of the following: configuration data, operation data, log data, and sensor data;

[0103] Each failure scenario is determined based on the performance indicator range of the target software system.

[0104] In an optional implementation of this embodiment, the second determining module 420 is specifically configured to:

[0105] Parsing the execution instruction of the target business to determine the execution content of the target business, and determining the target fault scenario based on the execution content;

[0106] Determine a target location area to be injected into the virtual system based on the fault information of the target fault scenario, and write the target fault scenario into the target location area;

[0107] The target location area includes: application layer, database layer, network layer, file system or external dependency.

[0108] In an optional implementation of this embodiment, the acquisition module 430 is specifically configured to:

[0109] Determining a data collection point in the virtual system, and obtaining, at the data collection point, first performance data of the virtual system and first business indicator data of the target business within a first preset time period before injecting the target fault scenario;

[0110] Second performance data of the virtual system and second business indicator data of the target business within a second preset time period after the target fault scenario is injected are acquired at the data collection point.

[0111] In an optional implementation of this embodiment, the third determining module 440 is specifically configured to:

[0112] Preprocessing each of the performance data and each of the business indicator data, and inputting the preprocessed data into a pre-trained target machine learning model to obtain a fault detection result, and determining the fault detection result as a detection result of the target software system;

[0113] An optimization strategy matching the detection result is determined, and the target software system is optimized based on the optimization strategy.

[0114] In an optional implementation of this embodiment, the detection device of the software system further includes: a model training module, which is used to:

[0115] Injecting each preset fault scenario into the virtual system respectively, and obtaining the performance data of the virtual system and the business indicator data of each business before and after the injection of each preset fault scenario in real time;

[0116] Preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a feature data set;

[0117] The feature data set is input into the first machine learning model for iterative training, and the target machine learning model is obtained when the condition for iteration stopping is met.

[0118] In an optional implementation of this embodiment, the detection device of the software system further includes: a model updating module, configured to:

[0119] Updating the virtual system to obtain an updated virtual system, and re-determining at least one fault scenario matching the virtual system;

[0120] Injecting each re-determined fault scenario into the virtual system respectively, and obtaining performance data of the virtual system and business indicator data of each business before and after the injection of each fault scenario in real time;

[0121] Preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a first feature data set;

[0122] The first feature data set is input into the target machine learning model for iterative training to update the target machine learning model.

[0123] The software system detection device provided in the embodiment of the present invention can execute the software system detection method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0124] In the technical solutions of the embodiments of the present invention, the collection, storage, use, processing, transmission, provision and disclosure of system data (such as performance data, business indicator data, etc.) involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0125] Example 5

[0126] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0127] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0128] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0129] The processor 11 can be various general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors that run machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The processor 11 executes the various methods and processes described above, such as a detection method for a software system, which may include: determining a virtual system that matches the target software system, and determining at least one fault scenario that matches the virtual system; in response to an execution instruction of a target business in the virtual system, determining a target fault scenario that matches the target business, and injecting the target fault scenario into the virtual system; obtaining the performance data of the virtual system before and after the injection of the target fault scenario and the business indicator data of the target business; determining the detection result of the target software system based on each of the performance data and each of the business indicator data, and determining the optimization strategy of the target software system.

[0130] In some embodiments, the detection method of the software system can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the detection method of the software system described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute the detection method of the software system by any other appropriate means (for example, by means of firmware).

[0131] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0132] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0133] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0134] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0135] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0136] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0137] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0138] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

[0139] An embodiment of the present invention further provides a computer program product, including a computer program, which, when executed by a processor, implements the database detection method provided in any embodiment of the present application.

[0140] The computer program product may be implemented by writing computer program code for performing the operations of the present invention in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0141] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned. They should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0142] Note that the above are only preferred embodiments of the present invention and the technical principles employed. Those skilled in the art will appreciate that the present invention is not limited to the specific embodiments herein, and that various obvious changes, readjustments, and substitutions are possible for those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments and may include many other equivalent embodiments without departing from the scope of the present invention. The scope of the present invention is determined by the scope of the appended claims.

Claims

1. A software system detection method, characterized in that: include: Determining a virtual system that matches the target software system, and determining at least one failure scenario that matches the virtual system; In response to an execution instruction of a target service in the virtual system, determining a target failure scenario that matches the target service, and injecting the target failure scenario into the virtual system; Acquire performance data of the virtual system before and after injection of the target fault scenario and business indicator data of the target business; Based on the performance data and the business indicator data, a detection result of the target software system is determined, and an optimization strategy for the target software system is determined.

2. The software system detection method according to claim 1, characterized in that: The determining of a virtual system matching the target software system and determining at least one fault scenario matching the virtual system includes: Acquire system data of the target software system, and perform modeling based on the system data to obtain the virtual system; wherein the system data includes at least one of the following: configuration data, operation data, log data, and sensor data; Each failure scenario is determined based on the performance indicator range of the target software system.

3. The software system detection method according to claim 1, characterized in that: The step of determining, in response to an execution instruction of a target service in the virtual system, a target fault scenario matching the target service, and injecting the target fault scenario into the virtual system includes: Parsing the execution instruction of the target business to determine the execution content of the target business, and determining the target fault scenario based on the execution content; Determine a target location area to be injected into the virtual system based on the fault information of the target fault scenario, and write the target fault scenario into the target location area; The target location area includes: application layer, database layer, network layer, file system or external dependency.

4. The software system detection method according to claim 1, characterized in that: The obtaining of the performance data of the virtual system and the business indicator data of the target business before and after the target fault scenario is injected includes: Determining a data collection point in the virtual system, and obtaining, at the data collection point, first performance data of the virtual system and first business indicator data of the target business within a first preset time period before injecting the target fault scenario; Second performance data of the virtual system and second business indicator data of the target business within a second preset time period after the target fault scenario is injected are acquired at the data collection point.

5. The software system detection method according to claim 1, characterized in that: Determining the detection result of the target software system based on each of the performance data and each of the business indicator data, and determining the optimization strategy of the target software system, includes: Preprocessing each of the performance data and each of the business indicator data, and inputting the preprocessed data into a pre-trained target machine learning model to obtain a fault detection result, and determining the fault detection result as a detection result of the target software system; An optimization strategy matching the detection result is determined, and the target software system is optimized based on the optimization strategy.

6. The software system detection method according to claim 5, characterized in that: The target machine learning model is trained by the following steps: Injecting each preset fault scenario into the virtual system respectively, and obtaining the performance data of the virtual system and the business indicator data of each business before and after the injection of each preset fault scenario in real time; Preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a feature data set; The feature data set is input into the first machine learning model for iterative training, and the target machine learning model is obtained when the condition for iteration stopping is met.

7. The software system detection method according to claim 6, characterized in that: The method further comprises: Updating the virtual system to obtain an updated virtual system, and re-determining at least one fault scenario matching the virtual system; Injecting each re-determined fault scenario into the virtual system respectively, and obtaining performance data of the virtual system and business indicator data of each business before and after the injection of each fault scenario in real time; Preprocessing the performance data of the virtual system and the business indicator data of each business to obtain a first feature data set; The first feature data set is input into the target machine learning model for iterative training to update the target machine learning model.

8. A software system detection device, characterized in that: include: A first determination module is configured to determine a virtual system that matches the target software system and to determine at least one failure scenario that matches the virtual system; a second determining module, configured to determine, in response to an execution instruction of a target service in the virtual system, a target fault scenario matching the target service, and inject the target fault scenario into the virtual system; An acquisition module, configured to acquire performance data of the virtual system and business indicator data of the target business before and after the target fault scenario is injected; The third determination module is used to determine the detection result of the target software system based on each of the performance data and each of the business indicator data, and determine the optimization strategy of the target software system.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor so that the at least one processor can execute the software system detection method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the software system detection method according to any one of claims 1 to 7 when executed.

11. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the software system detection method according to any one of claims 1 to 7.

Images