Fault reason analysis method for electric power informatization system

Abstract

The invention relates to an electric power informatization system fault cause analysis method, which comprises the following steps: step 1, in an offline stage, constructing a fault analysis decision tree according to an electric power business system document and knowledge and experience of operation and maintenance personnel, and registering various API tools required to be used in a diagnosis process; 2, in an online stage, generating a fault description according to a fault occurring in the system, then matching the fault analysis decision tree in the step 1 according to a keyword in the fault description, traversing the fault analysis decision tree by a control program, and performing fault analysis on the fault analysis decision tree; and combining the fault description, the execution decision of the nodes in the tree, the callable API tool and the historical fault information into a cue word template, and sending the cue word template to the large model, so that the large model analyzes the root cause of the system fault. According to the invention, the troubleshooting and positioning efficiency of the system can be improved.

Description

Technical Field

[0001] The invention belongs to the technical field of power information system operation and maintenance, and relates to a fault cause analysis method, in particular to a fault cause analysis method for a power information system. Background Art

[0002] I6000 is the core support system for the information and communication operation and maintenance of the State Grid. The platform is an integrated information and communication dispatching and operation support platform that integrates "dispatching, operation, maintenance, customer service, and three lines", which can greatly improve the State Grid's power information and communication operation guarantee capabilities, information and communication business sharing and integration capabilities, and information and communication quality service capabilities. The system has the following characteristics: 1. Full life cycle management: The State Grid i6000 system can manage the entire life cycle of information equipment, including equipment procurement, warehousing, maintenance, scrapping and other links, to achieve comprehensive management of equipment information; 2. Automated operation and maintenance: The State Grid i6000 system can realize functions such as automated inspection and automatic deployment, reduce manual intervention, and improve operation and maintenance efficiency; 3. Real-time monitoring: The State Grid i6000 system can monitor the operating status of the information system in real time, discover problems in a timely manner and handle them, and ensure the stable operation of the information system; 4. Data analysis: The State Grid i6000 system can analyze the information equipment and system operation data, provide data support, and provide a basis for decision-making.

[0003] As the complexity of power information systems continues to increase, the need for efficient and effective management of these systems is also growing. This is when AIOps (artificial intelligence operation and maintenance) becomes particularly important - it applies artificial intelligence (AI) and machine learning (ML) to the field of IT operation and maintenance. AIOps can automate many IT processes and provide faster and more accurate insights into indicators such as system performance and security. In AIOps, root cause analysis is a key link, which is essential to find the root cause of IT problems.

[0004] Root cause analysis is a method used to identify the root causes of problems in IT operations. This process usually includes a series of steps with the goal of tracing the problem back to its source. Although this method is an important part of IT operations, traditional root cause analysis methods are often time-consuming and prone to errors.

[0005] A major problem with traditional methods is that they require a lot of manual work. Analysts need to collect data, analyze it, and find the root cause of the problem, which can take hours or even days. This manual process is not only time-consuming, but also prone to errors because analysts may miss key data or make wrong inferences.

[0006] In addition, traditional root cause analysis methods can have difficulty identifying the root cause of complex problems. In situations where multiple problems are interrelated, it is difficult to accurately identify the root cause without a comprehensive understanding of the system.

[0007] Therefore, without solving the above-mentioned problem, the present invention proposes a method for analyzing the cause of faults in a power information system.

[0008] After searching, no public documents of the prior art identical or similar to the present invention were found. Summary of the invention

[0009] The purpose of the present invention is to overcome the deficiencies of the prior art and to provide a method for analyzing the causes of faults in an electric power information system, which can improve the efficiency of troubleshooting and locating system faults.

[0010] The present invention solves the practical problem by adopting the following technical solutions:

[0011] A method for analyzing the cause of a power information system failure comprises the following steps:

[0012] Step 1: In the offline phase, build a fault analysis decision tree based on the power business system documents and the knowledge and experience of the operation and maintenance personnel, and register various API tools needed in the diagnosis process;

[0013] Step 2: In the online stage, a fault description is generated based on the fault that occurred in the system. Then, the fault analysis decision tree in step 1 is matched based on the keywords in the fault description. The control program then traverses the fault analysis decision tree and combines the fault description, the execution decision of the nodes in the tree, the callable API tool, and the historical fault information into a prompt word template and sends it to the large model, allowing the large model to analyze the root cause of the system failure.

[0014] Moreover, the specific steps of step 1 include:

[0015] (1) In the offline phase, we first need to collect the power business system documents, which include failure cases in various fields and corresponding solutions;

[0016] (2) Build a fault analysis decision tree based on the documentation and be able to call the API tool of the system interface during the registration diagnosis process.

