Critical path and node identification system and method

Abstract

The invention discloses a key path and node identification system and method, and relates to the technical field of cloud services, the system comprises a data processing module, a graph structure module and an identification module; the data processing module is used for preprocessing API data of the cloud service to obtain standardized data; the graph structure module is used for performing relation mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure; and the identification module is used for identifying a core key path of the graph structure through a preset search algorithm, and exploring through a depth-first search strategy and a breadth-first search strategy to obtain a key path and a node. According to the application, the API data of the cloud service is converted into the graph structure, and the graph structure is explored by the preset search algorithm, the depth-first search strategy and the breadth-first search strategy in the identification module, so that key paths and nodes of the cloud service can be efficiently and accurately identified.

Description

Technical Field

[0001] The present application relates to the field of cloud service technology, and in particular to a critical path and node identification system and method. Background Art

[0002] With the development of technologies such as artificial intelligence, big data, and cloud native, as well as the development and popularization of microservice architecture, user-oriented applications have also gradually evolved from traditional monolithic architecture to microservice architecture, and cloud services are gradually becoming the mainstream computing model. Deploying user-oriented applications in cloud services can not only benefit from the low access latency of edge nodes, but also make full use of the high computing power of cloud nodes, thereby achieving faster response speed and better user experience.

[0003] With the widespread application of cloud services, the complexity and uncertainty of the system have also increased. Chaos drills, as an effective fault testing method, can simulate various fault scenarios without affecting the production environment, and can test the robustness and fault tolerance of the system. However, in the cloud service environment, due to the large number of system components and the complex interdependencies, it has become a challenge to determine the critical paths and key nodes. Traditional evaluation methods often rely on expert intuition and manual analysis, resulting in inaccurate and inefficient evaluation. Summary of the invention

[0004] The main purpose of this application is to provide a critical path and node identification system and method, aiming to solve the technical problem that traditional critical path and critical node evaluation methods often rely on expert intuition and manual analysis, resulting in inaccurate and inefficient evaluation.

[0005] To achieve the above-mentioned purpose, the present application proposes a critical path and node identification system, the system comprising: a data processing module, a graph structure module and an identification module;

[0006] The data processing module is used to pre-process the API data of the cloud service to obtain standardized data;

[0007] The graph structure module is used to perform relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure;

[0008] The identification module is used to identify the core critical path of the graph structure through a preset search algorithm;

[0009] The identification module is also used to explore the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

[0010] In one embodiment, the data processing module is further used to extract key dimension information from the API data of the cloud service to obtain a key data set;

[0011] The data processing module is further used to clean the key data set to obtain a cleaned key data set;

[0012] The data processing module is further used to format the cleaned key data set to obtain a key data set in a unified format;

[0013] The data processing module is also used to standardize the key data sets in the unified format to obtain standardized data.

[0014] In one embodiment, the graph structure module is further used to map system components into graph nodes according to the system topology of the cloud service;

[0015] The graph structure module is further used to convert the dependency relationship of the system components into graph edges;

[0016] The graph structure module is further used to perform relationship mapping according to the standardized data, the graph nodes and the graph edges to obtain a graph structure.

[0017] In one embodiment, the graph structure module is further used to extract key features according to the topological structure between the graph nodes and the graph edges;

[0018] The graph structure module is further used to use the system component interaction strength of the key feature as an edge weight;

[0019] The graph structure module is further used to perform relationship mapping between the graph nodes and the graph edges according to the edge weights and the standardized data to obtain a graph structure.

[0020] In one embodiment, the identification module is further used to create an open list and an explored list according to the graph structure, wherein the starting node of the graph structure is added to the open list and the next intermediate target node is used as the end point;

[0021] The identification module is further used to perform path exploration on the graph structure based on the open list and the explored list by using an A search algorithm and a heuristic function to obtain a core critical path.

[0022] In one embodiment, the identification module is further used to perform a depth search task on nodes on the core critical path based on the core critical path, starting from the starting point, using a depth-first search strategy;

[0023] The identification module is further used to perform parallel search tasks in adjacent areas of the core critical path through a breadth-first search strategy;

[0024] The identification module is further used to collect all identified key paths and nodes after the deep search task and the parallel search task are completed.

[0025] In one embodiment, the critical path and node identification system further includes a fault prediction module;

[0026] The fault prediction module is used to extract features according to the A search algorithm data, the depth-first search data and the breadth-first search data in the recognition module to obtain multiple feature data;

[0027] The fault prediction module is further used to train a preset gradient boosting decision tree model according to the multiple feature data;

[0028] The fault prediction module is also used to predict system data through the trained model to find key services or components.

[0029] In one embodiment, the fault prediction module is further used to perform feature processing on the multiple feature data to obtain processed feature data;

[0030] The fault prediction module is further used to construct a feature vector associated with a path and a node based on the processed feature data;

[0031] The fault prediction module is also used to initialize the GBDT parameters of the preset gradient boosting decision tree model;

[0032] The fault prediction module is also used to train the preset gradient boosting decision tree model according to the feature vector and the GBDT parameters.

[0033] In one embodiment, the fault prediction module is further used to predict system nodes, obtain prediction results, and generate a probability score of each node becoming a fault point in the chaos exercise;

[0034] The fault prediction module is further used to integrate the possibility score and the prediction result to obtain a set of key nodes and paths;

[0035] The fault prediction module is also used to optimize the trained model according to the key nodes and path sets.

[0036] In addition, to achieve the above purpose, the present application also proposes a critical path and node identification method, which is applied to a critical path and node identification system, the system including a data processing module, a graph structure module and an identification module; the method includes:

[0037] The data processing module pre-processes the API data of the cloud service to obtain standardized data;

[0038] The graph structure module performs relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure;

[0039] The identification module identifies the core critical path of the graph structure through a preset search algorithm;

[0040] The identification module explores the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

[0041] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a critical path and node identification system, the system comprising: a data processing module, a graph structure module and an identification module; the data processing module is used to preprocess the API data of the cloud service to obtain standardized data; the graph structure module is used to perform relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure; the identification module is used to identify the core critical path of the graph structure through a preset search algorithm; the identification module is also used to explore the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service. Since this application converts the API data of the cloud service into a graph structure, the graph structure is explored in the identification module using a preset search algorithm and a search strategy of a depth-first search strategy and a breadth-first search strategy, which can efficiently and accurately identify the critical path and nodes of the cloud service, avoiding the situation where the traditional evaluation method relies on expert intuition and manual analysis, thereby improving the accuracy and efficiency of critical path and node identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0044] Figure 1 Functional module diagram provided for the first embodiment of the critical path and node identification system of the present application;

[0045] Figure 2 This is an example diagram of the transfer service provided in Example 1 of the present application;

[0046] Figure 3 A flowchart of the A search algorithm provided in Example 1 of the present application;

[0047] Figure 4 Functional module diagram provided for the second embodiment of the critical path and node identification system of this application;

