Fault processing method, electronic equipment, readable medium and program product

Abstract

The invention provides a fault processing method, and the method comprises the steps: carrying out the classification processing of fault information, and obtaining a target fault type to which the fault information belongs; according to a fault knowledge graph and a fault processing standard process library, a fault processing graph and a standard processing process corresponding to the target fault category are determined, and the standard processing process comprises a plurality of fault processing stages; reasoning a fault processing process according to the fault processing atlas, the standard processing flow and the system interface information to obtain a target execution flow corresponding to the fault information, the target execution flow comprising steps of each stage in the standard processing flow and interface calling marks of each step, and being used for obtaining a fault processing result, the interface calling marks are used for indicating callable system interfaces corresponding to different steps. The invention further provides electronic equipment, a readable medium and a program product.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and in particular, to a fault processing method, an electronic device, a readable medium and a program product. BACKGROUND

[0002] With the rapid development of computer technology, computer software systems are developing towards high complexity and high dynamics. For example, computer software systems running on IT (Information Technology) infrastructures of data centers, cloud computing platforms or large enterprises usually have high complexity and dynamics. In order to improve the stability of computer software systems and enhance user experience, fault processing is crucial. In the related art, the efficiency of fault processing is low and the accuracy is not high. SUMMARY

[0003] The present disclosure provides a fault processing method, an electronic device, a readable medium and a program product.

[0004] In a first aspect, an embodiment of the present disclosure provides a fault processing method, comprising: performing classification processing on fault information to obtain a target fault category to which the fault information belongs; determining a fault processing graph and a standard processing flow corresponding to the target fault category according to a fault knowledge graph and a fault processing standard flow library, the standard processing flow comprising a plurality of stages of fault processing; performing reasoning on a fault processing process according to the fault processing graph, the standard processing flow and system interface information to obtain a target execution flow corresponding to the fault information, the target execution flow comprising steps of each stage in the standard processing flow and interface call markers of each step, and the target execution flow being used to obtain a fault processing result, and the interface call markers being used to indicate callable system interfaces corresponding to different steps.

[0005] In a second aspect, an embodiment of the present disclosure provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program executable by the processor, and the computer program is executed by the processor to implement the above-mentioned fault processing method.

[0006] In a third aspect, an embodiment of the present disclosure provides a computer readable medium, which stores a computer program, and the computer program is executed by a processor to implement the above-mentioned fault processing method.

[0007] In a fourth aspect, an embodiment of the present disclosure provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the above-mentioned fault processing method.

[0008] The fault handling method of this disclosure can determine the target fault category to which the fault information belongs, and then determine the fault handling map and standard handling process corresponding to the target fault category. Then, based on the fault handling map, standard handling process and system interface information, the fault handling process is reasoned to obtain the target execution process corresponding to the fault information. After executing the target execution process, the fault handling result is obtained. Thus, the fault handling process can be reasoned based on the three types of information: fault handling map, standard handling process and system interface information. This not only improves the efficiency of fault handling, but also improves the accuracy of fault handling. Attached Figure Description

[0009] In the accompanying drawings of the embodiments disclosed herein:

[0010] Figure 1 A flowchart of a fault handling method provided in an embodiment of this disclosure;

[0011] Figure 2 A schematic diagram illustrating the process of determining the target execution flow in a fault handling method provided in this embodiment of the present disclosure;

[0012] Figure 3 This is a schematic diagram illustrating the execution process of the target execution flow in a fault handling method provided in this embodiment of the disclosure;

[0013] Figure 4 A schematic diagram illustrating the processing procedure of a fault handling method provided in an embodiment of this disclosure;

[0014] Figure 5 This is a schematic diagram of a fault handling diagram provided in an embodiment of the present disclosure;

[0015] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of this disclosure, the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0017] The present disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of the disclosure.

[0018] The accompanying drawings of the embodiments disclosed herein are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the detailed embodiments to explain this disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the description of the detailed embodiments with reference to the accompanying drawings.

[0019] This disclosure may be described with reference to plan and / or cross-sectional views using the ideal schematic diagrams of this disclosure. Therefore, the example illustrations may be modified according to manufacturing techniques and / or tolerances.

[0020] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0021] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. The terms "comprising," "made of," etc., as used in this disclosure specify the presence of the stated feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0022] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this disclosure.

[0023] This disclosure is not limited to the embodiments shown in the accompanying drawings, but includes modifications to the configuration based on the manufacturing process. Therefore, the areas illustrated in the drawings are schematic, and the shapes of the areas shown illustrate specific shapes of the areas of an element, but are not intended to be limiting.

[0024] With the rapid development of computer technology, computer software systems are becoming increasingly complex and dynamic. For example, computer software systems running on data centers, cloud computing platforms, or the IT infrastructure of large enterprises typically exhibit high complexity and dynamism. Therefore, fault handling is crucial for improving the stability of computer software systems and enhancing user experience.

[0025] Furthermore, fault handling is also a crucial component of system health management. System health management refers to the technology of assessing, predicting, handling, and maintaining the health status of a system during its operational lifecycle by real-time monitoring, analysis, and prediction of its operational status and performance data. Improving the efficiency and accuracy of fault handling enhances the capabilities of system health management.

[0026] In some related technologies, fault handling is based on knowledge graphs and large models. For example, a large model is used to reason based on a knowledge graph to determine and execute the fault handling process. However, this method, relying solely on the knowledge graph, suffers from slow reasoning speed and low accuracy in obtaining the fault handling process, thus affecting the efficiency and accuracy of fault handling.

[0027] In other related technologies, fault handling mainly relies on expert experience and text output. This method requires manual intervention, is inefficient, and because expert experience usually has certain limitations, fault handling based on expert experience and text output may result in inaccurate fault location, leading to low accuracy in fault handling.

[0028] As a result, the efficiency and accuracy of fault handling in related technologies are low.

[0029] In a first aspect, embodiments of this disclosure provide a fault handling method. The method includes: classifying fault information to obtain a target fault category to which the fault information belongs; determining a fault handling graph and a standard handling process corresponding to the target fault category based on a fault knowledge graph and a fault handling standard process library, wherein the standard handling process includes multiple stages of fault handling; and reasoning about the fault handling process based on the fault handling graph, the standard handling process, and system interface information to obtain a target execution process corresponding to the fault information, wherein the target execution process includes steps in each stage of the standard handling process and interface call markers for each step, used to obtain a fault handling result, and the interface call markers are used to indicate callable system interfaces corresponding to different steps.

