CN114422399A

CN114422399A - Fault diagnosis method, device, equipment and storage medium

Info

Publication number: CN114422399A
Application number: CN202011173343.XA
Authority: CN
Inventors: 郭文婷; 罗鸿伟
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2020-10-28
Filing date: 2020-10-28
Publication date: 2022-04-29

Abstract

According to the fault diagnosis method, the fault diagnosis device, the fault diagnosis equipment and the fault diagnosis storage medium, the diagnosis strategy corresponding to the current networking scene and the type of the service to be diagnosed is determined; diagnosing the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result; and determining the fault diagnosis information of the service to be diagnosed based on the diagnosis result, realizing service fault diagnosis, delimiting, positioning and determining the fault service, and improving the accuracy and flexibility of service fault diagnosis.

Description

Fault diagnosis method, device, equipment and storage medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a fault diagnosis method, apparatus, device, and storage medium.

Background

In a telecommunication network, along with the rapid growth of various services, the carrying capacity, security and reliability of the network are all related to the further development of the services. In the current network engineering application, faults sometimes occur during the operation of a network, the normal operation of the network is influenced, the service quality of a user is reduced and even interrupted, and negative influences are caused on the operation of the network and the user experience.

At present, there are two main methods for diagnosing service failures in the existing network management system. The first is to use various test suite functions to manually perform layered and segmented detection on the service in the network management; the second is to detect the service according to a solidified flow after inputting the service information to be diagnosed in the network management.

The first mode is a manual operation mode, which has low efficiency and high maintenance cost; the second method provides automatic detection, but the diagnosis process is solidified, and the diagnosis process has great difference, which may result in inaccurate diagnosis result.

Disclosure of Invention

The application provides a fault diagnosis method, a fault diagnosis device, equipment and a storage medium, which realize service fault diagnosis and can flexibly and accurately delimit, position and determine a cause of a fault service.

In a first aspect, an embodiment of the present application provides a fault diagnosis method, including:

determining a diagnosis strategy corresponding to a current networking scene and a service type to be diagnosed;

diagnosing the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result;

and determining the fault diagnosis information of the service to be diagnosed based on the diagnosis result.

In a second aspect, an embodiment of the present application provides a fault diagnosis apparatus, including:

the diagnosis strategy determining module is configured to determine a current networking scene and a diagnosis strategy corresponding to the service type to be diagnosed;

the fault diagnosis module is configured to diagnose the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result;

and the diagnosis information determining module is configured to determine the fault diagnosis information of the service to be diagnosed based on the diagnosis result.

In a third aspect, an embodiment of the present application provides an apparatus, including:

one or more processors;

a memory for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method as any one of the embodiments provides herein.

In a fourth aspect, the present application provides a storage medium storing a computer program, which when executed by a processor implements the method according to any one of the methods provided in the embodiments of the present application.

According to the fault diagnosis method, the fault diagnosis device, the fault diagnosis equipment and the fault diagnosis storage medium, diagnosis strategies corresponding to the current networking scene and the service type are determined; diagnosing the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result; and determining the fault diagnosis information of the service to be diagnosed based on the diagnosis result, realizing service fault diagnosis, delimiting, positioning and determining the fault service, and improving the accuracy and flexibility of service fault diagnosis.

With regard to the above embodiments and other aspects of the present application and implementations thereof, further description is provided in the accompanying drawings description, detailed description and claims.

Drawings

Fig. 1 is a flowchart of a fault diagnosis method provided in an embodiment of the present application;

fig. 2 is a structural diagram of a service fault diagnosis system provided in an embodiment of the present application;

fig. 3 is a flowchart of a business fault diagnosis policy arrangement method according to an embodiment of the present application;

fig. 4 is a flowchart of a method for executing a service fault diagnosis policy according to an embodiment of the present application;

fig. 5 is a flowchart of L3VPN OVER SR-TP scenario service fault diagnosis provided in an embodiment of the present application;

fig. 6 is a flowchart of a diagnosis policy including only fault delimitation in L3VPN OVER SR-TP scenario arrangement provided in an embodiment of the present application;

