A cloud-native gray release governance control method and system

Abstract

The present application belongs to the technical field of gray release, and particularly relates to a cloud-native gray release governance control method and system. The method comprises the following steps: collecting multi-source data in a cloud-native environment; AI analyzing change semantics; constructing a change sensitive cause and effect propagation graph; AI predicting propagation coefficients and influence amplification coefficients; retrieving historical similar changes; predicting error budget consumption under different gray strategies; solving error budget safety envelope; generating release access control strategies; constructing gray-stable paired observation groups; dynamically adjusting release status; generating audit records and feeding back updated models. The present application can improve the risk identification capability before cloud-native change release, reduce the dependence of gray strategies on artificial experience, and reduce the production impact range of high-risk changes through error budget constraints and closed-loop control.

Description

Technical Field

[0001] This invention belongs to the field of canary release technology, specifically relating to a cloud-native canary release governance and control method and system. Background Technology

[0002] In cloud-native environments, applications are typically deployed as microservices on Kubernetes, container platforms, service meshes, or multi-cluster cloud platforms. Application image versions, configuration parameters, resource specifications, routing rules, rate limiting policies, circuit breaking policies, timeout policies, retry policies, database connection pool parameters, caching parameters, and cross-cluster traffic rules may all change frequently.

[0003] In real-world production environments, production failures are often closely related to change operations. Common change types include:

[0004] Application image release; modifications to Kubernetes Deployment, StatefulSet, ConfigMap, and Secret; adjustments to traffic rules for Service, Ingress, Gateway, VirtualService, and DestinationRule; adjustments to service mesh routing ratios, timeouts, retry, circuit breakers, and rate limiting policies; adjustments to CPU, memory Request / Limit, and HPA policies; adjustments to database connection pool, thread pool, message queue, and cache parameters; cross-cluster, cross-availability zone, and cross-region traffic switching; and adjustments to business configurations, feature switches, and canary deployment switches.

[0005] Existing technologies typically mitigate change risks by employing the following methods: manual approval before release; canary releases based on fixed templates; post-release monitoring based on error rates, latency, or resource metrics; triggering pauses or rollbacks when metrics exceed thresholds; displaying service dependencies through service topology; and using historical change records for risk reference.

[0006] However, existing technologies still have the following shortcomings: First, existing canary release strategies typically rely on fixed templates, such as canary release ratios of 1%, 5%, 20%, 50%, and 100%, failing to dynamically determine the canary release pace based on different change semantics, service dependency topology, error budget status, and runtime risks. Second, existing release gatekeepers typically treat changes as a whole for risk scoring, making it difficult to identify the runtime semantics behind change fields. For example, while increased retries, shortened timeouts, reduced CPU limits, expanded connection pools, traffic migration, and reduced rate limiting thresholds all manifest as configuration changes, their impact direction, propagation paths, and key observation indicators differ significantly. Third, existing service topology analysis is typically used for fault location or link visualization, lacking methods to combine change semantics with service call chains, shared resource edges, service-level target weights, and runtime resource pressure to calculate risk propagation coefficients and impact amplification coefficients. Fourth, while Service Level Objectives (SLOs) and Error Budgets are used for reliability management, existing systems typically only use error budgets for post-event statistics or manual decision-making. They lack methods to directly convert the remaining error budget percentage, error budget consumption rate, predicted error rate increment, service request volume, and impact amplification factor into initial canary release percentages, maximum canary release percentages, single-batch growth percentages, observation windows, pause boundaries, and rollback boundaries. Fifth, existing AI-powered O&M solutions are mostly used for anomaly detection, alarm aggregation, or risk scoring, lacking methods to combine AI model outputs with Kubernetes controllers, service mesh traffic rules, canary release executors, and error budget constraints to form automated access control. Sixth, existing canary release observations typically directly compare overall canary release metrics with global metrics, which is easily affected by environmental differences such as cluster, availability zone, node resource levels, traffic sources, and downstream dependency paths, leading to misjudgments or omissions. Seventh, existing automated canary release control is prone to frequent fluctuations between advancement, pause, and resumption, especially when metrics fluctuate near thresholds, potentially causing frequent changes in canary release percentages and affecting release stability. Summary of the Invention

[0007] This invention addresses the problems of existing technologies in cloud-native environments, such as the variety of change types, complex service dependencies, reliance on fixed templates for canary release strategies, difficulty in directly applying AI risk prediction results to release control, difficulty in engineering error budgets to enter release access control, and susceptibility of canary release observation to environmental noise interference. It provides a cloud-native canary release governance and control method and system.

[0008] The technical solution claimed by this invention is as follows:

[0009] A cloud-native canary release governance and control method includes the following steps:

[0010] S1: Collect multi-source data from cloud-native environments;

[0011] S2: Based on the multi-source data collected in S1, obtain the change objects and change content to be changed, extract differences based on the obtained change objects and change content, and generate configuration differences, code differences, resource object differences or release description differences; input the generated differences into the change semantic recognition model to generate change semantic fingerprints; the change semantic fingerprints include change semantic operators;

[0012] S3: Construct a change-sensitive causal propagation graph based on the multi-source data collected in S1; the change-sensitive causal propagation graph includes service nodes, resource nodes, call edges, shared resource edges, traffic migration edges, and service-level target weights;

[0013] S4: Based on the change semantic fingerprint and change semantic operator generated in S2, combined with the change-sensitive causal propagation graph constructed in S3, the risk propagation coefficient is predicted through the propagation risk prediction model; the key propagation path and impact amplification coefficient are determined based on the risk propagation coefficient.

[0014] S5: Encode the changes to be executed obtained in S2 into change vectors, retrieve similar historical changes from the historical change database collected in S1 based on the change vectors, and calculate historical risks in combination with historical release results;

[0015] S6: Based on the key propagation path and impact amplification factor determined in S4 and the historical risk calculated in S5, the budget consumption prediction model is used to predict the erroneous budget consumption and the probability of default on service level targets under different candidate gray-scale strategies.

[0016] S7: Based on the erroneous budget consumption and service level target default probability predicted by S6, and combined with the current erroneous budget data collected by S1, solve for the erroneous budget safety envelope.

[0017] S8: Generate a release access control policy based on the error budget security envelope solved in S7, and distribute the release access control policy to at least one of the release pipeline, service mesh control plane, Kubernetes controller or canary release executor;

[0018] S9: During the gray-scale release process, a gray-scale-stable paired observation group is constructed based on the real-time service indicator data collected by S1, and the differential observation indicators are calculated.

[0019] S10: Based on the differential observation index, differential risk status and real-time error budget consumption rate calculated in S9, and combined with the error budget safety envelope in S7, the subsequent release actions are output through the release strategy optimization module.

[0020] S11: Execute the subsequent release action of the output of S10 through the release state machine which is constrained by the error budget safety envelope of S7 and has a hysteresis interval;

[0021] S12: Generate a change risk audit record and write the change risk audit record into the historical change database of S1 to update at least one of the change semantic recognition model of S2, the propagation risk prediction model of S4, the budget consumption prediction model of S6, or the release strategy optimization model of S10.

[0022] The order of steps S2 and S3 can be interchanged; the order of steps S4 and S5 can be interchanged.

[0023] Preferably, the multi-source data includes: service dependency data, tracing data, service mesh telemetry data, Kubernetes resource object relationship data, and shared resource relationship data.

[0024] Preferably, the multi-source data further includes: service metric data, log data, Kubernetes resource configuration data, historical change records, historical release results, alarm records, service level target data, and error budget data; the change semantic recognition model can employ at least one of rule-based models, machine learning models, deep learning models, text semantic models, code semantic models, configuration semantic models, or multimodal fusion models; the change semantic recognition model uses Kubernetes resource object differences, Helm Charts, etc. The input consists of at least one of the following: differences, configuration file differences, code commit differences, release form descriptions, and historical incident texts. The output includes change semantic operators, runtime impact types, key observation indicators, and risk propagation directions. The change semantic fingerprint includes the change object, change field, field change magnitude, change direction, associated service, business level, change semantic operators, and runtime impact types. The change semantic operators include at least one of the following: resource shrinkage operator, resource amplification operator, traffic migration operator, timeout shrinkage operator, timeout relaxation operator, retry amplification operator, retry shrinkage operator, rate limiting threshold shrinkage operator, rate limiting threshold relaxation operator, circuit breaker threshold shrinkage operator, circuit breaker threshold relaxation operator, connection pool amplification operator, connection pool shrinkage operator, elastic capacity shrinkage operator, elastic capacity amplification operator, configuration semantic replacement operator, and application version replacement operator. The change-sensitive causal propagation graph includes service nodes, resource nodes, call edges, shared resource edges, traffic migration edges, retry relationships, timeout relationships, circuit breaker relationships, rate limiting relationships, and service level target weights.

[0025] Preferably, the impact amplification coefficient is calculated based on at least one of the following: call traffic percentage, business level, service level target weight, dependency path length, synchronous call ratio, retry amplification factor, downstream resource level, historical similar change failure rate, current error budget status, and propagation coefficient output by the propagation risk prediction model; the calculation formula for the impact amplification coefficient Amp is as follows:

[0026] Amp = Σp [ PathWeight(p) × OperatorWeight(op) × TrafficRatio(p) × SLOWeight(p) × BusinessWeight(p) × RetryFactor(p) × ResourcePressure(p) ×ContextRisk(p) × EdgePropagationCoef(p) × Decay(p) ]

[0027] Where: p represents the propagation path; PathWeight(p) represents the propagation path weight; OperatorWeight(op) represents the weight of the change semantic operator; TrafficRatio(p) represents the path traffic ratio; SLOWeight(p) represents the service level target weight on the path; BusinessWeight(p) represents the business level weight; RetryFactor(p) represents the retry amplification factor; ResourcePressure(p) represents the resource pressure coefficient; ContextRisk(p) represents the current running context risk; EdgePropagationCoef(p) represents the edge propagation coefficient output by the propagation risk prediction model; Decay(p) represents the path length decay coefficient.

[0028] Preferably, the historical risk is calculated based on change semantic fingerprint similarity, change semantic operator similarity, dependency topology similarity, runtime context similarity, historical release results, and time decay coefficient, wherein runtime context similarity includes at least one of traffic pattern similarity, error budget state similarity, resource level similarity, and business peak and valley state similarity; the calculation formula for the historical risk HistoryRisk is as follows:

[0029] HistoryRisk = Σi OutcomeRisk(i) × FingerprintSim(i) × OperatorSim(i) × TopologySim(i) × RuntimeContextSim(i) × BudgetSim(i) × TimeDecay(i)

[0030] Where: OutcomeRisk(i) represents the risk of the release result of the i-th historical similar change; FingerprintSim(i) represents the change fingerprint similarity; OperatorSim(i) represents the change semantic operator similarity; TopologySim(i) represents the topological similarity; RuntimeContextSim(i) represents the runtime context similarity; BudgetSim(i) represents the error budget state similarity; TimeDecay(i) represents the time decay coefficient.

[0031] Preferably, the budget consumption prediction model predicts the error rate, latency distribution, downstream call error rate, error budget consumption rate, and service level target default probability within a future time window for multiple candidate grayscale strategies; the error budget consumption amount PredictedBudgetCost(G) is calculated as follows:

[0032] PredictedBudgetCost(G)=Σt [Traffic(t)×GrayRatio(t)×PredictedErrorIncrement(t)×Amp×ObservationWindow(t)×BudgetWeight(t) ]

[0033] Where: G represents the candidate grayscale strategy; Traffic(t) represents the number of requests within the time window t; GrayRatio(t) represents the proportion of grayscale traffic; PredictedErrorIncrement(t) represents the prediction error rate increment; Amp represents the impact amplification coefficient; ObservationWindow(t) represents the observation window length; BudgetWeight(t) represents the service level target budget weight.

[0034] The service level target default probability ViolationProb(G) is output as follows:

[0035] ViolationProb(G)=F(G,Amp,HistoryRisk,RuntimeState,BudgetRemaining,BudgetBurnRate, BusinessPeakState)

[0036] Where: F is the budget consumption prediction model or rule model; G represents the candidate grayscale strategy; Amp represents the impact amplification coefficient; HistoryRisk represents historical risk; RuntimeState represents the runtime state; BudgetRemaining represents the remaining safety envelope range; BudgetBurnRate represents the allowed explosion radius; and BusinessPeakState represents the optimal state with minimum cost.

[0037] Preferably, the error budget safety envelope employs a release state machine with a hysteresis interval, setting pause and recovery thresholds. Only after multiple consecutive sampling periods meet the recovery conditions is canary release allowed to continue. Specifically, this is achieved by: calculating the predicted error budget consumption based on the canary traffic ratio, observation window, service request volume, expected error rate increment, service level target budget weight, and impact amplification coefficient; ensuring the predicted error budget consumption does not exceed the product of the remaining error budget and the safety factor; ensuring the service level target default probability does not exceed a preset default probability threshold; ensuring the overall risk does not exceed a preset overall risk threshold; and determining the maximum allowed canary traffic ratio, initial canary traffic ratio, single-batch canary growth ratio, and observation window based on candidate canary strategies that meet the constraints. The error budget safety envelope is defined as a set of candidate canary strategies that satisfy the following constraints:

[0038] Envelope = { G |PredictedBudgetCost(G) ≤ RemainingBudget ×SafetyFactor,

[0039] ViolationProb(G) ≤ ViolationThreshold,

[0040] RiskScore(G) ≤ RiskThreshold,

[0041] GrayRatio_first(G) ≤ FirstRatioLimit,

[0042] GrayRatio_max(G) ≤ MaxRatioLimit,

[0043] StepRatio(G) ≤ StepRatioLimit}

[0044] Where: PredictedBudgetCost(G) represents the projected budget; RemainingBudget represents the remaining error budget; SafetyFactor represents the safety factor; ViolationProb(G) represents the default ratio; ViolationThreshold represents the service level target default probability threshold; RiskScore(G) represents the risk factor; RiskThreshold represents the comprehensive risk threshold; GrayRatio_first(G) represents the initial grayscale release range percentage; FirstRatioLimit represents the upper limit of the initial grayscale ratio; GrayRatio_max(G) represents the maximum grayscale release ratio; MaxRatioLimit represents the upper limit of the maximum grayscale ratio; StepRatio(G) represents the single-batch growth ratio; StepRatioLimit represents the upper limit of the single-batch growth ratio; the comprehensive risk RiskScore(G) is calculated as follows:

[0045] RiskScore(G) =

[0046] α × Normalize(Amp)

[0047] + β × Normalize(HistoryRisk)

[0048] + γ × Normalize(PredictedBudgetCost(G))

[0049] + δ × Normalize(ViolationProb(G))

[0050] + ε × Normalize(RuntimePressure)

[0051] Where α, β, γ, δ, and ε are weighting coefficients, and RuntimePressure represents the current operating pressure.

[0052] Preferably, the matching score MatchScore(g,s) between the grayscale instance g and the stable instance s is calculated as follows:

[0053] MatchScore(g,s) =

[0054] w1 × ClusterSim(g,s)

[0055] + w2 × AZSim(g,s)

[0056] + w3 × NodeLoadSim(g,s)

[0057] + w4 × PodSpecSim(g,s)

[0058] + w5 × TrafficSourceSim(g,s)

[0059] + w6 × DependencyPathSim(g,s)

[0060] + w7 × BusinessLabelSim(g,s)

[0061] Select the stable instance with the highest matching score and meeting the minimum matching threshold as the control instance for the grayscale instance; calculate the differential observation index between the grayscale instance and the matching stable instance; the differential observation index includes at least one of the following: error rate difference, P95 latency difference, P99 latency difference, CPU Throttling difference, memory usage difference, container restart count difference, downstream error rate difference, queue length difference, connection pool usage difference, retries count difference, circuit breaker count difference, rate limiting count difference, and error budget consumption rate difference; calculate the differential risk state DiffRisk based on the differential observation index:

[0062] DiffRisk = a1 × Normalize(DiffErrorRate)

[0063] + a2 × Normalize(DiffP99)

[0064] + a3 × Normalize(DiffBudgetBurn)

[0065] + a4 × Normalize(DiffCPUThrottle)

[0066] + a5 × Normalize(DiffDownstreamError)

[0067] + a6 × Normalize(DiffRetry)

[0068] Where: a1 to a6 are the indicator weights; DiffErrorRate represents the error rate difference between gray-scale instances and matching stable instances; DiffP9 represents the P99 latency difference between gray-scale instances and matching stable instances; DiffBudgetBurn represents the error budget consumption rate difference between gray-scale instances and matching stable instances; DiffCPUThrottle represents the CPU throttling difference between gray-scale instances and matching stable instances; DiffDownstreamError represents the downstream error rate difference between gray-scale instances and matching stable instances; and DiffRetry represents the retry count difference between gray-scale instances and matching stable instances.

[0069] Preferably, the release access control policy includes at least one of the following: allow release, prohibit release, limit release time window, require manual approval, limit the initial grayscale traffic ratio, limit the maximum grayscale traffic ratio, limit the single batch grayscale growth ratio, increase the number of grayscale batches, extend the observation window, specify service indicators that must be observed, specify interfaces that must be observed, set pause conditions, set recovery conditions, set termination conditions, set rollback trigger conditions, or restrict parallel release with other changes.

