An intelligent operation and maintenance knowledge base construction method

Abstract

The application provides a kind of intelligent operation and maintenance knowledge base construction method, it is related to data processing technical field, the method includes: step 1, acquisition monitoring component, log component and the original operation and maintenance data of configuration management database, obtain the real-time data stream of multi-source heterogeneous;Entity recognition and relationship extraction are carried out to the real-time data stream of multi-source heterogeneous, obtain operation and maintenance entity and the association between operation and maintenance entities;Step 2, according to operation and maintenance entity and the association between operation and maintenance entities, construct operation and maintenance relationship network, in operation and maintenance relationship network, according to the direct connection quantity statistical result between each node, select the two operation and maintenance entities with the maximum direct connection quantity as reference node.The application can accumulate operation and maintenance knowledge, improve fault processing accuracy and intelligent level by integrating multi-source operation and maintenance data, constructing operation and maintenance relationship network and weighted optimization fault characteristics, combined with intelligent diagnosis model to generate dynamic solution.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for constructing an intelligent operation and maintenance knowledge base. Background Technology

[0002] In IT operations and maintenance, building an intelligent knowledge base is crucial for rapid fault diagnosis and resolution. Most common methods for building intelligent operations and maintenance knowledge bases focus on classifying historical fault cases and rule-based learning. These methods typically use individual fault events and their solutions as the main knowledge units.

[0003] However, in real-world operations and maintenance environments, various entities, such as servers, applications, and network devices, do not exist in isolation. Instead, they form a cohesive network through complex dependencies. Existing methods may struggle to fully reflect the deep topological relationships between these entities when building a knowledge base. For example, when a network device fails, the impact may extend beyond the servers directly connected to it. The effects may propagate along dependency paths to upper-layer applications and even the final business services. If existing knowledge bases only record individual device failures and solutions without analyzing the entire "network device, server, and application" relationship as a complete failure scenario, they may struggle to accurately determine the fundamental scope of the failure's impact when dealing with such interconnected failures, thus affecting the relevance of the generated solutions. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a method for constructing an intelligent operation and maintenance knowledge base, which improves the efficiency and accuracy of entity recognition.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a method for constructing an intelligent operation and maintenance knowledge base, the method comprising:

[0007] Step 1: Collect raw operation and maintenance data from monitoring components, log components, and configuration management database to obtain multi-source heterogeneous real-time data streams; perform entity identification and relationship extraction on the multi-source heterogeneous real-time data streams to obtain operation and maintenance entities and the relationships between them.

[0008] Step 2: Based on the operation and maintenance entities and the relationships between them, construct an operation and maintenance relationship network. In the operation and maintenance relationship network, select the two operation and maintenance entities with the largest number of direct connections as the baseline nodes based on the statistical results of the number of direct connections between each node.

[0009] Step 3: Based on the topological connection relationship between the two benchmark nodes, generate a benchmark analysis path and divide the benchmark analysis path into multiple analysis segments according to the consistency of entity types in the path;

[0010] Step 4: Perform fault correlation analysis on each analysis segment to obtain the weight adjustment coefficient for each analysis segment; associate historical fault records with the operation and maintenance relationship network, and combine the weight adjustment coefficient to perform weighted vectorization processing on historical fault features to obtain optimized vectorized fault events.

[0011] Step 5: Based on the optimized vectorized fault events and corresponding historical solutions, construct and train the intelligent diagnostic model to obtain the trained intelligent diagnostic model.

[0012] Step 6: Input the real-time fault data into the trained intelligent diagnostic model for processing to obtain a dynamic solution for the current fault, thus completing the construction of the intelligent operation and maintenance knowledge base.

[0013] In a second aspect, a computing device includes:

[0014] One or more processors;

[0015] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0016] Thirdly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0017] The above-described solution of the present invention has at least the following beneficial effects:

[0018] By identifying entities and extracting relationships, not only are operational entities such as servers and applications identified, but also the relationships between entities, such as call dependencies and deployments, are uncovered. This transforms scattered data into a structured network, avoiding the one-sidedness of fault diagnosis caused by data fragmentation. After constructing the operational relationship network, baseline nodes are determined, core analysis paths are generated, and segments are divided. This topology-based analysis clearly presents the propagation path of faults along network devices, servers, and applications, solving the problem of focusing only on a single faulty entity and failing to grasp the overall impact. By analyzing the correlation between each segment and the fault and assigning weights, historical fault features are weighted and vectorized, making the features more reflective of the core impact of the fault. The intelligent diagnostic model trained based on this takes optimized features containing topology correlation information as input and outputs a more relevant solution. In practice, compared to treating features equally, this method allows the model to focus more on key information, improving the accuracy of fault diagnosis. After obtaining a preliminary solution, it is adjusted based on the current state of nodes in the operation and maintenance relationship network to generate a dynamic solution. For example, when a server fails, if its associated application is under high load, the solution will first perform load migration before handling the fault, avoiding secondary problems that may be caused by mechanically applying a fixed solution. Real-time fault data, dynamic solutions, and processing effects are stored as new samples in the knowledge base, continuously enriching the knowledge reserve. At the same time, with the addition of new data, the operation and maintenance relationship network and intelligent diagnostic model can also be continuously optimized, enabling the knowledge base to have self-evolution capabilities. Compared with a knowledge base that relies on manual updates, this reduces maintenance costs and can continuously improve fault handling capabilities with the accumulation of operation and maintenance experience. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an intelligent operation and maintenance knowledge base construction method provided by an embodiment of the present invention.

[0020] Figure 2 This is a flowchart illustrating step 1 provided in an embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0022] like Figure 1 As shown in the figure, an embodiment of the present invention proposes a method for constructing an intelligent operation and maintenance knowledge base, the method comprising the following steps:

[0023] Step 1: Collect raw operation and maintenance data from monitoring components, log components, and configuration management database to obtain multi-source heterogeneous real-time data streams; perform entity identification and relationship extraction on the multi-source heterogeneous real-time data streams to obtain operation and maintenance entities and the relationships between them.

[0024] Step 2: Based on the operation and maintenance entities and the relationships between them, construct an operation and maintenance relationship network. In the operation and maintenance relationship network, select the two operation and maintenance entities with the largest number of direct connections as the baseline nodes based on the statistical results of the number of direct connections between each node.

[0025] Step 3: Based on the topological connection relationship between the two benchmark nodes, generate a benchmark analysis path and divide the benchmark analysis path into multiple analysis segments according to the consistency of entity types in the path;

[0026] Step 4: Perform fault correlation analysis on each analysis segment to obtain the weight adjustment coefficient for each analysis segment; associate historical fault records with the operation and maintenance relationship network, and combine the weight adjustment coefficient to perform weighted vectorization processing on historical fault features to obtain optimized vectorized fault events.

[0027] Step 5: Based on the optimized vectorized fault events and corresponding historical solutions, construct and train the intelligent diagnostic model to obtain the trained intelligent diagnostic model.

[0028] Step 6: Input the real-time fault data into the trained intelligent diagnostic model for processing to obtain a dynamic solution for the current fault, thus completing the construction of the intelligent operation and maintenance knowledge base.

