Fault processing system and method, electronic equipment and storage medium

Abstract

The invention discloses a fault processing system and method, electronic equipment and a storage medium. The method comprises the following steps: a fault classification agent used for receiving fault description information of fault events and classifying the fault events based on the fault description information to obtain fault categories of the fault events; the fault diagnosis agent communicates with the fault classification agent and is used for generating a fault detection task according to the fault category and the fault description information under the condition that the fault category is a first fault category, and disassembling the fault detection task to obtain a plurality of sub-detection tasks, sending the plurality of sub-detection tasks to the corresponding fault detection agents according to the task types of the plurality of sub-detection tasks; and the plurality of fault detection agents are used for performing anomaly detection on the at least one initial software module associated with the fault event according to the plurality of sub-detection tasks to obtain a fault detection result. According to the invention, the technical problem of poor fault processing capability for the fault event in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of fault detection, and in particular to a fault processing system, method, electronic equipment and storage medium. Background Art

[0002] Due to the high complexity of the civil aviation system, the personalized configuration of business scenarios, the multivariate and multimodal characteristics of monitoring data, and the customized requirements of fault detection solutions, fault diagnosis of civil aviation passenger service systems is very challenging.

[0003] Related fault diagnosis technologies mainly rely on manual labeling and expert experience, so the diagnostic efficiency and accuracy of new faults or complex scenarios are limited, and it is difficult to conduct comprehensive analysis of multiple types of data, making it difficult to handle complex faults, which in turn leads to poor fault handling capabilities for fault events in related technologies.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present invention provide a fault handling system, method, electronic device and storage medium to at least solve the technical problem of poor fault handling capability for fault events in the related art.

[0006] According to one aspect of an embodiment of the present invention, a fault handling system is provided, comprising: a fault classification agent, which is used to receive fault description information of a fault event, and classify the fault event based on the fault description information to obtain a fault category of the fault event; a fault diagnosis agent, which communicates with the fault classification agent, and is used to generate a fault detection task according to the fault category and the fault description information when the fault category is a first fault category, and to decompose the fault detection task to obtain a plurality of sub-detection tasks, and to send the plurality of sub-detection tasks to corresponding fault detection agents according to the task types of the plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types; and a plurality of fault detection agents, which respectively communicate with the fault detection agent, and are used to perform anomaly detection on at least one initial software module associated with the fault event according to the plurality of sub-detection tasks to obtain a fault detection result.

[0007] Further, multiple sub-detection tasks include a timing indicator detection task, a call chain detection task, and a log anomaly detection task, and multiple fault detection agents include: a timing indicator anomaly detection agent, which is used to perform anomaly detection on the timing indicator of at least one initial software module within a preset time period according to the timing indicator detection task, and obtain a timing indicator fault detection result, wherein the timing indicator fault detection result is used to indicate whether there is a software module with an abnormal timing indicator in at least one initial software module, and the timing indicator is used to indicate the running data of the initial software module at different time points; a log anomaly detection agent, which is used to perform anomaly detection on the log of at least one initial software module according to the call chain detection task, and obtain a log fault detection result, wherein the log fault detection result is used to indicate whether there is a software module with an abnormal log in at least one initial software module; a call chain anomaly detection agent, which is used to perform anomaly detection on the call chain of at least one initial software module according to the log anomaly detection task, and obtain a call chain fault detection result, wherein the call chain fault detection result is used to indicate whether there is a software module with an abnormal call chain in at least one initial software module, and the call chain is used to indicate the call relationship between different programs in the initial software module.

[0008] Furthermore, the fault handling system also includes: a fault resolution module, which communicates with the fault diagnosis agent and is used to generate a first fault resolution strategy according to the second fault category and fault description information when the fault category is the second fault category, and output the first fault resolution strategy.

[0009] Furthermore, the fault handling system also includes: a first interactive feedback module, which communicates with the fault resolution module and is used to generate a second fault resolution strategy based on the first feedback information and the fault description information when receiving the first feedback information of the fault resolution strategy.

[0010] Furthermore, the fault handling system also includes: a fault interaction module, which is connected to the fault diagnosis intelligent agent, and is used to perform a fault analysis on the fault event according to the third fault category and the fault description information when the fault category is the third fault category, obtain a fault analysis result, and output the fault analysis result; a second interactive feedback module, which communicates with the fault interaction module, and is used to generate a third fault resolution strategy based on the second feedback information and the fault analysis result when the second feedback information of the fault analysis result is received.

[0011] According to another aspect of an embodiment of the present invention, a fault handling method is also provided, including: in response to receiving fault description information of a fault event, classifying the fault event based on the fault description information to obtain a fault category of the fault event; in response to the fault category being a first fault category, generating a fault detection task according to the fault category and the fault description information; disassembling the fault detection task to obtain a plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types; performing anomaly detection on at least one initial software module associated with the fault event according to the plurality of sub-detection tasks to obtain an abnormal software module, performing fault detection on the abnormal software module to obtain a fault detection result.

[0012] Furthermore, fault events are classified based on the fault description information to obtain fault categories of the fault events, including: disassembling the fault description information to obtain multiple subtasks, wherein different subtasks are used to determine related information of the fault events from different dimensions; calling task query tools corresponding to the multiple subtasks; using the task query tool to query the related information of the multiple subtasks to obtain query results of the multiple subtasks; and classifying the fault events based on the query results and at least one historical query result to obtain fault categories, wherein at least one historical query result is used to represent the query results corresponding to at least one historical fault category determined in a historical time period.

[0013] Furthermore, fault events are classified based on query results of multiple subtasks and historical query results to obtain fault categories, including: in response to the presence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity, determining that the historical fault category corresponding to the historical query result is the fault category; in response to the absence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity, inputting the query result into a fault classification agent, and using the fault classification agent to infer the query result to obtain the fault category.