[0017] Moreover, the specific steps of constructing the fault analysis decision tree in step (2) of step 1 include:

[0018] ①Preset a fault classification set: {CPU fault handling process, I / O fault handling process}

[0019] ②Traverse the collection and use the keyword matching algorithm to retrieve relevant faults and solutions in the documents;

[0020] ③Summarize fault solutions and generate a fault analysis decision tree.

[0021] Furthermore, the specific method of the API tool that can call the system interface during the registration diagnosis process in step 1 (2) is:

[0022] Dynamically register API tools so that the big model can obtain power business system parameters through the API interface; in addition, the association relationship between the API tool and the decision tree nodes should be established;

[0023] The step of establishing an association relationship between a decision tree node and an API tool includes:

[0024] ①Add function labels to each API tool;

[0025] ②Mark the required function labels in the decision tree nodes where the parameters need to be called;

[0026] ③ When accessing a decision tree node that requires calling parameters, the system matches the labels and provides the API tool interface that needs to be called to the large model.

[0027] Moreover, the specific steps of step 2 include:

[0028] (1) In the online analysis phase, a prompt word template is first generated to guide the large model to analyze the fault;

[0029] (2) After the prompt word template is generated, the root cause analysis algorithm based on tree search or the multi-model collaborative analysis algorithm will be selected according to the number of fields involved in the fault, and finally the root cause description will be obtained.

[0030] Moreover, the prompt word template generated in step (1) of step 2 includes: fault description, fault analysis decision, available tool set and historical fault information; wherein the fault description is generated by the system monitoring tool, the fault analysis decision is obtained by the control program traversing the fault analysis decision tree, the available tool set is accessed by the label in the node, and the historical fault information is obtained by keyword retrieval in the fault description.

[0031] Moreover, the specific steps of step (2) of step 2 include:

[0032] ① When a single domain is abnormal, a root cause analysis method based on tree search is used to obtain the root cause description;

[0033] The specific steps include:

[0034] 1) Call the large model to analyze the fault:

[0035] After the prompt word template is input into the big model, the big model will analyze the fault according to the content in the decision tree and its own knowledge; if the node content includes obtaining the specified parameter and the normal threshold value of the parameter, this step will first instruct the big model to call the corresponding system API to obtain the required parameters, and then analyze the fault based on the parameter results, the content in the decision tree and its own knowledge.

[0036] 2) Result determination and path selection:

[0037] The next decision is selected based on the node execution result; if a node is not a leaf node when the fault judgment condition in the decision node is met, the next node needs to be traversed; if the next node is a leaf node, it means that the root cause is found, and the leaf node information is read to output a root cause analysis report; if the judgment condition is not met, it means that the fault is not in the current path, and another decision path is executed.

[0038] 3) Other situations:

[0039] When all nodes in the preset fault diagnosis decision tree have been visited and the root cause of the fault has not been found, the large model will use prompt words to summarize the completed diagnostic paths and excluded possibilities. It will then perform autonomous reasoning analysis based on its pre-trained knowledge base and the collected system status data to ultimately generate the root cause of the fault.

[0040] ② When there are anomalies in multiple fields, a multi-model collaborative analysis algorithm is used to obtain the root cause description;

[0041] The specific steps include:

[0042] 1) Fault analysis decision tree allocation: Match the fault domain according to the fault description, and then allocate a large model to each domain. When the fault description involves the coupling problem of CPU usage fault and I / O waiting time being too high, two large models will be called, and the CPU domain fault handling process decision tree and related API tools will be used in the prompt word template of the first model, and the I / O domain fault handling process decision tree and related API tools will be used in the prompt word template of the second model;

[0043] 2) Execute diagnosis: execute the root cause analysis algorithm based on decision tree guidance respectively;

[0044] 3) Result merging: Merge the analysis results of multiple models and finally generate a root cause analysis report.

[0045] Advantages and beneficial effects of the present invention:

[0046] 1. The present invention proposes a method for analyzing the cause of power information system failure, which can quickly and accurately find the cause of the store information system failure, thereby improving the operational reliability of the power information system and laying the foundation for subsequent fault resolution. This technology can assist in realizing the automated operation and maintenance of the power information system, improve the work efficiency and quality of operation and maintenance personnel and managers, and provide intelligent operation and maintenance decision support and assistance.

[0047] 2. The present invention proposes a method for analyzing the root causes of power information system failures to improve the efficiency of system fault detection and location.

[0048] 3. The present invention applies the powerful understanding and reasoning capabilities of large models to the field of fault analysis of power information systems.