[0029] In this embodiment of the invention, through entity recognition and relationship extraction, not only are operational entities such as servers and applications obtained, but also the relationships between entities, such as call dependencies and deployments, are mined. This transforms scattered data into a structured network, avoiding the one-sidedness of fault diagnosis caused by data fragmentation. After constructing the operational relationship network, baseline nodes are determined, core analysis paths are generated, and segments are divided. This topology-based analysis clearly presents the propagation path of faults along network devices, servers, and applications, solving the problem of focusing only on a single fault entity and failing to grasp the overall impact. By analyzing the correlation between each segment and the fault and assigning weights, historical fault features are weighted and vectorized, making the features more reflective of the core impact of the fault. The intelligent diagnostic model trained based on this takes optimized features containing topology correlation information as input and outputs a solution... The proposed solution is more practical. Compared to treating features equally, this method allows the model to focus more on key information, improving the accuracy of fault diagnosis. After obtaining a preliminary solution, it is adjusted based on the current state of nodes in the operation and maintenance relationship network to generate dynamic solutions. For example, if a server fails and its associated applications are under high load, the solution will first perform load migration before handling the fault, avoiding secondary problems that may be caused by mechanically applying fixed solutions. Real-time fault data, dynamic solutions, and processing effects are stored as new samples in the knowledge base, continuously enriching the knowledge reserve. At the same time, with the addition of new data, the operation and maintenance relationship network and intelligent diagnostic model can also be continuously optimized, enabling the knowledge base to have self-evolution capabilities. Compared with a knowledge base that relies on manual updates, this reduces maintenance costs and can continuously improve fault handling capabilities with the accumulation of operation and maintenance experience.

[0030] like Figure 2 As shown, in another preferred embodiment of the present invention, step 1 includes:

[0031] Step 100: Based on the indicator data collected from the monitoring component, the log text data collected from the log component, and the configuration item data collected from the configuration management database, perform unified data format processing to obtain preprocessed data with a unified data format. Specifically, this includes: indicator data such as CPU utilization, memory usage, and network bandwidth collected by the monitoring component. The original storage is mostly in key-value pair format. First, extract the core elements from each data entry, namely the collection time, device identifier, indicator name, and indicator value. Then, map these to fixed column fields of a structured table. The collection time format is uniformly set to year-month-day hour:minute:second. The device identifier uses a device type-number rule, such as server-001, router-012. The indicator value is retained to one decimal place, such as CPU utilization 65.2%. This ultimately forms a table of data where each row corresponds to one indicator record. For text data such as error logs and access logs generated by the log component, first use regular expression-based text parsing technology to match and extract fixed format information, namely the timestamp, such as 2024-05-20 14:30:22, and the device identifier, such as switch- 008. Log levels (information / warning / error) and log content, such as connection timeout for port 12; for log content without a fixed format, extract key information such as connection timeout and service startup failure, and then organize all extracted elements into a structured table according to timestamp, device identifier, log level, and log content column fields to ensure that each log corresponds to a separate row of data; although the device model and service deployment path data in the configuration management database are already in a structured format, there are differences in field naming, such as device number and device ID. First, sort out all fields and establish a unified mapping rule, that is, unify device number / device ID as device identifier, and service installation path / deployment path as service deployment path. Then check the integrity of field values. For missing non-critical information, such as device remarks not filled in, and critical information, such as IP address, complete it by associating with the device ledger. Finally, form a configuration item table data with a unified format. After completing the three types of data processing, convert all table data into standard JSON or CSV format to ensure data structure consistency and obtain preprocessed data with a unified data format.

[0032] Step 101: Based on the preprocessed data, perform timestamp alignment to obtain a consistent time series of multi-source heterogeneous real-time data streams. Specifically, this includes: extracting the timestamp fields of three types of data from the preprocessed data; first, determining the timestamp precision and unifying all timestamps to millisecond precision, with the format specified as year-month-day hour:minute:second; for data containing only second-level timestamps, such as some monitoring indicators, adding 000 after the second to meet millisecond format requirements; statistically analyzing the timestamp range of all preprocessed data to determine the start time (earliest timestamp) and end time (latest timestamp) of the time series; setting the time interval based on the frequency of operational data collection, such as collecting monitoring data every 10 seconds and generating logs every 5 seconds, then taking the minimum frequency of 5 seconds as the time interval, starting from the start time, and accumulating the time intervals sequentially to generate a time axis, with each time point on the axis sequentially recorded as the first time point, the second time point, ..., the nth time point (the first time point is the start time, and the nth time point is the end time); for each type of preprocessed data, comparing the timestamp of each data item with the timestamps on the time axis. If a timestamp exactly matches a given time point, the data is directly associated with that time point. If the timestamp lies between two adjacent time points (the previous time point and the next time point, where the next time point = the previous time point + the time interval), linear interpolation is used to calculate the data's value at all time points between those two time points. For example, if a monitoring indicator has a value of 50.2 at the previous time point (14:30:20.000) and a value of 60.2 at the next time point (14:30:25.000), the time interval... At 5-second intervals, the value at a certain intermediate time point (14:30:22.000) needs to be calculated. The calculation process is as follows: first, calculate the change per unit time (60.2 - 50.2) ÷ (25 - 20) = 2.0; then calculate the time difference of 2 seconds between the intermediate time point and the previous time point. The final value is 50.2 + 2.0 × 2 = 54.2. The three types of data are integrated one by one according to the time points on the time axis to ensure that each time point contains monitoring, log, and configuration data, forming a consistent time series of multi-source heterogeneous real-time data stream.

[0033] Step 102: Based on the multi-source heterogeneous real-time data stream, extract application service instances, server nodes, and network device entities to obtain a basic operation and maintenance entity set. Specifically, this includes: identifying three core entity types in the operation and maintenance scenario: application service instances, server nodes, and network devices; defining standard naming rules and common aliases for each type of entity; the standard name for application service instances follows a business type-service function-version rule, such as e-commerce-order service-version 2.1; common aliases include order service version 2, etc., covering simplified descriptions that may appear in actual operation and maintenance; the standard name format for server nodes is server class... The system uses a type-number-IP address structure, such as physical server-001-192.168.1.101. Common aliases include server001, 192.168.1.101 server, etc., corresponding to the abbreviation or IP address used for servers in daily operations and maintenance. The standard name of a network device is determined by the device type-number-port rule, such as switch-005-12. Common aliases include switch005, switch 12 port device, etc., to adapt to the naming habits of network devices in different scenarios. Finally, the above entity types, standard names, aliases, identification rules, and other information are organized into a structured entity dictionary for the operations and maintenance domain.

[0034] Entity recognition based on this dictionary follows a core process: first, an entity matching rule base is established; then, the data stream is split to extract entities. When establishing the rule base, the standard name and aliases of entities are broken down into keywords. For example, "e-commerce-order service-2.1 version" is broken down into "e-commerce," "order service," and "2.1 version." When a complete keyword combination appears in the data stream, the corresponding entity is directly matched. For abbreviations and shortened forms, such as "order version 2" corresponding to "order service version 2," a keyword overlap threshold is set (overlap ≥ 70% is considered a match), while irrelevant interference words such as "test" and "temporary" are excluded. For the same entity... A one-to-one mapping table is established between the full name of the entity and all its aliases. For example, physical server-001-192.168.1.101 corresponds to server 001 and server 192.168.1.101, ensuring that different representations can match the same entity. Multi-source heterogeneous real-time data streams aligned with timestamps are split into log data, configuration data, and monitoring data. Application service instance names are identified from the log content using a rule base. For example, the order service and device identifier are extracted from a failed order service startup, and server 001 is extracted from a connection error on server 001. The system extracts key information such as server node IP addresses and network device IDs from configuration data based on a rule base. It then matches the corresponding server or network device entities from the device identifier field of monitoring data using a rule base, ensuring that all entities in the three data streams are fully identified. Two core processes are performed on the identified entities: First, entity identifiers are standardized. If different representations of the same entity appear in different data, such as "e-commerce-order service-2.1 version" and "order service version 2," they are converted to the corresponding standard name based on the dictionary's alias mapping rules, eliminating representational differences. Second, duplicate entities are deleted. If multiple data entries identify entities with the same standard name, such as "physical server-001-192.168.1.101" being identified in both monitoring and configuration data, only one record with complete information is retained to avoid data redundancy. Finally, the deduplicated and standardized entities are categorized into three types: application service instances, server nodes, and network devices. Complete information is added to each entity record, including entity type, standard name, corresponding alias, and associated data source, such as from log data or configuration data, ultimately forming a structured set of basic operation and maintenance entities.