fig. 7 is a structural diagram of a fault diagnosis apparatus according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an apparatus provided in an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.

The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

In an embodiment, a fault diagnosis method is provided, as shown in fig. 1, the fault diagnosis method provided in this embodiment mainly includes the following steps:

and S11, determining a diagnosis strategy corresponding to the current networking scene and the service type to be diagnosed.

And S12, diagnosing the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result.

And S13, determining the fault diagnosis information of the service to be diagnosed based on the diagnosis result.

The fault diagnosis method provided by the embodiment of the application can be applied to service fault diagnosis of different network scenes, including but not limited to network services of a bearer network; the method can also be applied to the scenes related to the diagnosis function in the network management system, including but not limited to service fault diagnosis.

The determination of the current networking scenario and the diagnosis strategy corresponding to the service type to be diagnosed may be performed by the network management system executing a preset software program, or may be performed by the user through selection information input by an input device of the network management system.

In one embodiment, determining a diagnosis policy corresponding to a current networking scenario and a service type to be diagnosed includes: displaying the current networking scene and all diagnosis strategies corresponding to all service types; and determining a diagnosis strategy corresponding to the current networking scene and the type of the service to be diagnosed based on a selection instruction input by a user.

Specifically, all diagnosis strategies corresponding to the current networking scene and all service types may be displayed on a front-end interface of the network management system, an applicable diagnosis strategy is selected based on selection information input by a user at an input device at the front end of the network management system, and the selected and determined diagnosis strategy is transmitted to the rear end of the network management system.

In one embodiment, diagnosing the service to be diagnosed according to the workflow in the diagnosis policy includes: modeling the service to be diagnosed based on the service routing information and the service level information of the service to be diagnosed to obtain a service model to be diagnosed; and diagnosing the service model to be diagnosed according to the diagnosis strategy.

In this embodiment, the service routing information and the service level information of the service to be diagnosed are determined by the service parameter information. The service parameter information can be input by a user at an input device at the front end of the network management system to be diagnosed, and the service information is transmitted to the back end of the network management system.

Further, the back end of the network management system inquires out the service route and the service level information data of the service to be diagnosed according to the service parameter information transmitted by the front end of the network management system and then models the service; and transmitting the service routing and the layered information to a front-end interface in a notification mode for displaying.

In one embodiment, the diagnosing policy includes one or more diagnosing rules, and diagnosing the service to be diagnosed according to the diagnosing policy includes: loading all diagnosis rules in the diagnosis strategy; executing a diagnosis action according to the workflow of the diagnosis rule aiming at each diagnosis rule to obtain a rule execution result; and summarizing a plurality of rule execution results to form the diagnosis result.

In one embodiment, after performing the diagnostic action according to the workflow of the diagnostic rule, the method further includes: after the diagnostic rule is executed, updating a workflow diagram and/or a work list corresponding to the diagnostic rule; and displaying the workflow diagram and/or the work list.

In one embodiment, after performing the diagnostic action according to the workflow of the diagnostic rule, the method further includes: after the diagnosis action is executed, generating an action execution state and an action execution result; and displaying the action execution state and the action execution result in a list form.

Specifically, the back end of the network management system automatically loads all diagnosis rules contained in the selected diagnosis strategy by using a workflow strategy engine, and executes diagnosis actions according to the workflow; after the execution of each diagnosis rule is finished, each diagnosis rule is sent to a front-end interface of the network management system in a form of notification to update the execution progress of the workflow diagram; after each diagnosis action is executed, detailed information of an execution state (success or failure) and an execution result is output, and the information is sent to the front-end interface in a notification mode to display information data of the diagnosis process. Wherein the execution state comprises execution success and execution failure.

In one embodiment, loading all diagnostic rules in the diagnostic policy includes: and automatically loading all the diagnosis rules in the diagnosis strategy by utilizing a workflow strategy engine.

In one embodiment, the fault diagnosis information includes one or more of: type of failure, node causing failure, cause of failure.

