Service failure verification method, device, equipment and storage medium

Abstract

The embodiments of the present disclosure disclose a method, device, equipment and storage medium for verifying service failures. The methods include: traversing downstream dependent services in a business system; determining whether the traversed downstream dependent services are weakly dependent services; if the traversed downstream dependent services are weakly dependent services, selecting a set number of failures from a failure library; and injecting the set number of failures into the weakly dependent services to verify the weakly dependent services. The method for verifying service failures disclosed in the embodiments of the present disclosure, when the traversed downstream dependent services are weakly dependent services, selects a set number of failures from a failure library, and injects the selected failures into the weakly dependent services to verify the weakly dependent services, which can implement failure verification of downstream services, discover potential risks in services, and thus improve the reliability and fault tolerance of services.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer technology, and in particular to a method, apparatus, device and storage medium for verifying a service failure. Background Art

[0002] The verification of service failures in existing chaos engineering mainly includes the following three methods:

[0003] 1. When creating an experiment, configure the fault type and fault parameters according to the problem to be verified. When executing the experiment, inject the configured fault configuration into the service to be verified. The verification goal of this solution is relatively clear, but there is a problem with fault coverage, and unconfigured fault scenarios cannot be verified.

[0004] Second, perform an experiment for each fault in the fault library and typical fault parameters. This can completely cover all fault scenarios, but the number of executions of each round of experiments is too large. If the experiment is lossy, such as executing the experiment in an online environment, it will cause certain losses.

[0005] 3. Randomly select a certain fault and typical fault parameters from the fault library to perform the experiment. Similar to the situation where online faults occur, all fault scenarios are gradually covered by performing experiments at regular intervals. However, because all downstream dependencies are treated equally when performing experiments, unnecessary experimental impacts may still be introduced. Summary of the invention

[0006] The embodiments of the present disclosure provide a service fault verification method, apparatus, device and storage medium to implement fault verification of downstream services and discover potential risks in services, thereby improving the reliability and fault tolerance of services.

[0007] In a first aspect, an embodiment of the present disclosure provides a method for verifying a service failure, including:

[0008] Traverse downstream dependent services in the business system;

[0009] Determine whether the traversed downstream dependent service is a weakly dependent service;

[0010] If the downstream dependent service traversed is a weakly dependent service, a set number of faults are selected from the fault library;

[0011] The set number of faults is injected into the weakly dependent service to verify the weakly dependent service.

[0012] In a second aspect, an embodiment of the present disclosure further provides a service failure verification device, including:

[0013] Downstream dependency service traversal module, used to traverse downstream dependency services in the business system;

[0014] The weak dependency service judgment module is used to determine whether the traversed downstream dependency service is a weak dependency service;

[0015] A fault selection module is used to select a set number of faults from the fault library when the downstream dependent service traversed is a weakly dependent service;

[0016] The fault verification module is used to inject the set number of faults into the weakly dependent service to verify the weakly dependent service.

[0017] In a third aspect, an embodiment of the present disclosure further provides an electronic device, the electronic device comprising:

[0018] one or more processing devices;

[0019] A storage device for storing one or more programs;

[0020] When the one or more programs are executed by the one or more processing devices, the one or more processing devices implement the service failure verification method as described in the embodiment of the present disclosure.

[0021] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the service failure verification method as described in the embodiment of the present disclosure.

[0022] The embodiments of the present disclosure disclose a method, device, equipment and storage medium for verifying service failures. Traverse the downstream dependent services in the business system; determine whether the traversed downstream dependent services are weakly dependent services; if the traversed downstream dependent services are weakly dependent services, select a set number of failures from the failure library; inject the set number of failures into the weakly dependent services to verify the weakly dependent services. The method for verifying service failures disclosed in the embodiments of the present disclosure, when the traversed downstream dependent services are weakly dependent services, select a set number of failures from the failure library, and inject the selected failures into the weakly dependent services to verify the weakly dependent services, which can implement failure verification of downstream services and discover potential risks in services, thereby improving the reliability and fault tolerance of services. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a flow chart of a method for verifying a service failure in an embodiment of the present disclosure;

