Automatic operation and maintenance method for big data storage server

Abstract

The invention discloses an automatic operation and maintenance method for a big data storage server, and relates to the technical field of automatic operation and maintenance, and the method comprises the steps: collecting server BMC hardware sensor data, and substituting the data into a health scoring model to dynamically adjust a protocol strategy; constructing and adjusting a performance index weight based on a historical service SLA level to calculate a comprehensive influence factor BIF, and triggering a hierarchical response according to the BIF; and constructing a real-time comparison vector retrieval similar case execution solution, creating a dependency graph of a configuration item, an index and a service module, reversely tracing an influence path based on the graph, executing minimum unit rollback, and iteratively optimizing the graph according to a rollback effect. According to the invention, the adaptability of the server hardware operation and maintenance strategy is improved.

Description

Technical Field

[0001] This invention relates to the field of automated operation and maintenance technology, specifically to an automated operation and maintenance method for big data storage servers. Background Technology

[0002] With the popularization of big data technology, the complexity of big data storage servers is increasing exponentially, making the need for automated operation and maintenance increasingly urgent. While existing automated operation and maintenance methods can achieve basic indicator monitoring and resource scheduling, they have the following shortcomings in areas such as multi-dimensional indicator evaluation, dynamic policy adaptation, and reliability of anomaly handling: Existing technologies use a uniform static weight allocation when comprehensively evaluating multiple indicators, which leads to a mismatch between resource scheduling strategies and business needs. High SLA businesses often suffer from insufficient resource guarantees due to unreasonable indicator weights, while low SLA businesses are prone to over-allocation of resources. In the anomaly handling phase, traditional solutions lack dynamic adaptation to historical cases, and the anomaly handling process cannot be automatically adjusted according to real-time business impact factors, resulting in delayed fault response or processing failure. Existing operation and maintenance methods lack a precise rollback mechanism when configurations fail. They typically adopt a total rollback strategy, which undoes all associated configurations. While this coarse rollback approach can quickly restore the system state, it also clears valid configurations, causing fluctuations in business performance and severely impacting operation and maintenance efficiency and system stability.

[0003] Therefore, there is an urgent need for an automated operation and maintenance method that can combine multi-dimensional indicator characteristics and dynamically match business needs. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an automated operation and maintenance method for big data storage servers, which solves the problems of inaccurate multi-dimensional indicator evaluation, insufficient dynamic strategy adaptation, and low reliability of anomaly handling.

[0005] To achieve the above objectives, the present invention provides the following technical solution: an automated operation and maintenance method for big data storage servers, comprising: Step 1: Collect server BMC hardware sensor data and input it into the hardware health scoring model to obtain a real-time health score. Adjust the protocol strategy dynamically based on the score. Step 2: Construct initial weights for performance indicators based on historical business SLA levels, adjust the weights in real time based on changes in SLA levels, calculate the comprehensive impact factor (BIFi) of the business, and trigger a tiered response mechanism through the BIFi value. Step 3: Construct a real-time comparison vector for server services. Based on this vector, retrieve the top-3 similar cases from the historical case library using cosine similarity. Execute the corresponding solutions in order of similarity and monitor the BIF value in real time. If the BIF value does not reach the decrease threshold, trigger secondary configuration. Step 4: Build a dependency graph of configuration items, metrics and business modules, monitor in real time whether the configured metrics meet expectations, trace the impact path back based on the graph and perform the smallest unit rollback, and iteratively optimize the graph based on the rollback effect.

[0006] As a further aspect of the present invention, the specific steps for constructing the hardware health scoring model are as follows: Collect historical data from the server's BMC sensors. The historical data specifically includes hard drive bad sector count, CPU temperature, power supply voltage, and fan speed. Store data categorized by hardware type, with a time window set to 7 days; For each hardware metric, calculate the average of its historical data. with standard deviation ; For the current real-time hardware metrics According to the formula Calculate its deviation from historical benchmarks: like This indicates that the hardware specifications are normal; like This indicates a slight abnormality in the hardware indicators; like This indicates that the hardware indicators are severely abnormal; According to the formula Calculate the health score, where n is the number of hardware indicators.

