Method, device and equipment for handling operation and maintenance fault and storage medium

Abstract

The application discloses an operation and maintenance fault processing method and device, equipment and a storage medium, relates to the technical field of intelligent operation and maintenance, and comprises the following steps: acquiring operation index data and log data of a target system, calling a large model to perform fault reasoning on the operation index data and the log data, and generating a processing suggestion list; performing permission matching on the processing suggestions in the processing suggestion list according to a preset authorization rule to obtain a target processing suggestion; generating a to-be-confirmed work order according to the target processing suggestion, and sending the to-be-confirmed work order to an interactive terminal; receiving an interactive result returned by the interactive terminal, outputting an operation command of the target processing suggestion to an execution terminal when the interactive result is an execution instruction, and marking the to-be-confirmed work order as withdrawn when the interactive result is a rejection instruction. The application can reduce the risk of operation and maintenance operation failure caused by artificial intelligence misjudgment.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology, and in particular to a method, apparatus, equipment, and storage medium for handling operation and maintenance faults. Background Technology

[0002] As enterprise IT architectures become increasingly complex, the application of artificial intelligence (AI) in operations and maintenance (O&M) is becoming more widespread. Currently, AI models typically perform fault inference based on collected O&M data and automatically generate and execute operational instructions to achieve rapid fault repair. However, AI models are prone to inference errors or misinterpretations, and their generated handling suggestions may be inappropriate. Direct execution of these suggestions could easily expand the scope of the fault or even lead to system unavailability. Furthermore, existing O&M systems lack effective security control mechanisms for AI-generated instructions. Therefore, reducing the risk of O&M operational errors due to AI misjudgments remains a problem that needs to be addressed.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, equipment, and storage medium for handling operational and maintenance failures, aiming to solve the technical problem of how to reduce the risk of operational and maintenance errors caused by artificial intelligence misjudgments.

[0005] To achieve the above objectives, this application proposes a method for handling operational and maintenance failures, the method comprising: The system acquires operational metric data and log data of the target system, retrieves reference cases matching the operational metric data and log data from a knowledge base containing positive cases and misjudged cases, injects the positive cases into the inference context of the large model when the similarity of the positive cases in the reference cases is higher than a first threshold, and adds prompt information to the inference context when the similarity of the misjudged cases in the reference cases is higher than a second threshold. The large model is then invoked to infer the operational metric data, the log data, and the inference context to generate a list of disposal suggestions, each of which contains an operation command. According to the preset authorization rules, each disposal suggestion in the disposal suggestion list is matched for permissions, and the disposal suggestion that passes the match is determined as the target disposal suggestion; A work order to be confirmed is generated based on the target handling suggestion, and the work order to be confirmed is sent to the interactive terminal; The system receives the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

[0006] In one embodiment, the steps of retrieving reference cases matching the operational metric data and the log data from a knowledge base, wherein the knowledge base contains positive cases and misjudged cases, and injecting the positive cases into the inference context of the large model when the similarity of the positive cases in the reference cases is higher than a first threshold, and appending prompt information to the inference context when the similarity of the misjudged cases in the reference cases is higher than a second threshold, and calling the large model to infer the operational metric data, the log data, and the inference context to generate a list of disposal suggestions, wherein each disposal suggestion in the list contains an operation command, include: Retrieve reference cases that match the operational metric data and the log data from a knowledge base, which includes positive cases and false positive cases; When the similarity between the positive cases in the reference cases is higher than the first threshold, the positive cases are injected into the reasoning context of the large model. When the similarity between the misjudged cases in the reference cases is higher than the second threshold, additional prompt information is added to the reasoning context; The large model is invoked to infer the operational metric data, the log data, and the inference context to generate a list of disposal suggestions. Each disposal suggestion in the list contains an operation command.

[0007] In one embodiment, the step of performing permission matching on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and determining the disposal suggestion that passes the matching as the target disposal suggestion includes: Query the operation type of the proposed action in the preset authorization rules; When the operation type of the proposed action matches the preset authorization rule, obtain the risk level corresponding to the proposed action in the preset authorization rule; When the proposed action does not match the preset authorization rule, the risk level is determined based on the command type of the proposed action and the preset rule. Based on the risk level, determine whether the proposed action is approved, and identify the approved action as the target action.

[0008] In one embodiment, the step of sending the work order to be confirmed to the interactive terminal includes: Obtain the risk level and operational commands for the proposed target treatment; The audit path is determined based on the risk level and the operation command; The pending confirmation work order is sent to the interactive terminal based on the aforementioned review path.

[0009] In one embodiment, the step of outputting the operation command for the target treatment suggestion to the execution terminal includes: The operation commands for the proposed target handling are presented on the execution terminal; The operation channel between the execution terminal and the target system is kept in manual operation mode. The operation command is received by the execution terminal from the manual execution instruction and then transmitted to the target system for execution through the operation channel.

[0010] In one embodiment, after the step of outputting the operation command for the target treatment suggestion to the execution terminal, the method further includes: Receive the annotation results returned by the work order to be confirmed, the annotation results include root cause accuracy labels and handling success labels; Obtain the target handling suggestion and fault characteristic data corresponding to the work order to be confirmed; When both the root cause accuracy label and the treatment success label are positive, the target treatment suggestion and the fault feature data are stored in the positive case partition of the knowledge base; When the root cause accuracy label or the treatment success label is negative, the target treatment suggestion and the fault feature data are stored in the misjudgment case partition of the knowledge base.

