Operation and maintenance knowledge graph matching method and device, equipment and storage medium

Abstract

The invention discloses an operation and maintenance knowledge graph matching method and device, equipment and a storage medium, and the method comprises the steps: obtaining historical fault data, and constructing a fault knowledge graph according to the historical fault data; when a new fault occurs, extracting new fault features, and matching the new fault features through the fault knowledge graph to obtain similar fault data; and generating a fault matching report based on the similar fault data. Information isolation can be broken through by constructing a fault knowledge graph, multi-dimensional association of fault-related entities is established, and a hidden causal relationship is mined. The core information of the new fault can be quickly extracted by extracting the new fault feature, the subsequent matching efficiency is improved, the historical case which is highly matched can be quickly positioned by matching the new fault feature through the knowledge graph, the matching result is ensured to be accurate and comprehensive, and the manual screening cost is reduced. And the generated fault matching report can structurally present similar fault key information, so that troubleshooting direction and action suggestions are intuitively provided for users, and the decision-making difficulty is reduced.

Description

Technical Field

[0001] This invention relates to the field of system operation and maintenance, and in particular to an operation and maintenance knowledge graph matching method, apparatus, equipment and storage medium. Background Technology

[0002] In digital operations and maintenance scenarios, system complexity continues to increase, fault triggering factors are becoming increasingly diverse, and heterogeneous data from multiple sources, such as logs, monitoring metrics, and service topologies, are experiencing explosive growth. Operational fault diagnosis is directly related to business continuity and system availability, making rapid root cause identification and the reuse of historical handling experience core requirements.

[0003] Currently, existing technologies in the field of operation and maintenance fault diagnosis mainly fall into two categories: one is a historical fault storage and retrieval scheme based on traditional databases, which stores basic fault information, root causes and solutions in tabular form, and relies on precise keyword matching during retrieval; the other is a fault association analysis technology based on simple algorithms, which performs preliminary filtering and feature extraction on fault data to assist operation and maintenance personnel in locating fault points.

[0004] Traditional database storage models lead to isolated fault-related knowledge, failing to discover indirect relationships between services, metrics, and root causes, resulting in biased retrieval results. Simple algorithms can only perform preliminary data processing, lacking effective integration of historical experience. Fault diagnosis still heavily relies on the personal experience of senior operations and maintenance personnel, making it difficult to pass on experience and creating a high barrier to entry for newcomers. At the same time, existing technologies have not solved the problem of deep integration of multi-source heterogeneous data, making it impossible to perform accurate matching based on comprehensive features. This results in fault location taking an average of tens of hours, leading to low diagnostic efficiency. Some faults even fail to find a clear root cause reference, seriously affecting the speed of business recovery. Summary of the Invention

[0005] This invention provides an operation and maintenance knowledge graph matching method, device, equipment, and storage medium. By constructing an operation and maintenance knowledge graph that integrates multi-dimensional fault features and adopting a multi-dimensional weighted similarity intelligent matching method, it solves the technical problems of traditional operation and maintenance fault diagnosis, such as reliance on personal experience, difficulty in knowledge inheritance, low diagnostic efficiency, and difficulty in effectively integrating multi-source heterogeneous data.

[0006] According to one aspect of the present invention, an operation and maintenance knowledge graph matching method is provided, the method comprising: Acquire historical fault data and construct a fault knowledge graph based on the historical fault data; When a new fault occurs, new fault features are extracted, and the fault knowledge graph is used to match the new fault features to obtain similar fault data. A fault matching report is generated based on similar fault data.

[0007] Optionally, historical fault data can be acquired, including: defining the data collection scope, which includes basic attributes, fault characteristics, quantitative indicators, analysis results, and solutions; collecting original fault data that has been resolved in the operation and maintenance scenario based on the data collection scope; cleaning the original fault data to generate cleaned original fault data; and mapping the cleaned original fault data into a structure according to preset fields to generate historical fault data.

[0008] Optionally, a fault knowledge graph is constructed based on historical fault data, including: extracting graph nodes from historical fault data according to predefined entity types, where entity types include service, resource, error code, indicator, root cause, and operation types; establishing semantic associations in the extracted graph nodes based on predefined relationship types to form graph links, where relationship types include generation, cause, influence, aggravation, and resolution; and storing the identified graph nodes and established graph links in a graph database to form a fault knowledge graph.