[0049] 4. The present invention improves the operation and maintenance level of the power information system and the work efficiency and quality of operation and maintenance personnel and managers through automated and intelligent fault cause analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 is a root cause analysis flow chart of the present invention;

[0051] Figure 2 It is a schematic diagram of a fault analysis decision tree of the present invention;

[0052] Figure 3 It is a flow chart of the online analysis phase of the present invention;

[0053] Figure 4 It is a composition diagram of the prompt word template of the present invention. DETAILED DESCRIPTION

[0054] The embodiments of the present invention are further described in detail below with reference to the accompanying drawings:

[0055] A method for analyzing the causes of faults in a power information system, such as Figure 1 As shown, the following steps are included:

[0056] Step 1: In the offline phase, build a fault analysis decision tree based on the power business system documents and the knowledge and experience of the operation and maintenance personnel, and register various API tools needed in the diagnosis process;

[0057] The specific steps of step 1 include:

[0058] (1) In the offline phase, we first need to collect the power business system documents, which include failure cases in various fields and corresponding solutions;

[0059] (2) Build a fault analysis decision tree based on the documentation and register the API tools that can call the system interface during the diagnosis process.

[0060] The specific steps of constructing the fault analysis decision tree in step (2) of step 1 include:

[0061] ①Preset a fault classification set: {CPU fault handling process, I / O fault handling process}

[0062] ②Traverse the collection and use the keyword matching algorithm to retrieve relevant faults and solutions in the documents;

[0063] ③Summarize fault solutions and generate a fault analysis decision tree.

[0064] The specific method of the API tool that can call the system interface during the registration diagnosis process in step (2) of step 1 is:

[0065] Dynamically register API tools so that the big model can obtain power business system parameters through the API interface; in addition, the association relationship between the API tool and the decision tree nodes should be established;

[0066] The step of establishing an association relationship between a node and an API tool includes:

[0067] ①Add function labels to each API tool;

[0068] ②Mark the required function labels in the decision tree nodes where the parameters need to be called;

[0069] ③ When accessing a decision tree node that requires calling parameters, the system matches the labels and provides the API tool interface that needs to be called to the large model.

[0070] In this embodiment, the working principle of step 1 is:

[0071] 1.1 Offline preparation phase

[0072] Specifically, the work content of the offline preparation phase is as follows: To generate a fault analysis decision tree, it is necessary to first collect the power business system documents. The documents contain fault cases in various fields and corresponding solutions. Then it is necessary to build a fault analysis decision tree based on the documents and register an API tool that can call the system interface. This will enhance the ability of the large model to analyze faults in the online analysis phase.

[0073] 1.1.1 Building a fault analysis decision tree

[0074] Fault analysis decision trees can provide structured decision paths for large models, effectively converge the exploration space of large models through preset logical branches, and significantly improve reasoning efficiency. Especially in specific tasks such as fault diagnosis and root cause analysis, the introduction of decision trees can help models locate the core of the problem more quickly and accurately, thereby achieving a dual improvement in analysis efficiency and accuracy.

[0075] The steps to construct a fault analysis decision tree are:

[0076] 1. Preset a fault classification set: {CPU fault handling process, I / O fault handling process, etc.}; 2. Traverse the set and use keyword matching algorithms (such as BM25 algorithm) to retrieve relevant faults and solutions in the document; 3. Summarize the fault solutions and generate a fault analysis decision tree. Among them, the decision actions in the solution constitute the non-leaf nodes of the tree, such as calling the system API interface to obtain a certain indicator parameter and judging whether the parameter exceeds the normal threshold; the root cause description of the fault in the solution constitutes the leaf node of the tree. The sample fault analysis decision tree is as follows: Figure 2 As shown in Figure 1. The constructed fault analysis decision tree is used to provide execution decisions for the large model in the online analysis phase. According to the control program, a node in the tree is visited each time as part of the prompt word template.

[0077] 1.1.2 Registration API Tool

[0078] Since the non-leaf nodes of the decision tree may need to obtain system parameter information by calling the power business system API for fault diagnosis. Therefore, the API tool is dynamically registered so that the large model can obtain the power business system parameters through the API interface; in addition, the association relationship between the API tool and the decision tree node should be established. The steps to establish the association relationship between the node and the API tool are as follows: (1) Add a function label to each API tool, such as "XX parameter query", "XX status check", etc. (2) Mark the required function label in the decision tree node that needs to call the parameter. (3) When accessing the decision tree node that needs to call the parameter, the system provides the API tool interface that needs to be called to the large model based on the label matching.

