Data center automatic operation and maintenance work order processing system

Abstract

The application relates to the technical field of operation and maintenance data processing, and provides a data center automatic operation and maintenance work order processing system, a new system composed of a real-time data stream analysis module, an ontology model management semantic service module, a dynamic knowledge graph management module, a knowledge graph reasoning engine, an LLM collaborative processor, a reasoning decision engine and a knowledge graph evolution engine is developed, autonomous evolution and dynamic optimization of an operation and maintenance knowledge system are realized, the knowledge rigidity problem of a traditional method is fundamentally overcome, a real-time digital mirror image synchronous with a physical data center is established, the timeliness and accuracy of a decision basis are ensured, an interpretable and verifiable decision based on a multi-source evidence chain is generated, a reliable man-machine collaborative trust basis is constructed, and deep correlation reasoning and accurate root cause positioning in a complex fault scenario are realized.

Description

Technical Field

[0001] This invention belongs to the field of operation and maintenance data processing technology, and relates to an automated operation and maintenance work order processing system for data centers. Background Technology

[0002] With the popularization of cloud computing technology, the scale and complexity of modern cloud data centers are growing exponentially. Their infrastructure encompasses computing, storage, networking, virtualization, and various platform services, forming a dynamic, heterogeneous, and interdependent massive data service system. In this environment, the processing of operation and maintenance work orders typically includes fault diagnosis, root cause analysis, and repair execution, which has become a core challenge in ensuring the service level agreements and business continuity of cloud data centers.

[0003] Traditional automated operations and maintenance (O&M) scripts (such as Ansible and Shell) are based on predefined "IF-THEN" rules. While they can handle known scenarios, they lack flexibility and cannot cope with undefined, complex, or cross-system dependent faults. In recent years, two main technological evolution paths have emerged: one is based on static knowledge bases, which document O&M manuals and best practices to form a knowledge base. However, this method suffers from outdated knowledge and cannot be directly understood or reasoned about by machines, relying on manual querying and judgment. The other is based on artificial intelligence, which utilizes the powerful natural language processing capabilities of Large Language Models (LLMs) to directly understand alarm information or work order descriptions and generate handling suggestions. However, these traditional technologies still suffer from low O&M work order processing performance, making them difficult to industrially apply in cloud data center automated O&M scenarios that require extremely high accuracy and reliability. Summary of the Invention

[0004] To address the problems existing in the traditional methods mentioned above, this invention proposes an automated data center operation and maintenance work order processing system, which can achieve high-performance intelligent and automated processing of data center operation and maintenance work orders.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: A data center automated operation and maintenance work order processing system is provided, including: The real-time data stream parsing module is used to perform real-time semantic parsing and semantic mapping on the real-time monitoring data streams of various monitoring systems, and output the real-time status of the data center. The dynamic knowledge graph management module is used to perform creation, editing, real-time synchronization, evolutionary closed-loop update, and traversal query functions of the dynamic knowledge graph based on the ontology model; the key relationship edges of the dynamic knowledge graph have dynamically adjustable weight attributes. The knowledge graph reasoning engine is used to obtain reasoning query results from the knowledge graph through the dynamic knowledge graph management module. The reasoning decision engine is used to perform root cause analysis based on real-time status and reasoning query results from the knowledge graph, and generate root cause fault sequences and corresponding symptom alarm sets. The LLM coprocessor is used to generate a natural language work order handling solution by using facts, root cause fault sequences and corresponding symptom alarm sets provided by the dynamic knowledge graph management module as knowledge-driven and performing LLM reasoning according to semantic reasoning rules. The knowledge graph evolution engine is used to update the dynamic knowledge graph based on the feedback of the handling effect of the work order handling plan; The ontology model management semantic service module provides semantic specifications for the real-time data stream parsing module during semantic parsing and semantic mapping, and provides semantic reasoning rules for the knowledge graph reasoning engine and LLM coprocessor.

[0006] In one embodiment, the class definition of the ontology model includes resource entity class, state event class, causal relationship class and operation and maintenance activity class, and the relationship of the ontology model includes real-time state relationship, causal topology relationship, fault handling relationship and feedback relationship after fault handling is completed.

[0007] In one embodiment, the status event class includes health status, indicators, status assertions, symptoms, alarms, and faults; The key information carried by each instance of a causal assertion in the causal association class includes at least one symptom entity or alarm entity associated with the assertion as the effect of the assertion through the assertion's performance relationship, a fault entity associated with the assertion as the cause of the assertion through the assertion's cause relationship, confidence attribute, contribution attribute, and evidence attribute. Operation and maintenance activities include work orders, processing actions, processing procedures, handling solutions, and experience cases.

[0008] In one embodiment, the real-time state relationship includes possessing an indicator, the indicator being associated with, determining the state, and triggering. Causal topological relationships include originating from, located in, deployed in, dependent on, and connected to; Fault handling relationships include inclusion, composition, being handled by the solution, and execution.

[0009] In one embodiment, the feedback relationships after fault handling are completed include generation, used for handling, verification, occurrence, suggested modification actions, confirmation of cause and effect, and generation of new solutions.

[0010] In one embodiment, the creation and editing functions of the dynamic knowledge graph include: Create entity nodes representing specific resources in the cloud data center based on the ontology model; Based on the real-time topology and monitored status, create or update relationship instances between entities; The provided interactive interface allows operations and maintenance experts to input validated solutions and case studies into the dynamic knowledge graph.

[0011] In one embodiment, the evolutionary closed-loop update function includes: Based on the cases and causal assertions generated after the execution of the work order handling plan, the dynamic weight attributes of key relationships in the dynamic knowledge graph are automatically and incrementally updated. When a new treatment plan is verified to be effective or a new causal relationship is confirmed, new treatment plan nodes, causal assertion nodes, and corresponding relationships are created in the dynamic knowledge graph.

[0012] In one embodiment, the LLM coprocessor includes: The semantic parsing and information extraction submodule is used to guide the LLM to accurately anchor natural language input to the semantic space of the ontology model using semantic prompt word templates; The context-enhanced reasoning and decision support submodule is used to obtain real-time contextual evidence that is highly relevant to the current problem from the dynamic knowledge graph, and then use decision prompt word templates to reason, summarize and generate natural language explanations.

[0013] In one embodiment, the ontology model is formally defined as Φ: Φ =<C, R, A, W> Where C is a set of classes; R C×C is a set of binary relations on C; A is a set of attributes assigned to each class c∈C, and W is a set of attributes assigned to each relation r∈R.

[0014] In one embodiment, the formal definition of a dynamic knowledge graph is: Directed graph<V,E,ρ,ω> Where V is a set of nodes, and each node v∈V represents an entity, E V×R×V is the set of edges, and each edge has an edge e= <v s ,r,v t > Represents entity v s With entity v t There exists a relation r∈R, where ρ is the node attribute function and ω is the edge attribute function.

[0015] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned automated data center operation and maintenance work order processing system, through the development of a new system comprised of a real-time data stream parsing module, an ontology model management semantic service module, a dynamic knowledge graph management module, a knowledge graph reasoning engine, an LLM coprocessor, a reasoning decision engine, and a knowledge graph evolution engine, addresses the fundamental shortcomings of existing cloud data center operation and maintenance solutions based on static knowledge graphs and large language models. It forms a framework for automatically generating root cause analysis and handling solutions based on real-time perception of dynamic knowledge graphs and ontology models, achieving autonomous evolution and dynamic optimization of the operation and maintenance knowledge system. This fundamentally overcomes the knowledge rigidity problem of traditional methods, establishes a real-time digital mirror synchronized with the physical data center, ensuring the timeliness and accuracy of decision-making; generates interpretable and verifiable decisions based on multi-source evidence chains; constructs a reliable human-machine collaborative trust foundation; and realizes deep correlation reasoning and accurate root cause localization in complex fault scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the module structure of a data center automated operation and maintenance work order processing system in one embodiment. Figure 2 This is a schematic diagram of the module structure of an LLM coprocessor in one embodiment. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention.

