Fault self-healing method and system based on business semantic map and large language model

Abstract

The invention provides a fault self-healing method and system based on a business semantic map and a large language model, electronic equipment and a storage medium, and the method comprises the steps: converting enterprise unstructured business knowledge into a dynamic business semantic map through knowledge modeling, real-time perception, intelligent reasoning, automatic restoration and continuous evolution full-link closed loop; and fault self-healing is realized in combination with a large language model. The method comprises the following steps: constructing and updating a business semantic map, collecting multi-dimensional observable data of a production environment in real time and detecting anomalies, combining data and a map input model to output a root cause and a repair suggestion, automatically generating a repair request for a high-confidence fault, completing publishing after auditing, and reversely updating the map by a redisk report after the fault is recovered to form a self-evolution closed loop. According to the scheme, more than 80% of conventional fault recovery time is shortened to a minute level from several hours, MTTR is reduced, the fault risk is eliminated through precipitation organization level knowledge, manual intervention and regression risks are reduced, system intelligence is continuously improved, and production system stability and research and development efficiency are guaranteed.

Description

Technical Field

[0001] The embodiments of this invention relate to the field of enterprise-level observability and fault emergency response technology, and in particular to a fault self-healing method and system based on business semantic graphs and large language models. Background Technology

[0002] Enterprise-level observability and fault response are core technology areas for the stable operation of production systems in internet companies. They primarily address key scenarios such as log analysis, fault location, emergency repair, and on-call collaboration, with the core objective of shortening fault recovery time and improving system stability and development efficiency. Current mainstream practices in the industry include: traditional log analysis methods combining manual line-by-line review and keyword search; root cause localization models heavily reliant on the personal experience of a few senior employees; emergency release processes after temporary code modifications; and on-call wake-up mechanisms that use phone calls or group messages to notify employees of faults occurring outside of working hours. While some teams have introduced centralized log systems, they still rely heavily on manual analysis, resulting in low levels of intelligence. These methods are still widely used in small and medium-sized teams and some large enterprises, and involve the challenging optimization of the core metric of Mean Time To Recovery (MTTR).

[0003] To improve efficiency, some enterprises have introduced centralized logging systems and monitoring and alarm tools, achieving unified data collection and initial anomaly detection. However, these tools still lack intelligence at the root cause analysis and remediation execution levels, failing to effectively combine semantic information such as business logic and system architecture with real-time observation data, resulting in limited diagnostic accuracy. The process from fault location to remediation deployment remains fragmented, with low levels of automation, making rapid and secure fault self-healing impossible.

[0004] When production environment logs are massive, manual retrieval and analysis are extremely inefficient, and a single fault location often takes hours or even days. Key knowledge such as core business links and historical fault modes is highly concentrated in the hands of a few senior employees. Once these personnel are not on duty or have left the company, it will cause serious knowledge gaps and a lack of responsiveness. The fault repair process usually relies on temporary code modifications and emergency releases, which is time-consuming and carries a high risk of regression. When faults occur outside of working hours, relying on repeated calls to relevant personnel via phone or group chats often significantly prolongs response and recovery time due to the inability to contact them in a timely manner. Summary of the Invention

[0005] This invention provides a fault self-healing method, system, electronic device, and storage medium based on business semantic graphs and large language models to solve the technical problems in the current technology, such as traditional fault diagnosis relying on manual experience, low efficiency and easy formation of knowledge silos, fragmented process from fault diagnosis to repair, low degree of automation and high operational risks, and lack of self-evolution capability of operation and maintenance system unable to continuously learn from handling experience.

[0006] In a first aspect, embodiments of the present invention provide a fault self-healing method based on business semantic graphs and large language models, comprising: S1. Based on preset business knowledge data, extract entities, relationships, and attributes to represent business logic, entity relationships, and historical failure modes; vectorize the entities, relationships, and attributes to construct and continuously update a dynamic business semantic graph.

[0007] S2. Collect multidimensional observable data of the production environment in real time, and perform real-time analysis on the multidimensional observable data. When the analysis results indicate an anomaly, generate a trigger event.

[0008] S3. In response to the triggering event, the current multidimensional observable data and the business semantic graph are jointly input into the large language model to output root cause localization information and corresponding repair suggestions.

[0009] S4. If the confidence level of the root cause location information is higher than a preset threshold, and the fault scenario corresponding to the root cause location information meets the preset automatic repair conditions, then based on the repair suggestion, a repair request containing code modification or configuration change is automatically generated in the specified version control system.

[0010] S5. Push the repair request for review, and automatically execute the build, test and release process after the review is approved to complete the repair.

[0011] S6. After the fault is recovered, a structured debriefing report is automatically generated based on the current processing, and the business semantic graph is updated according to the debriefing report.

[0012] Preferably, in step S1, the preset business knowledge data includes at least one of the following: business architecture document, core link source code, historical fault review report, standard operating procedure (SOP), and business link topology diagram. The vectorization process includes: The extracted entities, relations, and attributes are semantically encoded using a pre-trained language model to generate corresponding vector representations; the business semantic graph is kept updated in real time with newly added business knowledge data through an event bus.

[0013] Preferably, in step S2, the multidimensional observable data includes server hardware metrics, distributed tracing data, full business logs, database slow query logs, and external dependent service status data. The server hardware metrics include CPU utilization, memory usage, I / O throughput, and network bandwidth.