[0030] The fault handling method of this disclosure can determine the target fault category to which the fault information belongs, and then determine the fault handling map and standard handling process corresponding to the target fault category. Then, based on the fault handling map, standard handling process and system interface information, the fault handling process is reasoned to obtain the target execution process corresponding to the fault information. After executing the target execution process, the fault handling result is obtained. Thus, the fault handling process can be reasoned based on the three types of information: fault handling map, standard handling process and system interface information. This not only improves the efficiency of fault handling, but also improves the accuracy of fault handling.

[0031] The fault handling method of this disclosure can be applied not only to system health management scenarios, but also to fault handling of software systems in scenarios such as communication network management, data centers, intelligent manufacturing, ToB (To Business) network management, and IoT (Internet of Things). It should be noted that the fault handling method of this disclosure can also be applied to other scenarios requiring fault handling, and this disclosure does not impose any limitations on these applications.

[0032] To improve the real-time performance of data transmission and processing, as well as the data storage and processing capabilities, when applying the fault handling method of this disclosure, a high-speed interconnected network environment, cloud computing environment, etc., can be constructed in the application scenario. Furthermore, the fault handling method of this disclosure involves a fault knowledge graph, which can provide an environment supporting knowledge graph construction and management technologies in the application scenario.

[0033] Figure 1 A flowchart illustrating a fault handling method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The fault handling method of this disclosure includes:

[0034] Step S11: Classify the fault information to obtain the target fault category to which the fault information belongs.

[0035] The fault information may include fault symptoms, fault problems, fault events, and other fault-related information. Fault information can be actively acquired by the system or obtained through user input (which is passive acquisition for the system).

[0036] In some possible implementations, during system operation, fault information can be obtained through real-time analysis of system logs and process data (referring to data generated during system operation, including operation logs, intermediate data, and output data).

[0037] In some possible implementations, users can input fault symptoms and problem descriptions in natural language via text, voice, or other means at the system front end. After receiving the user input, the system can perform intent recognition to obtain the intent recognition result. If the intent recognition result indicates a fault handling request, the user input is confirmed as fault information. This method enables the conversion from natural language to machine language, allowing users to input fault symptoms or problem descriptions into the system using natural language, thereby improving system usability and user experience, and reducing the human cost of machine coding.

[0038] In some possible implementations, a second neural network can be used for intent recognition to identify the user's input. For example, the user's input can be fed into the second neural network; the second neural network can then identify the input and determine whether it is a fault handling request, a knowledge query, a data query, a function call, or something else. If the result is a knowledge query, data query, function call, or something else, the request is forwarded to the corresponding module or program for processing; if the result is a fault handling request, the user's input is identified as fault information. Using a second neural network for intent recognition can improve the efficiency and accuracy of intent recognition.

[0039] Before using the second neural network, it can be pre-trained. The training process can include, for example: collecting data, including fault handling-related corpora, problem description-related corpora, knowledge question-and-answer-related corpora, data query-related corpora, function call-related corpora, and other corpora; cleaning and labeling the collected data to obtain a training set; using the training set to train the second neural network; after successful training, testing and verifying the second neural network; and after successful verification, obtaining the trained second neural network.

[0040] It should be noted that the number of network parameters in the second neural network is smaller than that in the first neural network, and the difference between the two can be orders of magnitude. Therefore, from the perspective of the number of network parameters, the second neural network can be regarded as a small model and the first neural network as a large model.

[0041] In some possible implementations, multiple fault categories can be preset. After obtaining fault information, the fault information can be classified through methods such as keyword extraction and semantic matching to obtain the target fault category to which the fault information belongs, so that subsequent steps can be processed based on the target fault category.

[0042] In some possible implementations, a third neural network for fault classification can be used to classify fault information and obtain the target fault category to which the fault information belongs. That is, fault information can be input into the third neural network for processing to obtain the target fault category. The third neural network can be pre-trained, using historical fault information with labeled fault categories as training data. Using a third neural network for fault classification can improve the efficiency and accuracy of fault classification.

[0043] It should be noted that the number of network parameters in the third neural network is smaller than that in the first neural network, and the difference between the two can be orders of magnitude. Therefore, from the perspective of the number of network parameters, the third neural network can be regarded as a small model and the first neural network as a large model.

[0044] Step S12: Based on the fault knowledge graph and the fault handling standard process library, determine the fault handling graph and standard processing process corresponding to the target fault category.

[0045] A knowledge graph is a graphical data structure used to store entities and relationships between them, supporting information retrieval and knowledge discovery. The fault knowledge graph in this embodiment is constructed by classifying historical fault handling information according to multiple preset fault categories. The construction process of the fault knowledge graph can be as follows: First, collect historical fault handling information, including historical fault handling knowledge, fault handling SOPs (Standard Operating Procedures), historical alarm knowledge, operation guidelines, and expert experience; then, clean the collected historical fault handling information; subsequently, classify the cleaned historical fault handling information according to multiple preset fault categories, and extract entities and relationships from the classified historical fault handling information; then, construct the entities and relationships to obtain the fault knowledge graph. It should be noted that the fault knowledge graph can be dynamically optimized according to actual conditions during use. By constructing a knowledge graph, human experience in fault handling and historical fault handling knowledge can be converted into a fault knowledge graph for storage, thereby not only solidifying historical fault handling knowledge but also improving its utilization rate.

[0046] Once the target fault category is obtained, the fault knowledge graph can be searched based on this category to determine the corresponding fault handling graph. In other words, the fault handling graph is a sub-graph of the fault knowledge graph corresponding to the target fault category, used for fault handling. The fault handling graph includes the node containing the target fault category and its child nodes within the fault knowledge graph.

[0047] The fault handling standard procedure library includes standard handling procedures for different categories of faults. The construction process of the fault handling standard procedure library can be, for example, as follows: first, obtain the fault handling SOP (Standard Operating Procedure) flow; then, classify the fault handling SOP flow according to multiple preset fault categories to obtain the standard handling procedures for different categories of faults. These standard handling procedures include multiple stages of fault handling. The standard handling procedures in the fault handling standard procedure library can be stored in a vectorized manner (i.e., converting text into vector form, for example, through text2vec) to facilitate accurate matching and semantic retrieval.

[0048] Once the target fault category is obtained, a standard fault handling procedure library can be searched to determine the standard handling procedure corresponding to the target fault category. The standard handling procedure corresponding to the target fault category may include multiple stages of fault handling. For example, the standard handling procedure corresponding to the target fault category may include four stages: statistical stage, analysis stage, repair stage, and verification stage. It should be noted that the verification stage here refers to the verification during the fault handling process, which is different from the verification of the fault handling results discussed below.

