Execution method of exception recovery strategy in continuous deployment environment

Abstract

The invention relates to a method for executing an exception recovery strategy in a continuous deployment environment, which comprises the following steps of: dividing construction, test, deployment and release of continuous deployment into atomic operation units with idempotence and traceability, setting a logic breakpoint after each unit is executed, and marking a state transfer node; during deployment, monitoring abnormity, splitting an abnormal chain, identifying a trigger factor, a relay effect and final state performance, and judging whether a recovery condition is met or not by combining a breakpoint state, an influence range, stage idempotence and module controllability; if the abnormal module does not influence the trunk link, freezing the context and resources of the trunk link, pausing the subsequent operation of the trunk link, and continuing to advance trunk deployment; logic confirmation is carried out before recovery, whether the fault-tolerant range is exceeded or not is evaluated, pollution risks exist or alternative processing exists, and whether rollback is carried out or not is comprehensively judged; and after the deployment is finished, generating a post-restoration strategy based on the abnormal information and the frozen state, and injecting the post-restoration strategy into a pre-check process of subsequent operation and maintenance or next deployment to realize abnormal isolation, continuous delivery and closed-loop treatment.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and operations and maintenance technology, specifically to a method for executing anomaly recovery strategies in a continuous deployment environment. Background Technology

[0002] Current technologies, such as the deployment method and apparatus of software disclosed in CN110413287A, have several shortcomings and technical limitations in their execution methods for anomaly recovery strategies in continuous deployment environments. These limitations mainly lie in the granularity of deployment anomaly handling, response mechanisms, logical judgment capabilities, and the key aspects of strategy adaptability. From the perspective of anomaly detection and localization capabilities, this solution primarily relies on canary deployment to reduce the scope of error impact. Its core strategy is to advance the deployment target in stages according to a subset of devices, thereby mitigating the risk of large-scale error propagation. However, it does not construct fine-grained atomic operation units, nor does it explicitly record breakpoint information and state snapshots for each deployment step. This makes it difficult to quickly trace back to the specific deployment logic location and restore the context environment after a deployment anomaly occurs. This deployment system, lacking atomicity and breakpoint snapshot mechanisms, is not conducive to accurate localization and recovery operations, limiting the efficient execution of deployment recovery.

[0003] The solution lacks a mechanism for identifying and analyzing the chain of anomalies when dealing with deployment anomalies. Its method does not involve how to break down an anomaly into three categories: trigger source, relay node, and final state impact. Nor does it provide a hierarchical strategy for constructing anomaly propagation paths based on temporal causality. As a result, when faced with complex anomalies, it can only rely on the deployment phase or parameter configuration to roughly avoid risks, and cannot accurately freeze and quickly repair by constructing anomaly propagation trees and locating key factors.

[0004] Regarding the anomaly detection logic, this solution does not introduce Boolean logic or weighted rules to determine whether a module has entered a frozen state. It only makes static judgments based on whether it is in a gray-scale stage and whether the target parameter value meets the requirements. It lacks a joint judgment mechanism for dynamic deployment status and the scope of anomaly impact, and it has not established a method for parsing the dependency structure between modules. It cannot dynamically respond to anomalies on critical dependency paths, nor can it distinguish the risk levels of parallel modules and mainline deployment modules. This leads to the system being overly conservative or erroneously optimistic when handling non-fatal but propagable anomalies, affecting the overall deployment efficiency and security.

[0005] In terms of recovery strategy formulation capabilities, the solution does not demonstrate the ability to estimate the confidence level of anomaly recoverability based on historical deployment data, nor does it construct any environmental variable similarity measurement or contextual contamination risk assessment mechanism. In actual deployment environments, if a certain type of anomaly has been successfully recovered multiple times in the past or if the combination of environmental variables has strong fault tolerance, the solution cannot use this information to automatically decide whether to roll back or continue, resulting in decisions that rely too much on manual judgment or fixed strategy templates and lack adaptive recovery intelligence.

[0006] The solution also fails to demonstrate the reloadability of policy triggers in terms of deployment strategy configuration. Its deployment control logic is hardcoded into the scheduling process. Once abnormal trigger conditions need to be dynamically changed or the freezing threshold needs to be adjusted according to different business lines, it will face the problem of process reconstruction or manual intervention. Deployment systems that lack configurable policy trigger mechanisms cannot efficiently unify policies and quickly respond to changes in large-scale multi-team collaborative scenarios.

[0007] During the candidate deployment unit selection process, this comparison scheme does not introduce any similarity calculation model, nor does it combine multi-factor scoring mechanisms such as edit distance, environmental variable matching degree, or semantic fit to automatically select the most relevant deployment operation unit. Especially in scenarios with fuzzy expression of abnormal logs or cross-module abnormal infection, the lack of an effective deployment unit mapping algorithm will significantly reduce the accuracy of abnormal location, thereby affecting the effectiveness of the freeze strategy and recovery path. Summary of the Invention

[0008] The purpose of this invention is to provide a method for implementing anomaly recovery strategies in a continuous deployment environment, thereby addressing some of the drawbacks and shortcomings pointed out in the background art.

[0009] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows: an execution method for an anomaly recovery strategy in a continuous deployment environment, comprising: dividing the build, test, deployment and release operations in the continuous deployment process into atomic operation units with idempotency and traceability, and setting logical breakpoints after the execution of each atomic unit to mark the deployment state transition node; During deployment, monitor abnormal events, break down the abnormal chain, identify triggering factors, relay effects and final state performance, and determine whether recovery conditions are met based on breakpoint status, scope of abnormal impact, stage idempotency and module controllability. When an abnormal module does not affect the main deployment chain, put it in a frozen state, retain its context and resource binding, suspend subsequent deployment, and continue to execute the main deployment path to support subsequent repair. Before the recovery strategy is executed, logical conditions are confirmed based on the current deployment status to assess whether it exceeds the tolerable range, whether there is a risk of contamination or alternative treatment conditions, and to make a comprehensive judgment on whether to trigger a rollback. After the deployment process is completed, a post-recovery strategy plan is generated based on the abnormal information and the status of the frozen module, and injected into the pre-deployment check process of subsequent operation and maintenance tasks or the next deployment.