[0011] In one embodiment, after receiving the interaction result returned by the interactive terminal, and when the interaction result is an execution instruction, outputting the operation command of the target handling suggestion to the execution terminal; and when the interaction result is a rejection instruction, marking the work order to be confirmed as withdrawn, the method further includes: The audit log of the entire process from the generation of the work order to the return of the interaction result is written in an append-only manner; The hash value of the audit log is calculated for each data block, and the hash value of the current data block is linked to the header of the next data block to form a hash chain.

[0012] Furthermore, to achieve the above objectives, this application also proposes a device for handling operational and maintenance failures, the device comprising: The module is used to obtain the target system's operational indicator data and log data, retrieve reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases, inject the positive case into the inference context of the large model when the similarity of the positive case in the reference case is higher than a first threshold, and attach a prompt message to the inference context when the similarity of the misjudged case in the reference case is higher than a second threshold. The large model is then invoked to infer the operational indicator data, the log data, and the inference context to generate a list of disposal suggestions. Each disposal suggestion in the list contains an operation command. The matching module is used to perform permission matching on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and determine the disposal suggestion that passes the matching as the target disposal suggestion; The generation module is used to generate a work order to be confirmed based on the target disposal suggestion, and send the work order to be confirmed to the interactive terminal. The output module is used to receive the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

[0013] In addition, to achieve the above objectives, this application also proposes a device for handling operational and maintenance failures, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the operational and maintenance failure handling method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the operation and maintenance fault handling method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the operation and maintenance fault handling method described above.

[0016] This application provides a method for handling operational and maintenance faults. The method involves acquiring operational indicator data and log data of a target system, retrieving reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases, injecting the positive case into the inference context of a large model when the similarity of the positive case in the reference cases exceeds a first threshold, and adding a prompt message to the inference context when the similarity of the misjudged case in the reference cases exceeds a second threshold. The large model is then invoked to infer the operational indicator data, log data, and inference context to generate a list of handling suggestions, each of which contains an operation command. Permission matching is performed on each handling suggestion in the list according to preset authorization rules, and the matching suggestions are determined as target handling suggestions. A pending confirmation work order is generated based on the target handling suggestion and sent to an interactive terminal. The interaction result returned by the interactive terminal is received; if the interaction result is an execution instruction, the operation command of the target handling suggestion is output to the execution terminal; if the interaction result is a rejection instruction, the pending confirmation work order is marked as withdrawn. This application achieves permission matching for AI-generated handling suggestions based on preset authorization rules, and generates a pending confirmation work order for the matched handling suggestions and sends it to the interactive terminal. Based on the interaction result, it decides to output the operation command or reject and withdraw it, thus realizing the legality review and manual confirmation of AI-generated instructions before execution, reducing the risk of operation and maintenance errors caused by AI misjudgment. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the method for handling operational and maintenance failures in this application (Example 1). Figure 2 A flowchart illustrating the second embodiment of the method for handling operational and maintenance failures in this application; Figure 3 A simplified flowchart illustrating the method for handling operational and maintenance faults provided in Embodiment 1 of this application; Figure 4 This is a schematic diagram of the module structure of the maintenance fault handling device according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the method for handling operation and maintenance faults in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] This application acquires the operational indicator data and log data of the target system, retrieves reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases, injects the positive case into the inference context of the large model when the similarity of the positive case in the reference case is higher than a first threshold, and adds a prompt message to the inference context when the similarity of the misjudged case in the reference case is higher than a second threshold, calls the large model to infer the operational indicator data, the log data, and the inference context, and generates a list of disposal suggestions, each of which contains an operation command; performs permission matching on each disposal suggestion in the list according to preset authorization rules, and determines the matched disposal suggestions as target disposal suggestions; generates a work order to be confirmed based on the target disposal suggestions and sends the work order to the interactive terminal; receives the interaction result returned by the interactive terminal, outputs the operation command of the target disposal suggestion to the execution terminal when the interaction result is an execution instruction, and marks the work order to be confirmed as withdrawn when the interaction result is a rejection instruction.

[0024] As enterprise IT architectures become increasingly complex, the application of artificial intelligence (AI) in operations and maintenance (O&M) is becoming more widespread. Currently, AI models typically perform fault inference based on collected O&M data and automatically generate and execute operational instructions to achieve rapid fault repair. However, AI models are prone to inference errors or misinterpretations, and their generated handling suggestions may be inappropriate. Direct execution of these suggestions could easily expand the scope of the fault or even lead to system unavailability. Furthermore, existing O&M systems lack effective security control mechanisms for AI-generated instructions. Therefore, reducing the risk of O&M operational errors due to AI misjudgments remains a problem that needs to be addressed.

[0025] This application achieves permission matching for AI-generated handling suggestions based on preset authorization rules, and generates a pending confirmation work order for the matched handling suggestions and sends it to the interactive terminal. Based on the interaction result, it decides to output the operation command or reject and withdraw it, thus realizing the legality review and manual confirmation of AI-generated instructions before execution, reducing the risk of operation and maintenance errors caused by AI misjudgment.

[0026] All user-related data involved in this application were obtained with the user's permission or consent; that is, when this application is applied to specific products or technologies, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0027] Based on this, the embodiments of this application provide a method for handling operation and maintenance faults, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for handling operational and maintenance failures in this application.