[0019] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0020] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0021] In this field, existing traditional solutions, such as intelligent operation and maintenance work order processing systems based on LLM, have the following core architecture and workflow: The system architecture mainly includes a monitoring system, a work order system, a centralized Large Language Model (LLM) service, and a predefined knowledge graph. This knowledge graph typically contains relatively static, prior domain knowledge such as device topology, historical fault cases, and emergency plans. The system workflow is as follows: Input: When the monitoring system generates an alarm or a maintenance work order is manually created, the system inputs the natural language description of the alarm / work order, along with relevant background information retrieved from the static knowledge graph, as enhanced prompt words into the LLM.

[0022] Processing: LLM integrates general knowledge internalized from enhanced prompt words with historical experience gained from static knowledge graphs to understand the current problem and generate disposal suggestions.

[0023] Output: A text-based suggestion (or action steps) generated by LLM. For example, for high CPU usage, the suggestion might be: "According to the knowledge base, this service previously experienced a surge in CPU usage due to a memory leak. It is recommended to check the relevant logs; consider using the top command to investigate the process." However, practical applications have revealed that the aforementioned LLM-based intelligent operation and maintenance work order processing system suffers from the following fundamental flaws, making it difficult to achieve reliable and autonomous operation and maintenance in real and dynamically changing cloud data center environments: The disconnect between static knowledge graphs and dynamic environments leads to distorted decision-making: In existing systems, knowledge graphs are essentially static and offline knowledge bases. Their content cannot be synchronized with the real-time operational status of the data center. While they may contain historical device topologies and contingency plans, they cannot perceive or integrate the current and recent real-world conditions (such as real-time resource utilization, instantaneous service dependencies, and dynamically changing network traffic). Therefore, LLM is essentially generating suggestions based on outdated maps, and the timeliness and accuracy of its decisions cannot be guaranteed at the outset.

[0024] The lack of a closed-loop learning mechanism hinders the evolution of the operations and maintenance (O&M) knowledge system. Existing solutions exhibit typical "open-loop" characteristics because the actual execution effectiveness of work order handling solutions (such as success rate, execution time, and impact on business) cannot be systematically collected, evaluated, and incorporated into the knowledge graph as valuable feedback data. This prevents the system from extracting experience from successes and learning lessons from failures. Each fault handling process starts from scratch, and the O&M knowledge system cannot automatically grow and optimize with O&M practice, severely restricting the continuous improvement of the system's troubleshooting capabilities.

[0025] Static knowledge graphs cannot provide accurate real-time digital images, leading to inaccurate decision-making. While existing solutions introduce static knowledge graphs as factual data sources, these graphs cannot timely and accurately map the factual digital image of a specific data center. They may contain static attributes such as device models, but lack a depiction of the system's real-time operating status (such as rapidly changing resource load, service dependencies, and network topology). Therefore, recommendations generated by LLM based on outdated snapshots are essentially using a historical knowledge framework to address the specific state of the current data center, easily creating illusions that do not match real-time conditions. For example, it may overlook that a service has been migrated to a new host due to load balancing, thus performing invalid operations on the old instance. In operation and maintenance scenarios requiring extremely high accuracy, this disconnect between decision-making and real-time facts is fatal and directly leads to a lack of trust in the system's output by operations personnel.

[0026] Lack of a computable reasoning foundation based on real-time state: When faced with complex failures, effective root cause analysis requires structured, computable reasoning based on real-time state data from the data center. Existing solutions combining LLM and static knowledge graphs lack a formal ontology model to precisely define the relationships between metrics, states, and resources. Therefore, they cannot transform real-time monitoring data (e.g., "database CPU utilization 95%" and "application response time spikes") into structured logical facts that can be directly processed by the rule engine. Their reasoning process is more like pattern matching based on historical text than logical deduction based on current facts, resulting in weak capabilities when handling complex failures involving multiple components and cross-domain issues.

[0027] In summary, the above research found that the core problem with existing solutions lies in the static nature of their knowledge base and the open-loop nature of their system architecture. They cannot build and maintain a digital twin that evolves synchronously with the real data center, thus making it difficult to ensure the accuracy, timeliness, and reliability of their operational decisions. These shortcomings severely restrict their industrial application in the field of automated operation and maintenance of cloud data centers, which requires extremely high accuracy and reliability.

[0028] To address the core shortcomings of existing solutions, such as the disconnect between static knowledge graphs and real-time operation and maintenance environments, and the lack of autonomous evolution capabilities, this invention will provide an automated operation and maintenance work order processing solution for cloud data centers based on ontology models and dynamic knowledge graphs. Its core lies in building an operation and maintenance cognitive center that is perceptive in real time, makes reliable decisions, and evolves autonomously, thereby realizing a paradigm shift from passive response to proactive perception, decision-making, and learning.

[0029] In one embodiment, such as Figure 1 As shown, a data center automated operation and maintenance work order processing system 100 is provided, including a real-time data stream parsing module 11, an ontology model management semantic service module 12, a dynamic knowledge graph management module 13, a knowledge graph inference engine 14, an LLM coprocessor 15, an inference decision engine 16, and a knowledge graph evolution engine 17. The real-time data stream parsing module 11 is used to perform real-time semantic parsing and semantic mapping on the real-time monitoring data streams of various monitoring systems, outputting the real-time status of the data center. The dynamic knowledge graph management module 13 is used to execute the creation and editing functions, real-time synchronization functions, evolutionary closed-loop update functions, and traversal query functions of the dynamic knowledge graph based on the ontology model; the key relationship edges of the dynamic knowledge graph have dynamically adjustable weight attributes.

[0030] The knowledge graph reasoning engine 14 is used to obtain reasoning query results from the knowledge graph through the dynamic knowledge graph management module. The reasoning decision engine 16 is used to perform root cause analysis based on real-time status and the reasoning query results from the knowledge graph, generating root cause fault sequences and corresponding symptom alarm sets. The LLM coprocessor 15 uses the facts, root cause fault sequences, and corresponding symptom alarm sets provided by the dynamic knowledge graph management module as knowledge drivers, and generates natural language work order handling solutions after performing LLM reasoning according to semantic reasoning rules. The knowledge graph evolution engine 17 updates the dynamic knowledge graph based on the feedback of the work order handling solution's handling effect. The ontology model management semantic service module 12 provides the semantic specifications required for semantic parsing and semantic mapping for the real-time data stream parsing module, and provides semantic reasoning rules for the knowledge graph reasoning engine and the LLM coprocessor.

[0031] The core objective of this embodiment is to construct an intelligent data center automated operation and maintenance work order processing system. This system uses a dynamic knowledge graph as its evolutionary core and an ontology model as its real-time perception and inference engine. Within the system, the ontology model provides a formalized, unified conceptual framework for the data center's physical and logical resources, monitoring indicators, and their interrelationships. It is responsible for semantic parsing and state judgment of real-time data streams, serving as the cornerstone for the system's current situation perception. The dynamic knowledge graph, under the specifications of the ontology model, not only stores static domain knowledge but, more importantly, continuously integrates entity states extracted from real-time monitoring data and handling experience fed back from historical work order execution results. This forms a digital twin that evolves synchronously with the physical data center, continuously accumulating operational wisdom. The entire system constitutes an autonomous closed loop of perception-decision-execution-learning. It makes decisions based on the current state of the dynamic knowledge graph and feeds back the execution results to the dynamic knowledge graph for autonomous evolution, ultimately achieving intelligent and automated processing of operation and maintenance work orders.

[0032] Specifically, this embodiment uses a predefined ontology model to perform real-time parsing and semantic mapping of real-time monitoring data streams from various existing monitoring systems. This transforms raw, discrete monitoring indicators into entities, attributes, and relationships with clear semantics within a knowledge graph. This enables the system to continuously and accurately build and update a dynamic digital image of the data center, providing millisecond-level freshness of situational awareness for subsequent decision-making. It fundamentally solves the problem of the disconnect between static knowledge graphs and real-time status, thereby establishing an operational situational awareness capability driven by real-time data.