[0014] Preferably, in step S2, the multidimensional observable data is analyzed in real time, and a trigger event is generated when the analysis result indicates an anomaly, including: The collected multidimensional observable data is uniformly normalized; real-time data features are extracted from the normalized data through an anomaly detection engine; the real-time data features are compared with a preset normal threshold range and / or a historical fault feature library; when the comparison result meets the preset anomaly judgment conditions, a trigger event is generated, and the trigger event includes anomaly type, occurrence time and associated business node information.

[0015] Preferably, S3 specifically includes: In response to the triggering event, business nodes and historical failure modes associated with the anomaly represented by the triggering event are retrieved from the business semantic graph to form a business context subgraph; the current multidimensional observable data is concatenated and formatted with the business context subgraph to construct a prompt message that can be processed by a large language model; the prompt message is input into the large language model for root cause analysis of causal reasoning; the output of the large language model is received and parsed to generate structured root cause location information and corresponding remediation suggestions, wherein the root cause location information includes at least the root cause entity, the impact link, and the confidence level; and the remediation suggestions include operation steps and risk levels.

[0016] Preferably, S4 specifically includes: When the confidence level of the root cause location information is higher than a preset threshold, the system determines whether the corresponding fault scenario meets the automatic repair conditions according to preset rules. The automatic repair conditions include that the root cause of the fault belongs to a defined standardized type and the repair operation has a verified security solution. If the system meets the conditions, a repair script containing specific code modifications or configuration changes is automatically generated based on the repair suggestions. The system calls the application programming interface of the version control system to create a repair request in the specified code repository, which includes the repair script, a root cause analysis summary, and a modification context. The repair request is associated with the triggering event, and a generation notification is pushed to the specified audit terminal.

[0017] Preferably, S6 specifically includes: Based on the triggering event, the root cause location information, the repair suggestions, and the repair execution results, a structured debriefing report is automatically generated. The debriefing report includes at least the fault phenomenon, root cause conclusions, repair measures, and prevention suggestions. The debriefing report is used as a new knowledge source to identify and extract newly added or changed entities, relationships, and attributes. Based on the extraction results, the business semantic graph is updated, including adding new graph nodes and edges, and updating the vectorized representation of existing nodes. The key indicators and knowledge update records of this fault handling are persistently stored to drive the continuous evolution of the business semantic graph and the association analysis model.

[0018] Secondly, embodiments of the present invention provide a fault self-healing system based on business semantic graphs and large language models, comprising: The business semantic graph construction and update module is used to extract entities, relationships and attributes that represent business logic, entity relationships and historical failure modes based on preset business knowledge data; and to vectorize the entities, relationships and attributes to construct and continuously update a dynamic business semantic graph.

[0019] The multidimensional observable data acquisition and anomaly detection module is used to acquire multidimensional observable data of the production environment in real time and perform real-time analysis on the multidimensional observable data. When the analysis results indicate an anomaly, a trigger event is generated.

[0020] The root cause analysis and remediation suggestion generation module is used to respond to the triggering event by jointly inputting the current multidimensional observable data and the business semantic graph into the large language model to output root cause location information and corresponding remediation suggestions.

[0021] An automated repair request generation module is used to automatically generate a repair request containing code modifications or configuration changes in a specified version control system based on the repair suggestions if the confidence level of the root cause location information is higher than a preset threshold and the fault scenario corresponding to the root cause location information meets preset automatic repair conditions.

[0022] The review and release execution module is used to push the repair request for review, and automatically execute the build, test and release process to complete the repair after the review is approved.

[0023] The review and graph update module is used to automatically generate a structured review report based on the current processing after the fault is recovered, and update the business semantic graph according to the review report.

[0024] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the fault self-healing method based on business semantic graph and large language model as described in the first aspect of the present invention.

[0025] Fourthly, embodiments of the present invention provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the fault self-healing method based on business semantic graph and large language model as described in the first aspect of the present invention.

[0026] This invention provides a fault self-healing method, system, electronic device, and storage medium based on business semantic graphs and large language models. Through a closed-loop design encompassing knowledge modeling, real-time perception, intelligent reasoning, automatic repair, and continuous evolution, it transforms unstructured business knowledge into a dynamically usable business semantic graph. Combined with a large language model, it achieves fault self-healing: First, based on data such as business architecture documents, source code, and historical fault reviews, entities, relationships, and attributes are extracted and quantified to construct and continuously update a dynamic business semantic graph. Then, multi-dimensional observable data from the production environment, including server metrics, logs, and network links, are collected in real-time. Anomalies are analyzed to generate trigger events. Upon responding to an event, real-time data and the business semantic graph are jointly input into the large language model to quickly output root cause location information and repair suggestions. For faults with high confidence and meeting automatic repair conditions, a repair request containing code modifications or configuration changes is automatically generated. After review, the repair request is automatically built, tested, and released. After fault recovery, a structured review report is generated, which in turn updates the business semantic graph, forming a positive self-evolutionary closed loop. The solution offers significant technical benefits, fundamentally changing the traditional fault handling model that relies on human experience. It reduces the recovery time for over 80% of common faults from hours to minutes, drastically lowering the mean time to recovery (MTTR). By accumulating organizational-level knowledge through business semantic graphs, it eliminates the risk of gaps in core technical knowledge due to reliance on individual senior employees. The fully automated process reduces human intervention, lowering the risk of regression and cross-team coordination costs. Continuous self-evolution capabilities enable the system's intelligence to improve over time, gradually expanding the scope of fault self-healing and fundamentally enhancing the stability and R&D efficiency of enterprise production systems. Attached Figure Description

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