[0010] Furthermore, the atomic operation unit is registered with a unique identifier before execution, making the state of each deployment process traceable and distinguishable from historical execution instances; the logical breakpoint records deployment parameters, runtime environment variables, and resource call status after being triggered, to form a time-series snapshot of the deployment state; the monitoring of abnormal events includes three signal sources: log analysis, process status detection, and probe response detection, to determine the stage and scope of the abnormality.

[0011] Furthermore, the breakdown of the anomaly chain is based on the temporal order of the causal relationship of events, and the anomaly triggering source and propagation path are described hierarchically; and when determining whether recovery conditions are met, the confidence level of anomaly recoverability is estimated based on historical deployment data.

[0012] Furthermore, the hierarchical description of the exception chain includes taking the exception triggering source as the root node and constructing an exception propagation tree according to the time causal order to support recovery path backtracking; the determination of the event causal relationship is based on timestamps, module call order and log dependency chain, and multiple exception events are chained together through a hash association mechanism.

[0013] Furthermore, after being identified, the abnormal triggering source is mapped to the corresponding deployment operation unit to locate the deployment breakpoint and assist in triggering the freeze strategy; the confidence estimation of the abnormal recoverability is based on the success rate of recovery of similar abnormalities in the deployment history, and is weighted in combination with the similarity of the deployment environment.

[0014] Furthermore, the process of mapping the abnormal triggering source to the deployment operation unit includes executing a matching function based on rule priority. The function calculates the weights according to the abnormal log keywords, error codes, and call stack depth to obtain the corresponding deployment operation unit. When locating the deployment breakpoint, the adjacent operation units are searched backward from the triggering source node until the time point when the abnormal signal first appears is used as the candidate node for the freeze point. Based on the keyword density, error code type, and call stack depth in the exception log, a mapping function is executed to calculate exception scores for multiple candidate deployment operation units. The mapping function is:

[0015] in, To deploy the operating unit, These are the keyword density function, error code mapping function, and call stack depth function, respectively. These are the feature weight coefficients. The system calculates a semantic fit function between the deployment unit and the exception context; The maximum value is selected from the target deployment unit, and the first abnormal signal occurrence point in the forward deployment path is used as the candidate breakpoint for the freeze strategy.

[0016] Furthermore, to ensure that the score reflects the actual fit between the deployed operational unit and the current anomaly context, a time-varying similarity kernel function is introduced. It comprehensively considers edit distance, environmental variable matching rate, and contextual factors, and is used as the harmonic factor for the entire integral function. Since the data scales of each original feature may differ, they are respectively processed through a nonlinear function. right Normalization or stretching transformations can be performed to unify the expression of intensity.

[0017] Finally, by multiplying the weighted feature representation terms by the kernel function and integrating over the time interval, the comprehensive anomaly matching score of the deployment unit throughout the entire anomaly cycle is obtained. The system then sorts all candidate units based on their scores and selects the unit with the highest score. It serves as the target deployment operation unit and is used for subsequent freeze strategies or recovery path location.

[0018] Furthermore, the freezing strategy is triggered based on a set of Boolean logic judgments, including two calculation results: whether there are key dependent links in the anomaly propagation path and whether the deployment unit is a parallel execution module. When there are multiple matching deployment operation units, the system selects the target deployment unit according to the principle of maximum similarity. The similarity is calculated by weighting the edit distance score between the operation unit identifier name and the keywords in the anomaly log, as well as the similarity ratio of key-value pairs in the deployment environment variables. The weighting calculation adopts a linear weighting or confidence scoring mechanism.

[0019] Furthermore, in determining whether the deployment unit is a parallel execution module, the system marks the concurrency flag of each unit based on the execution plan graph in the scheduling metadata; the Boolean logic judgment rule supports dynamic adjustment according to priority, and when the key dependency judgment result is true, even if the parallel flag is true, the freeze strategy is triggered.

[0020] Furthermore, the Boolean logic judgment is encapsulated as a policy trigger component, which supports configuration and reloading through deployment policy files; when multiple matching deployment operation units exist, the system first calculates the edit distance score and directly eliminates candidate units with scores lower than a preset threshold; the edit distance score is calculated using the Levenshtein algorithm and combined with the keyword length standardization processing result.

[0021] Furthermore, the deployment environment variable matching degree is obtained by calculating the Jaccard similarity coefficient between the set of environment variable key-value pairs of the candidate deployment unit and the set of environment variables in the abnormal context. The similarity result is used as a calculation factor for environment similarity in the screening of target deployment units.

[0022] The beneficial effects of this invention are as follows: By refining the build, test, deployment, and release processes into atomic operation units with idempotency and traceability, and setting logical breakpoints at key steps, fine-grained control and traceable recording of the deployment state are achieved. Combined with hierarchical decomposition and propagation path analysis of the exception chain, the system can accurately identify the trigger source, relay process, and final state of exceptions. Furthermore, by integrating Boolean logic judgment mechanisms to comprehensively evaluate the importance and freezeability of modules, module-level freezing and jumping can be achieved without affecting the main deployment path, greatly improving the continuity and robustness of deployment tasks when facing non-fatal exceptions.

[0023] The introduced matching function, which integrates edit distance, error code weight, call stack depth, and environment variable similarity, can accurately locate the module most relevant to the anomaly among multiple deployment operation unit candidates. Through a confidence scoring mechanism and weighted analysis of historical deployment recovery data, the system can dynamically assess anomaly recoverability and automatically trigger recovery or generate a post-recovery strategy to inject into subsequent processes when conditions are appropriate, avoiding erroneous rollbacks and deployment interruptions. The overall solution possesses intelligent judgment capabilities, policy adaptability, and uninterrupted deployment flow, significantly improving deployment stability, anomaly management accuracy, and business continuity in large-scale microservice environments. Attached Figure Description

[0024] Figure 1 This is a flowchart of the anomaly recovery strategy in a continuous deployment environment according to the present invention.

[0025] Figure 2 This is a flowchart illustrating the intelligent deployment anomaly detection and recovery process of this invention.

[0026] Figure 3 This is a diagram showing the relationship between the anomaly detection and response functions deployed in this invention.

