Critical path and node identification system and method

Abstract

The application discloses a key path and node identification system and method, relates to the technical field of cloud services, and comprises a data processing module, a graph structure module and an identification module. The data processing module is used for pre-processing API data of a cloud service to obtain standardized data. The graph structure module is used for performing relationship mapping on a system topology structure of the cloud service according to the standardized data to obtain a graph structure. 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 the key path and nodes. Since the API data of the cloud service is converted into the graph structure, the graph structure is explored in the identification module through the preset search algorithm and the depth-first search strategy and the breadth-first search strategy, and the key path and nodes of the cloud service can be efficiently and accurately identified.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud services, and particularly relates to a critical path and node identification system and method. BACKGROUND

[0002] With the development of artificial intelligence, big data, cloud native technology, and the development and popularization of microservice architecture, user-oriented applications are gradually evolving from traditional monolithic architecture to microservice architecture, and cloud services are gradually becoming the mainstream computing mode. Deploying user-oriented applications in cloud services not only benefits from the low access latency of edge nodes, but also fully utilizes 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 exercise, 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 complex interdependent relationships, determining the critical path and key node becomes a challenge. Traditional evaluation methods often rely on expert intuition and manual analysis, resulting in inaccurate evaluation and low efficiency. SUMMARY

[0004] The main purpose of the present application is to provide a critical path and node identification system and method, which aims to solve the technical problem that the traditional critical path and key node evaluation method often relies on expert intuition and manual analysis, resulting in inaccurate evaluation and low efficiency.

[0005] To achieve the above purpose, the present application provides a critical path and node identification system, which comprises a data processing module, a graph structure module and an identification module.

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

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

[0008] The identification module is used for identifying the core critical path of the graph structure through a preset search algorithm.

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

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

[0011] The data processing module is also used to perform data cleaning on the key dataset to obtain the cleaned key dataset.

[0012] The data processing module is also used to format the cleaned key dataset to obtain a key dataset in a unified format.

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

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

[0015] The graph structure module is also used to convert the dependencies of the system components into graph edges;

[0016] The graph structure module is also used to perform relation mapping based on 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 configured to extract key features based on the topological structure between the graph nodes and the graph edges;

[0018] The graph structure module is also used to use the interaction strength of the system components of the key features as edge weights.

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

[0020] In one embodiment, the identification module is further configured 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 endpoint;

[0021] The identification module is also used to explore the graph structure based on the open list and the explored list, using the A search algorithm and heuristic functions to obtain the core critical path.

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

[0023] The identification module is also used to perform a parallel search task in the adjacent area of ​​the core critical path using a breadth-first search strategy.

[0024] The identification module is also used to collect all identified critical 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 based on the A search algorithm data, depth-first search data and breadth-first search data in the identification module to obtain a variety of feature data.

[0027] The fault prediction module is also used to train a preset gradient boosting decision tree model based on the various feature data.

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

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

[0030] The fault prediction module is also used to construct a feature vector that associates paths and nodes 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 based on the feature vector and the GBDT parameters.

[0033] In one embodiment, the fault prediction module is further configured to predict system nodes, obtain prediction results, and generate a probability score for each node to become a fault point in the chaos exercise.

[0034] The fault prediction module is also used to integrate the probability 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 based on the set of key nodes and paths.

[0036] Furthermore, to achieve the above objectives, this application also proposes a critical path and node identification method, which 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:

[0037] The data processing module preprocesses the API data from the cloud service to obtain standardized data;

[0038] The graph structure module performs relational mapping on the system topology of the cloud service based on the standardized data to obtain a graph structure.

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

[0040] The identification module explores the core critical path using 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 API data of cloud services to obtain standardized data; the graph structure module is used to perform relation mapping on the system topology of the cloud service based on 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 node of the cloud service. Because this application transforms the API data of cloud services into a graph structure, and explores the graph structure in the identification module using a preset search algorithm and a depth-first search strategy and a breadth-first search strategy, it can efficiently and accurately identify the critical path and node of the cloud service, avoiding the reliance on expert intuition and manual analysis in traditional evaluation methods, thereby improving the accuracy and efficiency of critical path and node identification. Attached Figure Description

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

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a functional block diagram provided for Embodiment 1 of the critical path and node identification system of this application;

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

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

[0047] Figure 4 This is a functional block diagram provided for Embodiment 2 of the critical path and node identification system of this application;

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

[0049] Figure 6 This is a flowchart illustrating the critical path and node identification method in an embodiment of this application.

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

[0051] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0052] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

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

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

[0055] (2) The increased time and cost of the evaluation process limits its application scope and efficiency.

[0056] (3) The evaluation method cannot accurately and effectively recommend chaos simulation 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 simulation cases accordingly, has become a pressing problem that needs to be solved.

[0058] To this end, this application proposes a critical path and node identification system. This system combines the search strategies of the A search heuristic algorithm and graph algorithms (depth-first search strategy and breadth-first search strategy), as well as 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, embodiments of this application provide a critical path and node identification system, referring to... Figure 1 , Figure 1This is a functional block diagram provided for Embodiment 1 of the critical 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 preprocess the API data of the cloud service to obtain standardized data.