[0009] Optionally, when a new fault occurs, new fault features are extracted, including: when a new fault occurs, new fault data is collected in real time, including alarm data, log data, and monitoring data; initial fault features are extracted from the new fault data according to preset dimensions, including keywords, log templates, abnormal indicators, topology services, and root cause categories; the integrity of the initial fault features is verified, and new fault features are formed after the verification passes.

[0010] Optionally, the new fault features are matched using a fault knowledge graph to obtain similar fault data, including: directly searching the fault knowledge graph based on keywords in the new fault features to obtain directly matched fault data; performing association-based extended retrieval in the fault knowledge graph based on the new fault features to obtain indirectly matched fault data; and determining similar fault data based on the directly matched fault data and the indirectly matched fault data.

[0011] Optionally, similar fault data can be determined based on directly matched fault data and indirectly matched fault data, including: merging directly matched fault data and indirectly matched fault data, removing duplicate faults, and forming a candidate fault set; calculating the similarity between each candidate fault data in the candidate fault set and the new fault features to obtain a similarity score; sorting each candidate fault data in descending order of similarity score to obtain a sorted candidate fault set; and selecting a specified number of candidate fault data from the sorted candidate fault set as similar fault data.

[0012] Optionally, the method further includes: obtaining user feedback information based on the fault matching report, wherein the user feedback information includes valid information and invalid information; and updating the fault knowledge graph based on the valid information.

[0013] According to another aspect of the present invention, an operation and maintenance knowledge graph matching device is provided, the device comprising: The knowledge graph construction module is used to acquire historical fault data and construct a fault knowledge graph based on the historical fault data. The similar fault matching module is used to extract new fault features when a new fault occurs, and to match the new fault features with the fault knowledge graph to obtain similar fault data. The matching report generation module is used to generate fault matching reports based on similar fault data.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the operation and maintenance knowledge graph matching method according to any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement an operation and maintenance knowledge graph matching method as described in any embodiment of the present invention.

[0016] The technical solution of this invention, by constructing a fault knowledge graph, breaks down information silos, establishes multi-dimensional associations between fault-related entities, and uncovers hidden causal relationships. Extracting new fault features allows for the rapid refinement of core information about new faults, improving subsequent matching efficiency. Matching new fault features using the knowledge graph enables the rapid location of highly relevant historical cases, ensuring accurate and comprehensive matching results and reducing manual screening costs. The generated fault matching report presents key information about similar faults in a structured manner, providing users with intuitive troubleshooting directions and action suggestions, thus reducing decision-making difficulty.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0019] Figure 1 This is a flowchart of an operation and maintenance knowledge graph matching method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of another operation and maintenance knowledge graph matching method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the structure of an operation and maintenance knowledge graph matching device according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements an operation and maintenance knowledge graph matching method according to an embodiment of the present invention. Detailed Implementation

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

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] Example 1 Figure 1This invention provides a flowchart of an operation and maintenance knowledge graph matching method according to Embodiment 1. This embodiment is applicable to knowledge graph matching scenarios. The method can be executed by an operation and maintenance knowledge graph matching device, which can be implemented in hardware and / or software and can be configured in a computer controller. Figure 1 As shown, the method includes: S110. Obtain historical fault data and construct a fault knowledge graph based on the historical fault data.

[0023] Historical fault data refers to all processed operational fault information, which is structured and organized into standard fault records. Fault knowledge graph refers to a structured knowledge storage and association model for operational fault scenarios. It abstracts fault-related heterogeneous data into entities, establishes associations through predefined relationships such as generation, cause, impact, and resolution, and forms a visual graph network to achieve deep association and rapid retrieval of fault knowledge.

[0024] Optionally, historical fault data can be acquired, including: defining the data collection scope, which includes basic attributes, fault characteristics, quantitative indicators, analysis results, and solutions; collecting original fault data that has been resolved in the operation and maintenance scenario based on the data collection scope; cleaning the original fault data to generate cleaned original fault data; and mapping the cleaned original fault data into a structure according to preset fields to generate historical fault data.

[0025] The basic attributes include the specific time the fault occurred, the maintenance personnel who handled the fault, and the unique identifier corresponding to the fault; the fault characteristics include the specific phenomena presented when the fault occurred, the key services involved, the core error codes, and related log fragments; the quantitative indicators refer to the abnormal monitoring data that occurred when the fault occurred, such as the number of database connections surging from 50 to 480, or the Redis response time increasing from 5ms to 500ms, etc., reflecting the severity and scope of the fault through specific numerical changes; the analysis results mainly refer to the determination of the root cause of the fault by humans or the system, including the root cause category and the specific root cause; the solution refers to the specific actions taken to successfully resolve the fault.