[0028] In this embodiment, the method for handling maintenance failures includes steps S10 to S40: Step S10: Obtain the target system's operational metrics data and log data; retrieve reference cases matching the operational metrics data and log data from the knowledge base, which contains positive cases and misjudged cases; when the similarity of positive cases in the reference cases is higher than a first threshold, inject the positive cases into the inference context of the large model; when the similarity of misjudged cases in the reference cases is higher than a second threshold, add prompt information to the inference context; call the large model to infer the operational metrics data, the log data, and the inference context to generate a list of disposal suggestions; each disposal suggestion in the disposal suggestion list contains an operation command. It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or maintenance fault handling device capable of performing the above functions. The following description uses a maintenance fault handling device as an example to illustrate this embodiment and the subsequent embodiments.

[0029] It should be noted that the target system refers to the information technology (IT) system in the production environment that is being monitored and protected, such as database clusters, application servers, and operating systems. Operational metrics include quantitative performance indicators such as CPU utilization, memory usage, disk I / O latency, number of active database sessions, and application thread pool status. Log data includes unstructured or semi-structured text information such as system logs, application logs, and database error logs. In the specific implementation, the collector can obtain the above-mentioned metrics and logs through native operating system interfaces and read-only database accounts. The collector does not expose any write interfaces, only outputting data streams in one direction, thus ensuring that the collection behavior will not cause any write operations or configuration changes to the target system, avoiding the introduction of additional security risks. The collector can specifically execute collection tasks according to the frequency and scope defined in the Skill file. The Skill file is stored in YAML or JSON format and loaded into the analysis engine when the service starts. The Skill file defines the collection strategy for different target system types and monitored objects, including parameters such as collection interval, collection item list, and data sampling range.

[0030] It should be noted that reference cases matching the operational metric data and log data are retrieved from the knowledge base. The knowledge base includes positive cases and misjudged cases. When the similarity of a positive case among the reference cases exceeds a first threshold, the positive case is injected into the inference context of the large model. When the similarity of a misjudged case among the reference cases exceeds a second threshold, a prompt is added to the inference context. The large model is then invoked to infer the operational metric data, log data, and inference context, generating a list of proposed actions. Each action suggestion in the list contains an operation command. The step of generating the proposed action list can be specifically executed by the analysis engine. The analysis engine receives the operational metric data and log data output by the collector and invokes the large language model on the computing resources for inference analysis. The computing resources offer three optional deployment methods: customer-provided Graphics Processing Unit (GPU) running locally; rented private cloud GPUs connected via dedicated lines; and invocation of the public cloud Application Programming Interface (API). Customers can choose one method during system initialization and switch as needed later. The large model, based on input indicator and log data, combined with pre-built fault diagnosis logic and historical cases from the knowledge base, performs root cause analysis and generates handling suggestions, ultimately outputting a list of handling suggestions. Each handling suggestion can include an operation command, an estimated risk level, and an estimated impact range.

[0031] It should be noted that a Retrieval-Augmented Generation (RAG) mechanism can be introduced when generating the list of disposal suggestions to enhance the accuracy and reliability of large model inference by retrieving historical cases.

[0032] It should be noted that the system first retrieves reference cases matching the operational metric data and log data from the knowledge base. The knowledge base includes positive cases and misjudged cases. The knowledge base is divided into three logical partitions: a positive case library, storing records confirmed as having "accurate root cause and successful handling"; a misjudged case library, storing records that failed confirmation; and a vendor knowledge base, pre-loaded with equipment manuals and error code explanations, which can be maintained by the service provider. During the RAG retrieval process, the system converts the current fault's operational metric data and log data into vectors. By calculating the similarity between the current fault's feature vector and each case vector (e.g., using a cosine similarity algorithm), the system retrieves Top-K cases similar to the current fault's features from the positive case library and the misjudged case library. Positive cases provide referable successful handling experience for the current fault, while misjudged cases serve as reminders of past erroneous judgments by the system.

[0033] Then, when the similarity between the positive case and the reference case is higher than a first threshold, the positive case is injected into the inference context of the large model. The first threshold is a preset similarity judgment value, such as 0.85. When the similarity between the retrieved positive case and the current fault exceeds this threshold, it indicates that a highly similar fault has occurred in the past and was successfully handled. The system injects information such as the fault characteristics, handling process, and handling result of the positive case into the inference context of the large model as a reference. When the similarity between the misjudged case and the reference case is higher than a second threshold, a prompt message is added to the inference context. The second threshold is a preset similarity value used to determine the risk of misjudgment, such as 0.8. When the similarity between the retrieved misjudged case and the current fault exceeds this threshold, it indicates that a similar fault has been misjudged by artificial intelligence in the past. The system adds a prompt message to the inference context, such as "A similar fault has been misjudged by artificial intelligence in the past, please verify."

[0034] Finally, the large model is invoked to infer the operational metrics data, log data, and inference context, generating a list of proposed actions. Each action suggestion in the list contains an operation command. After receiving the operational metrics data, log data, and the inference context enhanced by the above retrieval process, the large model performs comprehensive inference analysis. Positive cases in the inference context provide the model with references to successful experiences, while warnings of misjudged cases remind the model to be more cautious in similar scenarios. The final model outputs a list of proposed actions, with each suggestion containing a specific operation command. In some implementations, the proposed actions may also include anomaly descriptions, root cause localization, and evidence chains.

[0035] In one feasible approach, the steps of obtaining the target system's operational indicator data and log data include: obtaining a preset collection frequency and a preset collection range; and using a database read-only account to collect operational indicator data and log data according to the preset collection frequency and the preset collection range.