[0028] Figure 1 This is a flowchart of a fault self-healing method based on business semantic graph and large language model according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a fault self-healing method based on business semantic graphs and large language models according to an embodiment of the present invention. Figure 3 This is a block diagram of a fault self-healing system based on business semantic graphs and large language models according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the physical structure according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0031] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance 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. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0032] This invention provides a fault self-healing method based on business semantic graphs and large language models, such as... Figure 1 , Figure 2 As shown, it includes: S1. Based on preset business knowledge data, extract entities, relationships, and attributes to represent business logic, entity relationships, and historical failure modes; vectorize the entities, relationships, and attributes to construct and continuously update a dynamic business semantic graph.

[0033] The pre-defined business knowledge data refers to structured and unstructured materials accumulated by the enterprise, such as business architecture documents, core link source code, historical fault review reports, standard operating procedures (SOPs), and business link topology diagrams (runaway diagrams). These serve as the foundational materials for constructing the business semantic graph. Entities, relationships, and attributes are the core elements extracted from the business knowledge data. Entities can be understood as specific objects such as core functional modules, database tables, and server nodes in a CMS (Content Management System). Relationships represent business dependencies or data flow connections between objects, such as the user login module calling the user information database. Attributes are the characteristic descriptions of entities, such as the CPU model of a server node or the field type of a database table. Vectorization processing uses a pre-trained large language model to semantically encode the extracted entities, relationships, and attributes, transforming unstructured information into high-dimensional semantic vectors that can be computed by computers, ensuring that business knowledge can be quickly retrieved and reasoned by the model. The dynamic business semantic graph is a visualized knowledge network built based on the above vectors, and new business knowledge is added in real time through an event bus, such as code iterations of the CMS system and new fault cases, to achieve continuous updates.

[0034] In this embodiment, S1 systematically organizes business knowledge and transforms it into a dynamic graph, turning scattered personal experience into a queryable and reasonable organizational-level asset. This solves the technical problems of difficult knowledge reuse and the impact of personnel turnover on responsiveness in the traditional model, providing a unique and reliable business context for subsequent intelligent fault handling. It also allows new employees to obtain expert-level knowledge support through the graph, eliminating knowledge barriers at the root.

[0035] S2. Collect multidimensional observable data of the production environment in real time, and perform real-time analysis on the multidimensional observable data. When the analysis results indicate an anomaly, generate a trigger event.

[0036] The multidimensional observable data includes server hardware metrics (CPU utilization, memory usage, IO throughput, network bandwidth, etc.), distributed tracing data, full business logs, database slow query logs, and external dependent service status data, comprehensively covering various key data dimensions during the CMS system's operation. Real-time analysis refers to the entire process of first uniformly normalizing the collected multidimensional data, then extracting real-time data features through an anomaly detection engine, and comparing them with preset normal threshold ranges or historical fault feature libraries, breaking through the limitations of traditional manual analysis. "Trigger events" are notification messages generated when the analysis results indicate an anomaly, containing key information such as the anomaly type (e.g., database connection timeout, interface response delay), occurrence time, and associated business nodes (e.g., the CMS system's content publishing module, user authentication interface), providing clear direction for subsequent root cause analysis.

[0037] In this embodiment, S2 solves the technical problems of scattered data and delayed manual retrieval in traditional fault diagnosis by collecting multi-dimensional data in real time and analyzing it automatically. It quickly captures system anomalies and accurately triggers the response process, laying a data foundation for subsequent second-level root cause location and significantly shortening the time difference between anomaly discovery and response.

[0038] S3. In response to the triggering event, the current multidimensional observable data and the business semantic graph are jointly input into the large language model to output root cause localization information and corresponding repair suggestions.

[0039] Among them, the large language model refers to an intelligent model that integrates a causal reasoning engine, which has the ability to correlate and reason with multidimensional data and business semantics; the root cause localization information is the structured result output by the model, which includes at least the root cause entity (such as a piece of code with a syntax error in the CMS system, or a database connection pool with a misconfiguration), the impact chain (such as the content publishing interface call failing due to the erroneous code, which in turn affects the user submission function), and the confidence level (characterizing the reliability of the root cause judgment); the remediation suggestion is an executable solution proposed for the root cause, which includes specific operation steps (such as modifying code parameters, adjusting database configuration) and risk level (such as low-risk configuration optimization, high-risk code refactoring).

[0040] This embodiment S3 inputs real-time multidimensional observable data and business semantic graphs into a large language model to achieve deep fusion reasoning of data and knowledge. This solves the technical problems of root cause localization relying on human experience, being inefficient, and lacking stability. It outputs a high-confidence root cause report and remediation suggestions within 10 to 30 seconds, compressing the traditional localization time of several hours to the second level, providing key support for rapid remediation.

[0041] S4. If the confidence level of the root cause location information is higher than a preset threshold, and the fault scenario corresponding to the root cause location information meets the preset automatic repair conditions, then based on the repair suggestion, a repair request containing code modification or configuration change is automatically generated in the specified version control system.