[0070] A cloud-native canary release governance and control system includes, in sequence, a data acquisition module for collecting service metric data, log data, tracing data, Kubernetes resource configuration data, service mesh telemetry data, service dependency data, shared resource relationship data, historical change records, historical release results, alarm records, service level target data, and error budget data from the cloud-native environment; a change semantic recognition module for acquiring configuration differences, code differences, resource object differences, or release descriptions of changes to be performed and generating change semantic fingerprints through a change semantic recognition model; a causal propagation graph construction module for constructing a change-sensitive causal propagation graph based on service dependency data, service mesh telemetry data, and shared resource relationship data; and a risk propagation coefficient and critical propagation factor for predicting the risk propagation coefficient and critical propagation factor based on the change semantic fingerprint, change semantic operator, and change-sensitive causal propagation graph. The system includes: a propagation risk prediction module for path and impact amplification coefficients; a historical risk calculation module for encoding changes to be executed into change vectors and retrieving similar historical changes from a historical change library based on these change vectors to calculate historical risks; a consumption prediction module for predicting error budget consumption and service level target default probability budgets under different candidate grayscale strategies; a security envelope solving module for solving the error budget security envelope based on the error budget consumption and service level target default probability; an access control policy generation module for generating release access control policies based on the error budget security envelope; and a module for distributing release access control policies to the release pipeline, service mesh control plane, and Kubernetes. The system includes: a canary release control module comprising at least one of a controller or a canary release executor; a canary pairing observation module for constructing a canary-stable paired observation group and calculating differential observation metrics during canary release execution; a release strategy optimization module for outputting subsequent release actions based on differential observation metrics, differential risk status, and real-time error budget consumption rate; a hysteresis state machine control module for executing subsequent release actions through a release state machine constrained by an error budget safety envelope and having a hysteresis interval; and an audit feedback module for generating change risk audit records and writing the change risk audit records into a historical change database for updating at least one of a change semantic recognition model, a propagation risk prediction model, a budget consumption prediction model, or a release strategy optimization model; the system is connected to at least one of a release pipeline, a service mesh control plane, a Kubernetes controller, a canary release executor, a monitoring system, an alarm system, a service level target management system, and a historical change database.

[0071] The beneficial effects of this invention are as follows:

[0072] This invention provides a cloud-native canary release governance and control method and system. It inputs generated configuration differences, code differences, resource object differences, or release description differences into a change semantic recognition model to generate change semantic fingerprints (including change semantic operators). This enables the use of artificial intelligence to identify change semantic operators from configuration differences, code differences, resource object differences, and release descriptions, distinguishing the different impact directions of different changes on runtime behavior. This avoids coarse-grained judgments based solely on field names or change types, improving the ability to identify risks before changes. A change-sensitive causal propagation graph is constructed, and different propagation rules are adopted according to different change semantic operators. This allows for the identification of the propagation paths and strengths of different changes such as retry amplification, timeout contraction, resource contraction, connection pool amplification, and traffic migration in the service dependency chain, improving the accuracy of impact scope calculation. The error budget safety envelope is solved based on error budget consumption and service level target default probability, directly generating the initial canary release ratio, maximum canary release ratio, observation window, and rollback boundary, engineering the error budget into canary release constraints. Instead of relying on fixed template configuration canary release ratios, it is based on change semantics, historical similar changes, current runtime status, error budget status, and AI. The prediction results dynamically generate access control policies, reducing the reliance on human experience in release strategies and addressing the challenges of existing technologies in cloud-native environments, such as the variety of change types, complex service dependencies, fixed templates for canary release strategies, the difficulty in directly applying AI risk prediction results to release control, and the difficulty in engineering the inclusion of error budgets into release access control. A canary-stable paired observation group is constructed, selecting and matching stable instances based on cluster, availability zone, node resource level, traffic source, and downstream dependency path to reduce the impact of environmental noise on canary analysis results and lower the canary observation misjudgment rate, addressing the issue of environmental noise interference in canary observations in cloud-native environments. During canary execution, the canary ratio, observation window, and release status are dynamically adjusted based on differential observation indicators, enhancing the closed-loop control capability of the release process. After the change is completed, a change risk audit record is generated and written to the historical change database for subsequent model calibration and similar change risk calculation, improving auditing and continuous model learning capabilities.

[0073] The error budget safety envelope employs a release state machine with a hysteresis interval, setting pause and recovery thresholds. Gray-scale release is only allowed to continue after the recovery conditions are met for multiple consecutive sampling periods, preventing frequent jitter in the release state. The change semantic fingerprint, propagation path, error budget safety envelope, paired observation group, differential index, state machine transition, and final release result are written into the audit log and used for subsequent model calibration and similar change risk calculation, improving audit and model continuous learning capabilities. Attached Figure Description

[0074] Figure 1This is a flowchart of the cloud-native canary release governance and control method in an embodiment of the present invention.

[0075] Figure 2 This is an example of changing a sensitive causal propagation graph in an embodiment of the present invention.

[0076] Figure 3 This is a schematic diagram of the change process in an embodiment of the present invention, showing how the change to be performed is parsed into a change semantic fingerprint and a change semantic operator by the AI ​​change semantic recognition model.

[0077] Figure 4 This is a diagram of the integrated risk and error budget security envelope model in an embodiment of the present invention.

[0078] Figure 5 This is a flowchart illustrating the dynamic control process for grayscale deployment in an embodiment of the present invention.

[0079] Figure 6 This invention provides an access control strategy decision matrix diagram for an embodiment of the invention.

[0080] Figure 7 This is a timing diagram of system module interactions in an embodiment of the present invention.

[0081] Figure 8 This is a schematic diagram of the closed-loop feedback of audit records in an embodiment of the present invention.

[0082] Figure 9 This is a diagram illustrating the overall architecture of the cloud-native canary release governance and control system in an embodiment of the present invention. Detailed Implementation

[0083] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions will be further described clearly and completely below with reference to the accompanying drawings.

[0084] This invention provides a cloud-native canary release governance and control method, such as... Figure 1 As shown, it includes the following steps:

[0085] S1: Collect multi-source data from the cloud-native environment; in a specific embodiment of the present invention, the multi-source data includes: service metric data, log data, tracing data, Kubernetes resource configuration data, service mesh telemetry data, service dependency data, shared resource relationship data, historical change records, historical release results, alarm records, service level target data, and error budget data. The service metric data includes at least one of the following: request volume, error rate, success rate, P50 latency, P95 latency, P99 latency, CPU utilization, memory utilization, CPU Throttling, container restart count, thread pool utilization, connection pool utilization, queue length, retries, circuit breaker counts, and rate limiting counts. The Kubernetes resource configuration data includes at least one of the following: Deployment, StatefulSet, DaemonSet, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler, PodDisruptionBudget, Gateway, VirtualService, and DestinationRule. The service mesh telemetry data includes at least one of the following: service mesh routing ratio, request success rate, request error rate, service-to-service call latency, Envoy proxy metrics, retry policy, timeout policy, circuit breaker policy, rate limiting policy, and traffic mirroring policy. The error budget data includes service level objectives, statistical period, allowed number of erroneous requests, number of consumed erroneous requests, remaining error budget, remaining percentage of error budget, and error budget consumption rate.

[0086] S2: AI analyzes change semantics: Based on the multi-source data collected in S1, the change objects and change content to be performed are obtained. Based on the obtained change objects and change content, differences are extracted to generate configuration differences, code differences, resource object differences, or release description differences. The generated differences are input into the change semantic recognition model to generate change semantic fingerprints. The change semantic fingerprints include change semantic operators.

[0087] In a specific embodiment of the present invention, the change object and change content to be executed are obtained. The change to be executed includes at least one of the following: image version change, configuration change, code change, Kubernetes resource object change, service mesh traffic rule change, timeout rule change, retry rule change, rate limiting rule change, circuit breaker rule change, connection pool parameter change, thread pool parameter change, and elastic scaling parameter change. The configuration differences include configuration field names, field values ​​before change, field values ​​after change, field change magnitude, field configuration file, and field service. The code differences include at least one of the following: commit file, interface definition change, function call change, dependency library version change, database access logic change, cache access logic change, exception handling logic change, and concurrency handling logic change. The resource object differences include at least one of the following: replica number change, CPU request change, CPU limit change, memory request change, memory limit change, probe configuration change, image version change, environment variable change, and auto-scaling parameter change. The release description differences include at least one of the following: release single text, change reason, changed service, business line, impact scope description, rollback plan, release time window, and manual risk marking.

[0088] The configuration differences, code differences, resource object differences, or release descriptions are input into the change semantic recognition model to generate a change semantic fingerprint. The change semantic recognition model can employ at least one of the following: a rule-based model, a machine learning model, a deep learning model, a text semantic model, a code semantic model, a configuration semantic model, or a multimodal fusion model.

[0089] The change semantic fingerprint includes: the object of change, the field of change, the magnitude of field change, the direction of change, the associated service, the business level, the service level target weight, the change semantic operator, the runtime impact type, the direction of risk propagation, key observation indicators, and the confidence level.

[0090] The change semantic operators include at least one of the following: resource shrinkage operator, resource amplification operator, traffic migration operator, timeout shrinkage operator, timeout relaxation operator, retry amplification operator, retry shrinkage operator, rate limiting threshold shrinkage operator, rate limiting threshold relaxation operator, circuit breaker threshold shrinkage operator, circuit breaker threshold relaxation operator, connection pool amplification operator, connection pool shrinkage operator, elastic capacity shrinkage operator, elastic capacity amplification operator, configuration semantic replacement operator, and application version replacement operator.

