Intelligent operation and maintenance management methods, devices and equipment

Abstract

This application provides an intelligent operation and maintenance management method, apparatus, and device, relating to the field of operation and maintenance management technology. The method includes: receiving natural language commands input by a user through a session window; performing intent recognition on the natural language commands with reference to context data within the session window to obtain intent recognition results; if the trigger words in a predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition results, then, based on the intent recognition results and a tool registry, performing declarative workflow orchestration using a state diagram to obtain a tool invocation plan corresponding to the operation and maintenance task; executing the corresponding invocation parameters of the target tool based on the invocation order in the tool invocation plan to obtain the execution result corresponding to the tool invocation plan; and returning the execution result and the corresponding natural language response to the user through a session window. This application aims to improve the quality of operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance management technology, and in particular to an intelligent operation and maintenance control method, device and equipment. Background Technology

[0002] With the continuous expansion of modern enterprise IT infrastructure, operation and maintenance scenarios are becoming increasingly complex and dynamic, greatly increasing the difficulty of operation and maintenance management.

[0003] In related technologies, operation and maintenance management heavily relies on manual monitoring, requiring maintenance personnel to frequently switch between multiple independent platforms such as monitoring, alarms, automation, and asset management. Furthermore, maintenance personnel complete daily management tasks by inputting data through forms and command-line tools. This decentralized, manual work mode is not only inefficient but also highly susceptible to human error, making it difficult to guarantee the consistency and stability of operation and maintenance quality. Summary of the Invention

[0004] This application provides intelligent operation and maintenance management methods, devices, and equipment to improve the quality of operation and maintenance.

[0005] Firstly, embodiments of this application provide an intelligent operation and maintenance management method, including...

[0006] The system receives natural language commands input by the user through a chat window. These natural language commands are used to represent operational and maintenance tasks.

[0007] Using the context data within the session window as a reference, the intent of the natural language command is recognized to obtain the intent recognition result;

[0008] If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition result, then based on the intent recognition result and the tool registry, a state diagram is used to perform declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool.

[0009] Based on the invocation order in the tool invocation plan, the corresponding invocation parameters of the target tool are executed to obtain the execution result corresponding to the tool invocation plan;

[0010] The execution result and its corresponding natural language response are returned to the user through a chat window.

[0011] In one possible implementation, based on the intent recognition results and the tool registry, a state diagram is used for declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task, including:

[0012] Based on the intent recognition results, the operation and maintenance tools related to the intent recognition results are matched from the tool registry to obtain at least one target tool to be invoked;

[0013] Based on the intent recognition results, determine the initial state and the target final state in the state diagram;

[0014] Based on the node configuration information pre-declared by each target tool in the tool registry, the state transition path from the initial state to the target final state is derived, and the calling order of the target tools is determined.

[0015] Based on the intent recognition results and context data, the parameters of the target tools are configured according to the parameter definitions pre-declared by each target tool in the tool registry to obtain the calling parameters of the target tools;

[0016] Based on the calling order and parameters of the target tools, the tool calling plan corresponding to the operation and maintenance task is obtained.

[0017] In one possible implementation, a predefined skill workflow template is used to represent a reusable automated workflow. The skill workflow template includes the invocation order and invocation parameters of multiple target tools to be invoked. If the trigger words in the predefined skill workflow template match the operation and maintenance intent words in the intent recognition result, the intelligent operation and maintenance management method further includes:

[0018] Based on the matching predefined skill workflow template, the order and parameters of the target tools to be invoked are used to obtain the tool invocation plan corresponding to the operation and maintenance task.

[0019] In one possible implementation, before executing the corresponding calls to the target tool based on the call order in the tool call plan and obtaining the execution result corresponding to the tool call plan, the method further includes:

[0020] Within the tool's registry, the confirmation flag for the target tool is found to be "yes".

[0021] or,

[0022] If the query shows whether the confirmation flag for the target tool is positive or negative, an approval request for the target tool is generated based on the target tool and its calling parameters, and the approval request is sent to the user through the session window.

[0023] Feedback information received regarding the user's approval request.

[0024] One possible implementation also includes: if feedback information indicating that the user has refused to approve the request is received, directly determining the execution result of the operation and maintenance task as: the user has refused to call the target tool.

[0025] One possible implementation involves executing the corresponding calls based on the call order in the tool call plan, and obtaining the execution result corresponding to the tool call plan, including:

[0026] Based on the invocation order in the tool invocation plan, the invocation corresponding to the invocation parameters is executed on the target tool, and the data returned by the target tool is used as the invocation result of the target tool.

[0027] Summarize the call results returned by each target tool to obtain the execution results corresponding to the tool call plan.

[0028] In one possible implementation, if the target tool includes query tools, analysis tools, prediction tools, and operational tools, wherein:

[0029] Query tools are used to obtain operation and maintenance data corresponding to the call parameters through predefined data channels;

[0030] Analysis tools are used to call the operation and maintenance analysis model, perform data analysis and processing on the operation and maintenance data within the context data, and obtain the analysis data output by the operation and maintenance analysis model;

[0031] Prediction tools are used to call capacity prediction models, perform capacity prediction on the operation and maintenance data within the context data, and obtain the prediction data output by the capacity prediction model.

[0032] Operational tools are used to execute operations corresponding to call parameters through predefined operation channels and obtain execution data corresponding to the call parameters.

[0033] In one possible implementation, the operation and maintenance analysis model includes: an anomaly detection model, an alarm noise reduction model, and a root cause analysis model, wherein:

[0034] An anomaly detection model is used to perform unsupervised anomaly detection on input operation and maintenance data using the Isolation Forest algorithm. It combines the normal patterns of time series indicators learned by the Long Short-Term Memory Network to identify operation and maintenance data that deviates from the normal patterns, and obtains and outputs the anomaly analysis data corresponding to the operation and maintenance data.

[0035] The alarm noise reduction model is used to cluster anomaly analysis data based on the similarity of the anomaly analysis data, and to obtain and output the alarm analysis data corresponding to the anomaly analysis data.

[0036] The root cause analysis model is used to locate the root causes of failures corresponding to anomaly analysis data by combining the dependency relationships in the entity relationship graph of hardware terminal devices with association rule mining algorithms, and to obtain and output the root cause analysis data of failures corresponding to the anomaly analysis data.

[0037] In one possible implementation, the capacity prediction model is used to predict resource usage over a future period of time using operational data within contextual data, employing a time-series prediction algorithm combined with a deep learning framework of long short-term memory networks, to obtain a capacity prediction curve.

[0038] The capacity prediction curve is output as the prediction data.

[0039] In one possible implementation, a session window is used to persist automatically saved context data.

[0040] In one possible implementation, before receiving natural language instructions input by the user through the session window, the method further includes:

[0041] A dual-track architecture is used to collect multi-source data from hardware terminal devices and software clusters within the system to be maintained and managed, thus obtaining maintenance data.

[0042] The operation and maintenance data is stored in the storage unit, which is equipped with a predefined data channel. The data channel is used to receive the call parameters sent by the operation and maintenance tools and return the operation and maintenance data corresponding to the call parameters.

[0043] One possible implementation involves using a dual-track architecture to collect multi-source data from the system under maintenance and management, resulting in maintenance data, including:

[0044] An automatic discovery mechanism is adopted to dynamically identify new devices in the system that need to be maintained and managed, resulting in multiple hardware terminal devices, and hardware status indicators of the hardware terminal devices are collected in a standard format.

[0045] By automatically detecting resource changes in software clusters within systems under maintenance and management, and collecting software status indicators of the software clusters in a standard format;

[0046] By unifying hardware and software status metrics into the same data format, operational data can be obtained.

[0047] Secondly, embodiments of this application provide an intelligent operation and maintenance management device, comprising:

[0048] The interaction module is used to receive natural language commands input by the user through a session window. These natural language commands are used to represent operation and maintenance tasks.

[0049] The processing module, referencing the context data within the session window, performs intent recognition on natural language commands to obtain intent recognition results. If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition results, then based on the intent recognition results and the tool registry, a declarative workflow orchestration using a state diagram is performed to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool. Based on the invocation order in the tool invocation plan, the corresponding invocation is performed on the target tool according to the invocation parameters to obtain the execution result corresponding to the tool invocation plan.

[0050] The interaction module is also used to return the execution result and the corresponding natural language response to the user through a session window.

[0051] In one possible implementation, the processing module is specifically used for:

[0052] Based on the intent recognition results, the operation and maintenance tools related to the intent recognition results are matched from the tool registry to obtain at least one target tool to be invoked;

[0053] Based on the intent recognition results, determine the initial state and the target final state in the state diagram;

[0054] Based on the node configuration information pre-declared by each target tool in the tool registry, the state transition path from the initial state to the target final state is derived, and the calling order of the target tools is determined.

[0055] Based on the intent recognition results and context data, the parameters of the target tools are configured according to the parameter definitions pre-declared by each target tool in the tool registry to obtain the calling parameters of the target tools;