[0062] It should be noted that the data processing module's main function is data collection and preprocessing. It is responsible for collecting information related to critical path and node identification, such as system service topology, system monitoring data, and log data, 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 for comprehensive monitoring of 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 used to interact with and call other systems through API interfaces.

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

[0066] It should be noted that standardized data is obtained by cleaning, integrating, and standardizing API data to eliminate 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 processes on the API data to obtain standardized data, so as to eliminate the scale differences between different data in the API data.

[0068] In one feasible implementation, the data processing module 10 of this embodiment is further configured to extract key dimension information from the API data of the cloud service to obtain a key dataset; the data processing module 10 is further configured to perform data cleaning on the key dataset to obtain a cleaned key dataset; the data processing module 10 is further configured to format the cleaned key dataset to obtain a key dataset with a unified format; the data processing module 10 is further configured to standardize the key dataset with the unified format to obtain standardized data.

[0069] It should be noted that key dimension information refers to information on different key dimensions extracted from API data during the data collection process to obtain key datasets. Examples include key dimensions such as call complexity, concurrent processing, fault tolerance, and statefulness. This embodiment does not impose limitations on these dimensions.

[0070] For example, to facilitate understanding, the data collection process will be illustrated using 10 key dimensions. The data processing module can perform in-depth analysis of the top n most active API data in the cloud service, extracting data from 10 core dimensions to comprehensively understand the dynamics and vulnerabilities of the service. Specifically:

[0071] 1. Call complexity: Measures the call structure and hierarchy of a service.

[0072] 2. Concurrency load: Evaluate service performance by the average number of concurrent requests.

[0073] 3. Dependency network: Quantifies the diversity of dependencies between services.

[0074] 4. Asynchronous Behavior: Analyze the asynchronous interaction patterns of the service.

[0075] 5. Transaction Behavior: Evaluates the complexity of the transactions being processed.

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

[0077] 7. Statefulness factor: Assess whether a service is a stateful service and the complexity of its management.

[0078] 8. Network Topology Impact: Analyzes the impact of network architecture on services.

[0079] 9. Historical performance: Reflects the stability of the service through historical response times.

[0080] 10. Resource pressure: Measures the utilization of CPU, memory, and I / O resources.

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

[0082] The data cleaning process includes: First, handling missing values ​​in the key dataset, which involves checking for missing values. Depending on the characteristics of the API data and business requirements, appropriate strategies can be used to handle these missing values, such as forward imputation, backward imputation, or using default values. Alternatively, records containing missing values ​​can be directly removed. Next, handling duplicate values. Since API call records may contain duplicates, redundant copies can be identified and deleted. However, if duplicate records reflect important information such as high-frequency API calls, they will be retained. Finally, for potential outliers, such as data anomalies caused by system errors or network latency, Z-score statistical methods (a statistical analysis method based on standard scores) can be used for detection. The decision to retain, correct, or delete outliers, as well as to repair formatting and logical errors, is made based on the analysis requirements. The final result is the cleaned key dataset.

[0083] It should be noted that formatting involves integrating data in a dataset to varying degrees to facilitate subsequent analysis and processing.

[0084] Specifically, the formatting process may include: First, converting the cleaned key dataset into a uniform format, such as using standard date and time formats and uniform units of measurement. Second, for non-numerical data (such as text, enumerated values, etc.), mapping tables or encoding tables can be created for subsequent analysis and processing. Next, data from different sources can be linked 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 type of non-relational database), or a time-series database for subsequent analysis and querying.

[0085] By integrating the cleaned key datasets to different degrees as described above, a key dataset in a unified format can be obtained, which will facilitate subsequent analysis and processing by the critical path and node identification system.

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

[0087] For example, the process of data standardization using the Z-score standardization method is illustrated as follows:

[0088] Because API data is continuous, and the goal is to transform data from different scales to the same scale for comparison and analysis, the Z-score standardization method is suitable. Z-score standardization transforms each data point in a uniformly formatted key dataset into a multiple of the standard deviation of its mean, thereby eliminating scale differences between different data points. This ultimately yields standardized data.

[0089] The formula for calculating the score is as follows:

[0090]

[0091] Where x is the original data point (i.e., the key dataset in uniform format), μ is the mean of the key dataset in uniform format, and σ is the standard deviation of the key dataset in uniform format.

[0092] After applying Z-score standardization, the dataset will be presented as a standard normal distribution with a mean of 0 and a standard deviation of 1. This will make comparisons between different API datasets easier and more intuitive.

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

[0094] 1. If the critical dataset in a uniform format is very large, calculating the mean and standard deviation may take some time. To improve efficiency, incremental calculation methods or distributed computing frameworks can be used.

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

[0096] 3. Before performing Z-score standardization, it is necessary to check whether the dataset contains extreme values ​​or outliers. These values ​​can significantly affect the mean and standard deviation, leading to inaccurate standardization results. If these values ​​exist in the data, they can be processed before standardization.

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