[0091] In specific embodiments of the present invention, the change semantic recognition model determines the change semantic operator according to the following rules or model output results: when the change to be executed causes a decrease in CPU Limit, memory Limit, number of replicas, thread pool capacity, or queue capacity, a resource shrinkage operator is output; when the change to be executed causes an increase in CPU Limit, memory Limit, number of replicas, or elastic capacity, a resource amplification operator is output; when the change to be executed causes a migration of the service mesh routing ratio from the first cluster, first availability zone, or first version to the second cluster, second availability zone, or second version, a traffic migration operator is output; when the change to be executed causes a decrease in timeout, a timeout shrinkage operator is output; when the change to be executed causes an increase in timeout, a timeout widening operator is output; when the change to be executed causes an increase in the number of retries, retry ratio, or retry window, a retry amplification operator is output; when the change to be executed causes an increase in the database connection pool, cache connection pool, or HTTP... When the connection pool upper limit increases, output the connection pool amplification operator; when the change to be executed causes the current limiting threshold to decrease, output the current limiting threshold shrinkage operator; when the change to be executed causes the circuit breaker trigger threshold, half-open detection threshold, or circuit breaker recovery parameter to change, output the circuit breaker threshold adjustment related operator.

[0092] S3: Construct a change-sensitive causal propagation graph based on the multi-source data collected in S1, specifically as follows: Construct a change-sensitive causal propagation graph based on service dependency data, tracing data, service mesh telemetry data, Kubernetes resource object relationships, and shared resource relationships.

[0093] The change-sensitive causal propagation graph includes service nodes, resource nodes, call edges, shared resource edges, traffic migration edges, retry relationships, timeout relationships, circuit breaker relationships, rate limiting relationships, and service level target weights.

[0094] Wherein: Service nodes represent microservices, API gateways, background task services, sidecar proxies, or external services; Resource nodes represent databases, caches, message queues, object storage, external interfaces, node resource pools, cluster resource pools, or availability zone resource pools; Call edges represent synchronous calls, asynchronous calls, cross-cluster calls, or cross-availability zone calls between services; Shared resource edges represent multiple services sharing databases, caches, message queues, connection pools, thread pools, or node resources; Traffic migration edges represent traffic transfer relationships caused by canary releases, cross-cluster migrations, cross-availability zone migrations, or version routing adjustments; Service level target weights represent the degree of impact of a service or interface on the overall business reliability.

[0095] Service node characteristics include request volume, error rate, P95 latency, P99 latency, CPU utilization, memory utilization, CPU Throttling, number of container restarts, percentage of remaining error budget, rate of error budget consumption, business level, and frequency of historical failures.

[0096] Edge features include call frequency, call traffic percentage, call success rate, call latency, call timeout, number of retries, synchronous call ratio, circuit breaker threshold, rate limiting threshold, cross-cluster identifier, cross-availability zone identifier, and downstream resource level.

[0097] Taking the order service as an example, this demonstrates microservice dependencies and change propagation paths, such as... Figure 2 As shown, the nodes include API Gateway, order-service, payment-service, inventory-service, coupon-service, user-service, notification-service, Kafka, MySQL, Redis, and external payment gateway.

[0098] S4: AI Prediction of Propagation Coefficient and Impact Amplification Coefficient: Input the change semantic fingerprint, change semantic operator, and change-sensitive causal propagation graph generated in S2 into the propagation risk prediction model (i.e., input the change-sensitive causal propagation graph, change semantic fingerprint, and change semantic operator into ai) to obtain the propagation rules of the change to be executed in the change-sensitive causal propagation graph. Figure 3 The propagation rules include risk propagation coefficient, critical propagation path, and impact amplification coefficient. In a specific embodiment of the present invention, different change semantic operators correspond to different propagation rules: the identified high-risk nodes (the higher the risk coefficient, the higher the risk, and the lower the allowed range of changes); the critical propagation path is the flow of data from node A to nodes bcdef, for example, the data flow from the application service to the business pod is the critical propagation path; some nodes are very critical, and changes may cause multiple nodes or even the cluster to crash. The degree of this crash is quantified, which is the impact amplification coefficient.

[0099] The timeout shrinkage operator calculates the risk of failure propagation along the upstream direction of the call chain, focusing on observing the upstream service error rate, client request failure rate, number of retries, and user-side success rate;

[0100] The timeout is relaxed to reduce the risk of computational resource consumption along the call chain of the current service and downstream. The focus is on monitoring thread pool usage, connection pool usage, queue length, and P99 latency.

[0101] The retry amplification operator calculates the request amplification risk along the downstream direction of the call chain, focusing on monitoring downstream QPS, downstream error rate, database connection pool wait time, cached connection pool wait time, and downstream P99 latency;

[0102] The resource shrinkage operator calculates the capacity gap of this service and the latency propagation risk of synchronizing upstream services, focusing on monitoring CPU Throttling, memory usage, container restart count, P99 latency, and upstream error rate;

[0103] The connection pool amplification operator calculates the connection pressure risk of downstream databases or cache resources along the shared resource edge, focusing on the number of database connections, connection wait time, slow query ratio, cache connection exhaustion times, and shared resource error rate;

[0104] The traffic migration operator calculates the capacity carrying risk of the target cluster, target availability zone, or target service version along the traffic migration edge, focusing on observing the target cluster CPU level, target cluster memory level, cross-region P99 latency, cross-cluster error rate, and target version error budget consumption rate.

[0105] The rate limiting threshold shrinkage operator calculates the risk of decreased entry request rejection rate and business success rate, focusing on monitoring the number of rate limiting attempts, request rejection rate, business success rate, and user-side error rate;

[0106] The circuit breaker threshold adjustment operator calculates the risk of downstream call isolation and upstream error propagation, focusing on the number of circuit breakers, half-open recovery success rate, call failure rate, and downstream recovery time.

[0107] The amplification factor (Amp) is calculated based on at least the following factors: call traffic percentage, business level, service level target weight, dependency path length, synchronous call ratio, retry amplification factor, downstream resource level, historical similar change failure rate, current error budget status, and the propagation factor output by the propagation risk prediction model.

[0108] In a specific embodiment of the present invention, the influence amplification factor Amp is calculated in the following manner:

[0109] Amp = Σp [ PathWeight(p) × OperatorWeight(op) × TrafficRatio(p) × SLOWeight(p) × BusinessWeight(p) × RetryFactor(p) × ResourcePressure(p) ×ContextRisk(p) × EdgePropagationCoef(p) × Decay(p) ]

[0110] Where: p represents the propagation path; PathWeight(p) represents the propagation path weight; OperatorWeight(op) represents the weight of the change semantic operator; TrafficRatio(p) represents the path traffic ratio; SLOWeight(p) represents the service level target weight on the path; BusinessWeight(p) represents the business level weight; RetryFactor(p) represents the retry amplification factor; ResourcePressure(p) represents the resource pressure coefficient; ContextRisk(p) represents the current running context risk; EdgePropagationCoef(p) represents the edge propagation coefficient output by the propagation risk prediction model; Decay(p) represents the path length decay coefficient.

[0111] The change semantic fingerprint, change semantic operator, and change sensitive causal propagation graph are input into the propagation risk prediction model to obtain the risk propagation coefficients on different service nodes and call edges, and the key propagation paths and impact amplification coefficients are determined based on the risk propagation coefficients.

[0112] S5: The changes to be executed obtained in S2 are encoded into change vectors. Based on the change vectors, historical similar changes are retrieved from the historical change database, and historical risks are calculated. In a specific embodiment of the present invention, the changes to be executed are encoded into change vectors. The change vectors are generated by concatenating or fusing at least one of the following: configuration difference features, code difference features, resource object difference features, change semantic operator features, service topology context features, running status features, error budget status features, release time window features, business peak and valley status features, and release single text features. Based on the change vectors, historical similar changes are retrieved from the historical change database. Historical similarity includes: change semantic fingerprint similarity, change semantic operator similarity, dependency topology similarity, running context similarity, error budget status similarity, business peak and valley status similarity, and resource level similarity. Historical risk (HistoryRisk) is calculated as follows:

[0113] HistoryRisk = Σi OutcomeRisk(i) × FingerprintSim(i) × OperatorSim(i) × TopologySim(i) × RuntimeContextSim(i) × BudgetSim(i) × TimeDecay(i)

[0114] Where: OutcomeRisk(i) represents the risk of the release result of the i-th historical similar change; FingerprintSim(i) represents the change fingerprint similarity; OperatorSim(i) represents the change semantic operator similarity; TopologySim(i) represents the topological similarity; RuntimeContextSim(i) represents the runtime context similarity; BudgetSim(i) represents the error budget state similarity; TimeDecay(i) represents the time decay coefficient.

[0115] When historical similar changes have similar fields but the difference in runtime context is greater than a preset threshold, the contribution of the historical similar change to the current historical risk is reduced.