[0049] Step S13: Based on the fault handling map, the standard processing flow and system interface information, reason about the fault handling process to obtain the target execution flow corresponding to the fault information. The target execution flow is used to obtain the fault handling result.

[0050] The system interface information may include the name and description of the system interface. The system interface may include at least one of the following: Application Programming Interface (API), Agent Interaction Interface, and Database Query Interface. It should be noted that the system interface may also include other callable interfaces; this disclosure does not limit the specific type of system interface.

[0051] Based on the fault handling diagram, standard handling procedures, and system interface information, the fault handling process can be inferred to obtain the target execution flow corresponding to the fault information. The target execution flow refers to an executable flow that includes specific fault handling steps, which may include the steps of each stage in the standard handling procedure and the interface call markers for each step. The interface call markers can be used to indicate the callable system interfaces corresponding to different steps.

[0052] In some possible implementations, the interface call markers for a step may include the system interfaces that the step can call. For example, if the interface call markers for step A are interface C and interface D, it means that the system interfaces that step A can call are interface C and interface D. If the interface call markers for a step are empty, it means that the step has no system interfaces that can be called.

[0053] In some possible implementations, the interface call flag for a step can also be a first flag (e.g., true) indicating that the step has a callable system interface, or a second flag (e.g., true) indicating that the step does not have a callable system interface. If the interface call flag for a step is the first flag, the callable system interface is determined when the step is executed.

[0054] It should be noted that those skilled in the art can determine the specific implementation of the interface call marker based on the actual situation, and this disclosure does not impose any restrictions on it.

[0055] In some possible implementations, a first neural network (which can be viewed as a large model, such as ChatGPT or Baichuan) can infer the fault handling process based on the fault handling graph, standard processing flow, and system interface information to obtain the target execution flow corresponding to the fault information. This approach improves the inference efficiency and accuracy of the fault handling process, thereby enhancing the accuracy of the target execution flow.

[0056] Once the target execution flow is obtained, the steps in the target execution flow can be executed sequentially to obtain the fault handling result. The fault handling result includes whether the fault is resolved or not. The fault handling result can be sent to the system front end via messages, pop-up text, etc., for users to view.

[0057] The fault handling method of this disclosure can determine the target fault category to which the fault information belongs, and then determine the fault handling map and standard handling process corresponding to the target fault category. Then, based on the fault handling map, standard handling process and system interface information, the fault handling process is reasoned to obtain the target execution process corresponding to the fault information. After executing the target execution process, the fault handling result is obtained. Thus, the fault handling process can be reasoned based on the three types of information: fault handling map, standard handling process and system interface information. This not only improves the efficiency of fault handling, but also improves the accuracy of fault handling.

[0058] In some possible implementations, the fault knowledge graph is stored as triples. The triples can be stored as follows: {"entity":"database performance bottleneck","relation":"includes","associated entity":"statistics"}, where "entity" is the first entity in the triple named "database performance bottleneck," meaning the node corresponding to this entity in the fault knowledge graph is named "database performance bottleneck"; "associated entity" is the second entity in the triple named "statistics," meaning the node corresponding to this associated entity in the fault knowledge graph is named "statistics"; and "relation" represents the relationship between the entity and the associated entity. In this example, the relationship between the entity and the associated entity is "includes" (has a), meaning the triple represents that the entity "database performance bottleneck" includes the associated entity "statistics".

[0059] In some possible implementations, step S13 may include: determining a first set of triples corresponding to the fault handling graph; reasoning about the triples corresponding to the stages based on the standard processing flow and the first set of triples to obtain a preliminary execution flow, wherein the preliminary execution flow includes multiple stages in the standard processing flow and triples corresponding to each stage; and reasoning about the steps included in each stage and the interface call markers of each step based on the preliminary execution flow and the system interface information to obtain a target execution flow corresponding to the fault information.

[0060] The first set of triples corresponding to the fault handling graph can be obtained from the storage area of ​​the fault knowledge graph. Then, based on the standard processing flow and the first set of triples, reasoning can be performed on the triples corresponding to the stages to obtain the preliminary execution flow. The reasoning on the triples corresponding to the stages is a reasoning that matches the stages in the standard processing flow with the triples in the first set of triples, and this reasoning can be regarded as graph reasoning.

[0061] The standard processing flow includes multiple stages of fault handling. For any stage in the standard processing flow, based on the stage's description information (including stage name, stage description, etc.) and the triples in the first set of triples, reasoning is performed to obtain the triples corresponding to that stage. Then, according to the stage order in the standard processing flow, the triples corresponding to each stage are stored as an ordered array. Finally, the multiple stages of fault handling in the standard processing flow and their corresponding ordered arrays are used to determine the preliminary execution flow. The preliminary execution flow includes multiple stages in the standard processing flow and the corresponding triples for each stage.

[0062] After obtaining the preliminary execution flow, the steps included in each stage and the interface call markers for each step can be inferred based on the preliminary execution flow and system interface information. This inference determines the steps included in each stage and the interface call markers for each step, thereby obtaining the target execution flow corresponding to the fault information. This inference can be viewed as interface inference.

[0063] As one embodiment of this disclosure, when determining the target execution flow, firstly, a first set of triples corresponding to the fault handling graph is determined. Then, based on the standard processing flow and the first set of triples, reasoning is performed on the triples corresponding to the stages to obtain a preliminary execution flow. Next, based on the preliminary execution flow and system interface information, reasoning is performed on the steps included in the stages and the interface call markers of each step to obtain the target execution flow. This allows graph reasoning (reasoning on the triples corresponding to the stages) and interface reasoning (reasoning on the steps included in the stages and the interface call markers of each step) to be combined when determining the target execution flow, thereby improving the accuracy of the target execution flow.

[0064] In some possible implementations, the step of reasoning about the triples corresponding to the stage based on the standard processing flow and the first triple set to obtain a preliminary execution flow includes: for any stage in the standard processing flow, inputting the description information of the stage and the first triple set into a first neural network to perform semantic matching-based reasoning to obtain the triples corresponding to the stage.

[0065] The descriptive information for each stage includes the stage name and stage description, and this disclosure does not limit the specific content of the descriptive information for each stage. The first neural network can be a large model such as ChatGPT or Baichuan, and this disclosure does not limit the specific type of the first neural network.

[0066] For any stage in the standard processing flow, the triples corresponding to that stage can be determined through reasoning by the first neural network. The descriptive information of that stage (including stage name, stage description, etc.) and the first set of triples can be input into the first neural network for semantic matching-based reasoning to obtain the triples corresponding to that stage.

