Software package rollback method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure relates to a software package rollback method and device, electronic equipment, storage medium and program product. The method comprises: in response to completing the upgrade of a target software package, obtaining the hardware and software performance information of the system; performing health assessment on the hardware and software performance information according to a preset number of health assessment dimensions to obtain a health assessment value of each health assessment dimension, wherein the preset number is an integer greater than 1; in the case that the health assessment value meets a first preset condition, determining a target failure level from a plurality of failure levels according to the health assessment value, wherein the first preset condition is used to indicate that the target software package upgrade fails; determining a target rollback scheme corresponding to the target failure level, wherein each failure level is configured with a corresponding rollback scheme, and the rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to the non-highest failure level includes rolling back part of the file; and executing the target rollback scheme on the target software package.

Description

Technical Field

[0001] This disclosure relates to the field of operating systems, and more particularly to a software package rollback method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In RHEL (Red Hat Enterprise Linux) Linux systems, software package upgrades (such as using dnf / yum) may introduce compatibility issues, dependency conflicts, or service anomalies, leading to business interruptions. If an upgrade fails, administrators typically need to manually uninstall or downgrade the package, a cumbersome process that makes it difficult to guarantee system consistency.

[0003] To solve this problem, the relevant technologies mainly employ the following three methods to achieve software rollback.

[0004] The first method is dnf / yum history rollback. This method is based on the system's recorded transaction history and restores the package state to the state it was in when a previous successful transaction was completed by undoing a single transaction or rolling back all changes after that transaction. However, this method does not support downgrading to any older version (Red Hat officially states that it does not support downgrading system packages).

[0005] The second method is transactional updates using Btrfs (B-tree File System, a modern copy-on-write file system). This method creates a new Btrfs snapshot of the root file system before applying the update, performs all updates within that snapshot, and sets it as the default snapshot for the next boot if successful. If it fails, the snapshot is discarded, and the system automatically rolls back to the previous default snapshot upon restarting and detecting a problem. However, this method relies on the Btrfs file system, while RHEL uses XFS (eXtended File System) by default, making it unsuitable for direct reuse.

[0006] The third method is a full-system LVM (Logical Volume Manager) snapshot rollback. This method is applicable to XFS. Before the upgrade, an LVM snapshot boot entry is created and registered for the original system. When a rollback is needed, this snapshot boot entry can be used to directly boot back to the complete state of the original system. However, this method is mainly for major version upgrades, has coarse granularity, requires a restart, and cannot retain incremental data after the upgrade.

[0007] Therefore, the relevant technologies make it difficult to perform flexible software rollback of the default file system used by RHEL-based Linux systems. Summary of the Invention

[0008] This disclosure provides a software package rollback method, apparatus, electronic device, storage medium, and program product to at least address the problem of flexible software rollback for the default file system used in RHEL-based Linux systems in related technologies.

[0009] According to a first aspect of the present disclosure, a software package rollback method is provided, comprising: in response to completing the upgrade of a target software package, acquiring system hardware and software performance information; performing health assessments on the hardware and software performance information according to a preset number of health assessment dimensions to obtain a health assessment value for each health assessment dimension, wherein the preset number is an integer greater than 1; when the health assessment value satisfies a first preset condition, determining a target failure level from a plurality of failure levels based on the health assessment value, wherein the first preset condition is used to indicate that the target software package upgrade has failed; determining a target rollback scheme corresponding to the target failure level, wherein each failure level is configured with a corresponding rollback scheme, the rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to a non-highest failure level includes rolling back a portion of the files; and executing the target rollback scheme on the target software package.

[0010] Optionally, the step of performing a health assessment on the software and hardware performance information according to a preset number of health assessment dimensions to obtain a health assessment value for each health assessment dimension includes: for each health assessment dimension, obtaining the performance parameter value corresponding to that health assessment dimension in the software and hardware performance information; and determining the health assessment value of that health assessment dimension based on the preset parameter range of that health assessment dimension and the obtained performance parameter value.

[0011] Optionally, the preset number of health assessment dimensions includes at least one of the following: system load, memory usage, disk input / output, critical service status, and application log error rate.

[0012] Optionally, determining the target failure level from multiple failure levels based on the health assessment value includes: determining the failure type that matches the health assessment value among the multiple failure types as the target failure type based on a preset matching rule for multiple failure types, wherein the preset matching rule is used to describe the correspondence between failure types and health assessment values, and each failure type has a unique corresponding failure level; and determining the target failure level based on the failure level corresponding to the target failure type.

[0013] Optionally, the multiple failure types have different priorities, each failure level corresponds to at least one failure type, and the level of each failure level is positively correlated with the priority of the failure type corresponding to that failure level. The step of determining the failure type that matches the health assessment value among the multiple failure types as the target failure type based on the preset matching rules of multiple failure types includes: determining the failure type that matches the health assessment value and has the highest priority among the multiple failure types as the target failure type based on the preset matching rules of multiple failure types.

[0014] Optionally, determining the target failure level from multiple failure levels based on the health assessment value further includes: if none of the multiple failure types match the health assessment value, determining the highest failure level as the target failure level.

[0015] Optionally, the multiple failure levels include an increasing first level, a second level, a third level, and a fourth level; wherein, the first level indicates that only the configuration file has changed, and the rollback plan corresponding to the first level includes a plan to roll back the configuration file; the second level indicates that the target software package conflicts with other installed software packages, and the rollback plan corresponding to the second level includes a plan to roll back the target software package and the software packages that conflict with the target software package; the third level indicates that the system performance has severely degraded, and the rollback plan corresponding to the third level includes a plan to roll back the software packages related to the performance degradation; the fourth level is the highest failure level.