[0036] It should be noted that, firstly, the preset collection frequency and preset collection range can be obtained. These preset collection frequency and range are defined by a pre-configured collection strategy file, stored in YAML or JSON format, and loaded into the analysis engine when the operation and maintenance fault handling system service starts. The collection strategy file defines parameters such as the collection interval and collection item list for different target system types and monitored objects. For example, for a database cluster, the collection strategy file can define to collect the number of active database sessions every ten seconds and the lock wait time every minute; for an application server, it can define to collect the thread pool status every minute and the central processing unit utilization and memory usage every five minutes. The collection frequency and range can be flexibly configured according to the importance of the target system and operation and maintenance needs, and are not limited to the examples above.

[0037] Then, using a read-only database account, operational metrics data and log data are collected according to a preset collection frequency and scope. The collector connects to the target database using a pre-configured read-only database account, which only has query permissions and no write, modify, or delete permissions. The collector periodically sends read-only query statements to the target database according to the preset collection frequency to obtain the operational metrics data and log data specified within the preset collection scope. Operational metrics data include, but are not limited to, quantitative performance indicators such as the number of active database sessions, lock wait time, central processing unit utilization, memory utilization, and disk I / O wait time; log data includes text information such as database error logs, slow query logs, and alarm logs. The collector does not expose any write interfaces; the collected data is output to the analysis engine only in a unidirectional data stream, thereby ensuring that the collection process itself does not cause any write operations or configuration changes to the target database, avoiding the introduction of additional security risks.

[0038] Step S20: Perform permission matching on each disposal suggestion in the disposal suggestion list according to the preset authorization rules, and determine the disposal suggestion that passes the matching as the target disposal suggestion; It should be noted that, according to preset authorization rules, each disposal suggestion in the disposal suggestion list undergoes permission matching, and the disposal suggestions that pass the matching are determined as target disposal suggestions. This step can be performed by the access control controller. The preset authorization rules are stored in the form of an authorized operation list, which is stored in JSON array format. Each authorization record can include fields such as operation identifier, operation name, target type, command type, scope of impact, risk level, confirmation role, confirmation timeout time, and execution role. After receiving the disposal suggestion list output by the analysis engine, the access control controller can extract the three fields of operation object type, command type, and scope of impact for each suggestion, and query the authorized operation list to match the corresponding risk level and approval path. For disposal suggestions that pass the matching, they are determined as target disposal suggestions; for disposal suggestions that do not pass the matching, no work order is generated.

[0039] Step S30: Generate a work order to be confirmed based on the target handling suggestion, and send the work order to be confirmed to the interactive terminal; It should be noted that a pending confirmation work order is generated based on the target handling suggestion and sent to the interactive terminal. The access control system packages the matched target handling suggestion into a pending confirmation work order, which includes information such as a fault summary, artificial intelligence analysis report, suggested command, risk level, and confirmation time limit. The work order is then pushed to the interactive terminal for engineers to view and process. For high-risk work orders, they can also be additionally pushed to the mobile terminal of the client's authorized contact person.

[0040] In one feasible approach, the step of sending the work order to be confirmed to the interactive terminal includes: obtaining the risk level and operation command of the target handling suggestion; determining the review path based on the risk level and the operation command; and sending the work order to be confirmed to the interactive terminal based on the review path.

[0041] It should be noted that after determining the target handling recommendation, the access control controller can extract the risk level field and the operation command field. The risk level reflects the degree of impact that the operation may have on the target system; the operation command is the specific instruction that needs to be executed.

[0042] Then, the review path is determined based on the risk level and the operation command. The review path refers to the approval process and roles required for a work order to go through from generation to confirmation. Different risk levels correspond to different review paths. For example, the review path for a handling suggestion at level L1 can be batch execution after confirmation by the vendor engineer; the review path for level L2 can be individual confirmation by the vendor engineer for each work order; and the review path for level L3 can be initial review by the vendor, followed by confirmation by the client's contact person, and execution after confirmation by both parties.

[0043] Finally, the work order to be confirmed is sent to the interactive terminal based on the aforementioned review path. Depending on the review path, the work order is sent to different confirmation terminals. For example, for L1 and L2 level work orders, the work order is sent to the vendor engineer's interactive terminal. For L3 level work orders, in addition to being sent to the vendor engineer's interactive terminal, the work order is also pushed to the mobile terminal of the client's authorized contact person, achieving double confirmation. The interactive terminal displays the complete information of the work order, including a fault summary, AI analysis report, suggested commands, risk level, and confirmation deadline, for engineers or authorized contacts to confirm or reject.

[0044] Step S40: Receive the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, output the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, mark the work order to be confirmed as withdrawn.

[0045] It should be noted that after viewing the work order on the interactive terminal, engineers can perform either "Confirm Execution" or "Reject and Remark" operations. The interactive terminal returns the engineer's operation result to the access control controller. The access control controller receives the interaction result; if the result is "Confirm Execution," it outputs the operation command in the target handling suggestion to the execution terminal, which the engineer can then manually execute on the target system via a bastion host or encrypted channel. If the result is "Rejection," the work order awaiting confirmation is marked as rejected. Furthermore, a time limit can be set; work orders that do not receive confirmation within the confirmation time limit can be marked as "Timeout Withdrawal."

[0046] In one feasible approach, the step of outputting the operation command of the target treatment suggestion to the execution terminal includes: presenting the operation command of the target treatment suggestion on the execution terminal; maintaining the operation channel between the execution terminal and the target system in manual operation mode, wherein the operation command is received by the execution terminal as a manual execution instruction and then transmitted to the target system for execution through the operation channel.

