A DevOps-based server firmware remote upgrading method and system

Abstract

This invention relates to the field of server technology and discloses a DevOps-based method and system for remote server firmware upgrades. The system includes: a data acquisition unit that matches the target firmware version based on device identification information and constructs a state parameter set corresponding to the server; a processing unit that performs weighted calculations on the normalized data, generating an execution instruction and sending it to the out-of-band management interface if the upgrade capability boundary value meets the execution conditions, and generating a restriction instruction and writing the upgrade task into a pending queue if the upgrade capability boundary value does not meet the execution conditions; an execution unit that performs firmware upgrades on the server based on the out-of-band management interface and controls the firmware upgrade based on offset generation process instructions; and an update unit that acquires the upgrade result data, associates it with the updated state parameter set, and writes the adjusted weighted calculations into the policy configuration. This invention ensures the stability of remote server firmware upgrades.

Description

Technical Field

[0001] This invention relates to the field of server technology, and more specifically, to a method and system for remote server firmware upgrade based on DevOps. Background Technology

[0002] In data center and cloud computing environments, server firmware is uniformly scheduled through DevOps pipelines and remotely upgraded via out-of-band management interfaces. However, server firmware upgrades involve multiple components, including BIOS, BMC, and peripheral control firmware. These components are interdependent, and the server firmware operates in different states during upgrades. Existing remote upgrade methods lack unified management of these multi-dimensional states and quantitative constraints on upgrade capability boundaries, relying solely on static rules to trigger upgrade tasks. This leads to upgrades being performed even when the device is in an unsuitable state. Furthermore, the lack of dynamic control mechanisms based on real-time state changes during upgrade execution prevents adjustments or interruptions to subsequent upgrade tasks when abnormal trends emerge. This can cause local anomalies to escalate into batch failures. Additionally, the separation of state acquisition and decision-making control during the upgrade process fails to create a robust closed-loop control system, resulting in insufficient stability for remote server firmware upgrades.

[0003] Therefore, it is necessary to design a DevOps-based method and system for remote server firmware upgrades to address the problems existing in current technologies. Summary of the Invention

[0004] In view of this, the present invention proposes a DevOps-based method and system for remote server firmware upgrade, aiming to solve the above-mentioned problems.

[0005] In one aspect, this invention proposes a DevOps-based remote server firmware upgrade system, comprising: The acquisition unit is configured to acquire the server's device identification information, current firmware version information, and running status data, match the target firmware version based on the device identification information, and construct a status parameter set corresponding to the server. The processing unit is configured to normalize each data in the state parameter set, perform weighted calculation on the normalized data, determine the upgrade capability boundary value, generate an execution instruction and send it to the out-of-band management interface if the upgrade capability boundary value meets the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue if the upgrade capability boundary value does not meet the execution conditions, and re-collect the server's running status data based on the waiting time and perform weighted calculation. The execution unit is configured to perform firmware upgrades on the server based on the out-of-band management interface, update the status parameter set, determine real-time capability boundary values, determine an offset based on the real-time capability boundary values ​​and the upgrade capability boundary values, and perform control processing on the firmware upgrade based on the offset generation process instructions. The control processing includes pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. The update unit is configured to, after completing the firmware upgrade or executing the control process, obtain upgrade result data and associate it with the updated state parameter set, adjust the weighted calculation based on the association result, and write the adjusted weighted calculation into the strategy configuration.

[0006] Furthermore, in constructing the state parameter set, the following steps are included: the acquisition unit divides the device identification information of the server into a hardware identification field and a firmware identification field; divides the operating status data into several operating status fields based on the data type; constructs a time series for each operating status field based on the acquisition time; aligns the data in the time series; determines the change amount based on adjacent sampled data in the aligned time series; combines the change amount with the baseline feature amount corresponding to the next sampled data to determine a two-dimensional feature set; encodes and maps the discrete data in the two-dimensional feature set; and establishes a data index relationship based on the hardware identification field, the firmware identification field, and each operating status field to determine the state parameter set.

[0007] Furthermore, when determining the upgrade capability boundary value, the process includes: the processing unit determining a feature sequence corresponding one-to-one with each running status field based on the data index relationship; arranging the data in the feature sequence according to the field order; segmenting and combining the feature sequences corresponding to the same running status field to determine a field feature subset; grouping the field feature subset based on the hardware identifier field, firmware identifier field, and running status field; and performing a weighted calculation on the grouping results to determine the upgrade capability boundary value.

[0008] Furthermore, in determining whether the upgrade capability boundary value meets the execution conditions, the processing unit compares the upgrade capability boundary value with the upgrade capability boundary threshold. If the upgrade capability boundary value is less than the upgrade capability boundary threshold, the upgrade capability boundary value is determined to meet the execution conditions. If the upgrade capability boundary value is greater than or equal to the upgrade capability boundary threshold, the upgrade capability boundary value is determined not to meet the execution conditions.

[0009] Furthermore, when determining the real-time capability boundary value, the process includes: the execution unit acquiring the target operating status data of the server during firmware upgrade, writing the target operating status data into the corresponding time series, determining the extended time series, and determining the real-time capability boundary value based on the extended time series.

[0010] Furthermore, when the generation process instruction controls the firmware upgrade, it includes: the execution unit sets a first offset threshold and a second offset threshold, wherein the first offset threshold is less than the second offset threshold; if the offset is less than or equal to the first offset threshold, then based on the relationship between the offset and the first offset threshold, it determines whether to generate an instruction corresponding to path switching or continue the firmware upgrade; if the offset is greater than the first offset threshold and less than the second offset threshold, then it generates an instruction corresponding to pause the upgrade; if the offset is greater than or equal to the second offset threshold, then it generates an instruction corresponding to terminate the upgrade.

[0011] Furthermore, when acquiring upgrade result data and associating it with the updated state parameter set, the process includes: the update unit matching the upgrade result data and the updated state parameter set based on the updated data index relationship to determine the associated dataset; determining several candidate itemsets based on the Eclat algorithm and the associated dataset; determining frequent itemsets based on the support of the candidate itemsets; and determining the association result based on the frequent itemsets.