[0035] Step 103: Based on the basic operations and maintenance entity set, extract the call dependencies between application service instances and the deployment relationships between service instances and server nodes to obtain a complete set of operations and maintenance entities with structured relationships. Specifically, this includes: using an association rule mining algorithm to extract relationships between entities, configuring algorithm parameters to suit the specific characteristics of the operations and maintenance scenario, setting a minimum support (e.g., 5%), meaning that the frequency of a certain type of relationship in all data must reach at least 5%, and a minimum confidence (e.g., 80%), meaning that the credibility of determining the existence of a certain type of relationship must reach at least 80%. Parameter constraints ensure that the extracted relationships conform to the actual operations and maintenance logic. Service call logs, including API call records and service interaction logs, are filtered from the real-time data stream and extracted according to the following steps. The process for determining service dependencies involves three steps: First, extracting three core fields from the service call logs—the caller's service name, the callee's service name, and the call time—to build a basic service call dataset. Second, using a daily statistical period, counting the number of calls between any two application service instances (e.g., counting the daily number of calls from service A to service B) to generate call frequency statistics. Third, comparing the counted call counts with a preset call frequency threshold (set based on business scale, e.g., an average of over 100 calls per day). If the call counts of two service pairs exceed the threshold and meet the algorithm's minimum support and minimum confidence requirements, then it is determined that the two application service instances have a call dependency relationship. Simultaneously, the call direction is recorded, e.g., from service A to service B, clarifying the directionality of the dependency relationship.

[0036] Deployment relationships are extracted by cross-validating two types of data. First, service names and deployment server IP addresses are extracted from the service deployment data in the configuration management database to form a preliminary correspondence between services and IPs. Then, service names and startup server identifiers, including server IP addresses and device numbers, are extracted from the service startup logs in the real-time data stream to supplement the actual running node information at the time of service startup. For the same service instance, the server IP address in the deployment data is compared with the server identifier in the startup log. If the two are confirmed to point to the same server node through the association matching of IP address and device number, it is determined that there is a deployment relationship between the service instance and the server node, ensuring the authenticity and accuracy of the deployment relationship. For each entity, two pieces of information are added: a list of associated entities and an association type. For example, the list of associated entities of service A includes service B (the caller) and deployment node server 001. The association types are marked as call dependency and deployment, respectively. After integration, a complete set of operation and maintenance entities containing basic entity information and structured association relationships is formed.

[0037] This embodiment eliminates data format barriers by unifying the storage format and core fields of three types of data, transforming the originally scattered and heterogeneous raw data into preprocessed data with a consistent structure, thus improving the operability of multi-source operation and maintenance data. By constructing a unified timeline and using interpolation to complete the data, the three types of data are accurately matched in the time dimension, which can fully present the running data of each operation and maintenance entity at the same point in time, ensuring the time consistency of operation and maintenance data. Combined with the operation and maintenance dictionary, core entities such as application services, servers, and network devices are accurately extracted, and through deduplication and unified identification, a complete set of basic operation and maintenance entities is formed, clearly presenting the core components of the operation and maintenance environment, improving the efficiency and accuracy of entity identification. By mining the call dependencies between application services and the deployment relationships between services and servers, isolated basic entities are transformed into a complete set containing structured relationships, clearly presenting the dependency chain between operation and maintenance entities, making the originally implicit entity relationships explicit structured information, and solving the drawbacks of ignoring entity relationships.

[0038] In a preferred embodiment of the present invention, step 2 includes:

[0039] Step 200: Based on the complete set of structured and related operation and maintenance entities, map each operation and maintenance entity to a network node, and map the relationships between entities to network edges, constructing a complete topological operation and maintenance relationship network. In this network, nodes represent operation and maintenance entities, and edges represent the relationships between them. Specifically, this includes: First, retrieving the previously constructed complete set of operation and maintenance entities. This set must meet the following conditions: it must cover three core operation and maintenance entities: application service instances, server nodes, and network devices. Each entity's record must contain complete information, including entity type (e.g., application service instance, server node), standard name (e.g., e-commerce-order service-2.1 version, physical server-001-192.168.1.101), corresponding alias, associated data source (e.g., log data, configuration data), and a key list of associated entities and their associated types (e.g., the associated entity list is the callee, service B; deployment node, server 001; the associated type is call dependency, deployment). This ensures the structure and completeness of the entities and their relationships within the set. Then, map the entities to network nodes according to the following rules. The process involves traversing the complete set of operations and maintenance entities, extracting each entity one by one, and ensuring that each entity corresponds to a network node in the operations and maintenance relationship network. This ensures a one-to-one correspondence between entities and nodes, with no duplication or omissions. For each network node, the core attributes of the entity are bound, and the entity type and standard name corresponding to the node are labeled. For example, e-commerce-order service-2.1 version (entity type: application service instance) is mapped to a node, with the node attribute labeled "application service instance-e-commerce-order service-2.1 version". Network edges are constructed based on the relationships between entities. Specifically, for each entity, the list of associated entities and their association types are extracted from its records, and the target entity to be connected is determined, i.e., the entity in the list of associated entities. A network edge is established between the node corresponding to the current entity and the node corresponding to the target entity, and the association type is labeled on the edge, such as "dependency call" or "deployment". This process is repeated until all entity relationships are mapped to edges, ultimately forming a complete topology. Nodes represent operations and maintenance entities, edges represent the relationships between entities, and each edge clearly labels the operations and maintenance relationship network with its association type.

[0040] Step 201: Based on the operation and maintenance relationship network, calculate the degree centrality value of each network node, that is, count the number of edges directly connected to each node to obtain the set of degree centrality values ​​of all nodes. Specifically, this includes: selecting each node in the network one by one, taking that node as the center, traversing all edges in the network, and counting the number of edges directly connected to that node. Regardless of the association type of the edge, such as call dependency or deployment, as long as one end of the edge connects to the current node, it is included in the total count. This total count is the degree centrality value of the current node. For example, if node A, corresponding to e-commerce-order service-2.1 version, has 3 directly connected edges, connecting to service B, server 001, and service C respectively, then the degree centrality value of node A is 3; if node B, corresponding to... The physical server B (001-192.168.1.101) has two directly connected edges, one connecting to the e-commerce order service (version 2.1) and the other to the logistics dispatch service (version 3.0). Therefore, the degree centrality of node B is 2. The calculation results for all nodes are summarized to generate a set of degree centrality values. This set is recorded in the form of node identifier-degree centrality value. The node identifier uses entity type-standard name, such as application service instance-e-commerce-order service-version 2.1-3 and server node-physical server-001-192.168.1.101-2. The completeness of the set is checked to ensure that the degree centrality value of each node has been recorded without any missing or incorrect values, forming a structured set of values ​​that can be directly used for sorting.