[0026] Specifically, based on the data collection scope defined above, the system will collect raw fault data that has been resolved in the operation and maintenance scenario. The collection targets all processed and closed-loop fault cases. Data sources include documents recorded by operation and maintenance personnel during fault handling, indicator data stored on the system monitoring platform, various logs retained by the log system, and records from fault reporting and processing forms. Then, the system will perform data cleaning on the collected raw fault data to remove invalid, redundant, and erroneous data, ensuring data accuracy and usability. That is, the system will filter out meaningless duplicate segments and incorrectly formatted or unrecognizable records from logs, correct erroneous values ​​in indicator data caused by monitoring equipment malfunctions, supplement missing key information in some fault records, and standardize data formats. For example, it will adjust fault times with inconsistent time formats in different log systems to a unified standard format and convert indicator data from different units to a consistent unit, ultimately generating cleaned raw fault data, laying the foundation for subsequent structured processing.

[0027] The preset fields are a set of standard fields predefined based on the needs of operation and maintenance fault diagnosis, including fault ID, symptom description, key services, core error codes, abnormal indicators, root cause category, specific root cause, solution, processing time, and related log patterns. During the mapping process, the system will map the cleaned raw data to each preset field one by one. For example, the fault phenomenon "user payment failure, error rate soars by 60%" extracted from the raw fault data is mapped to the "symptom description" field, and the error code WX_408 is mapped to the "core error code" field. At the same time, all preset field information is improved through a combination of automatic extraction by the system and manual supplementation, and finally standardized and structured historical fault data is formed. This data can be directly used for the subsequent construction of fault knowledge graph.

[0028] Optionally, a fault knowledge graph is constructed based on historical fault data, including: extracting graph nodes from historical fault data according to predefined entity types, where entity types include service, resource, error code, indicator, root cause, and operation types; establishing semantic associations in the extracted graph nodes based on predefined relationship types to form graph links, where relationship types include generation, cause, influence, aggravation, and resolution; and storing the identified graph nodes and established graph links in a graph database to form a fault knowledge graph.

[0029] The entity types include service, resource, error code, metric, root cause, and operation types. Service entities are extracted from key service fields in historical fault data, such as payment services, order services, and authentication services. Resource entities come from hardware and software resource information associated with the fault, such as databases, Redis, and MySQL, which are the basic resources supporting service operation. Error code entities are extracted from core error code fields, such as WX_408 and AUTH_SERVICE_TIMEOUT, which are one of the direct identifiers of the fault. Metric entities correspond to the monitoring metric names in the abnormal metric field, such as interface response time and database connection count, which can quantify the degree of abnormality of the fault. Root cause entities are derived from the root cause category and specific root cause field, such as WeChat interface upgrade, Redis memory overflow, and third-party interface change, which clearly identify the essential cause of the fault. Operation entities are extracted from the solution field, such as updating the payment gateway and optimizing the cache key expiration policy, which are the specific actions taken to resolve the fault. During the extraction process, open-source tools can be used to automatically identify and extract entities, while manual verification is combined to ensure the accuracy and completeness of entity extraction, ultimately forming the core node set of the graph.

[0030] Specifically, when establishing associations, the system can match the fault occurrence logic and processing procedures in historical fault data one by one. Generative relationships are used to connect service entities with error code entities. For example, establishing a generative relationship between the payment service and error code WX_408 indicates that this error code was generated during the operation of the payment service. Causative relationships are used to associate root cause entities with service anomaly-related entities. For example, establishing a causal relationship between the root cause entity of WeChat interface upgrades and payment service anomalies demonstrates the direct impact of the root cause on the service. Influencing relationships are applicable to associations between service entities. For example, establishing an influence relationship between payment service anomalies and order services indicates that a failure in the payment service will affect the normal operation of the order service. Exacerbating relationships describe the cumulative effect of different fault-related entities on the core fault. For example, establishing an exacerbating relationship between a resource entity with full database connections and payment service anomalies indicates that database connection problems will worsen the anomaly in the payment service. Resolving relationships are used to connect operation entities with root cause entities, representing that the operation can specifically resolve the fault caused by the corresponding root cause. When establishing associations, it is necessary to strictly adhere to the actual logic in historical fault data to ensure the accuracy of the relationships and avoid false associations affecting the usability of the graph.