[0067] In some possible implementations, to improve the inference accuracy of the triples corresponding to the stage, a first prompt message can be used to interact with the first neural network (i.e., a large model + prompt approach). The first prompt message is a type of prompt word information. It can be used to define the reference examples, output format, output requirements, and inference inputs of the first neural network when performing semantic matching-based inference based on the description information of any stage in the standard processing flow and the first triple set. It should be noted that the specific content of the first prompt message can be set by those skilled in the art according to the actual situation, and this disclosure does not impose any limitations on it.

[0068] For any stage in the standard processing flow, the description information and the first set of triples for that stage can be formatted according to the input of the reference example in the first prompt information. The formatted description information and the first set of triples for that stage are then used as the inference input in the first prompt information, which is then input into the first neural network. After receiving the first prompt information, the first neural network can obtain the description information and the first set of triples for that stage from the inference input of the first prompt information. Then, it performs semantic matching on the entities in the description information and the first set of triples for that stage, and determines the triples containing the entities (which can be subject or object) that match the description information of that stage as the triples corresponding to that stage. Finally, it outputs the triples corresponding to that stage according to the output format and output requirements in the first prompt information, thus obtaining the triples corresponding to that stage.

[0069] By performing the above processing on each stage of the standard processing flow, a preliminary execution flow can be obtained.

[0070] As one embodiment of this disclosure, when determining the preliminary execution flow, for any stage in the standard processing flow, the description information of that stage and the first set of triples can be input into a first neural network for semantic matching-based reasoning to obtain the triples corresponding to that stage. This approach not only improves processing speed but also enhances the accuracy of the preliminary execution flow.

[0071] In some possible implementations, the step of reasoning about the steps included in the stage and the interface call tags of each step based on the preliminary execution flow and the system interface information to obtain the target execution flow corresponding to the fault information includes: for any stage in the preliminary execution flow, determining the steps included in the stage from the triples corresponding to the stage; for any step, inputting the description information of the step and the system interface information into a first neural network for semantic matching-based reasoning to obtain the interface call tag of the step.

[0072] For any stage in the initial execution process, the corresponding triple contains its specific steps. Therefore, the steps included in that stage can be determined from the triple corresponding to that stage; these steps are executable single-step processing steps. For example, assuming the statistics stage includes steps A1 and A2, and the nodes corresponding to steps A1 and A2 in the fault handling graph are leaf nodes, then steps A1 and A2 can be regarded as executable single-step processing steps.

[0073] For any given stage, when retrieving the steps of that stage from the triples corresponding to that stage, the triples that represent the first entity (i.e., the subject) can be identified. Then, the second entity (i.e., the object) in the triples can be traversed to determine if it is a leaf node. If it is a leaf node, the relevant operation represented by the second entity can be identified as the steps of that stage. If it is not a leaf node, a similar method can be used to traverse the triples of the child nodes until a leaf node is reached.

[0074] Once the steps included in the stage are determined, for any step, the interface call marker for that step can be determined through reasoning by the first neural network. The description information of the step (including the step name, description, etc.) and the system interface information can be input into the first neural network for semantic matching-based reasoning to obtain the interface call marker for that step.

[0075] In some possible implementations, to improve the inference accuracy of the interface call markers for the steps, a second prompt message can be used to interact with the first neural network (i.e., a large model + prompt approach). The second prompt message is a type of prompt information that can be used to define the reference examples, output format, output requirements, and inference inputs for the first neural network when performing language matching-based inference based on the step description information and system interface information. It should be noted that the specific content of the second prompt message can be set by those skilled in the art according to the actual situation, and this disclosure does not impose any limitations on it.

[0076] For any step, the description information and system interface information of that step can be formatted according to the input of the reference example in the second prompt information. The formatted description information and system interface information of that step are then used as the inference input in the second prompt information, which is then input into the first neural network. After receiving the second prompt information, the first neural network can obtain the description information and system interface information of that step from the inference input of the second prompt information, and perform semantic matching on the description information of each interface in the description information and system interface information of that step to obtain the interface call flag of that step. Then, the interface call flag of that step is output according to the output format and output requirements in the second prompt information.

[0077] As one embodiment of this disclosure, when determining the target execution flow, for any stage in the preliminary execution flow, the steps included in that stage can be determined from the triples corresponding to that stage. Then, for any step, the description information and system interface information of that step are input into a first neural network for semantic matching-based reasoning to obtain the interface call tag for that step. This approach not only improves processing speed but also enhances the accuracy of the target execution flow.

[0078] Figure 2 This is a schematic diagram illustrating the process of determining the target execution flow in a fault handling method provided in this embodiment of the disclosure. (Refer to...) Figure 2When determining the target execution flow, the fault information 20 is classified to obtain the target fault category 21 to which the fault information 20 belongs; from the fault knowledge graph 22, the fault processing graph 23 corresponding to the target fault category 21 is determined, and then the first triple set 24 corresponding to the fault processing graph 23 is determined; from the fault processing standard process library 25, the standard processing flow 26 corresponding to the target fault category 21 is determined, and the standard processing flow 26 includes multiple stages of fault processing; based on the standard processing flow 26 and the first triple set 24, the triples corresponding to the stages are reasoned to obtain the preliminary execution flow 27, which includes multiple stages in the standard processing flow 26 and the triples corresponding to each stage; based on the preliminary execution flow 27 and the system interface information 28, the steps included in the stages and the interface call tags of each step are reasoned to obtain the target execution flow 29 corresponding to the fault information 20.

[0079] In some possible implementations, the method may further include: sequentially executing the steps in the target execution flow to obtain the execution results of each step; and determining the fault handling result based on the execution results of each step.

[0080] The target execution flow includes multiple executable steps. When executing the target execution flow, the steps are executed sequentially to obtain the execution result of each step. The execution results of each step can then be summarized and analyzed to obtain the fault handling result. The fault handling result includes whether the fault is resolved or not. If the fault is not resolved, possible causes can be displayed on the system front end for users to review and take appropriate action.

[0081] As one embodiment of this disclosure, the steps in the target execution flow can be executed sequentially to obtain the execution results of each step, and the fault handling result can be determined based on the execution results of each step, thereby improving the accuracy of step execution and fault handling results, and thus improving the precision of fault handling.

[0082] In some possible implementations, the method further includes: when executing the target execution flow, if the interface call flag of a step in the target execution flow is not empty, calling the system interface indicated by the interface call flag of the step, and determining the call result as the execution result of the step.