[0056] Based on the calling order and parameters of the target tools, the tool calling plan corresponding to the operation and maintenance task is obtained.

[0057] In one possible implementation, a predefined skill workflow template is used to represent a reusable automated workflow. The skill workflow template includes the calling order and calling parameters of multiple target tools to be invoked. If the trigger word in the predefined skill workflow template matches the operation and maintenance intent word in the intent recognition result, the processing module is further used to:

[0058] Based on the matching predefined skill workflow template, the order and parameters of the target tools to be invoked are used to obtain the tool invocation plan corresponding to the operation and maintenance task.

[0059] In one possible implementation, before executing the corresponding calls to the target tool based on the call order in the tool call plan and obtaining the execution result corresponding to the tool call plan, the processing module is further configured to:

[0060] Within the tool's registry, the confirmation flag for the target tool is found to be "yes".

[0061] or,

[0062] If the query shows whether the confirmation flag for the target tool is positive or negative, an approval request for the target tool is generated based on the target tool and its calling parameters, and the approval request is sent to the user through the session window.

[0063] Feedback information received regarding the user's approval request.

[0064] In one possible implementation, the processing module is further configured to: if it receives feedback information that the user has refused to approve the request, directly determine that the execution result of the operation and maintenance task is: the user has refused to call the target tool.

[0065] In one possible implementation, the processing module is specifically used for:

[0066] Based on the invocation order in the tool invocation plan, the invocation corresponding to the invocation parameters is executed on the target tool, and the data returned by the target tool is used as the invocation result of the target tool.

[0067] Summarize the call results returned by each target tool to obtain the execution results corresponding to the tool call plan.

[0068] In one possible implementation, if the target tool includes query tools, analysis tools, prediction tools, and operational tools, wherein:

[0069] Query tools are used to obtain operation and maintenance data corresponding to the call parameters through predefined data channels;

[0070] Analysis tools are used to call the operation and maintenance analysis model, perform data analysis and processing on the operation and maintenance data within the context data, and obtain the analysis data output by the operation and maintenance analysis model;

[0071] Prediction tools are used to call capacity prediction models, perform capacity prediction on the operation and maintenance data within the context data, and obtain the prediction data output by the capacity prediction model.

[0072] Operational tools are used to execute operations corresponding to call parameters through predefined operation channels and obtain execution data corresponding to the call parameters.

[0073] In one possible implementation, the operation and maintenance analysis model includes: an anomaly detection model, an alarm noise reduction model, and a root cause analysis model, wherein:

[0074] An anomaly detection model is used to perform unsupervised anomaly detection on input operation and maintenance data using the Isolation Forest algorithm. It combines the normal patterns of time series indicators learned by the Long Short-Term Memory Network to identify operation and maintenance data that deviates from the normal patterns, and obtains and outputs the anomaly analysis data corresponding to the operation and maintenance data.

[0075] The alarm noise reduction model is used to cluster anomaly analysis data based on the similarity of the anomaly analysis data, and to obtain and output the alarm analysis data corresponding to the anomaly analysis data.

[0076] The root cause analysis model is used to locate the root causes of failures corresponding to anomaly analysis data by combining the dependency relationships in the entity relationship graph of hardware terminal devices with association rule mining algorithms, and to obtain and output the root cause analysis data of failures corresponding to the anomaly analysis data.

[0077] In one possible implementation, the capacity prediction model is used to predict resource usage over a future period of time using operational data within contextual data, employing a time-series prediction algorithm combined with a deep learning framework of long short-term memory networks, to obtain a capacity prediction curve.

[0078] The capacity prediction curve is output as the prediction data.

[0079] In one possible implementation, a session window is used to persist automatically saved context data.

[0080] In one possible implementation, before receiving natural language commands input by the user through the session window, the acquisition module is used to:

[0081] A dual-track architecture is used to collect multi-source data from hardware terminal devices and software clusters within the system to be maintained and managed, thus obtaining maintenance data.

[0082] The operation and maintenance data is stored in the storage unit, which is equipped with a predefined data channel. The data channel is used to receive the call parameters sent by the operation and maintenance tools and return the operation and maintenance data corresponding to the call parameters.

[0083] In one possible implementation, the acquisition module is specifically used for:

[0084] An automatic discovery mechanism is adopted to dynamically identify new devices in the system that need to be maintained and managed, resulting in multiple hardware terminal devices, and hardware status indicators of the hardware terminal devices are collected in a standard format.

[0085] By automatically detecting resource changes in software clusters within systems under maintenance and management, and collecting software status indicators of the software clusters in a standard format;

[0086] By unifying hardware and software status metrics into the same data format, operational data can be obtained.

[0087] Thirdly, embodiments of this application provide an intelligent operation and maintenance management device, including: a memory and a processor;

[0088] The memory stores instructions that the computer executes;

[0089] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0090] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0091] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0092] The intelligent operation and maintenance management method, device, and equipment provided in this application receive natural language commands input by the user through a session window and perform intent recognition with reference to the context data within the session window, enabling a more accurate understanding of the user's current operation and maintenance task. When the trigger words in the skill workflow template do not match the operation and maintenance intent words, a declarative workflow orchestration is performed using a state diagram based on the intent recognition results and the tool registry. This generates a tool call plan containing the target tool, call order, and call parameters, allowing for flexible organization of multiple operation and maintenance tools for collaborative processing of different operation and maintenance tasks. Subsequently, by executing the target tool in the call order and returning the execution result and corresponding natural language response through the session window, the efficiency of cross-system analysis and handling in complex operation and maintenance scenarios is improved, while simultaneously reducing the user's operational threshold and promoting the accumulation and reuse of operation and maintenance experience. Attached Figure Description

[0093] 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.

[0094] Figure 1 A schematic diagram illustrating a scenario for the intelligent operation and maintenance management method provided in this application embodiment;

[0095] Figure 2 A flowchart illustrating the intelligent operation and maintenance management method provided in the embodiments of this application. Figure 1 ;

[0096] Figure 3A flowchart illustrating the intelligent operation and maintenance management method provided in the embodiments of this application. Figure 2 ;

[0097] Figure 4 This is a schematic diagram of the intelligent operation and maintenance management device provided in the embodiments of this application;

[0098] Figure 5 This is a schematic diagram of the structure of the intelligent operation and maintenance management equipment provided in the embodiments of this application.

[0099] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0100] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0101] Enterprise-level IT operations and maintenance management falls under the field of computer system management and intelligent operations and maintenance technology. It is typically applied in hybrid infrastructure environments consisting of physical servers, virtual machines, container clusters, databases, and business applications. These scenarios usually require the reliance on monitoring platforms, alarm systems, automation tools, and unified portals to continuously observe operational status and handle faults, performance fluctuations, and operations and maintenance requests.

[0102] In related technologies, multiple independent platforms work collaboratively: a monitoring platform collects host, network, and application metrics; an alarm system generates events based on preset thresholds or rules; automated tools execute queries, configuration changes, and fault handling operations according to scripts or predefined processes; and operations personnel then switch between different interfaces to complete analysis and handling. The basic working principle is that each system first outputs monitoring results, and then personnel, based on experience, interpret the meaning of alarms, select tools, and organize execution steps. However, this type of technical solution relies heavily on rules, scripts, and human experience. It not only struggles to accurately understand the user's true operational intent based on the session context but also easily leads to information gaps due to platform fragmentation. Faced with the same fault, operations personnel often need to first determine whether the requirement is for querying, analysis, or handling, then manually select tools, fill in parameters, and arrange the calling order. In complex tasks, the operation path may need to be repeatedly modified, resulting in low response efficiency.

[0103] Furthermore, existing interaction methods largely rely on specialized commands, query statements, or complex forms, making it difficult for non-technical personnel to directly participate in operation and maintenance. The accumulated experience of senior personnel is also difficult to distill into reusable standard procedures. As a result, alarm noise is difficult to converge quickly in complex scenarios, fault location and handling processes are highly dependent on individual capabilities, and cross-system collaborative analysis and execution efficiency are limited. In summary, how to more efficiently complete intent recognition, tool selection, and execution orchestration based on user input in complex operation and maintenance scenarios has become an urgent technical problem to be solved.

[0104] This application provides an intelligent operation and maintenance management method. It receives natural language commands through a session window and performs intent recognition based on contextual data. When a skill workflow template does not match, it uses a state diagram to declaratively orchestrate the operation and maintenance tasks based on the intent recognition results and the tool registry. This forms a tool invocation plan that includes the target tool, invocation order, and invocation parameters. After execution according to the plan, it returns the execution result and the corresponding natural language response. Through this intelligent operation and maintenance management architecture—using a session window as the interaction entry point, a tool registry as the capability organization foundation, and a state diagram orchestration as the task execution mechanism—it can transform previously fragmented operation and maintenance operations into a continuous, task-oriented processing flow, thereby lowering the operational threshold and improving the efficiency of cross-tool collaborative processing.