[0079] Step 2: In the online stage, a fault description is generated based on the fault that occurred in the system. Then, the fault analysis decision tree in step 1 is matched based on the keywords in the fault description. The control program then traverses the fault analysis decision tree and combines the fault description, the execution decision of the nodes in the tree, the callable API tool, and the historical fault information into a prompt word template and sends it to the large model, allowing the large model to analyze the root cause of the system failure.

[0080] The specific steps of step 2 include:

[0081] (3) In the online analysis phase, a prompt word template is first generated to guide the large model to analyze the fault;

[0082] The prompt word template generated in step (1) of step 2 includes: fault description, fault analysis decision, available tool set and historical fault information; wherein the fault description is generated by the system monitoring tool, the fault analysis decision is obtained by the control program traversing the fault analysis decision tree, the available tool set is accessed by the label in the node, and the historical fault information is obtained by keyword retrieval in the fault description.

[0083] (4) After the prompt word template is generated, the root cause analysis algorithm based on tree search or the multi-model collaborative analysis algorithm will be selected according to the number of fields involved in the fault, and finally the root cause description will be obtained.

[0084] The specific steps of step (2) of step 2 include:

[0085] ① When a single domain is abnormal, a root cause analysis method based on tree search is used to obtain the root cause description;

[0086] The specific steps include:

[0087] 1) Call the large model to analyze the fault:

[0088] After the prompt word template is input into the big model, the big model will analyze the fault according to the content in the decision tree and its own knowledge; if the node content includes obtaining the specified parameter and the normal threshold value of the parameter, this step will first instruct the big model to call the corresponding system API to obtain the required parameters, and then analyze the fault based on the parameter results, the content in the decision tree and its own knowledge.

[0089] 2) Result determination and path selection:

[0090] The next decision is selected based on the node execution result; if a node is not a leaf node when the fault judgment condition in the decision node is met, the next node needs to be traversed; if the next node is a leaf node, it means that the root cause is found, and the leaf node information is read to output a root cause analysis report; if the judgment condition is not met, it means that the fault is not in the current path, and another decision path is executed.

[0091] 3) Other situations:

[0092] When all nodes in the preset fault diagnosis decision tree have been visited and the root cause of the fault has not been found, the large model will use prompt words to summarize the completed diagnostic paths and excluded possibilities. It will then perform autonomous reasoning analysis based on its pre-trained knowledge base and the collected system status data to ultimately generate the root cause of the fault.

[0093] ② When there are anomalies in multiple fields, a multi-model collaborative analysis algorithm is used to obtain the root cause description;

[0094] The specific steps include:

[0095] 1) Fault analysis decision tree allocation: Match the fault domain according to the fault description, and then allocate a large model to each domain. For example, if the fault description involves the coupling problem of CPU usage fault and I / O waiting time being too high, two large models will be called, and the CPU domain fault handling process decision tree and related API tools will be used in the prompt word template of the first model, and the I / O domain fault handling process decision tree and related API tools will be used in the prompt word template of the second model;

[0096] 2) Execute diagnosis: execute the root cause analysis algorithm based on decision tree guidance respectively;

[0097] 3) Result merging: Merge the analysis results of multiple models and finally generate a root cause analysis report.

[0098] The working principle of step 2 is:

[0099] 1.2 Online analysis phase

[0100] In the online analysis phase, we first need to generate a prompt word template to guide the large model to analyze the fault. After the prompt word template is generated, we will choose to execute the root cause analysis algorithm based on tree search or the multi-model collaborative analysis algorithm according to the number of fields involved in the fault. Finally, we get the root cause description. The complete process is as follows Figure 3 shown.

[0101] 1.2.1 Prompt word generation

[0102] The prompt word generation step mainly constructs a prompt word template, which can be used to interact with the large model later. Figure 4 As shown, the prompt word template needs to include four parts.

[0103] (1) Fault description: This part includes the fault alarm triggered by the power information system, the occurrence time of the fault, the fault summary, the severity level of the fault (e.g., warning or critical), and additional characteristics (e.g., the fault status, which can be indicated as "resolved").

[0104] (2) Fault analysis decision: The non-leaf nodes in the decision tree store each decision step in the actual case, including interface parameter acquisition and threshold interval. When the parameter exceeds the preset threshold, the processing logic is divided into two cases: if the fault can be determined by a single parameter, the root cause report is directly output; if the fault requires a comprehensive judgment of multiple parameters, it is marked as a potential fault and the relevant parameter information of the lower-level nodes is checked. When the parameter does not exceed the threshold, it indicates that the current path has not found the fault and it is necessary to turn to other decision paths to continue searching. The leaf node of the decision tree represents the end point of the root cause of the fault and stores the corresponding root cause description and solution.