[0083] When executing the target execution flow, for any step in the target execution flow, it can first be determined whether the interface call flag of that step is empty; if the interface call flag of that step is not empty, the parameters of the system interface indicated by the interface call flag of that step can be extracted, and then the system interface can be called according to the extracted parameters, and the call result can be determined as the execution result of that step. If the call fails, the call will end after a first preset number of times.

[0084] As one embodiment of this disclosure, when executing the target execution flow, if the interface call flag of a step in the target execution flow is not empty, the system interface indicated by the interface call flag of that step is called, and the call result is determined as the execution result of that step. This enables the fault handling steps to be executed by calling the system interface, thereby improving the efficiency and automation of fault handling.

[0085] In some possible implementations, the method further includes: when executing the target execution flow, if the interface call flag of a step in the target execution flow is empty, determining the target knowledge corresponding to the step from a preset fault handling knowledge base; and determining the target knowledge as the execution result of the step.

[0086] When executing the target execution process, for any step in the target execution process, it can first be determined whether the interface call flag of the step is empty; if the interface call flag of the step is empty, the knowledge corresponding to the step can be queried from the preset fault handling knowledge base (e.g., the RAG (Retrievable-Augmented Generation) knowledge base, which includes fault handling SOPs, fault handling knowledge, alarm knowledge, operation guidelines, etc.), and the queried knowledge can be organized and summarized to obtain the target knowledge corresponding to the step. The target knowledge may include fault handling operation guidance or suggestions, etc.; then the target knowledge is determined as the execution result of the step.

[0087] As one embodiment of this disclosure, when executing a target execution flow, if the interface call flag of a step in the target execution flow is empty, the target knowledge corresponding to that step can be determined from the fault handling knowledge base, and the target knowledge can be determined as the execution result of that step, thereby improving the accuracy of fault handling.

[0088] Figure 3 This is a schematic diagram illustrating the execution process of the target execution flow in a fault handling method provided in this embodiment of the disclosure. Execution Figure 3 When executing the target execution flow 30, the steps to be executed can be extracted sequentially from the target execution flow 30; for any extracted step 31, it is determined whether the interface call flag 32 of step 31 is empty; if the interface call flag 32 is not empty, the system interface 33 indicated by the interface call flag 32 is determined; the system interface 33 is called to obtain the call result 34, and the call result 34 is determined as the execution result 35 of step 31.

[0089] If the interface call flag 32 is empty, the target knowledge 37 corresponding to step 31 is determined from the fault handling knowledge base 36, and the target knowledge 37 is determined as the execution result 38 of step 31.

[0090] In some possible implementations, the interface call flag for a step is a first flag (e.g., true) indicating that the step has a callable system interface, or a second flag (e.g., false) indicating that the step does not have a callable system interface. When executing a step, it can be determined whether the interface call flag is empty: if the interface call flag is the first flag, it is considered not empty; if the interface call flag is the second flag, it is considered empty.

[0091] When executing the steps, you can also check the interface call flag. If the interface call flag is the first flag, perform similar processing as if the interface call flag is not empty. If the interface call flag is the second flag, perform similar processing as if the interface call flag is empty.

[0092] Based on this, the method further includes: when executing the target execution flow, if the interface call of a step in the target execution flow is marked as a first marker, inputting the description information of the step and the system interface information into a first neural network to perform semantic matching-based reasoning to obtain the target interface that the step can call; calling the target interface, and determining the call result as the execution result of the step.

[0093] When executing the target execution flow, for any step in the target execution flow, the interface call flag of that step can be checked first. If the interface call flag is the first flag, the description information and system interface information of that step can be input into the first neural network for semantic matching-based reasoning to obtain the target interface that can be called by that step. Then, the parameters of the target interface are extracted, and the target interface is called according to the extracted parameters. The call result is then determined as the execution result of that step. If the call fails, the call ends after a first preset number of times.

[0094] As one embodiment of this disclosure, when executing the target execution flow, if the interface call of a step in the target execution flow is marked as a first marker, the description information and system interface information of the step can be input into a first neural network for semantic matching-based reasoning to obtain the target interface that the step can call. Then, the target interface is called, and the call result is determined as the execution result of the step. This enables the fault handling steps to be executed by calling the system interface, thereby improving the efficiency and automation of fault handling.

[0095] In some possible implementations, the method further includes: when executing the target execution flow, if the interface call of a step in the target execution flow is marked with a second marker, determining the target knowledge corresponding to the step from a preset fault handling knowledge base; and determining the target knowledge as the execution result of the step.

[0096] When executing the target execution process, for any step in the target execution process, the interface call marker of that step can be viewed first. If the interface call marker is the second marker, the knowledge corresponding to that step can be queried from a preset fault handling knowledge base (e.g., a RAG (Retrieval-Augmented Generation) knowledge base that includes fault handling SOPs, fault handling knowledge, alarm knowledge, operation guidelines, etc.). The queried knowledge is then organized and summarized to obtain the target knowledge corresponding to that step. This target knowledge may include fault handling operation guidance or suggestions, etc. The target knowledge is then determined as the execution result of that step.

[0097] As one embodiment of this disclosure, when executing the target execution flow, if the interface call of a step in the target execution flow is marked with a second marker, the target knowledge corresponding to that step can be determined from the fault handling knowledge base, and the target knowledge can be determined as the execution result of that step, thereby improving the accuracy of fault handling.

[0098] In some possible implementations, the method further includes: verifying the fault handling result if the fault handling result is that the fault has been resolved.

[0099] If the fault handling result indicates that the fault has been resolved, the fault handling result can be verified to confirm that the fault has been correctly diagnosed and repaired.

[0100] In some possible implementations, verifying the fault handling result includes: determining a fault verification graph and a standard verification process corresponding to the target fault category based on the fault knowledge graph and the fault handling standard process library; reasoning about the verification process based on the fault verification graph, the standard verification process, and the system interface information to obtain a verification execution process; and determining that the fault handling result has been verified as passed if the execution result of the verification execution process is passed.

[0101] When verifying the fault handling results, a similar approach to the fault handling described above can be adopted. First, a fault verification graph corresponding to the target fault category can be determined from the fault knowledge graph; that is, the fault verification graph is a sub-graph in the fault knowledge graph used for fault verification corresponding to the target fault category. Then, a standard verification process corresponding to the target fault category can be determined from the fault handling standard process library. The standard verification process includes multiple stages of fault verification.