[0047] It should be noted that the proposed operation commands for the target handling are first presented on the execution terminal. Simultaneously, the operation channel between the execution terminal and the target system remains in manual operation mode. The operation commands are received by the execution terminal from manual execution instructions and then transmitted to the target system for execution via the operation channel. In specific implementation, the confirmed command can be executed by the engineer on the target system via a bastion host or an encrypted channel. A bastion host is a jump server system used for operational security auditing. The engineer first logs into the bastion host, then connects to the target system through the bastion host, manually enters the operation commands, and executes them. An encrypted channel, such as a secure shell protocol, ensures data security during command transmission. Throughout the execution process, the AI ​​system does not communicate directly with the target server; the output of the analysis engine only flows to the access control controller and does not directly connect to the target server. This "human-machine isolation" design ensures that the final execution authority remains in the hands of the engineer. Even if the AI-generated command contains errors, the engineer still has a final opportunity for verification and correction before manually entering it.

[0048] In one feasible approach, the annotation result returned by the execution of the work order to be confirmed is received, the annotation result including a root cause accuracy label and a resolution success label; the target resolution suggestion and fault feature data corresponding to the work order to be confirmed are obtained; when both the root cause accuracy label and the resolution success label are positive, the target resolution suggestion and the fault feature data are stored in the positive case partition of the knowledge base; when either the root cause accuracy label or the resolution success label is negative, the target resolution suggestion and the fault feature data are stored in the misjudgment case partition of the knowledge base.

[0049] It should be noted that the system first receives the annotation results returned by the work order to be confirmed. These annotation results include root cause accuracy and resolution success labels. After executing the operation command through the execution terminal, the engineer needs to manually annotate the executed work order on the interactive terminal. The annotation content includes two dimensions: first, "whether the root cause is accurate," i.e., whether the artificial intelligence's judgment of the root cause of the fault is correct; and second, "whether the resolution is successful," i.e., whether the fault is effectively resolved after executing the operation command. The engineer gives a positive or negative label based on the actual execution effect. Then, the system obtains the target resolution suggestion and fault feature data corresponding to the work order to be confirmed. The system extracts the corresponding target resolution suggestion (including operation command, risk level, etc.) and the fault feature data of this fault (including operational indicator data, log data, fault feature vector, etc.) from the executed work order. Then, when both the root cause accuracy label and the resolution success label are positive, the target resolution suggestion and the fault feature data are stored in the positive case partition of the knowledge base. If the engineer determines the root cause is accurate and the handling is successful, the complete data of this work order, including the original work order data, fault feature data, AI analysis report, and execution results, is merged and written into the positive case library, and the vector index is updated. Records in the positive case library will be used as a reference for positive matching in subsequent search enhancement generation searches. When either the root cause accuracy label or the handling success label is negative, the target handling suggestion and fault feature data are stored in the misjudged case partition of the knowledge base. If the engineer determines the root cause is inaccurate or the handling is unsuccessful, the relevant data of this work order is written into the misjudged case library. Records in the misjudged case library will be used for comparison and exclusion in subsequent search enhancement generation searches. When a new fault is highly similar to a misjudged case, the system will automatically prompt "Similar faults have historically been misjudged by AI; please verify."

[0050] In one feasible approach, the audit log of the entire process from the generation of the work order to the return of the interaction result is written in an append-only manner; the hash value of the audit log is calculated by data block, and the hash value of the current data block is linked to the header of the next data block to form a hash chain.

[0051] It should be noted that, firstly, audit logs are written to the entire process of the work order to be confirmed, from its generation to the return of the interaction result, using an append-only approach. The access control controller continuously records audit logs throughout the entire work order lifecycle. Audit logs are written to the append-only log file in JSON line format (i.e., one independent JSON object per line). Each log record includes fields such as a log identifier (e.g., a universally unique identifier), a suggestion identifier, a risk level, the confirming personnel, the confirmation action (approval or rejection), the confirmation timestamp, and the execution result. The log file uses an append-only strategy; new records are only appended to the end of the file, and already written records cannot be modified. Then, the hash value of the audit log is calculated for each data block, and the hash value of the current data block is linked to the header of the next data block to form a hash chain. To further prevent historical records from being tampered with, the system uses hash chain protection for the audit logs. Specifically, the system divides the audit logs into several data blocks, each containing approximately one hour or 100 records. A hash value is calculated for each data block (e.g., using the secure hash algorithm SHA-256), and the hash value of the current data block is linked to the header of the next data block. In this way, each data block contains the hash information of the previous data block, forming a complete hash chain. Any tampering with the historical record will cause the hash values ​​of the tampered data block and all subsequent data blocks to become mismatched, thus making it detectable by the system or auditors. This mechanism ensures the integrity and immutability of the audit log, providing reliable technical protection for post-audit and compliance checks.

[0052] This embodiment acquires the target system's operational metrics data and log data, retrieves reference cases matching the operational metrics data and log data from a knowledge base containing positive cases and misjudged cases. When the similarity of positive cases among the reference cases is higher than a first threshold, the positive case is injected into the inference context of the large model. When the similarity of misjudged cases among the reference cases is higher than a second threshold, a prompt message is added to the inference context. The large model is invoked to infer the operational metrics data, the log data, and the inference context to generate a list of disposal suggestions. Each disposal suggestion in the disposal suggestion list contains an operation command. Permission matching is performed on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and the matched disposal suggestions are determined as target disposal suggestions. A pending confirmation work order is generated based on the target disposal suggestion and sent to the interactive terminal. The interaction result returned by the interactive terminal is received. When the interaction result is an execution instruction, the operation command of the target disposal suggestion is output to the execution terminal. When the interaction result is a rejection instruction, the pending confirmation work order is marked as withdrawn. This embodiment performs permission matching on AI-generated handling suggestions according to preset authorization rules, and sends the matching handling suggestions to the interactive terminal as a pending confirmation work order. Based on the interaction result, it decides to output the operation command or reject and withdraw it. This realizes the legality review and manual confirmation of AI-generated instructions before execution, reducing the risk of operation and maintenance errors caused by AI misjudgment.