[0042] Among them, the confidence level preset threshold is the critical value for judging whether a fault is suitable for automatic repair. It can be manually configured by the user according to the business importance and fault tolerance of the CMS system, or it can be dynamically adjusted by the system based on the historical fault repair success rate and false positive rate. The preset automatic repair conditions refer to high-frequency fault scenarios where the root cause of the fault is the inconsistency between design and implementation, basic coding errors, or has been recorded in the historical fault review report. The repair process for such scenarios is standardized and the risks are controllable. The version control system refers to the GitOps repository, which is a platform for storing code and configuration files and supporting version management. The repair request is a pull request (PR) automatically generated by the system that includes specific code modifications, configuration changes, root cause analysis summary, and business context description, ensuring that the repair process is traceable.

[0043] S4 in this embodiment automatically generates repair requests for high-confidence, standardized faults, solving the technical problems of low efficiency, high risk, and high cross-team coordination costs in traditional repair processes. It significantly shortens the preparation time for manual repair, avoids additional faults caused by configuration drift, and provides complete contextual support for subsequent review and release, thereby improving the standardization of the repair process.

[0044] S5. Push the repair request for review, and automatically execute the build, test and release process after the review is approved to complete the repair.

[0045] Among them, the repair request push review can push the repair request generated by S4 to enterprise collaboration platforms such as Lark and WeChat Work, and send a notification containing the repair request link and core information to the on-duty personnel to ensure that the on-duty personnel receive the review task in a timely manner; the build, test and release process is an automated execution link after the review is approved, including code building, smoke testing (quickly verify the availability of core functions), canary release (small traffic to verify the repair effect) and traffic switching (gradually switch all traffic to the repaired service), with full traceability.

[0046] S5 in this embodiment solves the technical problems of untimely fault response, non-standard release process, and uncontrollable risks by simplifying the review process and automating the release process. On average, the on-duty personnel can complete the review and one-click release in 2 to 5 minutes, which greatly shortens the time from repair to online. At the same time, the standardized release process reduces regression risk and ensures that the repair process is safe and traceable.

[0047] S6. After the fault is recovered, a structured debriefing report is automatically generated based on the current processing, and the business semantic graph is updated according to the debriefing report.

[0048] The structured debriefing report is a standardized document generated based on the entire process of this fault handling. It includes at least a detailed description of the fault phenomenon, root cause conclusions, remedial measures, and preventive suggestions. After being confirmed by the relevant responsible persons, it serves as a new knowledge source. The business semantic graph update refers to identifying and extracting newly added or changed entities, relationships, and attributes based on the new knowledge in the debriefing report, supplementing (such as adding new fault mode nodes) and adjusting (such as optimizing the relationship weights between entities) the business semantic graph, while simultaneously updating the inference parameters of the large language model.

[0049] In this embodiment, S6 solves the technical problems of ineffective accumulation of fault knowledge and stagnation of system intelligence by automatically reviewing and updating the graph. It forms a positive self-evolutionary closed loop of fault → learning → capability improvement. As the usage time increases, the accuracy of the business semantic graph and model continues to improve, and the fault scenarios that can be covered become more and more comprehensive, which promotes the continuous increase of the fault self-healing ratio and gradually realizes the evolution from rapid recovery to near-zero intervention self-healing.

[0050] Based on the above embodiments, as a preferred implementation, in step S2, the multidimensional observable data is analyzed in real time, and a trigger event is generated when the analysis result indicates an anomaly, including: The collected multidimensional observable data undergoes unified normalization processing. This data originates from diverse sources and comes in various formats (e.g., CPU utilization expressed as a percentage, memory usage measured in GB, and logs stored as text). The unified normalization process uses data standardization algorithms to convert multidimensional observable data of different magnitudes and formats into a unified standard range (e.g., the 0-1 interval) or a unified data format. For example, CPU utilization (0-100%), memory usage (2GB-32GB), and log error code frequency (0-100 times / minute) are uniformly converted into directly comparable standardized values. Simultaneously, unstructured log text is converted into structured feature fields. By unifying the data format and magnitude, the technical problem of joint analysis due to the heterogeneity of traditional data is solved, eliminating data format barriers and laying the foundation for subsequent real-time feature extraction and rapid comparison. This significantly improves the consistency and efficiency of data processing and avoids analysis delays caused by data clutter.

[0051] An anomaly detection engine extracts real-time data features from normalized data. This engine, an AI root cause analysis engine, is a core module with real-time data processing, feature recognition, and preliminary judgment capabilities. It can quickly parse normalized data based on preset rules and algorithms. Real-time data features refer to key information extracted from normalized data that reflects the CMS system's operational status, such as sudden changes in server CPU utilization, the frequency of specific error codes in logs, and the execution time and trigger count of slow database queries. These features are directly related to whether the system is operating normally. This step automates the extraction of real-time data features through the anomaly detection engine, solving the technical problems of low efficiency, strong subjectivity, and easy omission of key information in manual feature extraction. It quickly and accurately captures core features that characterize system anomalies, providing targeted basis for subsequent comparative analysis and improving the timeliness and accuracy of anomaly identification.