[0048] Figure 5 The overall implementation flow chart provided for this application;

[0049] Figure 6 Schematic diagram of the process of the key path and node identification method of the embodiment of the present application.

[0050] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0052] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0053] Traditional critical path and node evaluation methods generally have the following shortcomings:

[0054] (1) Usually based on subjective judgment and manual analysis, the evaluation results are not objective and accurate enough.

[0055] (2) The time and cost of the evaluation process increase, limiting its scope of application and efficiency.

[0056] (3) The evaluation method cannot accurately and effectively recommend chaos drill cases and lacks an immediate feedback and adjustment mechanism.

[0057] Therefore, how to quickly and accurately identify critical paths and nodes and design targeted chaos drill cases based on them has become a difficult problem that needs to be solved urgently.

[0058] To this end, this application proposes a critical path and node identification system, which combines the search strategies of the A-search heuristic algorithm and the graph algorithm (depth-first search strategy and breadth-first search strategy) with the learning ability of the gradient boosting decision tree model. It can efficiently and accurately identify the critical paths and nodes in the system, providing strong support for system optimization and fault prevention.

[0059] Based on this, the embodiment of the present application provides a critical path and node identification system, referring to Figure 1 , Figure 1This is a functional module diagram provided for Example 1 of the key path and node identification system of this application.

[0060] In this embodiment, the critical path and node identification system includes: a data processing module 10 , a graph structure module 20 and an identification module 30 .

[0061] The data processing module 10 is used to pre-process the API data of the cloud service to obtain standardized data.

[0062] It should be noted that the data processing module is mainly responsible for data collection and preprocessing. It is responsible for collecting system service topology, system monitoring data, log data and other information related to key path and node identification from the cloud service observability platform, and performing data cleaning, integration and standardization processes to provide a high-quality data foundation for subsequent identification and analysis.

[0063] It should be noted that the cloud service observability platform is a platform used to comprehensively monitor the cloud service environment. It can collect and integrate various data from all levels of cloud services (such as infrastructure, network, applications, etc.), including performance indicators, log information, events, etc.

[0064] It should be noted that API (Application Programming Interface) data is data that is interactively called with other systems through the API interface.

[0065] When a program or application in a cloud service interacts with other systems, the API can be used to send requests in the specified format and protocol. The other system processes the request and returns the corresponding data. The returned data is the data obtained through the API call.

[0066] It should be noted that standardized data is the data obtained after the API data is cleaned, integrated and standardized to eliminate the scale differences between different data in the API data.

[0067] In this embodiment, in the initial stage of the critical path and node identification system, the data processing module can obtain deep monitoring data (i.e., API data) from the cloud service observability platform, and then perform data cleaning, integration, and standardization on the API data to obtain standardized data to eliminate the scale differences between different data in the API data.

[0068] In a feasible implementation manner, the data processing module 10 described in this embodiment is also used to extract key dimension information from the API data of the cloud service to obtain a key data set; the data processing module 10 is also used to clean the key data set to obtain a cleaned key data set; the data processing module 10 is also used to format the cleaned key data set to obtain a key data set in a unified format; the data processing module 10 is also used to standardize the key data set in the unified format to obtain standardized data.

[0069] It should be noted that key dimension information is information of different key dimensions extracted from API data during data collection to obtain key data sets, such as call complexity, concurrent processing, fault tolerance, state, and other key dimensions, which are not limited in this embodiment.

[0070] For ease of understanding, the data collection process is illustrated by taking the collection of 10 key dimensions as an example. The data processing module can perform in-depth analysis on the top n most active API data in the cloud service and extract data from 10 core dimensions to fully understand the dynamics and vulnerabilities of the service. Specifically:

[0071] 1. Call complexity (call_complexity): Measures the call structure and hierarchy of services.

[0072] 2. Concurrency processing (concurrency_load): Evaluate service performance by the average number of concurrent requests.

[0073] 3. Dependency network (dependency_network): Quantify the diversity of dependencies between services.

[0074] 4. Asynchronous behavior (async_behavior): Analyze the asynchronous interaction mode of the service.

[0075] 5. Transaction behavior (transaction_behavior): Evaluates the complexity of the transactions processed.

[0076] 6. Fault tolerance (resilience_rating): Consider error handling strategies and recovery mechanisms.

[0077] 7. Statefulness (statefulness_factor): Evaluates whether the service is a stateful service and its management complexity.

[0078] 8. Network impact (network_topology_impact): Analyze the impact of network architecture on services.

[0079] 9. Historical performance (historical_performance): reflects the stability of the service through historical response time.

[0080] 10. Resource pressure (resource_pressure): Measures CPU, memory, and I / O resource utilization.

[0081] It should be noted that the purpose of data cleaning is to ensure data quality.

[0082] Among them, the process of data cleaning may include: first, processing missing values ​​for key data sets, which includes checking whether there are missing values ​​in the key data sets. According to the characteristics of API data and business needs, appropriate strategies can be used to handle these missing values, such as forward filling, backward filling, or using default values, or directly removing records with missing values. Then deal with duplicate values. Since API call records may be repeated, redundant copies can be identified and deleted, but if the duplicate records reflect important information such as high-frequency calls to the API, they will be retained. Finally, for possible outliers, such as data anomalies caused by system errors or network delays, the Z-score statistical method (a statistical analysis method based on standard scores) can be used for detection. According to the analysis requirements, it is decided whether to retain, correct, or delete outliers, as well as fix format and logical errors. Finally, the cleaned key data set is obtained.

[0083] It should be noted that formatting is the process of integrating the data in a data set to varying degrees for subsequent analysis and processing.

[0084] Specifically, the formatting process may include: First, the cleaned key data sets can be converted into a unified format, such as using a standard date and time format, a unified unit of measurement, etc. Second, for non-numeric data (such as text, enumeration values, etc.), a mapping table or coding table can be established for subsequent analysis and processing. Next, data from different sources can be associated and integrated according to the API to form a complete API data view. Finally, the data can be stored in a relational database, a NoSQL database (Not Only SQL, a non-relational database) or a time series database for subsequent analysis and query.

[0085] By integrating the cleaned key data sets to different degrees, a key data set in a unified format can be obtained to facilitate subsequent analysis and processing by the key path and node identification system.

[0086] It should be noted that the purpose of data standardization is to convert data of different scales to the same scale for comparison and analysis in order to eliminate the scale differences between different data.

[0087] Exemplarily, the process of data standardization is described using the Z-score standardization method, as follows:

[0088] Since API data is continuous and data of different scales need to be converted to the same scale for comparison and analysis, the Z-score standardization method is appropriate. Among them, Z-score standardization is to convert each data point in the key data set of unified format into the standard deviation multiple of its mean, thereby eliminating the scale differences between different data. Finally, standardized data is obtained.

[0089] The calculation formula of score is:

[0090]

[0091] Among them, x is the original data point (i.e., the key data set in a unified format), μ is the mean of the key data set in a unified format, and σ is the standard deviation of the key data set in a unified format.