[0098] After the above steps are completed, the standardized data will be used for subsequent identification of critical nodes and critical paths.

[0099] In this implementation, extracting key dimension information allows for a comprehensive understanding of the service's dynamics and vulnerabilities. Data cleaning ensures data quality. Formatting the cleaned key dataset to varying degrees facilitates subsequent analysis and processing by the critical path and node identification system. Data standardization transforms data from different scales to the same scale for comparison and analysis, eliminating scale differences between different data sets.

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

[0101] It should be noted that the main function of the graph structure module is to construct graph structures and encode features. After the data processing stage mentioned above, the graph structure module can reveal the interactions between system components of cloud services by converting standardized data into graph models.

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

[0103] It should be noted that system components are various network components of cloud services, such as security components, network components, middleware, monitoring and logging components, etc., and this embodiment does not limit them.

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

[0105] In this embodiment, after the data processing module stage, the graph structure module can construct and encode the system topology of the cloud service based on standardized data to obtain the graph structure.

[0106] In one feasible implementation, the graph structure module 20 of this embodiment is further configured to map system components as graph nodes according to the system topology of the cloud service; the graph structure module 20 is further configured to convert the dependencies of the system components into graph edges; the graph structure module 20 is further configured to perform relationship mapping according to the standardized data, the graph nodes and the graph edges to obtain a graph structure.

[0107] It's important to note that graph nodes are points in a graph data structure that represent system components. Dependencies are the interactions between system components, such as service calls and data read / write operations. Graph edges are the edges in a graph data structure.

[0108] In this implementation, the system topology of the cloud service is first analyzed, mapping all system components (such as microservice components, databases, middleware, etc.) as graph nodes. Each node has specific attributes, such as name, type, service call complexity, concurrency processing capability, and historical fault records. Then, dependency mapping is performed to determine the dependencies between system components, such as service calls and data read / write operations. These relationships are transformed into graph edges. In this way, standardized data is represented as a standardized graph structure containing information about system components and their interrelationships, which can be used as the basis for identifying critical paths and nodes in subsequent chaos simulations.

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

[0110] It should be noted that, based on the graph structure, key features can be extracted, such as the degree of a node (representing the number of nodes directly connected to that node), path length (representing the complexity of the transfer process), and clustering coefficient (measuring the tightness of collaboration between services), etc., and this embodiment does not impose any limitations on these.