[0116] S6: Based on the critical propagation path and impact amplification factor determined in S4, and the historical risks calculated in S5, the budget consumption prediction model is used to predict the erroneous budget consumption and service level target default probability under different candidate gray-scale strategies. Specifically, multiple candidate gray-scale strategies are generated, each including the initial gray-scale ratio, gray-scale batch, single batch growth ratio, observation window, maximum gray-scale ratio, pause boundary, and rollback boundary. The candidate gray-scale strategies, impact amplification factor, historical risks, current operating status, remaining erroneous budget ratio, erroneous budget consumption rate, service request volume, business peak and valley status, and release time window are input into the budget consumption prediction model to predict the erroneous budget consumption and service level target default probability under different candidate gray-scale strategies. Figure 4 ).

[0117] In a specific embodiment of the present invention, the predicted budget cost (G) is calculated as follows:

[0118] PredictedBudgetCost(G) =

[0119] Σt [Traffic(t) × GrayRatio(t)

[0120] × PredictedErrorIncrement(t)

[0121] × Amp × ObservationWindow(t)

[0122] × BudgetWeight(t)

[0123] Where: G represents the candidate grayscale strategy; Traffic(t) represents the request volume within the time window t; GrayRatio(t) represents the grayscale traffic ratio; PredictedErrorIncrement(t) represents the prediction error rate increment; Amp represents the impact amplification coefficient; ObservationWindow(t) represents the observation window length; and BudgetWeight(t) represents the service level target budget weight. The service level target default probability ViolationProb(G) is output as follows:

[0124] ViolationProb(G) = F(G, Amp, HistoryRisk, RuntimeState,

[0125] BudgetRemaining, BudgetBurnRate,

[0126] BusinessPeakState)

[0127] Where: F is the budget consumption prediction model or rule model; G represents the candidate grayscale strategy; Amp represents the impact amplification coefficient; HistoryRisk represents historical risk; RuntimeState represents the runtime state; BudgetRemaining represents the remaining safety envelope range; BudgetBurnRate represents the allowed explosion radius; and BusinessPeakState represents the optimal state with minimum cost.

[0128] S7: Solve the error budget safety envelope based on the prediction results of S6. Specifically, solve the error budget safety envelope based on the predicted error budget consumption of the candidate grayscale strategy and the service level target default probability.

[0129] The error budget safety envelope is used to limit the initial grayscale traffic ratio, the maximum grayscale traffic ratio, the single batch grayscale growth ratio, the observation window, the pause threshold, the recovery threshold, the termination threshold, and the rollback boundary.

[0130] The error budget safety envelope is defined as the set of candidate grayscale strategies that satisfy the following constraints:

[0131] Envelope = { G |

[0132] PredictedBudgetCost(G) ≤ RemainingBudget × SafetyFactor,

[0133] ViolationProb(G) ≤ ViolationThreshold,

[0134] RiskScore(G) ≤ RiskThreshold,

[0135] GrayRatio_first(G) ≤ FirstRatioLimit,

[0136] GrayRatio_max(G) ≤ MaxRatioLimit,

[0137] StepRatio(G) ≤ StepRatioLimit}

[0138] Where: PredictedBudgetCost(G) represents the projected budget; RemainingBudget represents the remaining error budget; SafetyFactor represents the safety factor; ViolationProb(G) represents the default ratio; ViolationThreshold represents the service level target default probability threshold; RiskScore(G) represents the risk factor; RiskThreshold represents the comprehensive risk threshold; GrayRatio_first(G) represents the initial grayscale release range percentage; FirstRatioLimit represents the upper limit of the initial grayscale ratio; GrayRatio_max(G) represents the maximum grayscale release ratio; MaxRatioLimit represents the upper limit of the maximum grayscale ratio; StepRatio(G) represents the single-batch growth ratio; StepRatioLimit represents the upper limit of the single-batch growth ratio; for example... Figure 5 As shown, the overall risk RiskScore(G) is calculated as follows:

[0139] RiskScore(G) =

[0140] α × Normalize(Amp)

[0141] + β × Normalize(HistoryRisk)

[0142] + γ × Normalize(PredictedBudgetCost(G))

[0143] + δ × Normalize(ViolationProb(G))

[0144] + ε × Normalize(RuntimePressure)

[0145] Where α, β, γ, δ, and ε are weighting coefficients, and RuntimePressure represents the current operating pressure.

[0146] Select the target grayscale strategy from the candidate grayscale strategies that satisfy the error budget safety envelope constraint. If no candidate grayscale strategy satisfies the error budget safety envelope, output an access control conclusion such as prohibiting release, allowing only a very small proportion of grayscale, extending the observation window, or transferring to manual approval.

[0147] S8: Generate and publish access control policies based on the error budget security envelope obtained in S7. Figure 6 In a specific embodiment of the present invention, the release is a multi-process process. Each process detects the cluster status, predicts the explosion radius safety risk coefficient, etc., and pauses or rolls back the release when a fixed threshold is reached. A canary release will only be performed when each process is below the threshold. The release access control strategy includes at least one of the following:

[0148] Allow release, prohibit release, restrict release time window, require manual approval, limit the initial grayscale traffic ratio, limit the maximum grayscale traffic ratio, limit the single batch grayscale growth ratio, increase the number of grayscale batches, extend the observation window, specify service indicators that must be observed, specify interfaces that must be observed, set pause conditions, set recovery conditions, set termination conditions, set rollback trigger conditions, or restrict parallel release with other changes.

[0149] Deploy the deployment access control policy to at least one of the following: deployment pipeline, service mesh control plane, Kubernetes controller, or canary deployment executor.

[0150] In some embodiments of the present invention, the proportion of canary traffic is adjusted by modifying the service mesh VirtualService, DestinationRule, Gateway, Ingress, or canary release controller resource objects. In other embodiments of the present invention, canary rollout, pausing, degradation, or rollback operations are performed through Argo Rollouts, Flager, Kubernetes Operator, CI / CD pipeline plugins, or custom canary release controllers.

[0151] S9: Canary releases are executed based on access control policies. During the canary release process, the canary instance selects a matching stable instance from the stable instance set to construct a canary-stable paired observation group, and calculates differential observation metrics based on the constructed observation group. Constructing the canary-stable paired observation group includes:

[0152] Based on at least one of the following: cluster where the instance resides, availability zone, node resource level, Pod resource specifications, request traffic source, business tag, downstream dependency path, and time window, select a stable instance from the stable instance set that matches the grayscale instance. Figure 7 ).

[0153] In some embodiments of the present invention, the matching score MatchScore(g,s) between the grayscale instance g and the stable instance s is calculated as follows:

[0154] MatchScore(g,s) =

[0155] w1 × ClusterSim(g,s)

[0156] + w2 × AZSim(g,s)

[0157] + w3 × NodeLoadSim(g,s)

[0158] + w4 × PodSpecSim(g,s)

[0159] + w5 × TrafficSourceSim(g,s)

[0160] + w6 × DependencyPathSim(g,s)

[0161] + w7 × BusinessLabelSim(g,s)

[0162] The stable instance with the highest matching score and meeting the minimum matching threshold is selected as the control instance for the grayscale instance. Differential observation metrics are calculated between the grayscale instance and the matching stable instance. These differential observation metrics include at least one of the following: error rate difference, P95 latency difference, P99 latency difference, CPU Throttling difference, memory usage difference, container restart count difference, downstream error rate difference, queue length difference, connection pool usage difference, retries difference, circuit breaker count difference, rate limiting count difference, and error budget consumption rate difference.

[0163] Differential observation indicators include:

[0164] DiffErrorRate = ErrorRate_gray - ErrorRate_stable

[0165] DiffP95 = P95_gray - P95_stable

[0166] DiffP99 = P99_gray - P99_stable

[0167] DiffBudgetBurn = BudgetBurn_gray - BudgetBurn_stable

[0168] DiffRetry = Retry_gray - Retry_stable

[0169] DiffDownstreamError = DownstreamError_gray - DownstreamError_stable

[0170] Calculate the differential risk status (DiffRisk) based on differential observation indicators:

[0171] DiffRisk =

[0172] a1 × Normalize(DiffErrorRate)

[0173] + a2 × Normalize(DiffP99)

[0174] + a3 × Normalize(DiffBudgetBurn)

[0175] + a4 × Normalize(DiffCPUThrottle)

[0176] + a5 × Normalize(DiffDownstreamError)

[0177] + a6 × Normalize(DiffRetry)

[0178] Where: a1 to a6 are the indicator weights; DiffErrorRate represents the error rate difference between gray-scale instances and matching stable instances; DiffP9 represents the P99 latency difference between gray-scale instances and matching stable instances; DiffBudgetBurn represents the error budget consumption rate difference between gray-scale instances and matching stable instances; DiffCPUThrottle represents the CPU throttling difference between gray-scale instances and matching stable instances; DiffDownstreamError represents the downstream error rate difference between gray-scale instances and matching stable instances; and DiffRetry represents the retry count difference between gray-scale instances and matching stable instances.