[0041] Step 202: Based on the degree centrality value set, select the operation and maintenance entities corresponding to the two network nodes with the largest degree centrality values ​​as the baseline nodes. Specifically, this includes: sorting the degree centrality value set generated in Step 201, arranging all records in the set in descending order of degree centrality value. If nodes have the same value, sort them according to the alphabetical or numerical order of their node identifiers, such as prioritizing server nodes over application service instances, and using smaller numbers over larger numbers for auxiliary sorting. This ensures the sorting result is unique and ordered, forming a clear numerical order table that visually presents the differences in degree centrality values ​​between nodes. The process involves selecting baseline nodes from the sorted results. This means extracting the top two records in the sorted results, which are the nodes corresponding to the two records with the highest degree centrality values. The corresponding operation and maintenance entities for these two nodes are then identified by their node identifiers. These two entities are the baseline nodes. For example, if the top two records after sorting are Application Service Instance - E-commerce - Order Service - Version 2.1 - 5 and Server Node - Physical Server - 002 - 192.168.1.102 - 4, then E-commerce - Order Service - Version 2.1 and Physical Server - 002 - 192.168.1.102 are the baseline nodes.

[0042] In this embodiment, the construction of the operation and maintenance relationship network transforms the dispersed operation and maintenance entities and their relationships into a visualized and structured topology model, clearly presenting the relationship logic between entities and providing intuitive data support for operation and maintenance management. The calculation of degree centrality values ​​can locate operation and maintenance entities with high core degree in the network. These entities have a greater impact on the stable operation of the overall operation and maintenance system. The determination of benchmark nodes can quickly analyze the operating status of related entities and troubleshoot fault propagation paths based on benchmark nodes, improving operation and maintenance efficiency and the pertinence of problem handling.

[0043] In a preferred embodiment of the present invention, step 3 includes:

[0044] Step 300: Calculate the shortest connection path between two benchmark nodes to generate a benchmark analysis path. This includes: first, defining the core boundaries and data foundation for the shortest path calculation; the path endpoints need to be selected from the two benchmark nodes determined in step 202, defined as the starting benchmark node and the target benchmark node, serving as the starting and ending points for the shortest path calculation; the network scope uses the operation and maintenance relationship network constructed in step 200 as the calculation boundary. This network includes all nodes mapped to operation and maintenance entities and the edges mapping the relationships between entities. Each edge is labeled with its association type, such as dependency or deployment. Although edge types are not distinguished during the calculation phase, the direct connection attributes between nodes must be preserved to ensure the effectiveness of the path search; and finally, organizing the operation and maintenance relationships. The structured data of the network generates a node identifier-associated node list mapping table. For example, the associated node list of node A is [node C, node D]. The shortest path is defined as the path with the fewest edges connecting the starting and target reference nodes. The specific execution flow is as follows: Create a queue of nodes to be visited, add the starting reference node to the queue, create a set of visited nodes, mark the starting reference node as visited, create a predecessor node dictionary to record the previous connected node of each node, where the predecessor node of the starting reference node is set to none, retrieve the current node from the head of the queue of nodes to be visited, and the first traversal is the starting reference node. Traverse all nodes in the associated node list of this node; for each associated node, if it is not in the set of visited nodes, then... Add the node to the queue of nodes to be visited, mark it as visited, and record the current node as the predecessor node of the associated node in the predecessor node dictionary. Repeat the queue traversal operation until the node taken out of the queue is the target reference node. At this point, terminate the search to avoid invalid calculations. Starting from the target reference node, query its predecessor node, the predecessor node's predecessor node, and so on in the predecessor node dictionary until the starting reference node is reached, forming a reverse node sequence, such as target reference node, node X, node Y, starting reference node. Adjust the reverse node sequence to the forward order, starting reference node, node Y, node X, target reference node, and count the number of edges in the sequence. For example, if there are 3 edges, the sequence is the shortest path with the fewest edges. The forward shortest path node sequence is structured by adding an entity type to each node in the sequence, such as application service instance / server node / network device and standard name, such as application service instance-e-commerce-order service-2.1 version. The node sequence is then organized into an ordered list according to the order of starting benchmark node, intermediate nodes, and target benchmark node to form a complete benchmark analysis path. For example, the starting benchmark node is application service instance-e-commerce-order service-2.1 version, node Y is server node-physical server-001-192.168.1.101, node X is network device-switch-005-12, and the target benchmark node is application service instance-e-commerce-payment service-3.0 version.

[0045] Step 301: Based on the entity type attributes of each node in the benchmark analysis path, group the path nodes according to three entity types: application service instance, server node, and network device. Divide the set of consecutive nodes with the same entity type into an analysis segment. Specifically, this includes: traversing all nodes in the benchmark analysis path and performing the following operations: extracting a unique entity type (application service instance / server node / network device) from the attribute information of each node, ensuring that a single node corresponds to only one entity type; numbering the nodes sequentially from 1, constructing a three-dimensional correspondence list of node number-node identifier-entity type, for example: 1-Application Service Instance-E-commerce-Order Service-Version 2.1-Application Service Instance; 2-Server Node-Physical Server-001-192.168.1.101-Server Node; 3-Network Device-Switch-005-12-Network Device; 4-Application Service Instance-E-commerce-Payment Service-Version 3.0-Application Service Instance; following the rule of grouping consecutive nodes with the same entity type together, group the three-dimensional correspondence list, starting from node number 1, recording the entity type of the current node, and creating a temporary group list. Add node 1 to the list; process node number 2 and subsequent nodes sequentially, comparing the entity type of the current node with that of the nodes in the temporary group list; if the entity types are the same, add the current node to the temporary group list; if the entity types are different, save the current temporary group list as a complete group, clear the temporary group list and reinitialize it with the entity type of the current node, add the current node to the new list, and after all nodes have been traversed, supplement and save the last temporary group list, ultimately forming multiple node groups. For example, the above example can be divided into 3 groups, namely [node 1], [node 2, node 3], etc. [Node 4]; Perform segmentation definition for each node group, where segment numbering assigns a unique segment number to each node group (incrementing from 1); segment boundary record records the starting node number and ending node number of each segment, such as 2-3 for node group [Node 2, Node 3]; segment entity type labeling labels the entity type within each segment, such as server node for node group [Node 2, Node 3]; integrate the above information to form a structured segment list of segment number-starting sequence number-ending sequence number-entity type, completing the segment division analysis.

[0046] Step 302: Based on the entity type characteristics contained in each analysis segment, determine the type classification of each analysis segment. Specifically, this includes: performing feature extraction on the structured segment list generated in step 301. Since each analysis segment consists of nodes of the same continuous entity type, and a single segment corresponds to only one entity type, the entity type within the segment is directly used as the core feature to generate a segment number-entity type feature mapping table. For example, the entity type feature of segment 1 is application service instance, and segment 2 is server node, ensuring that feature extraction is complete and error-free. Combined with the functional positioning of entity types in the operation and maintenance scenario, a unified classification standard is determined. Application service instances directly carry business logic and correspond to the entity type in the operation and maintenance system. Service layer; server nodes are hardware resource carriers, corresponding to the hardware layer; network devices are responsible for data transmission, corresponding to the network layer; if the entity type characteristic of a segment is an application service instance, it is classified as a service layer segment; if it is a server node, it is classified as a hardware layer segment; if it is a network device, it is classified as a network layer segment. The rules cover all entity types; traverse the structured segment list, perform classification matching and information improvement, that is, match the entity type characteristics of each segment with the classification rules one by one to determine the corresponding type classification, such as segment 1 matching as a service layer segment, segment 2 matching as a hardware layer segment; add a type classification field to the segment list to form a complete record of segment number-start sequence number-end sequence number-entity type-type classification.