[0092] After applying Z-score normalization, the dataset will be presented in the form of a standard normal distribution with a mean of 0 and a standard deviation of 1. This will make the comparison between different API data easier and more intuitive.

[0093] However, during the standardization process, the following points need to be noted:

[0094] 1. If the key data set in a unified format is large, it may take some time to calculate the mean and standard deviation. To improve efficiency, you can use incremental calculation methods or distributed computing frameworks.

[0095] 2. In some cases, if the distribution of API data is not normal, Z-score normalization may not be the best choice. In this case, other normalization methods such as Min-Max normalization or Robust Scaler feature scaling method can be used to scale the data.

[0096] 3. Before performing Z-score standardization, you need to check whether the data set contains extreme values ​​or outliers. These values ​​may have a significant impact on the mean and standard deviation and cause inaccurate standardization results. If these values ​​exist in the data, they can be processed before standardization.

[0097] 4. After the above data cleaning and formatting process is completed, data quality checks can be performed to ensure the accuracy, completeness and consistency of the data. Data quality checks can be performed using automated tools or manual spot checks.

[0098] After completing the above steps, the standardized data will be used for subsequent key node and key path identification.

[0099] In this implementation, by extracting key dimension information, the dynamics and vulnerability of the service can be fully understood. Data cleaning can ensure data quality. By formatting the cleaned key data sets to different degrees, the key path and node identification system can be used for subsequent analysis and processing. By data standardization, data of different scales can be converted to the same scale for comparison and analysis to eliminate scale differences between different data.

[0100] The graph structure module 20 is used to perform relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure.

[0101] It should be noted that the main function of the graph structure module is graph structure construction and feature encoding. After the above data processing stage, the graph structure module can reveal the interaction between system components of cloud services by converting standardized data into a graph model.

[0102] It should be noted that the system topology refers to the physical layout of various devices in the cloud service, that is, the form in which various sites in the network are connected to each other. It reflects the physical shape and structure of the cloud service network.

[0103] It should be noted that the system components are various network components of cloud services, such as security components, network components, middleware, monitoring and log components, etc., which are not limited in this embodiment.

[0104] It should be noted that the graph structure is a graph model that represents the system components and their interactions in cloud service chaos engineering.

[0105] In this implementation, after the stage of the above-mentioned data processing module, the graph structure module can construct a graph structure and perform feature encoding on the system topology structure of the cloud service according to the standardized data to obtain a graph structure.

[0106] In a feasible implementation, the graph structure module 20 described in this embodiment is also used to map system components into graph nodes according to the system topology structure of the cloud service; the graph structure module 20 is also used to convert the dependency relationships of the system components into graph edges; the graph structure module 20 is also used to perform relationship mapping according to the standardized data, the graph nodes and the graph edges to obtain a graph structure.

[0107] It should be noted that graph nodes are points that represent system components in a data structure called a graph structure. Dependencies are interactions between system components, such as service calls, data reading and writing, etc. Graph edges are edges in a data structure called a graph structure.

[0108] In this implementation, the system topology of the cloud service can be analyzed first, and all system components (such as various microservice components, databases, middleware, etc.) can be mapped as graph nodes. Each node has specific attributes, such as name, type, service call complexity, concurrent processing capability, historical fault records, etc. Then, dependency mapping is performed to determine the dependencies between system components, such as service calls and data reading and writing. These relationships are converted into graph edges. In this way, the standardized data is represented as a standardized graph structure, which contains information about system components and their relationships, and can be used as the basis for critical path and node identification in subsequent chaos exercises.

[0109] In another feasible implementation, the graph structure module 20 described in this embodiment is also used to extract key features based on the topological structure between the graph nodes and the graph edges; the graph structure module 20 is also used to use the system component interaction intensity of the key features as the edge weight; the graph structure module 20 is also used to perform relationship mapping between the graph nodes and the graph edges based on the edge weight and the standardized data to obtain a graph structure.

[0110] It should be noted that based on the topological structure of the graph structure, key features can be extracted, such as the degree of the node (indicating the number of nodes directly connected to the node), the path length (indicating the complexity of the transfer process) and the clustering coefficient (measuring the closeness of collaboration between services), etc., which are not limited in this embodiment.

[0111] Specifically, the process of determining edge weights may include: combining domain knowledge (such as call frequency, response time) to extract key information from key features. For example, the number of API calls can be used as edge weights to quantify the frequency of interactions between components. High-weight edges indicate critical paths or hotspots.

[0112] Specifically, in the calculation of edge weights, the edge weights can be determined based on the intensity or frequency of interaction between system components. If the original data provides direct interaction information, these can be used directly as weight values. Otherwise, indirect indicators such as the number of API calls and data traffic can be used to estimate weights to reflect the degree of interaction between components.

[0113] Edges with high weights usually indicate frequent interactions, which may correspond to the critical path or bottleneck of the system. For example, the edge between the frequently called risk assessment service and the transfer service has a high weight, while the edges with low frequency calls represent minor interactions. If the data contains information about the frequency or intensity of interactions between components, it can be used directly as the weight of the edge. If there is no direct information, other indicators (such as the number of calls, data transfer volume, etc.) can be used to calculate the weight. The attributes of the edge may include the relationship type and weight, and the weight is based on the frequency or intensity of the interaction.

[0114] For ease of understanding, the example of converting data into a standardized graph structure in a money transfer service is used for illustration. Figure 2 , Figure 2 An example diagram of the transfer service provided in Example 1 of the present application. A transfer API request is initiated from an account node, passes through a transfer service node, and may need to go through a verification service and a risk assessment service to ultimately update the account information involved in the database (update transfer records and update account balances), while storing dynamic account information through the kafka middleware. Edges represent interactions between these services, such as a transfer service calling a verification service, a risk assessment service, and read and write operations with a database. Edge attributes may include request frequency, transaction amount, and success / failure rate.

[0115] For example, the transfer process is as follows: transfer API request-transfer service, transfer service-verification service, transfer service-risk assessment service, transfer service-account B (receive transfer). These APIs can be mapped as graph nodes in the graph, and the relationships between them are mapped as edges to obtain a graph structure.

[0116] like Figure 2 As shown, the nodes represent the key components of the system: Account A: represents the account of the initiator of the transfer. Transfer service: a central service that processes transfer requests. Verification service: verifies the legitimacy of the transfer. Risk assessment service: assesses transaction risks. Database: stores account information and transaction records.

[0117] Edges represent dependencies and interactions between components: A transfer request is sent from account A to the transfer service. The transfer service relies on the verification service and the risk assessment service to complete the transfer. After the transfer is successful, the transfer service updates the account balance and transfer record in the database.

[0118] The weight of the edge can be expressed as the frequency of calling each service. For example, the edge weight from the transfer service to the verification service and risk assessment service is high because these services are required for each transfer.

[0119] Through this graph structure, potential critical paths (such as the transfer process of the transfer API) and key nodes (such as the transfer service and database) can be identified.