[0016] Optionally, after performing health assessments on the hardware and software performance information according to a preset number of health assessment dimensions to obtain health assessment values ​​for each health assessment dimension, the software package rollback method further includes: abandoning the determination of the target failure level when the health assessment value meets a second preset condition, and determining the scheme of rolling back the entire file system as the target rollback scheme, wherein the second preset condition is used to indicate that the target software package upgrade has failed and there is a serious anomaly; and / or abandoning the determination of the target failure level and the target rollback scheme when the decrease in the health assessment value relative to the baseline health assessment value exceeds a decrease threshold, and outputting an anomaly prompt message.

[0017] Optionally, after the step of executing the target rollback scheme on the target software package, the method further includes: if the rollback fails, adjusting the target failure level and re-executing the step of determining the target rollback scheme corresponding to the target failure level and the step of executing the target rollback scheme on the target software package; and / or if the rollback succeeds, acquiring the system's hardware and software performance information again, performing a health assessment on the acquired hardware and software performance information to obtain an updated health assessment value, and determining the rollback result information by comparing the updated health assessment value and the health assessment value.

[0018] According to a second aspect of the present disclosure, a software package rollback apparatus is provided, comprising: an acquisition unit configured to acquire system hardware and software performance information in response to completing an upgrade of a target software package; an evaluation unit configured to perform health evaluations on the hardware and software performance information according to a preset number of health evaluation dimensions to obtain a health evaluation value for each health evaluation dimension, wherein the preset number is an integer greater than 1; a level determination unit configured to determine a target failure level from multiple failure levels based on the health evaluation value when the health evaluation value meets a first preset condition, wherein the first preset condition indicates that the target software package upgrade has failed; a scheme determination unit configured to determine a target rollback scheme corresponding to the target failure level, wherein each failure level is configured with a corresponding rollback scheme, the rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to other failure levels includes rolling back a portion of the files; and an execution unit configured to execute the target rollback scheme on the target software package.

[0019] Optionally, the evaluation unit is further configured to: for each health evaluation dimension, obtain the performance parameter value corresponding to the health evaluation dimension from the software and hardware performance information; and determine the health evaluation value of the health evaluation dimension based on the preset parameter range of the health evaluation dimension and the obtained performance parameter value.

[0020] Optionally, the preset number of health assessment dimensions includes at least one of the following: system load, memory usage, disk input / output, critical service status, and application log error rate.

[0021] Optionally, the level determination unit is further configured to: determine the failure type that matches the health assessment value among the multiple failure types as the target failure type based on a preset matching rule for multiple failure types, wherein the preset matching rule is used to describe the correspondence between failure types and health assessment values, and each failure type has a unique corresponding failure level; and determine the target failure level based on the failure level corresponding to the target failure type.

[0022] Optionally, the multiple failure types have different priorities, each failure level corresponds to at least one failure type, and the level of each failure level is positively correlated with the priority of the failure type corresponding to that failure level. The level determination unit is further configured to: determine the failure type with the highest priority that matches the health assessment value among the multiple failure types as the target failure type based on the preset matching rules of the multiple failure types.

[0023] Optionally, the level determination unit is further configured to: determine the highest failure level as the target failure level when all of the multiple failure types do not match the health assessment value.

[0024] Optionally, the multiple failure levels include an increasing first level, a second level, a third level, and a fourth level; wherein, the first level indicates that only the configuration file has changed, and the rollback plan corresponding to the first level includes a plan to roll back the configuration file; the second level indicates that the target software package conflicts with other installed software packages, and the rollback plan corresponding to the second level includes a plan to roll back the target software package and the software packages that conflict with the target software package; the third level indicates that the system performance has severely degraded, and the rollback plan corresponding to the third level includes a plan to roll back the software packages related to the performance degradation; the fourth level is the highest failure level.

[0025] Optionally, the scheme determination unit is further configured to: abandon determining the target failure level and determine the scheme of rolling back the entire file system as the target rollback scheme when the health assessment value meets the second preset condition, wherein the second preset condition is used to indicate that the target software package upgrade failed and there is a serious anomaly; and / or, the software package rollback device further includes a prompting unit, configured to abandon determining the target failure level and the target rollback scheme and output an anomaly prompting message when the decrease in the health assessment value relative to the baseline health assessment value exceeds the decrease threshold.

[0026] Optionally, the level determination unit is further configured to: adjust the target failure level and rerun the scheme determination unit and the execution unit in the event of a rollback failure; and / or, the software package rollback device further includes a verification unit, in the event of a successful rollback, wherein the acquisition unit re-acquires the system's hardware and software performance information, the evaluation unit performs a health assessment on the re-acquired hardware and software performance information to obtain an updated health assessment value, and the verification unit determines the rollback result information by comparing the updated health assessment value with the health assessment value.

[0027] According to a third aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform a software package rollback method according to an exemplary embodiment of the present disclosure.

[0028] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause at least one processor to perform a software package rollback method according to an exemplary embodiment of the present disclosure.

[0029] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by at least one processor, cause at least one processor to perform a software package rollback method according to an exemplary embodiment of the present disclosure.

[0030] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: According to the software package rollback method, apparatus, electronic device, storage medium and program product of this disclosure, by introducing an independent multi-dimensional health assessment process after the software package upgrade is completed, the upgrade status is assessed, and then when it is determined that the upgrade has failed and the software package needs to be rolled back, a specific rollback plan is determined based on the health assessment results. This can decouple fault detection (perception) and rollback decision (judgment), so that both can be independently quantified, tested and optimized, and software rollback can be easily realized to ensure system state consistency.

[0031] Meanwhile, during health assessments, health evaluation values ​​can be determined based on hardware and software performance information that reflects the system's health status, enabling quantitative scoring. By comprehensively considering multiple evaluation dimensions, the risk of misjudgment caused by assessments based on a single dimension can be reduced, thus improving the reliability of the assessment.