[0027] Figure 4 This is a flowchart of the microservice deployment exception response and freezing process in Embodiment 1 of the present invention.

[0028] Figure 5 The flowchart for deploying anomaly detection and multi-branch freezing decision-making in Embodiment 2 of the present invention is shown. Detailed Implementation

[0029] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0030] Combined with appendix Figure 1 This invention provides a method for executing anomaly recovery strategies in a continuous deployment environment. The entire continuous deployment process is divided into multiple atomic operation units with idempotency and backtrackability. The deployment process typically includes a build phase, a testing phase, a deployment phase, and a release phase. Each phase contains several operational tasks, such as code compilation, dependency installation, container generation, configuration loading, unit testing, service registration, health checks, network policy distribution, and load balancing. All these operations can be abstracted into independent, finite, repeatable, and side-effect-free minimum functional units. The execution of each atomic operation unit is structurally encapsulated, allowing it to be invoked, retried, or rolled back independently during deployment. To ensure high controllability of the deployment path in case of anomalies, logical breakpoints are set after each atomic operation unit completes execution to record the transition of the deployment state. These logical breakpoints record the current unit execution result, input / output parameters, runtime environment snapshot, dependency state, resource call trajectory, and their corresponding timestamps, and are stored as state boundary nodes in the deployment state machine within the deployment control platform.

[0031] The system continuously monitors for abnormal events from multiple signal sources at each stage of the deployment process, including abnormal log output, abnormal probe response, abnormal process status, resource allocation failure, and configuration conflicts. When an abnormal event is detected, the system activates the exception chain handling module. This module segments and analyzes the abnormal events, breaking down the cascading response relationship caused by the exception in the deployment chain into three elements: triggering factor, relay effect, and final state manifestation. The triggering factor identifies the earliest deployment unit where the exception occurred and its initial abnormal signal source; the relay effect records the propagation path and scope of the exception between modules; and the final state manifestation captures the final exposed deployment failure symptoms or service unavailability. Based on the logical breakpoint states set in the deployment process, the system locates and categorizes the above exception chain elements. Combining the idempotency attribute of the current deployment stage and the boundary characteristics of the exception's impact scope, it further determines whether the exception is recoverable. This determination also includes assessing whether the current abnormal module is independent and its dependence on other modules. If the system confirms that the abnormal module does not disrupt the main deployment link in this deployment and its abnormality will not cause cascading failures, the system marks the module as frozen. In the frozen state, the system suspends the scheduling of subsequent deployment tasks for the module, while retaining the module's context information before the abnormality occurred, including running parameters, dependency configurations, allocated resources, and environment variable snapshot data, so that subsequent repairs or manual intervention can be restored based on the on-site state.

[0032] When a frozen module or a recorded anomaly occurs during the deployment process, the system will not immediately perform a rollback or redeployment. Instead, it will perform multi-condition logical checks based on the overall execution status of the current deployment task. This check process covers three key dimensions: First, it assesses whether the problem caused by the anomaly exceeds the system's current tolerable service interruption range, including the deployment window time, the responsiveness of already online services, and the degree of business impact. Second, it determines whether the anomaly poses risks of configuration pollution, data corruption, or dependency misalignment. The system determines pollution by comparing the consistency flags of environment variables, configuration files, and runtime parameters before and after deployment. Third, it assesses whether there are alternative handling conditions, i.e., whether the current anomaly can be compensated for through retrying, delayed deployment, hot updates, or canary switching without immediate rollback. After logically combining the above three judgments, the system makes a comprehensive decision. If the rollback trigger strategy rules are met, the preset rollback mechanism is executed; otherwise, the system enters the final stage of the deployment process. After the deployment process is completed, the system will collect all the abnormal information that occurred during this deployment and the execution status of the frozen modules. Based on these statuses, a structured post-recovery strategy plan will be generated. This plan includes the target module identifier, recovery trigger conditions, recommended handling methods, dependency verification instructions, and security execution window content.

[0033] Combined with appendix Figure 2The unique identifier contains the deployment task number to which the unit belongs, including the execution timestamp, module name, environment tag, and relevant context summary. This allows for clear differentiation of multiple execution instances of the same logical operation unit in different deployment cycles when tracking, comparing, or replaying deployment records. Through this unique identifier, the system can filter and compare historical records after deployment and quickly restore to a specific deployment node, effectively improving the granularity of deployment state management. After each atomic unit is executed, the system triggers a logical breakpoint. This breakpoint serves as a structured node in the deployment state diagram, used to record the deployment parameters, runtime environment variable snapshots, and resource call status involved in the execution of that step. Deployment parameters include the execution command, input / output paths, version information, and dependency configurations. Runtime environment variables include system variables, container environment, network configuration, and access tokens. Resource call status includes local computing resource consumption and external service call status. All information is recorded as a time-series snapshot to serve as a basis for state restoration and anomaly reconstruction in case of deployment failure or interruption. To achieve early identification and phased awareness of abnormal events, the system integrates a multi-source monitoring mechanism throughout the entire deployment lifecycle, including an abnormal log analysis module, a deployment process status detection module, and a service probe response detection module. The log analysis module extracts abnormal signals through keyword matching and behavior recognition algorithms. The status detection module determines whether there are unexpected terminations, lags, or resource blockages by tracking the lifecycle events of each deployment subprocess. The probe response module detects changes in availability, response latency, and error rate by periodically accessing the service endpoint.