[0120] In this way, the standardized data is represented as a standardized and weighted graph structure, which contains information about system components and their relationships. This graph structure can be used as the basis for the identification of key paths and nodes in subsequent chaos exercises.

[0121] In this implementation, each node of the graph structure represents a system component of the cloud service, whose characteristics incorporate key attributes such as call complexity, concurrent processing capabilities, and historical performance. The edges of the graph structure depict API calls, resource exchanges, or dependencies, forming a dynamic network between components. The weights of the edges are intelligently assigned based on core performance indicators such as call frequency, resource consumption, and response time to quantify the intensity of interaction and dependency between services. This representation optimizes the identification of key paths and nodes, providing an intuitive and information-rich structure for subsequent graph searches.

[0122] The above are only two feasible implementation methods of the graph structure module provided in this embodiment, and this embodiment does not specifically limit the specific implementation method of the graph structure module.

[0123] The identification module 30 is used to identify the core critical path of the graph structure through a preset search algorithm.

[0124] It should be noted that the main function of the identification module is to identify key paths and nodes. It can combine graph algorithms with preset search algorithms to intelligently identify key paths and nodes in the cloud service environment based on indicators such as API call relationships, resource utilization, and response time. These key paths and key points are the focus of attention and inspection.

[0125] It should be noted that the preset search algorithm is a pre-set algorithm for searching, such as A search algorithm, binary search, sequential search, etc., and this embodiment does not limit this.

[0126] It should be noted that the core critical paths are the critical paths obtained after identifying the graph structure through the preset search algorithm. These paths reveal the key operations and potential problems of the system.

[0127] In this implementation, the identification module can intelligently identify the core critical paths of the graph structure through a preset search algorithm based on indicators such as API call relationships, resource utilization, and response time. These paths reveal the key and potential problems of the system's operation.

[0128] In a feasible implementation, the identification module 30 described in this embodiment is also used to create an open list and an explored list based on the graph structure, wherein the starting node of the graph structure is added to the open list and the next intermediate target node is used as the end point; the identification module 30 is also used to perform path exploration on the graph structure based on the open list and the explored list through the A search algorithm and the heuristic function to obtain the core critical path.

[0129] It should be noted that the open list, also known as the list of nodes to be expanded, is used to store nodes that have not been explored in the search algorithm. These nodes are waiting to be further processed and expanded in the subsequent search process.

[0130] The Closed List is used to store nodes that have been explored in the search algorithm. These nodes are placed in this list to avoid repeated exploration of them, improve search efficiency and avoid loops. By maintaining these two lists, the search algorithm can effectively manage the progress and status of the search.

[0131] It should be noted that the A search algorithm is an algorithm that finds the path with the lowest passing cost on a graph structure plane with multiple nodes.

[0132] The heuristic function is used in the A search algorithm to estimate the "distance" or "cost" from the current node to the target node. By defining a suitable heuristic function, the search can be guided in a direction that is more likely to approach the target, thereby improving the search efficiency.

[0133] For ease of understanding, the implementation process of the A search algorithm is used as an example for explanation. Figure 3 , Figure 3 This is a flowchart of the A search algorithm provided in Example 1 of the present application. The core of the A search algorithm is to comprehensively calculate the actual cost g(n) and the estimated cost h(n) of each node in the OPEN table to form an evaluation function f(n)=g(n)+h(n).

[0134] Among them, g(n) represents the actual path cost from the starting point to node n in the graph structure. h(n) is the heuristic estimated cost from node n to the target node, which is crucial to the efficiency of the search path.

[0135] The basic algorithm flow is as follows Figure 3 As shown:

[0136] 1. Initialization.

[0137] Start by creating the OPEN table, create the CLOSE table, add the initial node s to the OPEN table, and use the next intermediate target node as the end point.

[0138] OPEN table (open list): a priority queue that stores the nodes to be explored, usually implemented using a minimum heap to quickly find the node with the smallest f value.

[0139] CLOSE table (explored list): records the explored nodes to avoid repeated exploration.

[0140] Set the starting point S and the target point T, and calculate the cost of the starting node: calculate the g(S) value of the starting node S (the actual cost from the starting point to the current point). Since the starting point is itself, g(S) = 0.

[0141] Calculate the h(S) value of the starting node S (the estimated cost from the current point to the target point) and use a suitable heuristic function for estimation.

[0142] Calculate the f(S) value (total cost) of the starting node S, f(S) = g(S) + h(S).

[0143] 2. Main loop.

[0144] Determine whether the OPEN table is empty. If the OPEN table is empty, the process fails and exits, indicating that there is no path to reach. Otherwise, select the node n corresponding to the minimum f(n) from the OPEN table as the current node, and move the current node n into the CLOSE table.

[0145] Then determine whether n is an intermediate target node. If so, save this shortest path, clear the list, put the current intermediate target node as the new starting node n into the OPEN table, and the next intermediate target node as the end point; then expand the neighborhood to the current node, and put the new node n that is not in the CLOSE table into the OPEN list; finally return to execute the calculation of the valuation function f(n) = g(n) + h(n) for each node in the OPEN table. If n is not an intermediate target node, determine whether n is the final target point.

[0146] If n is not the final target point, the neighborhood is expanded to the current node, and the new node n that is not in the CLOSE table is retained; then different operations are performed according to whether the new node n is in the OPEN table: if the new node n is in the OPEN table, the current g(n) of the new node n is compared with the previous g(n), and the current g(n) is updated to a smaller value; if the new node n is not in the OPEN table, the new node s is placed in the OPEN list; then the execution is returned to determine whether the OPEN table is empty. If n is the final target point, the complete shortest path is returned, and the search process ends.

[0147] It should be noted that in the process of identifying critical paths and nodes, the design of the heuristic function h(n) is key. This function aims to estimate the most sensitive path from node n to the target state in the transaction processing flow. h(n) takes into account multiple factors such as the complexity of service calls, concurrent processing, and dependencies. These factors constitute a multidimensional perspective for evaluating path vulnerability. The design of the heuristic function h(n) needs to meet the following principles:

[0148] 1. The principles of adoptability and consistency must be met.

[0149] 2. Commonly used heuristics: Manhattan distance, Euclidean distance, etc. The specific choice depends on the application scenario and problem characteristics.

[0150] 3. h(n) factors in chaos drills: call chain length, number of components, response time, resource usage, network latency, middleware processing, business weight, and failure history, etc.

[0151] Therefore, the construction of h(n) is not only a mathematical model, but also a vulnerability analysis tool for the dynamic characteristics of the system. It provides strategic guidance for chaos exercises, helps identify and simulate sensitive points that may cause system failures, and then recommends targeted chaos experiment cases to enhance the resilience and reliability of the system. For example, a comprehensive heuristic function example is used to illustrate, which fully considers the characteristics of the transfer service:

[0152] h(n)=w1*call_complexity(n)+w2*concurrency_load(n)+w3*dependency_network(n)+w4*async_behavior(n)+w5*transaction_behavior(n)+w6*resilience_ratin g(n)+w7*statefulness_factor(n)+w8*network_topology_impact(n)+w9*historical_performance(n)+w10*resource_pressure(n).

[0153] Among them, call_complexity(n) represents the call complexity of node n, including the number of microservices called and the call level. concurrency_load(n) represents the processing capacity of node n in a concurrent environment, measured by the average number of concurrent requests. dependency_network(n) represents the dependency network of node n, quantifying the diversity of microservices it depends on. async_behavior(n) represents the proportion of asynchronous interactions in which node n participates, such as message queues or event-driven. transaction_behavior(n) represents the transaction mode processed by node n, such as TCC or SOGA features, and the complexity of transactions. resilience_rating(n) represents the fault tolerance of node n, including error handling strategies, circuit breakers, and rollback mechanisms. statefulness_factor(n) represents the statefulness of node n. Stateful services may introduce additional complexity and management requirements. network_topology_impact(n) represents the impact of network architecture on node n, such as the number and complexity of middleware and load balancers. historical_performance(n) represents the historical response time of node n, reflecting its performance stability. resource_pressure(n) represents the resource utilization of node n, including CPU, memory, and disk I / O, reflecting the degree of resource tension. The weight coefficients w1-w10 need to be carefully adjusted according to the actual operation status and business needs of the transfer system. For example, if the system has high requirements for real-time response, w9 may be larger; if the system architecture is complex, the weights of w3 and w8 may increase. Through this quantitative comprehensive evaluation, chaos drills can more accurately identify critical paths and nodes for targeted fault simulation and system optimization.

[0154] The weights w1-w10 of each factor reveal the relative importance of these factors in identifying the critical path by estimating the “cost” from the current node to the target in a weighted sum rather than the direct physical distance. This approach reflects the design philosophy of the A-search algorithm heuristic design, but it is not limited to simple spatial distance comparisons, but adopts an abstract cost estimation that adapts to the characteristics of the transaction system, such as data flow, network latency, and resource utilization.

[0155] The weight coefficients w1-w10 are usually set subjectively based on expert knowledge, historical data, and business needs. For example, historical data can be combined for statistical analysis to find the correlation between various factors and failures, performance bottlenecks, or system instability. The stronger the correlation, the larger the corresponding weight coefficient may be. Feedback can also be continuously collected during the chaos exercise, and the weight coefficient can be iteratively optimized based on the actual effect to make it closer to the actual needs.

[0156] It should be noted that even with a more objective approach, a certain degree of subjective judgment is inevitably involved, as business scenarios and priorities may change over time. Therefore, the setting of weight coefficients is usually a dynamic adjustment and iteration process.

[0157] In this implementation, the "distance" or "cost" from the current node to the target node in the graph structure is estimated by the A search algorithm, and a suitable heuristic function is defined to guide the search in a direction that is more likely to approach the target, thereby improving the search efficiency.

[0158] The identification module 30 is further used to explore the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

[0159] It should be noted that the implementation process of the Depth-First Search (DFS) strategy is: starting from the starting node, explore as deeply as possible along a path until you can no longer go forward, then backtrack to the previous node, and then try another branch path to continue exploring. Just like in a tree structure, first go deep into the end of a branch and then backtrack.

[0160] The implementation process of the Breadth-First Search (BFS) strategy is: starting from the starting node, first visit all the directly adjacent nodes of the starting node in turn, then visit the adjacent nodes of these adjacent nodes in turn, and so on, expanding outward layer by layer. It focuses more on comprehensive exploration at the same level.

[0161] In this implementation, the core critical path is explored through the depth-first search strategy and the breadth-first search strategy to obtain the critical path and nodes of the cloud service. This multi-strategy fusion method takes into account the accuracy of path selection, the deep insight of DFS, and the extensive scanning capability of BFS, thereby improving the efficiency and accuracy of problem identification.

[0162] In a feasible implementation manner, the identification module 30 described in this embodiment is also used to perform a deep search task on the nodes on the core critical path based on the core critical path, starting from the starting point, using a depth-first search strategy; the identification module 30 is also used to perform a parallel search task in the adjacent area of ​​the core critical path through a breadth-first search strategy; the identification module 30 is also used to collect all identified critical paths and nodes after the deep search task and the parallel search task are completed.

[0163] Specifically, after the core critical path is identified by the above A-search algorithm, DFS exploration can be performed first: for the critical path determined by A-search, starting from the starting point, DFS is used to deeply explore the nodes on the path, layer by layer. Each time, an unvisited adjacent node is selected, marked as visited, and the exploration continues downward. If n is the target node, stop the A-search algorithm and record the critical path. Otherwise, add the unvisited neighbors of n to the OPEN list and calculate their f values.

[0164] Then, perform a BFS parallel search: Start a BFS parallel task in the adjacent area of ​​the critical path. For each critical node, create a parallel task to traverse all its adjacent nodes to ensure full coverage.

[0165] When a new key node or problem path is found, it is recorded and added to the queue for processing. In order to increase the processing speed, multi-threading or distributed computing can be used to process multiple BFS tasks at the same time to improve search efficiency.

[0166] The deep exploration of DFS reveals important nodes in the deep structure, while the broad coverage of BFS quickly detects potential problems related to critical paths. After all DFS and BFS tasks are completed, all identified key nodes and paths are collected. The results of A-search, DFS, and BFS are merged, and duplicate nodes and paths are removed to obtain the final chaos exercise target. This multi-strategy fusion method takes into account the accuracy of path selection, the deep insight of DFS, and the extensive scanning capability of BFS, thereby improving the efficiency and accuracy of problem identification in chaos engineering and providing precise positioning for system fault injection and stability testing.

[0167] In this embodiment, through the above-mentioned A search algorithm, combined with a comprehensive heuristic function h(n), which comprehensively considers system complexity, service interaction and resource utilization, the core critical paths in the system can be identified. These paths reveal the key and potential problems of the system's operation. Subsequently, DFS can be used to deepen the exploration of the path determined by the A search algorithm. Starting from the starting point of the path, each unexplored adjacent node is visited layer by layer until the target node is found or the entire path is traversed. At the same time, to ensure comprehensive coverage, BFS is executed in parallel, especially in the adjacent areas of the critical path. Each key node starts a parallel task to traverse all its adjacent nodes to ensure that no associations are missed. Multithreading or distributed computing is used to accelerate BFS and improve search efficiency.