[0111] Specifically, the process of determining edge weights may include: combining domain knowledge (such as call frequency and 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 interaction frequency between components. High-weight edges indicate critical paths or hotspots.

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

[0113] High-weighted edges typically indicate frequent interactions and may correspond to the system's critical path or bottleneck. For example, an edge between a frequently called risk assessment service and a money transfer service has a high weight, while a low-frequency edge represents a minor interaction. If the data contains information about the frequency or intensity of interactions between components, it can be directly used as the edge weight. If no direct information is available, other metrics (such as the number of calls, data transfer volume, etc.) can be used to calculate the weight. Edge attributes may include relationship type and weight, with the weight based on the frequency or intensity of the interaction.

[0114] For ease of understanding, we will use the example of a money transfer service transforming data into a standardized graph structure to illustrate this. (Refer to...) Figure 2 , Figure 2 This is an example diagram of the transfer service provided in Embodiment 1 of this application. A transfer API request originates from an account node, passes through the transfer service node, and may require verification and risk assessment services to ultimately update the account information in the database (updating transfer records and account balances). Simultaneously, the Kafka middleware is used to store transaction information. Edges represent interactions between these services, such as the transfer service calling the verification and risk assessment services, and read / write operations with the 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 to graph nodes in a graph, and the relationships between them can be mapped to edges, resulting in 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: The 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 goes from account A to the transfer service. The transfer service depends on the verification service and the risk assessment service to complete the transfer. After a successful transfer, the transfer service updates the account balance and transfer record in the database.

[0118] The weight of an edge can be represented by the frequency of each service call. For example, the edge weight from the transfer service to the verification service and the risk assessment service is higher because these services are needed for every transfer.

[0119] This graph structure can be used to identify potential critical paths (such as the transfer process of a transfer API) and key nodes (such as transfer services and databases).

[0120] In this way, the standardized data is represented as a standardized and weighted graph structure, which contains information about system components and their interrelationships. This graph structure can be used as the basis for subsequent critical path and node identification in chaos simulations.

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

[0122] The above are only two feasible implementation methods of the graph structure module provided in this embodiment. 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 critical paths and nodes. It can combine graph algorithms with preset search algorithms to intelligently identify critical paths and nodes in the cloud service environment based on indicators such as API call relationships, resource utilization, and response time. These critical paths and key points are the focus of attention and evaluation.

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

[0126] It should be noted that the core critical path is the critical path obtained after identifying the graph structure through a preset search algorithm. These paths reveal the criticalities and potential problems in the system's operation.

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

[0128] In one feasible implementation, the identification module 30 of this embodiment is further configured 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 endpoint; the identification module 30 is further configured to perform path exploration on the graph structure based on the open list and the explored list, using the A search algorithm and heuristic functions, 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 in search algorithms to store nodes that have not yet been explored. These nodes await further processing and expansion in subsequent search steps.

[0130] The Closed List is used in search algorithms to store nodes that have already been explored. Adding these nodes to this list avoids duplicate explorations, improves search efficiency, and prevents loops. By maintaining these two lists, the search algorithm can effectively manage the progress and state of the search.

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

[0132] A 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 lead to the target, thereby improving search efficiency.

[0133] For ease of understanding, the implementation process of the A search algorithm will be used as an example for illustration. (Refer to...) Figure 3 , Figure 3 The flowchart is provided for the A search algorithm in Embodiment 1 of this application. The core of the A search algorithm lies in the estimation function f(n) = g(n) + h(n) which comprehensively calculates the actual cost g(n) and the estimated cost h(n) of each node in the OPEN table.

[0134] Here, g(n) represents the actual path cost from the starting point to node n in the graph structure. h(n) is the heuristically 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, then create the CLOSE table, add the initial node s to the OPEN table, and use the next intermediate target node as the endpoint.

[0138] OPEN list: Stores a priority queue of nodes to be explored. It is usually implemented using a min-heap to quickly find the node with the smallest f value.

[0139] CLOSE table (explored list): Records explored nodes to avoid duplicate explorations.

[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) using a suitable heuristic function.

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

[0143] 2. Main loop.

[0144] Check if the OPEN list is empty. If the OPEN list is empty, exit the process, indicating that there is no path to the target node. Otherwise, select the node n corresponding to the smallest f(n) from the OPEN list as the current node and move the current node n into the CLOSE list.

[0145] Next, determine if n is an intermediate target node. If so, save this shortest path, clear the list, add the current intermediate target node as the new starting node n to the OPEN list, and the next intermediate target node as the endpoint. Then, expand the neighborhood to the current node and add the new node n not in the CLOSE list to the OPEN list. Finally, return to execute the calculation of the estimation function f(n) = g(n) + h(n) for each node in the OPEN list. If n is not an intermediate target node, determine if 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 not in the CLOSE table is retained. Then, different operations are performed depending on 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 the smaller value; if the new node n is not in the OPEN table, the new node s is added to the OPEN list; then the process returns to check if 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 is important to note that designing a heuristic function h(n) is crucial in identifying critical paths and nodes. This function aims to estimate the most sensitive path from node n to the target state in the transaction processing flow. h(n) comprehensively considers factors such as the complexity of service calls, concurrent processing, and dependencies. These factors constitute a multi-dimensional perspective for assessing path vulnerability. The design of the heuristic function h(n) needs to meet the following principles:

[0148] 1. The principles of acceptability 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) elements in chaos simulation: call chain length, number of components, response time, resource usage, network latency, middleware processing, business weight, and fault 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 simulations, helps identify and simulate sensitive points that may lead to system failure, and then recommends targeted chaos experiment cases to enhance the system's resilience and reliability. For example, a comprehensive heuristic function example is used to illustrate this, fully considering the characteristics of the money 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] Here, `call_complexity(n)` represents the call complexity of node n, including the number of microservices called and the call hierarchy. `concurrency_load(n)` represents node n's processing capacity in a concurrent environment, measured by the average number of concurrent requests. `dependency_network(n)` represents node n's dependency network, quantifying the diversity of its dependent microservices. `async_behavior(n)` represents the proportion of asynchronous interactions node n participates in, such as message queues or event-driven interactions. `transaction_behavior(n)` represents the transaction mode handled by node n, such as TCC or SOGA features, and the complexity of transactions. `resilience_rating(n)` represents node n's fault tolerance capabilities, including error handling strategies, circuit breaking mechanisms, and rollback mechanisms. `statefulness_factor(n)` represents node n's statefulness; stateful services may introduce additional complexity and management requirements. `network_topology_impact(n)` represents the impact of the network architecture on node n, such as the number and complexity of middleware and load balancers. `historical_performance(n)` represents node n's historical response time, 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 strain. The weighting coefficients w1-w10 need to be carefully adjusted based on the actual operating conditions and business needs of the transfer system. For example, if the system has high requirements for real-time response, w9 might be larger; if the system architecture is complex, the weights of w3 and w8 might be increased. Through this quantitative comprehensive evaluation, chaos simulation can more accurately identify critical paths and nodes, enabling targeted fault simulation and system optimization.

[0154] The weights w1-w10 of each factor reveal the relative importance of these factors when identifying the critical path. They represent the "cost" from the current node to the target estimated through a weighted summation, rather than the direct physical distance. This approach reflects the design philosophy of the A search algorithm's heuristics, but it goes beyond simple spatial distance comparisons, employing an abstract cost estimation adapted to the characteristics of the transaction system, such as data flow, network latency, and resource utilization.

[0155] The weighting coefficients w1-w10 are typically subjectively set based on expert knowledge, historical data, and business needs. For example, historical data is used for statistical analysis to identify the correlation between various factors and failure occurrences, performance bottlenecks, or system instability. The stronger the correlation, the larger the corresponding weighting coefficient may be. Feedback can also be continuously collected during chaos simulations, and the weighting coefficients can be iteratively optimized based on actual results to make them closer to actual needs.