[0105] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0106] Figure 1 This is a schematic diagram of a scenario for the intelligent operation and maintenance management method provided in the embodiments of this application, such as... Figure 1 As shown, the specific application scenario of this application embodiment includes user 11, processing center 12, and system 13 to be operated and maintained, wherein:

[0107] User 11 maintains a session window with processing center 12. The session window is used to establish a communication channel between user 11 and processing center 12. Processing center 12 receives natural language commands input by the user through the session window. User 11 sends natural language commands to processing center 12 through the session window.

[0108] User 11 initiates a session window creation request to processing center 12. This session window is used to establish a dedicated two-way communication channel between user 11 and processing center 12, and retains the interaction context data throughout the process to avoid information gaps in multiple rounds of operation and maintenance instructions.

[0109] User 11 sends natural language commands to processing center 12 through the established session window. Natural language commands are used to accurately represent the operation and maintenance tasks that the user wants to perform, without the need for the user to manually write complex operation and maintenance scripts or operation commands.

[0110] The processing center 12 receives natural language commands input by the user in real time through the session window and executes intelligent operation and maintenance management methods. It also returns the original execution results and corresponding natural language interpretation content to the user 12 in a synchronous manner through the session window, thus completing the entire operation and maintenance interaction loop.

[0111] The processing center 12 is also used to collect information from the system 13 to be maintained and managed based on natural language commands, and to carry out maintenance and management of the system 12.

[0112] Figure 2 A flowchart illustrating the intelligent operation and maintenance management method provided in the embodiments of this application. Figure 1 ,like Figure 2 As shown, this intelligent operation and maintenance management method includes:

[0113] S201. Receive natural language commands input by the user through the session window. Natural language commands are used to represent operation and maintenance tasks.

[0114] A session window is an interactive window that receives user input and returns processing results. Specifically, a session window can consist of a front-end dialog interface, a session identifier management module, and an interface channel connecting to the back-end service. The session window is used to handle single-round or multi-round operation and maintenance interactions.

[0115] Natural language commands are natural language input directly by the user through the session window. Natural language commands represent the operational tasks to be executed. Optionally, operational tasks include at least one of the following: querying host status, analyzing alarm causes, restarting services, verifying database connections, or troubleshooting container anomalies. Optionally, natural language commands include at least one of the following: natural language, session identifier, user identity identifier, submission time, and operational resources.

[0116] Specifically, the session window can be deployed on any location, such as a unified operations and maintenance portal, a World Wide Web console, a desktop client, or a mobile terminal. After the user outputs natural language on the front end, the natural language, session identifier, user identity identifier, submission time, and the resource scope associated with the current page are sent to the backend session access service, enabling the session window to obtain natural language commands.

[0117] In one possible embodiment, the user input may include at least one of the following: resource name, business system name, time range, fault phenomenon, handling action, and confirmation statement, such as "view the hosts with database connection errors today and provide the handling results" or "restart the container instance corresponding to the previous alarm".

[0118] When user input contains colloquial, abbreviated, or multi-round instructions, it is still preserved as the original natural language instruction and is not invoked during the access phase. It only completes the receiving, recording, and forwarding processing.

[0119] For hybrid infrastructure scenarios, the tenant, environment type, target resource set, and permission boundaries of the current session can also be collected simultaneously to limit the scope of subsequent task processing.

[0120] Based on the above processing method, operation and maintenance tasks enter the unified processing link in the form of natural language, without relying on users to switch monitoring platforms, alarm systems or automation tool interfaces in advance, and subsequent steps can be executed continuously around the same session context.

[0121] S202. Using the context data within the session window as a reference, perform intent recognition on the natural language command to obtain the intent recognition result.

[0122] Context data includes at least one of the following: historical dialogue content accumulated within the session window, resource entities identified in previous rounds, alarm number, hostname, application name, database instance name, namespace, time conditions, user confirmation status, and current task execution status data.

[0123] The intent recognition result is a structured output obtained after semantic understanding of the current natural language instruction. It represents the operational intent that the user wishes to execute. The intent recognition result includes at least operational intent words and may further include the task object, action type, constraints, and result presentation requirements.

[0124] Optionally, the context data and natural language instructions within the session window can be used as input to a large language model. The large language model can then be used to perform intent recognition on the natural language instructions to obtain the intent recognition result.

[0125] Specifically, the process involves retrieving the most recent N rounds of dialogue records and the current task cache from the storage unit corresponding to the dialogue window, based on the dialogue window-based representation. N can be set to two or more rounds according to system resource configuration to cover common omissions, transitions, and corrections in multi-round dialogues. Then, based on the most recent N rounds of dialogue records and the current task cache, context data is obtained. Based on this context data, joint semantic parsing is performed on the natural language instructions to determine intent, resulting in the intent recognition result. Optionally, the joint semantic parsing process may include at least one of the following: word segmentation or sub-word segmentation, named entity extraction, referential resolution, temporal phrase normalization, resource alias mapping, and action semantic classification.

[0126] For example, when a user's most recent input is "Check the interface alarms of the payment system production environment", the current natural language instruction is "Handle the serious ones first". Based on the intent recognition of joint semantic parsing of the natural language instruction in the context data, "serious" is parsed as a set of serious level alarms, and "handle" is parsed as a disposal-type operation and maintenance intent, rather than being interpreted as ordinary text in isolation.

[0127] Optionally, the natural language instruction can be represented by terms such as "it", "that node", or "this machine", and bound to the most recent valid entity in the context data of the most recent N rounds of dialogue records.

[0128] Optionally, incomplete semantic expressions in natural language commands, such as "restore," "see the reason," or "continue execution," can be combined with the most recent N rounds of dialogue records to infer whether the intent is a query, analysis, or operation.

[0129] The intent recognition results can be represented using structured data objects. Optionally, the intent recognition results may include at least one of the following fields: operational intent words, target resources, constraints, candidate parameter values, session-related entities, and confidence markers.

[0130] Optionally, when a single natural language instruction contains multiple intents, the natural language instruction is first split into a main intent and secondary intents. The main intent is used to drive subsequent orchestration, while the secondary intents serve as supplementary parameters or as the basis for generating subsequent responses.

[0131] By combining the current natural language instruction with contextual data in semantic parsing, task continuity can be maintained in multi-turn interactions, allowing subsequent template matching and tool orchestration to take more stable structured intents as input.

[0132] S203. If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition result, then based on the intent recognition result and the tool registry, a state diagram is used to perform declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool.

[0133] Predefined skill workflow templates are pre-configured, reusable automated workflow sets. Each skill workflow template includes at least a trigger word, the applicable intent scope, and the invocation order and parameters of the target tools corresponding to the trigger word. The trigger word indicates the operational intent that the skill workflow template can directly cover.

[0134] Optionally, the trigger word can be at least one of the following: restart service, query central processing unit (CPU) anomaly, and handle disk alarm.

[0135] Optionally, the intent recognition results and tool registry are input into the large language model. Using the large language model, a declarative workflow orchestration is performed through a state diagram to obtain the tool invocation plan corresponding to the operation and maintenance task.

[0136] Skill workflow templates can solidify the experience of senior operations and maintenance personnel into reusable automated workflows. Each skill workflow template is defined in Markdown file format, and the standardized file structure enables zero-code expansion and hot reloading.

[0137] For example, each skill workflow template includes a pre-processing metadata area and a main body step execution area, wherein:

[0138] The pre-processor metadata area, located at the header of the skill workflow template file, declares basic skill information using a data serialization format (YAML Ain'ta Markup Language). This basic information includes at least one of the following: skill name, category, and trigger keyword list. The skill name is used for skill identification during human-computer interaction. The category defines the type of the skill workflow template, facilitating the organization and retrieval of the skill library. The trigger keyword list is used to automatically trigger the corresponding skill workflow template through semantic matching. For example, the skill name can include any of the following: alarm handling, container restart, or log analysis. The category can include any of the following: alarm class, deployment class, or diagnostic class. The trigger keyword list can include at least one of the following keywords: alarm, alert, or alert.

[0139] The main execution section lists multiple steps in sequence, specifying the operation and maintenance tools to be called for each step, the parameters passed to the operation and maintenance tools, and the conditional execution rules.

[0140] Skill workflow templates encapsulate complex operations and maintenance (O&M) into standardized processes, significantly simplifying technical implementation. Zero-code extensions mean that O&M personnel do not need to master programming languages; they can define complete automated workflows simply by writing Markdown files, significantly lowering the technical barrier to automated O&M. Simultaneously, skill workflow templates feature a hot-reload mechanism, ensuring that changes to the template take effect immediately, shortening fault response time. Furthermore, skill workflow templates allow a single template to adapt to multiple scenarios, reducing redundant development and improving the reusability of automated assets.

[0141] If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition result, it means that the operation and maintenance task corresponding to the intent recognition result cannot directly apply the existing skill workflow template. Therefore, based on the intent recognition result and the tool registry, a declarative workflow orchestration using a state diagram is employed to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool registry is a data structure or database that stores the configuration information for each operation and maintenance tool invocation. Optionally, the tool registry can record at least one of the following information for each operation and maintenance tool: tool name, interface address, parameter definition, input / output mode, etc. An operation and maintenance tool is a tool that can execute operation and maintenance tasks.

[0142] Specifically, information related to the current task is extracted from the intent recognition results and combined with the call configuration information in the tool registry. A state diagram is used for declarative workflow orchestration to determine the target tool, call order, and call parameters corresponding to the operation and maintenance task, thereby forming an executable tool call plan.

[0143] For example, when the user inputs a natural language command such as "Analyze the CPU anomaly of the host that just received the alarm and handle the high-load process", the tool invocation plan corresponding to the operation and maintenance task can be generated by combining the intent recognition results with relevant information in the tool registry.

[0144] When a skill workflow template does not match, a declarative orchestration is formed by combining intent recognition results, tool registry, and state diagram. This transforms the tool selection, parameter assembly, and call ordering process, which originally relied on manual judgment, into a tool call plan automatically generated by the system, thereby enabling the continuous organization of complex operation and maintenance tasks under cross-platform conditions.

[0145] S204. Based on the calling order in the tool calling plan, execute the corresponding calls according to the calling parameters of the target tool to obtain the execution result corresponding to the tool calling plan.

[0146] The target tools are scheduled sequentially according to the invocation order determined in the tool invocation plan. The target tools are one or more tools selected from the tool registry to complete the current operation and maintenance task.

[0147] The execution interface of the target tool can be any of the following: Hypertext Transfer Protocol (HTTP) interface, Remote Procedure Call (RPC) interface, message queue consumption interface, script execution entry point, or automation platform task entry point. The call parameters represent the set of parameters required for the target tool to execute.

[0148] Optionally, when determining the tool invocation plan, parameter mapping is performed on the target tool to obtain the invocation parameters of the target tool. The invocation parameters include at least one of the following: resource identifier, time window, query conditions, operation action, execution context, and upstream node output reference.

[0149] Specifically, based on the tool invocation plan, an execution node instance is created for each target tool, and a request sequence number, session identifier, target tool tool identifier, and invocation parameters are assigned to the node instance. Then, invocations to the target tools are initiated according to the invocation order. After a target tool returns data, the execution engine extracts specified fields from the returned result and writes them into the input parameters of subsequent target tools according to the field mapping rules in the plan. For example, if the target tools in the tool invocation plan include a query tool and an analysis tool, and the execution order of the query tool precedes that of the analysis tool, then the data returned by the query tool is written into the invocation parameters of the analysis tool, enabling the analysis tool to analyze the data returned by the query tool.

[0150] When the tool invocation plan contains multiple target tools, the target tools are invoked one by one in the invocation order, and the task status cache is updated after each node instance completes. If the invocation of a target tool corresponding to a certain node instance fails, the system can decide whether to retry or terminate the invocation of target tools corresponding to subsequent node instances based on the return information of the target tool. Simultaneously, the failure information of the target tool invocation will be written to the execution result.

[0151] The execution result is the summary output obtained after the target tool is executed in the order of invocation. The execution result may include at least one of the following: data returned by each node, node execution status, operation receipt, error message, generated diagnostic conclusion, and final task completion identifier.

[0152] For example, in the "query alarm - analyze log - restart service" chain, the execution result includes alarm content, log exception summary, restart action receipt, and health check results after restart.

[0153] In this way, the output of the preceding target tool is continuously passed to the subsequent target tool, and the entire tool call plan forms a complete processing link from querying, analysis to handling. The execution results are then used as a unified summary object for subsequent response generation and session display.

[0154] S205. Return the execution result and the corresponding natural language response to the user through the session window.

[0155] Two types of information are output to the user through the session window: the execution result itself and the natural language response generated in response to the execution result.

[0156] The execution results can be displayed in the session window in any format, such as structured cards, tables, key-value pairs, log extracts, or text summaries. The execution results must include at least one of the following: the target resources involved in the operation and maintenance task, the executed tool nodes, the status of each node, and the final result.

[0157] Natural language responses are generated based on the execution results and natural language instructions, and are used to transform structured results into textual expressions that users can directly understand.

[0158] Specifically, firstly, the execution results are collected and trimmed, filtering out relevant fields directly related to the user's natural language commands. These relevant fields may include at least one of the following: abnormal hostname, peak CPU usage, critical error logs, execution action receipts, and current service status. Then, these relevant fields, along with the natural language commands, intent recognition results, and session context, are provided to the response generation module. The response generation module organizes the output content according to the task type.

[0159] For example, if the operation and maintenance task represented by the natural language instruction is a query task, the natural language response shall provide at least one of the following information: query object, time range, and query conclusion.

[0160] For example, if the operation and maintenance task represented by the natural language instruction is an analysis task, the natural language response shall provide at least one of the following information: abnormal phenomena, related evidence, and judgment conclusions.

[0161] For example, if the maintenance task represented by the natural language instruction is an operation-type task, the natural language response shall provide at least one of the following information: execution action, execution time, execution result, and subsequent status verification information.

[0162] For example, when the execution result indicates that a service has been restarted and restored to health, the session window simultaneously displays the operation receipt and a natural language reply stating "The restart of the target service has been completed, and the health check has passed after the restart."

[0163] For example, when the execution result indicates that the diagnostic link has only completed the analysis but has not performed any operation, the corresponding natural language response is "High-load process and associated host have been located, and no termination operation has been performed at present".

[0164] In one possible implementation, the natural language response generation retains session association information, allowing the user to continue subsequent tasks based on the returned results when entering "continue processing," "export results," or "only process the serious ones" in the next round. If the execution result contains failed nodes, the response generation module writes the failed node name, failure reason, and current stopping position into the response text, maintaining consistency with the node status in the execution result. After receiving the result, the session window writes the execution result and the natural language response as a single message into the session history for subsequent contextual reference.

[0165] Once the execution results and natural language responses are returned uniformly within the same session window, users do not need to switch to other system interfaces to retrieve the processing status again. They can continue to initiate supplementary analysis, confirm execution, or take subsequent actions within the current session.

[0166] This application provides an intelligent operation and maintenance management method, including: receiving natural language commands input by the user through a session window; performing intent recognition on the natural language commands with reference to the context data within the session window; and obtaining the intent recognition result. The session window serves as a unified interaction entry point, and the context data is used to maintain multi-turn semantic continuity. When the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition result, a declarative workflow orchestration is performed using a state diagram based on the intent recognition result and the tool registry, resulting in a tool invocation plan including the target tool, invocation order, and invocation parameters. The tool registry provides tool capability descriptions and invocation configuration information. Based on the invocation order in the tool invocation plan, the invocation corresponding to the invocation parameters is executed on the target tool, obtaining the execution result corresponding to the tool invocation plan; and the execution result and the corresponding natural language response are returned to the user through the session window, thereby enabling the operation and maintenance task to be directly connected from natural language input to a continuous processing chain of tool selection, parameter configuration, sequential execution, and result return. For task scenarios that cannot be covered by the skill workflow template, an executable plan can still be automatically formed based on the identified operation and maintenance intent and registered tool capabilities, thus addressing the complex operation and maintenance processing needs across systems and tools in a hybrid infrastructure environment. By recognizing the intent of user-initiated natural language commands and executing the corresponding instructions for operational tasks, the difficulty of operations and maintenance can be reduced. At the same time, it reduces errors caused by human intervention and improves the consistency and stability of operations and maintenance management.

[0167] Figure 3 A flowchart illustrating the intelligent operation and maintenance management method provided in the embodiments of this application. Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the examples, the intelligent operation and maintenance management method is described in detail, which includes:

[0168] In one possible implementation, step S203 above, based on the intent recognition result and the tool registry, uses a state diagram to perform declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task, which may further include:

[0169] S2031. Based on the intent recognition result, match the operation and maintenance tools related to the intent recognition result from the tool registry to obtain at least one target tool to be invoked.

[0170] The operation and maintenance intent words in the intent recognition results are compared with the tool tags, capability descriptions and invocation conditions in the tool registry to filter out the operation and maintenance tools that are consistent with the current operation and maintenance task, and thus obtain the target tool to be invoked.

[0171] S2032. Based on the intent recognition results, determine the initial state and the target final state in the state diagram.

[0172] Based on the task type of the operation and maintenance task indicated by the intent recognition result, the task start semantics are mapped to the initial state in the state diagram, and the task completion semantics are mapped to the target final state, so that the state diagram can carry the declarative orchestration constraints of the current operation and maintenance task.

[0173] S2033. Based on the node configuration information pre-declared by each target tool in the tool registry, deduce the state transition path from the initial state to the target final state, and determine the calling order of the target tools.

[0174] By reading the pre-declared node configuration information of each target tool, and combining the pre-dependencies and post-output relationships between tools, the state transition path from the initial state to the target final state is derived, and the calling order of each target tool is determined accordingly.

[0175] S2034. Based on the intent recognition results and context data, configure the parameters of the target tools according to the parameter definitions pre-declared by each target tool in the tool registry to obtain the calling parameters of the target tools.

[0176] By combining the constraint information in the intent recognition results with the object identifier, time range, target range and environment identifier in the context data, the parameter definitions of each target tool are filled and assigned values ​​to generate call parameters that match the semantics of the current operation and maintenance task, thus obtaining the call parameters of the target tool.

[0177] S2035. Based on the calling order and calling parameters of the target tools, obtain the tool calling plan corresponding to the operation and maintenance task.

[0178] Assemble the tool invocation plan according to the determined invocation order and invocation parameters to obtain the tool invocation plan corresponding to the operation and maintenance task.

[0179] By adopting a state diagram-based declarative orchestration approach, matching, sorting, and parameter configuration can be uniformly incorporated into the tool registry constraints, forming an executable tool invocation plan consistent with operational semantics. This results in stronger consistency and configurability in cross-tool collaboration processes.

[0180] In one possible implementation, a predefined skill workflow template is used to represent a reusable automated workflow. The skill workflow template includes the calling order and calling parameters of multiple target tools to be called. If the trigger words in the predefined skill workflow template match the operation and maintenance intent words in the intent recognition result, the intelligent operation and maintenance management method further includes: obtaining the tool calling plan corresponding to the operation and maintenance task based on the matching calling order and calling parameters of the target tools to be called in the predefined skill workflow template.

[0181] Predefined skill workflow templates can be stored in a template library. Each skill workflow template can simultaneously store at least one of the following information: template identifier, trigger word set, target tool identifier set, sequential dependency relationship between tools, and parameter mapping relationship corresponding to each tool.

[0182] The target tools can be query tools, analysis tools, alarm confirmation tools, configuration change tools, or work order linkage tools.

[0183] The skill workflow template solidifies the order in which target tools are invoked, allowing the template content to be read directly and the tool invocation plan to be assembled upon successful matching. In practical applications, target tools can also be stored using JavaScript Object Notation (JSON), Extensible Markup Language (XML), or database records; this application does not impose any limitations on this.

[0184] The system compares the operation and maintenance intent words from the intent recognition results with the set of trigger words in the skill workflow template. If a match is found between the trigger words in the predefined skill workflow template and the operation and maintenance intent words from the intent recognition results, the system extracts the preset target tool call order and call parameters from the corresponding skill workflow template and converts the target tool call order and call parameters into a tool call plan corresponding to the operation and maintenance task. Since the call relationships and parameter content are pre-fixed in the template, validated automated workflows can be directly reused.

[0185] The matching results of the trigger words in the predefined skill workflow template with the operation and maintenance intent words in the intent recognition results can directly drive the generation of tool call plans, reduce the reliance on state diagram derivation and manual arrangement, enable high-frequency operation and maintenance tasks to be executed quickly along the preset workflow, and precipitate mature handling experience into reusable templates, thereby improving the consistency and arrangement efficiency of cross-tool collaborative processing.

[0186] In one possible implementation, before executing the corresponding call to the target tool based on the call order in the tool call plan and obtaining the execution result corresponding to the tool call plan, the method further includes: querying the tool registry to find if the confirmation flag for the target tool is yes; or, if the confirmation flag for the target tool is no; generating an approval request for the target tool based on the target tool and its call parameters; and sending the approval request to the user through a session window; and receiving feedback information indicating that the user approves the approval request. Optionally, the approval request can be sent to the user through a Server-Sent Events Channel (SSE).

[0187] The tool registry can use a key-value index structure to store the target tool's identifier, invocation entry point, parameter template, and confirmation flag. During a query, the corresponding record is located based on the operation and maintenance tool's tool name or tool identifier, and the confirmation flag field is read.

[0188] When the confirmation flag is "yes", the tool is considered a trusted execution tool and proceeds directly to the subsequent scheduling.

[0189] When the confirmation flag is "No", the approval request content is generated based on the call parameters, and key fields in the call parameters are preserved in a readable format so that the user can verify the scope of execution. After receiving the approval request, the session window presents the approval request to the user and waits for feedback. The feedback information can be represented by a confirmation command in the session message. By parsing the confirmation command, it is confirmed that the user has approved the approval request.

[0190] Before the target tool is executed, a tool-level confirmation check is introduced, enabling high-risk operations requiring manual oversight to be authorized within the session window without altering the overall orchestration of the tool invocation plan. For authorized tools, the invocation chain can be directly continued; for tools requiring approval, the invocation is executed only after user approval, thus maintaining consistency between security control and automated execution in the tool invocation plan.

[0191] By implementing differentiated control over different target tools based on the confirmation flag in the tool registry, and completing approval collection and authorization feedback through a session window when necessary, the execution conditions of the target tools are made clearer, the controllability and consistency of the invocation process are improved, and the tool invocation plan continues to be executed in the predetermined order without affecting the tool invocation plan.

[0192] One possible implementation also includes, if feedback is received that the user has refused the approval request, directly determining the execution result of the operation and maintenance task as: the user has refused to call the target tool.

[0193] Approval requests can be associated with task identifiers, tool identifiers, call parameter summaries, and pending confirmation information. Upon receiving user rejection feedback, the current operation and maintenance task is located based on the task identifier, and the rejection status is synchronously recorded in the session state cache and task result record.

[0194] Upon detecting feedback that the approval request has been rejected, the call chain of the subsequent target tool is immediately frozen, and the execution result of the operation and maintenance task is output for the session window to generate the corresponding natural language response.

[0195] User confirmation is used as a prerequisite for the target tool to continue execution. When the user explicitly refuses, the task status is directly set to refused and terminated, without entering the actual invocation stage. This allows the tool invocation plan to complete the closed loop during the approval process, ensuring that the refusal result can be uniformly mapped to the standard execution result and remain consistent with subsequent session responses.

[0196] By adopting the above method, a clear task termination conclusion can be formed immediately when the user refuses to approve, reducing invalid calls and status ambiguity, and ensuring that the execution results of operation and maintenance tasks can be accurately recorded and transmitted back, which facilitates maintaining control consistency and result traceability in session interaction.

[0197] In one possible implementation, step S204 may further include:

[0198] S2041. Based on the calling order in the tool calling plan, execute the call corresponding to the calling parameters of the target tool, and use the data returned by the target tool as the calling result of the target tool.

[0199] Initiate call requests one by one in the order predetermined by the tool call plan, and record the data returned by the current target tool after receiving the call parameters directly as the call result corresponding to the target tool.

[0200] If the target tool returns structured data, the field content, field order, and status indicators within the structured data can be retained and used as the corresponding call result of the target tool.

[0201] If the target tool returns unstructured text, the original text can be saved as the result of the target tool's call.

[0202] S2042. Summarize the call results returned by each target tool to obtain the execution results corresponding to the tool call plan.

[0203] If a single tool invocation plan includes multiple target tools, the invocation results returned by each target tool are merged, integrated, or correlated to form an execution result corresponding to the overall operation and maintenance task. Optionally, the execution result can be represented as at least one of the following: a sequentially arranged result chain, a summarized status set, or a composite result object containing the outputs of each tool.

[0204] In one implementation, when executing a target tool call, the data returned by the previous target tool can be used as the basis for subsequent processing of the next target tool. When summarizing, the call result of each target tool is associated with and stored with the tool identifier, call order and parameter information corresponding to the target tool, so as to obtain a traceable overall execution result.

[0205] Optionally, if a target tool returns an error message, the error message can still be included in the summary as the result of the call to that target tool, so as to keep the execution result consistent with the actual call process.

[0206] In this way, the target tools in the tool invocation plan can be executed in a predetermined order. The return data of individual target tools is directly retained as the corresponding invocation result, and then aggregated to form the overall execution result, thus ensuring consistency between the execution output and the orchestration process. Simultaneously, the processing status of the operation and maintenance tasks, the output of each target tool, and their interrelationships can be fully presented. Therefore, the execution result of the tool invocation plan has good completeness and interpretability, facilitating subsequent display, auditing, or further orchestration.

[0207] In one possible implementation, if the target tool includes query tools, analysis tools, prediction tools, and operation tools, wherein: the query tools are used to obtain the operation and maintenance data corresponding to the call parameters through a predefined data channel; the analysis tools are used to call the operation and maintenance analysis model to perform data analysis processing on the operation and maintenance data in the context data and obtain the analysis data output by the operation and maintenance analysis model; the prediction tools are used to call the capacity prediction model to perform capacity prediction on the operation and maintenance data in the context data and obtain the prediction data output by the capacity prediction model; and the operation tools are used to execute the operation corresponding to the call parameters through a predefined operation channel and obtain the execution data corresponding to the call parameters.

[0208] After receiving the call parameters, the query tool maps them to the corresponding data source identifier, time range, and filter conditions. Then, it accesses the storage unit or monitoring platform via a predefined data channel to obtain the operational data that matches the call parameters.

[0209] After receiving operational data, analytical tools input the operational data and contextual data into the operational analysis model. This allows the model to calculate at least one of the following: abnormal fluctuations, recurring alarms, or related root causes, and output analytical data. Optionally, the analytical data may include at least one of the following: anomaly labels, alarm aggregation results, or root cause candidates.

[0210] After receiving operation and maintenance data, predictive tools use historical trends, periodic characteristics, and resource usage relationships in the context data to call capacity prediction models and obtain predictive data such as future capacity consumption, threshold approach time, or expansion suggestions.

[0211] After receiving the call parameters, the operation tool converts them into specific operation instructions, target objects, and / or execution constraints to obtain an execution request. Then, it sends the execution request to the target host, cluster, or application control plane through a predefined operation channel, returning execution data such as the execution result, receipt status, or scope of impact.

[0212] Optionally, both the data channel and the operation channel may adopt standardized protocols to reduce the adaptation costs between different operation and maintenance systems; this application does not impose any restrictions on this.

[0213] Query tools, analysis tools, prediction tools, and operational tools each have different responsibilities: data acquisition, model analysis, trend prediction, and action execution. Query tools provide input for subsequent analysis and prediction; analysis tools transform raw operational data into interpretable analytical data; prediction tools output information on future capacity changes; and operational tools complete controlled operational actions and provide feedback on execution data. This allows different target tools in the plan to work collaboratively according to their responsibilities. This division approach enables data querying, intelligent analysis, capacity prediction, and actual handling to be completed within a unified tool framework, forming a complete operational processing chain and facilitating subsequent session responses and status updates.

[0214] In one possible implementation, the operation and maintenance analysis model includes: an anomaly detection model, an alarm noise reduction model, and a root cause analysis model. Specifically: the anomaly detection model uses the Isolation Forest algorithm to perform unsupervised anomaly detection on the input operation and maintenance data, and combines this with a Long Short-Term Memory network to learn normal patterns in time-series metrics, identifying operation and maintenance data that deviates from normal patterns, and obtaining and outputting the corresponding anomaly analysis data; the alarm noise reduction model clusters the anomaly analysis data based on its similarity, obtaining and outputting the corresponding alarm analysis data; and the root cause analysis model locates the root causes of faults corresponding to the anomaly analysis data based on the dependencies in the entity relationship graph of hardware terminal devices, combined with an association rule mining algorithm, obtaining and outputting the corresponding root cause analysis data.

[0215] The anomaly detection model first performs unsupervised identification of operation and maintenance data, and then uses time series learning to constrain the anomaly judgment boundary, so that the output anomaly analysis data can simultaneously reflect outlier characteristics and time series offset characteristics.

[0216] The alarm noise reduction model reduces the repeated output of duplicate anomalies based on similarity clustering, and uses the aggregation results as input for subsequent analysis.

[0217] The root cause analysis model relies on the dependency propagation path in the entity relationship graph to infer the relationship between anomalies and equipment, thereby generating root cause analysis data for handling reference.

[0218] After adopting the above operation and maintenance analysis model, the operation and maintenance data can be processed sequentially through anomaly identification, alarm aggregation and root cause localization. The output results have continuity in expressing abnormal states, merging similar alarms and indicating the source of faults, thereby improving the accuracy, readability and targeted nature of the operation and maintenance analysis results.

[0219] In one possible implementation, the capacity prediction model is used to predict resource usage over a future period using time-series prediction algorithms combined with a deep learning framework of long short-term memory networks, based on operational data within the context data, to obtain a capacity prediction curve; the capacity prediction curve is then output as prediction data.

[0220] Specifically, firstly, resource monitoring records associated with the current operation and maintenance task are extracted from the context data, and missing values, outliers, and discontinuous timestamps are normalized to obtain processed operation and maintenance data. Next, the processed operation and maintenance data is input into a time-series prediction algorithm to generate basic trend prediction results. Simultaneously, the same operation and maintenance data is input into a long short-term memory network to generate compensated prediction results. The two prediction results are then fused to obtain prediction curves for various resource indicators over a future period, which are output as capacity prediction curves.

[0221] When fusing the two prediction results, any method can be used, such as weighted averaging, residual correction, or feature concatenation followed by regression mapping. The capacity prediction curve can generate hourly, daily, or weekly prediction values ​​according to a preset time granularity and map them into a continuous curve form for subsequent use.

[0222] The capacity prediction model combines trend prediction with deep learning time series modeling, enabling resource usage predictions to simultaneously incorporate cyclical fluctuations and long-term dependencies. The results are directly output as capacity prediction curves, facilitating subsequent analysis of resource expansion, load scheduling, or capacity alerts. This approach provides continuous and visually appealing prediction data, allowing operations and maintenance systems to anticipate future resource changes.

[0223] In one possible implementation, a session window is used to persist automatically saved context data.

[0224] The session state persistence component manages the session window. Each time new input content, tool call process, or return result occurs within the session window, the session state of the current session window is automatically extracted and written to persistent storage. The persistent storage medium can be any type of storage, such as a database, key-value store, or file. In practical applications, other storage formats can also be chosen, and this application does not limit this choice. Optionally, the session state persistence component can be a Checkpointer.

[0225] During saving, the session window's session identifier, message sequence, context variables, call chain, and intermediate results are stored together. This allows the session window to reload its previous state and restore its context before the interruption when refreshed, interrupted by network, restarted, or when interaction is initiated again. Correspondingly, the restored session window can continue to use the saved natural language command parsing results, tool call plans, and execution feedback information, ensuring continuity in subsequent interactions.

[0226] Through a persistent automatic saving mechanism, the session window can continuously record the interaction process without requiring manual saving by the user, and enable session state rollback after abnormal interruption. Therefore, the operation and maintenance analysis results, approval request records, and tool return data of the current round can all be retained and retrieved again, supporting continuous intelligent operation and maintenance interactions across multiple rounds. This ensures the recoverability and continuous availability of the session content within the session window, reduces the impact of context loss on the continuity of operation and maintenance processes, and maintains consistency in task orchestration and result tracking across rounds.

[0227] In one possible implementation, before receiving natural language commands input by the user through the session window, the method further includes: collecting multi-source data from hardware terminal devices and software clusters within the system to be maintained and managed using a dual-track architecture to obtain maintenance data; storing the maintenance data in a storage unit, which is equipped with a predefined data channel. The data channel is used to receive call parameters sent by the maintenance tool and return the maintenance data corresponding to the call parameters.

[0228] Specifically, the hardware-side data acquisition path and the software-side data acquisition path can be configured with a data acquisition agent and an event subscriber, respectively. The data acquisition agent periodically reads port status, CPU utilization, memory utilization, connection count, and alarm events; the event subscriber receives log streams and monitoring streams and encapsulates them uniformly.

[0229] Hardware multi-source data from hardware terminal devices is collected through hardware-side agents and event subscribers. Software multi-source data from the software cluster is collected through software-side agents and event subscribers. Then, the hardware and software multi-source data are written to storage units after timestamp alignment, field normalization, and deduplication, enabling continuous tracking of the state changes of the same resource at different points in time.

[0230] The predefined data channel can be implemented using any of the following methods: interface service, message queue subscription port, or query service endpoint.

[0231] When the operation and maintenance tools execute query tools, analysis tools, or prediction tools, they send the resource identifier, indicator type, and query range as call parameters to the data channel. The data channel returns the corresponding operation and maintenance data according to the parameter parsing rules, which serves as the data basis for subsequent intent recognition, tool calls, and session responses.

[0232] By pre-compiling the aggregation and standardized access of operation and maintenance data before receiving natural language commands in the session window, operation and maintenance tools can directly obtain target data through a unified data channel, reducing interface differences between different data sources, and ensuring that subsequent command parsing, tool orchestration, and result return are all based on a consistent data foundation, thereby improving the efficiency of collaborative processing across hardware terminal devices and software clusters.

[0233] One possible implementation involves using a dual-track architecture to collect multi-source data to obtain operation and maintenance data. This includes: using an automatic discovery mechanism to dynamically identify newly added devices within the system to be operated and managed, obtaining multiple hardware terminal devices, and collecting hardware status indicators of the hardware terminal devices in a standard format; automatically discovering resource changes in the software cluster within the system to be operated and managed, and collecting software status indicators of the software cluster in a standard format; and unifying the hardware status indicators and software status indicators into the same data format to obtain operation and maintenance data.

[0234] After entering the operations and maintenance (O&M) platform, hardware-side and software-side data collection results undergo field standardization. Device identifiers, metric names, collection times, metric values, and alarm levels are uniformly mapped to the same data structure. Data from different sources is also encoded, converted, and normalized in units, resulting in O&M data that can be directly accessed by subsequent analysis modules. This approach allows the status information of hardware terminals and software clusters to be expressed under the same data model, sharing a unified data foundation with subsequent tool calls, alarm analysis, and root cause analysis. Consequently, it enables synchronous discovery and collection when new devices or software resources are added, outputting structurally consistent O&M data and improving the consistency and analysability of multi-source data fusion.

[0235] First, the network auto-discovery task of the hardware monitoring core service is initiated, and scanning rules for the specified network segment are configured. By detecting all online hardware devices within the network segment, multiple hardware terminal devices are obtained. Then, based on these multiple hardware terminal devices, a preset device template is automatically matched, and the corresponding acquisition protocol is automatically associated according to the device type of the hardware terminal device to collect the raw status indicators of the hardware terminal devices. Subsequently, the raw status indicators are processed according to the standard format to obtain the hardware status indicators of the hardware terminal devices. Optionally, the standard format is the Prometheus standard format.

[0236] For example, if the hardware terminal device includes a network device, a storage device, and a graphics processing unit (GPU) server. The network device reports indicators such as port traffic, number of error packets, and device temperature via the Simple Network Management Protocol (SNMP); the storage device reports indicators such as disk capacity, input / output operations per second (IOPS), and latency via SNMP and the command line interface (CLI); and the GPU server reports indicators such as GPU utilization, video memory usage, and temperature via the nvidia-smi tool. The indicators received from the different hardware terminals are then organized according to the corresponding standard format to obtain the hardware status indicators of the hardware terminal device.

[0237] Simultaneously, a full-resource detection channel for the cluster is established through the container orchestration platform interface. Resource event callback rules are configured to capture creation, destruction, and scheduling change events of container instances, services, stateless deployments, and stateful sets in real time. This automatically identifies all active software service nodes and component resources within the cluster, resulting in multiple software cluster resource objects. Then, based on these identified software cluster resource objects, preset component collection rules are automatically matched, and the corresponding collection access method is automatically associated according to the type of software resource, collecting the raw operational data of the software cluster resources. Subsequently, the raw operational data is formatted according to the standard format and supplemented with metadata tags from the container orchestration platform to obtain software status indicators for the software cluster.

[0238] For example, if the software cluster resources include microservice applications, container instances, databases, and middleware, then the microservice applications automatically report three types of data—link tracing, business metrics, and runtime logs—through a pre-built observable software development kit (SDK). Container instances collect runtime status data such as container CPU, memory, network input / output (IO), and disk IO through a globally deployed collection agent with zero intrusion. The database exposes performance metrics such as connection count, query latency, and cache hit rate through a dedicated exporter. The middleware reports runtime metrics such as queue backlog and request success rate through Java Management Extensions (JMX) interfaces and a corresponding dedicated exporter. The raw data received from different software resources is then uniformly supplemented with container orchestration platform metadata such as instance tags, namespaces, and node names, and formatted according to the corresponding standard format to obtain the software status metrics of the software cluster.

[0239] Hardware and software status metrics are standardized into the same data format to obtain operation and maintenance data, which is then stored.

[0240] Optionally, a layered architecture combining message queues and multiple storage engines can be used to store operational data. First, operational data is buffered via a distributed message queue, completely decoupling the data production and consumption stages and preventing sudden traffic surges from impacting downstream storage services. Based on predefined data type tags, different categories of operational data are routed to their corresponding dedicated storage engines.

[0241] For example, time-series metric-type operation and maintenance data can be stored in a high-performance time-series database for long-term storage and fast querying; link tracing-type operation and maintenance data can be stored in a distributed tracing system to support the visual backtracking of the entire link call relationship; and log-type operation and maintenance data can be stored in a distributed search engine to achieve fast retrieval and correlation analysis of the full log.

[0242] Figure 4 This is a schematic diagram of the intelligent operation and maintenance management device provided in the embodiments of this application, as shown below. Figure 4 As shown, the intelligent operation and maintenance management device 40 provided in this embodiment includes:

[0243] The interaction module 401 is used to receive natural language commands input by the user through a session window. The natural language commands are used to represent operation and maintenance tasks.

[0244] Processing module 402 is used to perform intent recognition on natural language commands with reference to the context data in the session window, and obtain intent recognition results. If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition results, then based on the intent recognition results and the tool registry, a state diagram is used to perform declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool. Based on the invocation order in the tool invocation plan, the corresponding invocation is performed on the target tool according to the invocation parameters to obtain the execution result corresponding to the tool invocation plan.

[0245] The interaction module 401 is also used to return the execution result and the corresponding natural language response to the user through the session window.

[0246] In one possible implementation, the processing module 402 is specifically used for:

[0247] Based on the intent recognition results, the operation and maintenance tools related to the intent recognition results are matched from the tool registry to obtain at least one target tool to be invoked;

[0248] Based on the intent recognition results, determine the initial state and the target final state in the state diagram;

[0249] Based on the node configuration information pre-declared by each target tool in the tool registry, the state transition path from the initial state to the target final state is derived, and the calling order of the target tools is determined.

[0250] Based on the intent recognition results and context data, the parameters of the target tools are configured according to the parameter definitions pre-declared by each target tool in the tool registry to obtain the calling parameters of the target tools;

[0251] Based on the calling order and parameters of the target tools, the tool calling plan corresponding to the operation and maintenance task is obtained.

[0252] In one possible implementation, a predefined skill workflow template is used to represent a reusable automated workflow. The skill workflow template includes the calling order and calling parameters of multiple target tools to be invoked. If the trigger word in the predefined skill workflow template matches the operation and maintenance intent word in the intent recognition result, the processing module 402 is further used to:

[0253] Based on the matching predefined skill workflow template, the order and parameters of the target tools to be invoked are used to obtain the tool invocation plan corresponding to the operation and maintenance task.

[0254] In one possible implementation, before executing the corresponding call to the target tool based on the call order in the tool call plan and obtaining the execution result corresponding to the tool call plan, the processing module 402 is further configured to:

[0255] Within the tool's registry, the confirmation flag for the target tool is found to be "yes".

[0256] or,

[0257] If the query shows whether the confirmation flag for the target tool is positive or negative, an approval request for the target tool is generated based on the target tool and its calling parameters, and the approval request is sent to the user through the session window.

[0258] Feedback information received regarding the user's approval request.

[0259] In one possible implementation, the processing module 402 is further configured to: if feedback information indicating that the user has refused to approve the request is received, directly determine that the execution result of the operation and maintenance task is: the user has refused to call the target tool.

[0260] In one possible implementation, the processing module 402 is specifically used for:

[0261] Based on the invocation order in the tool invocation plan, the invocation corresponding to the invocation parameters is executed on the target tool, and the data returned by the target tool is used as the invocation result of the target tool.

[0262] Summarize the call results returned by each target tool to obtain the execution results corresponding to the tool call plan.

[0263] In one possible implementation, if the target tool includes query tools, analysis tools, prediction tools, and operational tools, wherein:

[0264] Query tools are used to obtain operation and maintenance data corresponding to the call parameters through predefined data channels;

[0265] Analysis tools are used to call the operation and maintenance analysis model, perform data analysis and processing on the operation and maintenance data within the context data, and obtain the analysis data output by the operation and maintenance analysis model;

[0266] Prediction tools are used to call capacity prediction models, perform capacity prediction on the operation and maintenance data within the context data, and obtain the prediction data output by the capacity prediction model.

[0267] Operational tools are used to execute operations corresponding to call parameters through predefined operation channels and obtain execution data corresponding to the call parameters.

[0268] In one possible implementation, the operation and maintenance analysis model includes: an anomaly detection model, an alarm noise reduction model, and a root cause analysis model, wherein:

[0269] An anomaly detection model is used to perform unsupervised anomaly detection on input operation and maintenance data using the Isolation Forest algorithm. It combines the normal patterns of time series indicators learned by the Long Short-Term Memory Network to identify operation and maintenance data that deviates from the normal patterns, and obtains and outputs the anomaly analysis data corresponding to the operation and maintenance data.

[0270] The alarm noise reduction model is used to cluster anomaly analysis data based on the similarity of the anomaly analysis data, and to obtain and output the alarm analysis data corresponding to the anomaly analysis data.

[0271] The root cause analysis model is used to locate the root causes of failures corresponding to anomaly analysis data by combining the dependency relationships in the entity relationship graph of hardware terminal devices with association rule mining algorithms, and to obtain and output the root cause analysis data of failures corresponding to the anomaly analysis data.

[0272] In one possible implementation, the capacity prediction model is used to predict resource usage over a future period of time using operational data within contextual data, employing a time-series prediction algorithm combined with a deep learning framework of long short-term memory networks, to obtain a capacity prediction curve.

[0273] The capacity prediction curve is output as the prediction data.

[0274] In one possible implementation, a session window is used to persist automatically saved context data.

[0275] In one possible implementation, before receiving natural language commands input by the user through the session window, the acquisition module 403 is used to:

[0276] A dual-track architecture is used to collect multi-source data from hardware terminal devices and software clusters within the system to be maintained and managed, thus obtaining maintenance data.

[0277] The operation and maintenance data is stored in the storage unit, which is equipped with a predefined data channel. The data channel is used to receive the call parameters sent by the operation and maintenance tools and return the operation and maintenance data corresponding to the call parameters.

[0278] In one possible implementation, the acquisition module 403 is specifically used for:

[0279] An automatic discovery mechanism is adopted to dynamically identify new devices in the system that need to be maintained and managed, resulting in multiple hardware terminal devices, and hardware status indicators of the hardware terminal devices are collected in a standard format.

[0280] By automatically detecting resource changes in software clusters within systems under maintenance and management, and collecting software status indicators of the software clusters in a standard format;

[0281] By unifying hardware and software status metrics into the same data format, operational data can be obtained.

[0282] The intelligent operation and maintenance management device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0283] Figure 5 This is a schematic diagram of the structure of the intelligent operation and maintenance management equipment provided in the embodiments of this application. Figure 5 As shown, the intelligent operation and maintenance management device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the intelligent operation and maintenance management device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0284] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0285] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0286] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0287] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0288] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0289] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0290] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0291] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0292] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0293] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0294] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0295] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0296] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0297] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0298] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. An intelligent operation and maintenance management method, characterized in that, include: The system receives natural language commands input by the user through a chat window. These natural language commands are used to represent operation and maintenance tasks. Using the context data within the session window as a reference, the natural language command is subjected to intent recognition to obtain the intent recognition result; If the trigger words in the predefined skill workflow template do not match the operation and maintenance intent words in the intent recognition result, then based on the intent recognition result and the tool registry, a state diagram is used to perform declarative workflow orchestration to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool. Within the tool's registry, a query reveals that the confirmation flag for the target tool is set to "yes". Alternatively, if the confirmation flag corresponding to the target tool is found to be negative, an approval request for the target tool is generated based on the target tool and its calling parameters, and the approval request is sent to the user through a session window. Receive feedback information from the user approving the approval request; Based on the invocation order in the tool invocation plan, the target tool is executed according to the invocation parameters to obtain the execution result corresponding to the tool invocation plan; The execution result and the corresponding natural language response are returned to the user through the session window.