[0014] According to another aspect of an embodiment of the present invention, a fault handling device is also provided, including: a classification module, used to respond to fault description information of a fault event, classify the fault event based on the fault description information, and obtain a fault category of the fault event; a generation module, used to respond to the fault category being a first fault category, and generate a fault detection task according to the fault category and the fault description information; a disassembly module, used to disassemble the fault detection task to obtain a plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types; a detection module, used to perform anomaly detection on at least one initial software module associated with the fault event according to the plurality of sub-detection tasks, obtain an abnormal software module, perform fault detection on the abnormal software module, and obtain a fault detection result.

[0015] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the above-mentioned fault handling method is executed when the program is running.

[0016] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored executable program. When the executable program runs, the device where the computer-readable storage medium is located is controlled to execute the above-mentioned fault handling method.

[0017] In an embodiment of the present invention, firstly, a fault classification agent receives fault description information of a fault event, and classifies the fault event based on the fault description information to obtain a fault category of the fault event; then, a fault diagnosis agent generates a fault detection task according to the fault category and the fault description information when the fault category is the first fault category, and decomposes the fault detection task into multiple sub-detection tasks, and then sends the multiple sub-detection tasks to the corresponding fault detection agent according to the task types of the multiple sub-detection tasks; finally, multiple fault detection agents perform abnormality detection on the initial software module to obtain a fault detection result. It is easy to notice that the present application constructs a fault processing system including a fault classification agent, a fault diagnosis agent and a fault detection agent, uses a fault classification agent to classify fault events to obtain fault categories, and then uses a fault diagnosis agent to diagnose fault events of the first fault category to generate multiple sub-detection tasks, and finally, the fault detection agent performs abnormality detection based on the initial software module corresponding to the sub-detection task to obtain a fault detection result, thereby achieving the technical purpose of efficiently processing fault events, thereby achieving the technical effect of improving the fault processing capability of the system, and thus solving the technical problem of poor fault processing capability for fault events in the related technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0019] Figure 1 is a schematic diagram of a fault handling system according to an embodiment of the present invention;

[0020] Figure 2 is a schematic diagram of an optional fault handling system according to an embodiment of the present invention;

[0021] Figure 3 is a schematic diagram of a work flow of a fault handling system according to an embodiment of the present invention;

[0022] Figure 4is a flow chart of a fault handling method according to an embodiment of the present invention;

[0023] Figure 5 is a schematic diagram of a fault handling device according to an embodiment of the present invention. DETAILED DESCRIPTION

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

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

[0026] According to an embodiment of the present invention, an embodiment of a fault handling system is provided. Figure 1 is a schematic diagram of a fault handling system according to an embodiment of the present invention. Figure 1 As shown, the fault handling system includes:

[0027] A fault classification agent is used to receive fault description information of a fault event, and classify the fault event based on the fault description information to obtain a fault category of the fault event;

[0028] a fault diagnosis agent, communicating with the fault classification agent, for generating a fault detection task according to the fault category and the fault description information when the fault category is the first fault category, and for decomposing the fault detection task to obtain a plurality of sub-detection tasks, and for sending the plurality of sub-detection tasks to corresponding fault detection agents according to the task types of the plurality of sub-detection tasks, wherein the fault detection types of different sub-detection tasks are different;

[0029] A plurality of fault detection agents communicate with the fault detection agent respectively, and are used to perform abnormality detection on at least one initial software module associated with the fault event according to a plurality of sub-detection tasks to obtain a fault detection result.

[0030] The above-mentioned fault classification agent may refer to an intelligent system for fault classification. The functions of the fault classification agent may include but are not limited to receiving fault description information, performing preliminary classification of fault events by analyzing and understanding the fault description information, etc.

[0031] The above-mentioned fault events may refer to any abnormal situation during the system operation that affects the normal operation of the system, service quality and user experience. The types of fault events may include but are not limited to system monitoring alarms, user complaints, service interruptions, performance degradation, etc. The specific fault events need to be determined based on actual conditions and are not limited here.

[0032] The above-mentioned fault description information may refer to the specific details of the fault event. The fault description information may include but is not limited to the environment, time, frequency, impact range, error code, exception log, user feedback, etc. in which the fault occurred. The specific fault description information needs to be determined according to the fault category and actual situation. It is not limited here. The fault description information can be used to enable the system to judge the nature and category of the fault based on the fault description information, thereby providing direction for subsequent processing.

[0033] The above-mentioned fault category may refer to the classification identification of the fault event. The fault category may include but is not limited to business configuration faults, common general system problem faults, and complex system faults. The specific fault category needs to be determined based on the description information of the fault event. No limitation is made here. Clarifying the fault category can be used to help the system understand the type of fault event, and then quickly locate the fault location and find a solution to the fault.

[0034] In an optional embodiment, a fault classification agent is used to receive fault description information from system monitoring or user reports, and the fault description information of the fault event is used to identify the fault and accurately classify the fault event, and classify the fault event into categories such as user business configuration fault, common general problem fault of the system, or complex system fault. This classification process improves the efficiency of fault response, reduces the blindness of operation and maintenance personnel in the early stage of fault troubleshooting, and enables the subsequent fault diagnosis and repair process to quickly focus on the essence of the fault, avoiding waste of resources.

[0035] The above-mentioned fault diagnosis agent may refer to an intelligent system responsible for fault analysis and diagnosis. The role of the fault diagnosis agent may include but is not limited to understanding complex fault scenarios, planning effective detection plans, ensuring the scientificity and efficiency of the fault diagnosis process, and can also be used to receive the fault detection results of the fault detection agent, reasonably dispatch multiple downstream fault detection agents based on the large model brain, and comprehensively evaluate the diagnosis conclusions after collecting all feedback.

[0036] The above-mentioned first fault category may refer to a complex system fault involving multiple system modules, complex interactions or deep-level software architecture problems in the fault category. The types of the first fault category may include but are not limited to complex faults including hardware, software, network, and business logic failures. The specific type needs to be determined based on the actual fault situation and is not limited here.