[0034] The system identifies the module where the earliest abnormal signal occurs, marking it as the anomaly trigger source. Then, by analyzing the operational units, log order, network calls, and service dependencies involved in the anomaly propagation path, it gradually reconstructs the anomaly's transmission process within the deployment path. This process forms a causal path from source to end, and constructs a structured hierarchical anomaly chain diagram according to its impact direction and propagation depth. Each node represents an affected deployment unit, and each edge represents the triggering logic and propagation relationship of the anomaly propagation. Based on this, the system forms a complete anomaly impact map and marks key propagation breakpoints. After completing the anomaly chain construction, the system enters the recovery condition assessment phase to determine whether the current anomaly is recoverable. A key criterion is the anomaly's recoverability confidence level. The system retrieves anomaly handling records from historical deployment tasks, comparing the current anomaly with historical anomalies in terms of type, environment, stage, and scope of impact. A similarity analysis method is used to select highly correlated historical samples, and the confidence score is calculated by statistically analyzing the proportion of successful and failed recovery in these samples. The system also considers the matching degree between the current deployment environment and the historical sample environment to adjust the weights, ensuring the estimation results have contextual consistency. The system compares the confidence value with a preset threshold. When the confidence value is higher than the set threshold, it determines that the current anomaly has recovery value, thereby driving the generation and execution of subsequent recovery strategies. If the confidence value is low, the system will switch to manual confirmation or wait for other anomaly resolution conditions to be met before processing.

[0035] When an anomaly is detected during deployment, the system locates the anomaly trigger source, typically the earliest deployment unit or service component to exhibit unexpected behavior. This source is marked as the root node of the anomaly chain. The system sorts all anomaly events in chronological order and, combined with the call dependencies between modules and the deployment chain structure, constructs a tree-like anomaly propagation tree rooted at the anomaly trigger source. Each node in this tree represents a deployment module or service unit where an anomaly occurred. The connections between nodes reflect the dependency trigger path of the anomaly propagating downstream. This structure clearly records the diffusion process of the anomaly from its root to its final state. During the construction of the propagation tree, the system uses timestamps to record the first occurrence time of each anomaly event, identifies the execution sequence of events through module call order, and further combines this with the context call chain and operation trajectory information recorded in the deployment logs to form a log dependency chain. To improve the efficiency and accuracy of event correlation analysis, the system introduces a hash correlation mechanism, which encodes the key features of each abnormal event, such as the exception type, service identifier, log signature, and time window information, into hash values. The system then uses a hash matching algorithm to identify related abnormal events on the deployment timeline and group them into the same propagation chain.

[0036] Once the system identifies an anomaly trigger source, it performs semantic extraction and structured classification using key fields in the anomaly log, including error code, anomaly message summary, stack trace, and trigger module identifier. Based on these structured features, the system executes a set of predefined rule priority mapping functions to calculate the matching degree between the anomaly and each deployment operation unit. The priority function performs a comprehensive score based on keyword matching degree, call path consistency, and service name similarity. The system selects the deployment operation unit with the highest matching degree from the scoring results and records it as the deployment breakpoint corresponding to the anomaly occurrence point. This deployment breakpoint serves as an important marker of the state boundary in the deployment process and will be used as the basis for determining the freeze strategy. If multiple anomalies or consecutive anomalies exist in the current deployment process, the system can further locate their aggregation point or propagation hub node as the main breakpoint by tracing back the time sequence and deployment topology. After locating the deployment operation unit, the system enters the anomaly recoverability assessment process, evaluating the feasibility of repairing the current anomaly using a historical data-driven confidence calculation model. The model retrieves instances with similar characteristics to the current anomaly from historical deployment records. Filtering criteria include anomaly type, deployment stage, affected modules, and anomaly severity level. The recovery success rate of these historical anomalies is then calculated and used as the first-level scoring input. To improve the contextual adaptability of the estimation, the system further introduces a deployment environment similarity weighting mechanism. By comparing the consistency between the current deployment task and historical records in terms of operating system version, node resource allocation, service topology, and deployment configuration parameters, a multi-dimensional environment similarity scoring model is constructed, and this score is used as a weighting factor for the confidence score. Finally, the system outputs a confidence score to determine whether the current anomaly is recoverable. When this score is higher than a preset threshold, a recovery strategy is triggered; if it is lower than the threshold, the system transitions to a manual intervention path or a post-recovery plan process.

[0037] Combined with appendix Figure 3 Once the system detects an anomaly trigger, it sequentially extracts the keyword density, error code type, and call stack depth features from the anomaly log fragments, and uses these as input variables to call the following scoring function:

[0038] in, Indicates candidate deployment operation units. They represent time points respectively The keyword density function, error code mapping function, and call stack depth function corresponding to this unit are three feature functions that are transformed by a nonlinear transformation function. Normalization is performed to unify its dimensions and expressive strength. Coefficients The feature weights are linearly adjustable, allowing the system to adjust the influence weights of different features according to the deployment scenario. To enhance the fit between the scoring results and the current anomaly context, a time-varying semantic fit kernel function is introduced. This function comprehensively considers the edit distance between the deployment unit and the exception context, the similarity of environment variables, and the overlap of semantic space, and uses these factors as a harmonic factor for the overall scoring function. The entire scoring function over the time interval... The internal integral operation reflects the cumulative effect of deployment anomalies over time, avoiding misjudgments caused by static scoring.

[0039] The above function The derivation process includes: Define deployment operation unit Abnormal correlation function This function should reflect the influence of three key features on anomaly targeting: ① keyword density in the anomaly log, ② importance of error codes, and ③ call stack depth distribution. The importance of these three varies across different deployment scenarios, hence the introduction of weighting coefficients. Linearly adjustable combinations are performed.

[0040] Since deployment anomalies occur dynamically and cannot be determined statically, a time variable is applied to each characteristic function. The integration operation ensures that abnormal evolution processes within the deployment time window are captured.

[0041] The system is conducting a survey of all candidate deployment units. After executing the scoring function, the deployment unit with the highest score is selected as the target deployment operation unit most closely associated with the current anomaly. This deployment unit serves as the anchor point in the anomaly propagation chain and is used to trigger the freeze strategy. To locate the optimal deployment breakpoint, the system traces backward from this deployment unit as the anomaly trigger source node, searching its adjacent operation units level by level in the deployment flowchart until the time point when the first anomaly signal is detected, marking it as a candidate node for the freeze point. This breakpoint records the runtime state, context, and resource usage at the time of deployment, for use in subsequent recovery strategy evaluation and path reconstruction.