[0012] Furthermore, when adjusting the weighted calculation based on the association results and writing the adjusted weighted calculation into the strategy configuration, the process includes: the update unit extracting association feature combinations based on the association results, mapping the association feature combinations to corresponding field positions based on the updated data index relationship, dividing the distribution of the association feature combinations in the extended time series, determining the extended time intervals, grouping the data in each extended time interval, determining field association data groups, adjusting the weighted calculation based on the field association data groups, and writing the adjusted weighted calculation into the storage location corresponding to each field in the strategy configuration.

[0013] Furthermore, the DevOps-based remote server firmware upgrade system further includes: after adjusting the weighted calculation based on the field-related data group, the update unit segments and stores each field in the strategy configuration based on the field type.

[0014] Compared with existing technologies, the advantages of this invention are as follows: It synchronously acquires the server's device identification information, current firmware version information, and operating status data, quickly matches the target firmware version, and constructs a status parameter set. This avoids the tedious process of manually verifying information and manually matching firmware, automating data collection and preparation before upgrades, thus adapting to the DevOps operation and maintenance system. By determining upgrade capability boundary values ​​through normalization processing and weighted calculation, it intelligently judges upgrade feasibility. If the conditions are met, execution instructions are directly issued through the out-of-band management interface; otherwise, restriction instructions are generated and added to the waiting queue. Combined with waiting time, the calculation is recalculated, avoiding hardware failures caused by blind upgrades and automatically retrying, thereby ensuring the reliability of upgrade scheduling. Remote upgrades are completed based on the out-of-band management interface, and corresponding process instructions are generated to achieve dynamic control of pause, termination, or path switching, ensuring the stability of the upgrade process. After the upgrade is completed or the control process is finished, the upgrade result data is correlated with the updated status parameter set, the weighted calculation is adjusted in reverse and written into the strategy configuration, realizing the system's self-optimization iteration, which meets the requirements of DevOps continuous integration and continuous optimization, improves the automation level, control accuracy and operation and maintenance efficiency of remote server firmware upgrades, and thus forms a closed-loop firmware upgrade control system, ensuring the stability of remote server firmware upgrades.

[0015] On the other hand, this application also provides a DevOps-based remote server firmware upgrade method for applying the aforementioned DevOps-based remote server firmware upgrade system, including: Obtain the server's device identification information, current firmware version information, and running status data; match the target firmware version based on the device identification information; and construct a status parameter set corresponding to the server. Normalize each data in the state parameter set, and perform weighted calculation on the normalized data to determine the upgrade capability boundary value. If the upgrade capability boundary value meets the execution conditions, generate an execution instruction and send it to the out-of-band management interface. If the upgrade capability boundary value does not meet the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue. Based on the waiting time, re-collect the server's running status data and perform weighted calculation. The server is upgraded using the out-of-band management interface, and the status parameter set is updated to determine the real-time capability boundary value. An offset is determined based on the real-time capability boundary value and the upgrade capability boundary value. The firmware upgrade is controlled based on the offset generation process instructions. The control process includes pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. After completing the firmware upgrade or executing the control process, the upgrade result data is obtained and associated with the updated state parameter set. The weighted calculation is adjusted based on the association result, and the adjusted weighted calculation is written into the strategy configuration.

[0016] It is understandable that the DevOps-based remote server firmware upgrade method and system described above have the same beneficial effects, and will not be elaborated further here. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A functional block diagram of a DevOps-based remote server firmware upgrade system provided in this embodiment of the invention; Figure 2 A flowchart illustrating a DevOps-based remote server firmware upgrade method provided in this embodiment of the invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, 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.

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] See Figure 1 As shown in some embodiments of this application, a DevOps-based remote server firmware upgrade system includes: The acquisition unit is configured to acquire the server's device identification information, current firmware version information, and running status data, match the target firmware version based on the device identification information, and construct a set of status parameters corresponding to the server. The processing unit is configured to normalize each data in the status parameter set, perform weighted calculation on the normalized data, determine the upgrade capability boundary value, generate an execution instruction and send it to the out-of-band management interface if the upgrade capability boundary value meets the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue, and re-collect the server's running status data based on the waiting time and perform weighted calculation. The execution unit is configured to perform firmware upgrades on the server based on the out-of-band management interface, update the status parameter set, determine the real-time capability boundary value, determine the offset based on the real-time capability boundary value and the upgrade capability boundary value, and control the firmware upgrade based on the offset generation process instructions. The control process includes pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. The update unit is configured to obtain upgrade result data and associate it with the updated state parameter set after completing firmware upgrade or performing control processing, adjust the weighted calculation based on the association result, and write the adjusted weighted calculation into the strategy configuration.