[0105] (3) Available tools: Tools refer specifically to a series of standardized API interfaces for system monitoring and diagnosis, including but not limited to system resource monitoring tools (such as query interfaces for CPU usage, memory utilization, disk I / O, etc.). By introducing these API tools into the prompt word template, the following two key goals can be achieved: first, significantly enhance the fault judgment ability of the large model, so that it can autonomously identify the type of indicators that need to be obtained during the reasoning process, accurately call the corresponding interface to obtain the real-time monitoring data of the power business system, and combine the preset thresholds and historical trends to make more reliable fault judgments; second, improve the interpretability of the model reasoning process, because each judgment can be traced back to specific indicator data support. This tool enhancement method not only improves the accuracy of fault detection, but also provides a reliable data basis for subsequent root cause analysis.

[0106] (4) Historical analysis information: Historical analysis information includes all faults that have occurred in a certain period of time, that is, the corresponding root cause analysis report. Integrating this information into the prompt word template can enable the large model to efficiently locate similar faults and obtain root cause analysis.

[0107] 1.2.2 Fault Cause Analysis Process Based on Tree Search

[0108] The motivation of this algorithm is that the training data of large language models mainly comes from a large amount of unlabeled text corpus. This feature requires the model to explore and reason in a huge parameter space when answering specific questions. In the absence of a clear problem-solving framework, large models may have problems with low answer efficiency and generate lengthy or off-topic content. The root cause location process is usually a series of ordered operations. For example, if the CPU utilization in the business system is too high at a certain moment, you can (1) check the log, which may record specific error or warning information; (2) call the database performance analysis tool to find the SQL with a long execution time, and then analyze the SQL query. This series of ordered operations can be abstracted into a structured decision path, namely the fault analysis decision tree. By traversing the tree to guide the reasoning process of the large model, complex problems can be decomposed into a series of specific judgment steps, which can not only improve the efficiency and accuracy of the model's answer, but also increase the transparency and explainability of the reasoning process. Therefore, we introduced the fault analysis decision tree to efficiently guide the large model to perform root cause location.

[0109] The idea of ​​this algorithm is to use the pre-order traversal algorithm of the tree to access the fault analysis decision tree, and effectively guide the reasoning process of the large model through a structured analysis path. The nodes of the decision tree contain specific analysis ideas (for example, obtaining XX indicator parameters and judging whether the parameters exceed the threshold), which can significantly compress the search space of the large model and improve the calculation efficiency while ensuring the accuracy of the analysis.

[0110] The pseudo code of the root cause analysis algorithm based on decision tree guidance is as follows:

[0111] Algorithm 1: Root cause analysis algorithm based on decision tree guidance Input: anomaly description D, anomaly analysis decision tree T, available API set I, historical information H Output: anomaly root cause R

[0112]

[0113] The specific execution process of the algorithm is divided into the following three key steps:

[0114] 1) Prompt word template generation:

[0115] The prompt word template consists of fault description, fault analysis decision, available tools, and historical fault information. Among them, the fault description is generated by the system monitoring tool, the fault analysis decision is obtained by the control program traversing the fault analysis decision tree, the available tools are accessed by the labels in the nodes, and the historical fault information is retrieved by the keywords in the fault description.

[0116] For example: In the CPU usage failure scenario, the monitoring tool will first generate a "CPU usage is too high" fault description, which contains the keyword "CPU". Then the fault analysis decision tree will be matched according to the keyword. In this example, the CPU fault handling process subtree will be matched. The tree will then be traversed through the control program. In this example, the leftmost node of the CPU fault handling process subtree will be entered first. This node needs to obtain the current process list of the system to analyze whether a certain process occupies a large amount of CPU resources. Because indicators need to be obtained in node decision-making, the process list API interface needs to be added to the prompt word template. In addition, the keyword "CPU" will be used to match related historical fault information and add it to the prompt word template to assist the large model in analyzing faults.

[0117] 2) Call the large model to analyze the fault:

[0118] After the prompt word template is input into the big model, the big model will analyze the fault according to the content in the decision and its own knowledge. If the node content includes obtaining the specified parameter and the normal threshold of the parameter, this step will first make the big model call the corresponding system API to obtain the required parameters, and then analyze the fault based on the parameter results, the content in the decision and its own knowledge.

[0119] For example, if the fault description is that the CPU utilization is too high at a certain moment, and the decision content is to check the process list, you need to call the current process list API interface, filter out the process list with CPU utilization exceeding 80%, and then analyze the resource usage trend and behavior characteristics of these processes.

[0120] 3) Result determination and path selection:

[0121] The next decision is selected based on the node execution result. If a node is not a leaf node under the fault judgment condition in the decision node, the next node needs to be traversed; if the next node is a leaf node, it means that the root cause is found, and the leaf node information is read to output the root cause analysis report. If the judgment condition is not met, it means that the fault is not in the current path, and another decision path is executed.

[0122] For example, if a process's CPU utilization rate exceeds 90% continuously, it occupies a large amount of system resources and is unresponsive, then the process is judged to be faulty (root cause analysis completed) and needs to be restarted to resolve the fault (solution). If no process with a CPU utilization rate exceeding 80% is found, then it is judged that the process is not the cause of the fault and other paths are executed.

[0123] 4) Other cases: When the nodes in the preset fault diagnosis decision tree have been visited and the root cause of the fault has not been found, the large model will use prompt words to summarize the completed diagnostic paths and the possibilities that have been eliminated, and then perform autonomous reasoning analysis based on its pre-trained knowledge base and the collected system status data. Finally, the root cause R of the fault is generated.

[0124] 1.2.3 Complex fault multi-model collaborative analysis process

[0125] Due to the limitations of knowledge in a single large model, there are some difficulties in solving complex faults with multiple root causes. For example, the analysis ideas are limited to a limited number of causes, making it difficult to analyze other causes. Therefore, multiple large models can be used to combine the fault analysis decision trees in their respective fields, execute the root cause analysis algorithm guided by the decision tree, and finally integrate the results through the large model to achieve more comprehensive, accurate and efficient root cause location.

[0126] The pseudo code of the multi-model collaborative analysis algorithm is as follows:

[0127] Algorithm 2 Multi-model collaborative analysis algorithm

[0128] Input: anomaly description D, anomaly analysis decision tree T, available API set I, historical information H

[0129] Output: Abnormal root cause R

[0130]

[0131] The steps of the multi-model collaborative root cause analysis algorithm are as follows:

[0132] 1) Fault analysis decision tree allocation: Match the fault domain according to the fault description, and then allocate a large model to each domain. For example, if the fault description involves the coupling problem of CPU usage fault and I / O waiting time being too high, two large models will be called, and the CPU domain fault handling process decision tree and related API tools will be used in the prompt word template of the first model, and the I / O domain fault handling process decision tree and related API tools will be used in the prompt word template of the second model.

[0133] 2) Execute diagnosis: execute the root cause analysis algorithm guided by decision tree respectively, the content is the same as above.

[0134] 3) Result merging: Merge the analysis results of multiple models and finally generate a root cause analysis report to ensure that the analysis results retain the professional insights of each professional model and reflect the correlation and systematic nature of cross-domain failures.

[0135] Example 1

[0136] 1.3.1 Fault Discovery

[0137] When the system triggers a fault monitoring threshold, for example, if the CPU usage continues to exceed the preset threshold of 85%, the fault monitoring module will automatically generate a fault description record containing the fault type, occurrence timestamp and severity, and mark it as a "critical fault to be resolved."

[0138] 1.3.2 Fault Analysis Decision Tree Matching

[0139] Subsequently, based on the fault description content, the system retrieves and extracts the corresponding CPU fault diagnosis decision tree from the preset fault analysis decision tree library through an accurate text similarity matching algorithm (such as the BM25 algorithm).

[0140] 1.3.3 Prompt word template generation

[0141] The system will integrate the decision tree into the prompt word template and call the system API interfaces related to CPU performance monitoring (such as the API for obtaining the CPU occupancy rate of the process, the API for obtaining the system resource usage, the API for obtaining the historical data of CPU load, etc.). These API interfaces enable the large model to obtain system operating parameters in real time, and combine historical fault analysis cases to form a complete analysis prompt word template. After obtaining the prompt word template, the system will adopt different analysis strategies according to the complexity of the fault:

[0142] 1.3.4 Fault Analysis Algorithm Selection

[0143] For single-domain faults (such as high CPU load only), the system executes a root cause analysis algorithm guided by a decision tree. This algorithm strictly follows the predefined fault analysis decision tree, evaluates the diagnostic results of each node, and drills down layer by layer until the specific root cause of the fault is located, and finally generates a structured analysis report.

[0144] For cross-domain compound faults (such as the coupling problem of high CPU load and high I / O waiting time), the system executes a multi-model collaborative analysis algorithm. Specifically, the system simultaneously calls two dedicated large model instances, responsible for CPU performance diagnosis and I / O performance analysis respectively. Each model independently executes the root cause analysis process based on its own domain decision tree. Subsequently, the analysis outputs of each model are merged to finally generate a comprehensive root cause analysis report.

[0145] The working principle of the present invention is:

[0146] The root cause analysis technology of power information system faults aims to quickly analyze and solve the faults and failures in the system, so as to ensure the efficient and stable operation of the system. However, there are many types of faults in the power information system, and some of them are caused by multiple factors, which makes the root cause analysis of the power information system very difficult. It usually requires human experts in multiple fields who understand a large number of relevant documents to jointly analyze the cause of the fault, which takes a lot of time and is costly.

[0147] In order to quickly and cost-effectively complete the root cause analysis of power information system failures, the present invention adopts a large model-based power information system failure root cause analysis method. The method is divided into two stages, namely, an offline preparation stage and an online analysis stage.

[0148] In the offline preparation phase, the main task is to build a fault analysis decision tree based on the power business system documents and the knowledge and experience of the operation and maintenance personnel, and register various API tools needed in the diagnosis process. The fault analysis decision tree can provide a decision path for the online analysis phase, help converge the exploration space of the large model, and thus accelerate the root cause analysis process. The API tool enables the large model to obtain key parameters and information of the power business system for fault judgment.

[0149] During the online analysis phase, a fault description is first generated based on the fault that occurred in the system, and then the fault analysis decision tree is matched based on the keywords in the fault description. The control program then traverses the fault analysis decision tree and combines the fault description, execution decisions of the nodes in the tree, callable API tools, and historical fault information into a prompt word template that is sent to the large model to analyze the system fault.

[0150] The AI-driven root cause analysis used in this invention is an emerging approach that uses machine learning algorithms to automate root cause analysis. By using AI, organizations can identify the root causes of problems faster and more accurately than traditional methods.

[0151] A key feature of AI-driven root cause analysis is its ability to analyze large amounts of data quickly. Machine learning algorithms can process vast amounts of data in minutes, providing analysts with insights that would be impossible to obtain through manual analysis. This increase in speed allows IT teams to quickly identify the root cause of problems and reduce the time it takes to resolve them. Another advantage is accuracy. Machine learning algorithms learn from data and continuously improve their accuracy over time. This means that as the amount of data processed by AI-driven root cause analysis increases, its effectiveness will also increase, helping IT teams to accurately identify the root cause of problems.

[0152] In addition to speed and accuracy, AI-driven root cause analysis is able to identify complex issues that may be difficult to detect using traditional methods. Machine learning algorithms are able to analyze data from multiple data sources and identify patterns and connections that are difficult for human analysts to detect. This allows organizations to identify the root causes of complex issues that may be missed by traditional methods.

[0153] AI-driven root cause analysis is similar to the traditional root cause analysis process, but with the addition of AI algorithms to automate and simplify the process. Here are the steps for AI-driven root cause analysis:

[0154] 1. Data collection: First, relevant data is collected from various sources such as logs, metrics, and events. This data is then processed and prepared for easy analysis.

[0155] 2. Data analysis: Apply machine learning algorithms to analyze the collected data to identify patterns and trends. This analysis helps to detect faults, such as traffic surges or unusual system behavior.

[0156] 3. Root Cause Identification: Once a fault is identified, the next step is to determine the root cause of the problem. AI algorithms use statistical models and machine learning techniques to find the most likely cause of the problem.

[0157] 4. Predict and act: AI-driven root cause analysis can also predict future problems by identifying patterns and trends that may lead to future problems. This enables IT teams to take preventive measures to prevent future problems from occurring.

[0158] AI algorithms are trained on historical data to learn the characteristics of normal system behavior. By identifying patterns and trends in the data, AI is able to learn to detect when failures or anomalies occur. The algorithm can then use this knowledge to identify the root cause of the problem in real time.

[0159] The quality and diversity of data is critical when training AI algorithms. To achieve accurate and effective results, AI needs access to a wide range of data that accurately reflects the behavior of the system. This means that the data must be comprehensive, consistent, and up-to-date to ensure the accuracy of AI analysis.

[0160] In summary, AI-driven root cause analysis is a key component of AI-based automated operations, which brings significant benefits to IT operations. By automating the root cause analysis process, organizations are able to increase the speed and accuracy of problem identification, reduce downtime and improve system performance.

[0161] It should be emphasized that the embodiments of the present invention are illustrative rather than restrictive. Therefore, the present invention includes but is not limited to the embodiments described in the specific implementation modes. Any other implementation modes derived by those skilled in the art based on the technical solutions of the present invention also fall within the scope of protection of the present invention.

Claims