[0042] When the system detects that a deployment unit is in an abnormal state, it performs a decision calculation on the unit's current state according to Boolean logic judgment rules. This Boolean judgment includes two core logical sub-items: the first is to determine whether there are critical dependent links in the abnormal propagation path, i.e., whether the deployment unit has a strong dependency relationship with the main deployment chain, such as database migration, core service registration, or configuration distribution operations; the second is to determine whether the deployment unit belongs to a parallel execution module, i.e., whether its deployment plan has a concurrency identifier in the scheduling graph and can be executed independently of the main line. The system parses the scheduling metadata and deployment topology structure, calculates the Boolean values ​​for the above two conditions respectively, and executes the logical combination. When the judgment result meets the freezing condition, the freezing policy is triggered, marking the module in a frozen state and suspending its subsequent deployment operations.

[0043] In deployment scenarios, a single anomaly event may correspond to multiple suspicious deployment units. To determine the most relevant target operation, the system constructs a maximum similarity matching mechanism. This mechanism comprehensively uses information from two dimensions for similarity calculation. The first dimension is the textual similarity between the identifier name of the deployment operation unit and the keywords extracted from the anomaly log, which is obtained through edit distance scoring. The second dimension is the degree of matching between each key-value pair in the deployment environment variables and the anomaly context information. This matching ratio is obtained by calculating the ratio of the intersection to the union of the key sets and is used as an environment similarity factor. The system uses a linear weighting or confidence scoring mechanism to fuse the similarity of the above two dimensions. The linear weighting is summed according to preset weight coefficients, while the confidence scoring dynamically adjusts the weights based on historical deployment success rates and anomaly handling experience.

[0044] During the deployment task orchestration and execution process, the system loads scheduling metadata and parses the execution plan graph. This execution plan graph consists of nodes composed of various deployment operation units, with directed edges representing their dependencies and execution order. The system traverses this graph structure, calculates the in-degree and out-degree of each deployment unit, and determines whether there are dependency paths directly connecting to the main deployment link. If the execution start node of a deployment unit has no sequential dependencies on other modules and can be independently scheduled and started by the scheduler, the system marks it as a parallel execution unit and writes a concurrency flag into the unit's metadata for subsequent judgment and strategy reference.

[0045] During the Boolean logic judgment process of the freeze strategy, the system determines the freeze trigger condition of the current module by reading the concurrency flag and critical dependency information of the deployment unit. Critical dependency judgment refers to whether the module is an irreplaceable core node in the deployment process, such as configuration initialization, database changes, or main chain service access operations. If this module fails, it will systematically block subsequent deployments. To enhance the flexibility and scenario adaptability of strategy execution, the system supports dynamic adjustment of Boolean logic judgment rules according to priority. When the critical dependency judgment result is true, the deployment unit is determined to be a core link in the deployment process. The system then ignores whether its concurrency flag is true and forcibly triggers the freeze strategy to ensure the integrity and stability of the deployment process. Conversely, when the critical dependency judgment result is false, the system will combine the concurrency flag to determine whether the module can be independently suspended. If the condition is met, only the module is frozen, and the main deployment path is allowed to continue.

[0046] The system encapsulates Boolean logic judgment rules as independent policy trigger components. These components are integrated into the deployment control engine in a modular manner and support dynamic configuration and online reloading via external deployment policy files, ensuring flexible adaptability of the policy logic in different environments. The policy trigger component internally defines a set of structured rule templates, allowing developers or operations personnel to configure the composition, priority, and judgment dimensions of each condition item according to the deployment scenario, including critical dependency identifiers, parallel execution identifiers, anomaly impact scope, and service weights. During deployment, this component parses the policy file in real time and injects the updated logic rules into the deployment process's decision chain, ensuring that anomaly handling behavior remains consistent with the latest policy.

[0047] The system extracts a keyword set from anomaly logs and performs semantic parsing on the identifier names of each candidate deployment unit. Then, it uses the Levenshtein edit distance algorithm to calculate the text similarity score between the anomaly keywords and the deployment unit names. This score reflects the minimum edit cost between the two; a smaller value indicates a closer similarity. To avoid scoring bias caused by different keyword lengths, the system performs standardization on the original edit distance results, dividing the calculated result by the average of the keyword length and the deployment name length to obtain a normalized similarity score. The system then filters out deployment units with scores below a preset threshold, ensuring that only highly matched candidate units are used for subsequent anomaly mapping and freeze strategy judgments, avoiding misuse of strategies due to low-relevance mismatches.

[0048] During deployment, the system records the runtime environment variables for each deployment operation unit, including key key-value pairs such as operating system type, dependent component version, network configuration parameters, and service port information. When an abnormal event occurs, the system will synchronously extract the environment variable information in the abnormal context, which usually includes log context, probe status return value, configuration snapshot or resource information content in the error stack.

[0049] The system represents the set of environment variables for candidate deployment units and the set of environment variables in the anomaly context as two distinct sets of key-value pairs. Based on this, the Jaccard similarity coefficient is used as the similarity calculation model. This coefficient is defined as the ratio of the number of elements in the intersection of the two sets to the number of elements in the union, effectively reflecting the degree of overlap in variable content. The calculation process does not consider the type differences of specific values ​​in the key-value pairs; instead, it uses the semantic combination of the key identifier and the value as the unique feature for set-based comparison, thus avoiding calculation bias caused by differences in data structure.

[0050] The resulting Jaccard similarity coefficient serves as a measure of environmental similarity between candidate deployment units and the current abnormal environment. The system uses this similarity result as a key parameter in the selection of target deployment units and can combine it with other similarity indicators, such as edit distance score, to form a weighted scoring model, participating in the final deployment unit ranking decision. If the environmental variable similarity of a candidate unit is higher than a set threshold and ranks high in the comprehensive score in the multi-dimensional scoring, the system will prioritize selecting this deployment unit as the target unit corresponding to the abnormal event.

[0051] Example 1: Combined with appendix Figure 4 In a large internet company, the development team continuously deployed a microservice system containing three key service modules: user authentication, product retrieval, and order settlement. The unique identifier for this deployment task was CD-20251023-008. Each atomic operation unit, such as building the authentication module, testing the retrieval module, and deploying the settlement module, was registered in the system's metadata table using this identifier before deployment. The atomic operation unit for deploying the retrieval module was identified as OP-Retrieve-56. After execution, this unit set a logical breakpoint and recorded deployment parameters such as image version v5.3.1, target node 172.16.0.48, dependent service Redis 6.2, and runtime environment variables such as JDK version 17, memory limit 1GB, and thread pool configuration. It also recorded the access status of its calls to Redis and Elasticsearch resources. All information was encapsulated as a time-series snapshot and written to the deployment snapshot database for visualization of deployment status and anomaly backtracking.