[0047] This embodiment, by calculating the shortest path between two baseline nodes, can focus on the core connection links in the operation and maintenance relationship network, avoiding increased analysis complexity due to excessively long paths; grouping analysis segments by consecutive entities of the same type can decompose complex path nodes into structured functional units, reducing interference from disordered node arrangement and making the hierarchical structure of the path clearer; and clearly classifying the hierarchical structure of segments based on entity type characteristics (service layer, hardware layer, network layer) can quickly locate the set of nodes with different functional attributes in the path, improving the targeting and efficiency of operation and maintenance analysis.

[0048] In a preferred embodiment of the present invention, step 4 includes:

[0049] Step 400: Based on the statistical results of the fault impact range recorded in the historical fault records, calculate the frequency ratio of each analysis segment in various fault events to obtain the fault correlation score for each analysis segment; map the fault correlation score to a preset numerical range to obtain the weight adjustment coefficient for each analysis segment. Specifically, this includes: firstly, collecting historical fault records from the operation and maintenance scenario; each record must include the fault number, fault occurrence time, fault type (e.g., network interruption, service unresponsiveness, hardware failure), and fault impact range (i.e., the list of operation and maintenance entities involved in the fault); then processing the records... Perform data cleaning to remove invalid data, such as fault records with missing information. Then, initially associate the maintenance entities within the fault's impact range with the nodes in the maintenance relationship network constructed in step 200, clarifying the analysis segment corresponding to each node involved in the fault (based on the analysis segments divided in step 301). Let the total number of valid fault events in the historical fault records be N. For each analysis segment, such as segment 1, segment 2, ..., segment m, iterate through all fault events and count the number of times that segment is included within the fault's impact range, denoted as Ci (where i is the segment number, e.g., the number of occurrences for segment 1 is C1, segment 2 is C2, ..., segment m is C3). C2); The frequency ratio of fault occurrence in each analysis segment = the number of fault occurrences in that segment ÷ the total number of fault events, i.e., the frequency ratio Pi = Ci ÷ N. For example, if the total number of fault events N = 100 and the number of fault occurrences in segment 1 C1 = 60, then the frequency ratio of segment 1 P1 = 60 ÷ 100 = 0.6; The calculated frequency ratio is directly used as the fault correlation score for that analysis segment, i.e., the score Si = Pi. The higher the score, the stronger the correlation between the segment and the fault; According to the requirements of the operation and maintenance scenario, the preset value range of the weight adjustment coefficient is [0.1, 1.0] (the lower limit of the range is...). (To ensure that low-relevance segments still have basic weights and avoid feature loss due to weights of 0), the fault correlation score Si is mapped to a preset interval. The mapping formula is: weight adjustment coefficient Wi = 0.1 + (Si × (1.0 - 0.1)) = 0.1 + 0.9 × Si. For example, if the correlation score S1 of segment 1 is 0.6, its weight adjustment coefficient W1 = 0.1 + 0.9 × 0.6 = 0.64; if the correlation score S2 of segment 2 is 0.2, its weight adjustment coefficient W2 = 0.1 + 0.9 × 0.2 = 0.28. Finally, the weight adjustment coefficient of each analysis segment is obtained.

[0050] Step 401: Match the operation and maintenance entities in the historical fault records with the nodes in the operation and maintenance relationship network to establish a mapping relationship between historical fault events and the operation and maintenance relationship network; perform weighted calculation on the feature vectors of historical fault events according to the weight adjustment coefficient to obtain optimized vectorized fault events, specifically including: extracting the operation and maintenance entities with fault impact range in the historical fault records, such as server node A and application service B; finding the corresponding nodes in the operation and maintenance relationship network according to the standard name of the entity, and establishing a mapping relationship between fault number and associated node list; based on the associated node list, combined with the division in step 301... The analysis segments are determined to identify the analysis segments involved in each fault event, forming a complete mapping table of fault number, associated segment list, and corresponding weight adjustment coefficient. For each historical fault event, an initial feature vector is constructed. The feature dimensions include fault type (e.g., network interruption is set to 1, service unresponsiveness to 2, hardware failure to 3), fault duration (directly used as a numerical feature), and the number of entities affected by the fault (i.e., the total number of nodes in the associated node list), which is also used as a numerical feature. Let the initial feature vector be V = [v1, v2, v3], where v1 is the fault type code, v2 is the duration, and v3 is the impact factor. Entity count; For numerical features, such as duration and the number of affected entities, standardization is performed using the Min-Max standardization formula: standardized value = (original value - minimum value of the feature) ÷ (maximum value of the feature - minimum value of the feature), ensuring that all features are on the same numerical order of magnitude to avoid affecting the weighting effect; The initial feature vector is weighted according to the weight adjustment coefficients in the mapping table, and the average of the weight adjustment coefficients of all analysis segments involved in the fault event is taken as the weighting coefficient W of the feature vector of the fault event. If the fault involves segment 1 and segment 2, the weights are 0.64 and 0.64 respectively. If the weighting factor is 0.28, then W = (0.64 + 0.28) ÷ 2 = 0.46; the optimized feature vector V' = V × W, which is the value of each feature dimension multiplied by the weighting coefficient, the formula is V' = [v1 × W, v2 × W, v3 × W]; for example, the initial feature vector V = [2, 10, 5] (the fault type is service unresponsive, lasting 10 minutes, affecting 5 entities), the weighting coefficient W = 0.46, then the optimized vector V' = [2 × 0.46, 10 × 0.46, 5 × 0.46] = [0.92, 4.6, 2.3], this vector is the optimized vectorized fault event.

[0051] This embodiment objectively quantifies the correlation between segments and faults by statistically analyzing the frequency of occurrence of segments in historical faults. This allows highly correlated segments, such as network device segments, to receive higher scores, avoiding the weakening of core fault features due to equal weighting and improving the targeting of fault analysis. The weight adjustment coefficients ensure numerical rationality through a mapping mechanism, avoiding information loss caused by low-correlation segments having zero weights, and strengthening the fault features corresponding to highly correlated segments through weighting. Compared to unweighted feature vectors, the optimized vectors better reflect the core influencing factors of faults, improving the accuracy of fault type identification. Historical faults are mapped to the operation and maintenance relationship network, clarifying the nodes and segments involved in the faults. This makes fault events no longer isolated data, but structured information containing topological context, avoiding one-sided solutions due to lack of contextual information. Standardization eliminates the magnitude differences of different features, while weighting strengthens core features, reducing the impact of redundant information on the model, and ultimately improving the training efficiency and convergence speed of the intelligent diagnostic model.

[0052] In a preferred embodiment of the present invention, step 5 includes:

[0053] Step 500: Based on the optimized vectorized fault events and corresponding historical solution records, construct a training sample set containing input feature vectors and output solution labels. Specifically, this includes: collecting all optimized vectorized fault events generated in step 401, and retrieving the historical solution record corresponding to each fault event, including the solution type (e.g., restarting service, replacing hardware, repairing network configuration), and solution execution parameters; associating each optimized vectorized fault event with its corresponding historical solution record according to the fault number, ensuring that each fault event has matching solution data; and labeling the historical solution records, converting the solution type into a numerical code, such as setting restarting service to 1 and replacing hardware to 2. The network configuration was set to 3. Solution execution parameters, such as restart wait time and hardware replacement priority, were processed using Min-Max normalization. The calculation method was: normalized value = (original value - minimum value of the parameter) ÷ (maximum value of the parameter - minimum value of the parameter). The processed type encoding was integrated with the normalized parameters to form a solution label vector. Optimized vectorized fault events were used as input feature vectors, and the corresponding solution label vectors were used as output labels. All data were organized according to the input feature vector - output label structure to form a training sample set. The training sample set was then divided into a training set (70%-80%) and a validation set (20%-30%), used for model training and training effect verification, respectively.