[0007] As a further aspect of the present invention, if HHS ≥ 80, the hardware is classified as healthy; if HHS < 80, the hardware is classified as unhealthy; when the hardware is in an unhealthy state, the hardware indicator with the largest deviation among the severe abnormal indicators, i.e., max{ } serves as the dominant anomaly indicator.

[0008] As a further aspect of the present invention, the protocol strategy is dynamically adjusted based on the dominant anomaly indicator: If the hard drive bad sector count is abnormal, you need to switch to a low IO load protocol. If the CPU temperature is abnormal, switch to the lightweight protocol; If the power supply voltage is abnormal, switch to a high-reliability protocol; If the fan speed is abnormal, switch to a low-power protocol.

[0009] As a further aspect of the present invention, the specific steps for constructing the initial weights of the performance indicators are as follows: Obtain historical sample data containing CPU utilization, memory bandwidth, IOPS, network latency and corresponding SLAq level, where q∈[1,3] and is an integer; The data was divided into 3 groups, each corresponding to an SLA level; For each SLAq, since the dimensions of each indicator are different, standardization is required first: For positive metrics, namely memory bandwidth and IPOS, according to the formula... Perform normalization; For negative metrics, namely CPU utilization and network latency, according to the formula... Perform normalization; Where xij is the j-th index value of the i-th sample in the SLAq group; According to the formula Calculate the probability matrix of index j, where n is the number of samples in the SLAq group; According to the formula Calculate the entropy value of index j, where, ; According to the formula Calculate the coefficient of variation; For the four indicators of the SLAq group, according to the formula The initial weights of the four indicators were calculated.

[0010] As a further aspect of the present invention, according to the formula Calculate the weight of each indicator when the SLA changes, and then normalize it. ,in, The adjusted indicator weights, As the benchmark weight, To adjust the coefficient, The change in level These are the normalized weights.

[0011] As a further aspect of the present invention, the specific steps for calculating the comprehensive business impact factor are as follows: For each business indicator j, according to the formula Calculate its impact factor BIFj, where Severity j =(actual value of indicator j - threshold) / threshold, where Durationj is the duration for which the indicator exceeds the threshold; For business i, according to the formula The comprehensive impact factor BIFi was calculated.

[0012] As a further aspect of the present invention, the specific operation of triggering the hierarchical response mechanism through the BIFi value is as follows: A dynamic threshold BIF is generated based on the 95th percentile of historical BIF data. threshold BIF threshold =Quantile(BIF histroy ,0.95), where Quantile() is the quantile function; If BIFi≤BIF threshold This indicates that the business is experiencing normal fluctuations, can be continuously monitored, and requires no intervention; If BIFi > BIF threshold This indicates that the service is experiencing abnormal fluctuations and resource scheduling needs to be initiated to prevent failures.

[0013] As a further aspect of the present invention, case solutions are executed in descending order of similarity, and real-time monitoring is initiated after initial configuration: If the BIF decreases by more than or equal to the threshold within T minutes, then the current configuration will be maintained. Otherwise, a secondary configuration will be triggered, and the suboptimal case solution will be executed; If the BIF decrease is still insufficient after secondary configuration, the Top-1 and Top-2 solutions will be merged, and the current exception will be stored in the database as a new case.

[0014] As a further aspect of the present invention, the currently effective resource configuration parameters and related indicators are extracted, a ternary dependency relationship of configuration item-indicator-business module is established, and a directed acyclic graph (DAG) is used for visualization. The nodes are configuration items, indicators, and business modules, and the edges are the influence relationships. According to the monitoring nodes defined in the graph, the configured indicator data is collected in real time.

[0015] This invention provides an automated operation and maintenance method for big data storage servers, which has the following advantages compared with the prior art: (1) This invention achieves real-time monitoring and fault prevention of hardware status through hardware health scoring model and protocol dynamic adjustment, thereby improving server hardware reliability and reducing the risk of business interruption caused by hardware failure. (2) Based on the SLA level, the present invention dynamically adjusts the indicator weights and calculates the BIF to achieve accurate quantification and graded response to business impact, thereby optimizing resource scheduling efficiency, ensuring the supply of high SLA business resources, and avoiding the waste of low SLA business resources. (3) This invention constructs a configuration impact factor map and implements minimum unit rollback to achieve accurate location and rapid recovery when configuration fails. At the same time, it iterative optimization of the map through rollback effect improves the reliability of operation and maintenance strategy. Attached Figure Description