The fault types comprise network internal faults and network external faults.

In this embodiment, the result of the back-end diagnostic action of the network management system obtains the diagnostic result, and finds the fault point and the fault reason of the service, so as to delimit the service fault (i.e., whether the network internal fault or the external fault), locate (the device node causing the fault), determine the cause (the cause of the fault), generate a diagnostic report from the result information, and transmit the diagnostic report to the front-end interface for display.

In one embodiment, before determining the diagnostic policy corresponding to the current networking scenario and the service type, the method further includes: determining a diagnosis strategy corresponding to each type of service fault and networking scene; storing a plurality of diagnostic policies into a diagnostic policy repository.

In one embodiment, determining a diagnostic policy corresponding to each service failure and each networking scenario includes: determining a diagnosis rule based on a target service fault and a target networking scene; configuring parameters of the diagnostic rules; and arranging a plurality of configured diagnosis rules into a diagnosis strategy according to the workflow.

In this embodiment, all the service fault diagnosis strategies and the diagnosis rules contained in the strategies are displayed on the front-end interface of the network management system according to the service fault and the networking scene classification; selecting a corresponding diagnosis rule according to a target networking scene and a service type, wherein a plurality of rules can be selected; configuring some parameters of the diagnosis rule on the interface, including parameters, execution conditions and the like related to the diagnosis action in the diagnosis rule; arranging a plurality of configured diagnosis rules into a new diagnosis strategy according to the workflow, and transmitting the diagnosis strategy to the back end of the network management system; and storing the diagnosis strategy at the back end of the network management system, and adding the strategy into a diagnosis strategy library of the network management system.

In one embodiment, before determining the diagnosis rule based on the target service failure and the target networking scenario, the method further includes: and encapsulating the diagnosis process of the same kind of service elements in the service information into a diagnosis rule.

The technical scheme provided by the embodiment can overcome the problems of solidified service fault diagnosis process and inaccurate diagnosis result in the prior art, realizes service fault diagnosis based on the strategy engine, and can flexibly and accurately delimit, position and determine the cause of the service with faults; the method can also realize the checking of the 'good or bad' of the service bearing, is convenient for avoiding some faults in advance, and effectively improves the accuracy and the flexibility of service fault diagnosis.

In an application embodiment, the diagnosis process of the same kind of service elements in the service information is encapsulated into a diagnosis rule, the service diagnosis strategy is arranged according to the networking scene and the service type, and a plurality of diagnosis rules are added into the diagnosis process of certain service faults; and then, performing service diagnosis according to the arranged strategy through a workflow engine, and outputting fault diagnosis information to finish delimitation, positioning and cause determination of the service fault.

Fig. 2 is a structural diagram of a service fault diagnosis system provided in an embodiment of the present application; as shown in fig. 1, the service fault diagnosis system mainly includes a front-end interface and a back-end interface.

1. The front-end interface of the service fault diagnosis system has the functions of diagnosis strategy configuration management, diagnosis process management and diagnosis report management.

1.1 the diagnosis strategy configuration management comprises a diagnosis strategy display function, a diagnosis strategy arranging function and a diagnosis parameter configuration function. The diagnosis strategy display function is to display all the service fault diagnosis strategies and diagnosis rules contained in the strategies according to the service fault and networking scene in a classified manner; the diagnosis strategy arranging function means that operation and maintenance personnel can select a required diagnosis rule according to different service faults and networking scenes, and a plurality of rules are combined into a diagnosis strategy to be added into a strategy library after rule parameters are configured; an existing diagnostic strategy may also be modified. The diagnosis parameter configuration means that operation and maintenance personnel can configure the service parameters needing diagnosis.

1.2 diagnostic process management includes diagnostic strategy operational process management, diagnostic strategy operational status and data presentation. The diagnosis strategy operation process management refers to an operation process which displays diagnosis rules by a workflow diagram and a list; the diagnostic policy operating state and data presentation means that the execution state, process and result data of all diagnostic actions in the diagnostic policy workflow are displayed in a list.