2. The intelligent operation and maintenance management method according to claim 1, characterized in that, Based on the intent recognition results and the tool registry, a declarative workflow orchestration using a state diagram is employed to obtain the tool invocation plan corresponding to the maintenance task, including: Based on the intent recognition result, the operation and maintenance tools related to the intent recognition result are matched from the tool registry to obtain at least one target tool to be invoked; Based on the intent recognition result, the initial state and the target final state in the state diagram are determined; Based on the node configuration information pre-declared by each target tool in the tool registry, the state transition path from the initial state to the target final state is derived, and the invocation order of the target tools is determined. Based on the intent recognition result and the context data, the parameters of the target tools are configured according to the parameter definitions pre-declared by each target tool in the tool registry to obtain the calling parameters of the target tools; Based on the calling order and calling parameters of the target tool, the tool calling plan corresponding to the operation and maintenance task is obtained.

3. The intelligent operation and maintenance management method according to claim 1, characterized in that, A predefined skill workflow template is used to represent a reusable automated workflow. The skill workflow template includes the calling order and calling parameters of multiple target tools to be invoked. If the trigger word in the predefined skill workflow template matches the maintenance intent word in the intent recognition result, the intelligent maintenance management method further includes: Based on the target tool invocation order and invocation parameters within the matched predefined skill workflow template, the tool invocation plan corresponding to the operation and maintenance task is obtained.