[0032] Furthermore, by employing different granularity rollback schemes for different failure levels—specifically, for the highest failure level, a full file system rollback scheme is used, including but not limited to full system LVM snapshot rollback; for other failure levels, a partial file rollback scheme is used, including but not limited to using a general package manager to roll back software packages—on the one hand, it can automatically select full or partial rollback based on the severity of the failure, avoiding excessive rollback, thereby adjusting the rollback granularity as needed. This improves rollback flexibility and reduces the MTTR (Mean Time To Repair) from hours to minutes compared to a full system reinstall, enabling rapid recovery. On the other hand, since a general package manager can be used for partial rollback, it does not depend on a specific file system, allowing for rollbacks of different granularities on the default file system, thus improving the flexibility of software rollback on the default file system.

[0033] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0035] Figure 1 This is a flowchart of a software package rollback method according to an exemplary embodiment of the present disclosure.

[0036] Figure 2 This is a flowchart illustrating a software package rollback method according to a specific embodiment of the present disclosure.

[0037] Figure 3 This is a block diagram of a software package rollback apparatus according to exemplary embodiments of the present disclosure.

[0038] Figure 4 This is a block diagram of an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0039] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0040] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0041] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0042] Hereinafter, a software package rollback method, apparatus, electronic device, storage medium, and program product according to exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0043] Figure 1 This is a flowchart of a software package rollback method according to an exemplary embodiment of the present disclosure.

[0044] Reference Figure 1 In step 101, in response to completing the upgrade of the target software package, the system's hardware and software performance information is obtained.

[0045] It should be understood that the system's software and hardware performance information reflects the system's software and hardware performance. For example, it may include quantitative indicators of software and hardware performance, or it may include the application logs themselves. This disclosure does not limit this.

[0046] In step 102, the hardware and software performance information is evaluated according to a preset number of health evaluation dimensions to obtain the health evaluation value for each health evaluation dimension.

[0047] The preset quantity is an integer greater than 1, meaning that multiple assessment dimensions are considered during health assessments. This reduces the risk of misjudgment caused by assessments based on a single dimension, improving the reliability of the assessment. By determining health assessment values ​​based on hardware and software performance information reflecting the system's health status, quantitative scoring can be achieved.

[0048] In step 103, if the health assessment value meets the first preset condition, the target failure level is determined from multiple failure levels based on the health assessment value.

[0049] The first preset condition is used to indicate that the target software package upgrade failed. It can be represented by the range of values ​​of health assessment values ​​of at least one health assessment dimension, or by summing the health assessment values ​​of multiple health assessment dimensions, such as including but not limited to calculating a weighted sum, and representing it by the range of values ​​of the weighted sum. This disclosure does not limit this.

[0050] In step 104, the target rollback scheme corresponding to the target failure level is determined.

[0051] Each failure level is configured with a corresponding rollback scheme. The rollback scheme for the highest failure level includes rolling back the entire file system, such as, but not limited to, rolling back a full system LVM snapshot. Rollback schemes for non-highest failure levels include rolling back partial files, such as, but not limited to, rolling back software packages using a general package manager. For example, if the number of non-highest failure levels is greater than one, the higher the failure level, the larger the rollback scope, but it never exceeds the rollback scope of the highest failure level (i.e., the entire file system). This results in the rollback scope of multiple failure levels increasing with the level, forming rollback schemes of different granularities. By using rollback schemes of different granularities for different failure levels, it is possible to automatically select between full and partial rollbacks, avoiding over-rollbacks. This allows for on-demand adjustment of rollback granularity, improving rollback flexibility and reducing MTTR from hours to minutes compared to a full system reinstall, enabling rapid recovery. Furthermore, since a general package manager can be used during partial rollbacks, there is no need to rely on a specific file system, allowing for rollbacks of different granularities on the default file system, thus improving the flexibility of software rollbacks on the default file system.

[0052] In step 105, the target rollback scheme is executed on the target software package.

[0053] According to the software package rollback method disclosed herein, after the software package upgrade is completed, an independent multi-dimensional health assessment process is introduced to evaluate the upgrade status. Then, when it is determined that the upgrade has failed and the software package needs to be rolled back, a specific rollback plan is determined based on the health assessment results. This decouples fault detection (perception) and rollback decision (judgment), allowing both to be quantified, tested, and optimized independently. This enables convenient software rollback and ensures system state consistency.

[0054] As an example, a pre-upgrade snapshot can be created before performing a package upgrade operation, ensuring the atomicity of snapshot creation and the integrity of metadata records. The LVM snapshot creation process may include, for example, creating a read-only snapshot of the LV volume using `lvcreate --snapshot` before executing `yum update / dnfupdate`; the snapshot size is calculated using the formula: `snap_size = min(OriginSize × 0.2, 10G)`, and is not less than 1G; the snapshot naming format is: `rollback_`. <timestamp>_<package_name> (Timestamps are accurate to the second, and package names can only contain the first 20 characters); After a snapshot is successfully created, metadata such as, but not limited to, the following can be recorded to a specified file (the specified file may include, but is not limited to, / var / lib / rollback-system / pre-upgrade-meta.json):

[0055] The following section provides a further description of a software package rollback method according to exemplary embodiments of this disclosure.

[0056] Regarding step 102, the health check in the relevant technology is merely a Boolean judgment, lacking a continuous scoring mechanism, and the thresholds rely on human experience, making standardization impossible. Optionally, step 102 includes: for each health assessment dimension, obtaining the performance parameter value corresponding to that health assessment dimension from the software and hardware performance information; determining the health assessment value for that health assessment dimension based on the preset parameter range of that health assessment dimension and the obtained performance parameter value. By combining the preset parameter range of the corresponding health assessment dimension to quantitatively calculate the health assessment value, clear continuous scoring calculation can be achieved.