And 1.3, the diagnosis report management comprises service route display, diagnosis result display and diagnosis report storage. The service route display means that the real-time route of the diagnosed service is displayed by a hierarchical topological graph; the diagnosis result display refers to the delimitation, positioning and factor result information display of the diagnosed service fault; the diagnostic report storage means that operation and maintenance personnel can store all information and data in the diagnostic strategy execution process.

2. And the back end of the service fault diagnosis system has the functions of diagnosis strategy configuration management and diagnosis operation management.

2.1 diagnostic policy configuration management includes diagnostic rule management, diagnostic policy management. The diagnosis rule management refers to inquiring and storing service fault diagnosis rule information; the diagnosis strategy management refers to inquiring and storing service fault diagnosis strategy information; the diagnostic rules and the diagnostic policy information are both stored in a diagnostic policy repository.

2.2 diagnostic run management includes workflow policy engine, diagnostic rule set, diagnostic action set, business model, diagnostic policy execution. The workflow strategy engine is used for decomposing a strategy into a plurality of task workflows and automatically managing the execution of the workflows; the diagnostic rule program set is a program set which outputs all diagnostic rules in the diagnostic strategy; the diagnostic action program set is a program set which outputs all diagnostic actions in the diagnostic rule; the service model is used for modeling information such as service routes, service layers and the like to be diagnosed; the diagnosis strategy execution means that all diagnosis rules contained in the diagnosis strategy are automatically loaded by using a workflow strategy engine, and diagnosis actions are executed according to the workflow.

By utilizing the strategy engine technology, the intelligent service fault diagnosis of arranging the diagnosis strategy according to different networking and service scenes is realized, and the definition, the positioning and the cause determination of the faulted service can be accurately carried out. Compared with the prior art, the method can solve the problems of solidified service fault diagnosis process and inaccurate diagnosis result in the prior art, and effectively improves the accuracy and the flexibility of service fault diagnosis.

In an embodiment, a business fault diagnosis policy arrangement method is provided, and fig. 3 is a flowchart of a business fault diagnosis policy arrangement method provided in an embodiment of the present application. As shown in fig. 3, a business fault diagnosis policy arranging method provided in the embodiment of the present application mainly includes the following steps:

step 101: and displaying all service fault diagnosis strategies and diagnosis rules contained in the strategies on a front-end interface of the network management system according to the service fault and the networking scene classification.

Step 102: and selecting a corresponding diagnosis rule according to the current networking scene and the service type, wherein a plurality of rules can be selected.

Step 103: some parameters of the diagnosis rule are configured on the interface, including parameters, execution conditions and the like related to the diagnosis action in the diagnosis rule.

Step 104: and arranging the configured multiple diagnosis rules into a new diagnosis strategy according to the workflow, and transmitting the strategy information to the back end of the network management system.

Step 105: and storing the diagnosis strategy at the back end of the network management system, and adding the strategy into a diagnosis strategy library of the network management system.

In an embodiment, a method for executing a business fault diagnosis policy is provided, and fig. 4 is a flowchart of a method for executing a business fault diagnosis policy provided in an embodiment of the present application. As shown in fig. 4, the method for executing a service fault diagnosis policy provided in the embodiment of the present application mainly includes the following steps:

step 201: selecting an applicable diagnosis strategy on a front-end interface of a network management system according to a current networking scene and a service type;

step 202: inputting service parameter information to be diagnosed on an interface, and transmitting the strategy and the service information to the back end of a network management system;

step 203: the back end of the network management system inquires out the service route and the service level information data of the service to be diagnosed and then models the service according to the service parameter information transmitted in the step 202; and transmitting the service routing and the layered information to a front-end interface in a notification mode for displaying;

step 204: the back end of the network management system automatically loads all the diagnosis rules contained in the diagnosis strategy selected in step 201 by using a workflow strategy engine, and executes diagnosis actions according to the workflow; after the execution of each diagnosis rule is finished, each diagnosis rule is sent to a front-end interface of the network management system in a form of notification to update the execution progress of the workflow diagram; after each diagnosis action is executed, outputting detailed information of an execution state (success or failure) and an execution result, and sending the information to a front-end interface in a form of notification to display information data of a diagnosis process;

