A software product automatic adaptation deployment method and system

Abstract

The application discloses a kind of software product automatic adaptation deployment method and system, it is related to software deployment technical field.The method comprises the following steps: S1, the software version data of distributed deployment node, configuration state data, deployment execution data and running state data are collected in real time, and preprocessed;S2, obtain target software version set, target configuration template, target deployment step set and running reference state;The running deterioration degree of deployment node and the deployment consistency degree are evaluated, the abnormal deployment node is judged, and the abnormal type is identified;S3, the adaptive deployment correction scheme corresponding to abnormal type is generated;S4, the correction feedback and closed-loop correction are executed to abnormal deployment node, and the correction result is judged, continue to correct, restore mark and failure disposal are completed.The problems that the difference between deployment nodes in distributed deployment scene is difficult to be quantified in real time and local abnormal nodes are easily covered by overall normal state are solved.

Description

Technical Field

[0001] This invention relates to the field of software deployment technology, specifically to a method and system for automatic adaptation and deployment of software products. Background Technology

[0002] With the development of cloud computing, microservices, containerized orchestration, and continuous delivery technologies, distributed software deployment has been widely applied in various internet information service platforms. These platforms typically rely on multi-node, distributed computing resources for deployment and operation, involving multiple stages such as software artifact distribution, configuration loading, process execution, service startup, and operational monitoring. A related technical system has gradually formed around distributed deployment management, node status monitoring, operational evaluation, and service maintenance.

[0003] For example, Chinese patent CN114564217A discloses a software deployment method and apparatus. The method includes: obtaining the code of a target software using a continuous integration tool; compiling the code of the target software using the continuous integration tool to obtain a program package of the target software; executing a local shell script of the target software using the continuous integration tool to generate a configuration file of the target software, and mounting the configuration file to an Nginx instance in a Docker cluster, so that Nginx can proxy and forward the target software according to the configuration file; and deploying the program package to the Docker cluster using the continuous integration tool. The software deployment method provided in this application can improve the efficiency of deploying software testing environments and reduce the probability of errors caused by manual operation.

[0004] For example, Chinese patent CN121785619A discloses a software intelligent deployment system, comprising: a context management module for establishing a context during business software deployment and terminating the context after deployment; an instruction tracing module for tracking all installation package commands and source code compilation processes, and collecting and recording all instruction data executed within the context; an instruction learning module for sending instruction data to an external large model for processing and obtaining an instruction stream; an instruction archiving module for combining the instruction stream with context information to form a configuration list, saving it to a deployment database, and then uploading it to the cloud; and a deployment search module for retrieving available configuration lists from the deployment database based on business software deployment commands and performing deployment operations according to the instructions in the configuration list. This application, through learning and archiving deployment instructions, achieves direct reuse of deployment knowledge and automated generation and optimization of instruction streams, reducing reliance on manual scripts and reducing costs.

[0005] However, in distributed deployment scenarios, different deployment nodes may have inconsistent software versions or configurations due to factors such as network fluctuations, execution failures, and configuration differences. Existing systems often rely on manual inspections or simple verifications, which cannot quantify the degree of difference between deployment nodes in real time. This can lead to some deployment nodes operating abnormally while the overall system is still misjudged as normal, thus affecting the collaborative operation of the system and data consistency.

[0006] Therefore, in response to the above problems, there is an urgent need for a method and system for automatic adaptation and deployment of software products. Summary of the Invention

[0007] Technical problems to be solved

[0008] To address the shortcomings of existing technologies, this invention provides a method and system for automatic adaptation and deployment of software products, which solves the problems of difficulty in real-time quantification of differences between deployment nodes and the easy masking of local abnormal nodes by the overall normal state in distributed deployment scenarios.

[0009] Technical solution

[0010] To achieve the above objectives, the present invention provides the following technical solution: an automatic adaptation and deployment method for software products, comprising the following steps: S1, real-time collection of software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes, and performing correlation, alignment, deduplication, and normalization processing to form a node status dataset; S2, acquisition of a target software version set, a target configuration template, and a target deployment step set, and construction of a running reference state based on the running status data of historical healthy deployment nodes; assessment of the running degradation degree of deployment nodes based on the running reference state; analysis of the deployment consistency degree of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determination of node consistency deviation based on the deployment consistency degree and running degradation degree; determination of abnormal deployment nodes and identification of abnormality types based on node consistency deviation; S3, generation of corresponding adaptive deployment correction schemes based on the abnormality type determination of abnormal deployment nodes; S4, execution of correction feedback and closed-loop correction on abnormal deployment nodes based on the adaptive deployment correction scheme, determination of correction results, and completion of continued correction, recovery marking, and failure handling based on the correction results.

[0011] Furthermore, the specific process of collecting software version data, configuration status data, deployment execution data, and runtime status data of distributed deployment nodes in real time, and performing correlation, alignment, deduplication, and normalization processing to form a node status dataset is as follows: Real-time collection of software version data, configuration status data, deployment execution data, and runtime status data of distributed deployment nodes; Software version data includes: software installation package version number, image digest value, and dependent component version number; configuration status data includes: configuration file hash value, environment variable value, startup parameter value, and key configuration item value; deployment execution data includes: deployment step name, step execution result, step return code, step retries, and step execution time; runtime status data includes: service process status, port listening status, node heartbeat time sequence, service interface response latency sequence, and sliding window latency. The system counts error log entries within a time window; it associates software version data, configuration status data, deployment execution data, and runtime status data of the same deployment node using the unique identifier of the deployment node as an index to form the original node dataset for the corresponding deployment node; it aligns the node heartbeat time series of the deployment nodes with timestamps according to a unified clock reference and calculates the heartbeat time interval sequence; it unifies the field formats of the software version data, configuration status data, deployment execution data, and runtime status data of the deployment nodes; it generates missing data markers when missing data items exist; when the same data item of the same deployment node has more than one record at the same collection time, it retains only the most recently written valid record; and it establishes a software deployment database to store the original and preprocessed software version data, configuration status data, deployment execution data, and runtime status data of the deployment nodes.

[0012] Further, the specific process of obtaining the target software version set, target configuration template, and target deployment step set, and constructing the operational reference state by combining them with the historical operational status data of healthy deployment nodes, is as follows: Read the target software version set, target configuration template, and target deployment step set corresponding to the current deployment task; wherein, the target software version set includes the target software installation package version number, target image digest value, and target dependent component version number corresponding to the current deployment task; the target configuration template includes the target configuration file hash value, target environment variable value, target startup parameter value, and target key configuration item value; the target deployment step set includes the target deployment step name corresponding to the current deployment task; count the heartbeat interval sequence, service interface response latency sequence, and number of error log entries within the sliding time window corresponding to the healthy deployment nodes of historical deployment tasks, and take the median of each to obtain the reference median heartbeat interval, reference median response latency, and reference median number of error log entries, forming the operational reference state set.

[0013] Furthermore, the specific process for assessing the operational degradation of deployment nodes based on the operational reference state is as follows: For each deployment node, obtain the heartbeat time interval sequence of the deployment node and take the median to obtain the median heartbeat interval; obtain the service interface response latency sequence of the deployment node and take the median to obtain the median response latency; count the number of error log entries within the sliding time window of the deployment node and take the median to obtain the median number of error log entries; calculate the difference between the median heartbeat interval and the reference median heartbeat interval, and compare the difference with zero to obtain the maximum value to obtain the heartbeat degradation difference; calculate the difference between the median response latency and the reference median response latency, and compare the difference with zero to obtain the maximum value. The largest value is used to obtain the response latency degradation difference; the difference between the median number of error log entries and the reference median number of error log entries is calculated, and the difference is compared with zero to obtain the maximum value, which is the error log degradation difference; the heartbeat degradation difference is divided by the sum of the reference median heartbeat interval and the smallest positive number, the response latency degradation difference is divided by the sum of the reference median response latency and the smallest positive number, and the error log degradation difference is divided by the sum of the reference median number of error log entries and one, respectively, to obtain the response latency degradation ratio, the heartbeat degradation ratio, and the error log degradation ratio; the sum of squares of the response latency degradation ratio, the heartbeat degradation ratio, and the error log degradation ratio is calculated, and the square root is taken to obtain the operational degradation amount of the deployed node.

[0014] Furthermore, based on the target software version set, target configuration template, and target deployment step set, the deployment consistency of deployment nodes is analyzed. The specific process for determining node consistency deviations, combining deployment consistency and operational degradation, is as follows: For each deployment node, the software installation package version number, image digest value, and dependent component version number of the deployment node are compared with the corresponding items in the target software version set. When the corresponding items are inconsistent, it is recorded as a software version anomaly. The number of software version anomalies for the deployment node is counted, and the total number of software version data items participating in the comparison is also counted. The configuration file hash value, environment variable value, startup parameter value, and key configuration item value of the deployment node are compared with the corresponding items in the target configuration template. When the corresponding items are inconsistent, it is recorded as a configuration anomaly. The number of configuration anomalies for the deployment node is counted, and the total number of configuration data items participating in the comparison is also counted. The deployment step name of the deployment node is compared with the target deployment step name in the target deployment step set. Matching is performed, and when any of the following occurs: a target deployment step is missing, the execution result of a deployment step fails, the step returns an abnormal return code, the number of retry attempts is greater than zero, or the execution time of a step exceeds a time threshold, the corresponding deployment step is recorded as a deployment step exception. The number of deployment step exceptions for each deployment node is counted, and the total number of deployment steps participating in the comparison is also counted. The number of software version exceptions is divided by the sum of the total number of software version data items and the smallest positive number to obtain the software version deviation ratio. The number of configuration exceptions is divided by the sum of the total number of configuration data items and the smallest positive number to obtain the configuration deviation ratio. The number of deployment step exceptions is divided by the sum of the total number of deployment steps and the smallest positive number to obtain the deployment step exception ratio. The runtime degradation is incremented by one and the natural logarithm is taken to obtain the runtime degradation mapping value. The sum of squares of the software version deviation ratio, configuration deviation ratio, deployment step exception ratio, and runtime degradation mapping value is calculated, and the square root of the sum of squares is taken to obtain the consistency deviation value of the deployment node.