[0031] Finally, the identified graph nodes and established graph links are stored in a graph database to form a fault knowledge graph. During storage, the extracted six categories of graph nodes are first formatted according to the database's storage specifications, clarifying the unique identifier, entity type, and specific attribute information of each node, and supplementing relevant descriptive information. Then, the established graph links are converted according to the relational storage format supported by the database, clarifying the source node, target node, and relation type for each link. Afterwards, the formatted node data and link data are batch-written into the graph database through the database interface, completing the initial construction of the fault knowledge graph.

[0032] S120. When a new fault occurs, extract the new fault features and match them with the fault knowledge graph to obtain similar fault data.

[0033] Among them, new fault features refer to the set of key attributes extracted from logs, monitoring metrics, and alarm information after a new fault occurs. Similar fault data refers to the set of historical fault cases with high overall similarity to the new fault, selected through fault knowledge graph matching.

[0034] Optionally, when a new fault occurs, new fault features are extracted, including: when a new fault occurs, new fault data is collected in real time, including alarm data, log data, and monitoring data; initial fault features are extracted from the new fault data according to preset dimensions, including keywords, log templates, abnormal indicators, topology services, and root cause categories; the integrity of the initial fault features is verified, and new fault features are formed after the verification passes.

[0035] Specifically, when a new fault occurs, a real-time data acquisition mechanism is first activated to comprehensively collect all types of data related to the new fault, ensuring that no critical information is missed. Alarm data comes from the system's alarm notification module, including the alarm type, alarm level, alarm trigger time, and associated basic service identifiers; log data comes from the log systems of each service node, recording the program's execution status and error messages at the time of the fault; and monitoring data comes from the system monitoring platform, capturing various indicator data before and after the fault occurs in real time.

[0036] Then, initial fault features are extracted from the new fault data according to five preset dimensions: keywords, log templates, anomaly indicators, topology services, and root cause categories. For keyword extraction, text analysis techniques are used to filter words or phrases that characterize the core features of the fault from alarm information and log content. Log template extraction utilizes the Drain algorithm from the existing diagnostic framework to perform pattern recognition and clustering on log data, extracting log templates with common structures, removing variables, and retaining the core fault scenario description. Anomaly indicator extraction filters indicators that deviate from the normal range from monitoring data, identifying the indicator name, abnormal value, and trend, quantifying the severity of the fault. Topology service extraction analyzes the service identifier associated with the alarm and the service node to which the log belongs to determine the core services involved in the fault. Root cause category extraction, based on the existing fault root cause classification system and combined with preliminary features such as keywords and log templates, predicts the possible root cause category of the fault.

[0037] Finally, the system performs a completeness check on the extracted initial fault features. This check ensures that the initial fault features fully support subsequent fault matching. The check criteria include: the keyword dimension must contain at least one core error code or core fault description term; the log template dimension must extract a clear template structure that reflects the core fault scenario; the anomaly indicator dimension must have specific anomaly indicator names, values, and normal range references; the topology service dimension must clearly identify at least one directly related core service; and the root cause category dimension must have a clear predicted category or a reasonable range of categories to be investigated. If a feature in a certain dimension is found to be missing or unclear during the check—for example, no core error code is extracted, or there is no normal range reference for anomaly indicators—the system will automatically trigger a supplementary collection mechanism to re-retrieve relevant new fault data or prompt maintenance personnel to supplement key information. If all preset dimensions of features meet the completeness requirements, the check passes, and the system integrates the checked features to form the final new fault features, providing accurate and comprehensive feature basis for subsequent matching using the fault knowledge graph.

[0038] S130. Generate a fault matching report based on similar fault data.

[0039] Among them, the fault matching report refers to the structured diagnostic document automatically generated by the system based on similar fault data, which is used to guide operation and maintenance personnel to quickly troubleshoot new faults.

[0040] Specifically, the fault matching report will clearly state the new fault signature and matching time, and then list recommended historical cases in descending order of comprehensive similarity score. Each case will present the historical phenomenon, root cause, solution, and related indicators in detail, and provide targeted diagnostic tips. Finally, action suggestions will be given based on the priority of the recommended cases, guiding operations and maintenance personnel to prioritize the path of the highest matching case for troubleshooting. If it does not meet the criteria, the investigation scope can be expanded by referring to the lower matching cases, helping operations and maintenance personnel to quickly locate the root cause of new faults and take effective solutions.

[0041] Optionally, the method further includes: obtaining user feedback information based on the fault matching report, wherein the user feedback information includes valid information and invalid information; and updating the fault knowledge graph based on the valid information.