step 205: the back end of the network management system finds out the fault point and the fault reason of the service according to the execution result of the diagnosis action in the step 204, so as to delimit the service fault (namely, the internal fault or the external fault of the network), position the equipment node causing the fault and determine the cause (the reason causing the fault), and generate a diagnosis report according to the result information and transmit the diagnosis report to the front end interface for displaying.

In an embodiment, a method for diagnosing a service fault in an L3VPN OVER SR-TP scenario in a bearer network management system is provided, and fig. 5 is a flowchart of diagnosing a service fault in an L3VPN OVER SR-TP scenario provided in the embodiment of the present application.

The L3VPN is an abbreviation of a three-Layer Virtual Private Network (Layer 3Virtual Private Network), and the SR is an abbreviation of Segment Routing. L3VPN OVER SR refers to a kind of networking deployment from L3 to the edge in a 5G bearer transport network, and SR-TP is one of the types of SR tunnels used for connection-oriented, point-to-point traffic bearers. The embodiment describes a service fault diagnosis process in a networking scene of L3VPN OVER SR-TP. In the L3VPN OVER SR-TP scene, the L3VPN service can be divided into three layers, namely an L3VPN tunnel, an SR-TP tunnel and a flexible Ethernet.

As shown in fig. 5, the method for diagnosing a service fault in an L3VPN OVER SR-TP scenario provided in the embodiment of the present application mainly includes the following steps:

step 301: selecting an L3VPN scene on-off diagnosis strategy on a front-end interface of a network management system;

step 302: inputting L3VPN service to be diagnosed and IP information of customer edge equipment (CE for short) on an interface, and transmitting strategy and service information to the back end of a network management system;

step 303: the back end of the network management system inquires out the service route and service level (L3VPN, SR-TP tunnel and flexible Ethernet) information data of the L3VPN service to be diagnosed according to the service parameter information transmitted in the step 302 and then models the service; and transmitting the service routing and the layered information to a front-end interface in a notification mode for displaying;

step 304: the back end of the network management system automatically loads all the diagnosis rules contained in the L3VPN scene on-off diagnosis strategy selected in the step 301 by using a workflow strategy engine, and executes diagnosis actions according to the workflow; firstly, executing an L3VPN PING action in a accessibility detection rule, and respectively executing the L3VPN PING between network side edge equipment (including access side equipment, which is called UPE for short hereinafter, and ground side equipment, which is called NPE for short hereinafter) of L3VPN services to CE, UPE to NPE, UPE to network inner equipment (called SPE for short hereinafter) of the L3VPN services, and SPE to UPE; if UPE or NPE to CE PING is not on, while UPE to NPE can PING on, then failure is indicated to occur outside the network; if the UPE or NPE to CE PING is on and the UPE to NPE PING is not on, the fault is indicated to occur in the network; if UPE or NPE is not connected to CE PING, and UPE is not connected to NPE and PING, it indicates that there is a fault inside and outside the network; the delimitation of the service fault is completed;

step 305: if the network has a fault outside the domain, executing a plurality of diagnostic actions in the out-of-domain detection rule, wherein the diagnostic actions comprise inquiring ARP learning conditions of a next hop and a local output interface UP state which are stored by the network side edge device; querying whether a local egress interface on the edge device is an L3 access port; inquiring the state of a BFD (bidirectional forwarding detection) of the static route of the ground side equipment; if the inquired configuration information is checked to be abnormal, the problematic equipment node and the detailed problem information are stored in the memory; sending the execution state (success or failure) of the diagnosis action to a front-end interface in a notification mode to display information data of the diagnosis process;

step 306: if the network has faults, the diagnosis action of inquiring the alarm and performance data related to the service in the alarm performance detection rule is executed; sending the inquired alarm and performance data to a front-end interface in a notification mode for displaying;