[0015] Furthermore, the specific process for determining abnormal deployment nodes and identifying anomaly types based on node consistency deviation is as follows: The consistency deviation value of the deployment node is compared with a deviation threshold. When the consistency deviation value is less than the deviation threshold, the deployment node is marked as a healthy deployment node; when the consistency deviation value is greater than or equal to the deviation threshold, the deployment node is marked as an abnormal deployment node. For abnormal deployment nodes, four deviation items—software version deviation ratio, configuration deviation ratio, deployment step anomaly ratio, and operational degradation mapping value—are compared with their corresponding anomaly thresholds to identify the anomaly type: If the software version deviation ratio is greater than or equal to the version anomaly threshold, it is marked as a software version deviation anomaly; if the configuration deviation ratio is greater than or equal to the configuration anomaly threshold, it is marked as a configuration deviation anomaly; if the deployment step anomaly ratio is greater than or equal to the deployment execution anomaly threshold, it is marked as a deployment execution deviation anomaly; if the operational degradation mapping value is greater than or equal to the operational anomaly threshold, it is marked as an operational degradation anomaly. The unique identifier of the deployment node, software version deviation ratio, configuration deviation ratio, deployment step anomaly ratio, operational degradation mapping value, consistency deviation value, node label, and anomaly type are associated to generate a deviation evaluation record for the corresponding deployment node and write it to the software deployment database.

[0016] Furthermore, based on the anomaly type of the abnormal deployment node, the specific process for generating the corresponding adaptive deployment correction plan is as follows: Read the deviation assessment record of the abnormal deployment node; for software version deviation anomalies, generate a software version correction plan, including: re-deploying the software installation package corresponding to the target software installation package version number, re-pulling the image content corresponding to the target image digest value, and reinstalling the dependent components corresponding to the target dependent component version number; for configuration deviation anomalies, generate a configuration correction plan, including: re-deploying the configuration file content corresponding to the target configuration template, rewriting the target environment variable values, rewriting the target startup parameter values, and rewriting the target key configuration item values; for deployment execution deviation anomalies, generate a deployment execution correction plan, including: performing supplementary execution of missing target deployment steps, retrying deployment steps whose execution results are failed, and re-executing steps... Deployment steps with abnormal return codes are re-invoked; deployment steps with a retry count greater than zero are re-verified; and deployment steps with execution time exceeding a threshold are rescheduled. For operational deterioration anomalies, operational correction plans are generated, including: restarting the service process when its state is abnormal; rebinding the port when its listening state is abnormal; restoring node connections when the median heartbeat interval is greater than the reference median heartbeat interval; reconfiguring service resource parameters when the median response latency is greater than the reference median response latency; and cleaning up the process corresponding to the abnormal logs when the median number of error log entries is greater than the reference median number of error log entries. The consistency deviation values ​​of abnormal deployment nodes are sorted in descending order to generate correction priorities for abnormal deployment nodes, and the corresponding correction plans are converted into executable correction instruction sets based on the anomaly types present in the abnormal deployment nodes.

[0017] Furthermore, the specific process for performing correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme, and determining the correction results, is as follows: According to the correction priority order of abnormal deployment nodes, executable correction instruction sets are sent to the corresponding abnormal deployment nodes, triggering them to perform correction; after the abnormal deployment node completes the correction, software version data, configuration status data, deployment execution data, and running status data are re-collected, and the corresponding consistency deviation value is calculated to obtain the corrected consistency deviation value; when the corrected consistency deviation value is less than the deviation threshold, the abnormal deployment node is re-marked as a healthy deployment node; when the corrected consistency deviation value is greater than or equal to the deviation threshold, and less than the original consistency deviation value, the abnormal deployment node is marked as a node awaiting further correction; when the corrected consistency deviation value is greater than or equal to the deviation threshold, and greater than or equal to the original consistency deviation value, the abnormal deployment node is marked as a correction failure node.

[0018] Furthermore, the specific process for completing the continued correction, restoration marking, and failure handling based on the correction results is as follows: For nodes to be corrected, read the latest deviation assessment record, determine the latest anomaly type, and regenerate the corresponding correction plan and executable correction instruction set for the nodes to be corrected; for nodes that fail to be corrected, roll back the software version status and configuration status of the nodes that fail to be corrected to the previous version; remove the nodes that fail to be corrected from the load balancer forwarding object and stop issuing new deployment scheduling tasks to the nodes that fail to be corrected; generate an alarm work order for the nodes that fail to be corrected, and attach the deviation assessment record and correction log of the nodes that fail to be corrected to the alarm work order.

[0019] The second aspect of this invention provides an automatic adaptation and deployment system for software products, comprising: a node data acquisition and processing module, used to collect software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes in real time, and perform correlation, alignment, deduplication, and normalization processing to form a node status dataset; a consistency deviation assessment module, used to obtain a target software version set, a target configuration template, and a target deployment step set, and construct a running reference state by combining the running status data of historical healthy deployment nodes; assess the running degradation degree of deployment nodes based on the running reference state; analyze the deployment consistency degree of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determine the node consistency deviation by combining the deployment consistency degree and the running degradation degree; determine abnormal deployment nodes and identify the abnormality type based on the node consistency deviation; an adaptive deployment correction module, used to generate a corresponding adaptive deployment correction scheme based on the abnormality type determination of the abnormal deployment nodes; and an execution feedback correction module, used to perform correction feedback and closed-loop correction on the abnormal deployment nodes according to the adaptive deployment correction scheme, determine the correction result, and complete continued correction, recovery marking, and failure handling based on the correction result.

[0020] Beneficial effects

[0021] The present invention has the following beneficial effects:

[0022] (1) This invention, by jointly collecting and associating software version data, configuration status data, deployment execution data and running status data, and combining the degree of running degradation and the degree of deployment consistency to comprehensively determine the node consistency deviation, can more comprehensively identify the differences between distributed deployment nodes and improve the accuracy and pertinence of abnormal deployment node identification.

[0023] (2) By identifying the software version deviation ratio, configuration deviation ratio, deployment step abnormal ratio and operation deterioration mapping value respectively, the present invention can classify and distinguish version deviation, configuration deviation, deployment execution deviation and operation deterioration abnormality, thereby improving the refinement of the abnormality cause judgment and enhancing the matching between subsequent correction actions and abnormality types.

[0024] (3) The present invention generates corresponding software version correction schemes, configuration correction schemes, deployment execution correction schemes and running correction schemes according to the anomaly type, and forms correction priorities by combining the consistency deviation value of the abnormal deployment node. It can realize differentiated and adaptive correction for abnormal nodes, and improve the orderliness of the correction process and the efficiency of anomaly recovery.

[0025] (4) This invention, by re-collecting relevant data after the correction is completed and determining the consistency deviation value again, and combining the results classification of healthy deployment nodes, nodes to be corrected and nodes that failed to be corrected, can form a correction feedback and closed-loop correction mechanism, thereby improving the continuous correction capability, node collaborative operation capability and data consistency guarantee capability in the distributed deployment process.

[0026] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0027] Figure 1 A flowchart illustrating an automated adaptation and deployment method for a software product.

[0028] Figure 2 A diagram of the architecture of an automatic adaptation and deployment system for a software product;

[0029] Figure 3 A diagram illustrating the consistency deviation values ​​and distribution of each component for deployment nodes;

[0030] Figure 4 This is a schematic diagram illustrating the workflow of an automatic adaptation and deployment method for a software product. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. As those skilled in the art will understand, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0032] Please see Figures 1-4 This invention provides a technical solution: an automatic adaptation and deployment method for software products, such as... Figure 1As shown, the process includes the following steps: S1, real-time collection of software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes, followed by correlation, alignment, deduplication, and normalization to form a node status dataset; S2, acquisition of the target software version set, target configuration template, and target deployment step set, combined with historical running status data of healthy deployment nodes to construct a running reference state; assessment of the running degradation degree of deployment nodes based on the running reference state; analysis of the deployment consistency degree of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determination of node consistency deviation based on the deployment consistency degree and running degradation degree; identification of abnormal deployment nodes and identification of abnormality types based on node consistency deviation; S3, generation of corresponding adaptive deployment correction schemes based on the abnormality type determination of abnormal deployment nodes; S4, execution of correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme, determination of correction results, and completion of continued correction, recovery marking, and failure handling based on the correction results.