[0042] Specifically, the system collects feedback from operations and maintenance personnel on the effectiveness of recommended case matching after handling new faults using reference reports. Feedback is primarily categorized into valid and invalid information. Users submit feedback through the system's user interface, which provides clear feedback options, such as "case valid," "case invalid," and supplementary explanation fields. Valid information indicates that operations and maintenance personnel confirm that the recommended similar fault cases closely match the root cause and solution of the new fault, accurately guiding fault handling. For example, if the new fault is Redis latency causing login timeout, the recommended case "Redis memory overflow causing authentication timeout" helps operations and maintenance personnel quickly locate and resolve the problem; the user submits a valid case, and the fault is successfully resolved according to the recommended solution. Invalid information, on the other hand, indicates that the recommended cases do not match the new fault and cannot provide effective guidance. For example, a recommended case related to a full database connection pool is irrelevant to the root cause of the new fault; the operations and maintenance personnel submit an invalid case, indicating a mismatch in root causes. Other negative feedback includes cases where the solution is not applicable to the new fault or the similarity score is unreasonable. Users can also provide additional details, such as specifying in invalid feedback that the new fault is due to Redis network latency rather than a memory issue, providing detailed evidence for subsequent graph updates and weight adjustments.

[0043] Furthermore, updating the fault knowledge graph based on valid information involves integrating the valid handling information of new faults into the existing graph, enabling the graph to evolve and making subsequent matching more accurate. First, the system extracts complete information about the new fault corresponding to valid feedback, including the structured features of the new fault, the ultimately verified root cause, and the effective solution. Then, according to the entity type definition of the knowledge graph, the system extracts new entities from the new fault information. If the new fault involves services, error codes, or metrics not present in the graph, it will be added as a new node. Next, based on predefined relationship types, semantic associations are established between the new entities and existing entities in the graph. Finally, the new entities and relationships are stored in the graph database, completing the expansion of graph nodes and links. Additionally, if the valid feedback includes supplementary association information for matching similar cases, such as a user labeling a new fault as having a "derived relationship" with a historical case, the system will establish a "evolved from..." association between the corresponding two case nodes, further enriching the graph's association dimensions. This allows the fault knowledge graph to continuously improve with the accumulation of valid feedback, continuously enhancing the accuracy and effectiveness of subsequent fault matching.

[0044] The technical solution of this invention, by constructing a fault knowledge graph, breaks down information silos, establishes multi-dimensional associations between fault-related entities, and uncovers hidden causal relationships. Extracting new fault features allows for the rapid refinement of core information about new faults, improving subsequent matching efficiency. Matching new fault features using the knowledge graph enables the rapid location of highly relevant historical cases, ensuring accurate and comprehensive matching results and reducing manual screening costs. The generated fault matching report presents key information about similar faults in a structured manner, providing users with intuitive troubleshooting directions and action suggestions, thus reducing decision-making difficulty.

[0045] Example 2 Figure 2 This is a flowchart of a maintenance knowledge graph matching method provided in Embodiment 2 of the present invention. This embodiment adds a specific process for matching new fault features using a fault knowledge graph to obtain similar fault data, based on Embodiment 1. The specific content of steps S210 and S290 is largely the same as steps S110 and S130 in Embodiment 1, and therefore will not be repeated in this embodiment. Figure 2 As shown, the method includes: S210. Obtain historical fault data and construct a fault knowledge graph based on the historical fault data.

[0046] Optionally, historical fault data can be acquired, including: defining the data collection scope, which includes basic attributes, fault characteristics, quantitative indicators, analysis results, and solutions; collecting original fault data that has been resolved in the operation and maintenance scenario based on the data collection scope; cleaning the original fault data to generate cleaned original fault data; and mapping the cleaned original fault data into a structure according to preset fields to generate historical fault data.

[0047] Optionally, a fault knowledge graph is constructed based on historical fault data, including: extracting graph nodes from historical fault data according to predefined entity types, where entity types include service, resource, error code, indicator, root cause, and operation types; establishing semantic associations in the extracted graph nodes based on predefined relationship types to form graph links, where relationship types include generation, cause, influence, aggravation, and resolution; and storing the identified graph nodes and established graph links in a graph database to form a fault knowledge graph.

[0048] S220. When a new fault occurs, extract the characteristics of the new fault.

[0049] Optionally, when a new fault occurs, new fault features are extracted, including: when a new fault occurs, new fault data is collected in real time, including alarm data, log data, and monitoring data; initial fault features are extracted from the new fault data according to preset dimensions, including keywords, log templates, abnormal indicators, topology services, and root cause categories; the integrity of the initial fault features is verified, and new fault features are formed after the verification passes.