[0057] Optionally, each health assessment dimension has a preset parameter range that is a continuous interval and has at least two reference parameter values. These at least two reference parameter values ​​include the two endpoints of the preset parameter range. Each reference parameter value has a unique corresponding reference health assessment value. Determining the health assessment value for a health assessment dimension based on the preset parameter range and the acquired performance parameter values ​​includes: truncating and linearly interpolating the acquired performance parameter values ​​based on the at least two reference parameter values ​​and their corresponding reference health assessment values ​​to obtain the health assessment value for that health assessment dimension. It should be understood that the reference parameter values ​​include at least the two endpoints of the preset parameter range, and the corresponding reference health assessment values ​​can be the maximum and minimum values ​​within a predetermined range of health assessment values. For example, for a percentage-based assessment mechanism, these could be 0 and 100 points, thus enabling linear interpolation calculation of the health assessment value based on the preset parameter range. Furthermore, reference parameter values ​​can be selected within the preset parameter range, and corresponding reference health assessment values ​​can be determined, thereby dividing the preset parameter range into multiple segments. In this case, the linear interpolation calculation is a piecewise linear interpolation calculation. The truncation process means that for performance parameter values ​​that exceed the preset parameter range, the health assessment value can be determined as the minimum or maximum value of the predetermined range to ensure that the obtained health assessment value is within the predetermined range.

[0058] Optionally, the preset number of health assessment dimensions includes at least one of the following: system load, memory usage, disk input / output, critical service status, and application log error rate, thereby enabling the evaluation of the software package upgrade from different dimensions.

[0059] As an example, the preset number of health assessment dimensions includes all five dimensions mentioned above. An exemplary embodiment of this disclosure provides a five-dimensional scoring model (HSM) to perform a quantitative health assessment of the upgraded system from 0 to 100 points. The definitions of the five-dimensional indicators are shown in Table 1 below.

[0060] Table 1 Definition of Five-Dimensional Indicators

[0061] For example, the individual scoring function for each dimension is a piecewise linear function, with an individual score S. For ∈ [0, 100], the calculation rules are as follows:

[0062] Regarding step 103, optionally, determining the target failure level from multiple failure levels based on the health assessment value in step 103 includes: determining the failure type that matches the health assessment value among multiple failure types as the target failure type based on preset matching rules for multiple failure types, wherein the preset matching rules are used to describe the correspondence between failure types and health assessment values, and each failure type has a unique corresponding failure level; and determining the target failure level based on the failure level corresponding to the target failure type. By automatically identifying failure types based on health assessment results and monitoring data, and matching the corresponding failure level and suitable rollback scheme, automated identification of failure types can be achieved.

[0063] As an example, the preset matching rules for each failure type may include at least one range of matching values ​​for a health assessment value, so that each judgment step has a clear threshold and reduces reliance on human experience.

[0064] Optionally, multiple failure types have different priorities, each failure level corresponds to at least one failure type, and the level of each failure level is positively correlated with the priority of the failure type corresponding to that failure level. Specifically, based on preset matching rules for multiple failure types, the failure type that matches the health assessment value among the multiple failure types is determined as the target failure type. This includes: based on preset matching rules for multiple failure types, determining the failure type with the highest priority that matches the health assessment value among the multiple failure types as the target failure type. By configuring explicit priorities for each failure type, failure type matching can be performed step-by-step according to priority, solving the decision-making challenges in mixed failure scenarios.

[0065] Optionally, step 103, determining the target failure level from multiple failure levels based on the health assessment value, further includes: when multiple failure types do not match the health assessment value, determining the highest failure level as the target failure level. It should be understood that under the aforementioned priority settings for failure types and failure levels, the lower the priority of the identified failure type, the lower its corresponding failure level, and the smaller the rollback scope. In special cases, the health assessment value may not match any of the failure types, suggesting that multiple factors may have caused the failure. By determining the highest failure level as the target failure level in this situation, complex problems can be resolved more reliably with a single rollback, improving rollback reliability. It should be understood that the special case where multiple failure types do not match the health assessment value can be considered a special failure type. Based on this, in actual execution, the aforementioned multiple failure types can be matched one by one according to priority. If a match is successful, other failure types can continue to be matched, or no further matching can be continued, directly determining the currently matched failure type as the target failure type. If no match is ever successful, it is determined as the aforementioned special failure type. At this point, the special failure type has the lowest priority from the perspective of processing order, but its corresponding failure level is the highest failure level.

[0066] It should also be understood that failure types can be configured appropriately as needed. As an example, a classification decision tree can be used to automatically categorize mixed failures into eight failure types (including the special failure types mentioned above) and process them according to priority, achieving automatic classification decision-making. For instance, a three-level classification decision tree can be designed, taking health assessment results and application log keywords as input, and matching the output failure type using deterministic rules of priority ranking. The pseudocode for a classification decision tree is as follows:

[0067] Optionally, multiple failure levels include an ascending sequence of Level 1, Level 2, Level 3, and Level 4. Level 1 indicates only the configuration file has changed, and the corresponding rollback plan includes rolling back the configuration file. Level 2 indicates the target software package conflicts with other installed software packages, and the corresponding rollback plan includes rolling back the target software package and the software packages that conflict with it. Level 3 indicates a severe degradation in system performance, and the corresponding rollback plan includes rolling back the software packages related to the performance degradation (hereinafter referred to as the performance regression package). Level 4 is the highest failure level. By configuring a four-level (e.g., L1-L4) rollback mechanism, the minimum necessary recovery range can be precisely selected based on the failure type, achieving tiered and fine-grained rollback, reducing the risk of excessive rollback, and helping to reduce service interruption time. Specifically, by combining LVM snapshots with package-level rollback, system-level failures (L4) are restored using snapshots, package-level problems (L2-L3) are downgraded using the package manager, and configuration problems (L1) can be directly restored using the original configuration file, balancing recovery speed and impact scope. As an example, for the third level, all packages in the service to which the target package belongs can be identified as performance regression packages, or packages that cause performance degradation can be detected by reasonable methods and identified as performance regression packages. This disclosure does not limit this.

[0068] As an example, this can be combined with the eight failure types mentioned above to create an "8-category × 4-level" rollback strategy matrix, which is automatically selected by the strategy matching engine based on the failure type and health score. The definitions of the four rollback levels are shown in Table 2 below, and the strategy matching matrix is ​​shown in Table 3 below.