[0033] Specifically, the process of real-time collection of software version data, configuration status data, deployment execution data, and runtime status data from distributed deployment nodes, followed by correlation, alignment, deduplication, and normalization to form a node status dataset, is as follows: Real-time collection of software version data, configuration status data, deployment execution data, and runtime status data from distributed deployment nodes; distributed deployment nodes are server nodes, virtual machine nodes, container host nodes, or other computing resource units capable of independently executing deployment tasks and participating in the current deployment task to run the target software; real-time collection can be achieved through deployment agents, configuration collection interfaces, log collection interfaces, process status detection interfaces, port listening detection interfaces, and service probe interfaces to ensure that all types of data have clear data sources and repeatable acquisition paths. The software version data includes: software installation package version number, image digest value, and dependent component version number; the software installation package version number is obtained by reading the local installation package metadata of the deployment node; the image digest value is obtained by reading the local cache information of the container image; and the dependent component version number is obtained by reading the dependency manifest file of the deployment node. All of the above software version data are used to characterize the current actual loaded software main version and dependent version status of the deployment node. Configuration status data includes: configuration file hash value, environment variable values, startup parameter values, and key configuration item values. The configuration file hash value is obtained by reading the content of the currently effective configuration file on the deployment node and performing a hash calculation. Environment variable values ​​are obtained by reading the environment variable table of the current running environment of the deployment node. Startup parameter values ​​are obtained from the process startup parameter list. Key configuration item values ​​are obtained by parsing the currently effective configuration file. This configuration status data characterizes the actual effective configuration status of the deployment node. Deployment execution data includes: deployment step name, step execution result, step return code, number of retries, and step execution time. The deployment step name is obtained by reading the current deployment orchestration process record. The step execution result is obtained by reading the deployment script execution result. The step return code is obtained by reading the step execution command exit code. The number of retries is obtained by reading the retry record of the task scheduler. The step execution time is obtained by recording the start and end times of the step and calculating the difference between them. This deployment execution data characterizes the actual execution status of the deployment node during the deployment process.The operational status data includes: service process status, port listening status, node heartbeat time series, service interface response latency sequence, and the number of error log entries within the sliding time window. Specifically, the service process status is obtained by reading the process list; the port listening status is obtained by reading port occupancy information; the node heartbeat time series is obtained by receiving periodically reported heartbeat records from the deployment node and saving the corresponding reporting time; the service interface response latency sequence is obtained by initiating multiple access requests to the service interface within a preset observation period and recording the response time for each request; and the number of error log entries within the sliding time window is obtained by reading and counting error-level log records generated by the deployment node within the current preset sliding statistical window. This operational status data is used to characterize the actual operational status of the deployment node after deployment is completed. Using the unique identifier of the deployment node as an index, which is composed of a node number, software version data, configuration status data, deployment execution data, and running status data of the same deployment node are associated. The association process includes: merging data records with the same unique identifier of the deployment node into the same node record set, and organizing them into a raw node dataset according to the collection time, so as to ensure that data from different collection sources for the same deployment node can correspond to the same analysis object, forming the raw node dataset of the corresponding deployment node. The node heartbeat time series of the deployment node is timestamped according to a unified clock reference, and the heartbeat time interval sequence is calculated. Each heartbeat record in the node heartbeat time series carries the corresponding reporting time. The unified clock reference preferably adopts the time of a standard time server. The timestamp alignment is to uniformly convert the heartbeat times recorded from different sources and different local clocks to the same time reference. The heartbeat time interval sequence is obtained by calculating the difference between two adjacent heartbeat reporting times, which is used to characterize the online continuity and communication stability of the deployment node. The software version data, configuration status data, deployment execution data, and runtime status data of deployment nodes are standardized in terms of field format. This standardization includes: unifying the software installation package version number, image digest value, and dependent component version number into a comparable version field format; unifying the configuration file hash value into a fixed-length digest field format; unifying the environment variable values, startup parameter values, and key configuration item values ​​into a standard key-value pair format; unifying the step execution results, service process status, and port listening status into a preset status identifier format; unifying the step execution time and service interface response latency into a unified time unit format; and unifying the number of error log entries into an integer count field format. This ensures the parsingability and consistency of fields during subsequent comparisons. When missing data items exist, a missing data marker is generated. Missing data items include version fields, configuration fields, deployment execution fields, or runtime status fields that were not acquired within the current collection period. The missing data marker must include at least the missing field name, the unique identifier of the deployment node, and the corresponding collection period information to clearly distinguish between situations where "the field value is normally zero" and "the field was not collected."When more than one record exists for the same data item on the same deployment node at the same acquisition time, only the most recently written valid record is retained. The same acquisition time refers to acquisition times with the same timestamp after conversion according to a unified clock reference. "Most recently written" is determined by the order in which data is written to the original node dataset, preferably by the timestamp. When multiple records exist, they are sorted according to their writing order, and the record written last with complete fields and a valid format is retained as a valid record; the remaining records are marked as duplicates. A software deployment database is established to store the original and preprocessed software version data, configuration status data, deployment execution data, and running status data of the deployment nodes to support the construction of running reference states, node consistency deviation analysis, anomaly identification, correction scheme generation, and closed-loop correction.

[0034] In this implementation scheme, by jointly collecting and standardizing the software version, configuration status, deployment execution, and running status of distributed deployment nodes, and combining the running reference status to comprehensively determine the degree of node deterioration and deployment consistency, abnormal deployment nodes and their abnormality types can be identified more accurately, and corresponding adaptive correction schemes can be generated. At the same time, through correction feedback and closed-loop correction mechanisms, abnormal nodes can be continuously corrected, restored, and failure handled, thereby improving the consistency of software deployment, the accuracy of anomaly identification, and the stability of node collaborative operation in distributed deployment scenarios.

[0035] Specifically, the process of obtaining the target software version set, target configuration template, and target deployment step set, and constructing the operational reference state by combining them with the operational status data of historical healthy deployment nodes, is as follows: Read the target software version set, target configuration template, and target deployment step set corresponding to the current deployment task; the current deployment task is the software deployment task to be executed; the target software version set, target configuration template, and target deployment step set are preferably generated and written by the deployment orchestration system when the deployment task is created; the target software version set is used to characterize the main software version state required by the current deployment task, the target configuration template is used to characterize the configuration state required by the current deployment task, and the target deployment step set is used to characterize the standard deployment process required by the current deployment task. The target software version set includes the target software installation package version number, target image digest value, and target dependent component version number corresponding to the current deployment task; the target software installation package version number characterizes the target version of the main target software program, the target image digest value characterizes the unique identifier of the target image content, and the target dependent component version number characterizes the target version of the dependent components required to be installed and loaded by the current deployment task. The target configuration template includes the target configuration file hash value, target environment variable values, target startup parameter values, and target key configuration item values. The target configuration file hash value represents the target consistency status of the target configuration file content. The target environment variable values ​​represent the environment variable status that the target runtime environment should have. The target startup parameter values ​​represent the parameter status that should be loaded when the target software starts, such as port parameters, concurrency parameters, and log parameters. The target key configuration item values ​​represent the key configuration status that affects the target software's running results, such as database configuration items, cache configuration items, and service address configuration items. The target deployment step set includes the target deployment step name corresponding to the current deployment task. The target deployment step name is a predefined standard deployment step identifier in the current deployment task, such as pulling software artifacts, verifying dependent components, distributing configuration files, writing startup parameters, starting the target service, and other steps, which are used as a benchmark for subsequent deployment execution consistency comparisons. The heartbeat interval sequence, service interface response latency sequence, and error log entry count sequence of healthy deployment nodes corresponding to historical deployment tasks are statistically analyzed. The median of each sequence is then used to obtain the reference median heartbeat interval, reference median response latency, and reference median error log entry count, forming a runtime reference state set. Historical healthy deployment nodes are those marked as healthy deployment nodes in historical deployment tasks after consistency deviation assessment. The historical sample preferably selects healthy deployment nodes from historical deployment tasks with the same or similar software type and node resource specifications as the current deployment task. Preferably, these are historical healthy deployment nodes within the most recent preset time range. The number of historical samples is determined based on the statistical stability required for constructing the runtime reference state, and the preset minimum sample size is preferably between 5 and 20.The operational reference state set includes three reference metrics: median heartbeat interval, median response latency, and median number of error log entries. These metrics correspond one-to-one with the three operational metrics used in the subsequent operational degradation assessment process. The operational reference state set characterizes the baseline performance of historically healthy deployed nodes under stable operating conditions. When assessing the operational degradation of the current deployed node, the median heartbeat interval, median response latency, and median number of error log entries are compared to the median reference heartbeat interval, median response latency, and median number of error log entries, respectively. This ensures a clear one-to-one correspondence between the reference metrics in the operational reference state set and the operational status assessment metrics of the current deployed node.

[0036] In this implementation plan, by pre-acquiring the target software version set, target configuration template, and target deployment step set, and combining them with the running status data of historical healthy deployment nodes to construct a running reference state, a clear version baseline, configuration baseline, step baseline, and running baseline can be provided for the current deployment task. This ensures that subsequent comparisons of the software body status, configuration status, deployment execution status, and running status of deployment nodes have a unified reference. At the same time, by mapping the reference median heartbeat interval, reference median response latency, and reference median number of error log entries in the running reference state to the corresponding running indicators of the current deployment node, the accuracy and comparability of the assessment of the degree of running degradation and the determination of node consistency deviation can be improved.