[0179] S10: Input the differential observation metrics into the release strategy optimization model to output subsequent release actions, and execute the subsequent release actions through a release state machine with a hysteresis interval. Determine whether the release is complete. If yes, proceed to S11; otherwise, re-execute S10. Specifically, input the differential observation metrics, differential risk status, real-time error budget consumption rate, current grayscale ratio, historical similar change risk, current release status, and observation window into the release strategy optimization model to obtain subsequent release actions. The subsequent release actions include expanding grayscale, maintaining grayscale, reducing grayscale, extending the observation window, pausing release, terminating release, transferring to manual approval, or calling a preset rollback interface. The subsequent release actions output by the release strategy optimization model are constrained by the error budget safety envelope. When the grayscale traffic ratio output by the release strategy optimization model exceeds the maximum grayscale traffic ratio limited by the error budget safety envelope, the grayscale traffic ratio is corrected to the maximum grayscale traffic ratio or the manual approval state is entered. The subsequent release actions are executed through a release state machine with a hysteresis interval. The release state machine includes at least one of the following states: pending release, initial grayscale, keep observing, expand grayscale, pause grayscale, reduce grayscale, rollback, transfer to manual approval, and release completed. The release state machine has a pause threshold (PauseThreshold), a recovery threshold (ResumeThreshold), and a rollback threshold (RollbackThreshold), wherein the recovery threshold is lower than the pause threshold.

[0180] The state machine transition rules include: when DiffRisk is greater than or equal to RollbackThreshold, or the real-time error budget consumption rate exceeds the rollback boundary, enter the rollback state and call the preset rollback interface; when DiffRisk is greater than or equal to PauseThreshold and less than RollbackThreshold, enter the pause grayscale state and stop expanding grayscale; when in the pause grayscale state, and DiffRisk is lower than ResumeThreshold for M consecutive sampling periods, and the real-time error budget consumption rate is lower than the recovery boundary, it is allowed to return to the maintain observation state or expand grayscale state; when DiffRisk is continuously lower than the advance threshold, and the predicted error budget consumption is still within the error budget safety envelope, the expand grayscale action is executed; when the grayscale ratio reaches the maximum grayscale traffic ratio limited by the error budget safety envelope but does not meet the full release conditions, maintain grayscale or switch to manual approval; when the remaining error budget is lower than the preset retention threshold, even if the differential observation index does not exceed the pause threshold, the grayscale ratio is reduced, the observation window is extended, or the release is paused. By using the hysteresis range between the pause threshold and the resume threshold, frequent jitter during gray-scale advancement, pause, and resume processes can be avoided.

[0181] like Figure 8As shown, S11: After the change is completed, a change risk audit record is generated, written to the historical change database, and fed back to the training model. The change risk audit record includes: change number, change semantic fingerprint, change semantic operator, state before change, state after change, snapshot of change-sensitive causal propagation graph, key propagation path, impact amplification coefficient, list of historical similar changes, historical risks, current state risks, error budget security envelope, release access control policy, gray-scale execution record, gray-scale-stable paired observation group, differential observation index, model prediction result, actual observation result, prediction bias, state machine transition record, policy adjustment record, approval record, final release result, whether rollback was performed, whether an alarm was triggered, whether an SLO was breached, reason for failure, and a summary of explainable risks.

[0182] Based on the discrepancy between the model's predictions and actual observations, at least one of the following models—the change semantic recognition model, the propagation risk prediction model, the budget consumption prediction model, or the release strategy optimization model—is incrementally updated.

[0183] When a change is successful and does not trigger an alarm or cause an SLO default, the historical risk of similar changes is reduced; when a change fails, is rolled back, triggers an alarm, or causes an SLO default, the historical risk of similar changes is increased.

[0184] S12: Generate a change risk audit record and write the change risk audit record into the historical change database of S1, for updating at least one of the following: the change semantic recognition model of S2, the propagation risk prediction model of S4, the budget consumption prediction model of S6, or the release strategy optimization model of S10. Figure 8 );

[0185] In a specific embodiment of the present invention, the order of steps S2 and S3 can be interchanged; the order of steps S4 and S5 can be interchanged.

[0186] This invention also provides a cloud-native canary deployment access control system, the overall system architecture of which is as follows: Figure 9 As shown, the interaction order between the modules is as follows: Figure 7As shown, the system includes, in sequence, a data acquisition module for collecting service metric data, log data, tracing data, Kubernetes resource configuration data, service mesh telemetry data, service dependency data, shared resource relationship data, historical change records, historical release results, alarm records, service level target data, and error budget data in a cloud-native environment; a change semantic recognition module for obtaining configuration differences, code differences, resource object differences, or release descriptions of changes to be performed and generating change semantic fingerprints through a change semantic recognition model; a causal propagation graph construction module for constructing a change-sensitive causal propagation graph based on service dependency data, service mesh telemetry data, and shared resource relationship data; and a risk propagation coefficient and key propagation parameters based on the change semantic fingerprint, change semantic operator, and change-sensitive causal propagation graph. The system includes: a propagation risk prediction module for path and impact amplification coefficients; a historical risk calculation module for encoding changes to be executed into change vectors and retrieving similar historical changes from a historical change library based on these change vectors to calculate historical risks; a consumption prediction module for predicting error budget consumption and service level target default probability budgets under different candidate grayscale strategies; a security envelope solving module for solving the error budget security envelope based on the error budget consumption and service level target default probability; an access control policy generation module for generating release access control policies based on the error budget security envelope; and a module for distributing release access control policies to the release pipeline, service mesh control plane, and Kubernetes. The system includes: a canary execution control module comprising at least one of a controller or a canary release executor; a canary pairing observation module for constructing a canary-stable paired observation group and calculating differential observation metrics during the canary release execution process; a release strategy optimization module for outputting subsequent release actions based on differential observation metrics, differential risk status, and real-time error budget consumption rate; a hysteresis state machine control module for executing subsequent release actions through a release state machine constrained by an error budget safety envelope and having a hysteresis interval; and an audit feedback module for generating change risk audit records and writing the change risk audit records into a historical change database for updating at least one of a change semantic recognition model, a propagation risk prediction model, a budget consumption prediction model, or a release strategy optimization model; the system is connected to at least one of a release pipeline, a service mesh control plane, a Kubernetes controller, a canary release executor, a monitoring system, an alarm system, a service level target management system, and a historical change database.

[0187] In a specific embodiment of the present invention, the overall system architecture is as follows: Figure 2 As shown, it includes a data acquisition layer, an AI risk understanding and prediction layer, an access control decision layer, a gray-scale execution control layer, and an audit feedback layer.

[0188] The data acquisition layer interfaces with Prometheus, Kubernetes API, service mesh, tracing system, CI / CD pipeline, Git repository, CMDB, alarm system, and SLO platform; the AI ​​risk understanding and prediction layer includes a change semantic recognition model, a propagation risk prediction model, a historical similar change retrieval model, and a budget consumption prediction model; the access control decision layer includes an error budget security envelope solving module and an access control policy generation module; the canary execution control layer interfaces with Argo Rollouts, Flager, Istio, Gateway API, or Kubernetes controller; and the audit feedback layer records change risk audit records and feeds back to the historical change library and AI model.

[0189] In specific embodiments of the present invention, the method and system provided by the present invention are applicable to the following scenarios:

[0190] 1. Scenarios requiring increased retries

[0191] The number of retries for a certain order service to call the inventory service has increased from 1 to 33.

[0192] The change semantic operator corresponding to this change is identified as the retry amplification operator. The runtime impact types include increased downstream request volume, increased inventory service error rate, increased database connection pool pressure, and increased error budget consumption rate. A change-sensitive causal propagation graph is constructed to identify the propagation path.

[0193] order-service → inventory-service → inventory-db

[0194] The retry amplification operator propagates downstream along the call chain, and the system calculates the risk propagation coefficients for inventory-service and inventory-db.

[0195] Generate an error budget safety envelope:

[0196] The initial grayscale ratio is 1%, the single batch growth ratio does not exceed 3%, the maximum grayscale ratio is 20%, and the observation window is 20 minutes.

[0197] The suspension condition is that the latency difference of inventory-service P99 exceeds 80ms or the downstream error rate difference exceeds 0.05%.

[0198] The rollback condition is that the wait time of the inventory-db connection pool exceeds twice that of the stable group and is met for three consecutive sampling periods.

[0199] 2. CPU resource contraction scenario

[0200] The CPU limit of a payment service has been reduced from 4 cores to 2 cores, while the number of replicas remains unchanged.

[0201] The change semantic operator corresponding to this change is identified as the resource shrinkage operator. The runtime impact types include service capacity reduction, increased CPU Throttling, increased P99 latency, and increased upstream service call failure rate.

[0202] The system identifies the propagation path:

[0203] API Gateway → order-service → payment-service

[0204] The resource shrinkage operator first acts on the payment-service itself and then propagates upstream along the call chain, resulting in increased latency and error rate.

[0205] Generate access control policy:

[0206] The initial grayscale ratio is 1%, the maximum grayscale ratio is 10%, and the observation window is 30 minutes.

[0207] The suspension condition is that the payment-service CPU Throttling difference exceeds 10%.

[0208] The rollback condition is that the difference in order-service 5xx exceeds 0.05% and is true for 3 consecutive sampling periods.

[0209] 3. Expanding the Scenario with Connection Pools

[0210] The maximum number of database connection pools for the user service has been increased from 50 to 200.