[0016] Figure 1 This is a flowchart of the steps of the present invention. Detailed Implementation

[0017] 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.

[0018] like Figure 1 This invention provides an automated operation and maintenance method for big data storage servers, comprising: Step 1: Collect server BMC hardware sensor data and input it into the hardware health scoring model to obtain a real-time health score. Then, dynamically switch the transmission protocol based on the score. The specific steps for constructing a hardware health scoring model are as follows: Continuously collect historical data from the server's BMC sensors, including hard drive bad sector count, CPU temperature, power supply voltage, and fan speed. Bad sectors are a direct manifestation of damage to the physical storage media of a hard drive. Their incremental changes reflect the gradual damage to the disk surface. If not monitored in time, they may lead to data read / write failures and storage system crashes. Temperature directly reflects the CPU's heat dissipation efficiency. High temperatures accelerate the aging of electronic components and trigger the CPU's dynamic frequency reduction mechanism, leading to service response delays. Voltage fluctuations exceeding the normal range can cause abnormal operation of hardware logic circuits, such as memory data flipping, controller firmware errors, etc., and in severe cases, it can cause the device to restart. Rotation speed reflects the mechanical condition of the cooling system and directly affects the temperature control of heat-generating components such as CPU / GPU. If the rotation speed decreases, it will directly cause the temperature to rise and indirectly lead to the degradation of hardware performance. Storage is categorized by hardware type, with a time window set to 7 days to cover the regular business cycle; The main purpose of setting a time window is to filter out transient interference and capture trend characteristics: Short-term fluctuations in hardware metrics may trigger false alarms, such as power surges or transient changes in fan speed during startup. Setting appropriate time windows can eliminate such occasional anomalies. Hardware failures usually have a gradual process, such as the gradual increase of bad sectors on a hard drive or the slow increase of voltage ripple due to capacitor aging. By sampling data over a continuous period of time, the trend changes of the indicators can be identified. For each hardware metric, calculate the average of its historical data. with standard deviation The normal fluctuation range is obtained as [ , ]; For the current real-time hardware metrics According to the formula Calculate its deviation from the historical benchmark: like This indicates that the hardware specifications are normal and the deviation is low. like This indicates a slight anomaly in the hardware indicators, which requires attention. like This indicates a serious anomaly in the hardware specifications, which should trigger a protocol adjustment. Health status is reflected by quantifying the deviation of hardware indicators from historical benchmarks, according to the formula. Calculate the health score, where n is the number of hardware indicators, which is set to 4 here; When hardware metrics are closer to the historical normal range The smaller the value, the closer the HHS value is to 100, indicating a healthier hardware condition; Determine the current hardware health status based on HHS: If HHS ≥ 80, then it is classified as healthy; If HHS < 80, it is classified as unhealthy; When hardware is in an unhealthy state, the first step is to identify the dominant abnormal indicator: select the hardware indicator with the largest deviation among the severe abnormal indicators, i.e., max{ }; Adjustment strategy based on dominant anomaly indicators: If the hard drive has an abnormal bad sector count, you need to switch to a low IO load protocol, such as compressed transmission and reduced read / write frequency. Bad sectors on a hard drive can increase the probability of read / write errors on the magnetic media. Continuous high-frequency I / O operations (such as uncompressed raw data transmission) may exacerbate the spread of bad sectors and even cause permanent sector damage. If a high-frequency read / write protocol is maintained, repeated access to bad sectors during data transmission will lead to CRC check failures and data packet loss, which in turn will affect the log storage and health data feedback of the monitoring system. If the CPU temperature is abnormal, switch to a lightweight protocol, such as reducing the sampling frequency and simplifying the protocol stack. When the CPU temperature exceeds the threshold, the chip will trigger a frequency reduction mechanism. If a high-complexity protocol is maintained, such as TCP + encryption + compression multi-layer processing, it will lead to increased interrupt handling latency and even protocol stack blocking. High-load protocol processing (such as AES encryption operations) will further increase CPU power consumption, causing the temperature to rise exponentially, which may exceed the critical value and cause hardware protection to restart. If the power supply voltage is abnormal, switch to a high-reliability protocol, such as adding a check bit and a retransmission mechanism to enhance reliability. Voltage fluctuations can cause data bus signal distortion, and the bit error rate of conventional protocols (such as unencrypted UDP) will increase significantly, resulting in packet verification failures or content tampering. When the voltage drops suddenly, protocol data in the memory cache may be lost. If there is no retransmission mechanism, it will cause the health data to be interrupted, affecting the continuity of HHS scores. If the fan speed is abnormal, switch to a low-power protocol, such as a sleep-wake mechanism + non-real-time data caching. When the fan speed is below the threshold, the hardware heat dissipation efficiency decreases. If a high-power protocol is maintained, such as continuous real-time transmission + full data encryption, the imbalance between chip heat generation and heat dissipation will cause the temperature to rise sharply, forming a vicious cycle of "low fan speed - high temperature - high power consumption - even lower fan speed". When a fan fails, the system power supply may need to prioritize powering core hardware (such as the CPU and hard drive). High-power protocols will consume power, exacerbate current fluctuations in the fan motor, and may cause the fan to stop completely. The aforementioned protocol adjustment strategies must directly target the physical impact path of abnormal hardware indicators. For example, bad sectors on the hard drive affect I / O reliability, so I / O operations should be reduced; overheating of the CPU affects computing power, so the protocol processing load should be reduced.