[0037] Specifically, the process of assessing the operational degradation of deployed nodes based on the operational reference state is as follows: For each deployed node, the heartbeat time interval sequence of the deployed node is obtained, and the median is taken to obtain the median heartbeat interval; the heartbeat time interval sequence is obtained by arranging the difference between two adjacent heartbeat reporting times of the same deployed node in chronological order, and the heartbeat reporting times come from the heartbeat records periodically sent by the deployed node during the operation phase; taking the median of the heartbeat time interval sequence can reduce the impact of individual instantaneous network jitter, short-term blocking and single delay surges on the assessment results, so that the median heartbeat interval can better characterize the typical online continuity level of the deployed node in the current observation period. The service interface response latency sequence of the deployment node is obtained, and the median response latency is obtained by taking the median. The service interface response latency sequence is a sequence of response time records obtained by making multiple access requests to the target service interface on the deployment node within a preset observation period. The response time is obtained by recording the sending time of each interface request and the response return time and calculating the difference between the two. Taking the median of the service interface response latency sequence can reduce the impact of occasional interface timeouts, short-term congestion and single probe anomalies on the overall operation status judgment, so that the median response latency can better characterize the typical interface response performance of the current deployment node. The median number of error log entries is obtained by counting the sequence of error log entries within the sliding time window of the deployment node. The sequence of error log entries within the sliding time window is obtained by counting the error logs generated by the deployment node within the continuous sliding statistical window. The error logs are obtained by reading the log records corresponding to the preset error level identifier in the operation log and performing window counting. Taking the median of the sequence of error log entries within the sliding time window can reduce the impact of single sudden abnormal logs and instantaneous log aggregation on the evaluation results, so that the median number of error log entries can better represent the typical error activity level of the current deployment node in the continuous operation phase. The difference between the median heartbeat interval and the reference median heartbeat interval is calculated, and the maximum value of the difference is taken by comparing it with zero to obtain the heartbeat deterioration difference. The median heartbeat interval is compared with the reference median heartbeat interval to determine whether the current deployed node has deteriorated in terms of heartbeat continuity relative to the operating reference state. When the median heartbeat interval is greater than the reference median heartbeat interval, it indicates that the heartbeat reporting frequency of the current deployed node has decreased or the heartbeat interval has lengthened. In this case, the difference is taken as the heartbeat deterioration difference. When the median heartbeat interval is less than or equal to the reference median heartbeat interval, it indicates that the current deployed node has not deteriorated in this indicator. In this case, the maximum value is taken by comparing it with zero to make the heartbeat deterioration difference zero, so as to avoid the situation of being better than the reference state being mistakenly counted as abnormal.Calculate the difference between the median response delay and the reference median response delay, and compare the difference with zero, taking the maximum value to obtain the response delay degradation difference. Compare the median response delay with the reference median response delay to determine whether the current deployed node has degraded in interface response performance relative to the operating reference state. When the median response delay is greater than the reference median response delay, it indicates that the interface response of the current deployed node has slowed down, and the difference is taken as the response delay degradation difference. When the median response delay is less than or equal to the reference median response delay, it indicates that the current deployed node has not degraded in this indicator, and the response delay degradation difference is taken as zero. The difference between the median number of error log entries and the reference median number of error log entries is calculated, and the maximum value is taken by comparing the difference with zero to obtain the error log deterioration difference. The median number of error log entries is compared with the reference median number of error log entries to determine whether the current deployed node has deteriorated in terms of error log activity relative to the operating reference state. When the median number of error log entries is greater than the reference median number of error log entries, it indicates that the error output of the current deployed node has increased in the current observation period, and the difference is taken as the error log deterioration difference. When the median number of error log entries is less than or equal to the reference median number of error log entries, it indicates that the current deployed node has not deteriorated in this indicator, and the error log deterioration difference is taken as zero. The heartbeat degradation difference is divided by the sum of the reference median heartbeat interval and a minimum positive number, the response latency degradation difference is divided by the sum of the reference median response latency and a minimum positive number, and the error log degradation difference is divided by the sum of the reference median number of error log entries and one, respectively, to obtain the response latency degradation ratio, heartbeat degradation ratio, and error log degradation ratio. Dividing each degradation difference by its corresponding reference indicator converts operating indicators with different dimensions and numerical ranges into relative degradation ratios, improving the comparability between different indicators. The minimum positive number is used to avoid division by zero when the denominator is close to zero and to ensure the numerical stability of the ratio calculation process. The sum of the reference median number of error log entries and one is used to avoid the inability to calculate the relative ratio when the reference median number of error log entries is zero. After the above normalization processing, the response latency degradation ratio, heartbeat degradation ratio, and error log degradation ratio are all dimensionless proportional quantities. The sum of squares of the response latency degradation ratio, heartbeat degradation ratio, and error log degradation ratio is calculated, and the square root is taken to obtain the operating degradation amount of the deployed node. The method of summing the squares and taking the square root is used to comprehensively characterize the overall deviation of the three dimensionless degradation ratios, so that when a single degradation ratio increases abnormally, it can be reflected in the comprehensive result, while avoiding the mutual cancellation of changes with different signs and directions. Since the response delay degradation ratio, heartbeat degradation ratio, and error log degradation ratio involved in the calculation are all dimensionless ratios, the operational degradation quantity obtained by squaring, summing, and taking the square root is still a dimensionless quantity. The operational degradation quantity is used to uniformly characterize the comprehensive deterioration of the deployed node relative to the operational reference state in terms of heartbeat continuity, interface response performance, and error log activity.

[0038] In this implementation scheme, by jointly analyzing the heartbeat continuity, interface response performance, and error log activity of the deployment nodes, and constructing corresponding relative deterioration ratios for dimensionless comprehensive characterization, the overall operational degradation of the deployment nodes relative to the operational reference state can be more accurately characterized. At the same time, by adopting median statistics and normalization processing, the impact of instantaneous jitter, occasional anomalies, and dimensional differences on the evaluation results can be reduced, thereby improving the stability, comparability, and accuracy of the operational status evaluation.

[0039] Specifically, the process of analyzing the deployment consistency of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determining node consistency deviations by combining deployment consistency and operational degradation, is as follows: For each deployment node, the software installation package version number, image digest value, and dependent component version number of the deployment node are compared with the corresponding items in the target software version set. When the corresponding items are inconsistent, it is recorded as a software version anomaly. The number of software version anomalies of the deployment node is counted, and the total number of software version data items participating in the comparison is also counted. Among them, the software installation package version number, image digest value, and dependent component version number are compared one-to-one with the corresponding items in the target software version set to identify the deviation of the deployment node in terms of software main version, image content, and dependent component version. The total number of software version data items is the number of fields actually participating in the version consistency comparison of the current deployment node. The configuration file hash value, environment variable value, startup parameter value, and key configuration item value of the deployment node are compared with the corresponding items in the target configuration template. When the corresponding items are inconsistent, they are recorded as a configuration anomaly. The number of configuration anomalies of the deployment node and the total number of configuration data items participating in the comparison are counted. The configuration file hash value, environment variable value, startup parameter value, and key configuration item value are compared one-to-one with the corresponding configuration items in the target configuration template to identify deviations of the deployment node in configuration file content, runtime environment, startup control parameters, and key configuration status. The total number of configuration data items is the number of configuration fields actually participating in the configuration consistency comparison of the current deployment node. The deployment step name of the deployment node is matched with the target deployment step name in the target deployment step set. If any of the following conditions exist: a target deployment step is missing, the step execution result is failed, the step return code is an exception code, the step retry count is greater than zero, or the step execution time exceeds a time threshold, the corresponding deployment step is recorded as a deployment step exception. The number of deployment step exceptions for the deployment node is counted, and the total number of deployment steps participating in the comparison is also counted. Matching the deployment step name with the target deployment step name is used to identify whether the current deployment node has completely executed the preset deployment process. A missing target deployment step refers to a situation where the target deployment step set exists but the current deployment node has not recorded the corresponding execution step. A step execution result of failure means that the corresponding status after the step execution is marked as failed, abnormally terminated, or incomplete. Exception return codes are abnormal return codes predefined by the deployment orchestration system, preferably including non-zero exit codes, exception status codes, timeout status codes, and business failure status codes. Exception return codes can be return status conventions based on the deployment system's built-in return code rules. A step retry count greater than zero indicates that the current deployment step has been executed at least once during this deployment process.The time consumption threshold is used to determine whether the execution time of the corresponding deployment step deviates significantly from the normal execution level. The time consumption threshold is preferably determined based on the statistical results of the execution time of the corresponding deployment steps in historical healthy deployment nodes, preferably the median of the historical execution time of the corresponding deployment steps, to ensure the feasibility and reproducibility of the judgment rule. The total number of deployment steps is the target number of deployment steps corresponding to the current deployment task, used to characterize the total scale of steps participating in the deployment execution consistency analysis of the current deployment node. The software version deviation ratio is obtained by dividing the number of software version anomalies by the sum of the total number of software version data items and the smallest positive number. The software version deviation ratio is used to characterize the relative proportion of anomalies occurring in all software version comparison items for the current deployment node. The smallest positive number is used to avoid division by zero when the total number of software version data items is too small or zero, and to ensure the stability of the calculation process. The configuration deviation ratio is obtained by dividing the number of configuration anomalies by the sum of the total number of configuration data items and the smallest positive number. The configuration deviation ratio is used to characterize the relative proportion of anomalies occurring in all configuration comparison items for the current deployment node. The deployment step anomaly ratio is obtained by dividing the number of deployment step anomalies by the sum of the total number of deployment steps and the smallest positive number. This ratio represents the relative proportion of anomalies occurring in all target deployment steps for the current deployment node. The logarithm of the operational degradation is then calculated by adding one to the operational degradation value. This logarithm is used to compress larger operational degradation values ​​while maintaining the general trend of operational degradation, preventing excessive amplification of other deviations in subsequent comprehensive evaluations. The sum of squares of the software version deviation ratio, configuration deviation ratio, deployment step anomaly ratio, and operational degradation mapping value is calculated, and the square root of the sum is taken to obtain the consistency deviation value of the deployment node. The method of summing squares and taking the square root integrates software version deviation, configuration deviation, deployment step deviation, and operational degradation into a unified comprehensive evaluation framework, ensuring that an abnormal increase in a single deviation item is reflected in the consistency deviation value. This consistency deviation value uniformly represents the overall deviation of the deployment node from the target software version set, target configuration template, target deployment step set, and operational reference state.

[0040] The specific formula for the consistency deviation value is as follows:

[0041] ;