[0054] Step 501: Based on the training sample set, construct a gradient boosting decision tree model as an intelligent diagnostic model. The input feature dimension of the intelligent diagnostic model is consistent with the dimension of the vectorized fault events, and the output result dimension is consistent with the dimension of the solution label. Step 501a: Based on the input feature vectors and output solution labels in the training sample set, set the initial parameters of the gradient boosting decision tree model. These initial parameters include the learning rate, the maximum tree depth, and the number of trees. Specifically, the learning rate is set to 0.01-0.1 to control the correction magnitude of each decision tree on the overall prediction result of the model. If the training sample size is large and the feature dimension is high, such as containing 10... For more than one input feature, use a smaller value of 0.01-0.05 to avoid overfitting due to excessively large single update magnitude. If the sample size is small and the feature dimension is low, such as 3-5 input features, use a larger value of 0.05-0.1 to accelerate model convergence. Set the maximum tree depth to 10-30 layers to limit the complexity of a single decision tree. If there is a lot of noisy data in the sample, use a smaller depth of 10-15 layers to reduce the risk of overfitting. If the mapping relationship between sample features and labels is complex, use a larger depth of 20-30 layers to ensure that the tree can fully learn the data patterns. Set the number of trees to 100-1000, corresponding to the preset number of iterations for model training (training one decision tree per iteration). When the sample size is large and the feature dimension is high, set 800-1000 trees; when the sample size is small and the feature dimension is low, set 100-300 trees to balance the model's fitting ability and training efficiency.

[0055] Step 501b: Initialize the gradient boosting decision tree model according to the initial parameters. The input feature dimension is consistent with the dimension of the input feature vector, and the output result dimension is consistent with the dimension of the output solution label. Specifically, this includes: initializing the model structure according to the initial parameters set in step 501a, ensuring that the input and output dimensions match the samples. Set the model input feature dimension to be consistent with the dimension of the input feature vector in the training sample set. For example, if the input feature vector contains 5 dimensions such as fault type and impact range, then the model input dimension is set to 5 to ensure that it can completely receive the optimized vectorized fault event data. Set the model output result dimension to be consistent with the dimension of the output solution label. For example, if the solution label contains 3 dimensions such as type encoding and execution time, then the model output dimension is set to 3 to ensure that the output can completely correspond to the various indicators of the solution. Use the mean vector of all output solution labels in the training sample set as the initial baseline prediction value of the model. The calculation method is to add the values ​​of all samples under each label dimension to get the sum, and then divide the sum by the total number of training samples to get the initial prediction value of that dimension. Integrate the initial prediction values ​​of all dimensions in order to form the initial baseline prediction value vector, which serves as the basis for the model's first prediction.

[0056] Step 501c: Based on the initialized gradient boosting decision tree model, train using the training sample set. Obtain the initial error by calculating the error between the prediction result and the output solution label. Specifically, for each training sample, calculate the difference between the value of each dimension in its output solution label vector and the value of the corresponding dimension in the initial prediction vector. Square each difference and sum them to obtain the error of a single sample. Sum the errors of all training samples to obtain the total error. Then divide the total error by the total number of training samples to obtain the initial error of the model. This error reflects the overall deviation between the model prediction and the true label in the initial state.

[0057] Step 501d: Based on the initial error, update the gradient boosting decision tree model parameters using the gradient boosting algorithm to obtain the updated gradient boosting decision tree model; repeat the training and parameter update process until the preset number of iterations is completed to obtain the constructed gradient boosting decision tree model. Specifically, this includes: for each training sample, first defining the loss function as mean squared error, whose expression is the square of (output solution label vector minus the current baseline prediction vector), and calculating the negative gradient of this loss function with respect to the current baseline prediction vector. Specifically, for each label dimension, multiply by 2 by (the dimension of the output solution label for that sample). Subtract the corresponding dimension value of the current baseline predicted value vector from the original value to obtain the pseudo residual value for that dimension; integrate the pseudo residual values ​​of all label dimensions in order to form the pseudo residual vector of the sample, which directly reflects the direction and magnitude of the predicted value that needs to be corrected; train a regression decision tree using the input feature vector of the training set as input and the pseudo residual vector as the target value. During the training process, calculate the optimal splitting feature and threshold according to the principle of maximizing the reduction of mean squared error. The specific steps are as follows: for all samples contained in the node, calculate the sum of squares of the pseudo residuals of all samples in each label dimension of the pseudo residual vector, and integrate the pseudo residual values ​​of all dimensions. The sum of squares, divided by the number of label dimensions, yields the total mean square error of the current node, reflecting the overall dispersion of pseudo-residuals within the node. All input features are iterated through, and candidate thresholds are generated for each feature based on its value distribution (median and quartiles for continuous distributions, and 0.1 intervals for features with defined ranges), forming multiple feature-threshold combinations. For each feature-threshold combination, the samples are divided into left and right child nodes based on whether the feature value is less than or greater than the threshold. The total mean square error of each child node is calculated separately (using the same method as for the current node), and then weighted by the number of samples in the child node, using (number of samples in the left child node × number of samples in the left child node). The total mean square error after splitting the current node is calculated as follows: (Total mean square error of the current node + Number of samples in the right child node × Total mean square error of the right child node) ÷ Total number of samples in the current node. The reduction in mean square error for each combination is calculated (Total mean square error of the current node minus the total mean square error after splitting). The combination with the largest reduction is selected as the optimal splitting feature and threshold. Based on this combination, the current node is divided into two child nodes. If the reduction in the mean square error for all combinations is less than 0.001, the splitting of the node is stopped. The above splitting process is repeated for the divided child nodes until the child nodes meet the stopping condition (number of samples less than 5-10, and reduction in mean square error less than 0).(001 or a tree depth of 10-30 layers) are marked as leaf nodes, ultimately generating a complete regression decision tree structure. For each leaf node, the number of samples it contains is counted. The pseudo-residual values ​​of all samples within the node are summarized according to the label dimension to obtain the residual sum for each dimension. The residual sum for each dimension is divided by the number of samples contained in the leaf node to obtain the output value for that dimension. The output values ​​of all dimensions are integrated in order to form the output value vector of the leaf node, thus establishing the correspondence between the leaf node and the output value vector. The value of each dimension in the output value vector of the currently trained decision tree is multiplied by the learning rate, and the result is added to the value of the corresponding dimension of the baseline prediction value vector in the previous round to obtain the updated baseline prediction value vector, completing the single-round parameter update. The above single-round parameter update process is repeated, training a new decision tree and updating the baseline prediction value in each iteration. At the same time, the training error after each iteration is recorded according to the error calculation method in step 501c. When the number of iterations reaches the number of trees set in step 501a (preset number of iterations), the iteration is stopped, and the completed gradient boosting decision tree model is obtained.