[0024] Figure 2 is a structural diagram of a service failure verification device in an embodiment of the present disclosure;

[0025] Figure 3It is a schematic diagram of the structure of an electronic device in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0026] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0027] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0028] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0029] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0030] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0031] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0032] Chaos engineering is a technical means to improve the resilience of technical architecture systems. Chaos engineering can ensure the availability of the system through experiments. Chaos engineering aims to identify faults before they cause service interruptions or downtime. By actively creating faults, testing the behavior of the system under various pressures, identifying and fixing fault problems, and avoiding serious consequences.

[0033] Figure 1This is a flow chart of a service failure verification method provided by an embodiment of the present disclosure. This embodiment is applicable to the case of performing a service failure test. The method can be executed by a service failure verification device, which can be composed of hardware and / or software and can generally be integrated in a device with a service failure verification function, which can be an electronic device such as a server, a mobile terminal or a server cluster. Figure 1 As shown, the method specifically comprises the following steps:

[0034] Step 110, traverse the downstream dependent services in the business system.

[0035] Among them, the business system includes upstream services and downstream services. The business system completes business processing through the cooperation of upstream services and downstream services. Downstream services depend on upstream services, and in the business system, there are multiple upstream services and multiple downstream services.

[0036] In the disclosed embodiment, all downstream dependent services are traversed to determine whether the traversed downstream dependent services need to be fault verified. If necessary, faults are selected from the fault library to verify the downstream dependent services.

[0037] Step 120, determine whether the traversed downstream dependent service is a weakly dependent service.

[0038] Among them, weak dependency service can be understood as when the upstream service that the downstream service depends on fails, the downstream service can still work normally. In contrast to weak dependency service is strong dependency service, which can be understood as when the upstream service that the downstream service depends on fails, the downstream service cannot work normally.

[0039] Specifically, the method for determining whether the traversed downstream dependent service is a weakly dependent service may be: injecting a set type of fault into the traversed downstream dependent service; if the downstream dependent service does not crash, the traversed downstream dependent service is a weakly dependent service.

[0040] Among them, the set type of fault can be a rejection of service fault. Injecting the set type of fault into the traversed downstream dependent service can be understood as injecting the set type of fault parameter into the traversed downstream dependent service, obtaining the response result of the downstream dependent service to the injected fault, if the response result is that the downstream dependent service is down, then the downstream dependent service is a strong dependent service, if the response result is that the downstream dependent service is not down, then the downstream dependent service is a weak dependent service.

[0041] In this embodiment, fault verification is only performed on weakly dependent services because fault verification on strongly dependent services will cause asset losses and affect user experience. If fault verification is performed on weakly dependent services, asset losses can be reduced and impact on user experience can be avoided.

[0042] Step 130: If the traversed downstream dependent service is a weakly dependent service, a set number of faults are selected from the fault library.

[0043] The fault library stores a variety of faults, and the faults are characterized by fault types and fault parameters. In this embodiment, the method of selecting a set number of faults from the fault library can be: randomly selecting a set number of faults from the fault library, or selecting a set number of faults from the fault library according to a set rule.

[0044] Optionally, the process of selecting a set number of faults from the fault library may be: obtaining faults stored in a deduplication library; filtering the faults in the fault library according to the faults stored in the deduplication library; and selecting a set number of faults from the filtered fault library.

[0045] The deduplication library is used to store faults that have been injected into weakly dependent services. The deduplication library can be embodied in the form of an orchestration (map) table, and the map table stores data in the form of keyword-specific value (key-value). The fault type is the key value of the map table, and the fault parameter is the value of the map table.