[0042] In the formula, The consistency deviation value represents the overall deviation of the deployment node from the target deployment baseline. It incorporates software version anomalies, configuration anomalies, deployment step anomalies, and operational degradation into the same evaluation framework, and outputs the node consistency deviation value to determine whether the deployment node has anomalies and the degree of anomalies; i represents the deployment node index. This indicates the number of software version anomalies, used to characterize the number of data items in the software version data of the deployed node that are inconsistent with the target software version set; This represents the total number of software version data items, used to characterize the total number of data items that the deployment node participates in the software version consistency comparison; This indicates the number of configuration anomalies, used to characterize the number of data items in the configuration status data of the deployed node that are inconsistent with the target configuration template; This indicates the total number of configuration data items, used to characterize the total number of data items that the deployment node participates in configuration consistency comparison; This indicates the number of abnormal deployment steps, representing the number of deployment steps identified as abnormal during the deployment process. This represents the total number of deployment steps, used to characterize the total number of steps in which deployment nodes participate in consistency comparisons during deployment. This represents the amount of operational degradation, used to characterize the degree of deterioration of a deployed node relative to its operational reference state in terms of heartbeat continuity, interface response performance, and error log performance. This represents a very small positive number, used to avoid division by zero when the total number of software version data items, the total number of configuration data items, or the total number of deployment steps is zero, and to ensure the stability of the formula calculation. The preferred value is 0.001.

[0043] In this embodiment, Table 1 is a consistency deviation value data table. The smallest positive number is 0.001. The total number of software version data items is 3, the total number of configuration data items is 8, and the total number of deployment steps is 10. The table records in detail the number of software version anomalies, the number of configuration anomalies, the number of deployment step anomalies, the amount of operational degradation, and the consistency deviation value for the five deployment nodes. Specifically, for deployment node 1, the number of software version anomalies is 0, the number of configuration anomalies is 0, the number of deployment step anomalies is 0, the operational degradation is 0.033, and the consistency deviation is 0.032; for deployment node 2, the number of software version anomalies is 0, the number of configuration anomalies is 3, the number of deployment step anomalies is 1, the operational degradation is 0.531, and the consistency deviation is 0.576; for deployment node 3, the number of software version anomalies is 0, the number of configuration anomalies is 1, the number of deployment step anomalies is 4, the operational degradation is 2.119, and the consistency deviation is 1.212; for deployment node 4, the number of software version anomalies is 2, the number of configuration anomalies is 0, the number of deployment step anomalies is 0, the operational degradation is 0.049, and the consistency deviation is 0.668; and for deployment node 5, the number of software version anomalies is 1, the number of configuration anomalies is 4, the number of deployment step anomalies is 3, the operational degradation is 4.324, and the consistency deviation is 1.802.

[0044] Table 1 Consistency Deviation Value Data Table

[0045]

[0046] like Figure 3 The figure shows the distribution of consistency deviation values ​​for deployment nodes. The horizontal axis represents different deployment nodes, and the vertical axis represents the values ​​of each component and the consistency deviation value. The bars represent the software version deviation ratio, configuration deviation ratio, deployment step abnormality ratio, operational deterioration mapping value, and consistency deviation value, respectively; the dashed lines represent deviation thresholds, used to distinguish between healthy and abnormal deployment nodes. The image centrally displays the four components and the final consistency deviation value, intuitively reflecting the sources of deviation for each deployment node and the overall degree of deviation. (Combined with Table 1 and...) Figure 3 As can be seen, the software version deviation ratio, configuration deviation ratio, and deployment step anomaly ratio of deployment node 1 are all 0, with a runtime degradation of only 0.033 and a consistency deviation value of 0.032, significantly lower than the deviation threshold. This indicates that the overall state of this node is stable and it is a healthy deployment node. Deployment node 2 has a software version deviation ratio of 0, but there is a significant configuration deviation and some deployment step anomalies. Simultaneously, the runtime degradation mapping value increases, resulting in a final consistency deviation value of 0.576, classifying it as an abnormal deployment node. Deployment node 3 also has a software version deviation ratio of 0, but a high deployment step anomaly ratio and a significantly increased runtime degradation mapping value, reaching a consistency deviation value of 1.212. This indicates that the anomaly of this node mainly stems from the combined effects of deployment execution anomalies and runtime degradation. Deployment node 4 has a very low runtime degradation mapping value, and both configuration deviation and deployment step anomalies are 0, but a high software version deviation ratio and a consistency deviation value of 0.668. This indicates that although the node's runtime state is temporarily stable, the version has significantly deviated from the target deployment baseline, representing a typical software version deviation anomaly. The software version deviation, configuration deviation, deployment step anomaly, and operational degradation mapping values ​​of deployment node 5 are all at high levels. Among them, the operational degradation mapping value is the highest, with a consistency deviation value reaching 1.802, the largest among the five nodes. This indicates that this node simultaneously exhibits multiple types of anomalies, and the overall deviation is the most severe, making it the priority for the correction process. The overall distribution further reveals two points: First, the consistency deviation value is not determined by a single item, but rather by the combined effects of software version deviation, configuration deviation, deployment step anomaly, and operational degradation. Second, the dominant sources of deviation differ significantly among different nodes: Node 2 tends towards a combination of configuration deviation and operational degradation; Node 3 tends towards deployment execution anomalies and operational degradation; Node 4 tends towards software version deviation; and Node 5 exhibits anomalies caused by multiple factors. Overall, this analysis not only determines whether a node exceeds the deviation threshold but also helps identify the main sources of anomalies for each node, providing a clear basis for generating targeted correction plans based on anomaly type.

[0047] In this implementation plan, by incorporating software version, configuration status, deployment step execution status, and operational degradation into the node consistency deviation analysis process, the deviation of deployment nodes from the target deployment baseline can be identified more accurately. At the same time, by jointly judging abnormal return status, abnormal step time, and operational degradation, the completeness of deployment consistency analysis and the accuracy of anomaly identification are improved, thereby providing a reliable basis for subsequent anomaly type determination and adaptive correction.

[0048] Specifically, the process of determining abnormal deployment nodes and identifying the anomaly type based on node consistency deviation is as follows: the consistency deviation value of the deployment node is compared with the deviation threshold. When the consistency deviation value is less than the deviation threshold, the deployment node is marked as a healthy deployment node; when the consistency deviation value is greater than or equal to the deviation threshold, the deployment node is marked as an abnormal deployment node. The deviation threshold is used to distinguish whether the deployment node deviates from the target deployment baseline as a whole, and is preferably determined based on the statistical distribution of consistency deviation values ​​of historical healthy deployment nodes. When a deployment node is marked as an abnormal deployment node, it indicates that at least one of the software version status, configuration status, deployment execution status, and running status of the deployment node has reached an abnormal level that requires further identification and correction. For abnormal deployment nodes, four deviation items—software version deviation ratio, configuration deviation ratio, deployment step abnormality ratio, and operational deterioration mapping value—are compared with their corresponding abnormality thresholds to identify the abnormality type: if the software version deviation ratio is greater than or equal to the version abnormality threshold, it is marked as a software version deviation abnormality; if the configuration deviation ratio is greater than or equal to the configuration abnormality threshold, it is marked as a configuration deviation abnormality; if the deployment step abnormality ratio is greater than or equal to the deployment execution abnormality threshold, it is marked as a deployment execution deviation abnormality; if the operational deterioration mapping value is greater than or equal to the operational abnormality threshold, it is marked as an operational deterioration abnormality. The version abnormality threshold, configuration abnormality threshold, deployment execution abnormality threshold, and operational abnormality threshold are used to determine whether the corresponding deviation item meets the abnormality identification conditions, preferably determined based on the statistical distribution of corresponding deviation items of historical healthy deployment nodes. "Compared with the corresponding abnormality thresholds" means that the four deviation items are judged independently, so the same abnormal deployment node can simultaneously meet the judgment conditions for multiple abnormality types. Therefore, software version deviation abnormality, configuration deviation abnormality, deployment execution deviation abnormality, and operational deterioration abnormality are coexisting abnormality types. Furthermore, when the same abnormal deployment node simultaneously meets multiple anomaly type criteria, the abnormal deployment node is allowed to carry multiple anomaly type tags. These multiple anomaly type tags collectively constitute the anomaly identification result of the abnormal deployment node, used to characterize the composite anomalies that may simultaneously exist in terms of version, configuration, deployment execution, and running status. Since the sources and affected stages of the deviation items corresponding to each anomaly type are different, allowing multiple tags to coexist can more completely preserve the true anomaly state of the abnormal deployment node, avoiding the omission of other anomaly information that has already met the anomaly threshold conditions while only retaining a single anomaly type. The unique identifier of the deployment node, software version deviation ratio, configuration deviation ratio, deployment step anomaly ratio, running degradation mapping value, consistency deviation value, node tag, and anomaly type are associated to generate the corresponding deployment node's deviation evaluation record and write it to the software deployment database.The anomaly type is the result of identifying all anomaly types obtained by comparing the current anomaly deployment node. When multiple anomaly types exist for the same anomaly deployment node, the corresponding anomaly type labels are recorded in the deviation assessment record. The deviation assessment record is used as the input for anomaly basis in the subsequent remediation plan generation process. When the subsequent remediation plan is generated, corresponding remedial measures are generated for each anomaly type identified in the deviation assessment record, and the remediation priority is determined by combining the consistency deviation value of the anomaly deployment node. This ensures that when anomaly types can coexist, each anomaly type can enter the subsequent remediation process, and the overall remediation order has a clear basis.

[0049] In this implementation plan, abnormal deployment nodes are screened by combining node consistency deviation values ​​with deviation thresholds. Software version deviation, configuration deviation, deployment execution deviation, and operational deterioration anomalies are identified independently. This allows for the complete retention of anomaly information even when multiple anomaly types coexist, avoiding omissions caused by single anomaly judgments. At the same time, by uniformly associating anomaly type identification results with node deviation information, the accuracy of abnormal deployment node identification and the completeness of subsequent correction basis are improved.