[0102] Then, based on the fault verification map, standard verification process, and system interface information, the verification process can be reasoned to obtain the verification execution process. The verification execution process includes the steps of each stage in the standard verification process and the interface call markers for each step. Then, the verification execution process is executed to obtain the verification result. The process of reasoning to obtain the verification execution process may include: determining the second set of triples corresponding to the fault verification map; reasoning about the triples corresponding to each stage based on the standard verification process and the second set of triples to obtain the preliminary verification process, which includes multiple stages in the standard verification process and the triples corresponding to each stage; and reasoning about the steps included in each stage and the interface call markers for each step based on the preliminary verification process and system interface information to obtain the verification execution process. It should be noted that the specific method of reasoning for the verification process is similar to the specific method of reasoning for the fault handling process described above, and will not be repeated here.

[0103] The verification result includes pass and fail. If the verification result is pass, the fault handling result is determined to be verified successfully. If the verification result is fail, the above verification process can be re-executed to ensure the correctness of the verification process. If the verification result is still fail after re-executing the verification process a second preset number of times, the above fault handling process is re-executed to repair the fault.

[0104] As one embodiment of this disclosure, when verifying the fault handling result, a fault verification graph and standard verification process corresponding to the target fault category can be determined based on the fault knowledge graph and the fault handling standard process library; the verification process is reasoned based on the fault verification graph, the standard verification process and the system interface information to obtain the verification execution process; if the execution result of the verification execution process is passed, the fault handling result is determined to be verified, thereby improving the efficiency and accuracy of the verification process.

[0105] In some possible implementations, the method further includes generating a fault handling report based on the execution results of each step and the fault handling results.

[0106] It can summarize and comprehensively analyze the execution results of each step in the target execution process, and then combine them with the fault handling results to generate a fault handling report described in natural language.

[0107] In some examples, the fault handling results can be verified before generating a fault handling report, which may also include the relevant results of the fault handling results verification.

[0108] When the fault information comes from user input, a fault handling report can be sent to the user for review. When the fault information comes from real-time analysis of system logs, process data, etc., during system operation, a fault handling report can be sent to the system administrator so that the system administrator can be informed of the fault handling status in a timely manner.

[0109] As one embodiment of this disclosure, a fault handling report can be generated based on the execution results of each step and the fault handling results, thereby improving the user experience.

[0110] Figure 4 This is a schematic diagram illustrating the processing procedure of a fault handling method provided in an embodiment of this disclosure. (Refer to...) Figure 4 The fault handling method includes:

[0111] Step S401: Perform intent recognition on the information input by the user (such as fault symptoms, fault problems, knowledge Q&A, etc.) to obtain intent recognition results;

[0112] Step S402: If the intent recognition result is a fault handling request, the information input by the user is determined as fault information;

[0113] Step S403: Determine the fault handling graph corresponding to the target fault category from the fault knowledge graph;

[0114] Step S404: Determine the standard processing procedure corresponding to the target fault category from the fault handling standard process library, wherein the standard processing procedure includes multiple stages of fault handling;

[0115] Step S405: Determine the first set of triples corresponding to the fault handling map;

[0116] Step S406: Based on the standard processing flow and the first set of triples, reason about the triples corresponding to the stages to obtain the preliminary execution flow, wherein the preliminary execution flow includes multiple stages in the standard processing flow and the triples corresponding to each stage.

[0117] Step S407: Based on the preliminary execution flow and system interface information, reason about the steps included in the stage and the interface call markers of each step to obtain the target execution flow corresponding to the fault information; wherein, the target execution flow includes the steps of each stage in the standard processing flow and the interface call markers of each step, used to obtain the fault handling result; the interface call markers are used to indicate the callable system interfaces corresponding to different steps; the system interfaces include at least one of API interface, intelligent agent interaction interface and database query interface;

[0118] Step S408: Execute the steps in the target execution flow and obtain the execution results of each step;

[0119] Step S409: Analyze the execution results of each step to obtain the fault handling results;

[0120] Step S410: If the fault handling result is that the fault has been resolved, verify the fault handling result and obtain the verification result.

[0121] Step S411: Generate a fault handling report based on the fault handling results and verification results.

[0122] The fault handling method of this disclosure embodiment will be described exemplarily below with reference to Example 1.

[0123] Example 1:

[0124] Example 1's application scenario is as follows: An IT administrator at a company discovers a performance degradation issue in one of their critical business systems. The administrator reports the problem to the system using natural language: "Recently, users have reported that the online order system is responding very slowly."

[0125] The process for handling the above-mentioned fault problems in this disclosure embodiment can be exemplified as follows:

[0126] Step one: Using the second neural network, the user input information "Recently, users have reported that the online order system is responding very slowly" is processed to determine the intent, and the intent recognition result is obtained. The training data for the second neural network is shown in Table 1 below:

[0127] Table 1. Training data illustration for the second neural network

[0128] Input Intention Current system system response is slow 1 (fault handling) Help me query CPU information 2 (data query) How to query system CPU information 3 (question and answer)

[0129] The intent recognition result obtained through the second neural network is "1 (fault handling)", which can be considered as a fault handling request. Then, the user input information "Recently, users reported that the online order system is responding very slowly" is identified as fault information.

[0130] Step two: The fault information is classified and processed using a third neural network to obtain the target fault category to which the fault information belongs.

[0131] The training data for the third neural network is shown in Table 2 below:

[0132] Table 2 shows the training data for the third neural network.

[0133]

[0134] Through processing by the third neural network, the target fault category of the fault information is obtained as "1 (database performance bottleneck)".

[0135] Step 3: Based on the target fault category "database performance bottleneck", search the fault knowledge graph and determine the fault handling graph corresponding to the target fault category "database performance bottleneck" from the fault knowledge graph.

[0136] Figure 5 This is a schematic diagram of a fault handling diagram provided in an embodiment of the present disclosure, with reference to... Figure 5 This fault handling graph is a sub-graph identified from the fault knowledge graph that corresponds to the target fault category "database performance bottleneck". It includes the node containing the target fault category "database performance bottleneck" and its sub-nodes. The "database performance bottleneck" node includes five sub-nodes: "statistics", "analysis", "repair", "verification", and "fault report". The "analysis" sub-node includes three sub-nodes: "step 1: query database ID", "step 2: check XXX data", and "step 3: check network latency".

[0137] It should be noted that, Figure 5 The text omits the sub-nodes of the four sub-nodes: "Statistics", "Repair", "Verification", and "Fault Report". In actual applications, these four sub-nodes should have sub-nodes. Here, only the "Analysis" sub-node is used as an example for illustration.

[0138] Step four: Determine the standard handling process corresponding to the target fault category "database performance bottleneck" from the fault handling standard process library. The standard handling process includes four stages: "statistical stage", "analysis stage", "repair stage", and "verification stage".