[0046] In this embodiment, the method of filtering the faults in the fault library according to the faults stored in the deduplication library can be to filter the faults in the deduplication library from the fault library. That is, in this application, a set number of faults are selected from the faults that have not been injected into the weakly dependent service. The advantage of doing so is to prevent the same fault from being repeatedly injected into the weakly dependent service.

[0047] Optionally, the process of selecting a set number of faults from the filtered fault library may be: if there are no remaining faults in the filtered fault library, the faults in the fault library are cleared, and the operation of selecting a set number of faults from the fault library is re-executed.

[0048] Among them, if there are no remaining faults in the fault library, it means that the fault library is empty. At this time, after the deduplication library is cleared, the faults in the fault library cannot be filtered out when filtering the faults in the fault library according to the faults stored in the deduplication library, so that the filtered fault library is not empty, and the operation of selecting a set number of faults from the fault library is re-executed.

[0049] Optionally, a method of selecting a set number of faults from the fault library may be: obtaining weight coefficients of the faults stored in the fault library; and selecting a set number of faults from the fault library according to the weight coefficients.

[0050] The weighting coefficient may be preset. In this embodiment, a set number of faults are selected from the fault library according to the weighting coefficient, and faults with high weighting coefficients may be preferentially selected and injected into weakly dependent services.

[0051] Optionally, after injecting a set number of faults into the weakly dependent service, the following steps are also included: determining whether the number of verifications reaches a set value; if not, returning to execute the operation of selecting a set number of faults from the fault library until the number of verifications reaches a set value.

[0052] Specifically, if the number of verifications does not reach the set value, it returns to select a set number of faults from the fault library; inject the set number of faults into the weakly dependent service to verify the weakly dependent service. The advantage of selecting a set number of faults from the fault library and injecting them into the weakly dependent service multiple times is that it can cover as many fault scenarios as possible and ensure the reliability of fault verification.

[0053] Step 140: inject a set number of faults into the weakly dependent service to verify the weakly dependent service.

[0054] Specifically, after injecting a set number of faults into the weakly dependent service, the response result of the weakly dependent service to the injected faults is obtained. If the response result is a service downtime, the weakly dependent service needs to be optimized to improve the fault tolerance of the weakly dependent service.

[0055] Optionally, after injecting a set number of faults into the weakly dependent service, the following step is further included: storing the faults injected into the weakly dependent service in a deduplication library. The advantage of this is that when the faults in the fault library are filtered according to the faults stored in the deduplication library, the filtered fault library is more accurate.

[0056] The technical solution of the embodiment of the present disclosure traverses the downstream dependent services in the business system; determines whether the traversed downstream dependent service is a weakly dependent service; if the traversed downstream dependent service is a weakly dependent service, selects a set number of faults from the fault library; and injects the set number of faults into the weakly dependent service to verify the weakly dependent service. The method for verifying service faults disclosed in the embodiment of the present disclosure, when the traversed downstream dependent service is a weakly dependent service, selects a set number of faults from the fault library, and injects the selected faults into the weakly dependent service to verify the weakly dependent service, which can realize fault verification of downstream services and discover potential risks in services, thereby improving the reliability and fault tolerance of services.

[0057] Figure 2 FIG. 1 is a schematic diagram of a structure of a service failure verification device provided by an embodiment of the present disclosure. Figure 2 As shown, the device comprises:

[0058] A downstream dependent service traversal module 210 is used to traverse downstream dependent services in the business system;

[0059] A weak dependency service determination module 220 is used to determine whether the traversed downstream dependency service is a weak dependency service;

[0060] A fault selection module 230 is used to select a set number of faults from a fault library when the traversed downstream dependent service is a weakly dependent service;

[0061] The fault verification module 240 is used to inject the set number of faults into the weakly dependent service to verify the weakly dependent service.

[0062] Optionally, the weakly dependent service determination module 220 is further used to:

[0063] Inject the set type of fault into the downstream dependent services traversed;