[0050] S230. Based on the keywords in the new fault features, directly search in the fault knowledge graph to obtain directly matching fault data.

[0051] Specifically, when searching directly in the fault knowledge graph based on keywords in new fault features to obtain directly matching fault data, the system utilizes core identifier keywords to quickly locate highly relevant historical faults. Keywords in new fault features mainly include core error codes and core fault description terms. For example, error codes such as "AUTH_SERVICE_TIMEOUT" and "WX_408" in new fault features, or core fault descriptions such as "Redis slow" and "payment failure," will be used as search criteria. The system will traverse all nodes in the fault knowledge graph, focusing on matching keywords in error code entities and symptom description-related entities. When a historical fault node in the graph contains completely identical or highly semantically matching keywords, the complete data corresponding to that historical fault will be extracted to form directly matching fault data. Direct search allows for the rapid filtering of historical cases that highly match the new fault features. For example, if the new fault keyword is "AUTH_SERVICE_TIMEOUT," all historical faults in the graph containing that error code will be directly matched, ensuring the accuracy and efficiency of the matching.

[0052] S240. Based on the new fault features, perform association expansion retrieval in the fault knowledge graph to obtain indirectly matched fault data.

[0053] Specifically, when performing association-based extended retrieval in a fault knowledge graph based on new fault features to obtain indirectly matching fault data, the system leverages the association characteristics of the knowledge graph to uncover indirect relationships between new and historical faults, overcoming the limitations of direct matching. First, the system extracts dimensional information such as topology services, anomaly indicators, and root cause categories from the new fault features. Starting with the entities corresponding to this information, the system performs multi-dimensional extended retrieval along predefined relationships such as generation, cause, impact, and aggravation within the knowledge graph. For example, if the new fault feature involves an authentication service entity, the system will find the authentication service node in the graph and then traverse all other nodes related to it, including service nodes affected by the authentication service, root cause nodes causing authentication service anomalies, and anomaly indicator nodes related to the authentication service. This allows the extraction of historical fault data corresponding to the associated nodes. Through indirect association-based extended retrieval, historical faults with indirect causal or relational relationships to the new fault can be uncovered, forming indirectly matching fault data. This overcomes the limitation of direct matching, which can only find similar faults, and discovers hidden similar fault cases.

[0054] S250. Merge the directly matched fault and indirectly matched fault data, remove duplicate faults, and form a candidate fault set.

[0055] Specifically, the system first integrates all content from both types of data. Directly matched fault data consists of highly relevant historical faults precisely located using new fault core keywords, while indirectly matched fault data consists of hidden similar historical faults discovered through graph association expansion mining. Although the two types of data originate from different sources, they may contain some duplicate fault cases. Therefore, the system uses the fault ID as a unique identifier to deduplicate all merged fault data, removing identical fault records to avoid redundancy in subsequent similarity calculations.

[0056] S260. Calculate the similarity between each candidate fault data in the candidate fault set and the new fault features to obtain a similarity score.

[0057] Specifically, when calculating the similarity score, the system determines each comparison dimension and its corresponding weight. Among them, error code keywords account for 30%, log templates account for 25%, anomaly indicators account for 20%, topology services account for 15%, and root cause categories account for 10%, with a total weight of 100%. Then, for each candidate fault data and new fault features, the system calculates the similarity sub-scores for each of the five dimensions, with sub-scores ranging from 0 to 100. In the error code keyword dimension, exact matching is the primary criterion, with semantic similarity as a secondary criterion. Complete matching scores 100 points, partial keyword matching scores 50 points, and irrelevant keywords score 0 points. The log template dimension is judged based on template ID or backbone information: identical templates score 100 points, structurally similar templates score 70 points, and different templates score 0 points. The anomaly indicator dimension requires identical indicator names and consistent numerical change directions to score 100 points; identical indicator names but different changes score 30 points, and different indicators score 0 points. The topology service dimension calculates the ratio of the number of intersection services to the number of union services (Jaccard similarity coefficient), converting it into sub-scores from 0 to 100. The root cause category dimension judges semantic similarity through keywords; issues belonging to the same category receive higher scores, and irrelevant issues receive lower scores. Finally, the system multiplies the sub-scores of each dimension by their corresponding weights to obtain the contribution value of each dimension, and then sums the contribution values ​​of all dimensions to obtain the comprehensive similarity score between the candidate fault data and the new fault features.

[0058] S270. Sort the candidate fault data according to the similarity score from high to low to obtain the sorted candidate fault set.