1. A method for analyzing the cause of a fault in a power information system, characterized in that: The following steps are involved: Step 1: In the offline phase, build a fault analysis decision tree based on the power business system documents and the knowledge and experience of the operation and maintenance personnel, and register various API tools needed in the diagnosis process; Step 2: In the online stage, a fault description is generated based on the fault that occurred in the system. Then, the fault analysis decision tree in step 1 is matched based on the keywords in the fault description. The control program then traverses the fault analysis decision tree and combines the fault description, the execution decision of the nodes in the tree, the callable API tool, and the historical fault information into a prompt word template and sends it to the large model, allowing the large model to analyze the root cause of the system failure.

2. The method for analyzing the cause of a fault in a power information system according to claim 1, characterized in that: The specific steps of step 1 include: (1) In the offline phase, we first need to collect the power business system documents, which include failure cases in various fields and corresponding solutions; (2) Build a fault analysis decision tree based on the documentation and be able to call the API tool of the system interface during the registration diagnosis process.

3. A method for analyzing the cause of a power information system failure according to claim 2, characterized in that: The specific steps of constructing the fault analysis decision tree in step (2) of step 1 include: ①Preset a fault classification set: {CPU fault handling process, I / O fault handling process} ②Traverse the collection and use the keyword matching algorithm to retrieve relevant faults and solutions in the documents; ③Summarize fault solutions and generate a fault analysis decision tree.

4. The method for analyzing the cause of a power information system failure according to claim 2, characterized in that: The specific method of the API tool that can call the system interface during the registration diagnosis process in step 1 (2) is: Dynamically register API tools so that the big model can obtain power business system parameters through the API interface; in addition, the association relationship between the API tool and the decision tree nodes should be established; The step of establishing an association relationship between a decision tree node and an API tool includes: ①Add function labels to each API tool; ②Mark the required function labels in the decision tree nodes where the parameters need to be called; ③ When accessing a decision tree node that requires calling parameters, the system matches the labels and provides the API tool interface that needs to be called to the large model.

5. The method for analyzing the cause of a fault in a power information system according to claim 1, characterized in that: The specific steps of step 2 include: (1) In the online analysis phase, a prompt word template is first generated to guide the large model to analyze the fault; (2) After the prompt word template is generated, the root cause analysis algorithm based on tree search or the multi-model collaborative analysis algorithm will be selected according to the number of fields involved in the fault, and finally the root cause description will be obtained.

6. A method for analyzing the cause of a fault in a power information system according to claim 5, characterized in that: The prompt word template generated in step (1) of step 2 includes: fault description, fault analysis decision, available tool set and historical fault information; wherein the fault description is generated by the system monitoring tool, the fault analysis decision is obtained by the control program traversing the fault analysis decision tree, the available tool set is accessed by the label in the node, and the historical fault information is obtained by keyword retrieval in the fault description.

7. The method for analyzing the cause of a fault in a power information system according to claim 5, characterized in that: The specific steps of step (2) of step 2 include: ① When a single domain is abnormal, a root cause analysis method based on tree search is used to obtain the root cause description; The specific steps include: 1) Call the large model to analyze the fault: After the prompt word template is input into the big model, the big model will analyze the fault according to the content in the decision tree and its own knowledge. If the node content includes obtaining the specified parameter and the normal threshold value of the parameter, this step will first instruct the big model to call the corresponding system API to obtain the required parameter, and then analyze the fault in combination with the parameter result, the content in the decision tree and its own knowledge. 2) Result determination and path selection: The next decision is selected based on the node execution result; if a node is not a leaf node under the fault judgment condition in the decision node, the next node needs to be traversed; if the next node is a leaf node, it means the root cause is found, and the leaf node information is read to output a root cause analysis report; if the judgment condition is not met, it means that the fault is not on the current path, and another decision path is executed; 3) Other situations: When all nodes in the preset fault diagnosis decision tree have been visited and the root cause of the fault has not been found, the large model will use prompt words to summarize the completed diagnostic paths and the possibilities that have been eliminated. Then, based on its pre-trained knowledge base and the collected system status data, it will perform autonomous reasoning analysis and finally generate the root cause of the fault. ② When there are anomalies in multiple fields, a multi-model collaborative analysis algorithm is used to obtain the root cause description; The specific steps include: 1) Fault analysis decision tree allocation: Match the fault domain according to the fault description, and then allocate a large model to each domain. When the fault description involves the coupling problem of CPU usage fault and excessive I / O waiting time, two large models will be called, and the CPU domain fault handling process decision tree and related API tools will be used in the prompt word template of the first model, and the I / O domain fault handling process decision tree and related API tools will be used in the prompt word template of the second model. 2) Execute diagnosis: execute the root cause analysis algorithm based on decision tree guidance respectively; 3) Result merging: Merge the analysis results of multiple models and finally generate a root cause analysis report.

Images