[0058] Step 502: Train the intelligent diagnostic model using the training sample set. Iterate through multiple rounds until a preset number of iterations is reached to obtain the trained intelligent diagnostic model. Specifically, after each round of training (training a decision tree and updating parameters), in addition to recording the training error, input the input feature vector of the validation set into the current model and calculate the validation error. The calculation method is as follows: for each sample in the validation set, calculate the sum of squares of the differences between each dimension of its true label vector and the model's predicted vector. Sum the squares of all samples to obtain the total sum of squares, and then divide the total sum of squares by the total number of samples in the validation set to obtain the validation error. By comparing the changes in training error and validation error, the model's generalization ability is judged. The preset early stopping round is 5-10 rounds. If, after multiple consecutive rounds, the validation error does not decrease after 5 rounds (i.e., the error change between adjacent rounds is less than 0.001), then the model is stopped. The iteration is terminated before the model is trained. For example, if the validation error in round N is 0.8, and the errors in rounds N+1 to N+5 are 0.8, 0.799, 0.801, 0.8, and 0.8 respectively, none of which are lower than 0.799, and the change in error over five consecutive rounds is less than 0.001, the iteration stops after round N+5 to avoid overfitting the training data. If the early stopping mechanism is not triggered, the iteration continues until the preset total number of iterations is reached. The validation errors of all iterations are compared, and the model corresponding to the iteration with the smallest error is selected as the final intelligent diagnostic model after training. If early stopping is triggered, the model with the smallest validation error before early stopping is selected. The complete parameters of the model are saved, including the structure of each decision tree, the optimal splitting feature and threshold, the output value vector of the leaf node, the learning rate, the actual number of iterations, the minimum error value of the validation set, and the minimum and maximum values ​​of feature standardization.

[0059] This embodiment associates and structures fault data with solutions, unifies data format, and allows for the reuse of historical experience. It also splits the training and validation sets to provide a reasonable data foundation for model training and performance evaluation. Model parameters are set and initialized according to sample characteristics to ensure that model input and output match the data, avoiding problems caused by blindly setting parameters or dimensional mismatches. By calculating initial errors and iteratively updating model parameters, the model is gradually optimized, enabling it to better fit the correlation between faults and solutions and improve prediction accuracy. Multiple rounds of iterative training combined with validation ensure the model's generalization ability, resulting in an intelligent diagnostic model that can be stably used for actual fault diagnosis, reducing the cost of manual judgment.

[0060] In a preferred embodiment of the present invention, step 6 includes:

[0061] Step 600 involves performing entity identification and relationship extraction on the real-time collected fault data to generate a real-time fault feature vector. This specifically includes: collecting real-time fault data through an operations and maintenance monitoring system, such as log monitoring or performance monitoring tools, including the fault occurrence time, involved operations and maintenance entities (servers, network devices, application services, etc.), and descriptions of fault phenomena, such as service response timeouts, network interruptions, and key performance indicators, such as CPU utilization, memory usage, and network bandwidth; extracting operations and maintenance entities from the fault data, such as server A, switch B, and order services, and determining the entity type (server node, network device node, etc.). (Application service nodes); analyze the relationships between entities, such as server A running order services and switch B connecting to server A, and construct a network of entity relationships involved in real-time faults, ensuring consistency with the operation and maintenance relationship network structure constructed in step 200; standardize the extracted fault features, such as CPU utilization, fault duration, and number of affected entities, using the same Min-Max standardization formula as in step 401, and integrate the standardized features according to the dimensional order of the input feature vectors in step 500 to generate a real-time fault feature vector, ensuring that the dimensions are consistent with the input dimensions of the trained intelligent diagnostic model.

[0062] Step 601: Input the real-time fault feature vector into the trained intelligent diagnostic model to obtain preliminary solution recommendations. This includes: First, performing an input adaptation check on the real-time fault feature vector to confirm that the vector dimension matches the input dimension of the trained intelligent diagnostic model (gradient boosting decision tree model), with no missing dimensions; simultaneously checking the numerical range of each feature in the vector to ensure it conforms to the standardized range (0-1 interval) during model training; if outliers exist, i.e., the original value of a feature exceeds its historical extreme value, historical extreme value replacement is used, i.e., when the original value is greater than the historical maximum value of the feature, the corresponding standardized value is set to 1; when the original value is less than the historical minimum value of the feature, the corresponding standardized value is set to 0, ensuring that the feature vector input to the model is free from abnormal interference; inputting the adapted real-time fault feature vector into the trained intelligent diagnostic model, the model calls the stored complete parameters (including the structure of each regression decision tree, the optimal splitting feature and threshold of each tree, leaf node numbers and corresponding output value vectors, learning rate), and performing gradient boosting... The prediction logic of the decision tree is used for reasoning. First, the real-time fault feature vector is matched one by one with the leaf nodes of each regression decision tree to obtain the output value vector of each leaf node. Then, the output value vector of each tree is multiplied by the learning rate and accumulated. Combined with the initial baseline prediction value vector of the model, the preliminary solution label vector is finally output. This vector contains the solution type code and the standardized value of the execution parameters. For the solution type, according to the preset coding mapping table, such as 1 corresponding to restarting the service, 2 corresponding to replacing hardware, and 3 corresponding to repairing the network configuration, the specific solution type is determined by the type code in the label vector. For the execution parameters, inverse Min-Max standardization is used to restore the standardized value to the actual value. For example, if the standardized value of a certain execution time is 0.5, its historical maximum value is 60 minutes, and its historical minimum value is 10 minutes, then the actual execution time = 0.5 × (60 - 10) + 10 = 35 minutes. This ensures that the parsed execution parameters can be directly used for actual operation and maintenance, and finally forms a complete preliminary solution recommendation result.

[0063] Step 602: Adaptively adjust the preliminary solution recommendation based on the current operating status of each node in the real-time operation and maintenance relationship network to generate the final dynamic solution. Specifically, this includes: obtaining the current operating status of each node in the real-time operation and maintenance relationship network through the operation and maintenance monitoring system, including node online / offline status, key performance indicators such as CPU utilization, memory usage, network latency, and load conditions such as current connection count and task queue length, forming a node state vector; for target nodes involved in the preliminary solution, such as application service nodes corresponding to service restarts or server nodes corresponding to hardware replacements, determine whether their current status meets the execution conditions of the preliminary solution. If the target node's current CPU utilization... If the U utilization rate exceeds a preset threshold, such as 80%, restarting the service may result in task loss. The solution should be adjusted to migrate tasks first and then restart. If the target node is currently offline, hardware replacement should prioritize starting a backup node. For related nodes, such as database nodes and network nodes that the target node depends on, if they currently have performance bottlenecks, such as database response latency exceeding a threshold, supplementary steps to optimize the performance of related nodes should be added to the initial solution. Based on the state adaptability assessment results, adjust the type or execution parameters of the initial solution, such as extending the task migration waiting time or adding a backup node startup step, and integrate them into a final dynamic solution to ensure that the solution can be executed safely and efficiently in the current operational environment.

[0064] Step 603 involves storing the real-time fault feature vector, the final dynamic solution, and the actual processing effect as new knowledge samples in the knowledge base, thus constructing the intelligent operation and maintenance knowledge base. Specifically, this includes: organizing the real-time fault feature vector (after standardization) and the final dynamic solution (including type, actual values ​​of execution parameters, adjustment reasons, and actual processing effects, such as fault resolution time, post-processing node recovery status, and business impact scope) into new knowledge samples according to the fault feature-solution-processing effect structure; storing these new knowledge samples in the intelligent operation and maintenance knowledge base using a structured storage method (such as a database table), with fields including sample number, fault occurrence time, fault feature vector, solution details, processing effect, and associated historical sample number (if similar to a historical fault); establishing an association index between samples, such as categorizing by fault type, involved node type, and solution type; and periodically cleaning up redundancy in the knowledge base samples, such as deleting duplicate samples and validating validity, such as marking invalid solution samples, to ensure the accuracy and usability of the knowledge base samples.