[0037] The above-mentioned fault detection task may refer to a specific detection instruction or target generated by the fault diagnosis agent according to the fault category and description information. The fault detection task type may include but is not limited to collecting timing indicators, analyzing log anomalies, tracing call links, confirming the scope of fault impact, etc. The specific fault detection task type needs to be determined according to the fault category, and is not limited here. The fault detection task can be used to indicate the direction and focus of fault analysis for the intelligent agent system, and to guide subsequent fault detection agents to conduct in-depth analysis of fault events.

[0038] The above-mentioned sub-detection tasks may refer to sub-tasks obtained by decomposing the fault detection task by the fault diagnosis agent. The types of sub-detection tasks may include but are not limited to timing anomaly detection, log anomaly analysis, call chain tracing, etc. Specific sub-detection tasks can be used to focus on a specific aspect of fault detection, which helps the fault diagnosis agents to work together and enable each fault diagnosis agent to focus on its own field, thereby improving the accuracy and efficiency of fault detection.

[0039] The above-mentioned fault detection agent may refer to an intelligent system specially designed to perform a certain type of sub-detection task. The types of fault detection agents may include but are not limited to timing indicator detection agents, log anomaly detection agents, and call chain detection agents. The specific fault detection agent needs to be determined based on the sub-detection task type and system design. No limitation is made here. The fault detection agent can be used to detect and analyze anomalies of different sub-detection tasks in fault events, thereby improving detection efficiency and accuracy.

[0040] The above-mentioned fault detection type may refer to the corresponding fault type that can be detected in the fault detection agent, and each fault detection agent corresponds to one fault detection type.

[0041] In an optional embodiment, after the fault classification agent determines that the fault category of the fault event is the first fault category, the fault diagnosis agent generates a fault detection task based on the fault category and fault description information, and then breaks down the fault detection task into multiple sub-detection tasks, and then inputs the multiple sub-detection tasks into fault detection agents of different fault detection types for detection according to their task types. The above process achieves efficient coordination and precise positioning of fault detection by breaking down the fault detection task into multiple sub-detection tasks and assigning them to different types of fault detection agents, which significantly improves the diagnostic capability and response speed of the civil aviation passenger service system when dealing with complex faults.

[0042] The above-mentioned initial software module may refer to a system component or service module that is preliminarily determined to be possibly associated with a fault event during fault handling. The types of initial software modules may include but are not limited to flight inquiry systems, ticket processing systems, baggage tracking systems, customer service systems, etc. The specific initial software module needs to be determined based on the specific fault event association module, which is not limited here. The role of the initial software module can be used for preliminary feature analysis based on fault events to ensure that the detection process starts from the point where problems are most likely to occur, thereby improving detection efficiency.

[0043] The above-mentioned anomaly detection may refer to the in-depth analysis process performed by the fault detection agent on a specific software module. Anomaly detection may be used to help the fault detection agent locate the specific location of the fault, determine the nature and possible causes of the fault, etc.

[0044] The above-mentioned fault detection results may refer to the specific analysis conclusions reached by the fault detection agent after completing the anomaly detection. The types of fault detection results may include but are not limited to whether the software module is abnormal, the specific manifestation of the anomaly, the possible causes of the anomaly, the scope of impact of the anomaly, etc. The specific fault detection results need to be determined based on the specific fault type and the anomaly detection situation. No limitation is made here. The fault detection results can be used to provide an important basis for fault analysis for the fault diagnosis agent, helping it to further improve the fault detection task or analyze the root cause of the fault.

[0045] In an optional embodiment, abnormal detection of different types of faults is performed through fault detection agents of multiple different fault detection types, which not only helps to quickly identify the root cause of the fault and improve the accuracy and efficiency of fault diagnosis, but also provides detailed data support for subsequent fault repair and system optimization.

[0046] In an embodiment of the present invention, firstly, a fault classification agent receives fault description information of a fault event, and classifies the fault event based on the fault description information to obtain a fault category of the fault event; then, a fault diagnosis agent generates a fault detection task according to the fault category and the fault description information when the fault category is the first fault category, and decomposes the fault detection task into multiple sub-detection tasks, and then sends the multiple sub-detection tasks to the corresponding fault detection agent according to the task types of the multiple sub-detection tasks; finally, multiple fault detection agents perform abnormality detection on the initial software module to obtain a fault detection result. It is easy to notice that the present application constructs a fault processing system including a fault classification agent, a fault diagnosis agent and a fault detection agent, uses a fault classification agent to classify fault events to obtain fault categories, and then uses a fault diagnosis agent to diagnose fault events of the first fault category to generate multiple sub-detection tasks, and finally, the fault detection agent performs abnormality detection based on the initial software module corresponding to the sub-detection task to obtain a fault detection result, thereby achieving the technical purpose of efficiently processing fault events, thereby achieving the technical effect of improving the fault processing capability of the system, and thus solving the technical problem of poor fault processing capability for fault events in the related technology.

[0047] Optionally, the multiple sub-detection tasks include a timing indicator detection task, a call chain detection task, and a log anomaly detection task, and the multiple fault detection agents include: a timing indicator anomaly detection agent, which is used to perform anomaly detection on the timing indicators of at least one initial software module within a preset time period according to the timing indicator detection task, and obtain a timing indicator fault detection result, wherein the timing indicator fault detection result is used to indicate whether there is a software module with an abnormal timing indicator in at least one initial software module, and the timing indicator is used to indicate the operation data of the initial software module at different time points; a log anomaly detection agent, which is used to perform anomaly detection on the log of at least one initial software module according to the call chain detection task, and obtain a log fault detection result, wherein the log fault detection result is used to indicate whether there is a software module with an abnormal log in at least one initial software module; a call chain anomaly detection agent, which is used to perform anomaly detection on the call chain of at least one initial software module according to the log anomaly detection task, and obtain a call chain fault detection result, wherein the call chain fault detection result is used to indicate whether there is a software module with an abnormal call chain in at least one initial software module, and the call chain is used to indicate the call relationship between different programs in the initial software module.