[0033] To construct a complete closed loop from decision-making to feedback, the system in this embodiment not only generates disposal plans based on dynamic knowledge graphs, but more importantly, it structurally feeds back and integrates the actual execution effects of the plans (such as success rate, execution time, and resource impact) into the knowledge graph. Through this mechanism, the knowledge graph is no longer a static knowledge base, but a "living" system that can continuously learn, evaluate, and optimize from every operation and maintenance practice. This allows the quality and usability of its knowledge base to continuously evolve with operation and maintenance practices, realizing closed-loop verification of operation and maintenance decisions and dynamic evolution of the knowledge system.

[0034] To generate explainable decisions rooted in the evidence chain of a dynamic knowledge graph, each work order processing suggestion is not generated in a "black box" by the LLM, but rather stems from the correlation analysis and logical reasoning of the current entity state (e.g., "CPU load of server A > 95%)", historical related cases (e.g., "similar situations were resolved by restarting service B") and established rules (e.g., "an alarm is triggered when CPU load > 95%" defined in the ontology model). This provides operations engineers with a clear path to trace the source of decisions, thereby establishing a high degree of trust in the automated system and achieving the technical goal of providing traceable and verifiable automated decision-making basis to build human-machine trust.

[0035] Furthermore, it leverages the complex constraints between concepts defined by the ontology model (such as "dependency" and "deployed in"), combined with the real-time association query capabilities of the dynamic knowledge graph, to provide a structured global reasoning framework for complex faults. When multiple monitoring indicators are abnormal at the same time, the system can simulate expert thinking and perform multi-hop reasoning along relational paths in the dynamic knowledge graph to accurately locate the root cause of faults across components and levels, rather than providing isolated and superficial handling suggestions, thereby enabling the location of complex fault root causes based on global association analysis.

[0036] The system's hierarchical architecture is as follows: Figure 2 As shown, the system can be divided into a knowledge base layer and a decision layer. The knowledge base layer implements functions including a real-time data stream parsing module 11, an ontology model management semantic service module 12, a dynamic knowledge graph management module 13, and a knowledge graph inference engine 14. The decision layer implements functions including a knowledge-driven LLM coprocessor 15, an inference decision engine 16, and a knowledge graph evolution engine 17. The knowledge base layer and the decision layer work together to achieve an autonomous closed loop of perception-decision-execution-learning. The real-time data stream parsing module refers to the data parsing performed on the real-time monitoring data stream.

[0037] The aforementioned automated data center operation and maintenance work order processing system 100, through the development of a new system consisting of a real-time data stream parsing module 11, an ontology model management semantic service module 12, a dynamic knowledge graph management module 13, a knowledge graph reasoning engine 14, an LLM coprocessor 15, a reasoning decision engine 16, and a knowledge graph evolution engine 17, addresses the fundamental deficiencies of existing cloud data center operation and maintenance solutions based on static knowledge graphs and large language models (LLM). It forms a framework for automatically generating root cause analysis and handling solutions based on real-time perception of dynamic knowledge graphs and ontology models, achieving autonomous evolution and dynamic optimization of the operation and maintenance knowledge system. This fundamentally overcomes the knowledge rigidity problem of traditional methods, establishes a real-time digital mirror synchronized with the physical data center, ensuring the timeliness and accuracy of decision-making; generates interpretable and verifiable decisions based on multi-source evidence chains; constructs a reliable human-machine collaborative trust foundation; and realizes deep correlation reasoning and accurate root cause localization in complex fault scenarios.

[0038] In one embodiment, the class definition of the ontology model includes resource entity classes, state event classes, causal relationship classes, and operation and maintenance activity classes, and the relationships of the ontology model include real-time state relationships, causal topology relationships, fault handling relationships, and feedback relationships after fault handling is completed.

[0039] Furthermore, the status event class includes health status, indicators, status assertions, symptoms, alarms, and faults. In the causal relationship class, each instance of a causal assertion carries key information including at least one symptom entity or alarm entity associated with the assertion's performance relationship as the effect of the assertion, a fault entity associated with the assertion's cause relationship as the cause of the assertion, confidence attributes, contribution attributes, and evidence attributes. The operations and maintenance activity class includes work orders, processing actions, processing flows, handling plans, and experience cases.

[0040] As can be understood, the specific details of the ontology model management semantic service module are as follows: As a unified semantic model for all concepts, attributes, and relationships in the field of cloud data center operation and maintenance, the ontology model in this embodiment is the semantic core of the entire system and the cognitive foundation for real-time perception. It is the blueprint for building a dynamic knowledge graph, providing semantic information for the reasoning decision engine, and providing unified and formalized semantic specifications for real-time data stream parsing, instantaneous judgment of device health status, and continuous evolution of the dynamic knowledge graph.

[0041] Specifically, the class definitions in the ontology model aim to accurately depict the static assets, dynamic states, and operational activities of the data center. Class definitions can be divided into the following four categories: (1) Resource entity class: such as, but not limited to, device, service, etc.

[0042] (2) Status event class: such as but not limited to health status, metric, status assertion, symptom, alarm and fault, etc.; among them, alarm is a subclass of symptom, status assertion is used to record a specific metric for a specific resource at a specific time, and the system makes a specific status judgment based on semantic reasoning rules.

[0043] (3) Causal Association Class (for root cause analysis of failures): To handle complex diagnostic scenarios with multiple symptoms and multiple root causes, this embodiment introduces the core entity class Causal Assertion. A causal assertion is a clear statement or assertion of a causal relationship, that is, asserting that a certain event or factor (cause) caused another event or result. Each instance of a causal assertion should carry the following key information to record the complete diagnostic context: at least one symptom entity or alarm entity is associated with the assertion as the "effect" of the assertion through the assertions Manifest relationship; a failure entity is associated with the assertion as the "cause" of the assertion through the assertions Cause relationship; confidence attribute; contribution attribute: indicating the percentage of contribution of the "cause" to the occurrence of the "manifestation". It should be noted that the same "manifestation" can be caused by multiple "causes"; evidence attribute: explanatory textual description of the causal assertion.

[0044] (4) Operation and maintenance activities: such as, but not limited to, tickets, actions, processes, solutions, and cases.

[0045] The design of relations in ontology models focuses on describing real-time states, tracking fault propagation, and recording handling effectiveness. Therefore, relations in ontology models can be divided into the following four categories: (1) Real-time status relationships can include having metrics, metric related to, judgment status, and triggers. For example, having a metric: Device|Service → Metric, and its inverse relationship is used to map the metric data stream to resources. Metric related to: Metric → Status assertion. Judging status: Status assertion → Health status; where metric related to and judge status are used to judge the health status in real time according to rules. Triggers: Health status → Symptoms|Alarms|Faults.

[0046] (2) Causal topology (fault propagation) relationships can include cause-by, location-on, deployment-on, dependent-on, and connected-to. For example, cause-by: symptoms|alarms|faults → faults|devices|services, used for root cause analysis; located-on: symptoms|alarms|faults → devices|services, which is key to fault location; deployed-on: services → devices, which is key to fault location and propagation; depends-on: services → services|devices, which is key to fault propagation; connected-to: devices → devices, which is key to fault propagation.

[0047] (3) Fault handling relationships can include inclusion, composition, handling by solution, and execution. For example, inclusion (contains): handling solution → handling process, a solution can contain at least one optional or parallel process; composition (composed Of): handling process → handling action, used to define the process as an ordered set of operation instructions; handling by solution (handled By Solution): fault → handling solution, dynamic attributes successCount (number of successful handlings), failure Count (number of failures), and confidence (confidence level) can be assigned to this relationship; execution (executes): work order → handling solution.

[0048] (4) Feedback relationships after fault handling is completed. These feedback relationships collaboratively refine one-time work order execution into structured operational experience for evaluating and optimizing solutions, which is key to supporting continuous system learning and optimization. Furthermore, these feedback relationships include generation, already used for processing, verification, occurrence, suggested modification actions, confirmation of cause and effect, and generation of new solutions. Specific examples include: Generates: Work Order → Experience Case, where the inverse relation of generates is generatedBy (generated from [ ]): Experience Case → Work Order.

[0049] Used for: Case Studies → Faults | Symptoms | Alarms.

[0050] Validates: Experience cases → Solutions. Experience cases can validate solutions from both positive (experience) and negative (lessons learned) perspectives. The number of successful solutions, the number of failures, and the confidence level are recorded in this relationship. This is one of the core mechanisms for dynamic evolution of the dynamic knowledge graph in this invention. The more successful cases that validate a solution, the higher its confidence level; conversely, failed cases will lower its confidence level. The inverse relationship of validation is validated By (validated by [ ]): Solution → Experience cases.

[0051] "Occurred On": Causal Assertion → Device | Service, used to trace the location of historical failures. The inverse relationship of "Occurred On" is "had Occurrence": Device | Service → Causal Assertion.

[0052] Suggestions for Modification For: Case Studies → Solution. This indicates that the case study explicitly points out that the solution needs to be modified. The attributes recorded in this relationship specify which actions in the solution require what kind of modification, such as "delete," "replace with a new action," or "adjust the order of actions."

[0053] Confirms Cause: Experience case → Causal assertion, indicating that the experience case confirms (the confirmation attribute of the relation is true) or disproves (the confirmation attribute of the relation is false) the causal relationship of a certain fault-symptom in the dynamic knowledge graph.

[0054] Generates New Solutions: Case Studies → Disposal Plans. When a successful disposal practice cannot be categorized into any existing solutions, the case study can serve as a blueprint to incubate a completely new disposal plan. This endows the dynamic knowledge graph in this invention with creativity and scalability, rather than merely optimization.

[0055] Supported by the above ontology model, the dynamic knowledge graph of this invention contains two levels of causal knowledge: (1) General causal layer (implemented by cause By relation): encapsulates universal and possible causal relationships in the operation and maintenance domain, forming a complete fault hypothesis space, which is the blueprint for the system to perform initial root cause reasoning. (2) Specific evidence layer (implemented by Causal Assertion entity): encapsulates specific causal relationship instances that are verified to be valid in each specific operation and maintenance practice.

[0056] The innovation of the above design lies in the fact that the specific evidence layer continuously and automatically adjusts and optimizes the prior knowledge of the general causal layer through quantitative feedback (such as confidence and contribution). This allows the dynamic knowledge graph to evolve from a static knowledge base into a cognitive system that can continuously learn from practical experience, connecting the post-event verification in operation and maintenance practice with the prior assumptions in the dynamic knowledge graph, forming a hypothetical-verification-adjustment learning loop. The system no longer mechanically matches symptoms, but reasons based on causal models that are constantly strengthened or weakened by evidence, making the root cause location increasingly accurate. For example, the general relationship "[slow disk I / O] -- <caused By> --> [insufficient memory]" may have a low initial confidence. However, when causal assertions in a large number of cases confirm this relationship, its confidence will significantly increase. In the future, when the system encounters "slow disk I / O" again, it will prioritize "insufficient memory" as the cause.

[0057] The formal definition of the ontology model (Φ) is: Φ =<C, R, A, W> Where: C is the set of the above classes; R C×C is a set of binary relations on C; A is a set of attributes assigned to each class c∈C, for example, A(Metric)={metricID, current Value, timestamp, threshold}, to support real-time monitoring and rule judgment; where current Value is the current value, timestamp is the timestamp, and threshold is the threshold. W is a set of attributes assigned to each relation r∈R (can be empty).

[0058] To achieve knowledge evolution, this embodiment assigns quantifiable operational efficiency attributes to important relationships. For example, the `causedBy` relationship is assigned a `confidence` attribute, which dynamically adjusts based on the number of successful root cause analyses. The `handledBy Solution` relationship is assigned `successCount`, `failureCount`, and `lastExecutionEffect` attributes, whose values ​​are updated immediately after a work order is executed, directly driving the dynamic evolution of the knowledge graph.

[0059] The functions of the ontology model management semantic service module 12 are summarized as follows: It provides a graphical interface for operation and maintenance experts to define and maintain the above ontology model, and provides real-time data stream semantic parsing services to the outside world through the real-time data stream parsing module 11. This service provides semantic parsing based on the ontology model for the incoming monitoring data stream, thereby realizing the instant transformation of raw data (such as "SVR-01 CPU 95%") into entities and relationships in a dynamic knowledge graph (such as "[Device:SVR-01]--〈Own Indicator〉-->[Indicator:CPU Utilization](Current Value=95)"); SVR-01 represents one of the devices in the cloud data center, such as a server.

[0060] In one embodiment, the dynamic knowledge graph management module and the knowledge graph inference engine are described as follows: The dynamic knowledge graph is the dynamic intelligent core of the system. It is not only an instantiation of the ontology model, but also a living digital twin that evolves synchronously with the physical cloud data center and continuously accumulates operational wisdom. By integrating real-time monitoring data and historical processing experience, the dynamic knowledge graph constitutes the sole source of facts and the knowledge graph inference engine for the system's automated decision-making.

[0061] The formal definition of a dynamic knowledge graph (G) is: G is a directed graph.<V,E,ρ,ω> , where: V is a set of nodes, each node v∈V represents an entity, its node type type(v)∈C, and v is the specific attribute value of each attribute of type(v) specified in the ontology model. E V×R×V is the set of edges, and each edge has an edge e= <v s ,r,v t > Represents entity v s With entity v t There exists a relationship r∈R. ρ is a node attribute function that assigns a value to each node and its attribute name, for example, ρ(v,currentValue)=95.

[0062] ω is an edge attribute function that assigns a value to each edge and its attribute name. To achieve dynamic evolution, this embodiment assigns dynamically adjustable weight attributes to key relationship edges (e.g., edges caused by cause By, handled by solution), such as ω(e,confidence)=0.90, ω(e,successCount)=10, etc.

[0063] The functionalities of the dynamic knowledge graph management module and the knowledge graph reasoning engine are summarized as follows: The graph creation and editing functions provide the ability to create and edit instance data in a dynamic knowledge graph, strictly adhering to the semantic specifications and constraints defined by the ontology model management semantic service module. Specifically, the graph creation and editing functions may include: Initialization instance: This involves creating entity nodes (e.g., device: Server-01) and status nodes (e.g., health status: abnormal) that represent specific resources in the cloud data center based on the ontology model.

[0064] Maintaining instance relationships: This involves creating or updating relationship instances between entities based on the real-time topology and monitored status (e.g., [Device: Server-01] -- <Deployed on> --> [Device: Rack-A]), where Rack is a rack / cabinet.

[0065] Human knowledge input: Through the provided interactive interface, operation and maintenance experts are allowed to input verified handling solutions and experience cases into the dynamic knowledge graph as the initial seeds for the system's self-learning.

[0066] The graph's real-time synchronization function receives data streams from the aforementioned real-time data stream parsing module and updates the attribute values ​​of corresponding entities (such as metrics and health status) in the dynamic knowledge graph in real time, ensuring that the dynamic knowledge graph is an accurate mirror of the current state of the cloud data center.

[0067] The evolutionary closed-loop update function of the graph: (1) Dynamic weight adjustment, that is, based on the cases and causal assertions generated after the execution of the work order handling plan, the dynamic weight attributes (such as confidence, successCount, failureCount, etc.) of key relationships (such as handled By Solution, caused By, etc.) in the dynamic knowledge graph are automatically and incrementally updated. For example, a successful fault handling will immediately strengthen the confidence of the corresponding solution relationship. (2) Structural evolution, that is, when a new handling plan is verified to be effective, or a new causal relationship is confirmed, new handling plan nodes, causal assertion nodes and corresponding relationships are created in the dynamic knowledge graph, thereby realizing the structural growth of the knowledge system.

[0068] The graph traversal query function provides a high-performance graph traversal interface to support complex reasoning queries, such as: "Given a set of currently active symptoms, find the fault node with the highest confidence and return its highest confidence solution."

[0069] In one embodiment, the LLM coprocessor is knowledge-driven, not using traditional LLM in isolation, but rather as a core component within the overall cognitive framework for processing unstructured text, performing semantic association, and generating natural language. Through strict contextual constraints and output specifications, the LLM coprocessor combines the generalization capabilities of LLM with the structured knowledge of dynamic knowledge graphs, ensuring the accuracy, interpretability, and operability of its output.

[0070] Furthermore, such as Figure 2 As shown, the LLM coprocessor can include the following two sub-modules: a semantic parsing and information extraction sub-module, and a context-enhanced reasoning and decision support sub-module. The semantic parsing and information extraction sub-module is used to accurately anchor natural language input into the semantic space defined by the aforementioned ontology model.

[0071] Specifically, the semantic parsing and information extraction submodule is designed to use carefully crafted semantic prompt word templates to guide the LLM in extracting structured information from input alarm messages or natural language work order descriptions and directly mapping it to concepts (entity classes) in the ontology model. Examples of semantic prompt word templates include, but are not limited to: "Your current role is a cloud data center operations expert. Please extract information from the text strictly according to the following ontology model concepts:" Devices: such as servers, switches, and storage devices.

[0072] Services: such as API gateways, authentication services, and database services.

[0073] Symptoms or alerts include 'high latency', 'CPU usage exceeding 95%', or 'connection timeout'.

[0074] Please identify instances of the above concepts from the following text and output them in the specified JSON format, ensuring that the entity names are normalized.

[0075] Input text: {input_text}; Output format: {"devices": list of devices, "services": list of services, "symptoms": list of symptoms}. By utilizing the design of semantic parsing and information extraction submodules, it is effectively ensured that the output of LLM can be seamlessly integrated with entities in the dynamic knowledge graph, providing standardized input for subsequent graph querying and reasoning.

[0076] The context-enhanced reasoning decision support submodule is the core of the collaboration between LLM and dynamic knowledge graph. It is used to solve the "illusion" problem of LLM and provide decision support with transparent and visible reasoning chains and reasoning basis located within the dynamic knowledge graph.

[0077] Specifically, the context-enhanced reasoning decision support submodule receives requests from the reasoning decision engine containing real-time contextual evidence highly relevant to the current problem, retrieved from a dynamic knowledge graph. Based on this solid evidence (real-time contextual evidence), the LLM uses configured decision prompt templates to reason, summarize, and generate natural language explanations. Examples of decision prompt templates include, but are not limited to: "Your current role is a cloud data center operations expert. Please answer the question based on the following solid evidence (from a dynamic knowledge graph)."

[0078] Question: {From a query request submitted by the user}; Relevant evidence includes topological relationships such as {service} being deployed on {device} and depending on {(another service)service}; real-time status such as {metric} having a current value of {value} and a status of {health status}; current symptoms such as {device} having CPU usage exceeding {value}; and historical cases (examples) such as the solution {solution} succeeding {successCount} times in {successCount+failureCount} trials, with a confidence level of {confidence}).