4. The intelligent operation and maintenance management method according to claim 1, characterized in that, Also includes: If feedback is received that the user has rejected the approval request, the execution result of the operation and maintenance task is directly determined to be: the user has rejected calling the target tool.

5. The intelligent operation and maintenance management method according to any one of claims 1 to 3, characterized in that, The step of executing the corresponding call to the target tool based on the call order in the tool call plan, and obtaining the execution result corresponding to the tool call plan, includes: Based on the invocation order in the tool invocation plan, the invocation corresponding to the invocation parameters is executed on the target tool, and the data returned by the target tool is used as the invocation result corresponding to the target tool. The execution results corresponding to the tool invocation plan are obtained by summarizing the invocation results returned by each target tool.

6. The intelligent operation and maintenance management method according to claim 5, characterized in that, If the target tools include query tools, analysis tools, prediction tools, and operational tools, then: The query tool is used to obtain the operation and maintenance data corresponding to the call parameters through a predefined data channel; The analysis tool is used to call the operation and maintenance analysis model, perform data analysis and processing on the operation and maintenance data in the context data, and obtain the analysis data output by the operation and maintenance analysis model. The prediction tool is used to call the capacity prediction model to perform capacity prediction on the operation and maintenance data in the context data, and obtain the prediction data output by the capacity prediction model. The operation tool is used to execute the operation corresponding to the call parameter through a predefined operation channel and obtain the execution data corresponding to the call parameter.