[0052] The real-time data features are compared with preset normal threshold ranges and / or historical fault feature libraries. The preset normal threshold ranges are based on historical data from the long-term normal operation of the CMS system, combined with reasonable ranges for each feature set according to business needs. For example, the normal threshold for CPU utilization is 0-80%, and the normal threshold for slow database queries is execution time ≤ 1 second. The historical fault feature library stores a set of features accumulated during past fault handling, containing key data features at the time of each fault occurrence. For example, the feature corresponding to database connection timeout is connection failures > 5 times / minute and external dependent service response delay > 3 seconds, and it is continuously updated as the system runs. This step uses dual reference standards (normal thresholds + historical fault features) for automated comparison, solving the technical problems of vague, subjective, and inaccurate traditional anomaly judgment reference standards. It achieves standardization and scientification of anomaly judgment. By judging the deviation between real-time features and normal thresholds, and matching the similarity between real-time features and historical fault features, the comprehensiveness and accuracy of anomaly identification are improved, reducing the probability of false alarms and missed alarms.

[0053] When the comparison result meets the preset anomaly judgment conditions, a trigger event is generated. The trigger event includes the anomaly type, the occurrence time, and the associated business node information. The preset anomaly judgment conditions refer to judgment rules set based on business importance and fault risk, such as real-time features exceeding the normal threshold and having a match rate ≥90% with historical fault features, or real-time features exceeding the normal threshold for 3 consecutive minutes without a reasonable business explanation. The trigger event is a signal generated by the system after detecting an anomaly, used to initiate subsequent root cause analysis and repair processes, and is a key link connecting anomaly detection and intelligent response. The anomaly type is a classification description of the fault, such as slow database query anomaly, interface response timeout anomaly, code syntax error anomaly, etc. The associated business node information refers to the specific modules or components of the CMS system involved in the fault, such as the content publishing module, user information database, third-party storage service interface, etc. This step solves the technical problems of incomplete and unclear alarm information by generating trigger events containing complete key information. It provides a clear starting point and clear context for subsequent second-level root cause analysis, allowing the AI ​​root cause analysis engine to quickly locate the scope of anomaly association. At the same time, it makes it easier for on-duty personnel to intuitively understand the core information of the fault, greatly shortens the preparation time for fault response, and lays the foundation for minute-level fault recovery.

[0054] Based on the above embodiments, as a preferred implementation, step S3 specifically includes: In response to the triggering event, business nodes and historical failure modes associated with the anomaly represented by the triggering event are retrieved from the business semantic graph to form a business context subgraph. Here, a business node refers to a specific functional unit or component in the CMS system related to the anomaly, such as a content storage module, user information database, or third-party CDN interface. Historical failure modes are the correspondences between past failure characteristics and root causes stored in the business semantic graph, such as CDN interface response delay → content loading failure, database connection pool exhaustion → query timeout, etc. The business context subgraph is a local graph directly related to the current triggering event, selected from the complete business semantic graph, focusing on nodes associated with the anomaly, dependency links, and historically similar failures. This step solves the technical problems of fragmented business knowledge and time-consuming information filtering in traditional models by automatically retrieving associated business nodes and historical failure modes. It quickly focuses on the core business context related to the anomaly, providing accurate knowledge support for subsequent root cause reasoning, avoiding interference from irrelevant information, and improving reasoning efficiency.

[0055] The current multidimensional observable data is concatenated and formatted with the business context subgraph to construct a prompt message that can be processed by the large language model. Concatenation and formatting integrate real-time multidimensional data with information from the business context subgraph, organizing it according to a logical structure recognizable by the large language model. For example, the current CMS system content publishing interface response time is 5 seconds (normal threshold ≤ 1 second), associated business nodes: content publishing interface → content storage module → user information database, historical similar fault mode: insufficient user information database connection pool causing interface timeout (failure in October 2025), current database connection pool utilization rate 98% (configuration limit 50). The prompt message is the final structured text input to the large language model, containing abnormal data, business-related background, and historical reference information, ensuring the model can fully understand the fault scenario. This step, through data and knowledge concatenation and formatting, solves the technical problems of data and business context being disconnected and model reasoning lacking complete scenario support, providing the large language model with comprehensive and structured input information, allowing the model to simultaneously grasp the real-time operating status and business background, significantly improving the accuracy of root cause analysis.

[0056] The prompt information is input into the large language model for root cause analysis based on causal reasoning. The large language model is an intelligent model integrating a causal reasoning engine, possessing the ability to understand natural language, correlate multi-source information, and perform logical reasoning; it is the core of the AI ​​root cause analysis engine. Causal reasoning analyzes the causal relationship between real-time abnormal data and potential root causes based on entity dependencies and historical failure patterns in the business semantic graph, rather than simple feature matching. Root cause analysis uses model reasoning to pinpoint the root cause of the anomaly, rather than superficial phenomena. This step, by combining the large language model with causal reasoning, solves the technical problems of traditional root cause analysis—relying on manual intervention, low efficiency, and poor accuracy. It completes high-confidence root cause reasoning within 10-30 seconds, compressing the traditional location time of several hours to seconds, while overcoming the limitations of personal experience and accurately identifying the root cause in complex chains.

[0057] The system receives and parses the output of the large language model to generate structured root cause localization information and corresponding remediation suggestions. The root cause localization information includes at least the root cause entity, the impact chain, and the confidence level. The remediation suggestions include operational steps and risk levels. The structured root cause localization information is a clear report organized according to fixed logic, avoiding vague descriptions. The root cause entity refers to the specific object or configuration that directly causes the anomaly. The impact chain refers to the complete path from the root cause to the business anomaly. The remediation suggestions are actionable solutions proposed for the root cause. The risk level is a risk assessment of the remediation operation, providing a reference for manual decision-making. This step, by generating structured information and accurate remediation suggestions, solves the technical problems of vague traditional root cause reports and impractical remediation solutions. It provides on-duty personnel with clear and directly referable root cause information and execution solutions, reducing the cost of manual understanding and decision-making. Simultaneously, the risk level prompts mitigate operational risks, laying the foundation for subsequent automated remediation or rapid manual processing.