[0156] It's important to note that even with a more objective approach, a degree of subjective judgment is unavoidable, as business scenarios and priorities may change over time. Therefore, setting weighting coefficients is typically a dynamic and iterative process.

[0157] In this embodiment, the "distance" or "cost" from the current node to the target node in the graph structure is estimated using the A search algorithm. Furthermore, by defining a suitable heuristic function, the search can be guided in a direction more likely to lead to the target, thereby improving search efficiency.

[0158] The identification module 30 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.

[0159] It's important to note that the Depth-First Search (DFS) strategy works as follows: starting from the initial node, it explores as deeply as possible along a path until it can no longer proceed. At this point, it backtracks to the previous node and then tries another branch path to continue exploring. This is analogous to exploring a tree structure by first reaching the end of a branch and then backtracking.

[0160] The Breadth-First Search (BFS) strategy works as follows: starting from the starting node, it first visits all its direct neighbors in sequence, then visits the neighbors of those neighbors in sequence, and so on, expanding outwards layer by layer. It places greater emphasis on comprehensive exploration at the same level.

[0161] In this embodiment, the core critical path is explored using a depth-first search (DFS) and a breadth-first search (BFS) strategy to obtain the critical path and nodes of the cloud service. This multi-strategy fusion method combines the accuracy of path selection, the depth insight of DFS, and the extensive scanning capability of BFS, thereby improving the efficiency and accuracy of problem identification.

[0162] In one feasible implementation, the identification module 30 of this embodiment is further configured to perform a depth search task on the nodes on the core critical path, starting from the origin, using a depth-first search strategy; the identification module 30 is further configured to perform a parallel search task in the adjacent region of the core critical path using a breadth-first search strategy; the identification module 30 is further configured to collect all identified critical paths and nodes after the depth search task and the parallel search task are completed.

[0163] Specifically, after identifying the core critical path using the A search algorithm described above, a Depth-First Search (DFS) exploration can be performed first: For the critical path determined by the A search, starting from the starting point, DFS is used to explore the nodes along the path in depth, layer by layer. At each step, an unvisited neighbor is selected, marked as visited, and the exploration continues downwards. If n is the target node, the A search algorithm is stopped and the critical path is recorded. Otherwise, the unvisited neighbors of n are added to the OPEN list, and their f-values ​​are calculated.

[0164] Then, perform a BFS parallel search: In the adjacent region of the critical path, start a BFS parallel task. For each critical node, create a parallel task to traverse all its adjacent nodes, ensuring full coverage.

[0165] When a new critical node or problem path is discovered, it is recorded and added to the processing queue. To improve processing speed, multithreading or distributed computing can be used to process multiple BFS tasks simultaneously, thereby improving search efficiency.

[0166] Depth-first search (DFS) reveals critical nodes in the deep structure, while breadth-first search (BFS) quickly detects potential problems related to the critical path. After all DFS and BFS tasks are completed, all identified critical 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 simulation target. This multi-strategy fusion approach combines the accuracy of path selection, the depth of insight of DFS, and the broad scanning capability of BFS, thereby improving the efficiency and accuracy of problem identification in chaos engineering and providing precise localization for system fault injection and stability testing.

[0167] In this implementation, the A-search algorithm described above, combined with a comprehensive heuristic function h(n), which considers system complexity, service interaction, and resource utilization, identifies the core critical paths in the system. These paths reveal the system's operational criticalities and potential problems. Subsequently, Depth-First Search (DFS) can be used to further explore the paths determined by the A-search algorithm. Starting from the path's origin, each unexplored neighboring node is visited layer by layer until the target node is found or the entire path is traversed. Simultaneously, to ensure comprehensive coverage, Breadth-First Search (BFS) is executed in parallel, especially in the adjacency regions of critical paths. Each critical node initiates a parallel task to traverse all its neighboring nodes, ensuring 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 observability platform. Then, it performs data cleaning, integration, and standardization processes on the API data to obtain standardized data, eliminating scale differences between different data points within the API data. Following the data processing module, the graph structure module can construct and feature-encode the system topology of the cloud service based on the standardized data to obtain the graph structure. Next, the identification module can intelligently identify the core critical paths of the graph structure using a preset search algorithm based on indicators such as API call relationships, resource utilization, and response time. These paths reveal the system's operational criticalities and potential problems. Finally, the core critical paths are explored using a depth-first search strategy and a breadth-first search strategy to obtain the critical paths and nodes of the cloud service. This multi-strategy fusion method balances 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 this embodiment transforms the API data of cloud services into a graph structure, the graph structure is explored in the identification module using a preset search algorithm and a search strategy of depth-first search and breadth-first search. This can efficiently and accurately identify the critical paths and nodes of cloud services, avoiding the situation where traditional evaluation methods rely on expert intuition and manual analysis, thereby improving the accuracy and efficiency of critical path and node identification.

[0169] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a functional block diagram provided for Embodiment 2 of the critical path and node identification system of this application.

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