[0168] In the technical solution provided in this embodiment, in the initial stage of the critical path and node identification system, the data processing module can obtain deep monitoring data (i.e., API data) from the cloud service observable platform, and then perform data cleaning, integration, and standardization processing on the API data to obtain standardized data to eliminate the scale differences between different data in the API data. After the stage of the above-mentioned data processing module, the graph structure module can construct and feature encode the system topology of the cloud service according to the standardized data to obtain the graph structure. Then the identification module can intelligently identify the core critical paths of the graph structure through a preset search algorithm based on indicators such as API call relationships, resource utilization, and response time. These paths reveal the key and potential problems of the system's operation. Finally, the core critical path is explored through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service. This multi-strategy fusion method takes into account the accuracy of path selection, the deep insight of DFS, and the extensive scanning capability of BFS, thereby improving the efficiency and accuracy of problem identification. Since the present embodiment converts the API data of the cloud service into a graph structure, the graph structure is explored in the identification module using a preset search algorithm and a depth-first search strategy and a breadth-first search strategy, which can efficiently and accurately identify the key paths and nodes of the cloud service, avoiding the situation where traditional evaluation methods rely on expert intuition and manual analysis, thereby improving the accuracy and efficiency of key path and node identification.

[0169] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 4 , Figure 4 This is a functional module diagram provided for Example 2 of the key path and node identification system of this application.

[0170] The critical path and node identification system described in this example further includes a fault prediction module 40 .

[0171] It should be noted that the reference Figure 5 , Figure 5 The overall implementation flow chart provided for this application. After the key path and node identification system is initialized, all identified key paths and nodes in the graph structure can be obtained through the above-mentioned data collection and preprocessing, A search algorithm and heuristic function. After that, this embodiment can also perform operations such as construction and verification of the GBDT model, experimental analysis, and model feedback and update based on the graph structure data, as follows:

[0172] The fault prediction module 40 is used to extract features according to the A search algorithm data, the depth-first search data and the breadth-first search data in the recognition module to obtain a variety of feature data.

[0173] It should be noted that the main function of the fault prediction module is to predict the failure of key services using GBDT (gradient boosted decision tree). Based on the identification of key paths and nodes, the GBDT (gradient boosted decision tree) model can be further introduced for training to enhance the ability to predict the possibility of chaos explosion. These models use historical chaos exercise data, resource utilization, response time and other multi-dimensional indicators to predict the key paths and nodes of transactions.

[0174] It should be noted that the A-search algorithm data is the heuristic cost (h(n)) and actual path from each node to the target state calculated during the execution of the A-search algorithm.

[0175] The depth-first search data and breadth-first search data (i.e., graph algorithm data) are the data collected by running DFS and BFS as mentioned above, such as the degree of nodes and path information.

[0176] It should be noted that the various feature data are characteristics of paths and nodes in cloud services, such as path cost characteristics, dependency characteristics, connectivity characteristics, etc., which are not limited in this embodiment.

[0177] Exemplarily, the feature extraction process may include: first, calculating the average heuristic cost and actual cost of each node, as well as the relative distance from the target state, to obtain the path cost feature. Then, the number of in-edges and out-edges of each node, as well as the diversity of dependencies (such as dependent service types) are counted to obtain the dependency feature. Then, the in-degree, out-degree, and total degree of the node are calculated to obtain the node degree feature. Next, the number of occurrences of the node in the DFS and BFS paths is counted to obtain the path frequency feature. Then, the shortest path length and the number of direct connections between the node and the known key nodes are calculated to obtain the connectivity feature. Then, the number of failures and failure rates of the node are extracted from the log or monitoring data to obtain the historical failure feature. Finally, the response time, throughput, and error rate of the node are collected, which may require time series data processing to obtain performance characteristics. Finally, the above-mentioned multiple feature data are obtained.

[0178] In this embodiment, the fault prediction module can collect the heuristic cost (h(n)) and actual path from each node to the target state calculated during the execution of the search algorithm A in the recognition module, as well as the above-mentioned running DFS and BFS, to perform feature extraction and obtain a variety of feature data.

[0179] The fault prediction module 40 is further used to train a preset gradient boosting decision tree model according to the multiple feature data.

[0180] It should be noted that the preset gradient boosting decision tree model (Gradient Boosting Decision Tree, GBDT) is a machine learning algorithm. In the gradient boosting decision tree, new decision trees are continuously constructed to fit the data, and each new tree is constructed to make up for the shortcomings of the previous tree, thereby improving the overall prediction performance through gradual improvement.

[0181] Specifically, during the training process of the preset gradient boosting decision tree model, a feature vector may be constructed for training, or the data set may be divided into a training set and a validation set for training to improve the performance of the model, which is not limited in this embodiment.

[0182] In this implementation, the fault prediction module may perform various trainings on the preset gradient boosting decision tree model according to the various feature data to improve the performance of the model.

[0183] In a feasible implementation manner, the fault prediction module 40 described in this embodiment is also used to perform feature processing on the multiple feature data to obtain processed feature data; the fault prediction module 40 is also used to construct a feature vector associating paths and nodes based on the processed feature data; the fault prediction module 40 is also used to initialize the GBDT parameters of the preset gradient boosting decision tree model; the fault prediction module 40 is also used to train the preset gradient boosting decision tree model based on the feature vector and the GBDT parameters.

[0184] Specifically, the process of feature processing may include: first, the numerical features of various feature data may be normalized using Min-Max scaling or Z-Score standardization to ensure that all numerical features are on the same scale. Then, the classification features (such as service type, error type) may be independently encoded or label encoded to obtain classification feature encoding. Finally, feature data is obtained.

[0185] Specifically, the process of constructing the feature vector may include: organizing all processed feature data into a row vector, forming a matrix with n rows (n is the number of nodes) and m columns (m is the number of features), and combining them into a matrix, where each row represents a node and each column represents a feature.

[0186] Among them, for the path-node association and key point index, new features can be created. For example, the overlap degree of nodes in A search path and graph algorithm path is taken as the weighted sum, and the key point index is defined as the weighted average of heuristic cost and path frequency.

[0187] For example, assume there are 5 nodes (n=5) and each node has 8 features (m=8):

[0188] Characteristics of node 1: heuristic cost 0.75, actual cost 10, in-degree 3, out-degree 2, path frequency 0.4, shortest path length 5, number of failures 1, error rate 0.05.

[0189] Characteristics of node 2: heuristic cost 0.8, actual cost 12, in-degree 4, out-degree 1, path frequency 0.3, shortest path length 4, number of failures 2, error rate 0.03.

[0190] Characteristics of node 3: heuristic cost 0.6, actual cost 8, in-degree 2, out-degree 3, path frequency 0.2, shortest path length 6, number of failures 0, error rate 0.02.

[0191] Characteristics of node 4: heuristic cost 0.9, actual cost 15, indegree 1, outdegree 4, path frequency 0.5, shortest path length 3, number of failures 3, error rate 0.07.

[0192] Characteristics of node 5: heuristic cost 0.7, actual cost 9, in-degree 3, out-degree 2, path frequency 0.1, shortest path length 7, number of failures 1, error rate 0.04.

[0193] After normalizing the numerical features and encoding the categorical features (assuming there are no categorical features), a feature matrix is ​​constructed (using Min-Max scaling, assuming a 0-1 range). This matrix is ​​the input of the GBDT model, with each row representing a node and each column being a feature value. The model will learn and predict the criticality of the node based on these features.