[0139] Step 5: Determine the first set of triples corresponding to the fault handling map.

[0140] The set of first triples corresponding to the fault handling graph can be retrieved from the storage area of ​​the fault knowledge graph. Figure 5 The set of first triples corresponding to the fault knowledge graph shown can be exemplified as follows:

[0141]

[0142] Step 6: Based on the standard processing flow and the first set of triples, reason about the triples corresponding to each stage to obtain the preliminary execution flow. The preliminary execution flow includes multiple stages in the standard processing flow and the triples corresponding to each stage.

[0143] Specifically, for any stage in the standard processing flow, the triples corresponding to that stage can be determined through reasoning by a first neural network (such as large models like Baichuan or ChatGPT). The descriptive information of that stage (including stage name, stage description, etc.) and the first set of triples can be input into the first neural network for semantic matching-based reasoning to obtain the triples corresponding to that stage.

[0144] In this step, to improve the accuracy of reasoning about the triples corresponding to the stage, the first cue information can be used to interact with the first neural network.

[0145] Based on the input from the reference example in the first prompt information, the format of the description information and the first set of triples for that stage can be adjusted. This adjusted description information and the first set of triples are then used as the inference input in the first prompt information, which is then input into the first neural network. Upon receiving the first prompt information, the first neural network can obtain the description information and the first set of triples for that stage from the inference input. Based on this, it performs semantic matching-based inference to obtain the triples corresponding to that stage.

[0146] The initial prompts here include a reference example, output format, input requirements, and inference input (in the example below, "My input information: [Process Information] and [Set of Triples of Fault Handling Graph]"), which can be exemplified as follows:

[0147]

[0148]

[0149]

[0150]

[0151] The resulting preliminary execution flow is a structured processing flow, represented here as an ordered array of multiple stages of the standard processing flow and the corresponding triples for each stage. The order of the array follows the same temporal sequence as the standard processing flow. An example of the preliminary execution flow is as follows:

[0152]

[0153]

[0154] Step 7: For any stage in the initial execution process, determine the steps included in that stage from the triples corresponding to that stage. Specifically, this can be achieved by iterating through the triples corresponding to that stage to obtain the steps included in that stage.

[0155] Taking the "analysis phase" mentioned above as an example, the steps included in the "analysis phase" can be obtained from the triples corresponding to the "analysis phase". For example, the value of the associated entity in the "analysis phase" can be obtained from the triples of the initial execution process, as follows:

[0156]

[0157]

[0158] Based on the values ​​of the aforementioned related entities, the steps included in the "analysis phase" can be determined as follows: Step 1, query the database ID; Step 2, check the XXX data; Step 3, check the network latency.

[0159] Step 8: Obtain system interface information. For example, you can query the names and descriptions of all registered and callable API interfaces, agent interaction interfaces, database query interfaces, etc., to obtain the system interface information.

[0160] The system interface information can be exemplified as follows:

[0161]

[0162] It should be noted that the system interface names in the above examples are for illustrative purposes only.

[0163] Step 9: For any step in the preliminary execution process, input the description information and system interface information of the step into the first neural network (such as large models like Baichuan and ChatGPT) to perform semantic matching-based reasoning to obtain the interface call tag for that step.

[0164] In this step, in order to improve the inference accuracy of the interface call markers for the step, the second prompt information can be used to interact with the first neural network.

[0165] For any step, the description information and system interface information of that step can be formatted according to the input of the reference example in the second prompt information. The formatted description information and system interface information of that step are then used as the inference input in the second prompt information, which is then input into the first neural network. After receiving the second prompt information, the first neural network can obtain the description information and system interface information of that step from the inference input of the second prompt information, and perform semantic matching on the description information of each interface in the description information and system interface information of that step to obtain the interface call tag of that step.

[0166] In this example, the interface call of a step is marked with a first flag (e.g., true) indicating that the step has a callable system interface, or a second flag (e.g., false) indicating that the step does not have a callable system interface.

[0167] Below is an example of the second prompt message, which includes a reference example and inference input (in the example below, "My input information: [Process Data] and [System Interface Information]").

[0168]

[0169]

[0170]

[0171]

[0172] After performing semantic matching-based reasoning based on the second prompt information, the first neural network obtains the steps including the interface call marker, as described below:

[0173]

[0174] In the example above, the interface call "Step 1: Query Database ID" is marked with the first tag; the interface call "Step 2: Check XXX data" is marked with the first tag; and the interface call "Step 3: Check Network Latency" is marked with the second tag.

[0175] Then, each step in the initial execution flow is replaced with a step that includes an interface call marker, or the interface call markers of each step are written into the corresponding steps in the initial execution flow to obtain the target execution flow.

[0176] Step 10: Execute the steps in the target execution flow in sequence to obtain the fault handling result.

[0177] For any step in the target execution flow, the interface call flag of that step can be viewed first. If the interface call flag is the first flag, the description information of the step (in this example, the name of the step) and the system interface information can be input into the first neural network for semantic matching-based reasoning to obtain the target interface that the step can call. Then, the parameters of the target interface are extracted, and the call to the target interface is executed according to the extracted parameters. The call result is then determined as the execution result of the step.

[0178] In this step, to improve the efficiency and accuracy of parameter extraction from the target interface, a first neural network can be used to extract the parameters. During parameter extraction, a third prompt can be used to interact with the first neural network.

[0179] The third prompt information can be used to define the input information, output information, and format requirements when extracting parameters from the target interface using the first neural network. An example of the third prompt information is as follows:

[0180]

[0181] The extraction results of the parameters from the target interface can be exemplified as follows:

[0182] {"system interface name": "queryDbId", "parameters": null}

[0183] If the interface call is marked as the second flag indicating that the system interface cannot be called, then the information corresponding to the step is queried from the preset fault handling knowledge base. Then, through the first neural network and the fourth prompt information (i.e., the large model + prompt method), the queried information is summarized to obtain the target knowledge corresponding to the step, and then the target knowledge is determined as the execution result of the step.

[0184] The fourth prompt can be used to define the input, context information, and requirements when summarizing information through the first neural network. An example of the fourth prompt is as follows:

[0185]

[0186] The execution results of each step can be represented in a structured manner. The following example shows the execution results of each step in the "analysis phase":

[0187]

[0188]

[0189] Then, the execution results of all steps in the target execution flow are summarized in sequence to obtain the summary result. The summary result may include the stage, step name, step execution method, execution result, node information, etc. The summary result can be represented in a structured manner. An example of a summary result is shown below (the system interface names in the example are for illustrative purposes only):