[0211] The change semantic operator corresponding to this change is identified as the connection pool amplification operator. The runtime impact types include increased database connection pressure, increased slow query ratio, and shared database connection resources being squeezed out by other services.

[0212] Identify the propagation path of shared resources:

[0213] user-service → user-db

[0214] profile-service → user-db

[0215] account-service → user-db

[0216] Based on the shared resource edge, user-db is identified as a shared resource node, and the connection pressure risk is calculated.

[0217] Generate access control policy:

[0218] The initial grayscale ratio is 2%, the growth rate of a single batch shall not exceed 5%, the maximum grayscale ratio is 30%, and the observation window is 15 minutes.

[0219] The suspension condition is that the database connection wait time exceeds 1.5 times that of the stable group.

[0220] The rollback condition is that the shared database connection usage exceeds 90% and this condition is met for two consecutive sampling periods.

[0221] 4. Cross-cluster traffic migration scenarios

[0222] We migrated 30% of the order service traffic from the Shanghai cluster to the Singapore cluster. The Singapore cluster has sufficient capacity, but cross-region database access latency is high.

[0223] The semantic operator for identifying changes is a traffic migration operator. The runtime impact types include target cluster capacity capacity, increased cross-region latency, and database connection pool wait times.

[0224] Generate a secure envelope:

[0225] The initial grayscale ratio is 3%, the single batch growth ratio does not exceed 5%, the maximum grayscale ratio is 30%, and the observation window is 20 minutes.

[0226] The pause condition is that the cross-region P99 latency difference exceeds 100ms.

[0227] The rollback condition is that the database connection pool wait time exceeds twice that of the stable group.

[0228] 5. Scenarios with shortened timeout periods

[0229] The timeout for payment-service calls has been reduced from 3 seconds to 1 second.

[0230] The system identifies the semantic change operator as a timeout shrinkage operator, and the runtime impact types include increased upstream error rate, increased client retries, and propagation of request failures.

[0231] The propagation direction is upstream along the call chain.

[0232] Identify the propagation path:

[0233] API Gateway → order-service → payment-service

[0234] The key evaluation metrics are the 5xx error rate, request retries, and user-side failure rate for the order-service and API Gateway.

[0235] Generate access control policy:

[0236] The initial grayscale ratio is 1%, the maximum grayscale ratio is 20%, and the observation window is 20 minutes.

[0237] The suspension condition is that the difference between order-service 5xx exceeds 0.05%.

[0238] The rollback condition is that the API Gateway user request failure rate exceeds the threshold for three consecutive sampling periods.

[0239] 6. Scenarios where the current limiting threshold is reduced.

[0240] The rate limiting threshold of an API gateway has been reduced from 10,000 requests per second to 5,000 requests per second.

[0241] The semantic operator for the change was identified as the rate limiting threshold shrinkage operator. The runtime impact types include increased request rejection rate, decreased business success rate, and increased user-side error rate.

[0242] The system generates access control policies:

[0243] The initial grayscale ratio is 5%, the maximum grayscale ratio is 30%, and the observation window is 10 minutes.

[0244] The suspension condition is that the difference in request rejection rate exceeds 0.1%.

[0245] The rollback condition is a decrease in business success rate of more than 0.2% that occurs for three consecutive sampling periods.

Claims

1. A cloud-native gray release governance control method, characterized in that, Includes the following steps: S1: Collect multi-source data from cloud-native environments; S2: Based on the multi-source data collected in S1, obtain the change objects and change content to be changed, extract differences based on the obtained change objects and change content, and generate configuration differences, code differences, resource object differences or release description differences; input the generated differences into the change semantic recognition model to generate change semantic fingerprints; the change semantic fingerprints include change semantic operators; S3: Construct a change-sensitive causal propagation graph based on the multi-source data collected in S1; the change-sensitive causal propagation graph includes service nodes, resource nodes, call edges, shared resource edges, traffic migration edges, and service-level target weights; S4: Based on the change semantic fingerprint and change semantic operator generated in S2, combined with the change-sensitive causal propagation graph constructed in S3, the risk propagation coefficient is predicted through the propagation risk prediction model; the key propagation path and impact amplification coefficient are determined based on the risk propagation coefficient. S5: Encode the changes to be executed obtained in S2 into change vectors, retrieve similar historical changes from the historical change database collected in S1 based on the change vectors, and calculate historical risks in combination with historical release results; S6: Based on the key propagation path and impact amplification factor determined in S4 and the historical risk calculated in S5, the budget consumption prediction model is used to predict the erroneous budget consumption and the probability of default on service level targets under different candidate gray-scale strategies. S7: Based on the erroneous budget consumption and service level target default probability predicted by S6, and combined with the current erroneous budget data collected by S1, solve for the erroneous budget safety envelope. S8: Generate a release access control policy based on the error budget security envelope solved in S7, and distribute the release access control policy to at least one of the release pipeline, service mesh control plane, Kubernetes controller or canary release executor; S9: During the gray-scale release process, a gray-scale-stable paired observation group is constructed based on the real-time service indicator data collected by S1, and the differential observation indicators are calculated. S10: Based on the differential observation index, differential risk status, and real-time error budget consumption rate calculated in S9, and combined with the error budget safety envelope in S7, output subsequent release actions through the release strategy optimization module; S11: Execute the subsequent release action of the output of S10 through the release state machine which is constrained by the error budget safety envelope of S7 and has a hysteresis interval; S12: Generate a change risk audit record and write the change risk audit record into the historical change database of S1 to update at least one of the change semantic recognition model of S2, the propagation risk prediction model of S4, the budget consumption prediction model of S6, or the release strategy optimization model of S10. The order of steps S2 and S3 can be interchanged; the order of steps S4 and S5 can be interchanged.

2. The cloud-native canary release governance and control method based on claim 1, characterized in that, The multi-source data includes: service dependency data, tracing data, service mesh telemetry data, Kubernetes resource object relationship data, and shared resource relationship data.

3. The cloud-native canary release governance and control method based on claim 2, characterized in that, The multi-source data also includes: service metric data, log data, Kubernetes resource configuration data, historical change records, historical release results, alarm records, service level target data, and error budget data; the change semantic recognition model can employ at least one of rule-based models, machine learning models, deep learning models, text semantic models, code semantic models, configuration semantic models, or multimodal fusion models; the change semantic recognition model uses Kubernetes resource object differences, Helm Charts, etc. The input consists of at least one of the following: differences, configuration file differences, code commit differences, release form descriptions, and historical incident texts. The output includes change semantic operators, runtime impact types, key observation indicators, and risk propagation directions. The change semantic fingerprint includes the change object, change field, field change magnitude, change direction, associated service, business level, change semantic operators, and runtime impact types. The change semantic operators include at least one of the following: resource shrinkage operator, resource amplification operator, traffic migration operator, timeout shrinkage operator, timeout relaxation operator, retry amplification operator, retry shrinkage operator, rate limiting threshold shrinkage operator, rate limiting threshold relaxation operator, circuit breaker threshold shrinkage operator, circuit breaker threshold relaxation operator, connection pool amplification operator, connection pool shrinkage operator, elastic capacity shrinkage operator, elastic capacity amplification operator, configuration semantic replacement operator, and application version replacement operator. The change-sensitive causal propagation graph includes service nodes, resource nodes, call edges, shared resource edges, traffic migration edges, retry relationships, timeout relationships, circuit breaker relationships, rate limiting relationships, and service level target weights.

4. The cloud-native canary release governance and control method based on any one of claims 1-3, characterized in that, The impact amplification coefficient is calculated based on at least one of the following: call traffic percentage, business level, service level target weight, dependency path length, synchronous call ratio, retry amplification factor, downstream resource level, historical similar change failure rate, current error budget status, and propagation coefficient output by the propagation risk prediction model; the calculation formula for the impact amplification coefficient Amp is as follows: Amp = Σp [ PathWeight(p) × OperatorWeight(op) × TrafficRatio(p) × SLOWeight(p) × BusinessWeight(p) × RetryFactor(p) × ResourcePressure(p) ×ContextRisk(p) × EdgePropagationCoef(p) × Decay(p) ] Where: p represents the propagation path; PathWeight(p) represents the propagation path weight; OperatorWeight(op) represents the weight of the change semantic operator; TrafficRatio(p) represents the path traffic ratio; SLOWeight(p) represents the service level target weight on the path; BusinessWeight(p) represents the business level weight; RetryFactor(p) represents the retry amplification factor; ResourcePressure(p) represents the resource pressure coefficient; ContextRisk(p) represents the current running context risk; EdgePropagationCoef(p) represents the edge propagation coefficient output by the propagation risk prediction model; Decay(p) represents the path length decay coefficient.