[0069] Table 2 Definitions of Four-Level Rollback Levels

[0070] Table 3 Strategy Rollback Matrix

[0071] As an example, each failure type triggers a rollback at the corresponding level only once. As shown in the table above, L2 package conflicts may be dependency conflicts or file conflicts. In actual execution, additional settings can be made to prioritize dependency conflict handling if the same package is both a performance regression package and the root cause of a dependency conflict.

[0072] Optionally, after step 102, the software package rollback method according to an exemplary embodiment of this disclosure further includes: if the health assessment value meets a second preset condition, abandoning the determination of the target failure level and determining the scheme of rolling back the entire file system as the target rollback scheme, wherein the second preset condition is used to indicate that the target software package upgrade has failed and there is a serious anomaly. By directly determining to perform a complete rollback when the upgrade has failed and there is a serious anomaly based on the health assessment value, the computational load of determining the rollback scheme can be reduced, and a rapid response can be achieved, improving the response rate.

[0073] As an example, a weighted sum can be calculated for a preset number of health assessment dimensions to obtain a comprehensive health assessment value. Taking an embodiment including the five health assessment dimensions described above as an example, the corresponding weights are, for example, 0.15, 0.20, 0.10, 0.30, and 0.25. After obtaining the comprehensive health assessment value, a threshold comparison is used to determine whether the first or second preset condition is met. Furthermore, a third preset condition indicating a successful upgrade can be configured. If this condition is met, no rollback is required, thus combining these three preset conditions to classify three health levels. The classification of health levels is shown in Table 4 below.

[0074] Table 4 Health Level Classification

[0075] It should be understood that the range of comprehensive health assessment values ​​for the three health levels in Table 4—healthy, downgraded, and severely abnormal—corresponds to the third, first, and second preset conditions, respectively.

[0076] Optionally, after step 102, the software package rollback method according to an exemplary embodiment of this disclosure further includes: if the decrease in the health assessment value relative to the baseline health assessment value exceeds a decrease threshold, abandoning the determination of the target failure level and the target rollback scheme, and outputting an exception prompt message. By configuring the baseline health assessment value, it is possible to effectively identify anomalies where the absolute value of the health assessment value is high but performance degradation exists, thereby improving the reliability of software upgrade assessment. As an example, the baseline health assessment value may include the baseline value of each health assessment dimension, or it may be the baseline value of the aforementioned comprehensive health assessment value; the baseline health assessment value may be obtained after acquiring software and hardware performance information and conducting health assessments in the same manner before the upgrade; the decrease may be the absolute value of the decrease or the percentage decrease. For example, the five-dimensional health assessment values ​​mentioned above can be collected simultaneously when creating a snapshot, and a comprehensive health assessment value can be calculated as the baseline H_baseline. When assessing after the upgrade, ΔH = H_upgrade - H_baseline is calculated, which is the difference between the upgraded comprehensive health assessment value and the baseline health assessment value. If ΔH < -15 (i.e., the score drops by more than 15 points), that is, the absolute drop exceeds the absolute drop threshold of 15, then even if H_upgrade ≥ 75, it is still considered abnormal, and an abnormal prompt message is output, indicating that further manual investigation is required, and subsequent steps are not executed for the time being.

[0077] The rollback operation itself may also fail (e.g., due to snapshot corruption or missing dependencies of the downgraded package). Optionally, after executing the target rollback scheme on the target software package, the software package rollback method according to an exemplary embodiment of this disclosure further includes: in the event of rollback failure, adjusting the target failure level (e.g., increasing the target failure level, such as including but not limited to increasing it by one or two levels), and re-executing the steps of determining the target rollback scheme corresponding to the target failure level and executing the target rollback scheme on the target software package; and / or, in the event of successful rollback, re-acquiring the system's hardware and software performance information, performing a health assessment on the re-acquired hardware and software performance information to obtain an updated health assessment value, and determining the rollback result information by comparing the updated health assessment value and the original health assessment value. By automatically escalating the failure level after a rollback failure, the rollback surface can be expanded, helping to ensure successful rollback. By performing a health assessment again in the event of a successful rollback, a closed loop of rollback execution and verification can be achieved, ensuring the verifiability of the rollback process. As an example, rollback operations can also employ a transaction model, specifically a three-phase atomic transaction design of "pre-check-execution-verification", coupled with an automatic failure level escalation mechanism and closed-loop verification, to ensure the reliability of the rollback itself.

[0078] As an example, the rollback transaction model can encapsulate each rollback operation (regardless of level) as a transaction: record the state before rollback (snapshot path, package version, configuration hash), record the rollback operation list (each specific step), record the state after rollback (whether the snapshot was successfully released, whether the package version was rolled back), and write the transaction log to a specified file, such as, but not limited to, / var / log / rollback-system / transaction.log.

[0079] As an example, pre-rollback checks may include: checking snapshot integrity before L4 rollback, using dmeventd or lvdisplay to confirm the snapshot status is active; and checking whether an older version of the target package exists in the repository before L2 rollback, using yum / dnf --showduplicates list. <package>Before rolling back L1, check if the backup file exists: `test -f / var / lib / rollback-system / config-backups / ` <file>.

[0080] As an example, automatic escalation upon rollback failure includes: if the L1 rollback fails, automatically escalate to L2 processing; if the L2 rollback fails, automatically escalate to L3 processing; if the L3 / L4 rollback fails, record complete error information, send an alert to the administrator (email / instant messaging software / Web interface notification), and enter the manual intervention process.

[0081] As an example, post-rollback verification includes: performing a complete health assessment (the same process as the post-upgrade assessment), recording H_post_rollback; if H_post_rollback ≥ 75 and H_post_rollback ≥ H_pre_rollback, marking the rollback as successful; if H_post_rollback < H_baseline - 5, marking the rollback as incomplete and prompting a manual check.

[0082] Figure 2 is a schematic flowchart of a software package rollback method according to a specific embodiment of the present disclosure.