[0058] Based on the above embodiments, as a preferred implementation, step S4 specifically includes: When the confidence level of the root cause location information is higher than a preset threshold, the system determines whether the corresponding fault scenario meets the automatic repair conditions according to preset rules. The automatic repair conditions include that the root cause of the fault belongs to a defined standardized type and that the repair operation has a verified security solution. The confidence level of the root cause location information is a reliability score of the root cause judgment by a large language model, calculated based on historical fault matching degree, causal link integrity, and data support strength. The preset threshold is the critical value for determining whether to initiate automatic repair. It can be manually configured by the user based on the importance of the CMS system's core business (such as content publishing and user authentication) or dynamically adjusted by the system based on historical repair success rate and false positive rate. The preset rules are the system's built-in judgment logic, clearly defining the processing strategies corresponding to different confidence levels and different fault types. The automatic repair conditions are the prerequisites for allowing the system to automatically execute repairs. Defined standardized types include inconsistencies between design and implementation, basic coding errors, and high-frequency faults recorded in historical fault review reports. Verified security solutions refer to repair operations that have been verified in historical practice to have no regression risk and do not affect related business links (e.g., the solution for adjusting connection pool configuration has been verified multiple times in the test environment). This step, through confidence screening and fault scenario judgment, solves the technical problems of unclear automation boundaries and uncontrollable risks in traditional repair modes. It accurately identifies fault scenarios suitable for automatic repair, ensuring automation efficiency while avoiding misoperation in high-risk scenarios, laying the foundation for subsequent safe and automated repair.

[0059] If the assessment confirms a match, a repair script containing specific code modifications or configuration changes is automatically generated based on the repair recommendations. This repair script is an automatically generated, executable code file or configuration file that serves as the implementation of the repair recommendations. Code modifications address root causes at the coding level, such as basic syntax errors and logical vulnerabilities. Configuration changes address root causes related to system configuration, such as unreasonable parameter configurations or changes in dependent service addresses, such as adjusting database connection timeouts or updating third-party CDN interface authentication keys. This step, by automating the generation of accurate repair scripts, solves the technical problems of low efficiency and error-proneness associated with traditional manual repair. It eliminates the need for manual code writing or configuration, directly generating an executable repair tool, significantly shortening repair preparation time while ensuring the accuracy and standardization of the repair content and reducing regression risk.

[0060] The process involves calling the version control system's application programming interface (API) to create a fix request in the specified code repository. This request includes the fix script, root cause analysis summary, and modification context. The version control system refers to a GitOps repository, a centralized storage and version management platform for CMS system code and configuration. The API acts as a bridge between the system and the version control system, supporting automated creation and submission of fix requests. The specified code repository is the code repository for the corresponding business module of the CMS system, representing a formal submission request containing the fix content to trigger the review and merge process. The root cause analysis summary is the core extraction of S3 root cause location information. The modification context provides the business background of the fix operation, including related business modules, historical failure cases, and the basis for the modification. This step, by automating the creation of a fix request with complete context, solves the technical problems of non-standardized and incomplete information in traditional fix submission processes. It achieves standardized and automated submission of fix requests, allowing reviewers to quickly grasp the root cause, content, and scope of impact of the fix, reducing review comprehension costs, improving cross-team collaboration efficiency, and complying with GitOps version management standards to ensure the traceability of the fix process.

[0061] The repair request is associated with the triggering event, and a notification is pushed to the designated audit terminal. Associating the repair request with the triggering event binds the current repair request to the abnormal triggering event generated by S2, using a unique identifier to link the entire chain of fault detection, root cause analysis, and repair execution information, facilitating subsequent source tracing. The designated audit terminal is a preset enterprise collaboration platform (such as Lark or WeChat Work), serving as the carrier for on-duty personnel to receive audit tasks. Pushing the notification automatically sends a reminder to the audit terminal containing a link to the repair request, a root cause analysis summary, and core information about the modification context. This step, through triggering event association and precise notification push, solves the technical problems of inefficiency and incomplete information transmission in traditional audit notification methods, achieving full-chain source tracing of repair requests and fault events. It also ensures that on-duty personnel receive audit tasks promptly and grasp core information, significantly shortening audit response time and providing assurance for subsequent one-click release and minute-level fault recovery.

[0062] Based on the above embodiments, as a preferred implementation, step S6 specifically includes: Based on the triggering event, the root cause location information, the repair suggestions, and the repair execution results, a structured debriefing report is automatically generated. The debriefing report includes at least the fault phenomenon, root cause conclusion, repair measures, and prevention suggestions. The triggering event is the abnormal signal detected in S2, including the abnormality type, occurrence time, and associated business nodes. The root cause location information is the structured result output by S3, including the root cause entity, the impact chain, and the confidence level. The repair suggestions are the executable solutions proposed in S3. The repair execution results are the implementation status in S5, including approval status, successful release, and whether the fault has been recovered. The structured debriefing report is a standardized document automatically generated by the system, distinct from traditional unstructured records. It includes an objective description of the abnormal behavior of the fault phenomenon, a precise summary of the essence of the fault, actual actions taken in the repair measures, and solutions to avoid similar faults. This step, by automatically integrating end-to-end data to generate a structured report, solves the technical problems of low efficiency and difficulty in knowledge accumulation in traditional debriefing, quickly forming standardized and traceable fault handling experience, providing high-quality materials for subsequent knowledge reuse and system evolution, while reducing the time cost of manual debriefing.