[0052] During the deployment of the order settlement module, the system logs showed the following exception: NullPointerException at OrderCheckoutService line 102. Accompanying this error was a spike in probe response latency to 3500ms, while the normal value should be within 600ms. Process monitoring data showed that the service thread pool was saturated, with CPU usage reaching 96%. The system collected exception events from three signal sources: log analysis, probe responses, and process status. After sorting by timestamp, an exception chain was constructed with the service that triggered the exception, OrderCheckoutService, as the root node. This chain contained two relay nodes: a failed DiscountService call and a timeout in the inventory lock interface. The final state was a failed user order placement triggering a payment rollback.

[0053] The system then retrieved seven similar anomalies from the historical deployment database within the past 30 days, five of which were ultimately resolved by service restarts, a success rate of 71.4%. Furthermore, the environment similarity score was 0.87, indicating that the current deployment environment is quite similar to historically recoverable instances. Therefore, the system calculated the recovery confidence level for this anomaly to be 0.76, exceeding the system's minimum recoverability threshold of 0.65, thus assessing it as recoverable.

[0054] Ultimately, the system executes a freeze strategy, freezing only the deployment chain of the faulty module, order settlement service, while preserving its context information. Subsequent modifications and deployments to this module are suspended, while the main deployment continues to complete the upgrade process for the authentication and retrieval modules. After deployment, the system generates a recovery strategy list containing information on the faulty module, fault type, historical references, and recovery suggestions. This list is then injected into the pre-deployment check process for the next deployment task, ensuring that deployment is forcibly blocked if the fault is not repaired, thus guaranteeing system stability and consistency.

[0055] During deployment, the order service threw a null pointer exception after calling the settlement logic. The system identified the key identifier "OrderCheckoutService" in the exception log and recorded its first exception timestamp as 15:42:10. The log immediately followed by "DiscountService not responding" and "Inventory lock interface call timeout". The system uses the exception triggering source "OrderCheckoutService" as the root node and constructs an exception propagation tree in chronological order. The child nodes are, in turn, the discount module failure and the inventory service exception, ultimately converging to the final state node indicating the user's order failure. This structure forms a three-layer exception propagation tree. The two sub-paths extending downwards from the root node are explicitly determined by the call order between modules and are linked together by the RequestID field in the log dependency chain. The system performs hash operations on these event blocks to generate unique hash codes, ensuring consistent binding between events and preventing reordering or loss.

[0056] After the anomaly propagation tree is constructed, the system enters the trigger source mapping phase. In this phase, the system uses a pre-defined rule matching function to perform a weighted analysis of keywords, error codes, and stack call depth in the logs. Taking the current trigger source, OrderCheckoutService, as an example, the keyword matching score is 0.83, the error code matching score is 0.66, and the call stack location weight is 0.91. Finally, the mapping function calculates the anomaly score for the deployment operation unit Deploy-Checkout-Node17 to be 0.812. In the deployment execution path, the system traces back from this operation unit to its upstream configuration loading node, finding that the timestamp of this point is the last operation before the anomaly occurred, i.e., 15:41:38. Based on this, the system marks it as a candidate node for freezing breakpoints.

[0057] To determine if recovery was feasible, the system retrieved the past thirty exception records related to the order service from the deployment history. Nine of these records showed a NullPointerException at CheckoutService, and seven of these were successfully recovered through service restart and hotfix configuration, resulting in a recovery success rate of 77.8%. Further, the system calculated deployment environment similarity by comparing environment variables such as JDK version, Redis configuration, and thread pool parameters between the current and historically recovered tasks, obtaining a Jaccard similarity coefficient of 0.82. After weighting the exception recovery success rate and environment similarity to 0.6 and 0.4 respectively, the system calculated the recovery confidence score. 0.6×0.778+0.4×0.82=0.7968.

[0058] Since the recovery confidence level is higher than the system's set threshold of 0.75, the system determines that the anomaly can be recovered and decides to implement a freeze strategy, which only suspends the deployment of the current module and writes its environment context and resource status into the recovery list, while allowing other deployment paths such as the authentication module and the recommendation module to continue to complete the upgrade, so as to reduce the overall deployment interruption time.

[0059] Example 2: Combined with appendix Figure 5 Based on Example 1, during deployment, the system detected a NullPointerException error in the order settlement service module, triggering the exception monitoring mechanism. The system extracted the keyword set {OrderCheckoutService, NullPointerException, line102} from the exception log and used it as the keyword density feature. The error code is... The call stack depth is 8 levels. The system identified three candidate deployment operation units:

[0060] The system is configured with feature weight coefficients of 100%. Set the integration time window to... It is simplified to a single-moment scoring. The system calculates the keyword density function for each candidate unit. Error code mapping function , Call stack depth function And set a nonlinear transformation function , Set at time The following values ​​were obtained:

[0061] The system also calculated the semantic fit kernel function. ,set up , .

[0062] Therefore, the system calculates the following:

[0063] System selection The system deploys an operation unit for the target. Then, tracing back to its upstream operation unit, the system finds a configuration loading completion operation at 15:41:38. This operation is the last successful breakpoint before the first occurrence of the abnormal signal, and the system marks it as a candidate breakpoint for the freeze strategy.

[0064] After the exception handling was triggered, the system identified three candidate deployment units associated with the exception event: D1: Deploy-Checkout-Service, D2: Deploy-User-Session-Service, and D3: Deploy-Payment-Gateway-Service. To further identify the target deployment units related to the freeze policy, the system needs to perform Boolean logic checks on each of these three units.

[0065] The system checks whether D1, D2, and D3 are in critical dependency paths. The system scheduling diagram shows that D1 is located in the main transaction path and is a critical link in order processing, while D2 and D3 are the user state cache and payment processing module, respectively. Although important, they do not constitute core dependency links. Based on Boolean logic judgment rules, the system marks the critical dependency result of D1 as true, and D2 and D3 as false.