[0064] If the downstream dependent service does not crash, the traversed downstream dependent service is a weakly dependent service.

[0065] Optionally, the fault selection module 230 is further configured to:

[0066] Obtaining the faults stored in the deduplication library; the faults are characterized by fault types and fault parameters;

[0067] Filtering the faults in the fault library according to the faults stored in the deduplication library;

[0068] Select a set number of faults from the filtered fault library.

[0069] Optionally, it also includes: a fault storage module, used for:

[0070] The faults injected into the weak dependency are stored in the deduplication library.

[0071] Optionally, the fault selection module 230 is further configured to:

[0072] If there are no remaining faults in the fault library after filtering, the faults in the deduplication library are cleared, and the operation of selecting a set number of faults from the fault library is performed again.

[0073] Optionally, it also includes: a verification times judgment module, which is used to:

[0074] Determine whether the number of verifications reaches the set value;

[0075] If not, the process returns to executing the operation of selecting a set number of faults from the fault library until the number of verification times reaches the set value.

[0076] Optionally, the fault selection module 230 is further configured to:

[0077] Obtaining weighting coefficients of faults stored in a fault database;

[0078] A set number of faults are selected from the fault library according to the weighting coefficients.

[0079] The above device can execute the methods provided by all the above embodiments of the present disclosure, and has the corresponding functional modules and beneficial effects of executing the above methods. For technical details not fully described in this embodiment, please refer to the methods provided by all the above embodiments of the present disclosure.

[0080] Reference below Figure 3 , which shows a schematic diagram of the structure of an electronic device 300 suitable for implementing the embodiment of the present disclosure. The electronic device in the embodiment of the present disclosure may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc., or various forms of servers, such as independent servers or server clusters. Figure 3 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0081] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only storage device (ROM) 302 or a program loaded from a storage device 308 to a random access storage device (RAM) 303. In the RAM 303, various programs and data required for the operation of the electronic device 300 are also stored. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0082] Typically, the following devices may be connected to the I / O interface 305: input devices 306 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 308 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 309. The communication devices 309 may allow the electronic device 300 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 3 The electronic device 300 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0083] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing a method for recommending words. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 309, or installed from a storage device 308, or installed from a ROM 302. When the computer program is executed by the processing device 301, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0084] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0085] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with 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"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0086] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0087] The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by the electronic device, the electronic device is enabled to: traverse the downstream dependent services in the business system; determine whether the traversed downstream dependent services are weakly dependent services; if the traversed downstream dependent services are weakly dependent services, select a set number of faults from the fault library; and inject the set number of faults into the weakly dependent services to verify the weakly dependent services.

[0088] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, 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 separate 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 through 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., through the Internet using an Internet service provider).

[0089] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0090] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a unit does not, in some cases, limit the unit itself.

[0091] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0092] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0093] According to one or more embodiments of the present disclosure, the present disclosure discloses a method for verifying a service failure, including:

[0094] Traverse downstream dependent services in the business system;

[0095] Determine whether the traversed downstream dependent service is a weakly dependent service;

[0096] If the downstream dependent service traversed is a weakly dependent service, a set number of faults are selected from the fault library;

[0097] The set number of faults is injected into the weakly dependent service to verify the weakly dependent service.

[0098] Furthermore, it is determined whether the traversed downstream dependent service is a weakly dependent service, including:

[0099] Inject the set type of fault into the downstream dependent services traversed;

[0100] If the downstream dependent service does not crash, the traversed downstream dependent service is a weakly dependent service.

[0101] Further, a set number of faults are selected from the fault library, including:

[0102] Obtaining the faults stored in the deduplication library; the faults are characterized by fault types and fault parameters;

[0103] Filtering the faults in the fault library according to the faults stored in the deduplication library;

[0104] Select a set number of faults from the filtered fault library.

[0105] Further, after injecting the set number of faults into the weakly dependent service, the method further includes:

[0106] The faults injected into the weak dependency are stored in the deduplication library.

[0107] Further, a set number of faults are selected from the filtered fault library, including:

[0108] If there are no remaining faults in the fault library after filtering, the faults in the deduplication library are cleared, and the operation of selecting a set number of faults from the fault library is performed again.

[0109] Further, after injecting the set number of faults into the weakly dependent service, the method further includes:

[0110] Determine whether the number of verifications reaches the set value;

[0111] If not, the process returns to executing the operation of selecting a set number of faults from the fault library until the number of verification times reaches the set value.

[0112] Further, a set number of faults are selected from the fault library, including:

[0113] Obtaining weighting coefficients of faults stored in a fault database;

[0114] A set number of faults are selected from the fault library according to the weighting coefficients.

[0115] Note that the above are only preferred embodiments of the present disclosure and the technical principles used. Those skilled in the art will understand that the present disclosure is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present disclosure. Therefore, although the present disclosure is described in more detail through the above embodiments, the present disclosure is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present disclosure, and the scope of the present disclosure is determined by the scope of the attached claims.

Claims

1. A method for verifying a service failure, characterized in that: include: Traverse downstream dependent services in the business system; Determine whether the traversed downstream dependent service is a weakly dependent service; If the traversed downstream dependent service is the weakly dependent service, a set number of faults are selected from the fault library; Injecting the set number of faults into the weakly dependent service to verify the weakly dependent service; The step of determining whether the traversed downstream dependent service is a weakly dependent service includes: Injecting a set type of fault into the traversed downstream dependent service; wherein the set type of fault is a denial of service fault; If the downstream dependent service has not experienced any downtime, the traversed downstream dependent service is the weakly dependent service.

2. The method according to claim 1, characterized in that: Select a set number of faults from a fault library, including: Obtaining the faults stored in the deduplication library; the faults are characterized by fault types and fault parameters; Filtering the faults in the fault library according to the faults stored in the deduplication library; Select a set number of faults from the filtered fault library.

3. The method according to claim 2, characterized in that After injecting the set number of faults into the weakly dependent service, the method further includes: The faults injected into the weak dependency are stored in the deduplication library.

4. The method according to claim 2, characterized in that: Select a set number of faults from a filtered fault library, including: If there are no remaining faults in the fault library after filtering, the faults in the deduplication library are cleared, and the operation of selecting a set number of faults from the fault library is performed again.

5. The method according to claim 1, characterized in that After injecting the set number of faults into the weakly dependent service, the method further includes: Determine whether the number of verifications reaches the set value; If not, the process returns to executing the operation of selecting a set number of faults from the fault library until the number of verification times reaches the set value.

6. The method according to claim 1, characterized in that Select a set number of faults from a fault library, including: Obtaining weighting coefficients of faults stored in a fault database; A set number of faults are selected from the fault library according to the weighting coefficients.

7. A service failure verification device, characterized in that: include: Downstream dependency service traversal module, used to traverse downstream dependency services in the business system; The weak dependency service judgment module is used to determine whether the traversed downstream dependency service is a weak dependency service; A fault selection module, used for selecting a set number of faults from a fault library when the traversed downstream dependent service is the weakly dependent service; A fault verification module, used for injecting the set number of faults into the weakly dependent service to verify the weakly dependent service; Among them, the weak dependency service judgment module is specifically used to inject a set type of fault into the traversed downstream dependency service; wherein the set type of fault is a denial of service fault; if the downstream dependency service does not crash, the traversed downstream dependency service is the weak dependency service.

8. An electronic device, characterized in that: The electronic device comprises: one or more processing devices; A storage device for storing one or more programs; When the one or more programs are executed by the one or more processing devices, the one or more processing devices implement the service failure verification method as described in any one of claims 1-6.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processing device, the service failure verification method as described in any one of claims 1-6 is implemented.

Images