[0063] The debriefing report is used as a new knowledge source to identify and extract newly added or changed entities, relationships, and attributes. The new knowledge source is the structured debriefing report confirmed by the responsible party, containing new experiences or updates to existing knowledge related to the handling of this fault. Entities may include newly emerging fault types or unrecorded root cause objects. Relationships refer to newly added logical connections. Attributes refer to the characteristics of newly added or changed entities. This step, through automated identification and extraction of core knowledge elements, solves the technical problems of low efficiency and high subjectivity in traditional knowledge extraction. It quickly transforms implicit experiences in the debriefing report into explicit knowledge elements, providing accurate and standardized input for updating the business semantic graph, ensuring the integrity and efficiency of knowledge accumulation.

[0064] Based on the extraction results, the business semantic graph is updated, including adding new graph nodes and edges, and updating the vectorized representation of existing nodes. The extraction results refer to the newly added or changed entities, relationships, and attributes obtained in previous steps. Adding new graph nodes and edges means adding new entities as nodes to the business semantic graph and establishing connections as edges. Updating the vectorized representation of existing nodes involves using a pre-trained large language model to synchronize changes in entity attributes to the high-dimensional semantic vectors of the corresponding nodes, ensuring that the model can access the latest knowledge during subsequent inference. This step, by updating the graph structure and vector representation based on the extraction results, solves the technical problem of traditional graphs lacking dynamic evolution capabilities, ensuring the business semantic graph maintains its timeliness and completeness. This allows subsequent root cause analysis to be based on the latest business knowledge and failure modes, significantly improving the accuracy and coverage of inference.

[0065] The key metrics and knowledge update records of this fault handling are persistently stored to drive the continuous evolution of the business semantic graph and correlation analysis model. Key metrics refer to the core data of this fault handling, including fault recovery time, root cause location reliability, success rate of repair plan execution, and review time. Knowledge update records include the core content of the debriefing report, node / edge information of graph updates, and vector adjustment records. Persistent storage involves storing the above data and records in an enterprise knowledge base (such as a GitOps repository or dedicated database) to ensure long-term retention and traceability. The correlation analysis model refers to the large language model and causal inference engine in S3. This step, by persistently storing key information and driving evolution, solves the technical problem of the disconnect between fault handling and knowledge accumulation in the traditional model, forming a positive self-evolutionary flywheel of fault handling → knowledge accumulation → model optimization → efficiency improvement. As usage time increases, the knowledge coverage of the business semantic graph becomes more comprehensive, the inference accuracy of the correlation analysis model becomes higher, and the fault scenarios that the system can self-heal continuously expand, gradually realizing the evolution from minute-level recovery to near-zero intervention self-healing, fundamentally improving the stability and intelligent operation and maintenance level of the CMS system.

[0066] Secondly, embodiments of the present invention provide a fault self-healing system based on business semantic graphs and large language models, and a fault self-healing method based on business semantic graphs and large language models based on the above embodiments, such as... Figure 3 As shown, it includes: The business semantic graph construction and update module 310 is used to extract entities, relationships and attributes that represent business logic, entity relationships and historical failure modes based on preset business knowledge data; and to vectorize the entities, relationships and attributes to construct and continuously update a dynamic business semantic graph. The multidimensional observable data acquisition and anomaly detection module 320 is used to acquire multidimensional observable data of the production environment in real time and perform real-time analysis on the multidimensional observable data. When the analysis result indicates an anomaly, a trigger event is generated. The root cause analysis and remediation suggestion generation module 330 is used to respond to the triggering event by jointly inputting the current multidimensional observable data and the business semantic graph into the large language model to output root cause location information and corresponding remediation suggestions. The automated repair request generation module 340 is used to automatically generate a repair request containing code modifications or configuration changes in a specified version control system based on the repair suggestion if the confidence level of the root cause location information is higher than a preset threshold and the fault scenario corresponding to the root cause location information meets the preset automatic repair conditions. The review and release execution module 350 is used to push the repair request for review, and automatically execute the build, test and release process to complete the repair after the review is passed; The review and graph update module 360 ​​is used to automatically generate a structured review report based on the current processing after the fault is recovered, and update the business semantic graph according to the review report.

[0067] Based on the same concept, this invention also provides a schematic diagram of a physical structure, such as... Figure 4 As shown, the server may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can invoke logical instructions stored in the memory 430 to execute the steps of the fault self-healing method based on business semantic graphs and large language models as described in the above embodiments.

[0068] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 described in the various embodiments of the present invention. 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.

[0069] Based on the same concept, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a master control device to control the master control device to implement the steps of the fault self-healing method based on business semantic graph and large language model as described in the above embodiments.

[0070] Based on the same technical concept, this application also provides a computer program, which, when executed by a main control device, is used to implement the above-described method embodiments.