step 307: executing the SR-TP tunnel PING diagnosis action in the SR-TP detection rule; executing tunnel PING on each tunnel according to the SR-TP tunnel information inquired in the step 303; sending the result (on or off) of the tunnel PING diagnosis action to a front-end interface in a notification mode for displaying;

step 308: for the SR-TP tunnel communicated with the tunnel PING in the step 307, a diagnosis action for inquiring the SR-TP tunnel connectivity loss alarm in the SR-TP detection rule is executed; sending the inquired tunnel connectivity loss alarm data to a front-end interface in a notification mode for displaying;

step 309: executing a diagnosis action of tunnel Loopback (LB) detection in the SR-TP detection rule for the SR-TP tunnel inquired in the step 308 and having the tunnel connectivity loss alarm; if the tunnel LB detection result is 'on', the tunnel is possible to be a source-destination both-end configuration error; if the tunnel LB detection result is not through, the tunnel maintenance point configuration is wrong; storing the detailed information of the problems in a memory, and sending the result (communication or non-communication) of the tunnel LB detection diagnosis action to a front-end interface in a notification mode for displaying;

step 310: for the SR-TP tunnel which does not inquire the warning of the loss of tunnel connectivity in the step 308, the diagnostic actions of checking the number consistency of UPE/NPE equipment load sharing group members in the SR-TP detection rule and checking the forwarding in-out label matching of the virtual router are executed; if the inquired configuration information is checked to be abnormal, the problematic equipment node and the detailed problem information are stored in the memory; sending the execution state (success or failure) of the diagnosis action to a front-end interface in a notification mode to display information data of the diagnosis process;

step 311: for the SR-TP tunnel with the tunnel PING not communicated in the step 307, the diagnosis action of the SR-TP tunnel TRACE in the SR-TP detection rule is executed; sending the result (success or failure) of the tunnel TRACE diagnosis action to a front-end interface in a notification mode for displaying;

step 312: for the SR-TP tunnel with the tunnel trapped failure in step 311, according to the flexible ethernet data information queried in step 303, a diagnostic action of flexible ethernet configuration consistency check in the flexible ethernet detection rule is executed; the flexible Ethernet configuration consistency check comprises that the Group number and the member number of both ends of a source and a sink of a flexible Ethernet Group (hereinafter referred to as a Flexe Group) are consistent, the PhyNumbers of member ports are consistent and a negotiation mode is consistent; if the inquired configuration information is checked to be abnormal, the problematic equipment node and the detailed problem information are stored in the memory; sending the execution state (success or failure) of the diagnosis action to a front-end interface in a notification mode to display information data of the diagnosis process;

step 313: the back end of the network management system delimitates the service fault (namely, the internal fault or the external fault of the network) according to the execution result of the diagnosis action in the step 304; according to the execution result of the diagnosis action in the

steps

305, 309, 310 and 312, finding out the fault point and the fault reason of the service, and positioning the service fault (the equipment node causing the fault) and determining the cause (the reason causing the fault); and generating a diagnosis report, and sending the diagnosis report to a front-end interface for displaying the diagnosis report.

In an embodiment, a flowchart of a diagnosis policy including only fault definition for L3VPN OVER SR-TP scene arrangement in a bearer network management system is provided, and fig. 6 is a flowchart of a diagnosis policy including only fault definition for L3VPN OVER SR-TP scene arrangement provided in an embodiment of the present application.

As shown in fig. 6, the process of arranging L3VPN OVER SR-TP scenes only including a diagnosis policy of fault delimitation provided in the embodiment of the present application includes the following steps:

step 401: all service fault diagnosis strategies and diagnosis rules contained in the strategies are displayed on a front-end interface of the network management system according to service fault and networking scene classification;

step 402: selecting a diagnostic rule of accessibility detection in an L3VPN scene on-off diagnostic strategy;

step 403: configuring some parameters of a diagnostic rule of accessibility detection on an interface, wherein the parameters comprise tos priority and a packet returning mode of an L3VPN PING;

step 404: arranging the configured diagnosis rules into a new diagnosis strategy according to the workflow, and transmitting the strategy information to the back end of the network management system;