[0059] Specifically, the system uses similarity scores as the sorting criterion, ranking all cases in the candidate fault set in descending order of score. Higher scores indicate a greater degree of relevance to the new fault in core dimensions such as error codes, log templates, and anomaly indicators, thus providing greater reference value for handling the new fault. If scores are identical during the sorting process, sub-scores in the error code / keyword dimension are further compared, prioritizing cases with higher sub-scores to ensure the reasonableness and accuracy of the sorting results. Ultimately, this forms a candidate fault set ranked by similarity priority.

[0060] S280. Select a specified number of candidate fault data from the sorted candidate fault set as similar fault data.

[0061] The specified number is pre-set based on actual operational needs, typically 3-5. The system will select the top-ranked specified number of cases from the sorted candidate fault set. For example, setting the specified number to 3 will select the top 3 sorted candidate fault cases as similar fault data. Subsequently, a fault matching report containing historical phenomena, root causes, solutions, and diagnostic tips will be generated based on this data, providing accurate and efficient reference for operations personnel to handle new faults.

[0062] S290. Generate a fault matching report based on similar fault data.

[0063] Optionally, the method further includes: obtaining user feedback information based on the fault matching report, wherein the user feedback information includes valid information and invalid information; and updating the fault knowledge graph based on the valid information.

[0064] The technical solution of this invention can quickly identify core matching historical faults and obtain accurate direct matching data by directly searching based on new fault feature keywords. Through associated extended retrieval, indirect relationships between faults can be discovered, supplementing indirect matching data. By merging the two types of data and removing duplicates, a comprehensive and non-redundant candidate fault set is formed. Similarity scores are obtained through multi-dimensional weighted calculations and sorted, clarifying the reference priority of candidate faults. Finally, a specified number of high-value cases are selected as similar fault data, achieving accurate, comprehensive, and efficient screening of matching results.

[0065] Example 3 Figure 3 This is a schematic diagram of the structure of an operation and maintenance knowledge graph matching device provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a knowledge graph construction module 310, used to acquire historical fault data and construct a fault knowledge graph based on the historical fault data; The similar fault matching module 320 is used to extract new fault features when a new fault occurs, and to match the new fault features with the fault knowledge graph to obtain similar fault data. The matching report generation module 330 is used to generate a fault matching report based on similar fault data.

[0066] Optionally, the knowledge graph construction module 310 specifically includes: a historical data collection unit, used to: define the data collection scope, wherein the data collection scope includes basic attributes, fault characteristics, quantitative indicators, analysis results and solutions; collect original fault data that has been resolved in the operation and maintenance scenario based on the data collection scope; clean the original fault data to generate cleaned original fault data; and perform structured mapping on the cleaned original fault data according to preset fields to generate historical fault data.

[0067] Optionally, the knowledge graph construction module 310 specifically includes: a knowledge graph construction unit, used to: extract graph nodes from historical fault data according to predefined entity types, wherein the entity types include service types, resource types, error code types, indicator types, root cause types, and operation types; establish semantic associations in the extracted graph nodes based on predefined relationship types to form graph links, wherein the relationship types include generation, cause, influence, aggravation, and resolution; and store the identified graph nodes and established graph links into a graph database to form a fault knowledge graph.

[0068] Optionally, the similar fault matching module 320 specifically includes: a new fault feature extraction unit, used to: collect new fault data in real time when a new fault occurs, wherein the new fault data includes alarm data, log data and monitoring data; extract initial fault features from the new fault data according to preset dimensions, wherein the preset dimensions include keywords, log templates, abnormal indicators, topology services and root cause categories; perform integrity verification on the initial fault features, and form new fault features after the verification passes.

[0069] Optionally, the similar fault matching module 320 specifically includes: a direct matching unit, used to directly search in the fault knowledge graph based on keywords in the new fault features to obtain directly matched fault data; an indirect matching unit, used to perform association expansion retrieval in the fault knowledge graph based on the new fault features to obtain indirect matched fault data; and a similarity matching unit, used to determine similar fault data based on the directly matched fault data and the indirect matched fault data.

[0070] Optionally, the similarity matching unit is specifically used for: merging directly matched fault data and indirectly matched fault data, removing duplicate faults, and forming a candidate fault set; calculating the similarity between each candidate fault data in the candidate fault set and the new fault features to obtain a similarity score; sorting each candidate fault data in descending order of similarity score to obtain a sorted candidate fault set; and selecting a specified number of candidate fault data from the sorted candidate fault set as similar fault data.