[0083] with reference to Figure 2 , this specific embodiment adopts a five-stage closed-loop architecture of "perception-assessment-recognition-decision-execution". After receiving the upgrade instruction, the perception stage is carried out, where the pre-check module is executed first. This module mainly pre-checks the resources used in the upgrade process, for example, checking whether there is sufficient Logical Volume Management (LVM) space for the upgrade. Immediately after passing the pre-check module, a Logical Volume Management snapshot is created. Then the software package upgrade is performed, and after the upgrade is completed, the assessment stage is entered to conduct a multi-dimensional health assessment of the system environment. If the assessment is passed, the current upgrade is completed. If the assessment is not passed, the recognition stage is entered to identify the failure type, and then the decision stage is entered, where the policy matching engine (for example, using the aforementioned "8 categories × 4 levels" rollback policy matrix) matches the failure level and the corresponding rollback policy according to the failure type, and then the execution stage is entered to perform rollback execution. After the rollback is completed, health verification can be performed, that is, the system environment is inspected and health-assessed again. If the health verification is not passed, abnormal prompt information is output to prompt manual participation.

[0084] As an example, the core parameters in the synchronization process exist in the form of a logical structure TerminalSizeFrame, which is encapsulated in, for example, the following structure object:

[0085] The following are three examples of software package upgrade and rollback.

[0086] Example 1: Nginx upgrade failure triggers a full L4 rollback.

[0087] Scenario: After upgrading Nginx, a company's overall health assessment value H = 28 (CRITICAL) and service status dimension S4 = 0 (all services are unavailable).

[0088] The processing flow is as follows.

[0089] 1. Failure type identification: S4<30 → SERVICE_CRASH, priority 2.

[0090] 2. Policy matching: SERVICE_CRASH → L4 full rollback.

[0091] 3. Pre-check: Confirm that the snapshot / dev / vg_root / rollback_20260630_143000_nginx is active.

[0092] 4. Perform a rollback: lvconvert --merge / dev / vg_root / rollback_20260630_143000_nginx, the system will restart automatically.

[0093] 5. Verification: After reboot, H = 92, indicating successful rollback.

[0094] Example 2: Dependency conflict triggers L2 partial rollback.

[0095] Scenario: Dependency conflicts occurred after upgrading PostgreSQL, but core services (Nginx, Redis) are still running normally. H = 68 (DEGRADED), S4 = 80.

[0096] The processing flow is as follows.

[0097] 1. Failure type identification: Logs containing the keyword "file conflicts between" → DEPENDENCY_CONFLICT.

[0098] 2. Policy matching: DEPENDENCY_CONFLICT → L2 partial rollback.

[0099] 3. Pre-check: use `dnf --showduplicates list postgresql` to confirm the existence of a downgradeable version.

[0100] 4. Execute: dnf downgrade postgresql postgresql-libs postgresql-server.

[0101] 5. Verification: H = 91, indicating successful rollback.

[0102] Example 3: Configuration file conflict triggers L1 configuration rollback.

[0103] Scenario: After upgrading HTTPd, the configuration file was overwritten (service status is normal, H = 72), and a change in the configuration hash was detected.

[0104] The processing flow is as follows.

[0105] 1. Failure type identification: S4 ≥ 60, health assessment values ​​of all dimensions ≥ 50, configuration hash change, logs containing the keyword "configuration" → CONFIG_CONFLICT.

[0106] 2. Policy matching: CONFIG_CONFLICT → L1 configuration rollback.

[0107] 3. Pre-check: Backup file / var / lib / rollback-system / config-backups / httpd.conf.md5 exists.

[0108] 4. Execute: cp / var / lib / rollback-system / config-backups / httpd.conf / etc / httpd / conf / httpd.conf.

[0109] 5. Execute: systemctl reload httpd.

[0110] 6. Verification: H = 94, indicating successful rollback.

[0111] Figure 3 This is a block diagram of a software package rollback apparatus according to exemplary embodiments of the present disclosure. (Refer to...) Figure 3 The device includes an acquisition unit 301, an evaluation unit 302, a level determination unit 303, a scheme determination unit 304, and an execution unit 305.

[0112] The acquisition unit 301 is configured to acquire system hardware and software performance information in response to completing the upgrade of the target software package.

[0113] The evaluation unit 302 is configured to perform health evaluations on the hardware and software performance information according to a preset number of health evaluation dimensions, and obtain a health evaluation value for each health evaluation dimension, wherein the preset number is an integer greater than 1.

[0114] The level determination unit 303 is configured to determine a target failure level from multiple failure levels based on the health assessment value when the health assessment value meets a first preset condition, wherein the first preset condition is used to indicate that the target software package upgrade has failed.

[0115] The scheme determination unit 304 is configured to determine the target rollback scheme corresponding to the target failure level. Each failure level is configured with a corresponding rollback scheme. The rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to other failure levels includes rolling back a portion of the files.

[0116] Execution unit 305 is configured to execute a target rollback scheme on the target software package.

[0117] According to the software package rollback device disclosed herein, after the software package upgrade is completed, an independent multi-dimensional health assessment process is introduced to evaluate the upgrade status. Then, when it is determined that the upgrade has failed and the software package needs to be rolled back, a specific rollback plan is determined based on the health assessment results. This decouples fault detection (perception) and rollback decision (judgment), allowing both to be quantified, tested, and optimized independently. This enables convenient software rollback and ensures system state consistency.

[0118] Meanwhile, during health assessments, health evaluation values ​​can be determined based on hardware and software performance information that reflects the system's health status, enabling quantitative scoring. By comprehensively considering multiple evaluation dimensions, the risk of misjudgment caused by assessments based on a single dimension can be reduced, thus improving the reliability of the assessment.