[0022] Specifically, device identification information represents exclusive data used to uniquely identify a single server, such as the server's unique serial number (SN), the server motherboard's unique hardware ID, the physical location code of the rack within the data center, and the server model code. Current firmware version information represents the existing version information of the BIOS, BMC, and various peripheral control firmware installed on the server, such as the server motherboard BIOS firmware version V2.4.1, the out-of-band management BMC firmware version V3.1.0, the RAID card peripheral control firmware version V1.7.5, and the network card firmware version V2.0.The parameters of existing firmware versions such as version 3, and the running status data represent the actual operating conditions of the server at the current moment, such as the server's real-time CPU load status, memory usage status, power supply stability, cooling fan speed, overall operating temperature, system fault-free uptime, and service load. Based on the device identification information, a suitable target firmware version is accurately matched for the server. The target firmware version is the optimally matched official firmware version selected based on the server's unique hardware attributes, the shortcomings of the existing firmware version, and the maintenance and upgrade requirements. Simultaneously, a set of status parameters is constructed based on the device identification information, the current firmware version information, and the running status data to achieve... The system now unifies and manages multi-dimensional server operation and device status, locking in device compatibility from the source and avoiding upgrade risks caused by firmware mismatch. Normalization transforms various data of different dimensions and magnitudes in the status parameter set into data of a unified standard dimension, eliminating dimensional differences and magnitude conflicts between different data. Simultaneously, weighted calculations consider the actual impact of various data on the feasibility of firmware upgrades. Each normalized data item is assigned a corresponding weight and a comprehensive calculation is performed. The upgrade capability boundary value, obtained through normalization and weighted calculations, is used to quantitatively determine whether the server is currently suitable for a firmware upgrade. The execution condition is a pre-set boundary value used by the processing unit to determine the upgrade capability. The criteria for determining whether a task meets the direct upgrade requirements are defined. The pending processing queue is a dedicated task storage queue used to temporarily store upgrade tasks that do not yet meet the upgrade conditions. The processing unit first normalizes all data in the status parameter set, then performs weighted calculations on all normalized data, and finally compares the upgrade capability boundary value with the execution conditions. If the upgrade capability boundary value meets the execution conditions, the processing unit directly generates an execution command to initiate the upgrade operation and sends the command to the server's out-of-band management interface. The out-of-band management interface is a dedicated interface that does not depend on the server's main operating system and can independently implement remote firmware control, management, and communication with the server. If the upgrade capability boundary value does not meet the execution conditions, the processing unit... This process generates a restriction command to pause the current upgrade task, adds the upgrade task to the pending queue, and then re-collects the server's operational status data after the waiting time expires. The normalization and weighted calculation process is repeated to reassess the upgrade feasibility. The waiting time is related to the urgency of the current upgrade task; the more urgent the task, the shorter the waiting time. By replacing the original static upgrade rules with quantified upgrade capability boundary values, precise triggering of upgrade tasks is achieved, avoiding the risk of forcibly performing upgrade operations when the device is in an unsuitable upgrade state. The cyclical mechanism of the pending queue balances upgrade scheduling efficiency and server operational security, ensuring the stability of remote server firmware upgrades.

[0023] Understandably, after the processing unit completes the instruction issuance, the execution unit performs firmware upgrades on the server based on the out-of-band management interface. The real-time capability boundary value represents the value recalculated using the updated state parameter set during the firmware upgrade process, reflecting the server's real-time upgrade adaptability and operating conditions. The offset represents the difference between the real-time capability boundary value and the upgrade capability boundary value. The process instruction is a special operation instruction generated based on the offset size, used to control the firmware upgrade process in real time. The backup upgrade path represents the backup control channel that the system can use to complete the firmware upgrade, in addition to the main upgrade control channel. The execution unit first performs firmware upgrade operations on the server using the out-of-band management interface, and updates the corresponding state parameter set synchronously during the upgrade process. Then, it determines the real-time capability boundary value based on the updated state parameter set. The process of determining the real-time capability boundary value is consistent with the process of determining the upgrade capability boundary value. The offset is determined based on the difference between the real-time capability boundary value and the upgrade capability boundary value. The offset represents the difference between the real-time capability boundary value during the firmware upgrade process and the upgrade capability boundary value before the upgrade starts. Based on the process instructions corresponding to the offset generation, targeted control processing is performed on the firmware upgrade process using these instructions. The control processing includes three operation modes: pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. This overcomes the deficiency of real-time dynamic status control mechanisms in existing technologies, allowing for timely intervention and regulation as soon as abnormal upgrade trends appear, preventing small local anomalies from gradually spreading into large-scale batch failures, thereby improving the controllability and stability of the upgrade process. The upgrade result data represents the final completion status of this firmware upgrade or all data after executing the control processing. The policy configuration represents the data used for... The configuration file contains the weighted calculation rules and execution condition judgment criteria for the storage upgrade decision-making process. After the firmware upgrade is completed, or after the execution unit completes the control processing of pausing the upgrade, terminating the upgrade, or switching to the backup upgrade path, the update unit is first responsible for obtaining the upgrade result data of this upgrade process, and establishing a correlation between the upgrade result data and the updated status parameter set. Based on the correlation result, the weighted calculation rules used by the processing unit are adjusted and optimized accordingly. Finally, the adjusted and improved weighted calculation rules are written into the policy configuration, thereby completing the closed-loop management of the entire upgrade process. This constructs a complete closed-loop control system that fits DevOps, optimizing decisions through the actual results of each data-driven upgrade, thereby continuously improving the overall stability of remote server firmware upgrades.

[0024] In some embodiments of this application, the construction of the state parameter set includes: the acquisition unit dividing the server's device identification information into a hardware identification field and a firmware identification field; dividing the running status data into several running status fields based on the data type; constructing a time series for each running status field based on the acquisition time; aligning the data in the time series; determining the change amount based on adjacent sampled data in the aligned time series; combining the change amount with the baseline feature amount corresponding to the next sampled data to determine a two-dimensional feature set; encoding and mapping the discrete data in the two-dimensional feature set; and establishing a data index relationship based on the hardware identification field, the firmware identification field, and each running status field to determine the state parameter set.