[0050] Specifically, the process of generating a corresponding adaptive deployment correction scheme based on the anomaly type of the abnormal deployment node is as follows: read the deviation assessment record of the abnormal deployment node. The deviation assessment record includes at least the unique identifier of the deployment node, the consistency deviation value, the anomaly type, the software version deviation ratio, the configuration deviation ratio, the deployment step anomaly ratio, and the operation deterioration mapping value. The reading process is preferably implemented by the software deployment database providing a data query interface to the correction strategy generation module to ensure that the abnormal deployment node and its anomaly type information can be accurately retrieved. To address software version deviations, a software version correction plan is generated, including: re-distributing the software installation package corresponding to the target software installation package version number, re-pulling the image content corresponding to the target image digest value, and reinstalling the dependent components corresponding to the target dependent component version number. Specifically, re-distributing the software installation package corresponding to the target software installation package version number is preferably done by the deployment control end through an artifact distribution channel to the abnormal deployment node. The artifact distribution channel is preferably at least one of a file transfer channel, an artifact repository pull channel, or a deployment agent communication channel. Re-pulling the image content corresponding to the target image digest value is preferably achieved by the container runtime initiating an image pull request from the image repository based on the target image digest value. Re-installing the dependent components corresponding to the target dependent component version number is preferably completed by the dependency installation executor on the node calling a dependency management tool, so that the abnormal deployment node is restored to the version state required by the target software version set. To address configuration deviation anomalies, a configuration correction plan is generated, including: re-distributing the configuration file content corresponding to the target configuration template, rewriting the target environment variable values, rewriting the target startup parameter values, and rewriting the target key configuration item values. Specifically, re-distributing the configuration file content corresponding to the target configuration template is preferably achieved by the deployment control end sending the configuration file content from the target configuration template to the abnormal deployment node via the configuration distribution interface; rewriting the target environment variable values ​​is preferably achieved by the node configuration executor writing them into the runtime environment variable table; rewriting the target startup parameter values ​​is preferably achieved by the service startup configuration manager modifying the target service startup command; and rewriting the target key configuration item values ​​is preferably achieved by the configuration parser overwriting and updating the key configuration items in the currently effective configuration, so that the abnormal deployment node is restored to the configuration state required by the target configuration template.To address deployment execution deviations, a deployment execution correction plan is generated, including: supplementing missing target deployment steps, retrying deployment steps that failed, re-invoking deployment steps with abnormal return codes, re-verifying deployment steps with more than zero retries, and rescheduling deployment steps whose execution time exceeds a time threshold. Among these, supplementing execution, retrying, re-invoking, re-verifying, and rescheduling are preferably performed by the deployment orchestration executor. Supplementing execution refers to re-triggering the execution task for target deployment steps that were not actually executed. Retrying refers to re-initiating the same execution instruction for steps that failed when the retry conditions are met. Re-invoking refers to re-invoking the execution script for the step based on the exception type corresponding to the step's return code. Re-verifying refers to re-verifying the execution status of steps that have already been retried to determine if the step has recovered to the target execution state. Rescheduling refers to the scheduler reallocating the execution order, execution node resources, and execution timing when the execution time exceeds the time threshold, in order to reduce execution blocking and timeout risks. To address operational deterioration anomalies, a remedial plan is generated, including: restarting the service process when its state is abnormal; rebinding the port when its listening state is abnormal; restoring node connections when the median heartbeat interval is greater than the reference median heartbeat interval; reconfiguring service resource parameters when the median response latency is greater than the reference median response latency; and cleaning up the processes corresponding to the abnormal logs when the median number of error log entries is greater than the reference median number of error log entries. Specifically, restarting the service process is preferably implemented using the service manager's restart command; port rebinding is preferably implemented by rebinding the target listening port using the network configuration executor; restoring node connections is preferably implemented by rebuilding the communication connection between the deployment node and the deployment control terminal; reconfiguring service resource parameters is preferably implemented by modifying service runtime resource parameters, thread parameters, connection parameters, and concurrency parameters; and cleaning up the processes corresponding to the abnormal logs is preferably implemented by locating the corresponding abnormal processes, zombie threads, and abnormal subtasks based on the error logs, and having the node cleanup executor perform termination, recycling, and cleanup operations to restore the stable operation of the target service. The consistency deviation values ​​of abnormal deployment nodes are sorted in descending order to generate a correction priority for the abnormal deployment nodes. For each abnormal deployment node, the corresponding correction scheme is converted into an executable correction instruction set. This executable correction instruction set is a structured set of instructions that can be directly parsed and executed by the deployment orchestration executor, node execution agent, configuration distribution executor, image pull executor, dependency installation executor, service manager, and run repair executor. The executable correction instruction set preferably includes: a unique identifier for the deployment node, anomaly correction type, correction object identifier, target version information, target configuration content, target step identifier, execution order, retry rules, execution permission identifier, idempotency control identifier, and execution receipt requirements.The executable correction instruction set is preferably sent from the deployment control terminal to the corresponding abnormal deployment node and the corresponding execution component via the deployment agent communication interface. The execution permission identifier limits the execution to only execution components with the corresponding deployment permissions, configuration write permissions, service control permissions, and resource adjustment permissions. The idempotency control identifier ensures that repeated issuance and execution of the same correction action will not lead to state conflicts caused by repeated installation, repeated writing, repeated restarts, and repeated scheduling. The execution receipt requirement ensures that after the correction action is completed, the execution component returns the execution result, return code, execution time, and failure reason to support subsequent correction feedback and closed-loop correction processes. When multiple abnormal types exist on an abnormal deployment node, the executable correction instruction set preferably generates corresponding instruction subsets according to each abnormal type, and combines them according to the correction priority and the execution order corresponding to the abnormal type to form a complete correction instruction set, ensuring a clear execution sequence and implementation path among multiple correction actions. Within the same abnormal deployment node, the preferred execution order for different exception types is as follows: software version deviation exception, configuration deviation exception, deployment execution deviation exception, and operational deterioration exception. This is because the software version is the most fundamental operational basis; without correcting the version first, subsequent configuration, steps, and operational corrections may all be based on the wrong version. The configuration status depends on the correct software version; if the version is incorrect, configuration corrections may be ineffective. Deployment execution exceptions are often execution problems in the process of implementing the version and configuration, and are suitable to be addressed after version and configuration corrections. Operational deterioration exceptions are usually the result of the first three types of problems, and are suitable to be addressed after the structural problems are corrected before operational recovery. Therefore, this order best conforms to the causal chain.

[0051] In this implementation plan, corresponding remediation schemes are generated for software version deviation anomalies, configuration deviation anomalies, deployment execution deviation anomalies, and operational deterioration anomalies. These remediation schemes are further converted into executable remediation instruction sets. This enables the remediation process of abnormal deployment nodes to have clear execution objects, execution paths, and execution constraints, thereby improving the feasibility and implementability of the remediation schemes. At the same time, by combining the consistency deviation value of abnormal deployment nodes to determine the remediation priority, and combining remediation actions according to the causal order of software version, configuration, deployment execution, and operational status when multiple anomalies coexist, the orderliness, completeness, and efficiency of the anomaly remediation process can be improved.

[0052] Specifically, the process of performing correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme and determining the correction results is as follows: Executable correction instruction sets are sent to the corresponding abnormal deployment nodes according to their correction priority, triggering the corresponding abnormal deployment nodes to perform corrections. Preferably, the executable correction instruction sets are sent from the deployment control terminal to the corresponding abnormal deployment nodes and the corresponding execution components via the deployment agent communication interface. Correction priority is used to characterize the order in which multiple abnormal deployment nodes enter the correction process. After receiving the executable correction instruction sets, the corresponding execution components of the abnormal deployment nodes complete the correction actions according to the correction action types, execution order, retry rules, and execution permission requirements specified in the instruction sets. After the abnormal deployment nodes complete the correction, software version data, configuration status data, deployment execution data, and runtime status data are re-collected, and the corresponding consistency deviation values ​​are calculated to obtain the corrected consistency deviation value. The method of collecting the re-collected software version data, configuration status data, deployment execution data, and runtime status data is consistent with the aforementioned node data collection and processing process. The corrected consistency deviation value is the result obtained by recalculating the re-collected data and following the aforementioned node consistency deviation determination process after the corresponding abnormal deployment node completes this round of correction actions. The consistency deviation value before correction is the most recent consistency deviation value recorded in the deviation assessment record corresponding to the abnormal deployment node before the current round of executable correction instruction set is issued. Preferably, it is taken from the latest deviation assessment record corresponding to the unique identifier of the abnormal deployment node in the software deployment database before the correction instruction is issued, to ensure that the consistency deviation values ​​before and after correction have a clear temporal correspondence and a basis for comparison. When the corrected consistency deviation value is less than the deviation threshold, the abnormal deployment node is remarked as a healthy deployment node. The deviation threshold is preferably consistent with the deviation threshold used in the aforementioned abnormal deployment node determination process to ensure consistent determination criteria before and after correction. When the corrected consistency deviation value is less than the deviation threshold, it indicates that the abnormal deployment node has recovered to the healthy deployment node determination range after this round of correction. When the corrected consistency deviation value is greater than or equal to the deviation threshold, and less than the original consistency deviation value, the abnormal deployment node is marked as a node requiring further correction. A node requiring further correction indicates that although the current abnormal deployment node has not recovered to the range of healthy deployment nodes after this round of correction, its overall deviation has decreased compared to before the correction, signifying that the current correction action has a mitigating effect on the abnormal state, and therefore proceeds to the next round of correction. When the corrected consistency deviation value is greater than or equal to the deviation threshold, and greater than or equal to the original consistency deviation value, the abnormal deployment node is marked as a node where correction failed.Among them, a failed correction node indicates that the current abnormal deployment node has not recovered to the range of healthy deployment nodes after this round of correction, and its overall deviation has not decreased or has further increased, indicating that the current correction action has not achieved the expected correction effect, and therefore enters the subsequent failure handling process. Furthermore, the corrected consistency deviation value, the uncorrected consistency deviation value, the corresponding unique identifier of the abnormal deployment node, and the current node marking result are preferably written together into the software deployment database to form a correction feedback record, which is used to support the further correction of nodes to be corrected and the failure handling of failed correction nodes.