[0079] Please answer the questions based on the above evidence, and clearly indicate which pieces of evidence were primarily used to arrive at the current character's conclusion. Avoid using information not mentioned in the relevant evidence.

[0080] By leveraging the context-enhanced reasoning decision support submodule, the LLM's reasoning process is made transparent and evidence-based, and its output work order handling solutions are built on a dynamic knowledge graph as the sole source of fact, thereby greatly improving the credibility of the results.

[0081] The inference decision engine can execute the root cause analysis algorithm based on real-time state and multi-source evidence fusion, as shown below. The input data for the root cause analysis algorithm based on real-time state and multi-source evidence fusion includes: Input events: Natural language description of alarm messages or symptoms; Number N of the most likely root cause faults.

[0082] The output data of the root cause analysis algorithm based on real-time state and multi-source evidence fusion includes: The root cause fault sequence RC_seq, and the symptom alarm set corresponding to each fault in the root cause fault sequence, i.e. f ∈RC_seq, using F_to_S_map( f ) indicates a fault f The resulting symptom alerts.

[0083] The processing steps of a root cause analysis algorithm based on real-time state and multi-source evidence fusion may include: (1) Natural language understanding and information extraction; Specifically, first fill the semantic prompt word template "Template-1: Information Extraction" based on the above ontology model, and then call the "Semantic parsing and information extraction submodule" to extract the device list (denoted as D), service list (S) and symptom alarm list (denoted as P) from the input event.