[0019] Step 2: Construct initial weights for performance indicators based on historical business SLA levels, and adjust the weights in real time based on changes in SLA levels. Calculate the Business Impact Factor (BIF) and trigger a tiered response mechanism using the BIF value. Features are extracted from three dimensions: functional attributes, traffic characteristics, and business value of the business system, and an input feature vector is constructed. In terms of functional attributes, we extract processing latency and concurrent processing capabilities; Processing latency (which can be taken as a real-time average) directly reflects the service response speed. The higher the latency, the greater the risk of blocking user requests, which may lead to timeouts and retries. High-latency services have higher real-time requirements, such as financial transactions and real-time risk control, and need to guarantee the priority of low-latency resources through SLA levels; Concurrency processing capability (which can be the maximum processing volume in real time) reflects the upper limit of system resource utilization. Insufficient concurrency capability can easily lead to thread / process competition, resulting in an increase in error rate. High-concurrency services require higher SLA levels to ensure sufficient resource allocation; In terms of traffic characteristics, peak traffic and traffic volatility are extracted. Peak traffic (the maximum value within a 5-minute sliding window) reflects the impact of sudden loads on network and computing resources. Excessively high peak traffic may lead to bandwidth congestion. The higher the peak traffic of a service, the more stringent the requirements for resource elastic scheduling capabilities, and the more necessary it is to match the corresponding emergency response strategy with the SLA level. Traffic volatility (calculation) Standard deviation of flow rate / mean Traffic (represented as the difference between the instantaneous value and the mean) characterizes the degree of traffic mutation. High volatility can lead to resource scheduling lag and cause performance jitter. Businesses with volatile traffic need to dynamically adjust their SLA levels to balance stability and resource costs; In terms of business value, extract user impact; User impact (based on real-time online user count) reflects the scale of users covered by the service and the social spread of the fault. Businesses with a large user base require higher SLA levels to reduce the impact of failures. After extracting the feature values ​​from the above three dimensions, the resulting input feature vector is: [processing latency, concurrent processing capability, peak traffic, traffic volatility, user impact]. The classification model is trained using gradient boosting tree (XGBoost). The above input feature vectors are substituted into XGBoost, and the output levels are SLA1-SLA3, resulting in the trained XGBoost model. The performance metrics specifically include CPU utilization, memory bandwidth, IOPS, and network latency. The specific steps for constructing the initial weights of performance metrics are as follows: Obtain historical sample data containing four metrics (CPU utilization, memory bandwidth, IOPS, and network latency) and their corresponding SLAq (q∈[1,3] and take integers) levels, such as the monitoring data of a system over the past 6 months, with each sample corresponding to a metric value and SLA level at a specific time point; The data was divided into 3 groups, each corresponding to an SLA level; For each SLAq, since the dimensions of each indicator are different, standardization is required first: For positive metrics, such as memory bandwidth and IPOS, higher values ​​are better, according to the formula... Perform normalization; For negative metrics, such as CPU utilization and network latency, lower values ​​are better, according to the formula... Perform normalization; Where xij is the j-th index value of the i-th sample in the SLAq group (j=1 to 4, corresponding to four indicators); According to the formula Calculate the probability matrix of index j, where n is the number of samples in the SLAq group; According to the formula Calculate the entropy value of index j, where, ; Entropy reflects the degree of information disorder of an indicator; the smaller the variation, the higher the entropy and the lower the weight. According to the formula Calculate the coefficient of variation. The larger the coefficient of variation, the more important the index j is to SLAq. For the four indicators of the SLAq group, according to the formula The initial weights of the four indicators were calculated. When the SLA level changes due to business fluctuations, the indicator weights need to be adjusted in real time to quickly adapt to the current service goals and ensure that key indicators receive more resource allocation. According to the formula Calculate the weight of each indicator when the SLA changes, and then normalize it. ,in, The adjusted indicator weights, As the benchmark weight, To adjust the coefficient, a value of 0.2 can be used. The change in level, These are the normalized weights; For each business indicator j, according to the formula Calculate its impact factor, where Severity j =(actual value of indicator j - threshold) / threshold, where Durationj is the duration for which the indicator exceeds the threshold; For business i, according to the formula Calculate its comprehensive impact factor BIFi; A dynamic threshold BIF is generated based on the 95th percentile of historical BIF data. threshold To avoid fixed thresholds failing to adapt to business changes, i.e., BIF threshold =Quantile(BIF histroy ,0.95), where Quantile() is the quantile function; The specific details of triggering the hierarchical response mechanism using the BIF value are as follows: If BIFi≤BIF threshold This indicates that the business is experiencing normal fluctuations, can be continuously monitored, and requires no intervention; If BIFi > BIF threshold This indicates that the service is experiencing abnormal fluctuations and resource scheduling needs to be initiated to prevent failures.