[0048] The above-mentioned timing indicator detection task may refer to one of the sub-detection tasks planned by the fault detection agent based on the fault diagnosis agent. The timing indicator detection task can be used to check the key performance indicators and resource usage of a specific software module within a preset time period to identify whether there are any abnormalities in the operating status. Among them, key indicators may include but are not limited to central processing unit (CPU) utilization, memory occupancy, network interface, disk interface, delay time, response time, error rate, etc. The specific key indicators need to be determined based on actual conditions and are not limited here.

[0049] The above-mentioned call chain detection task may refer to another sub-detection task planned by the fault detection agent based on the fault diagnosis agent. The call chain detection task can be used to analyze and track the calling relationship between components in the software system to detect abnormal behavior in the call chain, etc. By executing the call chain detection task, the agent can identify delays, errors, timeouts or failures in service calls, as well as abnormal calling patterns, and then determine whether the fault is related to a component or interaction link in the call chain.

[0050] The above-mentioned log anomaly detection task may refer to one of the sub-detection tasks planned by the fault detection agent based on the fault diagnosis agent. The log anomaly detection task may be used to check the log files of the software module to identify abnormal log entries or patterns, etc. By executing the log anomaly detection task, the agent can discover error messages, warnings, records of abnormal behavior, and unusual patterns or deviations in the logs, thereby quickly locating errors at the software level.

[0051] The above-mentioned timing indicator anomaly detection agent may refer to an intelligent system designed to monitor timing indicators within a preset time period and identify anomalies in operating data. The timing indicator anomaly detection agent analyzes the timing indicator data within a preset time period, looks for data points that deviate greatly from the normal operating mode, and then obtains the timing indicator fault detection results.

[0052] The preset time period may refer to a specific time period before and after the fault occurs, or a time window dynamically set according to the running characteristics of the software module and the need for fault detection.

[0053] The above-mentioned timing indicators may refer to the running status data of the software module at different time points, and the timing indicators may be used to monitor system performance and resource usage.

[0054] The above-mentioned log anomaly detection agent may refer to an intelligent system designed to detect the logs of the initial software module. The log anomaly detection agent performs in-depth analysis on the log data generated by the initial software module, identifies abnormal patterns or entries therein, and then obtains log fault detection results.

[0055] The above-mentioned call chain anomaly detection agent can refer to an intelligent system designed to detect the call chain of the initial software module. The call chain anomaly detection agent can identify any call anomaly or fault propagation path by analyzing the call relationship and interaction data between software modules, and then obtain the call chain fault detection result.

[0056] In an optional embodiment, according to the task types of multiple sub-detection tasks, they are input into different fault detection agents for detection, and the timing indicator anomaly detection agent is used to perform timing anomaly detection to obtain timing indicator fault detection results, the log anomaly detection agent is used to perform log anomaly detection to obtain log fault detection results, and the call chain anomaly detection agent is used to perform call chain anomaly detection to obtain call chain fault detection results. Through the collaborative work of the above multiple fault detection agents, the system can perform comprehensive and in-depth detection of software modules, identify and locate potential faults or anomalies, thereby improving the operation and maintenance efficiency and fault recovery capabilities of the civil aviation passenger service system.

[0057] In an optional embodiment, Figure 2 is a schematic diagram of an optional fault handling system according to an embodiment of the present invention, such as Figure 2 As shown, the system includes a fault classification agent, a fault diagnosis agent, a timing indicator anomaly detection agent, a call chain anomaly detection agent and a log anomaly monitoring agent, wherein the fault classification agent includes a memory module, a civil aviation business big model, a planning module and a tool; the fault diagnosis agent includes a memory module, a civil aviation fault diagnosis big model, a planning module and a tool; the timing indicator anomaly detection agent includes a memory module, a civil aviation timing big model, a planning module and a timing anomaly detection tool; the call chain anomaly detection agent includes a memory module, a civil aviation call chain big model, a planning module and a call chain anomaly detection tool; the log anomaly monitoring agent includes a memory module, a civil aviation log big model, a planning module and a log anomaly detection tool.

[0058] The civil aviation business big model in the fault classification agent is the brain of the fault classification agent, and has the ability to understand the intent and semantic analysis of knowledge in the civil aviation business field; the memory module is divided into long-term and short-term memory. The short-term memory includes prompt words set by the user, etc. The long-term memory includes the knowledge of the big model itself and the business requirements, product manuals, civil aviation terminology and other information of the local vector knowledge base. The tool module is the relevant tool interface required to solve the fault classification problem, such as the business configuration query interface, the online change order query interface, the user configuration query interface, etc.

[0059] The civil aviation fault diagnosis big model in the fault diagnosis agent is the brain of the fault diagnosis agent. It has the intention understanding and semantic analysis capabilities of knowledge in the field of civil aviation fault diagnosis. The memory module is divided into long-term and short-term memory. The short-term memory includes the prompt words set by the user and the contextual interaction content with the three detection agents. The long-term memory includes the knowledge of the big model itself and the historical fault diagnosis records of the vector knowledge base, operation and maintenance manuals and other information. The planning module performs task decomposition through the prompt word project, such as querying the root node of the fault, fault causal inference, confirmation of the fault impact range, confirmation of the fault impact degree, etc. The tool module is the relevant tool interface required to solve the problem of fault root cause analysis, such as software module fault knowledge graph, fault diagnosis decision tree, etc.

[0060] The time series indicator anomaly detection agent uses the civil aviation time series big model as the brain of the time series indicator anomaly detection agent, and has the ability to process and analyze the knowledge related to the time series indicators of various civil aviation systems. The memory module is divided into long-term and short-term memory. The short-term memory includes the prompt words set by the user and the context information interacting with the fault root cause analysis agent. The long-term memory includes the knowledge of the big model itself and the historical time series analysis records of each system in the vector knowledge base, historical detection methods and other information; the planning module decomposes tasks through the prompt word project, such as collecting time series indicators, confirming fault mutation points, impact time periods, time series trend changes, etc.; time series anomaly detection tools, including various time series detection algorithm tools, abnormal mutation point detection, time series trend detection, etc.