7. The intelligent operation and maintenance management method according to claim 6, characterized in that, The operation and maintenance analysis model includes: an anomaly detection model, an alarm noise reduction model, and a root cause analysis model, wherein: The anomaly detection model is used to perform unsupervised anomaly detection on the input operation and maintenance data using the isolated forest algorithm, and to identify the operation and maintenance data that deviates from the normal pattern by combining the learning of time series indicators by the long short-term memory network, thereby obtaining and outputting the anomaly analysis data corresponding to the operation and maintenance data. The alarm noise reduction model is used to cluster the anomaly analysis data based on the similarity of the anomaly analysis data, and to obtain and output the alarm analysis data corresponding to the anomaly analysis data. The root cause analysis model is used to locate the root cause of the fault corresponding to the anomaly analysis data based on the dependency relationship in the entity relationship graph of the hardware terminal device, combined with the association rule mining algorithm, and to obtain and output the root cause analysis data of the fault corresponding to the anomaly analysis data.

8. The intelligent operation and maintenance management method according to claim 6, characterized in that, The capacity prediction model is used to predict resource usage over a future period of time by using the operation and maintenance data within the context data and employing a time-series prediction algorithm combined with a deep learning framework of long short-term memory networks, thereby obtaining a capacity prediction curve. The capacity prediction curve is output as the prediction data.