[0020] Step 3: Construct a real-time comparison vector for the business. Based on this vector, retrieve the top-3 similar cases from the historical case library using cosine similarity. Execute the corresponding solutions in order of similarity and monitor the BIF value in real time. If the BIF value does not reach the decrease threshold, trigger secondary configuration. The features in the business comparison vector Ma specifically include CPU utilization, memory bandwidth, IOPS, network latency, BIF value, and duration exceeding the threshold, i.e., Ma = [CPU utilization, memory bandwidth, IOPS, network latency, BIF value, duration], and all of them are standardized values. BIF quantifies the overall impact of anomalies on business, while Duration reflects the urgency of time. By adding these two features to the comparison vector, matching solutions can be retrieved more accurately from the historical case library. For each case in the historical case library, calculate the cosine similarity sim between the comparison vector Mb and Ma, sort them in descending order of sim, and extract the top-3 cases. Each case includes: comparison vector Mb, configuration scheme, and historical effect. Calculating the cosine similarity between two contrasting vectors is to emphasize the directional consistency of feature vectors, which is suitable for capturing "abnormal pattern similarity". By extracting the top-3 cases, we can avoid single-case bias and also cross-validate the solution with multiple cases; Execute case solutions based on similarity from high to low, and enable real-time monitoring after initial configuration: If the BIF decreases by more than or equal to the threshold within T minutes, then the current configuration will be maintained. Among them, T can be 3, and the amplitude threshold can be 20%; Otherwise, a secondary configuration will be triggered, and the suboptimal case solution, such as the Top-2 case, will be executed; If the BIF decrease is still insufficient after secondary configuration, a hybrid strategy is initiated: the Top-1 and Top-2 solutions are merged, and the current exception is stored in the database as a new case. Using a hybrid strategy can avoid the limitations of a single solution in the case library, and combine the two to achieve a rapid decrease in BIF.