[0061] The call chain anomaly detection agent uses the civil aviation call chain big model as the brain of the call chain anomaly detection agent, and has the ability to analyze knowledge in the field of civil aviation system call chain anomaly detection. The memory module is divided into long and short-term memory. The short-term memory includes the prompt words set by the user and the context information interacting with the fault root cause analysis agent. The long-term memory includes the knowledge of the big model itself and the software system call chain topology relationship of the vector knowledge base, business topology relationship and other information; the planning module performs task decomposition through the prompt word project, such as call chain detection plan, positioning fault impact range, fault propagation path, node delay time, etc.; the call chain anomaly detection tool is the relevant tool interface required to solve the call chain detection problem, such as software module fault propagation cause and effect diagram, link tracking tool, service call tracking tool, etc.

[0062] The log anomaly monitoring agent uses the civil aviation log big model as the brain of the log anomaly monitoring agent, and has the knowledge analysis ability in the field of civil aviation system log anomaly detection. The memory module is divided into long-term and short-term memory. The short-term memory includes the prompt words set by the user and the contextual interaction content with the fault root cause analysis agent. The long-term memory includes the knowledge of the big model itself and the system log templates, log alarm history analysis, high-frequency terms of each system log and other information in the vector knowledge base; the planning module uses the prompt word project to inquire the big model for task decomposition, such as collecting logs, analyzing log anomaly patterns within a period of time, log parsing and alarm convergence, etc. The log anomaly detection tool is the relevant tool interface required to solve the log anomaly detection problem.

[0063] Optionally, the fault handling system also includes: a fault resolution module, which communicates with the fault diagnosis agent and is used to generate a first fault resolution strategy according to the second fault category and fault description information when the fault category is the second fault category, and output the first fault resolution strategy.

[0064] The above-mentioned fault resolution module may refer to a key component in the fault processing system that is responsible for generating a fault resolution strategy. The fault resolution module may be used to output the first fault resolution strategy when the fault category is the second fault category.

[0065] The second fault category mentioned above may refer to a service configuration fault, that is, a fault classification in a fault diagnosis system.

[0066] The above-mentioned first fault resolution strategy may refer to a fault handling plan generated for the second fault category. The types of the first fault resolution strategy may include but are not limited to software restart process, network configuration check and repair, database optimization suggestions, software configuration adjustment, hardware inspection and replacement, etc. The specific first fault resolution strategy needs to be determined based on the actual fault situation of the second fault category, and is not limited here. The first fault resolution strategy can be used to provide fast and accurate fault resolution guidance to help operation and maintenance personnel or automation systems take quick action to reduce the impact of faults on the system and users.

[0067] In an optional embodiment, when the fault diagnosis agent determines that the fault category is the second fault category, i.e., a business configuration fault, the fault resolution module generates and outputs the first fault resolution strategy according to the second fault category and the fault description information. In the above process, through the efficient collaboration between the fault resolution module and the fault diagnosis agent, a rapid response and effective handling of the second fault category is achieved, ensuring the stable operation of the civil aviation passenger service system, improving user experience, and reducing operation and maintenance costs and work pressure.

[0068] Optionally, the fault handling system further includes: a first interactive feedback module, communicating with the fault resolution module, and configured to generate a second fault resolution strategy based on the first feedback information and the fault description information when receiving first feedback information of the fault resolution strategy.

[0069] The above-mentioned first interactive feedback module may refer to a key component in the fault handling system, which is responsible for receiving feedback information from application operation and maintenance personnel or users after the working and fault solving module. The first interactive feedback module may be used to evaluate the effectiveness of the fault solving strategy, generate a second fault solving strategy, ensure closed-loop control of the fault handling process, and enhance the adaptability and self-optimization capability of the system.

[0070] The above-mentioned first feedback information may refer to the feedback provided by the application operation and maintenance personnel or the user after executing the fault resolution strategy. The types of the first feedback information may include but are not limited to feedback on solution results, feedback on operational difficulties, feedback on functional abnormalities, feedback on performance impacts, and feedback on resource consumption, etc. The specific first feedback information needs to be determined based on the handling method of the application operation and maintenance personnel and the actual effect of the fault resolution strategy. No limitation is made here. The first feedback information can be used to evaluate the feasibility, effectiveness and any potential problems of the fault resolution strategy, while ensuring the continuous optimization and correction of the fault handling process, improving the accuracy and efficiency of fault resolution, etc.

[0071] The above-mentioned second fault resolution strategy may refer to an optimized or adjusted fault resolution solution generated by the first interactive feedback module after receiving the first feedback information in combination with the original fault description information. The types of the second fault resolution strategy may include but are not limited to parameter adjustment strategies, function fallback strategies, operation guidance optimization, and resource management strategies, etc. The specific second fault resolution strategy needs to be determined based on actual conditions and is not limited here. The role of the second fault resolution strategy may include but is not limited to dynamically adjusting the resolution strategy, accumulating actual strategy experience for the system, performing preventive maintenance, and reducing the possibility of future faults.

[0072] In an optional embodiment, the first feedback information of the fault resolution strategy in the fault resolution module is received through the first interactive feedback module, and the second fault resolution strategy is generated based on the first feedback information and the fault description information. In the above process, the actual feedback of the application operation and maintenance personnel on the execution of the original fault resolution strategy is obtained through interactive feedback, which realizes the closed-loop optimization of the fault handling process, promotes the continuous improvement of the fault handling process and the long-term improvement of system performance, enhances the self-learning and adaptability of the system, and thus improves the operation and maintenance efficiency and user satisfaction of the civil aviation passenger service system.

[0073] Optionally, the fault handling system also includes: a fault interaction module, connected to the fault diagnosis agent, used to perform a fault analysis on the fault event according to the third fault category and the fault description information when the fault category is a third fault category, obtain a fault analysis result, and output the fault analysis result; a second interactive feedback module, communicating with the fault interaction module, used to generate a third fault resolution strategy based on the second feedback information and the fault analysis result when receiving second feedback information of the fault analysis result.

[0074] The above-mentioned fault interaction module may refer to a key component for performing fault analysis in the fault handling system. The fault interaction module may be used to analyze the fault event and obtain and output the fault analysis result when the fault category is the third fault category.