[0194] Then, in the process of model training, firstly, we can select appropriate GBDT parameters, such as the number of trees, the depth of the tree, the learning rate, the regularization parameter, etc. to configure the model. Then, we perform data segmentation, dividing the data set into a training set, a validation set, and a test set, usually in a ratio of 70%, 15%, and 15%. Then, we use the training set data to train the GBDT model, and use the validation set to select and tune the model to train the model. Finally, we evaluate the performance of the model on the test set, such as accuracy, recall, F1 score, etc.

[0195] In this embodiment, the preset gradient boosting decision tree model is trained by selecting appropriate GBDT parameters, data segmentation, model selection and tuning to improve the performance of the model.

[0196] The fault prediction module 40 is also used to predict system data through the trained model to find key services or components.

[0197] In this implementation, the trained model can be used to predict key nodes to predict new system data and identify potential key services or components.

[0198] Furthermore, the fault prediction module 40 is also used to predict system nodes, obtain prediction results, and generate a probability score for each node to become a fault point in the chaos exercise; the fault prediction module 40 is also used to integrate the probability score and the prediction results to obtain a set of key nodes and paths; the fault prediction module 40 is also used to optimize the trained model based on the set of key nodes and paths.

[0199] Specifically, the trained GBDT model can be used to predict system nodes and generate a probability score for each node to become a failure point in a chaos exercise.

[0200] Since the A-search algorithm and graph algorithms (such as DFS or BFS) have already determined the critical paths and nodes in the chaotic scenario in the previous stage, this information is no longer generated repeatedly, but is compared with the prediction results of the GBDT model.

[0201] Next, we integrate the results and screen the differences: First, we integrate the high-scoring nodes predicted by the model with the search results of the A-search algorithm and the graph algorithm to form a preliminary set of key nodes and paths. Then, we compare the results of different methods to find out the nodes that only appear in a single method, which may be potential key nodes.

[0202] For example, in the transfer system, we can represent the key components and their interactions as a graph structure. The graph structured data is as follows:

[0203] 1. Nodes: T (transfer service), V (verification service), R (risk assessment service), DB (database), K (Kafka middleware).

[0204] 2. Edge: TV, TR, VT, RT, T-DB, DB-T, TK, KT.

[0205] Among them, the GBDT model focuses on the performance and risk of services, while the A search algorithm focuses on the call path between services. The integration process is as follows:

[0206] 1. GBDT model prediction: Risk / important services: transfer service (T), verification service (V), risk assessment service (R). Prediction path: T→V→T→R→T.

[0207] 2. A search: Key components: database (DB), Kafka middleware (K). Identify the path: T→DB→T→K.

[0208] Finally, according to the above process, the optimization and integration results are as follows: Core services: T is determined as the core of the system because it appears in all paths. Critical paths: Two important paths, TVRT and T-DB-TK, are identified. Complementary components: V / R and DB / K are discovered by the model and algorithm respectively, which may reveal different risk points or performance bottlenecks in the system.

[0209] After integration, experiments can be designed to test the stability of core services, the response of verification services and risk assessment services, and the reliability of databases and Kafka middleware. Through fault injection or simulated delays, the system performance of these components under abnormal conditions can be evaluated.

[0210] Then conduct chaos simulation: design a series of simulated failures, target predicted key nodes and paths, and simulate failures or anomalies, such as sudden high load, delay, or fault injection. Record and analyze system responses in chaos experiments, such as service degradation, recovery time, cascading failures, etc.

[0211] Next, we conduct response evaluation: we analyze the experimental data and observe the behavior of the system under simulated failures. If the failure of critical nodes or paths leads to significant system impact, then these identifications are valid. For nodes that only appear in a single method, their criticality is verified based on the response of the chaos experiment.

[0212] Finally, optimize the results: adjust the key nodes and path sets according to the experimental results. If necessary, add nodes that were not originally in the prediction set. For nodes that the model predicts inaccurately, consider adjusting the model parameters or reengineering the features to improve the prediction accuracy.

[0213] Through this process, model prediction, graph algorithms, and chaos experiments can be combined to ensure that the identified critical paths and nodes are both data-driven and verified by actual system responses, which improves the accuracy and practicality of the identification.

[0214] In this implementation, the trained GBDT model is integrated with the A-search algorithm and the graph algorithm, and their complementary advantages are used to identify critical paths and nodes. GBDT learns nonlinear patterns through historical data, while the A-search and graph algorithms reveal the system structure and dynamic paths. This comprehensive approach improves recognition accuracy and avoids the limitations of a single model. By comparing and integrating the results, combined with the fault simulation of chaos drills, the recognition results are verified and optimized to ensure their effectiveness and decision-making value in real-world applications. Multi-angle analysis provides a data basis for fault prevention, performance improvement, and chaos engineering. In short, the steps of integrating model prediction with chaos experiments include: using GBDT to predict the fault point, and then comparing it with the chaotic scenario analysis results of the A-search and graph algorithms to enhance the reliability of recognition.

[0215] In the technical solution provided in this embodiment, by integrating the heuristic evaluation h(n) generated in the previous stage, the actual path data and the graph structure information, key features are extracted, including path attributes, dependencies, historical failures and performance indicators. These multi-angle features are converted into feature vectors to form a feature matrix as the input of the GBDT model. Model training aims to learn the connection between features and key nodes of the system, and to accurately predict elements that may affect stability. In the model application stage, the GBDT model predicts key nodes, and the chaos experiment is used as a verification tool to simulate failures and optimize the model based on experimental feedback to ensure that the model prediction is consistent with the actual system behavior, thereby improving the practical effect of chaos engineering.

[0216] Based on the first and second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those of the first and second embodiments can be referred to the above description, and will not be described in detail later. Figure 4 and Figure 5 As shown, the critical path and node identification system of this example also includes a visualization interaction module 50 for visualization presentation.

[0217] Specifically, the output of the visualization interaction module is presented in the form of a refined system topology diagram, which intuitively reveals the overall architecture of the system. The highlighted key nodes and paths are like the focus of the network. Through the differentiation of color, shape or legend, possible fault hotspots are highlighted, which makes it easier for users to quickly understand the key components and dependencies of the system. This visualization simplifies the understanding of complex networks and helps decision makers quickly locate potential problems.

[0218] At the same time, the module intelligently recommends matching cases from the case library based on the following core principles:

[0219] 1. Feature matching: Compare the features of the identified key paths and nodes (such as service type, dependency, performance indicators, etc.) with the features of the cases in the case library and calculate the similarity, such as using cosine similarity or Jaccard similarity.

[0220] 2. Failure mode analysis: Retrieve past failures that are similar to the currently identified critical paths and nodes, and consider the failure type, impact range, and recovery time. Next, compare system responses: match the system's response strategies and effects under similar critical path and node failures in the case, such as service interruption time, chain effects, repair strategies, and recovery speed.

[0221] 3. Impact assessment: The impact of the key node failure in the case on the overall system performance is compared with the currently identified key nodes.