[0119] Furthermore, by employing different granularity rollback schemes for different failure levels—specifically, for the highest failure level, a full file system rollback scheme is used, including but not limited to full system LVM snapshot rollback; for other failure levels, a partial file rollback scheme is used, including but not limited to using a general package manager to roll back software packages—on the one hand, it can automatically select full or partial rollback based on the severity of the failure, avoiding excessive rollback, thereby adjusting the rollback granularity as needed. This improves rollback flexibility and reduces the MTTR (Mean Time To Repair) from hours to minutes compared to a full system reinstall, enabling rapid recovery. On the other hand, since a general package manager can be used for partial rollback, it does not depend on a specific file system, allowing for rollbacks of different granularities on the default file system, thus improving the flexibility of software rollback on the default file system.

[0120] Optionally, the evaluation unit 302 is further configured to: for each health evaluation dimension, obtain the performance parameter value corresponding to that health evaluation dimension from the software and hardware performance information; and determine the health evaluation value for that health evaluation dimension based on the preset parameter range of that health evaluation dimension and the obtained performance parameter value. By combining the preset parameter range of the corresponding health evaluation dimension to quantitatively calculate the health evaluation value, clear and continuous scoring calculation can be achieved.

[0121] Optionally, the preset number of health assessment dimensions includes at least one of the following: system load, memory usage, disk input / output, critical service status, and application log error rate, thereby enabling the evaluation of the software package upgrade from different dimensions.

[0122] Optionally, the level determination unit 303 is further configured to: determine the failure type that matches the health assessment value among multiple failure types based on preset matching rules for multiple failure types as the target failure type, wherein the preset matching rules are used to describe the correspondence between failure types and health assessment values, and each failure type has a unique corresponding failure level; and determine the target failure level based on the failure level corresponding to the target failure type. By automatically identifying failure types based on health assessment results and monitoring data, and matching the corresponding failure level and suitable rollback scheme, automated identification of failure types can be achieved.

[0123] Optionally, multiple failure types have different priorities, each failure level corresponds to at least one failure type, and the level of each failure level is positively correlated with the priority of the failure type corresponding to that failure level. The level determination unit 303 is further configured to: determine the failure type with the highest priority that matches the health assessment value among the multiple failure types as the target failure type based on preset matching rules for multiple failure types. By configuring clear priorities for each failure type, failure type matching can be performed step by step according to priority, solving the decision-making problem in mixed failure scenarios.

[0124] Optionally, the rating determination unit 303 is further configured to determine the highest failure rating as the target failure rating when multiple failure types do not match the health assessment value.

[0125] Optionally, multiple failure levels include an ascending sequence of Level 1, Level 2, Level 3, and Level 4. Level 1 indicates only the configuration file has changed, and the corresponding rollback plan includes rolling back the configuration file. Level 2 indicates the target software package conflicts with other installed software packages, and the corresponding rollback plan includes rolling back both the target software package and any conflicting packages. Level 3 indicates severe system performance degradation, and the corresponding rollback plan includes rolling back the software packages related to the performance degradation. Level 4 is the highest failure level. By configuring a four-level (e.g., L1-L4) rollback mechanism, the minimum necessary recovery scope can be precisely selected based on the failure type, achieving tiered and fine-grained rollback, reducing the risk of excessive rollback, and helping to reduce service interruption time. Specifically, combining LVM snapshots with package-level rollback allows system-level failures (L4) to be restored using snapshots, package-level issues (L2-L3) to be downgraded using the package manager, and configuration issues (L1) to be directly restored using the original configuration file, balancing recovery speed and impact scope.

[0126] Optionally, the scheme determination unit 304 is further configured to: abandon determining the target failure level and determine the scheme of rolling back the entire file system as the target rollback scheme when the health assessment value meets the second preset condition; wherein the second preset condition is used to indicate that the target software package upgrade has failed and there is a serious anomaly; and / or, the software package rollback apparatus according to the exemplary embodiment of this disclosure further includes a prompting unit (not shown in the figure), configured to abandon determining the target failure level and the target rollback scheme and output an anomaly prompt message when the decrease in the health assessment value relative to the baseline health assessment value exceeds a decrease threshold. By directly determining to perform a complete rollback when the upgrade has failed and there is a serious anomaly based on the health assessment value, the computational load of determining the rollback scheme can be reduced, and a rapid response can be achieved, improving the response rate. By configuring the baseline health assessment value, it is possible to effectively identify anomalies where the absolute value of the health assessment value is high but there is a performance degradation, thereby improving the reliability of software upgrade assessment.

[0127] Optionally, the level determination unit 303 is further configured to: adjust the target failure level and rerun the scheme determination unit and the execution unit in the event of a rollback failure; and / or, the software package rollback apparatus according to an exemplary embodiment of this disclosure further includes a verification unit (not shown in the figure), in the event of a successful rollback, the acquisition unit 301 acquires the system's hardware and software performance information again, and the evaluation unit 302 performs a health assessment on the re-acquired hardware and software performance information to obtain an updated health assessment value, and the verification unit determines the rollback result information by comparing the updated health assessment value and the health assessment value. By automatically upgrading the failure level after a rollback failure, the rollback surface can be expanded, which helps to ensure a successful rollback. By performing a health assessment again in the event of a successful rollback, a closed loop of rollback execution and verification can be achieved, ensuring the verifiability of the rollback process.

[0128] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0129] According to embodiments of this disclosure, an electronic device may be provided. Figure 4 This is a block diagram of an electronic device 400 according to an embodiment of the present disclosure. The electronic device includes at least one memory 401 and at least one processor 402. The at least one memory stores a set of computer-executable instructions 4011 and an operating system 4012. When the set of computer-executable instructions 4011 is executed by the at least one processor 402, a software package rollback method according to an embodiment of the present disclosure is executed.

[0130] As an example, electronic device 400 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 400 is not necessarily a single electronic device, but may be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 400 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0131] In electronic device 400, processor 402 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 402 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0132] The processor 402 can execute instructions or code stored in memory, and the memory 401 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0133] The memory 401 may be integrated with the processor 402, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 401 may include a separate device, such as an external disk drive, a storage array, or other storage device that can be used by any database system. The memory 401 and the processor 402 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 402 to read files stored in the memory 401.