[0075] The third fault category mentioned above may refer to common general problem faults in the system among the fault categories.

[0076] The above-mentioned fault analysis results may refer to the conclusions drawn by the fault interaction module after an in-depth analysis of the third fault category. The types of fault analysis results may include but are not limited to root cause analysis reports, impact assessment reports, and fault recovery plans. The specific fault analysis results need to be determined based on the fault description information and the system processing flow, and are not limited here. The fault analysis results can be used to describe the nature of the fault event, the scope of impact, the possible root causes, and provide suggested solutions.

[0077] The above-mentioned second interactive feedback module may refer to a component in the fault handling system that is responsible for receiving second feedback information on the fault analysis results from application operation and maintenance personnel or domain experts. The types of the second interactive feedback modules may include but are not limited to expert feedback interfaces, operation and maintenance personnel feedback interfaces, and intelligent analysis feedback interfaces, etc. The specific second interactive feedback module needs to be determined based on actual conditions and is not limited here. The second interactive feedback module may be used to analyze and process the second feedback information and generate a more targeted third fault resolution strategy, etc.

[0078] The second feedback information may refer to the evaluation or suggestion information on the analysis results provided by the application operation and maintenance personnel or domain experts after receiving the fault analysis results. The second feedback information may be used to help the system adjust its strategies and optimize the use requirements of system resources.

[0079] The above-mentioned third fault resolution strategy may refer to an optimized fault resolution solution for the third fault category generated based on the fault analysis results and feedback information. The third fault resolution strategy may include but is not limited to software repair, hardware adjustment, process optimization, and comprehensive adjustment and other multi-faceted solution strategies. The specific third fault resolution strategy needs to be determined based on actual conditions and is not limited here. The third fault resolution strategy can be used to ensure that the fault is fundamentally resolved, improve the stability and reliability of the system, etc.

[0080] In an optional embodiment, when the fault diagnosis agent determines that the fault category is the third fault category, the fault interaction module performs fault analysis on the fault event to obtain and output the fault analysis result, and then the second interactive feedback module generates a third fault resolution strategy based on the fault analysis result and the corresponding second feedback information. In the above process, through the collaborative work of the fault interaction module and the second interactive feedback module, effective response to common general faults of the system is achieved, which not only improves the accuracy of fault diagnosis, but also promotes the continuous optimization of fault resolution strategies and the long-term improvement of system performance, providing more powerful technical support for system operation and maintenance.

[0081] In an optional embodiment, Figure 3 FIG. 1 is a schematic diagram of a work flow of a fault handling system according to an embodiment of the present invention. Figure 3 As shown, the fault classification agent includes a large model of civil aviation business and a memory module, and can perform task planning, tool selection and execution; the fault diagnosis agent includes a large model of civil aviation fault diagnosis and a memory module, and can perform task planning, tool selection and execution; the timing indicator anomaly detection agent includes a memory module and a large model of civil aviation timing, and can interact with the planning module and the timing anomaly detection tool; the call chain anomaly detection agent includes a memory module and a large model of civil aviation call chain, and can interact with the planning module and the call chain anomaly tool; the log anomaly detection agent includes a memory module and a large model of civil aviation log, and can interact with the planning module and the log anomaly detection tool.

[0082] The workflow of the fault handling system is as follows: first, the fault category of the fault event is classified by the fault classification agent: when the fault category is a common general problem fault in the system, it is handled by the operation and maintenance personnel; when the fault category is a business configuration fault, a fault alarm is issued, and the user enters supplementary information, and then the fault classification agent rethinks and plans the solution; when the fault category is a complex system fault, it is input into the fault diagnosis agent, and the fault diagnosis agent outputs the fault analysis results and determines whether the fault is resolved. If so, a diagnostic conclusion and a disposal plan are generated. If not, it is input into the fault diagnosis agent again for further diagnosis.

[0083] According to an embodiment of the present invention, an embodiment of a fault handling method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0084] Figure 4 is a flow chart of a fault handling method according to an embodiment of the present invention. Figure 4 As shown, the method comprises the following steps:

[0085] Step S402: in response to receiving the fault description information of the fault event, classify the fault event based on the fault description information to obtain the fault category of the fault event.

[0086] In an optional embodiment, after receiving the fault description information of the fault event, the fault event is first classified to determine the fault category of the fault event. This classification process can effectively distinguish between user business configuration faults, common system general problem faults, or complex system faults through the key features of the fault description information and the deep learning ability of the model. Through this preliminary classification, the system can quickly call the corresponding intelligent agents and tools to adopt the most appropriate diagnosis and solution process for different types of faults, greatly improving the efficiency and pertinence of fault handling.

[0087] Step S404: in response to the fault category being the first fault category, generating a fault detection task according to the fault category and the fault description information.

[0088] In an optional embodiment, when it is determined that the fault event belongs to the first fault category, that is, a complex system fault, the system responds immediately and automatically generates a highly customized fault detection task based on the fault category and detailed fault description information. This process improves the speed of solving user business configuration problems through immediate response and precise task generation, and ensures the accuracy and effectiveness of fault detection tasks.

[0089] Step S406, decomposing the fault detection task to obtain a plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types.

[0090] In an optional embodiment, after determining that the fault category is the first fault category, the system further refines the generated fault detection task and generates multiple targeted sub-detection tasks, each of which focuses on a different fault detection type, such as timing indicator anomalies, call chain anomalies, or log anomalies. This decomposition process subdivides the fault detection task into multiple sub-detection tasks, ensuring that each sub-detection task can be efficiently and accurately executed by an agent specifically responsible for that type, thereby avoiding the loss of data features and misjudgment, and improving the accuracy and speed of fault detection.

[0091] Step S408, performing anomaly detection on at least one initial software module associated with the fault event according to the multiple sub-detection tasks to obtain an abnormal software module, performing fault detection on the abnormal software module to obtain a fault detection result.