[0025] Specifically, the acquisition unit performs fine-grained segmentation of the acquired server device identification information, dividing it into hardware identification fields and firmware identification fields. The hardware identification field represents dedicated fields used to identify the attributes of the server hardware itself, such as the corresponding server motherboard model, hardware serial number, and other detailed data items. The firmware identification field represents dedicated fields used to distinguish the basic attributes of various server firmware, such as the detailed data items indicating the current version of peripheral control firmware like BIOS and BMC. The acquisition unit also performs classification processing on the operational status data, splitting the originally integrated operational status data into several operational status fields based on the data's own type attributes. Each operational status field represents an independent data field corresponding to a single dimension of operational status. For example, different types of operational data such as CPU load, memory usage, heat dissipation temperature, and power supply status are each split into independent corresponding operational status fields. For instance, the operational status field corresponding to CPU load is cpu_core_load, which specifically stores the actual operational information of the server's CPU core load, and the operational status field corresponding to memory usage is mem_occupied_ratio, which specifically stores the actual operational information of the server's memory usage ratio, and so on. The acquisition unit uses the data acquisition time of each running status field as a basis, arranging the data collected at different time points under the same running status field in chronological order to construct a time series for the corresponding running status field. The time series is a sequence of running status data of the same dimension arranged according to a fixed acquisition time order. The acquisition unit performs alignment processing on the time series corresponding to each running status field. This alignment process uniformly adjusts the time series of different running status fields to the same sampling time, avoiding misalignment of running status data of different dimensions due to inconsistent acquisition times. For example, the sampling time points of CPU load time series and memory usage time series are uniformly aligned to the same moment at fixed intervals, ensuring that various running status data under the same time node can correspond and match. After alignment, for each group of aligned data... The time series data is extracted and compared between two adjacent sets of sampled data. Two adjacent sets of sampled data represent two consecutive sets of operational status data collected sequentially within the same operational status field. Taking the time series for the operational status field corresponding to CPU load as an example, this time series is recorded sequentially according to the collection time: the first set of CPU load data, the second set of CPU load data, the third set of CPU load data, and so on. The first and second sets of sampled data constitute a pair of adjacent sets. The change between these two sets of data is determined; this change represents the fluctuation amplitude and degree of difference between two adjacent sets of data under the same operational status field, which can intuitively reflect the stability of that operational status.The acquisition unit combines the obtained change with the baseline feature value corresponding to the next sampled data in the adjacent data set. The baseline feature value represents the basic feature value inherent in the operating status data obtained from a single sample, such as the CPU core load feature value obtained from a single sample in the operating status field corresponding to CPU load, including data such as CPU instruction execution cycle. By bidirectionally combining the change with the baseline feature value, the two-dimensional feature set represents a two-dimensional feature dataset that simultaneously contains the real-time baseline feature of the operating status and the status fluctuation change feature. It can simultaneously reflect the current level and dynamic change trend of the operating status, avoiding the problem that single data cannot reflect status fluctuations. The acquisition unit performs encoding mapping processing on the discrete data contained in the two-dimensional feature set. Discrete data is non-continuous data that does not have continuous numerical attributes and exists in the form of classification or identification. Encoding mapping transforms this type of discrete data, which cannot be directly used in quantitative calculations, into system identification. Furthermore, standardized data formats are used in subsequent calculations. For example, discrete classification data such as "normal" and "abnormal" in server power supply status are converted into a standardized format through encoding and mapping. The acquisition unit establishes a dedicated data index relationship based on the hardware identifier field, firmware identifier field, and the corresponding relationship between various operating status fields. Hardware, firmware, and operating status data are bound one-to-one, enabling quick location of other fields through any one field. This is ultimately integrated into a status parameter set. Field subdivision achieves the classification and organization of various data types, avoiding the confusion and chaos of multi-dimensional data. Moreover, time series construction and alignment processing solve the risk of misaligned acquisition times and inability to synchronize and compare operating status data from different dimensions. This preserves real-time baseline information of the operating status while capturing status change trends, ensuring that the status parameter set fully reflects the actual operating conditions of the server and further improving the stability of remote server firmware upgrades.

[0026] In some embodiments of this application, determining the upgrade capability boundary value includes: a processing unit determining a feature sequence that corresponds one-to-one with each running status field based on a data index relationship, arranging each data in the feature sequence based on the field order, and segmenting and combining the feature sequences corresponding to the same running status field to determine a subset of field features, grouping the subset of field features based on the hardware identifier field, firmware identifier field, and running status field, and performing a weighted calculation on the grouping results to determine the upgrade capability boundary value.

[0027] Specifically, based on the established data index relationship, the processing unit accurately retrieves and determines the feature sequences that correspond one-to-one with each running status field. The feature sequence is a continuous feature dataset formed by the running status field, containing the baseline feature quantity and the change quantity in the two-dimensional feature set. For example, the running status field corresponding to CPU load will be matched to form a dedicated CPU load feature sequence, and the running status field corresponding to memory usage will be matched to form a dedicated memory usage feature sequence. The processing unit arranges the data in the feature sequence according to the field order. The field order represents the pre-set sorting rules for each running status field, which can ensure that the data arrangement of different feature sequences follows a unified standard and avoid data layout chaos. The processing unit will perform segmentation and combination operations on the feature sequences corresponding to the same running status field. Segmentation and combination is to divide a single feature sequence into multiple data segments according to the generation time or feature type of the feature data, and then integrate the multiple data segments into a unified whole dataset, that is, the field feature subset. The field feature subset represents the dedicated feature dataset formed by the segmentation and combination of the feature sequence corresponding to a single running status field, which can realize the modular collection of feature data of a single running status dimension.Based on the category attributes of the hardware identifier field, firmware identifier field, and operating status field, all generated field feature subsets are grouped. The grouping result is a categorized dataset formed by classifying the field feature subsets according to three major categories: hardware, firmware, and operating status. This enables the classification, isolation, and centralized management of feature data across different dimensions. The processing unit performs a weighted calculation on the resulting grouping results. The weights are determined based on the hardware compatibility constraints corresponding to the hardware identifier field, the firmware compatibility necessity corresponding to the firmware identifier field, and the operating status security impact degree corresponding to the operating status field. The higher the constraint level of firmware upgrade feasibility, the higher the corresponding weight. The data used for the weighted calculation is the data of each group of field feature subsets obtained by the processing unit after grouping by the hardware identifier field, firmware identifier field, and operating status field. For example, for a rack server in a data center, the field feature subset of the group corresponding to the hardware identifier field includes server motherboard hardware compatibility features and machine architecture matching features. This group serves as the physical basis for firmware upgrades and has the highest constraint level. Therefore, based on the core constraint role of hardware compatibility, this group is determined to have the highest weight. The feature subset of the group includes target firmware version compatibility features and existing BMC firmware matching features. This group serves as a software prerequisite for upgrade execution and has the second highest constraint level. Therefore, based on the necessary constraint of firmware compatibility, this group is determined to have the second highest weight. The feature subset of the group corresponding to the running status field includes CPU load stability features, heat dissipation temperature compliance features, and power supply stability features. This group serves as a safety condition for upgrade timing and has a normal constraint level. Therefore, based on the auxiliary constraint of running status, this group is determined to have a normal weight. The processing unit retrieves data from the feature subsets of the hardware group, firmware group, and running status group, and combines the feature data of each group with the corresponding determined weights for weighted calculation to finally determine the upgrade capability boundary value. Retrieving feature sequences based on data index relationships ensures the accuracy and relevance of data sources. Arranging data according to field order ensures the standardization and uniformity of data processing. Grouping feature subsets based on hardware identifier field, firmware identifier field, and running status field can distinguish the influence weights of data from different dimensions, avoiding interference from multi-dimensional data in the calculation results, and providing a data foundation for the execution determination of subsequent upgrade tasks.