[0171] It should be noted that the reference Figure 5 , Figure 5 This is a flowchart illustrating the overall implementation of this application. After the critical path and node identification system is initialized, all identified critical paths and nodes in the graph structure can be obtained through the aforementioned data collection and preprocessing, A-search algorithm, and heuristic functions. Following this, this embodiment can also perform operations such as GBDT model construction and verification, experimental analysis, and model feedback and updates based on the graph structure data, as detailed below:

[0172] The fault prediction module 40 is used to extract features based on the A search algorithm data, depth-first search data and breadth-first search data in the identification 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 critical service faults using GBDT (Gradient Boosting Decision Tree). Based on the identification of critical paths and nodes, GBDT models can be further introduced for training to enhance the ability to predict the probability of chaotic bursts. These models utilize historical chaotic simulation data, resource utilization, response time, and other multi-dimensional indicators to predict the critical paths and nodes of a transaction.

[0174] It should be noted that the A search algorithm data consists of 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] Depth-first search data and breadth-first search data (i.e., graph algorithm data) are the data collected by running DFS and BFS to gather node degrees, path information, and other data.

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

[0177] For example, the feature extraction process may include: First, calculating the average heuristic cost and actual cost of each node, as well as its relative distance to the target state, to obtain path cost features. Then, counting the number of incoming and outgoing edges for each node, and the diversity of dependencies (such as the type of service depended upon), to obtain dependency features. Next, calculating the in-degree, out-degree, and total degree of each node, to obtain node degree features. Then, counting the frequency of each node's appearance in DFS and BFS paths, to obtain path frequency features. Next, calculating the shortest path length and number of direct connections between each node and known key nodes, to obtain connectivity features. Then, extracting the number of node failures and failure rates from logs or monitoring data, to obtain historical failure features. Finally, collecting node response time, throughput, and error rate, which may require time-series data processing, to obtain performance features. Ultimately, the above-mentioned various feature data are obtained.

[0178] In this embodiment, the fault prediction module can extract features by collecting data such as the degree and path information of nodes based on the heuristic cost (h(n)) and actual path of each node to the target state calculated during the execution of the search algorithm in the above-mentioned record A in the identification module, as well as the above-mentioned running DFS and BFS, and obtaining a variety of feature data.

[0179] The fault prediction module 40 is also used to train a preset gradient boosting decision tree model based on the various feature data.

[0180] It should be noted that the Gradient Boosting Decision Tree (GBDT) model is a machine learning algorithm. In GBDT, new decision trees are continuously built to fit the data, and each new tree is built to make up for the shortcomings of the previous trees, thereby improving the overall predictive performance in a step-by-step manner.

[0181] Specifically, during the training process of the preset gradient boosting decision tree model, feature vectors can be constructed for training, or the dataset can be divided into training and validation sets for training to improve the performance of the model. This embodiment does not impose any restrictions on this.

[0182] In this embodiment, the fault prediction module can perform various training exercises on the preset gradient boosting decision tree model based on the various feature data to improve the model's performance.

[0183] In one feasible implementation, the fault prediction module 40 of this embodiment is further configured to perform feature processing on the multiple feature data to obtain processed feature data; the fault prediction module 40 is further configured to construct feature vectors for path and node association based on the processed feature data; the fault prediction module 40 is further configured to initialize the GBDT parameters of the preset gradient boosting decision tree model; the fault prediction module 40 is further configured to train the preset gradient boosting decision tree model based on the feature vectors and the GBDT parameters.

[0184] Specifically, the feature processing procedure may include: First, using Min-Max scaling or Z-Score normalization, the numerical features of various feature data can be normalized to ensure that all numerical features are on the same scale. Then, categorical features (such as service type and error type) can be independently encoded or labeled to obtain categorical feature codes. Finally, the feature data is obtained.

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

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

[0187] For example, suppose 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, in-degree 1, out-degree 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 performing numerical feature normalization and categorical feature encoding (assuming no categorical features), a feature matrix is ​​constructed (using Min-Max scaling, assuming a 0-1 range). This matrix serves as the input to the GBDT model, with each row representing a node and each column representing a feature value. The model will learn and predict the criticality of nodes based on these features.

[0194] Next, during model training, appropriate GBDT parameters, such as the number of trees, tree depth, learning rate, and regularization parameters, are selected for model configuration. Then, the data is split into training, validation, and test sets, typically in proportions of 70%, 15%, and 15%, respectively. The GBDT model is then trained using the training set, and model selection and tuning are performed using the validation set. Finally, the model's performance is evaluated on the test set, including metrics such as accuracy, recall, and F1 score.