[0084] (2) Knowledge graph context retrieval; call the dynamic knowledge graph management module and knowledge graph reasoning engine to perform traversal query in the dynamic knowledge graph that reflects the current real-time status of the cloud data center, and obtain the maximum subgraph of the graph related to the device list D, service list S and symptom alarm P (called the "evidence subgraph", denoted as C_kg).

[0085] The node set V and edge set E of the maximal subgraph can be calculated as follows: Initially, the node set V = D∪S∪P and the edge set E = Ø (empty set).

[0086] Recursively execute: If node v1∈V, edge e=<v1,r,v2> If node v2 is an edge in the entire graph and edge e belongs to at least one of the following relationships: causal reasoning (e.g., caused By, asserts Manifest, and asserts Cause), resource topology (e.g., located At, deployed On, and connect To), service dependency (e.g., depends On), real-time status (e.g., has Metric and indicates Status), disposal (e.g., handled By Solution), and feedback (e.g., occurred On and validated By), then node v2 and edge e are added to node set V and edge set E, respectively. Here, connect To indicates a connection to a given point, and indicate Status indicates a symptom.

[0087] In the process of constructing the maximal subgraph of the graph, the real-time state attributes corresponding to the nodes are injected into the nodes in the maximal subgraph, and the current dynamic confidence attributes are carried on the causal reasoning relationship edges to which the nodes belong.

[0088] Clearly, the maximal subgraph of the graph contains known fault-symptom causal knowledge related to symptom alarm P, the current cloud data center's actual asset topology related to the backup list D and service list S, the real-time status of the assets, and lessons learned from historical operations and maintenance activities.

[0089] (3) Root cause generation; specifically including the following processes: For each symptom or alarm in symptom alarm P, the fault is reachable via a causal reasoning relationship (such as caused By). f Perform comprehensive confidence level and symptom alarm set calculation. First, calculate the fault... f The confidence level of the causal evidence is:

[0090] Among them, Paths( p → f ) indicates the progression from symptom p to fault. f The set of causal paths, where g is a normalization function (e.g., but not limited to the Softmax function).

[0091] Then, calculate the fault. f Confidence level of real-time state evidence:

[0092] in, E state ( f The meaning of ) is: related to faults. f The percentage of currently unhealthy resources among the associated resources. R 0( f ) indicates a fault f A collection of resource entities (e.g., devices and services) associated through topological relationships (e.g., located At, deployed On, etc.), Health ( r 0) is a resource r 0 represents the current health status (provided by the real-time monitoring data stream), while UNHEALTHY indicates an unhealthy status. I It is an indicator function that takes the value 1 when the condition is true, and 0 otherwise.

[0093] Next, calculate the fault. f Confidence level of historical efficacy evidence:

[0094] in, S ( f This indicates a relationship with the fault through a handling relationship (e.g., handled By Solution). f A set of interconnected solutions. ωsuccess ( s ) is the plan s The historical success rate is the ratio of the number of successful executions to the total number of executions.

[0095] Then calculate the fault f Overall confidence level:

[0096] in, α , β and γ ∈[0,1] are configurable weight coefficients, satisfying α + β + γ =1, which reflects the relative importance of causality, real-time status, and historical evidence, respectively.

[0097] Finally, the fault was calculated. f Corresponding symptom alert set: F_to_S_map( f )={p∈P|C_kg contains a path from symptom p to fault f The causal path}.

[0098] According to the fault f Overall confidence score f After sorting the elements of the symptom alert set (e.g., in order of overall confidence from high to low), the root cause failure sequence RC_seq is generated.

[0099] In calculating the confidence level of the aforementioned causal evidence, this embodiment employs a quantitative root cause scoring model based on multi-source evidence fusion (i.e., the comprehensive confidence score). f The core advantage of the calculation formula is: On the one hand, by performing a double summation operation on the confidence levels of causal evidence, the support strength for the same candidate fault from all observed symptoms and through all causal paths can be accumulated. This allows fault hypotheses that can explain multiple anomalies to obtain more significant evidence scores, thus accurately reflecting the common root cause fault pattern of "one cause, multiple effects." On the other hand, it effectively avoids the dilution of key high-confidence paths due to the presence of a large number of low-confidence paths, ensuring that the core supporting evidence for the fault hypothesis is not drowned out. Furthermore, after normalization, the summation model can produce a more significantly discriminative score distribution among candidate faults, thereby providing a sharper decision boundary, making the top-ranked root cause hypotheses more convincing, and improving the reliability of subsequent automated decision-making.

[0100] It is important to note that the quantitative root cause scoring model based on multi-source evidence fusion in this embodiment transforms the qualitative analysis relying on expert intuition in traditional techniques into precise calculations based on dynamic knowledge graphs. For example, the model's structuring: by defining three orthogonal mathematical components—causal evidence, real-time state evidence, and historical performance evidence—systematically characterizes different dimensions of operational reasoning. Another example is the adaptability of the weights: the weight coefficients in the model... α , β and γ It can be adjusted according to the operation and maintenance strategies or specific service level agreements (SLAs) of different cloud data centers. For example, in scenarios that pursue high availability, real-time status evidence can be provided. β Higher weighting. Another example is the dynamic accuracy of the computation: the calculation of all evidence components relies on attributes updated in real time in the dynamic knowledge graph (such as edge confidence, node health status, and scheme success rate), ensuring that the entire analysis process remains synchronized with the dynamic evolution of the data center.

[0101] In some implementations, the inference decision engine can also execute a dynamic knowledge graph-based disposal solution generation algorithm as shown below, wherein the input data for the dynamic knowledge graph-based disposal solution generation algorithm includes: Root cause failure sequence RC_seq; evidence subgraph C_kg; set of actions available for LLM Act_set; number of optimal treatment options to be recommended K; time window size W (seconds) for the indicator time series data; set of time periods T_slots (e.g., {"weekdays 8:00~17:59", "weekdays 18:00~21:59", "weekdays 22:00~next day 7:59", "holidays 8:00~17:59", ...}); fitness threshold τ for including candidate treatment sequences; input event: natural language description of alarm information or symptoms.

[0102] The output data of the disposal solution generation algorithm based on dynamic knowledge graph includes: a sequence of recommended disposal solutions S_seq, and the reasons for recommending each optimal disposal solution (including evidence from the evidence subgraph) and the recommendation score.

[0103] The processing steps of the disposal scheme generation algorithm based on dynamic knowledge graphs may include: (1) For each fault rc in the root cause fault sequence, perform the following processing: First, let the set of disposal schemes S(rc):={s| edge(rc,handled By Solution,s)∈C_kg}; Then, for each disposal plan s in the disposal plan set S(rc), the following processing is performed: The first step is to calculate the degree of matching between the topological features of the fault rc and the mitigation plan s: Let R_aff(rc):={r| The path from fault rc to resource r ∈ C_kg, which contains only caused By and located At edges. R_aff(rc) represents the set of IDs of resources (such as devices and services) affected by fault rc. Let R_aff(s) := {r| The path from treatment plan s to resource r ∈ C_kg satisfies the following conditions: the first edge is a validated By edge from s to a certain empirical case cs, the second edge is a used For edge from a certain empirical case cs to a certain symptom alert, and the remaining edges can only be caused By or located At relationships. R_aff(s) represents the set of resource IDs involved in the successful cases of treatment plan s.

[0104] The topological similarity between fault rc and disposal scheme s is calculated as M. Jaccard (rc,s) := .

[0105] The second step is to calculate the matching degree of the index features between the fault rc and the handling plan s: Let RM_pairs(rc,s):={<r,m> |r∈R_aff(rc)∩R_aff(s), and edge(r,hasMetric,m)∈C_kg}. RM_pairs(rc,s) represents the set of ordered pairs of resource IDs and their metrics that are jointly affected by fault rc and disposal scheme s.

[0106] Let f_history(s):={f| In the empirical case ec, the validates edge ed∈C_kg from ec to disposal s and ω(ed,out come)==SUCCESS. edge(ec,used For,f )∈C_kg} represents the set of faults that have been successfully handled by the solution s in the past, outcome represents the result, and SUCCESS represents success.

[0107] Let ts_cur(r,m) and ts_history(r,m) mark the sequence of measured data points of index m of resource r in two corresponding time periods. The time periods corresponding to ts_cur(r,m) and ts_history(r,m) are [occur(rc)-W,occur(rc)] and [min_occur(s)-W,min_occur(s)], respectively. Here, occur(rc) represents the time when fault rc occurs, and min_occur(s) represents the earliest time when all fault instances that have been successfully handled by the handling scheme s have occurred, that is: min_occur(s)=min(occur(s)), occur(s)={occur(f)|f∈f_history(s)}.

[0108] The degree of matching between the indicators and characteristics of fault rc and handling plan s M metric (rc , s) is defined as: , in, N =|RM_pairs(rc, s)| It represents the morphological similarity between two time series data after normalization, with a value range of [0,1], where 0 indicates that they are completely identical and 1 indicates that they are completely different.

[0109] The third step is to calculate the time feature matching degree between the fault rc and the handling plan s. M time (rc , s): M time (rc , s):= Where λ is the attenuation coefficient. :={ts∈T_slots| t∈occur(s). t lies within the time interval ts. =min({dist(t,ts)|ts∈T_slots}) represents the minimum distance between time t and all time intervals in T_slots. The distance function dist() is defined as follows: if time t is within time interval ts, then dist(t,ts)=0; if time t is to the left of time interval ts, then dist(t,ts)=left(ts)-t; otherwise (i.e., time t is to the right of time interval ts), dist(t,ts)=t-right(ts). left(ts) and right(ts) represent the left and right boundaries of time interval ts, respectively.

[0110] The fourth step is to calculate the environmental characteristic matching degree between the fault rc and the mitigation plan s. M env (rc, s): M env (rc, s):=

[0111] Wherein, EL(s) represents the set of environmental requirement labels for treatment plan s. I This is an indicator function. Examples of environment requirement labels are: "TimeRegion:East-8" and "osVersion:>=Ubuntu 22.01", which respectively indicate "time zone is East 8" and "operating system is Ubuntu, version number >= 22.01".

[0112] The fifth step is to calculate the overall matching degree between the fault rc and the handling plan s. Match (rc, s): Match (rc, s):=∏ f∈{Jaccard, metric, time, env} ( M f ) Φf in, Φ f For dimensions (faults) f The weights satisfy ∑ Φ f =1; The Jaccard coefficient (Jaccard similarity coefficient) is a statistical indicator used to measure the similarity between two sets.

[0113] Step 6: Quantitatively score the decision of "adopting solution s for the fault rc": Let Ψ(rc,s):= Match (rc,s)×ω(rc→s,confidence), that is: the product of the comprehensive matching degree between the fault rc and the disposal plan s and the historical confidence of the decision is used as the quantitative score of the decision.

[0114] Finally, let Γ(rc) denote the sequence of candidate solutions formed by the K disposal solutions with the largest Ψ(rc,s) values ​​that satisfy the condition Ψ(rc,s)>τ (sorted in descending order of Ψ(rc,s) values).

[0115] (2) Execute evidence-driven solution generation and optimization: Based on the input event, root cause failure sequence RC_seq, candidate solution sequence Γ(rc), evidence subgraph C_kg and set of processing actions available to LLM Act_set, fill the decision prompt word template, such as "Template-2: Disposal solution generation and optimization", requiring LLM to generate a recommended disposal solution sequence S_seq for each failure in the root cause failure sequence RC_seq, as well as the recommendation reason and recommendation score for each solution.

[0116] In some implementations, examples of "Template-2: Disposal Plan Generation and Optimization" include: System instruction: The current role is a cloud data center operations expert. The current role's task is to generate the optimal fault handling solution for each fault based on the following decision input information.

[0117] Decision input information: (1) Alarm information or symptoms: {inputEvent}. (2) Main candidate faults (sorted by probability score): {Fault F1(score:X1): {evidence of F1}, {Fault F2(score:X2): {evidence of F2}, and so on. (3) Candidate solutions for each fault: For fault F1, {Solution A1(confidence:c_A1, context matching:Ψ_A1)}: {brief description of solution A1}, {applicable scenarios of A1}; {Solution B1(confidence:c_B1, context matching:Ψ_B1)}: {brief description of solution B1}, {applicable scenarios of B1}, and so on; For fault F2: (similar to the configuration for fault F1). (4) Available facts and knowledge: {natural language representation of C_kg}. (5) Available actions: Action Act1: {Name and effect description of Act1}, {Parameter description of Act1}; Action Act2: (The configuration is similar to that of Action Act1).

[0118] The current role's task is to assess the likelihood of each candidate fault causing the input symptoms. If you believe it is entirely impossible, please provide a detailed reasoning process and supporting evidence.

[0119] For each candidate fault that the current role considers possible, generate up to K recommended solutions and sort them from highest to lowest according to the recommendation score.

[0120] For each recommended treatment plan, the reasons for the recommendation are given from the perspectives of "applicability" and "reliability".

[0121] If modifications are required based on the proposed solutions provided by the decision input information, a reason should be given for each modification.

[0122] If a completely new recommended solution needs to be generated, the reasons why the solutions in the decision input section are not applicable should be given.

[0123] If a new action needs to be added beyond the actions given in the decision input information, in addition to providing the name, effect, and parameter description of the new action, the reason for adding the new action must also be described.

[0124] The output should be in JSON format. Please note: If the recommended solution is a completely new solution (i.e., not based on any candidate solutions from the input), then the input candidate solutions are empty, but the reason for creating a completely new solution must be non-empty.

[0125] If the recommended treatment plan does not modify the basic treatment plan, then the reason for modification is empty.

[0126] The "Source" of a newly added action should be "newly added", and the "Expected Effect" and "Reason for Adding" must be non-empty.

[0127] For actions that are not newly added, the "Expected Effect" and "Reason for Adding" fields should be empty. If the action comes from a candidate solution of the input, its "Source" is the name of that solution; otherwise, the "Source" is "from_input", indicating that it comes from an available action of the input.

[0128] In some implementations, the core of the knowledge graph evolution engine is the following automatic knowledge graph evolution algorithm based on feedback of treatment effects: Input data includes: completed work orders T; experience cases EC generated from work order T, which include the action taken and the action plan adopted (denoted as EC.solution), the set of resources involved (denoted as EC.resourceSet), and whether the action was successful (denoted as EC.success); the symptom alarm set F_to_S_map corresponding to each root cause fault and the reasoning basis for the fault leading to these symptoms (see the calculation process of F_to_S_map in "Root Cause Analysis Algorithm Based on Real-Time Status and Multi-Source Evidence Fusion"); and the current knowledge graph KG.

[0129] The output data is the updated dynamic knowledge graph.

[0130] The processing steps of a knowledge graph-based automatic evolution algorithm based on feedback of treatment effects may include: (1) Causal network calibration, including updating causal assertions and cause-by relationships; wherein, the faults of the empirical case EC handling (denoted as f) are taken from the adopted handling solution EC.solution, and the symptom alarm set F_to_S_map(f) is the symptom set and reasoning basis (denoted as S) caused by fault f. The algorithm for creating and updating causal assertions below is called with the current knowledge graph KG, fault f, reasoning basis S and whether the handling was successful EC.success.

[0131] For each piece of evidence s in the reasoning evidence S, perform the following processing: If edge(s,causedBy,f) does not yet appear in KG, then add this edge (denoted as e) and initialize the properties of e: ω(e,successCount):=max(0,CA.conf× +I(EC.success)); ω(e,failureCount):=max(0,(1-CA.conf× )-I(EC.success)).

[0132] in, CA . symptoms Let I represent the symptom set of CA, and let I be an indicator function (1 if the treatment is successful, -1 otherwise).

[0133] Otherwise, update the attribute value of this side (denoted as e): if the processing is successful, then ω new (e, successCount):=ω old (e, successCount) + 1; otherwise ω new (e, failureCount):=ω old (e, failureCount)+1.

[0134] Update the confidence of e (regardless of whether e has a new edge): If ω(e, successCount) + ω(e, failureCount) = 0, then ω(e, confidence) := 0.5; otherwise: ω(e, confidence) := .

[0135] (2) Update the fault handling and feedback relationships: Add edge(f, handledBySolution, EC) and edge(EC, validates, EC.solution) to KG. Update the successCount, failureCount and confidence attribute values ​​of the above two edges in the same way as updating the attribute values ​​of this edge (denoted as e) and updating the "otherwise" part of the confidence of e.

[0136] (3) Add necessary nodes and edges to KG according to the definition of the aforementioned ontology model, namely the nodes and edges determined after the update in step (2) of the previous section.

[0137] Furthermore, the creation and updating of causal assertions are implemented using the following algorithm: Input data includes: the current knowledge graph KG, fault f, the symptom set and reasoning basis S caused by fault f, successFlag indicating whether the current treatment was successful, initial confidence value of the causal assertion init_conf, and the learning rate η (e.g., 0.1) used when updating the confidence of the causal assertion.

[0138] The output data is the updated dynamic knowledge graph.

[0139] The steps for creating and updating causal assertions may include: (1) Calculate the confidence level of the causal assertion: Search in KG for a CausalAssertion node with f as the cause and S as the effect. If no node is found, then: if successFlag is true, create a new CausalAssertion node (denoted as CA), set its confidence to init_conf, and create an assertsCause edge connecting CA and f. For each symptom s in S, create an assertsManifest edge connecting CA and s.

[0140] If the search finds the node, then: denote this node as CA and update its confidence score: CA.confnew:=CA.confold+η×(Iconfirm-CA.confold), where Iconfirm is an indicator function that takes the value 1 when successFlag is true, and 0 otherwise.

[0141] (2) Calculate the contribution of CA.CA.contrib: For each symptom s in S, execute: Let Competing(s):={ca| Let edge(ca,assertsManifest,s)∈KG} represent the set of assertions that compete with CA for the occurrence of symptom s. For each assertion CA_i in Competing(s), calculate its strength score for s: strength(CA_i,s) :=CA_i.conf × Based on this formula, we can obtain strength(CA,s):=CA.conf× The contribution of CA to s is contrib(CA,s):= .

[0142] Therefore, CA's contribution to S is CA.contrib:= .

[0143] (3) Update the contribution of assertions that compete with CA: Let Competing:=∪ s∈S Competing(s)\{CA}; For each ca in Competing, update ca.contrib using the steps described above for calculating the contribution of CA.contrib.

[0144] Unlike solutions that use knowledge graphs as static reference libraries, the aforementioned automated data center operation and maintenance work order processing system 100 constructs a "living" knowledge system with closed-loop learning capabilities. The execution result of each operation and maintenance work order (whether successful or not) serves as structured feedback (experience cases, causal assertions, etc.) driving the dynamic updating of the knowledge graph: the effectiveness attributes of the handling plan (such as successCount, confidence) are adjusted in real time, and the causal relationship between symptoms and faults (caused by confidence) is continuously calibrated. This allows the system's decision-making basis to continuously evolve with operational practices, constantly accumulating and optimizing operational wisdom for specific data centers, achieving a paradigm shift from a "static knowledge base" to a "dynamic experience body."

[0145] Traditional solutions suffer from a severe disconnect between the knowledge base and the real-time operational status of the data center. This invention addresses this by using a predefined ontology model to perform real-time semantic parsing of data streams from various monitoring systems, instantly mapping raw metrics to entity states (such as state assertions) with explicit semantics within a knowledge graph. This allows the system to base its fault diagnosis and solution recommendations not on historical snapshots, but on a dynamic digital twin that integrates current resource topology, service dependencies, and health status, fundamentally preventing decision-making errors caused by outdated information.

[0146] This invention completely solves the "black box" and "illusion" problems of LLM (Local Management Model). Every root cause analysis conclusion and response plan output by the system is not freely generated by LLM, but rather stems from multi-dimensional fusion reasoning based on real-time state evidence, historical causal relationships, and quantifiable attributes of solution effectiveness within a dynamic knowledge graph. The decision report clearly displays the complete chain of evidence supporting its conclusions (e.g., which specific abnormal indicators are associated, which historical success cases are referenced, and their confidence levels), providing operations engineers with a transparent audit path. This verifiability enables automated approval of high-risk operations, greatly improving the level of operations automation.

[0147] Solutions relying solely on LLM lack a structured understanding of the internal relationships of complex systems and have weak reasoning capabilities. This invention provides a rigorous reasoning framework for LLM through formalized concepts and relationships (such as deployed on, dependent on, and originating from) defined by an ontology model. Combined with the real-time relational query capabilities of a dynamic knowledge graph, the system can simulate expert thinking, performing multi-hop reasoning across components (e.g., reasoning paths can traverse different devices, services, technical fields, or functional modules within the data center) and levels (e.g., reasoning paths can traverse different abstraction levels from physical infrastructure to upper-layer business applications). This accurately identifies fault propagation paths and root causes, rather than providing superficial or isolated suggestions. This enables it to effectively address the severe challenges of multi-service coupling and complex fault chains in cloud data centers.

[0148] In summary, this invention constructs an autonomous operation and maintenance brain that is truly adapted to the complex and dynamic environment of cloud data centers through four core capabilities: dynamic evolution, real-time perception, reliable decision-making, and deep reasoning. This can significantly improve the work efficiency, reliability, and intelligence level of the operation and maintenance system.

[0149] Each module in the aforementioned data center automated operation and maintenance work order processing system 100 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of devices with data processing capabilities, or stored in software within the memory of the aforementioned devices, so that the processor can call and execute the operations corresponding to each module. The aforementioned devices can be, but are not limited to, various types of data processing system devices already existing in the art.

[0150] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0151] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of protection of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and all such modifications and improvements fall within the scope of protection of the present invention.

Claims

1. A data center automated operation and maintenance work order processing system, characterized in that, include: The real-time data stream parsing module is used to perform real-time semantic parsing and semantic mapping on the real-time monitoring data streams of various monitoring systems, and output the real-time status of the data center. The dynamic knowledge graph management module is used to perform creation, editing, real-time synchronization, evolutionary closed-loop update, and traversal query functions of the dynamic knowledge graph based on the ontology model; the key relationship edges of the dynamic knowledge graph have dynamically adjustable weight attributes. The knowledge graph reasoning engine is used to obtain reasoning query results from the knowledge graph through the dynamic knowledge graph management module. The reasoning decision engine is used to perform root cause analysis based on real-time status and reasoning query results from the knowledge graph, and generate root cause fault sequences and corresponding symptom alarm sets. The LLM coprocessor is used to generate a natural language work order handling solution after LLM reasoning based on the facts, root cause fault sequences and corresponding symptom alarm sets provided by the dynamic knowledge graph management module, according to semantic reasoning rules. The knowledge graph evolution engine is used to update the dynamic knowledge graph based on the feedback of the handling effect of the work order handling plan; The ontology model management semantic service module provides semantic specifications for the real-time data stream parsing module during semantic parsing and semantic mapping, and provides semantic reasoning rules for the knowledge graph reasoning engine and LLM coprocessor.

2. The data center automated operation and maintenance work order processing system according to claim 1, characterized in that, The class definitions of the ontology model include resource entity classes, state event classes, causal relationship classes, and operation and maintenance activity classes. The relationships of the ontology model include real-time state relationships, causal topology relationships, fault handling relationships, and feedback relationships after fault handling is completed.

3. The data center automated operation and maintenance work order processing system according to claim 2, characterized in that, Status event classes include health status, indicators, status assertions, symptoms, alarms, and faults; The key information carried by each instance of a causal assertion in the causal association class includes at least one symptom entity or alarm entity associated with the assertion as the effect of the assertion through the assertion's performance relationship, a fault entity associated with the assertion as the cause of the assertion through the assertion's cause relationship, confidence attribute, contribution attribute, and evidence attribute. Operation and maintenance activities include work orders, processing actions, processing procedures, handling solutions, and experience cases.

4. The data center automated operation and maintenance work order processing system according to claim 2 or 3, characterized in that, Real-time status relationships include ownership of metrics, metric associations, status determination, and triggering. Causal topological relationships include originating from, located in, deployed in, dependent on, and connected to; Fault handling relationships include inclusion, composition, being handled by the solution, and execution.

5. The data center automated operation and maintenance work order processing system according to claim 2 or 3, characterized in that, The feedback relationships after fault handling is completed include generation, already used for handling, verification, occurrence, suggested modification actions, confirmation of cause and effect, and generation of new solutions.

6. The data center automated operation and maintenance work order processing system according to any one of claims 1 to 3, characterized in that, The creation and editing functions of dynamic knowledge graphs include: Create entity nodes representing specific resources in the cloud data center based on the ontology model; Based on the real-time topology and monitored status, create or update relationship instances between entities; The provided interactive interface allows operations and maintenance experts to input validated solutions and case studies into the dynamic knowledge graph.

7. The data center automated operation and maintenance work order processing system according to claim 6, characterized in that, The evolutionary closed-loop update function includes: Based on the cases and causal assertions generated after the execution of the work order handling plan, the dynamic weight attributes of key relationships in the dynamic knowledge graph are automatically and incrementally updated. When a new treatment plan is verified to be effective or a new causal relationship is confirmed, new treatment plan nodes, causal assertion nodes, and corresponding relationships are created in the dynamic knowledge graph.

8. The data center automated operation and maintenance work order processing system according to claim 6, characterized in that, LLM coprocessors include: The semantic parsing and information extraction submodule is used to guide the LLM to accurately anchor natural language input to the semantic space of the ontology model using semantic prompt word templates; The context-enhanced reasoning and decision support submodule is used to obtain real-time contextual evidence that is highly relevant to the current problem from the dynamic knowledge graph, and then use decision prompt word templates to reason, summarize and generate natural language explanations.

9. The data center automated operation and maintenance work order processing system according to claim 6, characterized in that, The formal definition of an ontology model is Φ: Φ =<C, R, A, W> Where C is a set of classes; R C×C is a set of binary relations on C; A is a set of attributes assigned to each class c∈C, and W is a set of attributes assigned to each relation r∈R.

10. The data center automated operation and maintenance work order processing system according to claim 6, characterized in that, The formal definition of dynamic knowledge graph is: Directed graph<V,E,ρ,ω> Where V is a set of nodes, and each node v∈V represents an entity, E V×R×V is the set of edges, and each edge has an edge e= <v s ,r,v t > Represents entity v s With entity v t There exists a relation r∈R, where ρ is the node attribute function and ω is the edge attribute function.

Images