step 405: and storing the diagnosis strategy at the back end of the network management system, and adding the strategy into a diagnosis strategy library of the network management system.

In one embodiment, a fault diagnosis apparatus is provided, and as shown in fig. 7, the fault diagnosis apparatus provided in this embodiment mainly includes a diagnosis policy determination module 71, a fault diagnosis module 72, and a diagnosis information determination module 73.

The diagnosis policy determining module 71 is configured to determine a current networking scenario and a diagnosis policy corresponding to a service type to be diagnosed;

the fault diagnosis module 72 is configured to diagnose the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result;

a diagnostic information determination module 73 configured to determine fault diagnostic information of the service to be diagnosed based on the diagnosis result.

The fault diagnosis device provided by the embodiment of the application determines the diagnosis strategy corresponding to the current networking scene and the service type; diagnosing the service to be diagnosed according to the diagnosis strategy to obtain a diagnosis result; and determining the fault diagnosis information of the service to be diagnosed based on the diagnosis result, realizing service fault diagnosis, delimiting, positioning and determining the fault service, and improving the accuracy and flexibility of service fault diagnosis.

In one embodiment, determining a diagnosis policy corresponding to a current networking scenario and a service type to be diagnosed includes: displaying the current networking scene and all diagnosis strategies corresponding to all service types; and determining a diagnosis strategy corresponding to the current networking scene and the service type based on a selection instruction input by a user.

In one embodiment, diagnosing the service to be diagnosed according to the workflow in the diagnosis policy includes: modeling the service to be diagnosed based on the service routing information and the service level information of the service to be diagnosed to obtain a service model to be diagnosed;

and diagnosing the service model to be diagnosed according to the diagnosis strategy.

In one embodiment, after performing the diagnostic action according to the workflow of the diagnostic rule, the method further includes: and after the diagnosis action is executed, generating an action execution state and an action execution result, and displaying the action execution state and the action execution result in a list form.

The fault diagnosis device provided by the embodiment can execute the fault diagnosis method provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects for executing the method. For details of the technique not described in detail in this embodiment, reference may be made to the fault diagnosis method provided in any embodiment of the present invention.

It should be noted that, in the embodiment of the fault diagnosis apparatus, the included units and modules are merely divided according to functional logic, but are not limited to the above division as long as the corresponding functions can be implemented; in addition, specific names of the functional units are only used for distinguishing one functional unit from another, and are not used for limiting the protection scope of the application.

Fig. 8 is a schematic structural diagram of an apparatus provided in the embodiment of the present application, and as shown in fig. 8, the apparatus includes a processor 81, a memory 82, an input device 83, an output device 84, and a communication device 85; the number of the processors 81 in the device may be one or more, and one processor 81 is taken as an example in fig. 8; the processor 81, the memory 82, the input device 83 and the output device 84 in the apparatus may be connected by a bus or other means, and the connection by the bus is exemplified in fig. 8.

The memory 82, which is a computer-readable storage medium, may be used to store software programs, computer-executable programs, and modules. The processor 81 executes various functional applications of the device and data processing by executing software programs, instructions and modules stored in the memory 82, namely, implements any of the methods provided by the embodiments of the present application.

The memory 82 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the device, and the like. Further, the memory 82 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, the memory 82 may further include memory located remotely from the processor 81, which may be connected to the device over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 83 is operable to receive input numeric or character information and to generate key signal inputs relating to user settings and function controls of the apparatus. The output device 84 may include a display device such as a display screen.

The communication device 85 may include a receiver and a transmitter. The communication device 85 is configured to perform information transceiving communication according to control of the processor 81.

In an exemplary embodiment, the present application further provides a storage medium containing computer-executable instructions, which when executed by a computer processor, are used to perform a fault diagnosis method, including:

Of course, the storage medium provided in the embodiments of the present application contains computer-executable instructions, and the computer-executable instructions are not limited to the operations of the method described above, and may also perform related operations in the fault diagnosis method provided in any embodiments of the present application.