[0028] In some embodiments of this application, when determining whether the upgrade capability boundary value meets the execution conditions, the process includes: the processing unit compares the upgrade capability boundary value with the upgrade capability boundary threshold; if the upgrade capability boundary value is less than the upgrade capability boundary threshold, the upgrade capability boundary value is determined to meet the execution conditions; if the upgrade capability boundary value is greater than or equal to the upgrade capability boundary threshold, the upgrade capability boundary value is determined not to meet the execution conditions.

[0029] Specifically, the upgrade capability boundary threshold is a pre-set value based on the server firmware upgrade security operation and maintenance specifications, hardware capacity limits, business operation stability requirements, and unified standards for data center batch upgrades. It serves as a critical threshold to distinguish between feasible and infeasible upgrade states and is also a reference standard for determining whether the upgrade capability boundary value meets the requirements for initiating an upgrade. For example, for rack servers carrying core cloud services, the upgrade capability boundary threshold is set based on the server model's thermal safety threshold, power supply stability baseline, and firmware compatibility hardware constraints. The processing unit compares the upgrade capability boundary value with the pre-configured threshold. When the upgrade capability boundary value is less than the threshold value, the processing unit determines that the upgrade capability boundary value meets the upgrade initiation requirements and thus determines that the execution conditions are met. At this point, it indicates that the server's hardware compatibility, firmware compatibility, and operating conditions are all within a safe upgrade range, and there are no risks affecting firmware upgrade execution, thus enabling the upgrade to proceed. The basic condition for upgrade operation is that when the upgrade capability boundary value is greater than or equal to the upgrade capability boundary threshold, the processing unit determines that the upgrade capability boundary value does not meet the upgrade start requirements, and thus determines that the execution conditions are not met. At this time, it means that there is an upgrade risk in the server's hardware adaptation, firmware compatibility, or operating status, and the firmware upgrade cannot be directly started. By using the upgrade capability boundary threshold to achieve a unified and standardized judgment across the entire server, the error and blindness caused by human subjective judgment are eliminated, so that the result of the upgrade feasibility judgment has an objective and unified basis, thereby improving the response efficiency of firmware upgrade scheduling and ensuring the overall security of server hardware, firmware, and business operation.

[0030] In some embodiments of this application, determining the real-time capability boundary value includes: the execution unit acquiring the target running status data of the server during firmware upgrade, writing the target running status data into the corresponding time series, determining the extended time series, and determining the real-time capability boundary value based on the extended time series.

[0031] Specifically, during the ongoing firmware upgrade process, the execution unit collects and acquires the target operating status data of the server in real time. This target operating status data represents the operating status data generated during the firmware upgrade process, in dynamic scenarios such as firmware writing, component initialization, and hardware adaptation and debugging. For example, CPU load data, chip power supply fluctuation data, and motherboard heat dissipation temperature changes during the firmware burning stage are all considered target operating status data. The execution unit accurately writes this real-time acquired target operating status data into a pre-constructed time series based on the corresponding operating status field, adding real-time acquisition data to the existing time series. The data content is used to determine the extended time series. Based on the generated extended time series, the real-time capability boundary value during the firmware upgrade process is determined synchronously according to the previous calculation process of upgrade capability boundary value. By acquiring target operating status data in real time during the upgrade process, the actual operating status of the server under the dynamic scenario of firmware upgrade can be accurately captured. The target operating status data is written into the original time series to form an extended time series, retaining the historical change trajectory of the operating status and combining it with real-time data. This ensures that the real-time capability boundary value can fit the actual working conditions during the upgrade process, providing data support for dynamic control during the upgrade process and preventing the risk of hardware failure or business interruption caused by abnormal status during the firmware upgrade process.

[0032] In some embodiments of this application, when generating process instructions to control firmware upgrades, the following steps are included: the execution unit sets a first offset threshold and a second offset threshold, wherein the first offset threshold is less than the second offset threshold; if the offset is less than or equal to the first offset threshold, the unit determines whether to generate an instruction corresponding to path switching or continue firmware upgrade based on the relationship between the offset and the first offset threshold; if the offset is greater than the first offset threshold and less than the second offset threshold, the unit generates an instruction corresponding to pause upgrade; and if the offset is greater than or equal to the second offset threshold, the unit generates an instruction corresponding to terminate upgrade.

[0033] Specifically, the execution unit pre-sets a first offset threshold and a second offset threshold. When the offset is less than or equal to the first offset threshold, it indicates that the deviation of the server's operating state from the baseline state is within a safe and controllable range, and there is no substantial upgrade risk. At this time, the execution unit will further determine the ratio between the first offset threshold and the offset based on the specific numerical relationship between the offset and the first offset threshold. If the ratio is greater than or equal to 1.5, it means that the offset is relatively small, and the firmware upgrade instruction continues. If the ratio is less than 1.5, it means that the offset is relatively large, and the corresponding instruction for path switching is generated. That is, under the premise that the upgrade state is stable, the system switches to the backup upgrade path. When the offset is greater than the first offset threshold but less than the second offset threshold, it means that the deviation of the server's operating state exceeds a certain safe fluctuation range, and a moderate upgrade risk occurs, but it has not yet reached the hardware safety tolerance limit. At this time, the execution unit will generate the corresponding instruction for pausing the upgrade. The system generates an instruction to temporarily interrupt the firmware upgrade process, preserving the current upgrade progress and waiting for the server's operating state to return to a safe range before restarting the upgrade. When the offset value is greater than or equal to the second offset threshold, it indicates that the deviation of the server's operating state has reached the hardware's safety tolerance limit. Continuing the upgrade would lead to serious security incidents such as hardware damage, firmware burning failure, or service interruption. The execution unit will then generate an instruction to terminate the upgrade, directly stopping all execution operations of the current firmware upgrade and providing security protection for the server's hardware. Differentiated instructions are matched to different degrees of operating state deviation. This ensures upgrade execution efficiency during minor fluctuations, timely pauses to avoid potential risks during moderate risks, and forced termination to protect the hardware during severe risks. This constructs a multi-layered dynamic security protection system for firmware upgrades, accurately balancing the execution efficiency of firmware upgrades with the operational security of server hardware and services, further ensuring the stability of remote server firmware upgrades.