[0053] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S20 also includes steps S201 to S204: Step S201: Query the operation type of the proposed handling in the preset authorization rules; It should be noted that after receiving the handling recommendations, the operation object type field is extracted from the recommendations, such as database operation, system operation, network operation, etc. Then, the authorized operation list is checked to see if a corresponding authorized record exists for that operation type. The authorized operation list is stored in JSON array format, and each authorized record contains fields such as operation identifier, operation name, target type, command type, scope of impact, risk level, confirmation role, confirmation timeout time, and execution role. For example, an authorized record for an Oracle database can be represented as: operation identifier "ORA-KILL-03", operation name "Kill database session", target type "database", command type "write_kill", scope of impact "single_instance", and risk level "L3".

[0054] Step S202: When the operation type of the proposed action matches the preset authorization rule, obtain the risk level corresponding to the proposed action in the preset authorization rule; It should be noted that if the proposed action type has an exact match in the authorized action list, the predefined risk level in that record will be directly retrieved. For example, if the action identifier in the proposed action matches the action identifier in the authorized action list, the predefined risk level L3 in the authorized action list will be directly retrieved.

[0055] Step S203: When the proposed action does not match the preset authorization rule, determine the risk level based on the command type of the proposed action and the preset rule; It should be noted that if the suggested operation type does not have an exact match in the authorized operation list, the system will automatically assess the risk level according to preset rules. These preset rules can be: a command type of restart affecting the cluster is rated L3; a command type of write and terminate (i.e., kill-like operations) is rated L3; a command type of safe write (such as modifying configuration parameters but not involving restarting or terminating processes) is rated L2; a command type of read-only query is rated L1; and other uncovered cases are rated L4, indicating that the operation is not within the authorized scope. For example, if the suggested operation command is "reboot system," and its command type is restart with a cluster impact, and no matching record is found in the authorized operation list, it will be rated L3 according to the default rules.

[0056] Step S204: Determine whether the proposed treatment is approved based on the risk level, and identify the approved treatment recommendations as the target treatment recommendations.

[0057] It should be noted that the system employs different processing strategies based on the risk level: For L1-level handling suggestions (read-only operations), if the suggestion is approved, the corresponding approval path is batch execution after initial confirmation by the vendor's engineer; for L2-level handling suggestions (secure write operations), if the suggestion is approved, the corresponding approval path is individual confirmation by the vendor's engineer for each work order; for L3-level handling suggestions (high-risk operations), if the suggestion is approved, the corresponding approval path is initial review by the vendor followed by confirmation by the client's contact person, and execution after confirmation by both parties; for L4-level handling suggestions, if the suggestion is deemed unsuitable, work order generation is directly rejected, and the AI ​​only outputs a root cause report without generating any handling suggestions. Only handling suggestions with risk levels of L1, L2, or L3 are deemed suitable, designated as "target handling suggestions," and enter the subsequent work order generation process. Furthermore, for L3-level target handling suggestions, the corresponding confirmation role and confirmation timeout (e.g., 30 minutes) can be recorded when generating the work order to be confirmed, providing a basis for subsequent work order sending and timeout withdrawal.

[0058] This embodiment queries the operation type of the proposed handling action within the preset authorization rules. When the operation type of the proposed handling action matches the preset authorization rules, the risk level corresponding to the proposed handling action is obtained from the preset authorization rules. When the proposed handling action does not match the preset authorization rules, the risk level is determined based on the command type of the proposed handling action and the preset rules. The risk level is then used to determine whether the proposed handling action is a successful match, and the successful match is designated as the target handling action. This embodiment employs a two-level matching mechanism—querying authorization rules and evaluating default rules for the operation type of the proposed handling action—to accurately match the risk level of defined operations and to automatically assess the risk level of undefined operations based on command type and scope of impact. This ensures that all types of proposed handling actions are effectively classified and managed, avoiding situations where actions cannot be handled due to missing authorization rules, thereby improving the completeness and flexibility of permission matching.

[0059] For example, to help understand the implementation flow of the operation and maintenance fault handling method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3 A simplified flowchart of a method for handling operational and maintenance faults is provided. Specifically: the input is a list of suggestions from artificial intelligence; operational features are extracted; the authorized list is queried for matching; a work order is generated and pushed to the interactive terminal; confirmation is awaited, and if no confirmation is received within the timeout period, the work order is marked as timeout and rejected; if confirmation is received within the timeout period, the confirmed work order is released; and logs are recorded.

[0060] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the methods for handling operational and maintenance failures in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0061] This application also provides a device for handling operational and maintenance failures, please refer to... Figure 4 The device for handling maintenance failures includes: Module 10 is invoked to obtain the target system's operational metrics data and log data, retrieve reference cases matching the operational metrics data and log data from a knowledge base containing positive cases and misjudged cases, inject the positive cases into the inference context of the large model when the similarity of the positive cases in the reference cases is higher than a first threshold, and attach prompt information to the inference context when the similarity of the misjudged cases in the reference cases is higher than a second threshold, invoke the large model to infer the operational metrics data, the log data, and the inference context, and generate a list of disposal suggestions, each of which contains an operation command. Matching module 20 is used to perform permission matching on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and determine the disposal suggestion that passes the matching as the target disposal suggestion; The generation module 30 is used to generate a work order to be confirmed based on the target disposal suggestion, and send the work order to be confirmed to the interactive terminal. The output module 40 is used to receive the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