[0134] In addition, the electronic device 400 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0135] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform a software package rollback method according to embodiments of this disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R, BD-R The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agents, and servers. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, allowing the computer program and any associated data, data files, and data structures to be stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0136] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, which, when executed by a processor, implement the software package rollback method of the embodiment of this disclosure.

[0137] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0138] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.< / file> < / package> < / timestamp>

Claims

1. A software package rollback method, characterized in that, include: In response to the completion of the target software package upgrade, obtain the system's hardware and software performance information; The hardware and software performance information is evaluated according to a preset number of health evaluation dimensions to obtain a health evaluation value for each health evaluation dimension, wherein the preset number is an integer greater than 1. If the health assessment value meets the first preset condition, a target failure level is determined from multiple failure levels based on the health assessment value, wherein the first preset condition is used to indicate that the target software package upgrade has failed; Determine the target rollback scheme corresponding to the target failure level, wherein each failure level is configured with a corresponding rollback scheme, the rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to other failure levels includes rolling back a portion of the files; The target rollback scheme is executed on the target software package.

2. The software package rollback method as described in claim 1, characterized in that, The process of performing a health assessment on the software and hardware performance information according to a preset number of health assessment dimensions, and obtaining a health assessment value for each health assessment dimension, includes: For each health assessment dimension, obtain the performance parameter value corresponding to that health assessment dimension from the software and hardware performance information; Based on the preset parameter range and the obtained performance parameter values ​​of this health assessment dimension, the health assessment value of this health assessment dimension is determined.

3. The software package rollback method as described in claim 1, characterized in that, The preset number of health assessment dimensions include at least one of the following: system load, memory usage, disk input / output, critical service status, and application log error rate.

4. The software package rollback method as described in claim 1, characterized in that, The step of determining a target failure level from multiple failure levels based on the health assessment value includes: Based on preset matching rules for multiple failure types, the failure type that matches the health assessment value among the multiple failure types is determined as the target failure type. The preset matching rules are used to describe the correspondence between failure types and health assessment values, and each failure type has a unique corresponding failure level. The target failure level is determined based on the failure level corresponding to the target failure type.

5. The software package rollback method as described in claim 4, characterized in that, The multiple failure types have different priorities, each failure level corresponds to at least one failure type, and the level of each failure level is positively correlated with the priority of the failure type corresponding to that failure level. The step of determining the failure type that matches the health assessment value among the multiple failure types based on a preset matching rule for the multiple failure types includes: Based on preset matching rules for multiple failure types, the failure type that matches the health assessment value and has the highest priority among the multiple failure types is determined as the target failure type.

6. The software package rollback method as described in claim 5, characterized in that, The step of determining the target failure level from multiple failure levels based on the health assessment value further includes: If none of the multiple failure types match the health assessment value, the highest failure level will be determined as the target failure level.

7. The software package rollback method as described in claim 1, characterized in that, The multiple failure levels include an increasing first level, second level, third level, and fourth level; Wherein, the first level indicates that only the configuration file changes, and the rollback scheme corresponding to the first level includes the scheme of rolling back the configuration file; The second level indicates that the target software package conflicts with other installed software packages. The rollback scheme corresponding to the second level includes a scheme to roll back the target software package and the software packages that conflict with the target software package. The third level indicates a severe degradation in system performance, and the rollback scheme corresponding to the third level includes rolling back software packages related to the performance degradation. The fourth level is the highest failure level.

8. The software package rollback method as described in claim 1, characterized in that, After performing health assessments on the software and hardware performance information according to a preset number of health assessment dimensions to obtain the health assessment value for each health assessment dimension, the software package rollback method further includes: If the health assessment value meets the second preset condition, the determination of the target failure level is abandoned, and the scheme of rolling back the entire file system is determined as the target rollback scheme, wherein the second preset condition is used to indicate that the target software package upgrade failed and there is a serious anomaly; and / or If the decrease in the health assessment value relative to the baseline health assessment value exceeds the decrease threshold, the determination of the target failure level and the target rollback plan is abandoned, and an abnormal prompt message is output.

9. The software package rollback method according to any one of claims 1 to 8, characterized in that, After the step of executing the target rollback scheme on the target software package, the method further includes: In the event of a rollback failure, adjust the target failure level and re-execute the steps of determining the target rollback scheme corresponding to the target failure level and executing the target rollback scheme on the target software package; and / or If the rollback is successful, the system's hardware and software performance information is retrieved again, and a health assessment is performed on the retrieved hardware and software performance information to obtain an updated health assessment value. By comparing the updated health assessment value with the original health assessment value, the rollback result information is determined.

10. A software package rollback device, characterized in that, The software package rollback device includes: The acquisition unit is configured to acquire system hardware and software performance information in response to completing the upgrade of the target software package; The evaluation unit is configured to perform a health evaluation on the software and hardware performance information according to a preset number of health evaluation dimensions, and obtain a health evaluation value for each health evaluation dimension, wherein the preset number is an integer greater than 1; The level determination unit is configured to determine a target failure level from multiple failure levels based on the health assessment value when the health assessment value meets a first preset condition, wherein the first preset condition is used to indicate that the target software package upgrade has failed; The scheme determination unit is configured to determine the target rollback scheme corresponding to the target failure level, wherein each failure level is configured with a corresponding rollback scheme, the rollback scheme corresponding to the highest failure level includes rolling back the entire file system, and the rollback scheme corresponding to other failure levels includes rolling back a portion of the files. The execution unit is configured to execute the target rollback scheme on the target software package.

11. An electronic device, characterized in that, include: At least one processor; At least one memory that stores computer-executable instructions. The computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform the software package rollback method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, they cause the at least one processor to perform the software package rollback method as described in any one of claims 1 to 9.

13. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by at least one processor, they cause the at least one processor to perform the software package rollback method as described in any one of claims 1 to 9.

Images