[0092] The above-mentioned abnormal software module may refer to a software module that is identified to deviate from normal behavior or expected results in terms of function, performance, data processing or system interaction. The types of abnormal software modules may include but are not limited to timing abnormal modules, call chain abnormal modules, log abnormal modules and configuration abnormal modules. The specific abnormal software module needs to be determined according to the actual abnormal situation and is not limited here. The abnormal software module can be used to locate the specific location of the fault, assess the severity of the fault, and prevent the fault.

[0093] In an optional embodiment, an abnormal software module is obtained by performing an abnormal detection on the initial software module associated with the fault event in the sub-detection task, and then a fault detection is performed on the abnormal software module to obtain a fault detection result. The above process reduces the complexity and uncertainty of manual diagnosis through automated fault detection and location, improves the accuracy of fault resolution and the overall reliability of the system, and at the same time improves the system's operation and maintenance efficiency and fault response speed, reduces business interruption time, and optimizes user experience.

[0094] Optionally, fault events are classified based on the fault description information to obtain fault categories of the fault events, including: disassembling the fault description information to obtain multiple subtasks, wherein different subtasks are used to determine related information of the fault events from different dimensions; calling task query tools corresponding to the multiple subtasks; using the task query tool to query the related information of the multiple subtasks to obtain query results of the multiple subtasks; and classifying the fault events based on the query results and at least one historical query result to obtain fault categories, wherein at least one historical query result is used to represent the query results corresponding to at least one historical fault category determined in a historical time period.

[0095] The above-mentioned related information may refer to key details in the fault description information that are directly or indirectly related to the fault event. The types of related information may include but are not limited to user configuration information, system architecture information, software module status, business scenarios, and historical change records. The specific related information needs to be determined based on the specific circumstances of the fault event and is not limited here. The related information can be used to understand and classify fault events, help intelligent agents analyze the root causes of faults from different dimensions, etc.

[0096] The above-mentioned task query tool may refer to a software tool or interface specially designed for collecting, analyzing and verifying related information. The types of task query tools may include but are not limited to business configuration query tools, system status query tools and historical record query tools. The specific task query tool needs to be determined according to actual needs and is not limited here. The task query tool can be used to extract data from all levels of the system and provide query and analysis capabilities for related information involved in the fault description information.

[0097] The above-mentioned historical query results may refer to the results obtained after querying and analyzing similar fault events within a historical time period. The historical query results may be used to assist the fault classification agent to quickly determine the fault category based on the current fault description information and compare the historical situation, thereby improving the diagnostic efficiency and accuracy.

[0098] The above-mentioned historical time period may refer to the time range for reference when classifying faults. The historical time period may include but is not limited to the most recent day, the most recent week, the most recent month, etc. The specific historical time period needs to be determined based on actual needs and is not limited here. Reasonable selection of the historical time period can ensure that the intelligent agent obtains the historical information most relevant to the current fault event, thereby making a more accurate judgment.

[0099] The above-mentioned historical fault categories may refer to categories obtained by classifying faults according to diagnosis and processing results of past fault events.

[0100] In an optional embodiment, the fault description information is disassembled to obtain multiple subtasks, and then the task query tools corresponding to the multiple subtasks are called, and then the related information in the multiple subtasks is queried through the task query tool to obtain the query results of the multiple subtasks, and finally the fault events are classified based on the query results and the historical query results to obtain the fault category. The above process, by disassembling the fault description information and calling the task query tool to collect related information, and combining the historical query results for comparative analysis, can not only quickly locate the fault type, but also improve the judgment ability of the intelligent body through the learning of historical data, provide smarter and more comprehensive support for system operation and maintenance, effectively reduce the time and cost of fault handling, and improve system stability and user experience.

[0101] Optionally, fault events are classified based on query results of multiple subtasks and historical query results to obtain fault categories, including: in response to the presence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity, determining that the historical fault category corresponding to the historical query result is the fault category; in response to the absence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity, inputting the query result into a fault classification agent, and using the fault classification agent to infer the query result to obtain the fault category.

[0102] The above-mentioned preset similarity may refer to a pre-set quantitative indicator for measuring the similarity between the query results of the current fault description information and the historical query results. The preset similarity may include but is not limited to 80%, 85%, 90%, 95%, etc. The specific preset similarity needs to be determined according to the actual situation of different faults, and is not limited here. The preset similarity can be used to quickly judge the query results, quickly locate the fault category, autonomously infer new faults, etc.

[0103] In an optional embodiment, first, based on the query results of multiple subtasks, historical fault cases that are highly similar to the current fault description are identified by calculating the similarity with the historical query results. When the similarity between the query results and the historical query results exceeds the preset similarity, the system can directly reference the fault category of the historical case; and when the similarity between the query results and the historical query results is lower than the preset threshold, it means that the current fault event may appear as a new or abnormal pattern. At this time, the system submits the query results to the fault classification agent, and the agent uses its reasoning and learning capabilities to conduct an in-depth analysis of the query results, thereby autonomously inferring the category of the current fault. This process can not only ensure the accurate diagnosis of new faults, but also continuously enrich and optimize the historical fault database through the learning and evolution of the agent, thereby improving the overall intelligent diagnosis level and fault handling capabilities of the system.

[0104] According to another aspect of an embodiment of the present invention, a fault handling device is further provided, which can execute the fault handling method of the above embodiment. The specific implementation method and preferred application scenario are the same as those of the above embodiment and will not be described in detail here.

[0105] Figure 5 is a schematic diagram of a fault handling device according to an embodiment of the present invention. Figure 5 As shown, the device includes the following: a classification module 502 , a generation module 504 , a disassembly module 506 , and a detection module 508 .

[0106] A classification module 502 is used to respond to the fault description information of the fault event, classify the fault event based on the fault description information, and obtain the fault category of the fault event; a generation module 504 is used to respond to the fault category being the first fault category, and generate a fault detection task according to the fault category and the fault description information; a disassembly module 506 is used to disassemble the fault detection task to obtain multiple sub-detection tasks, wherein different sub-detection tasks have different fault detection types; a detection module 508 is used to perform anomaly detection on at least one initial software module associated with the fault event according to the multiple sub-detection tasks, obtain an abnormal software module, perform fault detection on the abnormal software module, and obtain a fault detection result.