[0062] This application acquires the operational indicator data and log data of the target system, retrieves reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases, injects the positive case into the inference context of the large model when the similarity of the positive case in the reference case is higher than a first threshold, and adds a prompt message to the inference context when the similarity of the misjudged case in the reference case is higher than a second threshold, calls the large model to infer the operational indicator data, the log data, and the inference context, and generates a list of disposal suggestions, each of which contains an operation command; performs permission matching on each disposal suggestion in the list according to preset authorization rules, and determines the matched disposal suggestions as target disposal suggestions; generates a work order to be confirmed based on the target disposal suggestions and sends the work order to the interactive terminal; receives the interaction result returned by the interactive terminal, outputs the operation command of the target disposal suggestion to the execution terminal when the interaction result is an execution instruction, and marks the work order to be confirmed as withdrawn when the interaction result is a rejection instruction. This application achieves permission matching for AI-generated handling suggestions based on preset authorization rules, and generates a pending confirmation work order for the matched handling suggestions and sends it to the interactive terminal. Based on the interaction result, it decides to output the operation command or reject and withdraw it, thus realizing the legality review and manual confirmation of AI-generated instructions before execution, reducing the risk of operation and maintenance errors caused by AI misjudgment.

[0063] In one embodiment, the calling module 10 is further configured to retrieve reference cases matching the operational metric data and the log data from a knowledge base, the knowledge base containing positive cases and misjudged cases; when the similarity of positive cases in the reference cases is higher than a first threshold, the positive cases are injected into the inference context of the large model; when the similarity of misjudged cases in the reference cases is higher than a second threshold, a prompt message is added to the inference context; the large model is invoked to infer the operational metric data, the log data, and the inference context to generate a list of disposal suggestions, each disposal suggestion in the list containing an operation command.

[0064] In one embodiment, the matching module 20 is further configured to query the operation type of the handling suggestion in the preset authorization rules; when the operation type of the handling suggestion matches the preset authorization rules, obtain the risk level corresponding to the handling suggestion in the preset authorization rules; when the handling suggestion does not match the preset authorization rules, determine the risk level according to the command type of the handling suggestion and the preset rules; determine whether the handling suggestion is matched successfully according to the risk level, and determine the matched handling suggestion as the target handling suggestion.

[0065] In one embodiment, the generation module 30 is further configured to obtain the risk level and operation command of the target disposal suggestion; determine the review path based on the risk level and the operation command; and send the work order to be confirmed to the interactive terminal based on the review path.

[0066] In one embodiment, the output module 40 is further configured to present the operation command of the target handling suggestion on the execution terminal; maintain the operation channel between the execution terminal and the target system in manual operation mode, and the operation command is received by the execution terminal as a manual execution instruction and then transmitted to the target system for execution through the operation channel.

[0067] In one embodiment, the output module 40 is further configured to receive the annotation result returned by the execution of the work order to be confirmed, the annotation result including a root cause accuracy label and a handling success label; obtain the target handling suggestion and fault feature data corresponding to the work order to be confirmed; when both the root cause accuracy label and the handling success label are positive, store the target handling suggestion and the fault feature data in the positive case partition of the knowledge base; when either the root cause accuracy label or the handling success label is negative, store the target handling suggestion and the fault feature data in the misjudgment case partition of the knowledge base.

[0068] In one embodiment, the output module 40 is further configured to write audit logs of the entire process from the generation of the work order to the return of the interaction result in an append-only manner; calculate the hash value of the audit logs by data block, and link the hash value of the current data block to the header of the next data block to form a hash chain.

[0069] The maintenance fault handling device provided in this application, employing the maintenance fault handling method in the above embodiments, can solve the technical problem of how to reduce the risk of maintenance operation errors caused by artificial intelligence misjudgment. Compared with the prior art, the beneficial effects of the maintenance fault handling device provided in this application are the same as those of the maintenance fault handling method provided in the above embodiments, and other technical features in the maintenance fault handling device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0070] This application provides a device for handling maintenance failures. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the maintenance failure handling method in the above embodiment 1.

[0071] The following is for reference. Figure 5The diagram illustrates a structural schematic of a fault handling device suitable for implementing the embodiments of this application. The fault handling device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), tablets, PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The equipment shown for handling operational and maintenance failures is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0072] like Figure 5 As shown, the maintenance fault handling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the maintenance fault handling device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touch screens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the maintenance fault handling equipment to communicate wirelessly or wiredly with other equipment to exchange data. Although the figure shows maintenance fault handling equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0073] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0074] The maintenance fault handling device provided in this application, employing the maintenance fault handling method in the above embodiments, can solve the technical problem of how to reduce the risk of maintenance operation errors caused by artificial intelligence misjudgment. Compared with the prior art, the beneficial effects of the maintenance fault handling device provided in this application are the same as those of the maintenance fault handling method provided in the above embodiments, and other technical features in the maintenance fault handling device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0075] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0077] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the maintenance fault handling method in the above embodiments.

[0078] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0079] The aforementioned computer-readable storage medium may be included in the fault handling equipment or may exist independently and not assembled into the fault handling equipment.

[0080] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a fault handling device, the fault handling device performs the following actions: acquires operational indicator data and log data of the target system; retrieves reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases; when the similarity of positive cases among the reference cases exceeds a first threshold, injects the positive case into the inference context of a large model; when the similarity of misjudged cases among the reference cases exceeds a second threshold, appends a prompt message to the inference context, and invokes the large model to process the operational indicator data. The system performs inference based on the target data, the log data, and the inference context to generate a list of handling suggestions, each of which contains an operation command. It then performs permission matching on each suggestion according to preset authorization rules, identifying the matched suggestions as target handling suggestions. Based on the target handling suggestions, it generates a work order to be confirmed and sends it to an interactive terminal. It receives the interaction result returned by the interactive terminal; if the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal; if the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