[0034] In some embodiments of this application, when acquiring upgrade result data and associating it with the updated state parameter set, the process includes: the update unit matching the upgrade result data and the updated state parameter set based on the updated data index relationship, determining the associated dataset, determining several candidate itemsets based on the Eclat algorithm and the associated dataset, determining frequent itemsets based on the support of the candidate itemsets, and determining the association result based on the frequent itemsets.

[0035] Specifically, the update unit, based on the updated data index relationship, precisely matches the upgrade result data corresponding to the firmware upgrade with the status parameter set updated synchronously throughout the upgrade process. The updated status parameter set represents a status dataset containing the latest information on server hardware, firmware, and operating status across all dimensions, formed after real-time data supplementation and dynamic adjustment throughout the firmware upgrade process. After matching through the updated data index relationship, the corresponding upgrade result data and the updated status parameter set are integrated into a unified associated dataset, laying the data foundation for subsequent association analysis. Data mining is performed on the associated dataset based on the Eclat algorithm to determine the potential association relationships between multi-dimensional data, thereby adapting to the association analysis scenario of multi-dimensional status and multi-type results of firmware upgrades. Several candidate option sets are initially selected from the associated dataset. The candidate option set represents a potential association combination extracted from the associated dataset that contains status parameter-related items and upgrade result-related items, such as hardware identifier full adaptation, firmware version high compatibility, and continuous stable operating status. Combinations of status items and successful upgrade completion results, including combinations of status items such as power supply fluctuations and moderately excessive offsets with results such as upgrade pause, all belong to the generated candidate item sets. These comprehensively cover all potential status and result associations. The selection process is completed based on the support of each candidate item set. Support represents the percentage of actual frequency of a single candidate item set in the entire associated dataset, directly reflecting the frequency and prevalence of the status and result combination. Simply random combinations lack regularity value. Frequent itemsets are determined through support filtering. Frequent itemsets represent frequently occurring association combinations with commonalities in the associated dataset. Association results are determined based on these frequent itemsets. These association results are stable rules and association patterns between various server status parameters and firmware upgrades, summarized from the frequent itemsets. They can be directly used for subsequent optimization and upgrade decision-making logic, transforming scattered association data into optimization basis, establishing a complete closed-loop firmware upgrade process control system, and reducing the risk of server firmware upgrade failure.

[0036] In some embodiments of this application, when adjusting the weighted calculation based on the association results and writing the adjusted weighted calculation into the strategy configuration, the following steps are included: the update unit extracts the association feature combination based on the association results, maps the association feature combination to the corresponding field position based on the updated data index relationship, divides the distribution of the association feature combination in the extended time series, determines the extended time interval, groups the data in each extended time interval, determines the field association data group, adjusts the weighted calculation based on the field association data group, and writes it into the storage location corresponding to each field in the strategy configuration.

[0037] Specifically, the update unit extracts associated feature combinations based on the previously mined association results. These combinations are selected from the association results and are related to the firmware upgrade weighted calculation, directly affecting the accuracy of the upgrade capability boundary value calculation, and are combinations of state parameters and corresponding features of the upgrade results. These combinations are regularity carriers verified by frequent itemsets. For example, verified feature combinations such as hardware identification matching meeting standards with no offset exceeding the standard during the upgrade, firmware version matching matching with no instruction control during the upgrade, and continuous stable operation status matching with successful upgrade completion are all extracted associated feature combinations. Based on the updated data index relationship, the extracted associated feature combinations are mapped one by one to the corresponding field positions. The process involves precisely mapping the associated feature combinations to specific matching positions in the hardware identifier field, firmware identifier field, and various operational status fields, based on their respective categories. This ensures that each set of associated features corresponds one-to-one with the previously constructed field system, preventing mismatches and laying the foundation for subsequent targeted adjustments to weighted calculations. A comprehensive division of the distribution of associated feature combinations within the extended time series is then performed to determine the extended time intervals. These extended time intervals are continuous and independent time segments defined by the time periods, distribution density, and change patterns of associated feature combinations throughout the firmware upgrade's extended time series. For example, periods with a stable distribution of associated feature combinations during the upgrade process can be classified as one type of extended time interval. Periods where feature combinations show slight fluctuations are divided into another type of extended time interval. Dividing these time intervals allows for a more detailed analysis of the impact of features at different stages on the weighted calculation. The update unit categorizes and integrates all data within each extended time interval according to field affiliation, determining field-related data groups. These field-related data groups are dedicated data sets formed by uniformly aggregating related data belonging to the same field within the same extended time interval. Each field corresponds to a dedicated related data group, enabling independent aggregation and management of single-field related data. For example, related data within the interval corresponding to the hardware identifier field is aggregated into a hardware identifier field related data group, and related data within the interval corresponding to the memory usage and running status field is aggregated into a memory usage field related data group. This is based on the organization... The completed field association data group makes targeted adjustments to the weighted calculation process. Based on the actual impact of the corresponding field on the firmware upgrade result reflected by the field association data group, the weight ratio of that field in the weighted calculation is optimized. For fields that show a high degree of impact on state stability in the association results, their weights are appropriately increased; for fields with low impact and almost no interference with the upgrade process, their weights are moderately decreased. This ensures that the weighted calculation closely reflects the actual upgrade conditions. By optimizing the weight allocation through association data, the calculation of subsequent upgrade capability boundary values ​​can better reflect the actual operation and upgrade situation of the server, thereby improving the accuracy of the judgment. The update unit writes the adjusted weighted calculation rules into the dedicated storage location corresponding to each field in the policy configuration.The strategy configuration file stores the decision rules, weighted calculation logic, and various threshold parameters for the entire firmware upgrade process. Writing the adjusted single-field weighted rule to the corresponding field's storage location within the strategy configuration binds the weighted rule to the field. Subsequent system calls for weighted calculations can directly retrieve the adjusted rule through the field, thus completing the remote server firmware upgrade. This continuously reduces upgrade risks and improves the upgrade success rate.