[0065] This embodiment transforms unstructured real-time fault data into standardized feature vectors through entity recognition and standardization, ensuring compatibility with the input of the trained model while preserving entity relationship information to avoid model inference errors caused by inconsistent data formats. Based on the trained intelligent diagnostic model, it quickly outputs preliminary solutions, shortening response time compared to manual diagnosis. Furthermore, label vector parsing and inverse standardization ensure the readability and usability of the solutions, reducing the cost of manual interpretation. The solution is dynamically adjusted based on the real-time node operating status, avoiding execution failures or inefficiencies caused by static solutions being unsuitable for the current environment, thus improving the feasibility and security of the solution and reducing operational risks. Finally, real-time fault processing data is transformed into knowledge base samples, enabling the structured accumulation of operational experience and continuously improving intelligent operation and maintenance capabilities.

[0066] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0067] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0068] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for constructing an intelligent operation and maintenance knowledge base, characterized in that, The method includes: Step 1: Collect raw operation and maintenance data from monitoring components, log components, and configuration management database to obtain multi-source heterogeneous real-time data streams; perform entity identification and relationship extraction on the multi-source heterogeneous real-time data streams to obtain operation and maintenance entities and the relationships between them. Step 2: Based on the operation and maintenance entities and the relationships between them, construct an operation and maintenance relationship network. In the operation and maintenance relationship network, select the two operation and maintenance entities with the largest number of direct connections as the baseline nodes based on the statistical results of the number of direct connections between each node. Step 3: Based on the topological connection relationship between the two benchmark nodes, generate a benchmark analysis path and divide the benchmark analysis path into multiple analysis segments according to the consistency of entity types in the path; Step 4: Perform fault correlation analysis on each analysis segment to obtain the weight adjustment coefficient for each analysis segment; associate historical fault records with the operation and maintenance relationship network, and perform weighted vectorization processing on historical fault features based on the weight adjustment coefficient to obtain optimized vectorized fault events. This includes: calculating the frequency ratio of each analysis segment in various fault events based on the statistical results of fault impact range recorded in historical fault records to obtain the fault correlation score for each analysis segment; mapping the fault correlation score to a preset numerical range to obtain the weight adjustment coefficient for each analysis segment; matching operation and maintenance entities in historical fault records with nodes in the operation and maintenance relationship network to establish the mapping relationship between historical fault events and the operation and maintenance relationship network; and performing weighted calculation on the feature vectors of historical fault events based on the weight adjustment coefficient to obtain optimized vectorized fault events. Step 5: Based on the optimized vectorized fault events and corresponding historical solutions, construct and train the intelligent diagnostic model to obtain the trained intelligent diagnostic model. Step 6: Input the real-time fault data into the trained intelligent diagnostic model for processing to obtain a dynamic solution for the current fault, thus completing the construction of the intelligent operation and maintenance knowledge base.

2. The method for constructing an intelligent operation and maintenance knowledge base according to claim 1, characterized in that, Step 1 includes: Based on the metric data collected from the monitoring component, the log text data collected from the log component, and the configuration item data collected from the configuration management database, the data format is unified to obtain preprocessed data with a unified data format. Based on the preprocessed data, timestamp alignment is performed to obtain a consistent time series of multi-source heterogeneous real-time data streams; Based on multi-source heterogeneous real-time data streams, application service instances, server nodes, and network device entities are extracted to obtain a set of basic operation and maintenance entities. Based on the basic set of operation and maintenance entities, the call dependencies between application service instances and the deployment relationships between service instances and server nodes are extracted to obtain a complete set of operation and maintenance entities with structured relationships.

3. The method for constructing an intelligent operation and maintenance knowledge base according to claim 2, characterized in that, Step 2 includes: Based on the complete set of operation and maintenance entities with structured relationships, each operation and maintenance entity is mapped to a network node, and the relationships between entities are mapped to network edges, thus constructing a complete topological operation and maintenance relationship network. In this network, nodes represent operation and maintenance entities, and edges represent the relationships between operation and maintenance entities. Based on the operation and maintenance relationship network, calculate the degree centrality value of each network node, that is, count the number of edges directly connected to each node, and obtain the set of degree centrality values ​​of all nodes. Based on the set of degree centrality values, the operation and maintenance entities corresponding to the two network nodes with the largest degree centrality values ​​are selected as the baseline nodes.

4. The method for constructing an intelligent operation and maintenance knowledge base according to claim 3, characterized in that, Step 3 includes: Calculate and generate a baseline analysis path based on the shortest connection path between two baseline nodes; Based on the entity type attributes of each node in the baseline analysis path, the path nodes are grouped according to three entity types: application service instance, server node, and network device. A set of consecutive nodes with the same entity type is divided into an analysis segment. Based on the entity type characteristics contained in each analysis segment, the type classification of each analysis segment is determined.

5. The method for constructing an intelligent operation and maintenance knowledge base according to claim 4, characterized in that, Step 5 includes: Based on the optimized vectorized fault events and corresponding historical solution records, a training sample set containing input feature vectors and output solution labels is constructed. Based on the training sample set, a gradient boosting decision tree model is constructed as an intelligent diagnostic model. The input feature dimension of the intelligent diagnostic model is consistent with the dimension of the vectorized fault events, and the output result dimension is consistent with the dimension of the solution label. The intelligent diagnostic model is trained based on the training sample set, and multiple iterations are performed until the preset number of iterations is reached to obtain the trained intelligent diagnostic model.

6. The method for constructing an intelligent operation and maintenance knowledge base according to claim 5, characterized in that, Based on the training sample set, a gradient boosting decision tree model is constructed as an intelligent diagnostic model. The input feature dimension of the intelligent diagnostic model is consistent with the dimension of the vectorized fault events, and the output result dimension is consistent with the dimension of the solution label, including: Based on the input feature vectors and output solution labels in the training sample set, set the initial parameters of the gradient boosting decision tree model, including the learning rate, the maximum depth of the tree, and the number of trees. Initialize the gradient boosting decision tree model based on the initial parameters, where the dimension of the input features is the same as the dimension of the input feature vector, and the dimension of the output result is the same as the dimension of the output solution label. Based on the initialized gradient boosting decision tree model, the model is trained using the training sample set, and the initial error is obtained by calculating the error between the prediction result and the output solution label. Based on the initial error, the gradient boosting algorithm is used to update the parameters of the gradient boosting decision tree model, resulting in the updated gradient boosting decision tree model. The training and parameter update process is repeated until the preset number of iterations is completed, resulting in the constructed gradient boosting decision tree model.

7. The method for constructing an intelligent operation and maintenance knowledge base according to claim 6, characterized in that, Step 6 includes: Entity recognition and relationship extraction are performed on the real-time collected fault data to generate real-time fault feature vectors. The real-time fault feature vector is input into the trained intelligent diagnostic model to obtain preliminary solution recommendation results. The preliminary solution recommendation results are adaptively adjusted based on the current operating status of each node in the real-time operation and maintenance relationship network to generate the final dynamic solution; Real-time fault feature vectors, final dynamic solutions, and actual processing results are stored as new knowledge samples in the knowledge base to realize the construction of an intelligent operation and maintenance knowledge base.

8. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images