[0081] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0083] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0084] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described method for handling operational and maintenance faults. This addresses the technical problem of reducing the risk of operational and maintenance errors caused by misjudgments in artificial intelligence. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the operational and maintenance fault handling method provided in the above embodiments, and will not be elaborated upon here.

[0085] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for handling operational and maintenance faults.

[0086] The computer program product provided in this application can solve the technical problem of how to reduce the risk of operational errors caused by artificial intelligence misjudgment. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the operation and maintenance fault handling method provided in the above embodiments, and will not be repeated here.

[0087] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for handling operational and maintenance faults, characterized in that, The method includes: The system acquires operational metric data and log data of the target system, retrieves reference cases matching the operational metric data and log data from a knowledge base containing positive cases and misjudged cases, injects the positive cases into the inference context of the large model when the similarity of the positive cases in the reference cases is higher than a first threshold, and adds prompt information to the inference context when the similarity of the misjudged cases in the reference cases is higher than a second threshold. The large model is then invoked to infer the operational metric data, the log data, and the inference context to generate a list of disposal suggestions, each of which contains an operation command. According to the preset authorization rules, each disposal suggestion in the disposal suggestion list is matched for permissions, and the disposal suggestion that passes the match is determined as the target disposal suggestion; A work order to be confirmed is generated based on the target handling suggestion, and the work order to be confirmed is sent to the interactive terminal; The system receives the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

2. The method as described in claim 1, characterized in that, The steps for obtaining the target system's operational metrics data and log data include: Obtain the preset sampling frequency and preset sampling range; Using a read-only database account, collect operational indicator data and log data according to the preset collection frequency and preset collection range.

3. The method as described in claim 1, characterized in that, The step of performing permission matching on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and determining the disposal suggestion that passes the matching as the target disposal suggestion includes: Query the operation type of the proposed action in the preset authorization rules; When the operation type of the proposed action matches the preset authorization rule, obtain the risk level corresponding to the proposed action in the preset authorization rule; When the proposed action does not match the preset authorization rule, the risk level is determined based on the command type of the proposed action and the preset rule. Based on the risk level, determine whether the proposed action is approved, and identify the approved action as the target action.

4. The method as described in claim 1, characterized in that, The step of sending the work order to be confirmed to the interactive terminal includes: Obtain the risk level and operational commands for the proposed target treatment; The audit path is determined based on the risk level and the operation command; The pending confirmation work order is sent to the interactive terminal based on the aforementioned review path.

5. The method as described in claim 1, characterized in that, The step of outputting the operation command for the target treatment suggestion to the execution terminal includes: The operation commands for the proposed target handling are presented on the execution terminal; The operation channel between the execution terminal and the target system is kept in manual operation mode. The operation command is received by the execution terminal from the manual execution instruction and then transmitted to the target system for execution through the operation channel.

6. The method as described in claim 1, characterized in that, After the step of outputting the operation command for the target treatment suggestion to the execution terminal, the method further includes: Receive the annotation results returned by the work order to be confirmed, the annotation results include root cause accuracy labels and handling success labels; Obtain the target handling suggestion and fault characteristic data corresponding to the work order to be confirmed; When both the root cause accuracy label and the treatment success label are positive, the target treatment suggestion and the fault feature data are stored in the positive case partition of the knowledge base; When the root cause accuracy label or the treatment success label is negative, the target treatment suggestion and the fault feature data are stored in the misjudgment case partition of the knowledge base.

7. The method as described in claim 1, characterized in that, After receiving the interaction result returned by the interactive terminal, and when the interaction result is an execution instruction, outputting the operation command of the target handling suggestion to the execution terminal; and when the interaction result is a rejection instruction, marking the work order to be confirmed as withdrawn, the method further includes: The audit log of the entire process from the generation of the work order to the return of the interaction result is written in an append-only manner; The hash value of the audit log is calculated for each data block, and the hash value of the current data block is linked to the header of the next data block to form a hash chain.

8. A device for handling operational and maintenance faults, characterized in that, The device includes: The module is used to obtain the target system's operational indicator data and log data, retrieve reference cases matching the operational indicator data and log data from a knowledge base containing positive cases and misjudged cases, inject the positive case into the inference context of the large model when the similarity of the positive case in the reference case is higher than a first threshold, and attach a prompt message to the inference context when the similarity of the misjudged case in the reference case is higher than a second threshold. The large model is then invoked to infer the operational indicator data, the log data, and the inference context to generate a list of disposal suggestions. Each disposal suggestion in the list contains an operation command. The matching module is used to perform permission matching on each disposal suggestion in the disposal suggestion list according to preset authorization rules, and determine the disposal suggestion that passes the matching as the target disposal suggestion; The generation module is used to generate a work order to be confirmed based on the target disposal suggestion, and send the work order to be confirmed to the interactive terminal. The output module is used to receive the interaction result returned by the interactive terminal. When the interaction result is an execution instruction, it outputs the operation command of the target handling suggestion to the execution terminal. When the interaction result is a rejection instruction, it marks the work order to be confirmed as withdrawn.

9. A device for handling operational and maintenance faults, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for handling operational and maintenance failures as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the method for handling maintenance faults as described in any one of claims 1 to 7.

Images