[0066] The system then checks whether these three are parallel execution units. The deployment scheduling metadata shows that D1 is deployed serially with other modules, while D2 and D3 use parallel branches in the deployment process. Therefore, the system determines that the parallel flag for D1 is false, while that for D2 and D3 is true.

[0067] The system uses the critical dependency judgment result and the parallel state as a Boolean logic combination input to determine whether the freeze strategy is triggered. Since this strategy is set to trigger freeze when the critical dependency is true, and D1 meets this condition, the freeze action must still be performed even though it is not a parallel module; D2 and D3 will not trigger freeze.

[0068] If the system fails to accurately identify anomalies during the initial analysis phase, resulting in multiple candidate deployment units, a final screening process using similarity comparisons is required. The system calculates the edit distance score between the name of each candidate deployment unit and the keywords in the anomaly logs, and combines this with the Jaccard similarity of environment variable key-value pairs as an environment fit factor. Finally, a total similarity score is obtained using a linear weighted approach.

[0069] The exception log keyword is OrderCheckoutService, and the keyword set extracted by the system is {Order, Checkout, Service}. The word segmentation set of the identifier name of each deployment unit is as follows: D1, named Deploy-Checkout-Service, has a high overlap with the keyword set, an edit distance of 2, and a Jaccard similarity of 0.67. D2 is named Deploy-User-Session-Service, has an edit distance of 6, and a Jaccard similarity of 0.43. D3 is named Deploy-Payment-Gateway-Service, with an edit distance of 5 and a Jaccard similarity of 0.51. The system sets the linear weighting factor to 0.6:0.4, and assigns it to the edit distance and the matching degree of the environmental variable, respectively.

[0070] The system first standardizes the edit distance, setting the maximum edit distance to 8 and the minimum to 0. The standardized scores are as follows: D1: 1 - 2 / 8 = 0.75 D2: 1 - 6 / 8 = 0.25 D3: 1 - 5 / 8 = 0.375 Next, a weighted calculation is performed: D1 similarity = 0.6 × 0.75 + 0.4 × 0.67 = 0.45 + 0.268 = 0.718 D2 similarity = 0.6 × 0.25 + 0.4 × 0.43 = 0.15 + 0.172 = 0.322 D3 similarity = 0.6 × 0.375 + 0.4 × 0.51 = 0.225 + 0.204 = 0.429 The system selects D1 as the target deployment operation unit based on the principle of maximum similarity, and combines it with the aforementioned Boolean logic judgment result to confirm that a freeze strategy should be triggered on it. At the same time, the system retains the context state and resource binding information to provide a stable entry point for subsequent recovery strategies or manual intervention.

[0071] The exception log detected the error message "Error invoking module OrderCheck: NullPointerException in CheckServiceHandler". Based on the exception keywords, three related deployment operation units were initially identified: Deploy-Order-Check, Deploy-CheckService-Node, and Deploy-Session-Monitor. At this point, the system initiated the policy trigger component for further decision analysis. This component consists of a Boolean logic engine and an edit distance filtering module. All judgment rules support hot reloading and updating via policy files. In this deployment strategy, the priority of critical dependency judgments is set to a strong logical condition that takes precedence over parallel identifier judgments.

[0072] The system reads the deployment plan diagram through scheduling metadata and finds that Deploy-Order-Check belongs to the main transaction process. Its deployment path has a strict sequential order with the payment process, so it is marked as a critical dependency path. Furthermore, this module executes sequentially with other modules, and the system records its concurrency flag as false. Although Deploy-CheckService-Node has some data interaction with the main process, it is marked as a parallel branch in the deployment scheduling diagram, and the system records its concurrency flag as true, while its critical dependency flag is false. Deploy-Session-Monitor is an independent monitoring module with no direct data dependencies, and is marked as a parallel and non-critical path module.

[0073] Based on the Boolean logic expression of the policy trigger, the freeze policy is immediately triggered when the critical dependency is true. The system determines that Deploy-Order-Check meets the conditions and enters the freeze candidate stage. The other two modules, because they do not meet the critical dependency and are executed in parallel, are marked as non-freeze targets.

[0074] Based on this, to ensure the accuracy of freezing target deployment units, the system calculates edit distance scores for all candidate units. The keyword in the exception log is "OrderCheck," which the system extracts into a word set {Order,Check}. The word segmentation set for each deployment unit name is as follows: Deploy-Order-Check:{Order,Check} Deploy-CheckService-Node: {Check,Service,Node} Deploy-Session-Monitor: {Session,Monitor} The system uses the Levenshtein algorithm to calculate the shortest edit distance between the keyword and the target keyword. OrderCheck vs OrderCheck: Distance is 0 OrderCheck vs CheckServiceNode: Distance is 10 OrderCheck vs SessionMonitor: Distance is 13 Then, standardization was performed, with the maximum distance set to 13. The standardized score was calculated as follows: Deploy-Order-Check:

[0075] Deploy-CheckService-Node:

[0076] Deploy-Session-Monitor:

[0077] The system sets a score threshold of 0.4, therefore, Deploy-Session-Monitor and Deploy-CheckService-Node are removed, and only Deploy-Order-Check is retained as the final deployment exception handling target. The policy trigger, based on concurrency indicators and key dependency results, combined with edit distance standardized scoring, accurately triggers the freeze policy and locates the deployment unit.

[0078] In this deployment process, the exception context environment variables captured by the system when an exception is triggered are as follows: REGION:us-east-1 ENV: production DB_CLUSTER:cluster-alpha FEATURE_FLAG:settlement_v2 Meanwhile, the system selected the following three deployment candidate units: 1. Deploy-Order-Check The environment variables are: REGION:us-east-1 ENV: production DB_CLUSTER:cluster-alpha FEATURE_FLAG:settlement_v2 2. Deploy-CheckService-Node The environment variables are: REGION:us-east-2 ENV:staging DB_CLUSTER:cluster-beta FEATURE_FLAG:settlement_v1 3. Deploy-Session-Monitor The environment variables are: REGION:us-east-1 ENV: production LOG_LEVEL:debug METRIC_ENABLED:true The system calculates the Jaccard similarity coefficient based on the above data. This coefficient is defined as the ratio of the number of elements in the intersection of two sets to the number of elements in their union. Let A represent the set of anomaly context variables, and B represent the set of environment variables for candidate units. Then the Jaccard similarity formula is:

[0079] Calculate the Jaccard similarity of the three candidate units respectively: Deploy-Order-Check: A and B are identical; their intersection is 4 key-value pairs, and their union is 4...

[0080] Deploy-CheckService-Node: No variables are consistent with the exception context; the intersection is 0, and the union is 8.

[0081] Deploy-Session-Monitor: The variables REGION and ENV have the same value, their intersection is 2, and their union contains a total of 6 key-value pairs.

[0082] The system sets the similarity filtering threshold to 0.6, retaining only deployment operation units with a matching degree higher than this value, further confirming that Deploy-Order-Check is the candidate with the strongest environmental similarity.

[0083] Following this step, the system incorporates the environment variable matching results and the aforementioned log keyword edit distance score into the final scoring mechanism, calculating the normalized score of the target deployment unit using a linear weighting method. With the environment matching score weighted at 40% and the edit distance score weighted at 60%, the comprehensive score is: Deploy-Order-Check: The edit distance standardized score is 1.0, and the Jaccard similarity is 1.0.

[0084] Deploy-Session-Monitor: The edit distance score is 0, and the Jaccard similarity is 0.333.

[0085] This demonstrates that by introducing the matching degree of deployment environment variables, the system can effectively eliminate the risk of deployment misjudgment caused by inconsistencies in the environment, making the final selected target deployment unit more context-consistent and controllable in abnormal response.

[0086] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for executing an anomaly recovery strategy in a continuous deployment environment, characterized in that... include: The build, test, deploy, and release operations in the continuous deployment process are divided into atomic operation units that are idempotent and traceable. Logical breakpoints are set after each atomic unit is executed to mark deployment state transition nodes. During deployment, monitor abnormal events, break down the abnormal chain, identify triggering factors, relay effects and final state performance, and determine whether recovery conditions are met based on breakpoint status, scope of abnormal impact, stage idempotency and module controllability. When an abnormal module does not affect the main deployment chain, put it in a frozen state, retain its context and resource binding, suspend subsequent deployment, and continue to execute the main deployment path to support subsequent repair. Before the recovery strategy is executed, logical conditions are confirmed based on the current deployment status to assess whether it exceeds the tolerable range, whether there is a risk of contamination or alternative treatment conditions, and to make a comprehensive judgment on whether to trigger a rollback. After the deployment process is completed, a post-recovery strategy plan is generated based on the abnormal information and the status of the frozen module, and injected into the pre-deployment check process of subsequent operation and maintenance tasks or the next deployment.

2. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 1, characterized in that... The atomic operation unit is registered with a unique identifier before execution, so that the state of each deployment process is traceable and can be distinguished from historical execution instances; the logical breakpoint records deployment parameters, runtime environment variables and resource call status after being triggered, so as to form a time series snapshot of the deployment state; the monitoring of abnormal events includes three signal sources: log analysis, process status detection and probe response detection, to determine the stage and scope of the abnormality.

3. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 1, characterized in that... The breakdown of the anomaly chain is based on the temporal order of the causal relationship of events, and the anomaly triggering source and propagation path are described hierarchically; when determining whether the recovery conditions are met, the confidence level of the anomaly recoverability is estimated based on historical deployment data.

4. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 3, characterized in that... The hierarchical description of the anomaly chain includes taking the anomaly trigger source as the root node and constructing an anomaly propagation tree according to the time causal order to support recovery path backtracking; the determination of the event causal relationship is based on timestamps, module call order and log dependency chain, and multiple anomaly events are chained together through a hash association mechanism.

5. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 3, characterized in that... Once identified, the abnormal trigger source is mapped to the corresponding deployment operation unit to locate the deployment breakpoint and assist in triggering the freeze strategy; the confidence estimate of the abnormal recoverability is based on the success rate of recovery of similar abnormalities in the deployment history, and is weighted by the similarity of the deployment environment.

6. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 5, characterized in that... The process of mapping the abnormal trigger source to the deployment operation unit includes executing a matching function based on rule priority. The function calculates the weights according to the abnormal log keywords, error codes, and call stack depth to obtain the corresponding deployment operation unit. When locating the deployment breakpoint, the adjacent operation units are searched backward from the trigger source node until the time point when the abnormal signal first appears is used as the candidate node for the freeze point.

7. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 5, characterized in that... The freezing strategy is triggered based on a set of Boolean logic judgments, including two calculation results: whether there are critical dependent links in the anomaly propagation path and whether the deployment unit is a parallel execution module. When there are multiple matching deployment operation units, the system selects the target deployment unit according to the principle of maximum similarity. The similarity is calculated by weighting the edit distance score between the operation unit identifier name and the keywords in the anomaly log, as well as the similarity ratio of key-value pairs in the deployment environment variables. The weighting calculation adopts a linear weighting or confidence scoring mechanism.

8. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 7, characterized in that... In determining whether the deployment unit is a parallel execution module, the system marks the concurrency flag of each unit based on the execution plan graph in the scheduling metadata; the Boolean logic judgment rule supports dynamic adjustment according to priority, and when the key dependency judgment result is true, the freeze strategy is triggered even if the parallel flag is true.

9. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 7, characterized in that... The Boolean logic judgment is encapsulated as a strategy trigger component, which supports configuration and reloading through deployment strategy files. When multiple matching deployment operation units exist, the system first calculates the edit distance score and directly eliminates candidate units with scores lower than a preset threshold. The edit distance score is calculated using the Levenshtein algorithm and combined with the keyword length standardization result.

10. The method for executing an anomaly recovery strategy in a continuous deployment environment according to claim 7, characterized in that... The deployment environment variable matching degree is obtained by calculating the Jaccard similarity coefficient between the set of environment variable key-value pairs of the candidate deployment unit and the set of environment variables in the abnormal context. The similarity result is used as a calculation factor for environment similarity in the screening of target deployment units.

Images