[0107] Optionally, the classification module includes: a disassembly unit, which is used to disassemble the fault description information to obtain multiple subtasks, wherein different subtasks are used to determine the related information of the fault event from different dimensions; a calling unit, which is used to call the task query tools corresponding to the multiple subtasks; a query unit, which is used to use the task query tool to query the related information of the multiple subtasks to obtain query results of the multiple subtasks; and a classification unit, which is used to classify the fault event based on the query results and at least one historical query result to obtain a fault category, wherein at least one historical query result is used to represent the query result corresponding to at least one historical fault category determined in a historical time period.

[0108] Optionally, the classification unit includes: a determination subunit, used to determine that the historical fault category corresponding to the historical query result is a fault category in response to the presence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity; and an inference subunit, used to input the query result into a fault classification agent in response to the absence of a historical query result in at least one historical query result whose similarity with the query result is greater than a preset similarity, and use the fault classification agent to infer the query result to obtain the fault category.

[0109] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the method in each embodiment of the present invention is executed when the program is running.

[0110] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program. When the program is executed, a processor of a device is controlled to execute the methods of various embodiments of the present invention.

[0111] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0112] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication shown or discussed can be through some interfaces, indirect coupling or communication of units or modules, which can be electrical or other forms.

[0113] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0114] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0115] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0116] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A fault handling system, characterized in that: include: A fault classification agent, used to receive fault description information of a fault event, and classify the fault event based on the fault description information to obtain a fault category of the fault event; a fault diagnosis agent, communicating with the fault classification agent, for generating a fault detection task according to the fault category and the fault description information when the fault category is the first fault category, and decomposing the fault detection task to obtain a plurality of sub-detection tasks, and sending the plurality of sub-detection tasks to corresponding fault detection agents according to the task types of the plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types; The multiple fault detection agents communicate with the fault detection agent respectively, and are used to perform abnormality detection on at least one initial software module associated with the fault event according to the multiple sub-detection tasks to obtain a fault detection result.

2. The fault handling system according to claim 1, characterized in that: The multiple sub-detection tasks include a timing indicator detection task, a call chain detection task, and a log anomaly detection task. The multiple fault detection agents include: A timing indicator anomaly detection agent, used to perform anomaly detection on the timing indicator of at least one initial software module within a preset time period according to the timing indicator detection task, and obtain a timing indicator fault detection result, wherein the timing indicator fault detection result is used to indicate whether the at least one initial software module has a software module with an abnormal timing indicator, and the timing indicator is used to indicate the operation data of the initial software module at different time points; a log anomaly detection agent, used to perform anomaly detection on the log of the at least one initial software module according to the call chain detection task, and obtain a log fault detection result, wherein the log fault detection result is used to indicate whether there is a software module in the at least one initial software module whose log has an anomaly; A call chain anomaly detection agent is used to perform anomaly detection on the call chain of the at least one initial software module according to the log anomaly detection task to obtain a call chain fault detection result, wherein the call chain fault detection result is used to indicate whether there is a software module in the at least one initial software module in which the call chain has an anomaly, and the call chain is used to indicate the calling relationship between different programs in the initial software module.

3. The fault handling system according to claim 1, characterized in that: The fault handling system further includes: The fault resolution module communicates with the fault diagnosis agent and is used to generate a first fault resolution strategy according to the second fault category and the fault description information when the fault category is the second fault category, and output the first fault resolution strategy.

4. The fault handling system according to claim 3, characterized in that: The fault handling system further includes: The first interactive feedback module communicates with the fault resolution module and is configured to generate a second fault resolution strategy based on the first feedback information and the fault description information when receiving the first feedback information of the fault resolution strategy.

5. The fault handling system according to claim 1, characterized in that: The fault handling system further includes: a fault interaction module connected to the fault diagnosis agent, and configured to, when the fault category is the third fault category, perform a fault analysis on the fault event according to the third fault category and the fault description information, obtain a fault analysis result, and output the fault analysis result; The second interactive feedback module communicates with the fault interactive module and is used to generate a third fault resolution strategy based on the second feedback information and the fault analysis result when receiving the second feedback information of the fault analysis result.

6. A fault handling method, characterized in that: include: In response to receiving fault description information of a fault event, classifying the fault event based on the fault description information to obtain a fault category of the fault event; In response to the fault category being a first fault category, generating a fault detection task according to the fault category and the fault description information; Decomposing the fault detection task to obtain a plurality of sub-detection tasks, wherein different sub-detection tasks have different fault detection types; According to the multiple sub-detection tasks, an abnormality detection is performed on at least one initial software module associated with the fault event to obtain an abnormal software module, and a fault detection is performed on the abnormal software module to obtain a fault detection result.

7. The fault handling method according to claim 6, characterized in that: Classifying the fault event based on the fault description information to obtain a fault category of the fault event includes: Decomposing the fault description information to obtain a plurality of subtasks, wherein different subtasks are used to determine the associated information of the fault event from different dimensions; Retrieving task query tools corresponding to the multiple subtasks; Using the task query tool to query the associated information of the multiple subtasks to obtain query results of the multiple subtasks; The fault event is classified based on the query result and at least one historical query result to obtain the fault category, wherein the at least one historical query result is used to represent the query result corresponding to at least one historical fault category determined in a historical time period.

8. The fault handling method according to claim 7, characterized in that: Classifying the fault event based on the query results of the multiple subtasks and the historical query results to obtain the fault category includes: In response to the existence of a historical query result in the at least one historical query result whose similarity to the query result is greater than a preset similarity, determining that the historical fault category corresponding to the historical query result is the fault category; In response to the absence of at least one historical query result having a similarity with the query result greater than the preset similarity, the query result is input into a fault classification agent, and the query result is inferred by the fault classification agent to obtain the fault category.

9. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 6 to 8 when running.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the storage medium is located is controlled to execute the method according to any one of claims 6 to 8.

Images