[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 model's performance.

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

[0197] In this embodiment, the trained model can ultimately predict new data in the system by predicting key nodes, thereby identifying 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 the chaos simulation.

[0200] Since A search algorithms 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. Instead, it is compared with the prediction results of the GBDT model.

[0201] Next, results integration and difference filtering are performed: First, the high-scoring nodes predicted by the model are integrated with the search results of the A-search algorithm and the graph algorithm to form a preliminary set of key nodes and paths. Then, the results of different methods are compared to identify nodes that appear only in a single method; these may be potential key nodes.

[0202] For example, in a money transfer system, we can represent key components and their interactions as a graph structure, with the following graph-structured data:

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

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

[0205] The GBDT model focuses on service performance and risk, while the A search algorithm emphasizes the call paths 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. Search A: Key components: Database (DB), Kafka middleware (K). Identification path: T→DB→T→K.

[0208] Based on the above process, the optimized integration results are as follows: Core Service: T is identified as the core of the system because it appears in all paths. Critical Path: 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, and they 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, verify the responsiveness of services and risk assessment services, and assess the reliability of the database and Kafka middleware. By injecting faults or simulating latency, the system performance of these components under abnormal conditions can be evaluated.

[0210] Then, chaos simulation is performed: a series of simulated faults are designed for predicted critical nodes and paths, simulating faults or anomalies such as sudden high load, latency, or fault injection. The system responses in the chaos experiments are recorded and analyzed, such as service degradation, recovery time, and cascading failures.

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

[0212] Finally, optimize the results: Based on the experimental results, adjust the key nodes and path sets, and if necessary, add nodes that were not originally in the prediction set. For nodes where the model prediction is inaccurate, consider adjusting the model parameters or performing feature reengineering to improve prediction accuracy.

[0213] This process combines model prediction, graph algorithms, and chaos experiments to ensure that the identified critical paths and nodes are both data-driven and verified by actual system responses, thus improving the accuracy and practicality of the identification.

[0214] This implementation integrates a trained GBDT model with A-search and graph algorithms, leveraging their complementary strengths to identify critical paths and nodes. GBDT learns nonlinear patterns from historical data, while A-search and graph algorithms reveal system structure and dynamic paths. This comprehensive approach improves identification accuracy and avoids the limitations of a single model. By comparing and integrating the results, combined with fault simulations from chaotic exercises, the identification results are validated and optimized, ensuring their effectiveness and decision-making value in real-world applications. Multi-faceted analysis provides a data foundation for fault prevention, performance improvement, and chaos engineering. In short, the integration steps of model prediction and chaos experiments include: using GBDT to predict fault points, and then comparing them with the chaotic scenario analysis results from A-search and graph algorithms to enhance the reliability of identification.

[0215] In the technical solution provided in this embodiment, key features are extracted by integrating the heuristic evaluation h(n) generated in the previous stage, actual path data, and graph structure information. These features include path attributes, dependencies, historical failures, and performance indicators. These multi-faceted features are transformed into feature vectors, forming a feature matrix, which serves as the input to the GBDT model. Model training aims to learn the relationship between features and key nodes of the system, used to accurately predict elements that may affect stability. In the model application stage, the GBDT model predicts key nodes, while chaos experiments serve as a verification tool. By simulating failures and optimizing the model based on experimental feedback, it is ensured that the model predictions are consistent with the actual system behavior, thereby improving the practical effectiveness of chaos engineering.

[0216] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. On this basis, as Figure 4 and Figure 5 As shown, the critical path and node identification system in this example also includes a visualization interaction module 50 for visualization presentation.

[0217] Specifically, the visualization module outputs results in a concise system topology diagram, intuitively revealing the overall system architecture. Highlighted key nodes and paths act as focal points in the network, using color, shape, or legend distinctions to highlight potential fault hotspots, allowing users to quickly identify critical system components and dependencies. This visualization simplifies the understanding of complex networks and helps decision-makers quickly pinpoint 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 relationship, performance indicators, etc.) with the features of cases in the case library, and calculate the similarity, such as using cosine similarity or Jaccard similarity.

[0220] 2. Failure Mode Analysis: Retrieve events or patterns from past failures that are similar to the currently identified critical paths and nodes, considering failure type, scope of impact, 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 study, such as service interruption time, cascading effects, repair strategies, and recovery speed.

[0221] 3. Impact Assessment: Based on the impact of critical node failures in the case on the overall system performance, compare it with the currently identified critical nodes.

[0222] 3. Solution Library: Search for strategies that have successfully solved similar problems in historical cases, including architectural adjustments, redundant design, fault tolerance mechanisms, or contingency 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. Rating and Sorting: Assign a comprehensive score to each matched case, and display the results to the user in descending order of scores based on the weights of the factors mentioned above.

[0225] Through these matching principles and factors, the visual interaction module can provide users with targeted reference cases to help them understand and address the risks that may be brought about by the identified critical paths and nodes, as well as to 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 the A* heuristic algorithm and graph search strategy, it achieves deep insights into critical paths and nodes in complex systems. This method not only enhances the accuracy of fault prediction and reduces false positives and false negatives, but also overcomes the limitations of single methods through multi-model fusion analysis, ensuring a more comprehensive understanding of the system. Simulated faults in chaos drills validate the identification results, further improving the adaptability of predictions in real-world environments and providing strong decision support for preventing system failures. Furthermore, this innovative method optimizes resource allocation and reduces troubleshooting time, thereby improving the overall system stability and performance. Therefore, this invention not only reduces operational 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 user-friendly interface is provided through a visualization interaction module, displaying the system structure, critical path, node topology diagram, and recommended chaos simulation cases. Combining historical chaos simulation cases, expert experience, and predictions of the probability of chaos bursts, targeted case recommendations are provided for chaos simulations. These recommended cases not only consider the system's critical path and nodes but also incorporate prediction results, making chaos simulations more accurate and effective.