5. The cloud-native canary release governance and control method based on claim 4, characterized in that, The historical risk is calculated based on change semantic fingerprint similarity, change semantic operator similarity, dependency topology similarity, runtime context similarity, historical release results, and time decay coefficient. Runtime context similarity includes at least one of traffic pattern similarity, error budget state similarity, resource level similarity, and business peak / valley state similarity. The formula for calculating the historical risk HistoryRisk is as follows: HistoryRisk = Σi OutcomeRisk(i) × FingerprintSim(i) × OperatorSim(i) × TopologySim(i) × RuntimeContextSim(i) × BudgetSim(i) × TimeDecay(i) Where: OutcomeRisk(i) represents the risk of the release result of the i-th historical similar change; FingerprintSim(i) represents the change fingerprint similarity; OperatorSim(i) represents the change semantic operator similarity; TopologySim(i) represents the topological similarity; RuntimeContextSim(i) represents the runtime context similarity; BudgetSim(i) represents the error budget state similarity; TimeDecay(i) represents the time decay coefficient.

6. The cloud-native canary release governance and control method based on claim 5, characterized in that, The budget consumption prediction model predicts the error rate, latency distribution, downstream call error rate, error budget consumption rate, and service level target default probability within a future time window for multiple candidate gray-scale strategies; the error budget consumption amount PredictedBudgetCost(G) is calculated as follows: PredictedBudgetCost(G)=Σt [Traffic(t)×GrayRatio(t)×PredictedErrorIncrement(t)×Amp×ObservationWindow(t)×BudgetWeight(t) ] Where: G represents the candidate grayscale strategy; Traffic(t) represents the number of requests within the time window t; GrayRatio(t) represents the proportion of grayscale traffic; PredictedErrorIncrement(t) represents the prediction error rate increment; Amp represents the impact amplification coefficient; ObservationWindow(t) represents the observation window length; BudgetWeight(t) represents the service level target budget weight. The service level target default probability ViolationProb(G) is output as follows: ViolationProb(G)=F(G,Amp,HistoryRisk,RuntimeState,BudgetRemaining,BudgetBurnRate, BusinessPeakState) Where: F is the budget consumption prediction model or rule model; G represents the candidate grayscale strategy; Amp represents the impact amplification coefficient; HistoryRisk represents historical risk; RuntimeState represents the runtime state; BudgetRemaining represents the remaining safety envelope range; BudgetBurnRate represents the allowed explosion radius; and BusinessPeakState represents the optimal state with minimum cost.

7. The cloud-native canary release governance and control method based on claim 6, characterized in that, The error budget safety envelope employs a release state machine with a hysteresis interval, setting pause and recovery thresholds. Canary releases are only allowed to continue after the recovery conditions are met for multiple consecutive sampling periods. Specifically, this is achieved by calculating the predicted error budget consumption based on the canary traffic ratio, observation window, service request volume, expected error rate increment, service level target budget weight, and impact amplification coefficient. This predicted error budget consumption is ensured to not exceed the product of the remaining error budget and the safety factor. Ensure that the service level target default probability does not exceed a preset default probability threshold; The overall risk is kept below a preset overall risk threshold; the maximum allowable grayscale traffic ratio, the initial grayscale traffic ratio, the single-batch grayscale growth ratio, and the observation window are determined based on candidate grayscale strategies that meet the constraints; the error budget safety envelope is defined as a set of candidate grayscale strategies that meet the following constraints: Envelope = { G |PredictedBudgetCost(G) ≤ RemainingBudget ×SafetyFactor, ViolationProb(G) ≤ ViolationThreshold, RiskScore(G) ≤ RiskThreshold, GrayRatio_first(G) ≤ FirstRatioLimit, GrayRatio_max(G) ≤ MaxRatioLimit, StepRatio(G) ≤ StepRatioLimit} Where: PredictedBudgetCost(G) represents the projected budget; RemainingBudget represents the remaining error budget; SafetyFactor represents the safety factor; ViolationProb(G) represents the default ratio; ViolationThreshold represents the service level target default probability threshold; RiskScore(G) represents the risk factor; RiskThreshold represents the comprehensive risk threshold; GrayRatio_first(G) represents the initial grayscale release range percentage; FirstRatioLimit represents the upper limit of the initial grayscale ratio; GrayRatio_max(G) represents the maximum grayscale release ratio; MaxRatioLimit represents the upper limit of the maximum grayscale ratio; StepRatio(G) represents the single-batch growth ratio; StepRatioLimit represents the upper limit of the single-batch growth ratio; the comprehensive risk RiskScore(G) is calculated as follows: RiskScore(G) = α × Normalize(Amp) + β × Normalize(HistoryRisk) + γ × Normalize(PredictedBudgetCost(G)) + δ × Normalize(ViolationProb(G)) + ε × Normalize(RuntimePressure) Where α, β, γ, δ, and ε are weighting coefficients, and RuntimePressure represents the current operating pressure.

8. The cloud-native canary release governance and control method based on claim 7, characterized in that, The matching score MatchScore(g,s) between the grayscale instance g and the stable instance s is calculated as follows: MatchScore(g,s) = w1 × ClusterSim(g,s) + w2 × AZSim(g,s) + w3 × NodeLoadSim(g,s) + w4 × PodSpecSim(g,s) + w5 × TrafficSourceSim(g,s) + w6 × DependencyPathSim(g,s) + w7 × BusinessLabelSim(g,s) Select the stable instance with the highest matching score and meeting the minimum matching threshold as the control instance for the grayscale instance; calculate the differential observation index between the grayscale instance and the matching stable instance; the differential observation index includes at least one of the following: error rate difference, P95 latency difference, P99 latency difference, CPU Throttling difference, memory usage difference, container restart count difference, downstream error rate difference, queue length difference, connection pool usage difference, retries count difference, circuit breaker count difference, rate limiting count difference, and error budget consumption rate difference; calculate the differential risk state DiffRisk based on the differential observation index: DiffRisk = a1 × Normalize(DiffErrorRate) + a2 × Normalize(DiffP99) + a3 × Normalize(DiffBudgetBurn) + a4 × Normalize(DiffCPUThrottle) + a5 × Normalize(DiffDownstreamError) + a6 × Normalize(DiffRetry) Where: a1 to a6 are the indicator weights; DiffErrorRate represents the error rate difference between gray-scale instances and matching stable instances; DiffP9 represents the P99 latency difference between gray-scale instances and matching stable instances; DiffBudgetBurn represents the error budget consumption rate difference between gray-scale instances and matching stable instances; DiffCPUThrottle represents the CPU throttling difference between gray-scale instances and matching stable instances; DiffDownstreamError represents the downstream error rate difference between gray-scale instances and matching stable instances; and DiffRetry represents the retry count difference between gray-scale instances and matching stable instances.

9. The cloud-native canary release governance and control method based on claim 8, characterized in that, The release access control policy includes at least one of the following: allow release, prohibit release, limit release time window, require manual approval, limit the initial gray-scale traffic ratio, limit the maximum gray-scale traffic ratio, limit the single batch gray-scale growth ratio, increase the number of gray-scale batches, extend the observation window, specify service indicators that must be observed, specify interfaces that must be observed, set pause conditions, set recovery conditions, set termination conditions, set rollback trigger conditions, or restrict parallel release with other changes.

10. A cloud-native canary release governance and control system, characterized in that, It includes data collection modules connected in sequence for collecting service metric data, log data, tracing data, Kubernetes resource configuration data, service mesh telemetry data, service dependency data, shared resource relationship data, historical change records, historical release results, alarm records, service level target data, and error budget data in the cloud-native environment; A change semantic recognition module is used to obtain configuration differences, code differences, resource object differences, or release descriptions of changes to be performed, and to generate change semantic fingerprints through a change semantic recognition model; a causal propagation graph construction module is used to construct change-sensitive causal propagation graphs based on service dependency data, service mesh telemetry data, and shared resource relationship data; A propagation risk prediction module for predicting risk propagation coefficients, key propagation paths, and impact amplification coefficients based on change semantic fingerprints, change semantic operators, and change-sensitive causal propagation graphs; A historical risk calculation module for encoding changes to be executed into change vectors and retrieving similar historical changes from the historical change library based on the change vectors to calculate historical risks; and a consumption prediction module for predicting the erroneous budget consumption and service level target default probability budget under different candidate grayscale strategies. A security envelope solving module for calculating the security envelope of the erroneous budget based on the erroneous budget consumption and the probability of default for service level objectives; and an access control policy generation module for generating and publishing access control policies based on the security envelope of the erroneous budget. A canary release control module for distributing release access control policies to at least one of the following: release pipeline, service mesh control plane, Kubernetes controller, or canary release executor; This module is used to build gray-scale-stable paired observation groups and calculate differential observation metrics during the gray-scale release execution process. A release strategy optimization module used to output subsequent release actions based on differential observation indicators, differential risk status, and real-time error budget consumption rate; A hysteresis state machine control module for executing subsequent release actions through a release state machine constrained by an error budget safety envelope and having a hysteresis interval; an audit feedback module for generating change risk audit records and writing the change risk audit records into a historical change database for updating at least one of a change semantic recognition model, a propagation risk prediction model, a budget consumption prediction model, or a release strategy optimization model; the system is connected to at least one of a release pipeline, a service mesh control plane, a Kubernetes controller, a canary release executor, a monitoring system, an alarm system, a service level target management system, and a historical change database.

Images