[0222] 3. Solution library: Search historical cases for strategies that successfully solved similar problems, including architectural adjustments, redundant designs, fault-tolerant mechanisms, or emergency plans.

[0223] 4. Business relevance: Consider the impact of critical path and node failures on business processes and user experience, and match cases with similar impacts.

[0224] 5. Scoring and sorting: Assign a comprehensive score to each matching case, and display it to the user in descending order based on the weight of the above factors.

[0225] Through these matching principles and factors, the visual interaction module can provide users with targeted reference cases to help them understand and deal with the risks that may be brought about by the identified critical paths and nodes, as well as formulate corresponding prevention and response strategies.

[0226] The implementation of this patent significantly improves the efficiency and accuracy of chaos engineering. By combining a well-trained GBDT model with an A* heuristic algorithm and a graph search strategy, it achieves deep insights into the critical paths and nodes of complex systems. This method not only enhances the accuracy of fault prediction and reduces false positives and false negatives, but also makes up for the limitations of a single method through multi-model fusion analysis, ensuring a more comprehensive understanding of the system. The simulated faults in the chaos drills verify the identification results, further improve the adaptability of the predictions in real environments, and provide powerful decision-making support for preventing system failures. In addition, this innovative method optimizes resource allocation and reduces troubleshooting time, thereby improving the stability and performance of the overall system. Therefore, the present invention not only reduces operation and maintenance costs, but also enhances the reliability of cloud services, which is of great significance for improving service quality and user experience.

[0227] In the technical solution provided in this embodiment, a friendly user interface can be provided through a visual interaction module to display the system structure, key paths and node topology diagrams, as well as recommended chaos drill cases. Combining historical chaos drill cases, expert experience, and the prediction results of the possibility of chaos explosion, targeted case recommendations are provided for chaos drills. These recommended cases not only consider the key paths and nodes of the system, but also combine the prediction results to make chaos drills more accurate and effective.

[0228] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the key path and node identification system of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0229] This application also provides a critical path and node identification method, please refer to Figure 6 , Figure 6The flowchart of the critical path and node identification method of the embodiment of the present application is as follows; the critical path and node identification method is applied to a critical path and node identification system, the system includes a data processing module, a graph structure module and an identification module; the method includes:

[0230] Step S10: The data processing module pre-processes the API data of the cloud service to obtain standardized data.

[0231] Step S20: the graph structure module performs relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure.

[0232] Step S30: The identification module identifies the core critical path of the graph structure through a preset search algorithm.

[0233] Step S40: the identification module explores the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

[0234] Other embodiments or specific implementation methods of the key path and node identification method of the present application can refer to the above-mentioned system embodiments and will not be repeated here.

[0235] The critical path and node identification method provided by the present application is applied to the critical path and node identification system in the above-mentioned embodiment, and can solve the technical problem that the traditional critical path and critical node evaluation method often relies on the intuition and manual analysis of experts, resulting in inaccurate and inefficient evaluation. Compared with the prior art, the beneficial effects of the critical path and node identification method provided by the present application are the same as the beneficial effects of the critical path and node identification system provided by the above-mentioned embodiment, and the other technical features in the critical path and node identification method are the same as the features disclosed in the above-mentioned embodiment system, which will not be repeated here.

[0236] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A critical path and node identification system, characterized in that: The system comprises: a data processing module, a graph structure module and a recognition module; The data processing module is used to pre-process the API data of the cloud service to obtain standardized data; The graph structure module is used to perform relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure; The identification module is used to identify the core critical path of the graph structure through a preset search algorithm; The identification module is also used to explore the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

2. The system according to claim 1, characterized in that The data processing module is also used to extract key dimension information from the API data of the cloud service to obtain a key data set; The data processing module is further used to clean the key data set to obtain a cleaned key data set; The data processing module is further used to format the cleaned key data set to obtain a key data set in a unified format; The data processing module is further used to standardize the key data sets in the unified format to obtain standardized data.

3. The system according to claim 1, characterized in that The graph structure module is further used to map system components into graph nodes according to the system topology of the cloud service; The graph structure module is further used to convert the dependency relationship of the system components into graph edges; The graph structure module is further used to perform relationship mapping according to the standardized data, the graph nodes and the graph edges to obtain a graph structure.

4. The system according to claim 3, characterized in that The graph structure module is further used to extract key features according to the topological structure between the graph nodes and the graph edges; The graph structure module is further used to use the system component interaction strength of the key feature as an edge weight; The graph structure module is further used to perform relationship mapping between the graph nodes and the graph edges according to the edge weights and the standardized data to obtain a graph structure.

5. The system according to claim 1, wherein: The identification module is further used to create an open list and an explored list according to the graph structure, wherein the starting node of the graph structure is added to the open list and the next intermediate target node is used as the end point; The identification module is further used to perform path exploration on the graph structure based on the open list and the explored list by using an A search algorithm and a heuristic function to obtain a core critical path.

6. The system according to claim 1, wherein: The identification module is further used to perform a depth search task on the nodes on the core critical path based on the core critical path, starting from the starting point, using a depth-first search strategy; The identification module is further used to perform parallel search tasks in adjacent areas of the core critical path through a breadth-first search strategy; The identification module is further used to collect all identified key paths and nodes after the deep search task and the parallel search task are completed.

7. The system according to any one of claims 1 to 6, characterized in that The critical path and node identification system also includes a fault prediction module; The fault prediction module is used to extract features according to the A search algorithm data, the depth-first search data and the breadth-first search data in the recognition module to obtain multiple feature data; The fault prediction module is further used to train a preset gradient boosting decision tree model according to the multiple feature data; The fault prediction module is also used to predict system data through the trained model to find key services or components.

8. The system according to claim 7, characterized in that The fault prediction module is further used to perform feature processing on the multiple feature data to obtain processed feature data; The fault prediction module is further used to construct a feature vector associated with a path and a node based on the processed feature data; The fault prediction module is also used to initialize the GBDT parameters of the preset gradient boosting decision tree model; The fault prediction module is also used to train the preset gradient boosting decision tree model according to the feature vector and the GBDT parameters.

9. The system according to claim 8, characterized in that The fault prediction module is also used to predict system nodes, obtain prediction results, and generate a probability score for each node to become a fault point in the chaos exercise; The fault prediction module is further used to integrate the possibility score and the prediction result to obtain a set of key nodes and paths; The fault prediction module is also used to optimize the trained model according to the key nodes and path sets.

10. A critical path and node identification method, characterized in that: The critical path and node identification method is applied to a critical path and node identification system, the system comprising a data processing module, a graph structure module and an identification module; the method comprises: The data processing module pre-processes the API data of the cloud service to obtain standardized data; The graph structure module performs relationship mapping on the system topology structure of the cloud service according to the standardized data to obtain a graph structure; The identification module identifies the core critical path of the graph structure through a preset search algorithm; The identification module explores the core critical path through a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service.

Images