From the above description of the embodiments, it is obvious for those skilled in the art that the present application can be implemented by software and necessary general hardware, and certainly can be implemented by hardware, but the former is a better embodiment in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which may be stored in a computer-readable storage medium, such as a floppy disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a FLASH Memory (FLASH), a hard disk or an optical disk of a computer, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute the methods described in the embodiments of the present application.

The above description is only exemplary embodiments of the present application, and is not intended to limit the scope of the present application.

It will be clear to a person skilled in the art that the term user terminal covers any suitable type of wireless user equipment, such as a mobile phone, a portable data processing device, a portable web browser or a car mounted mobile station.

In general, the various embodiments of the application may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the application is not limited thereto.

Embodiments of the application may be implemented by a data processor of a mobile device executing computer program instructions, for example in a processor entity, or by hardware, or by a combination of software and hardware. The computer program instructions may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages.

Any logic flow block diagrams in the figures of this application may represent program steps, or may represent interconnected logic circuits, modules, and functions, or may represent a combination of program steps and logic circuits, modules, and functions. The computer program may be stored on a memory. The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), optical storage devices and systems (digital versatile disks, DVDs, or CD discs), etc. The computer readable medium may include a non-transitory storage medium. The data processor may be of any type suitable to the local technical environment, such as but not limited to general purpose computers, special purpose computers, microprocessors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), programmable logic devices (FGPAs), and processors based on a multi-core processor architecture.

The foregoing has provided by way of exemplary and non-limiting examples a detailed description of exemplary embodiments of the present application. Various modifications and adaptations to the foregoing embodiments may become apparent to those skilled in the relevant arts in view of the following drawings and the appended claims without departing from the scope of the invention. Therefore, the proper scope of the invention is to be determined according to the claims.

Claims

1. A fault diagnosis method, comprising:

determining a diagnosis strategy based on the current networking scene and the type of the service to be diagnosed;

and determining the fault information of the service to be diagnosed based on the diagnosis result.

2. The method of claim 1, wherein determining the diagnosis policy corresponding to the current networking scenario and the service type to be diagnosed comprises:

displaying all the diagnosis strategies corresponding to all the networking scenes and all the service types;

and determining a diagnosis strategy corresponding to the current networking scene and the type of the service to be diagnosed based on a selection instruction input by a user.

3. The method of claim 1, wherein the diagnosis policy comprises one or more diagnosis rules, and diagnosing the service to be diagnosed according to the diagnosis policy to obtain a diagnosis result comprises:

loading all diagnosis rules in the diagnosis strategy;

executing a diagnosis action according to the workflow of the diagnosis rule aiming at each diagnosis rule to obtain a rule execution result;

and summarizing a plurality of rule execution results to form the diagnosis result.

4. The method of claim 3, after performing a diagnostic action according to the workflow of the diagnostic rule, further comprising:

after the diagnostic rule is executed, updating a workflow diagram and/or a work list corresponding to the diagnostic rule;

and displaying the workflow diagram and/or the work list.

5. The method of claim 3, wherein loading all diagnostic rules in the diagnostic policy comprises:

and automatically loading all the diagnosis rules in the diagnosis strategy by utilizing a workflow strategy engine.

6. The method of claim 1, wherein before determining the diagnostic policy corresponding to the current networking scenario and the service type, the method further comprises:

determining a diagnosis strategy corresponding to each type of service fault and networking scene;

storing a plurality of diagnostic policies into a diagnostic policy repository.

7. The method of claim 6, wherein determining the diagnostic policy for each service failure and each networking scenario comprises:

determining a diagnosis rule based on a target service fault and a target networking scene;

configuring parameters of the diagnostic rules;

and arranging a plurality of configured diagnosis rules into a diagnosis strategy according to the workflow.

8. A failure diagnosis device characterized by comprising:

9. An apparatus, comprising:

one or more processors;

a memory for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement any of the methods described herein.

10. A storage medium, characterized in that the storage medium stores a computer program which, when executed by a processor, implements any of the methods.