9. The intelligent operation and maintenance management method according to any one of claims 1 to 3, characterized in that, The session window is used to persist automatically saved context data.

10. The intelligent operation and maintenance management method according to any one of claims 1 to 3, characterized in that, Before receiving natural language commands input by the user through the session window, the method further includes: A dual-track architecture is used to collect multi-source data from hardware terminal devices and software clusters within the system to be maintained and managed, thus obtaining maintenance data. The operation and maintenance data is stored in a storage unit, which is equipped with a predefined data channel. The data channel is used to receive the call parameters sent by the operation and maintenance tool and return the operation and maintenance data corresponding to the call parameters.

11. The intelligent operation and maintenance management method according to claim 10, characterized in that, The dual-track architecture is used to collect multi-source data from the system under maintenance and management, resulting in maintenance data, including: An automatic discovery mechanism is adopted to dynamically identify new devices in the system to be maintained and managed, resulting in multiple hardware terminal devices. The hardware status indicators of the hardware terminal devices are collected in a standard format. By automatically detecting resource changes in software clusters within systems under maintenance and management, and collecting software status indicators of the software clusters in a standard format; The hardware status indicators and the software status indicators are unified into the same data format to obtain the operation and maintenance data.

12. An intelligent operation and maintenance management device, characterized in that, include: An interaction module is used to receive natural language commands input by the user through a session window, wherein the natural language commands are used to represent operation and maintenance tasks; The processing module is used to perform intent recognition on the natural language command with reference to the context data in the session window, and obtain the intent recognition result. If the trigger word in the predefined skill workflow template does not match the operation and maintenance intent word in the intent recognition result, then based on the intent recognition result and the tool registry, a declarative workflow orchestration is performed using a state diagram to obtain the tool invocation plan corresponding to the operation and maintenance task. The tool invocation plan includes at least one target tool to be invoked selected from the operation and maintenance tools in the tool registry, the invocation order of the target tools, and the invocation parameters. The tool registry stores the invocation configuration information of each operation and maintenance tool. In the tool registry, the confirmation flag corresponding to the target tool is found to be "yes". Alternatively, if the confirmation flag corresponding to the target tool is found to be negative, an approval request for the target tool is generated based on the target tool and its calling parameters, and the approval request is sent to the user through a session window. Upon receiving feedback from the user approving the approval request; based on the invocation order in the tool invocation plan, execute the corresponding invocation for the target tool according to the invocation parameters, and obtain the execution result corresponding to the tool invocation plan; The interaction module is also used to return the execution result and the corresponding natural language response to the user through the session window.

13. An intelligent operation and maintenance management device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

Images