[0021] Step 4: Build a dependency graph of configuration items, metrics and business modules, monitor in real time whether the configured metrics meet expectations, trace the impact path back based on the graph and perform the smallest unit rollback, and iteratively optimize the graph based on the rollback effect. Extract currently effective resource configuration parameters (such as the number of new nodes and IO scheduling policies) and related metrics (such as CPU utilization and BIF value), and establish a ternary dependency relationship between configuration items, metrics, and business modules. A Directed Acyclic Graph (DAG) is used to visualize the graph. Nodes represent configuration items / metrics / business modules, and edges represent influence relationships. For example, "Adding a new storage node" points to "Improved IOPS", and "Improved IOPS" points to "Accelerated response of the order processing module". After completing the resource configuration, the mapping relationship between the configuration and the system status is solidified through the graph, providing a structured data foundation for the impact analysis during anomalies. For example, if the configuration is "add 2 CPU cores", the graph needs to clearly define the expected impact path of this configuration on indicators such as CPU utilization and memory bandwidth. The monitoring nodes defined by the graph collect the configured indicator data in real time. Compare the actual values ​​of the indicators with the expected range in the graph. If the values ​​collected three times in a row exceed the threshold, it is marked as an abnormal configuration. The previous graph defined the monitoring objects and expected results. This step is based on the graph to perform targeted monitoring and avoid interference from invalid data. For example, if the graph shows that "adding a storage node" should reduce IOPS response latency, when the actual latency increases, it can be quickly located as a configuration anomaly and the rollback process can be triggered. After an anomaly is triggered, trace the impact path backward along the graph to identify the smallest affected business module, such as only affecting log writing rather than core transactions; Choose the smallest rollback unit: prioritize rolling back individual configuration items rather than overwriting all configurations, thus reducing the impact on normal business operations; The smallest rollback unit refers to the smallest operable configuration unit that causes the problem, rather than the entire configuration. For example, if the configuration includes three items: "add node + modify routing rules + adjust caching strategy", and only "add node" causes the anomaly, then "add node" is the smallest rollback unit. For example, a configuration operation may contain three independent configuration items: A. Add 2 new nodes (parameter values: number of nodes = 2, node type = computed); B. Modify the database connection pool parameters (parameter value: maximum number of connections = 500); C. Adjust the load balancing strategy (parameter value: forwarding rule = round-robin); At this point, the newly added second node caused a service error due to a hardware failure, while the first node in item A, and configuration items B and C were all normal. For the smallest rollback unit: it is "Add a second node" in configuration item A, not the entire item A or item B / C; For priority rollback of a single configuration item: only the specific operation of "adding a second node" is undone, that is, the second node in the parameter value "number of nodes = 2" of the configuration item is rolled back, while the validity of the first node and the B / C configuration item is preserved; After rollback, regenerate temporary graphs and verify rollback effect, such as whether BIF value has fallen back to the normal range. If invalid, rollback to the previous configuration version in a progressive manner. Record changes in configuration parameters and metrics before and after the rollback, as well as the impact on business operations, and generate configuration-anomaly-rollback feedback logs. If the same configuration item triggers rollback ≥ 3 times within 30 days, the dependency weight in the graph will be automatically updated, such as reducing the recommendation priority of the configuration item to avoid duplicate invalid configurations. The rollback operation in the previous step provides real data for the graph iteration. The accuracy of dependencies is optimized through feedback logs. For example, if "memory expansion" frequently triggers rollback, the graph will mark that the impact of this configuration on memory bandwidth is uncertain, and reduce its similarity weight when matching subsequent cases.

[0022] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0023] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. An automated operation and maintenance method for big data storage servers, characterized in that, Includes the following steps: Step 1: Collect server BMC hardware sensor data and input it into the hardware health scoring model to obtain a real-time health score. Adjust the protocol strategy dynamically based on the score. Step 2: Construct initial weights for performance indicators based on historical business SLA levels, adjust the weights in real time based on changes in SLA levels, calculate the comprehensive impact factor (BIFi) of the business, and trigger a tiered response mechanism through the BIFi value. Step 3: Construct a real-time comparison vector for server services. Based on this vector, retrieve the top-3 similar cases from the historical case library using cosine similarity. Execute the corresponding solutions in order of similarity and monitor the BIF value in real time. If the BIF value does not reach the decrease threshold, trigger secondary configuration. Step 4: Build a dependency graph of configuration items, metrics and business modules, monitor in real time whether the configured metrics meet expectations, trace the impact path back based on the graph and perform the smallest unit rollback, and iteratively optimize the graph based on the rollback effect.

2. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, The specific steps for constructing a hardware health scoring model are as follows: Collect historical data from the server's BMC sensors. The historical data specifically includes hard drive bad sector count, CPU temperature, power supply voltage, and fan speed. Store data categorized by hardware type, with a time window set to 7 days; For each hardware metric, calculate the average of its historical data. with standard deviation ; For the current real-time hardware metrics According to the formula Calculate its deviation from historical benchmarks: like This indicates that the hardware specifications are normal; like This indicates a slight abnormality in the hardware indicators; like This indicates that the hardware indicators are severely abnormal; According to the formula Calculate the health score, where n is the number of hardware indicators.

3. The automated operation and maintenance method for a big data storage server according to claim 2, characterized in that, If HHS ≥ 80, the hardware is classified as healthy; if HHS < 80, the hardware is classified as unhealthy. When the hardware is in an unhealthy state, the hardware indicator with the largest deviation among the severe abnormal indicators is selected, i.e., max{ } serves as the dominant anomaly indicator.

4. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, The protocol strategy is dynamically adjusted based on the dominant anomaly indicators. If the hard drive bad sector count is abnormal, you need to switch to a low IO load protocol. If the CPU temperature is abnormal, switch to the lightweight protocol; If the power supply voltage is abnormal, switch to a high-reliability protocol; If the fan speed is abnormal, switch to a low-power protocol.

5. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, The specific steps for constructing the initial weights of performance metrics are as follows: Obtain historical sample data containing CPU utilization, memory bandwidth, IOPS, network latency and corresponding SLAq level, where q∈[1,3] and is an integer; The data was divided into 3 groups, each corresponding to an SLA level; For each SLAq, since the dimensions of each indicator are different, standardization is required first: For positive metrics, namely memory bandwidth and IPOS, according to the formula... Perform normalization; For negative metrics, namely CPU utilization and network latency, according to the formula... Perform normalization; Where xij is the j-th index value of the i-th sample in the SLAq group; According to the formula Calculate the probability matrix of index j, where n is the number of samples in the SLAq group; According to the formula Calculate the entropy value of index j, where, ; According to the formula Calculate the coefficient of variation; For the four indicators of the SLAq group, according to the formula The initial weights of the four indicators were calculated.

6. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, According to the formula Calculate the weight of each indicator when the SLA changes, and then normalize it. ,in, The adjusted indicator weights, As the benchmark weight, To adjust the coefficient, The change in level These are the normalized weights.

7. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, The specific steps for calculating the overall business impact factor are as follows: For each business indicator j, according to the formula Calculate its impact factor BIFj, where Severity j =(actual value of indicator j - threshold) / threshold, where Durationj is the duration for which the indicator exceeds the threshold; For business i, according to the formula The comprehensive impact factor BIFi was calculated.

8. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, The specific steps for triggering a tiered response mechanism using BIFi values ​​are as follows: A dynamic threshold BIF is generated based on the 95th percentile of historical BIF data. threshold BIF threshold =Quantile(BIF histroy ,0.95), where Quantile() is the quantile function; If BIFi≤BIF threshold This indicates that the business is experiencing normal fluctuations, can be continuously monitored, and requires no intervention; If BIFi > BIF threshold This indicates that the service is experiencing abnormal fluctuations and resource scheduling needs to be initiated to prevent failures.

9. The automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, Execute case solutions based on similarity from high to low, and enable real-time monitoring after initial configuration: If the BIF decreases by more than or equal to the threshold within T minutes, then the current configuration will be maintained. Otherwise, a secondary configuration will be triggered, and the suboptimal case solution will be executed; If the BIF decrease is still insufficient after secondary configuration, the Top-1 and Top-2 solutions will be merged, and the current exception will be stored in the database as a new case.

10. An automated operation and maintenance method for a big data storage server according to claim 1, characterized in that, Extract currently effective resource configuration parameters and related metrics, establish a ternary dependency relationship between configuration items, metrics, and business modules, and use a directed acyclic graph (DAG) for visualization. Nodes represent configuration items, metrics, and business modules, while edges represent influence relationships. Monitor the nodes defined in the graph and collect the configured metric data in real time.

Images