[0053] In this implementation plan, by re-collecting relevant data and recalculating the consistency deviation value after the abnormal deployment node has been corrected, quantitative feedback and unified judgment of the correction results are achieved. At the same time, by classifying abnormal deployment nodes into recovery nodes, nodes to be corrected, and nodes that have failed to be corrected, a closed-loop correction mechanism based on the correction effect can be formed, thereby improving the verifiability of the abnormal node correction process, the continuous correction capability, and the overall deployment consistency recovery effect.

[0054] Specifically, the process of continuing correction, restoring marking, and handling failures based on the correction results is as follows: For nodes to be corrected, the latest deviation assessment record is read, the latest anomaly type is determined, and a correction plan and executable correction instruction set for the corresponding node to be corrected are generated again. The latest deviation assessment record is preferably the latest deviation assessment record written to the software deployment database after the current round of corrections and corresponding to the unique identifier of the node to be corrected. The latest anomaly type is the anomaly type that still exists and is re-identified based on the latest deviation assessment record, used to ensure that the regenerated correction plan matches the actual anomaly state of the current node. For nodes that fail to correct, the rollback process, isolation process, and manual takeover process are executed sequentially. Specifically, the software version state and configuration state of the node that failed to correct are rolled back to the previous version. The previous version is the software version state and configuration state that were most recently stable before the current deployment task was executed. The rollback process is preferably completed by the deployment control terminal calling the version rollback executor and configuration rollback executor to restore the node that failed to correct to the most recently verified stable version and configuration state, thereby avoiding the continued retention of the current failed correction state. Remove the failed node from the load balancer's forwarding object and stop issuing new deployment scheduling tasks to it. Optionally, mark the failed node as an unavailable node. Removing it from the load balancer's forwarding object means removing it from the load balancer, preventing external access requests from being forwarded to it. Stopping the issuance of new deployment scheduling tasks means suspending its participation in subsequent automatic deployment, automatic correction, and resource scheduling processes. Marking the failed node as an unavailable node is used to explicitly record in the software deployment database, scheduling system, or node status management table that the node is currently unable to participate in normal service carrying and automatic deployment processes. An alarm ticket for the corresponding failed node is generated, and the deviation assessment record and correction log of the failed node are attached to the alarm ticket. The alarm work order is preferably generated by the operation and maintenance work order system. Deviation assessment records characterize the deviation changes of the failed node before and after correction, while correction logs characterize the correction actions performed, results, return codes, execution times, and reasons for failure for the failed node. Attaching deviation assessment records and correction logs to the alarm work order provides a complete basis for subsequent manual investigation, intervention, and fault handling. Furthermore, the rollback process, isolation process, and manual takeover process are executed sequentially. The rollback process is prioritized for restoring the basic version and configuration state of the failed node; the isolation process is used to prevent the failed node from continuing to carry business traffic and participate in automatic deployment; and the manual takeover process is used to transfer the failed node to the manual handling stage after automatic handling, ensuring a clear sequence and implementable path for the failure handling process.

[0055] In this implementation plan, by generating a correction plan again based on the latest deviation assessment record for nodes to be corrected, and sequentially executing rollback, isolation, and manual takeover processes for nodes that fail to correct, abnormal nodes can continue to undergo targeted corrections before they recover to a healthy state, and promptly switch to stable rollback and manual handling processes when corrections are ineffective. This improves the continuity of the abnormal handling process, the controllability of failure handling, and the reliability of overall operation recovery in distributed deployment scenarios.

[0056] Reference Figure 2 As shown, the second aspect of the present invention provides an automatic software product adaptation and deployment system, applied to the aforementioned automatic software product adaptation and deployment method, comprising: a node data acquisition and processing module, used to collect software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes in real time, and perform correlation, alignment, deduplication, and normalization processing to form a node status dataset; a consistency deviation assessment module, used to obtain a target software version set, a target configuration template, and a target deployment step set, and construct a running reference state by combining the running status data of historical healthy deployment nodes; assess the running degradation degree of deployment nodes based on the running reference state; analyze the deployment consistency degree of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determine the node consistency deviation by combining the deployment consistency degree and the running degradation degree; determine abnormal deployment nodes and identify the abnormality type based on the node consistency deviation; an adaptive deployment correction module, used to generate a corresponding adaptive deployment correction scheme based on the abnormality type determination of the abnormal deployment nodes; and an execution feedback correction module, used to perform correction feedback and closed-loop correction on the abnormal deployment nodes according to the adaptive deployment correction scheme, determine the correction result, and complete continued correction, recovery marking, and failure handling based on the correction result.

[0057] like Figure 4The diagram illustrates the workflow of an automatic software product adaptation and deployment method. It demonstrates the overall execution flow of this invention's automatic software product adaptation and deployment method in a distributed deployment scenario. First, real-time data on the software version, configuration status, deployment execution, and running status of distributed deployment nodes are collected and processed through association, alignment, deduplication, and normalization to form a node status dataset. Next, the target software version, target configuration, and target deployment steps are obtained, and a running reference status is constructed by combining historical running statuses. Based on this, the degree of operational degradation and deployment consistency of the deployment nodes are comprehensively evaluated to obtain a node consistency deviation value. Then, the node consistency deviation value is compared with a deviation threshold: when the consistency deviation value is less than the deviation threshold, the node is determined to be a healthy deployment node; when the consistency deviation value is greater than or equal to the deviation threshold, the node is determined to be an abnormal deployment node, and further identified as belonging to one or more of the following abnormality types: software version abnormality, configuration abnormality, deployment execution abnormality, or running abnormality. Afterwards, corresponding correction schemes are generated according to the abnormality type, and the correction priority is determined according to the consistency deviation value. The correction schemes are then converted into executable instruction sets and executed. After the correction action is completed, the data of the corresponding node is re-collected and the corrected consistency deviation value is recalculated. The correction result is then judged: if the corrected deviation value is less than the deviation threshold, the node is restored to a healthy deployment node, and the process ends; if the corrected deviation value is still greater than or equal to the deviation threshold but has decreased compared to before the correction, the node is marked as a node to be further corrected, and the aforementioned correction process is returned to continue execution; if the corrected deviation value is still greater than or equal to the deviation threshold and has not decreased or has further deteriorated, the failure handling process is entered, and rollback, isolation, and alarm work order generation are performed in sequence. Thus, the entire process logic of this invention from data collection, deviation assessment, anomaly identification, adaptive correction to feedback closed-loop correction is fully demonstrated.

[0058] In this implementation scheme, through the coordinated operation of the node data acquisition and processing module, the consistency deviation assessment module, the adaptive deployment correction module, and the execution feedback correction module, the software version status, configuration status, deployment execution status, and running status of distributed deployment nodes can be uniformly perceived, comprehensively evaluated, and closed-loop corrected. This enables accurate identification, differentiated correction, and continuous feedback correction of abnormal deployment nodes, thereby improving the deployment consistency, anomaly handling efficiency, and overall operational stability of software products in distributed deployment scenarios.

[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0060] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. As those skilled in the art will understand, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for automatic adaptation and deployment of software products, characterized in that, Includes the following steps: S1 collects software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes in real time, and performs correlation, alignment, deduplication, and normalization processing to form a node status dataset; S2, obtain the target software version set, target configuration template and target deployment step set, and construct the operation reference state by combining the operation status data of historical healthy deployment nodes; evaluate the degree of operation degradation of the deployment nodes based on the operation reference state; Based on the target software version set, target configuration template, and target deployment step set, analyze the deployment consistency of deployment nodes, and determine node consistency deviations by combining the deployment consistency and operational degradation levels; identify abnormal deployment nodes and anomaly types based on node consistency deviations. S3, based on the anomaly type of the abnormal deployment node, generates a corresponding adaptive deployment correction plan; S4: Perform correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme, determine the correction result, and complete the continued correction, recovery marking and failure handling based on the correction result.

2. The method for automatic adaptation and deployment of software products according to claim 1, characterized in that, The specific process of collecting software version data, configuration status data, deployment execution data, and runtime status data of distributed deployment nodes in real time, and performing correlation, alignment, deduplication, and normalization processing to form a node status dataset is as follows: Real-time collection of software version data, configuration status data, deployment execution data, and runtime status data from distributed deployment nodes; software version data includes: software installation package version number, image digest value, and dependent component version number; configuration status data includes: configuration file hash value, environment variable value, startup parameter value, and key configuration item value; deployment execution data includes: deployment step name, step execution result, step return code, step retries, and step execution time; runtime status data includes: service process status, port listening status, node heartbeat time sequence, service interface response latency sequence, and the number of error log entries within the sliding time window; Using the unique identifier of the deployment node as an index, the software version data, configuration status data, deployment execution data, and runtime status data of the same deployment node are associated to form the original node dataset of the corresponding deployment node; the node heartbeat time series of the deployment node are timestamped according to a unified clock reference, and the heartbeat time interval sequence is calculated; the field format of the software version data, configuration status data, deployment execution data, and runtime status data of the deployment node is unified; when there are missing data items, a missing tag is generated; when there are more than one record of the same data item of the same deployment node at the same collection time, only the most recently written valid record is retained; a software deployment database is established to store the original and preprocessed software version data, configuration status data, deployment execution data, and runtime status data of the deployment nodes.