[0071] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0072] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0073] The various embodiments of the present invention can be combined arbitrarily to achieve different technical effects.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fault self-healing method based on business semantic graph and large language model, characterized in that, include: S1. Based on preset business knowledge data, extract entities, relationships, and attributes used to represent business logic, entity relationships, and historical failure modes; The entities, relationships, and attributes are vectorized to construct and continuously update a dynamic business semantic graph; S2. Collect multidimensional observable data of the production environment in real time, and perform real-time analysis on the multidimensional observable data. When the analysis result indicates an anomaly, generate a trigger event. S3. In response to the triggering event, the current multidimensional observable data and the business semantic graph are jointly input into the large language model to output root cause localization information and corresponding repair suggestions; S4. If the confidence level of the root cause location information is higher than a preset threshold, and the fault scenario corresponding to the root cause location information meets the preset automatic repair conditions, then based on the repair suggestion, a repair request containing code modification or configuration change is automatically generated in the specified version control system. S5. Push the repair request for review, and automatically execute the build, test and release process to complete the repair after the review is approved; S6. After the fault is recovered, a structured debriefing report is automatically generated based on the current processing, and the business semantic graph is updated according to the debriefing report.

2. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, In S1, the preset business knowledge data includes at least one of the following: business architecture document, core link source code, historical fault review report, standard operating procedure (SOP), and business link topology diagram. The vectorization process includes: A pre-trained language model is used to semantically encode the extracted entities, relations, and attributes to generate corresponding vector representations; The business semantic graph is kept in real-time synchronized with newly added business knowledge data through an event bus.

3. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, In S2, the multidimensional observable data includes server hardware metrics, distributed tracing data, full business logs, database slow query logs, and external dependent service status data. The server hardware metrics include CPU utilization, memory usage, IO throughput, and network bandwidth.

4. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, In step S2, the multidimensional observable data is analyzed in real time. When the analysis result indicates an anomaly, a trigger event is generated, including: The collected multidimensional observable data are subjected to unified normalization processing; The anomaly detection engine extracts real-time data features from the normalized data. The real-time data features are compared with a preset normal threshold range and / or a historical fault feature library; When the comparison result meets the preset anomaly judgment conditions, a trigger event is generated. The trigger event includes the anomaly type, the occurrence time, and the associated business node information.

5. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, S3 specifically includes: In response to the triggering event, business nodes and historical fault modes associated with the anomaly represented by the triggering event are retrieved from the business semantic graph to form a business context subgraph; The current multidimensional observable data is combined with the business context subgraph and formatted to construct a prompt message that can be processed by a large language model; The prompt information is input into the large language model for root cause analysis of causal reasoning; The system receives and parses the output of the large language model to generate structured root cause localization information and corresponding remediation suggestions. The root cause localization information includes at least the root cause entity, the impact chain, and the confidence level. The remediation suggestions include operation steps and risk levels.

6. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, S4 specifically includes: When the confidence level of the root cause location information is higher than a preset threshold, the corresponding fault scenario is judged according to the preset rules to determine whether it meets the automatic repair conditions. The automatic repair conditions include that the root cause of the fault belongs to a defined standardized type and the repair operation has a verified safety scheme. If the determination is met, a repair script containing specific code modifications or configuration changes will be automatically generated based on the repair suggestions. Call the application programming interface of the version control system to create a fix request in the specified code repository, which includes the fix script, root cause analysis summary and modification context; The repair request is associated with the triggering event, and a generation notification is pushed to the designated audit terminal.

7. The fault self-healing method based on business semantic graph and large language model according to claim 1, characterized in that, S6 specifically includes: Based on the triggering event, the root cause location information, the repair suggestions, and the repair execution results, a structured debriefing report is automatically generated. The debriefing report includes at least the fault phenomenon, root cause conclusion, repair measures, and prevention suggestions. The review report is used as a new knowledge source to identify and extract newly added or changed entities, relationships, and attributes. Based on the extraction results, the business semantic graph is updated, including adding new graph nodes and edges, and updating the vectorized representation of existing nodes; The key indicators and knowledge update records of this fault handling will be persistently stored to drive the continuous evolution of the business semantic graph and association analysis model.

8. A fault self-healing system based on business semantic graphs and large language models, characterized in that, include: The business semantic graph construction and update module is used to extract entities, relationships and attributes that represent business logic, entity relationships and historical failure modes based on preset business knowledge data; and to vectorize the entities, relationships and attributes to construct and continuously update a dynamic business semantic graph. The multidimensional observable data acquisition and anomaly detection module is used to acquire multidimensional observable data of the production environment in real time and perform real-time analysis on the multidimensional observable data. When the analysis results indicate an anomaly, a trigger event is generated. The root cause analysis and remediation suggestion generation module is used to respond to the triggering event by jointly inputting the current multidimensional observable data and the business semantic graph into the large language model to output root cause location information and corresponding remediation suggestions. An automated repair request generation module is used to automatically generate a repair request containing code modifications or configuration changes in a specified version control system based on the repair suggestions if the confidence level of the root cause location information is higher than a preset threshold and the fault scenario corresponding to the root cause location information meets preset automatic repair conditions. The review and release execution module is used to push the repair request for review, and automatically execute the build, test and release process to complete the repair after the review is approved; The review and graph update module is used to automatically generate a structured review report based on the current processing after the fault is recovered, and update the business semantic graph according to the review report.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the fault self-healing method based on business semantic graph and large language model as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the fault self-healing method based on business semantic graphs and large language models as described in any one of claims 1 to 7.

Images