[0228] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the critical path and node identification system of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0229] This application also provides a method for identifying critical paths and nodes; please refer to [reference needed]. Figure 6 , Figure 6This is a flowchart illustrating the critical path and node identification method according to an embodiment of this application; the critical path and node identification method 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:

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

[0231] Step S20: The graph structure module performs relational mapping on the system topology of the cloud service based on 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 implementations of the critical path and node identification method of this application can be found in the above-described system embodiments, and will not be repeated here.

[0235] The critical path and node identification method provided in this application, applied to the critical path and node identification system in the above embodiments, can solve the technical problem that traditional critical path and critical node evaluation methods often rely on expert intuition and manual analysis, leading to inaccurate evaluation and low efficiency. Compared with the prior art, the beneficial effects of the critical path and node identification method provided in this application are the same as those of the critical path and node identification system provided in the above embodiments, and other technical features in the critical path and node identification method are the same as those disclosed in the system of the above embodiments, and will not be repeated here.

[0236] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A critical path and node identification system, characterized in that, The system includes: a data processing module, a graph structure module, and a recognition 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 relational mapping on the system topology of the cloud service based on the standardized data to obtain a graph structure. The identification module is used to identify the core critical paths 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; The identification module is further configured 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 endpoint; based on the open list and the explored list, the graph structure is explored using the A search algorithm and heuristic functions to obtain the core critical path; The core of the A search algorithm lies in comprehensively calculating the estimation function of each node in the open list: f(n) = g(n) + h(n); where g(n) represents the actual path cost from the starting point to node n in the graph structure; h(n) is a heuristic function that represents the heuristic estimated cost from node n to the target node.

2. The system as described in 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 dataset; The data processing module is also used to perform data cleaning on the key dataset to obtain the cleaned key dataset. The data processing module is also used to format the cleaned key dataset to obtain a key dataset in a unified format. The data processing module is also used to standardize the key dataset in the unified format to obtain standardized data.

3. The system as described in claim 1, characterized in that, The graph structure module is also used to map system components as graph nodes according to the system topology of the cloud service; The graph structure module is also used to convert the dependencies of the system components into graph edges; The graph structure module is also used to perform relation mapping based on the standardized data, the graph nodes, and the graph edges to obtain a graph structure.

4. The system as described in claim 3, characterized in that, The graph structure module is also used to extract key features based on the topological structure between the graph nodes and the graph edges; The graph structure module is also used to use the interaction strength of the system components of the key features as edge weights. The graph structure module is further configured to perform relationship mapping between the graph nodes and the graph edges based on the edge weights and the standardized data to obtain the graph structure.

5. The system as described in claim 1, characterized in that, The identification module is also used to perform a depth search task on the nodes on the core critical path, starting from the starting point, using a depth-first search strategy; The identification module is also used to perform a parallel search task in the adjacent area of ​​the core critical path using a breadth-first search strategy. The identification module is also used to collect all identified critical paths and nodes after the deep search task and the parallel search task are completed.

6. The system as described in any one of claims 1 to 5, 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 based on the A search algorithm data, depth-first search data and breadth-first search data in the identification module to obtain a variety of feature data. The fault prediction module is also used to train a preset gradient boosting decision tree model based on the various feature data. The fault prediction module is also used to predict system data using the trained model to identify key services or components.

7. The system as described in claim 6, characterized in that, The fault prediction module is also used to perform feature processing on the various feature data to obtain processed feature data; The fault prediction module is also used to construct a feature vector that associates paths and nodes 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 based on the feature vector and the GBDT parameters.

8. The system as described in claim 7, 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 also used to integrate the probability 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 based on the set of key nodes and paths.

9. A method for identifying critical paths and nodes, characterized in that, The critical path and node identification method is applied to a critical path and node identification system, which includes a data processing module, a graph structure module, and an identification module; the method includes: The data processing module preprocesses the API data from the cloud service to obtain standardized data; The graph structure module performs relational mapping on the system topology of the cloud service based on the standardized data to obtain a graph structure. The identification module identifies the core critical paths of the graph structure using a preset search algorithm; The identification module explores the core critical path using a depth-first search strategy and a breadth-first search strategy to obtain the critical path and nodes of the cloud service; The identification module creates an open list and an explored list based on the graph structure. The starting node of the graph structure is added to the open list, and the next intermediate target node is taken as the endpoint. Based on the open list and the explored list, the graph structure is explored using the A search algorithm and heuristic functions to obtain the core critical path. The core of the A search algorithm lies in comprehensively calculating the estimation function of each node in the open list: f(n) = g(n) + h(n); where g(n) represents the actual path cost from the starting point to node n in the graph structure; h(n) is a heuristic function that represents the heuristic estimated cost from node n to the target node.

Images