[0190]

[0191]

[0192]

[0193]

[0194] It should be noted that the above summary results include stages, steps, nodes, processing methods, system interface names, results, etc. This is only an example for illustration. In practical applications, those skilled in the art can set the content included in the summary results according to the actual situation. This disclosure does not limit the specific content included in the summary results.

[0195] The above summary results can be analyzed to determine the fault handling outcome. The fault handling outcome includes whether the fault has been resolved or not.

[0196] Step 11: If the fault handling result indicates that the fault has been resolved, the fault handling result can be verified to ensure that the fault has been correctly diagnosed and repaired.

[0197] When verifying the fault handling results, a similar approach to the fault handling described above can be adopted. First, a fault verification graph corresponding to the target fault category can be determined from the fault knowledge graph; that is, the fault verification graph is a sub-graph in the fault knowledge graph used for fault verification corresponding to the target fault category. Then, a standard verification process corresponding to the target fault category can be determined from the fault handling standard process library. The standard verification process includes multiple stages of fault verification. Next, based on the fault verification graph, the standard verification process, and system interface information, the verification process can be reasoned to obtain the verification execution process. The verification execution process includes the steps of each stage in the standard verification process and the interface call markers for each step. Finally, the verification execution process is executed to obtain the verification result.

[0198] The verification result includes pass and fail. If the verification result is pass, the fault handling result is determined to be verified successfully.

[0199] Step 12: Based on the summarized results and fault handling results, generate a fault handling report. In some examples, fault handling may also include verification results. In other examples, the entire fault handling process can be summarized using large models such as ChatGPT or Baichuan to generate a fault handling report. The fault handling report is then sent to the IT administrator for review.

[0200] In Example 1 above, combining fault knowledge graphs, large models (first neural networks), and small models (second and third neural networks) for fault handling not only improves the efficiency and accuracy of fault handling and reduces system maintenance costs, but also enables rapid diagnosis and handling of system faults through natural language interaction and proactive detection.

[0201] Secondly, embodiments of this disclosure provide an electronic device, which includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements any of the fault handling methods of embodiments of this disclosure.

[0202] Figure 6 This is a schematic diagram of an electronic device provided according to an embodiment of the present disclosure. (Refer to...) Figure 6 The electronic device includes:

[0203] At least one processor 701;

[0204] The memory 702 stores at least one program, which, when executed by the at least one processor, enables the at least one processor to implement the fault handling methods provided in the above embodiments.

[0205] At least one I / O interface 703 is connected between the processor and the memory and configured to enable information exchange between the processor and the memory.

[0206] The processor 701 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 702 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 703 is connected between the processor 701 and the memory 702, enabling information exchange between the processor 701 and the memory 702, including but not limited to a data bus (Bus).

[0207] In some embodiments, the processor 701, memory 702, and I / O interface 703 are interconnected via a bus, and thus connected to other components of the computing device.

[0208] Thirdly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the fault handling methods provided in the above embodiments.

[0209] Fourthly, this disclosure provides a computer program product comprising a computer program that, when executed by a processor, implements the fault handling methods provided in the various embodiments.

[0210] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0211] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0212] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; read-only optical disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cartridges, magnetic tapes, disk storage or other magnetic storage; and any other media that can be used to store desired information and can be accessed by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0213] This disclosure has disclosed exemplary embodiments, and although specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A fault processing method comprising: classifying fault information to obtain a target fault category to which the fault information belongs; determining, according to a fault knowledge graph and a fault processing standard process library, a fault processing graph corresponding to the target fault category and a standard processing process, the standard processing process comprising multiple stages of fault processing; reasoning, according to the fault processing graph, the standard processing process and system interface information, a target execution process corresponding to the fault information, the target execution process comprising steps of each stage in the standard processing process and interface call markers of each step, for obtaining a fault processing result, the interface call markers being used to indicate callable system interfaces corresponding to different steps.

2. The method of claim 1, wherein, The fault knowledge graph is stored in a triple manner, and the reasoning, according to the fault processing graph, the standard processing process and system interface information, of a fault processing process to obtain a target execution process corresponding to the fault information comprises: determining a first triple set corresponding to the fault processing graph; reasoning, according to the standard processing process and the first triple set, of a triple corresponding to a stage to obtain a preliminary execution process, the preliminary execution process comprising multiple stages in the standard processing process and triples corresponding to each stage; reasoning, according to the preliminary execution process and the system interface information, of steps included in a stage and interface call markers of each step to obtain a target execution process corresponding to the fault information.

3. The method of claim 2, wherein, The reasoning, according to the standard processing process and the first triple set, of a triple corresponding to a stage to obtain a preliminary execution process comprises: for any stage in the standard processing process, inputting description information of the stage and the first triple set into a first neural network for reasoning based on semantic matching to obtain a triple corresponding to the stage.

4. The method of claim 2, wherein, The reasoning, according to the preliminary execution process and the system interface information, of steps included in a stage and interface call markers of each step to obtain a target execution process corresponding to the fault information comprises: for any stage in the preliminary execution process, determining steps included in the stage from a triple corresponding to the stage; for any step, inputting description information of the step and the system interface information into a first neural network for reasoning based on semantic matching to obtain an interface call marker of the step.

5. The method of claim 1, wherein, The method further comprises: when executing the target execution process, if an interface call marker of a step in the target execution process is not empty, calling a system interface indicated by the interface call marker of the step and determining a calling result as an execution result of the step.

6. The method of claim 1, wherein, The method further comprises: when executing the target execution process, if an interface call marker of a step in the target execution process is empty, determining, from a preset fault processing knowledge base, target knowledge corresponding to the step; determining the target knowledge as an execution result of the step.

7. The method of claim 1, wherein, The method further comprises: In a case where the fault processing result is that the fault has been solved, according to the fault knowledge graph and the fault processing standard process library, a fault verification graph corresponding to the target fault category and a standard verification process are determined respectively; According to the fault verification graph, the standard verification process and the system interface information, a verification process is inferred to obtain a verification execution process; In a case where an execution result of the verification execution process is passed, it is determined that the fault processing result is verified to be passed. 8.An electronic device, comprising a memory and a processor, wherein the memory stores a computer program capable of being executed by the processor, and the computer program is executed by the processor to implement the fault processing method in any one of claims 1 to 7. 9.A computer readable medium, wherein a computer program is stored on the computer readable medium, and the computer program is executed by a processor to implement the fault processing method in any one of claims 1 to 7. 10.A computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the fault processing method in any one of claims 1 to 7.

Images