[0038] In some embodiments of this application, the DevOps-based server firmware remote upgrade system further includes: after adjusting the weighted calculation based on the field-related data group, the update unit segments and stores each field in the strategy configuration based on the field type.

[0039] Specifically, after completing all adjustments to the weighted calculation based on the field-associated data group and writing the adjusted weighted calculation rules to the corresponding field positions in the policy configuration, the update unit then performs a segmented storage operation based on field type for each field in the policy configuration. Field type is a classification attribute formed according to the source, functional attributes, and role played in firmware upgrade management of various fields stored internally in the policy configuration. According to established classification standards, it is mainly divided into three categories: hardware identifier field type, firmware identifier field type, and running status field type. Each field type corresponds to a specific attribute positioning, such as the hardware identifier field... The types correspond to basic server hardware attributes, the firmware identifier type corresponds to server firmware compatibility attributes, and the running status type corresponds to real-time server operating conditions. Segmented storage means that the update unit first divides the originally unified overall storage space of the policy configuration into multiple independent, clearly defined, non-interfering, and non-overlapping dedicated storage segments based on the above three field types. Each storage segment corresponds specifically to one type of field, preventing cross-type mixing of storage segments. The update unit will identify all fields in the policy configuration that have been written with adjusted weighted calculation rules to accurately determine... Each field belongs to a specific field type. All fields of the same type, along with their corresponding adjusted weighted calculation rules and associated configuration parameters, are then uniformly aggregated and stored in their respective dedicated storage segments. This achieves a storage model where similar fields are centrally stored while dissimilar fields are completely isolated. For example, all hardware identifier fields and their corresponding adjusted weighted calculation rules are stored in the dedicated storage segment corresponding to the hardware identifier field type; all firmware identifier fields and their corresponding adjusted weighted calculation rules are stored in the dedicated storage segment corresponding to the firmware identifier field type; and all running status fields and their corresponding adjusted weighted calculation rules are stored in the running status segment. The dedicated storage segments corresponding to field types, based on the core concept of DevOps modular operation and maintenance, realize the structured and fine-grained storage of policy configuration through field types. On the one hand, it can avoid the risk of mixed storage of multiple types of fields and data crossover and disorder within the policy configuration, making the configuration file structure neat and tidy, so that subsequent operation and maintenance personnel can check and verify the configuration content. On the other hand, it can improve the retrieval efficiency of fields and weighted rules in the subsequent firmware upgrade process, reduce the risk of configuration modification errors and upgrade failures, and adapt to the large-scale operation and maintenance needs of batch upgrades of multiple servers, further ensuring the control and configuration management capabilities of remote server firmware upgrades.

[0040] In summary, the beneficial effects of this invention are as follows: It synchronously acquires the server's device identification information, current firmware version information, and operational status data, quickly matches the target firmware version, and constructs a status parameter set. This avoids the tedious process of manually verifying information and manually matching firmware, automating data collection and preparation before upgrades, thus adapting to the DevOps operation and maintenance system. By determining upgrade capability boundary values ​​through normalization processing and weighted calculation, it intelligently judges upgrade feasibility. If the conditions are met, execution instructions are directly issued through the out-of-band management interface; otherwise, restriction instructions are generated and added to the pending queue. Combined with waiting time, the calculation is recalculated, avoiding hardware failures caused by blind upgrades and automatically retrying, thereby ensuring the reliability of upgrade scheduling. Remote upgrades are completed based on the out-of-band management interface, and corresponding process instructions are generated to achieve dynamic control of pause, termination, or path switching, ensuring the stability of the upgrade process. After the upgrade is completed or the control process is finished, the upgrade result data is correlated with the updated status parameter set, the weighted calculation is adjusted in reverse and written into the strategy configuration, realizing the system's self-optimization iteration, which meets the requirements of DevOps continuous integration and continuous optimization, improves the automation level, control accuracy and operation and maintenance efficiency of remote server firmware upgrades, and thus forms a closed-loop firmware upgrade control system, ensuring the stability of remote server firmware upgrades.

[0041] In another preferred embodiment based on the above embodiments, see [reference] Figure 2 As shown, this embodiment provides a DevOps-based remote server firmware upgrade method for using a DevOps-based remote server firmware upgrade system, including: S100: Obtain the server's device identification information, current firmware version information, and running status data; match the target firmware version based on the device identification information; and construct a set of status parameters corresponding to the server. S200: Normalize each data in the status parameter set, and perform weighted calculation on each normalized data to determine the upgrade capability boundary value. If the upgrade capability boundary value meets the execution conditions, generate an execution instruction and send it to the out-of-band management interface. If the upgrade capability boundary value does not meet the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue. Based on the waiting time, re-collect the server's running status data and perform weighted calculation. S300: Based on the out-of-band management interface, the server is upgraded with firmware and the status parameter set is updated. The real-time capability boundary value is determined. The offset is determined based on the real-time capability boundary value and the upgrade capability boundary value. The firmware upgrade is controlled based on the offset generation process instructions. The control process includes pausing the upgrade, terminating the upgrade, or switching to the backup upgrade path. S400: After completing the firmware upgrade or performing control processing, it obtains the upgrade result data and associates it with the updated state parameter set. Based on the association result, it adjusts the weighted calculation and writes the adjusted weighted calculation into the policy configuration.