3. The automatic adaptation and deployment method for software products according to claim 1, characterized in that, The specific process of obtaining the target software version set, target configuration template, and target deployment step set, and constructing the operational reference state by combining them with the historical operational status data of healthy deployment nodes, is as follows: Read the target software version set, target configuration template, and target deployment step set corresponding to the current deployment task; wherein, the target software version set includes the target software installation package version number, target image digest value, and target dependent component version number corresponding to the current deployment task; the target configuration template includes the target configuration file hash value, target environment variable value, target startup parameter value, and target key configuration item value; the target deployment step set includes the target deployment step name corresponding to the current deployment task; The heartbeat interval sequence, service interface response delay sequence, and number of error log entries within the sliding time window of the healthy deployment nodes corresponding to historical deployment tasks are statistically analyzed, and the median of each is taken to obtain the reference median heartbeat interval, reference median response delay, and reference median number of error log entries, forming a set of running reference states.

4. The automatic adaptation and deployment method for software products according to claim 1, characterized in that, The specific process for assessing the operational degradation of deployed nodes based on operational reference states is as follows: For each deployment node, obtain the heartbeat time interval sequence of the deployment node, and take the median to obtain the median heartbeat interval; obtain the service interface response latency sequence of the deployment node, and take the median to obtain the median response latency; count the number of error log entries within the sliding time window of the deployment node, and take the median to obtain the median number of error log entries. Calculate the difference between the median heart rate interval and the reference median heart rate interval, and compare the difference with zero to take the maximum value to obtain the heart rate deterioration difference; Calculate the difference between the median response delay and the reference median response delay, and compare the difference with zero to take the maximum value to obtain the response delay degradation difference; calculate the difference between the median number of error log entries and the reference median number of error log entries, and compare the difference with zero to take the maximum value to obtain the error log degradation difference; The heartbeat deterioration difference is divided by the sum of the reference median heartbeat interval and the smallest positive number, the response delay deterioration difference is divided by the sum of the reference median response delay and the smallest positive number, and the error log deterioration difference is divided by the sum of the reference median number of error log entries and one, to obtain the response delay deterioration ratio, heartbeat deterioration ratio, and error log deterioration ratio. The sum of squares of the response latency degradation rate, heartbeat degradation rate, and error log degradation rate is calculated, and the square root is taken to obtain the operational degradation of the deployed node.

5. The automatic adaptation and deployment method for software products according to claim 1, characterized in that, The specific process of analyzing the deployment consistency of deployment nodes based on the target software version set, target configuration template, and target deployment step set, and determining the node consistency deviation by combining the deployment consistency and operational degradation degree, is as follows: For each deployment node, the software installation package version number, image digest value, and dependent component version number of the deployment node are compared with the corresponding items in the target software version set. When the corresponding items are inconsistent, they are recorded as a software version exception. The number of software version exceptions of the deployment node is counted, and the total number of software version data items participating in the comparison is also counted. The configuration file hash value, environment variable value, startup parameter value, and key configuration item value of the deployment node are compared with the corresponding items in the target configuration template. When the corresponding items are inconsistent, they are recorded as a configuration exception. The number of configuration exception items of the deployment node is counted, and the total number of configuration data items participating in the comparison is also counted. Match the deployment step name of the deployment node with the target deployment step name in the target deployment step set. If any of the following situations exist, such as missing target deployment step, failure of deployment step execution result, abnormal return code of step, retry count greater than zero, or execution time of step greater than time threshold, the corresponding deployment step is recorded as a deployment step exception. Count the number of deployment step exceptions of the deployment node and the total number of deployment steps participating in the comparison. The software version deviation ratio is obtained by dividing the number of software version anomalies by the sum of the total number of software version data items and the smallest positive number; the configuration deviation ratio is obtained by dividing the number of configuration anomalies by the sum of the total number of configuration data items and the smallest positive number; the deployment step anomaly ratio is obtained by dividing the number of deployment step anomalies by the sum of the total number of deployment steps and the smallest positive number. Add one to the deterioration amount and take the natural logarithm to obtain the deterioration mapping value; The sum of squares is calculated for the software version deviation ratio, configuration deviation ratio, deployment step abnormality ratio, and operation deterioration mapping value. The square root of the sum of squares is then taken to obtain the consistency deviation value of the deployment node.

6. The automatic adaptation and deployment method for a software product according to claim 5, characterized in that, The specific process for determining abnormal deployment nodes and identifying the anomaly type based on node consistency deviation is as follows: The consistency deviation value of the deployment node is compared with the deviation threshold. When the consistency deviation value is less than the deviation threshold, the deployment node is marked as a healthy deployment node; when the consistency deviation value is greater than or equal to the deviation threshold, the deployment node is marked as an abnormal deployment node. For abnormal deployment nodes, the four deviation items—software version deviation ratio, configuration deviation ratio, deployment step abnormality ratio, and operation deterioration mapping value—are compared with their corresponding abnormality thresholds to identify the abnormality type: if the software version deviation ratio is greater than or equal to the version abnormality threshold, it is marked as a software version deviation abnormality; if the configuration deviation ratio is greater than or equal to the configuration abnormality threshold, it is marked as a configuration deviation abnormality; if the deployment step abnormality ratio is greater than or equal to the deployment execution abnormality threshold, it is marked as a deployment execution deviation abnormality. If the deterioration mapping value is greater than or equal to the abnormal operation threshold, it is marked as an abnormal operation deterioration. The unique identifier of the deployment node, the software version deviation ratio, the configuration deviation ratio, the abnormal ratio of the deployment steps, the operation deterioration mapping value, the consistency deviation value, the node tag and the anomaly type are associated to generate the deviation evaluation record of the corresponding deployment node and write it into the software deployment database.

7. The automatic adaptation and deployment method for a software product according to claim 6, characterized in that, The specific process of determining the anomaly type of the abnormal deployment node and generating the corresponding adaptive deployment correction scheme is as follows: Read the deviation assessment records of abnormal deployment nodes, generate a software version correction plan for software version deviation anomalies, including: re-distributing the software installation package corresponding to the target software installation package version number, re-pulling the image content corresponding to the target image digest value, and reinstalling the dependent components corresponding to the target dependent component version number; For configuration deviation anomalies, generate configuration correction solutions, including: re-distributing the configuration file content corresponding to the target configuration template, rewriting the target environment variable values, rewriting the target startup parameter values, and rewriting the target key configuration item values. To address deployment execution deviations and anomalies, a deployment execution correction plan is generated, including: performing missing target deployment steps, retrying deployment steps that fail, re-calling deployment steps with abnormal return codes, re-verifying deployment steps with more than zero retry counts, and rescheduling deployment steps whose execution time exceeds the time threshold. In response to operational deterioration anomalies, operational correction plans are generated, including: restarting the service process when the service process status is abnormal, rebinding the port when the port listening status is abnormal, restoring node connections when the median heartbeat interval is greater than the reference median heartbeat interval, reconfiguring service resource parameters when the median response latency is greater than the reference median response latency, and cleaning up the process corresponding to the abnormal log when the median number of error log entries is greater than the reference median number of error log entries. The consistency deviation values ​​of abnormal deployment nodes are sorted in descending order to generate the correction priority of abnormal deployment nodes. For the abnormal types of abnormal deployment nodes, the corresponding correction schemes are converted into executable correction instruction sets.

8. The automatic adaptation and deployment method for software products according to claim 1, characterized in that, The specific process of performing correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme, and determining the correction result, is as follows: According to the priority order of the abnormal deployment nodes, the executable correction instruction set is sent to the corresponding abnormal deployment nodes to trigger the corresponding abnormal deployment nodes to perform correction; after the abnormal deployment nodes complete the correction, software version data, configuration status data, deployment execution data and running status data are collected again, and the corresponding consistency deviation value is calculated to obtain the corrected consistency deviation value. When the corrected consistency deviation value is less than the deviation threshold, the abnormal deployment node will be remarked as a healthy deployment node; When the corrected consistency deviation value is greater than or equal to the deviation threshold and less than the original consistency deviation value, the abnormal deployment node is marked as a node to be corrected. When the corrected consistency deviation value is greater than or equal to the deviation threshold and greater than or equal to the original consistency deviation value, the abnormal deployment node is marked as a node that failed to be corrected.

9. The automatic adaptation and deployment method for a software product according to claim 8, characterized in that, The specific process for completing further correction, restoring the marker, and handling failures based on the correction results is as follows: For nodes that need further correction, read the latest deviation assessment record, determine the latest anomaly type, and regenerate the corresponding correction plan and executable correction instruction set for the nodes that need further correction; for nodes that failed to be corrected, roll back the software version status and configuration status of the nodes that failed to be corrected to the previous version. Remove the failed node from the load balancer forwarding object and stop issuing new deployment scheduling tasks to the failed node; Generate an alarm work order for the corresponding node that failed to be corrected, and attach the deviation assessment record and correction log of the node that failed to be corrected to the alarm work order.

10. A software product automatic adaptation and deployment system, characterized in that, include: The node data acquisition and processing module is used to collect software version data, configuration status data, deployment execution data, and running status data of distributed deployment nodes in real time, and perform correlation, alignment, deduplication, and normalization processing to form a node status dataset. The consistency deviation assessment module is used to obtain the target software version set, target configuration template, and target deployment step set, and construct an operational reference state by combining the operational status data of historical healthy deployment nodes; and assess the degree of operational degradation of deployment nodes based on the operational reference state. Based on the target software version set, target configuration template, and target deployment step set, analyze the deployment consistency of deployment nodes, and determine node consistency deviations by combining the deployment consistency and operational degradation levels; identify abnormal deployment nodes and anomaly types based on node consistency deviations. The adaptive deployment correction module is used to determine the anomaly type of the abnormal deployment node and generate a corresponding adaptive deployment correction scheme. The execution feedback correction module is used to perform correction feedback and closed-loop correction on abnormal deployment nodes according to the adaptive deployment correction scheme, determine the correction result, and complete the continued correction, restoration marking and failure handling based on the correction result.

Images