[0071] Optionally, the device further includes: a knowledge graph update module, used to obtain user feedback information based on the fault matching report, wherein the user feedback information includes valid information and invalid information; and to update the fault knowledge graph based on the valid information.

[0072] The technical solution of this invention, by constructing a fault knowledge graph, breaks down information silos, establishes multi-dimensional associations between fault-related entities, and uncovers hidden causal relationships. Extracting new fault features allows for the rapid refinement of core information about new faults, improving subsequent matching efficiency. Matching new fault features using the knowledge graph enables the rapid location of highly relevant historical cases, ensuring accurate and comprehensive matching results and reducing manual screening costs. The generated fault matching report presents key information about similar faults in a structured manner, providing users with intuitive troubleshooting directions and action suggestions, thus reducing decision-making difficulty.

[0073] The operation and maintenance knowledge graph matching device provided in this embodiment of the invention can execute the operation and maintenance knowledge graph matching method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0074] Example 4 Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0075] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0076] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0077] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as an operational knowledge graph matching method.

[0078] In some embodiments, an operations and maintenance knowledge graph matching method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the operations and maintenance knowledge graph matching method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform an operations and maintenance knowledge graph matching method by any other suitable means (e.g., by means of firmware).

[0079] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0080] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0081] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0082] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0083] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0084] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0085] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0086] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for matching an operation and maintenance knowledge graph, characterized in that, include: Acquire historical fault data and construct a fault knowledge graph based on the historical fault data; When a new fault occurs, new fault features are extracted, and the fault knowledge graph is used to match the new fault features to obtain similar fault data. A fault matching report is generated based on the similar fault data.

2. The method according to claim 1, characterized in that, The acquisition of historical fault data includes: Define the scope of data collection, which includes basic attributes, fault characteristics, quantitative indicators, analysis results, and solutions; Based on the aforementioned data collection range, original fault data that has been resolved in the operation and maintenance scenario is collected; The original fault data is cleaned to generate cleaned original fault data. The cleaned original fault data is structured and mapped according to preset fields to generate historical fault data.

3. The method according to claim 2, characterized in that, The construction of the fault knowledge graph based on the historical fault data includes: Extract graph nodes from historical fault data according to predefined entity types, wherein the entity types include service type, resource type, error code type, indicator type, root cause type and operation type; Semantic associations are established among the extracted graph nodes based on predefined relationship types to form graph links, wherein the relationship types include generating, causing, influencing, aggravating, and resolving. The identified graph nodes and established graph links are stored in the graph database to form a fault knowledge graph.

4. The method according to claim 1, characterized in that, When a new fault occurs, the extraction of new fault features includes: When a new fault occurs, new fault data is collected in real time, including alarm data, log data, and monitoring data. Initial fault features are extracted from the new fault data according to preset dimensions, wherein the preset dimensions include keywords, log templates, abnormal indicators, topology services, and root cause categories; The initial fault characteristics are subjected to integrity verification. If the verification passes, a new fault characteristic is formed.

5. The method according to claim 1, characterized in that, The process of matching the new fault features using the fault knowledge graph to obtain similar fault data includes: Based on the keywords in the new fault features, a direct search is performed in the fault knowledge graph to obtain directly matching fault data. Based on the new fault characteristics, an association-expanded retrieval is performed in the fault knowledge graph to obtain indirectly matched fault data. Similar fault data are determined based on the directly matched fault data and the indirectly matched fault data.

6. The method according to claim 5, characterized in that, The step of determining similar fault data based on the directly matched fault data and the indirectly matched fault data includes: The directly matched fault and the indirectly matched fault data are merged, duplicate faults are removed, and a candidate fault set is formed. Calculate the similarity between each candidate fault data in the candidate fault set and the new fault feature to obtain a similarity score; The candidate fault data are sorted in descending order of similarity score to obtain a sorted set of candidate faults. A specified number of candidate fault data are selected from the sorted candidate fault set as similar fault data.

7. The method according to claim 1, characterized in that, The method further includes: User feedback information is obtained based on the fault matching report, wherein the user feedback information includes valid information and invalid information; The fault knowledge graph is updated based on the valid information.

8. A knowledge graph matching device for operation and maintenance, characterized in that, include: The knowledge graph construction module is used to acquire historical fault data and construct a fault knowledge graph based on the historical fault data. The similar fault matching module is used to extract new fault features when a new fault occurs, and match the new fault features with the fault knowledge graph to obtain similar fault data. The matching report generation module is used to generate a fault matching report based on the similar fault data.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores computer instructions that are used to cause a processor to execute the method of any one of claims 1-7.

Images