[0042] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program goods according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0043] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A DevOps-based remote server firmware upgrade system, characterized in that, include: The acquisition unit is configured to acquire the server's device identification information, current firmware version information, and running status data, match the target firmware version based on the device identification information, and construct a status parameter set corresponding to the server. The processing unit is configured to normalize each data in the state parameter set, perform weighted calculation on the normalized data, determine the upgrade capability boundary value, generate an execution instruction and send it to the out-of-band management interface if the upgrade capability boundary value meets the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue if the upgrade capability boundary value does not meet the execution conditions, and re-collect the server's running status data based on the waiting time and perform weighted calculation. The execution unit is configured to perform firmware upgrades on the server based on the out-of-band management interface, update the status parameter set, determine real-time capability boundary values, determine an offset based on the real-time capability boundary values ​​and the upgrade capability boundary values, and perform control processing on the firmware upgrade based on the offset generation process instructions. The control processing includes pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. The update unit is configured to, after completing the firmware upgrade or executing the control process, obtain upgrade result data and associate it with the updated state parameter set, adjust the weighted calculation based on the association result, and write the adjusted weighted calculation into the strategy configuration.

2. The DevOps-based remote server firmware upgrade system according to claim 1, characterized in that, When constructing the state parameter set, the following steps are included: the acquisition unit divides the device identification information of the server into a hardware identification field and a firmware identification field; divides the running status data into several running status fields based on the data type; constructs a time series for each running status field based on the acquisition time; aligns the data in the time series; determines the amount of change based on adjacent sampled data in the aligned time series; combines the amount of change with the baseline feature quantity corresponding to the next sampled data to determine a two-dimensional feature set; encodes and maps the discrete data in the two-dimensional feature set; and establishes a data index relationship based on the hardware identification field, the firmware identification field, and each running status field to determine the state parameter set.

3. The DevOps-based remote server firmware upgrade system according to claim 2, characterized in that, When determining the upgrade capability boundary value, the process includes: the processing unit determining a feature sequence that corresponds one-to-one with each running status field based on the data index relationship; arranging the data in the feature sequence according to the field order; segmenting and combining the feature sequences corresponding to the same running status field to determine a field feature subset; grouping the field feature subset based on the hardware identifier field, firmware identifier field, and running status field; and performing a weighted calculation on the grouping results to determine the upgrade capability boundary value.

4. The DevOps-based remote server firmware upgrade system according to claim 3, characterized in that, When determining whether the upgrade capability boundary value meets the execution conditions, the processing unit compares the upgrade capability boundary value with the upgrade capability boundary threshold. If the upgrade capability boundary value is less than the upgrade capability boundary threshold, the processing unit determines that the upgrade capability boundary value meets the execution conditions. If the upgrade capability boundary value is greater than or equal to the upgrade capability boundary threshold, the processing unit determines that the upgrade capability boundary value does not meet the execution conditions.

5. The DevOps-based remote server firmware upgrade system according to claim 4, characterized in that, When determining the real-time capability boundary value, the process includes: the execution unit acquiring the target operating status data of the server during firmware upgrade, writing the target operating status data into the corresponding time series, determining the extended time series, and determining the real-time capability boundary value based on the extended time series.

6. The DevOps-based remote server firmware upgrade system according to claim 5, characterized in that, When the generation process instruction controls the firmware upgrade, it includes: the execution unit sets a first offset threshold and a second offset threshold, wherein the first offset threshold is less than the second offset threshold; if the offset is less than or equal to the first offset threshold, then based on the relationship between the offset and the first offset threshold, it determines whether to generate an instruction corresponding to path switching or continue the firmware upgrade; if the offset is greater than the first offset threshold and less than the second offset threshold, then it generates an instruction corresponding to pause the upgrade; if the offset is greater than or equal to the second offset threshold, then it generates an instruction corresponding to terminate the upgrade.

7. The DevOps-based remote server firmware upgrade system according to claim 6, characterized in that, When acquiring upgrade result data and associating it with the updated state parameter set, the process includes: the update unit matching the upgrade result data and the updated state parameter set based on the updated data index relationship to determine the associated dataset; determining several candidate itemsets based on the Eclat algorithm and the associated dataset; determining frequent itemsets based on the support of the candidate itemsets; and determining the association result based on the frequent itemsets.

8. The DevOps-based remote server firmware upgrade system according to claim 7, characterized in that, When adjusting the weighted calculation based on the association results and writing the adjusted weighted calculation into the strategy configuration, the process includes: the update unit extracting association feature combinations based on the association results, mapping the association feature combinations to corresponding field positions based on the updated data index relationship, dividing the distribution of the association feature combinations in the extended time series, determining the extended time intervals, grouping the data in each extended time interval, determining field association data groups, adjusting the weighted calculation based on the field association data groups, and writing the adjusted weighted calculation into the storage location corresponding to each field in the strategy configuration.

9. The DevOps-based remote server firmware upgrade system according to claim 8, characterized in that, Also includes: After adjusting the weighted calculation based on the field-related data group, the update unit segments and stores each field in the strategy configuration based on the field type.

10. A DevOps-based remote server firmware upgrade method, used in applying the DevOps-based remote server firmware upgrade system as described in any one of claims 1-9, characterized in that, include: Obtain the server's device identification information, current firmware version information, and running status data; match the target firmware version based on the device identification information; and construct a status parameter set corresponding to the server. Normalize each data in the state parameter set, and perform weighted calculation on the normalized data to determine the upgrade capability boundary value. If the upgrade capability boundary value meets the execution conditions, generate an execution instruction and send it to the out-of-band management interface. If the upgrade capability boundary value does not meet the execution conditions, generate a restriction instruction and write the upgrade task into the pending queue. Based on the waiting time, re-collect the server's running status data and perform weighted calculation. The server is upgraded using the out-of-band management interface, and the status parameter set is updated to determine the real-time capability boundary value. An offset is determined based on the real-time capability boundary value and the upgrade capability boundary value. The firmware upgrade is controlled based on the offset generation process instructions. The control process includes pausing the upgrade, terminating the upgrade, or switching to an alternative upgrade path. After completing the firmware upgrade or executing the control process, the upgrade result data is obtained and associated with the updated state parameter set. The weighted calculation is adjusted based on the association result, and the adjusted weighted calculation is written into the strategy configuration.

Images