Cloud mobile phone intelligent operation and maintenance method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of cloud mobile phones, and discloses a cloud mobile phone intelligent operation and maintenance method and device, computer equipment and a storage medium, and the method comprises the steps: collecting multi-dimensional performance indexes of a cloud mobile phone cluster at a preset frequency through a configurable collector; analyzing the multi-dimensional performance indexes to obtain a multi-index incidence matrix representing space-time correlation characteristics among the indexes, and performing fault prediction based on the multi-index incidence matrix to obtain a fault prediction result; screening a target repair strategy matched with the fault prediction result from a multi-stage repair strategy library, and executing repair operation according to the target repair strategy to obtain a key index change rate; and triggering a strategy optimization mechanism to iteratively update the target repair strategy according to the key index change rate until the key index change rate meets a preset dynamic balance condition. According to the method, the problems that monitoring and prediction are separated, multi-dimensional correlation analysis is lacked, a repair strategy is rigid and a repair effect verification closed loop is lacked in existing cloud mobile phone operation and maintenance are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud mobile phones, and particularly to a cloud mobile phone intelligent operation and maintenance method, device, computer device, and storage medium. Background Art

[0002] With the deep integration of cloud computing and virtualization technologies, cloud mobile phones, as a mobile terminal service that runs virtually through the cloud, have been widely used in scenarios such as game hanging and mobile application testing. The rapid expansion of its cluster scale poses higher requirements for operation and maintenance management: the performance stability of cloud mobile phones directly affects the user experience, while the traditional operation and maintenance mode relies on manual experience or independent tools and is difficult to meet the needs of cluster-level real-time monitoring, fault prediction, and rapid repair. Although the existing technologies have realized the basic performance data collection and single-dimensional anomaly warning, there are still technical gaps in the collaborative optimization of multi-index correlation analysis, predictive maintenance, and automated repair, resulting in the cloud mobile phone service often falling into the dilemma of passive response due to sudden failures.

[0003] Existing cloud mobile phone operation and maintenance solutions have systematic fragmentation and intelligent shortcomings: monitoring tools and prediction platforms are difficult to support real-time collaborative decision-making due to significant data transmission delays and index isolation at the device / virtualization / application layer; mainstream models only rely on single-dimensional analysis of CPU / memory and ignore the spatio-temporal correlation of multiple types of indexes such as IO latency and network throughput, resulting in insufficient complex fault prediction ability; automated tools based on preset rules cannot dynamically adjust repair strategies in combination with prediction confidence, easily causing problems of overly strict or overly loose strategies; there is no closed-loop for effect verification after repair, and strategy iteration lags behind the dynamic changes of the cluster, forming a "fault-repair-re-fault" cycle. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a cloud mobile phone intelligent operation and maintenance method, device, computer device, and storage medium to solve the problems of fragmentation between monitoring and prediction, lack of multi-dimensional correlation analysis, rigid repair strategies, and lack of a closed-loop for repair effect verification in existing cloud mobile phone operation and maintenance.

[0005] In a first aspect, an embodiment of the present invention provides a cloud mobile phone intelligent operation and maintenance method, and the method includes:

[0006] Collect multi-dimensional performance indexes of a cloud mobile phone cluster at a preset frequency through a configurable collector;

[0007] Analyze the multi-dimensional performance indexes to obtain a multi-index correlation matrix representing the spatio-temporal correlation characteristics between indexes, and perform fault prediction based on the multi-index correlation matrix to obtain a fault prediction result;

[0008] Screen a target repair strategy that matches the fault prediction result from the multi-level repair strategy library, and perform a repair operation according to the target repair strategy to obtain a key index change rate;

[0009] Trigger a strategy optimization mechanism based on the key index change rate to iteratively update the target repair strategy until the key index change rate meets a preset dynamic balance condition.

[0010] Further, analyzing the multi-dimensional performance indicators to obtain a multi-index correlation matrix characterizing the spatio-temporal correlation characteristics between indicators, including:

[0011] Set a sliding time window according to a preset length;

[0012] Perform a sliding operation on the multi-dimensional performance indicators through the sliding time window, and calculate the statistical characteristic values of each performance indicator within the window;

[0013] Calculate the cross-dimensional index correlation degree based on the statistical characteristic values, and construct a multi-index correlation matrix using the index correlation degree.

[0014] Further, performing fault prediction based on the multi-index correlation matrix to obtain a fault prediction result, including:

[0015] Extract the temporal characteristics in the multi-index correlation matrix and the spatial correlation characteristics between multiple performance indicators;

[0016] Determine a weighting ratio according to the current system load status, and fuse the temporal characteristics and the spatial correlation characteristics according to the weighting ratio to obtain a fused feature;

[0017] Input the fused feature into a fault prediction model, and output the fault type and the corresponding prediction confidence as the fault prediction result.

[0018] Further, screening a target repair strategy that matches the fault prediction result from the multi-level repair strategy library, including:

[0019] Analyze the fault type and prediction confidence in the fault prediction result;

[0020] Determine a screening criterion according to the fault type and the prediction confidence, and traverse multiple preset repair strategies in the multi-level repair strategy library to obtain candidate repair strategies that match the screening criterion;

[0021] Adjust the repair parameters in the candidate repair strategies to obtain a target repair strategy.

[0022] Further, adjusting the repair parameters in the candidate repair strategies to obtain a target repair strategy, including:

[0023] Obtain the historical execution records of the candidate repair strategy;

[0024] Extract the performance parameters from the historical execution records, and adjust the repair parameters in the candidate repair strategy according to the performance parameters to obtain the target repair strategy.

[0025] Further, the triggering of the policy optimization mechanism according to the change rate of the key metrics to iteratively update the target repair strategy until the change rate of the key metrics meets the preset dynamic balance condition includes:

[0026] Calculate the change rate of the key metrics after the execution of the repair operation;

[0027] Compare the change rate of the key metrics with the dynamic threshold;

[0028] When the change rate of the key metrics does not reach the corresponding dynamic threshold, update the policy weight parameter of the target repair strategy until the change rate of the key metrics reaches the dynamic threshold, and determine that the repair effect meets the preset dynamic balance condition;

[0029] When the change rate of the key metrics does not reach the dynamic threshold and the number of updates reaches the preset number of times, determine that the repair effect does not meet the preset dynamic balance condition.

[0030] Further, the method further includes:

[0031] Within a preset verification period after the execution of the repair operation, inject traffic pressure data simulating the user behavior distribution into the repaired cloud mobile phone cluster, and monitor the composite verification metrics of the cloud mobile phone cluster;

[0032] When the composite verification metrics exceed the preset safety boundary, dynamically adjust the execution priority of the target repair strategy;

[0033] If the adjusted composite verification metrics continue to exceed the preset safety boundary, then call the baseline repair template preset in the backup policy library to overwrite the target repair strategy.

[0034] In a second aspect, an embodiment of the present invention provides a cloud mobile phone intelligent operation and maintenance device, and the device includes:

[0035] An acquisition module, configured to acquire multi-dimensional performance metrics of a cloud mobile phone cluster at a preset frequency through a configurable collector;

[0036] An analysis module, configured to analyze the multi-dimensional performance metrics to obtain a multi-index correlation matrix characterizing the spatio-temporal correlation characteristics between the metrics, and perform fault prediction based on the multi-index correlation matrix to obtain a fault prediction result;

[0037] A screening module, configured to screen a target repair strategy that matches the fault prediction result from a multi-level repair strategy library, and perform a repair operation according to the target repair strategy to obtain a key index change rate;

[0038] An update module, configured to trigger a strategy optimization mechanism to iteratively update the target repair strategy according to the key index change rate until the key index change rate meets a preset dynamic balance condition.

[0039] In a third aspect, an embodiment of the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the method according to the first aspect or any corresponding implementation manner thereof.

[0040] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the method according to the first aspect or any corresponding implementation manner thereof.

[0041] The method provided by the embodiments of the present application has the following beneficial effects:

[0042] The method provided by the embodiments of the present application can collect multi-dimensional performance indicators of a cloud mobile phone cluster at a preset frequency through a configurable collector, and can comprehensively and timely obtain detailed information on the operating status of the cloud mobile phone, providing a rich and accurate data basis for subsequent fault prediction and repair; analyzing the multi-dimensional performance indicators to obtain a multi-index correlation matrix representing the spatio-temporal correlation characteristics between the indicators and performing fault prediction, fully considering the correlation between each indicator, effectively making up for the lack of multi-dimensional correlation analysis in the prior art, and greatly improving the ability to predict complex faults; screening and executing a target repair strategy that matches the fault prediction result from a multi-level repair strategy library, and the repair strategy can be dynamically adjusted according to different fault types and prediction confidence levels, avoiding the problems of over-strict or over-loose strategies caused by traditional preset rules, and achieving accurate and efficient fault repair; triggering a strategy optimization mechanism to iteratively update the target repair strategy according to the key index change rate until the preset dynamic balance condition is met, forming a closed loop for verifying the repair effect, ensuring that the repair strategy can be continuously optimized according to the dynamic changes of the cluster, breaking the vicious cycle of "fault - repair - re-fault", and comprehensively improving the intelligent level of cloud mobile phone operation and maintenance and the stability of services. Description of the Drawings

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0044] Figure 1 It is a schematic flowchart of a cloud mobile phone intelligent operation and maintenance method according to an embodiment of the present invention;

[0045] Figure 2 It is a schematic architecture diagram of a fault prediction model according to an embodiment of the present invention;

[0046] Figure 3 It is an example structural diagram of a repair strategy decision tree according to an embodiment of the present invention;

[0047] Figure 4 It is a closed-loop operation and maintenance flowchart of cloud mobile phone real-time performance monitoring and fault repair according to an embodiment of the present invention;

[0048] Figure 5 It is a structural block diagram of a cloud mobile phone intelligent operation and maintenance system according to an embodiment of the present invention;

[0049] Figure 6 It is a structural block diagram of a cloud mobile phone intelligent operation and maintenance device according to an embodiment of the present invention;

[0050] Figure 7 It is a schematic hardware structure diagram of a computer device according to an embodiment of the present invention. Specific Embodiments

[0051] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0052] According to an embodiment of the present invention, a cloud mobile phone intelligent operation and maintenance method, device, computer device, and storage medium are provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0053] In this embodiment, a cloud mobile phone intelligent operation and maintenance method is provided. Figure 1is a flowchart of the intelligent operation and maintenance method of cloud phones according to an embodiment of the present invention. As Figure 1 shown, the process includes the following steps:

[0054] Step S11, collect multi-dimensional performance indicators of the cloud phone cluster at a preset frequency through a configurable collector.

[0055] In the embodiment of the present application, the data collection layer can adopt a combination of Prometheus and a customized Exporter. Prometheus is an open-source monitoring system with powerful data collection capabilities, while the customized Exporter is a data collector customized for the cloud phone environment, which can push the performance indicator data specific to cloud phones to Prometheus. The configurable collector here reflects the flexibility of the system, and the collection frequency can be adjusted according to actual needs. The default collection frequency is once every 30 seconds. Such a setting can balance the real-time nature of data collection and the consumption of system resources in different application scenarios.

[0056] The object of collection is the cloud phone cluster, involving at least 20 multi-dimensional performance indicators, such as CPU usage rate, memory occupancy rate, network latency, disk I / O, etc. These indicators reflect the running state of cloud phones from different aspects, and comprehensively can describe the performance status of the cloud phone cluster. By continuously collecting these multi-dimensional performance indicators at a preset frequency, the system can obtain the dynamic data during the operation of cloud phones, thus providing rich and accurate data support for subsequent analysis of the correlation characteristics between indicators, fault prediction, and formulation of repair strategies.

[0057] Step S12, analyze the multi-dimensional performance indicators to obtain a multi-index correlation matrix representing the spatio-temporal correlation characteristics between indicators, and perform fault prediction based on the multi-index correlation matrix to obtain a fault prediction result.

[0058] In the embodiment of the present application, analyzing the multi-dimensional performance indicators to obtain a multi-index correlation matrix representing the spatio-temporal correlation characteristics between indicators includes the following steps A1 - A3:

[0059] Step A1, set a sliding time window according to a preset length.

[0060] Specifically, through a 5-minute fixed-length sliding window (matched with the typical fault latency of cloud phones), the continuously collected multi-dimensional time-series data (such as more than 20 indicators like CPU usage rate, memory occupancy rate, network latency, etc.) is segmented into overlapping time slices. The window length is set based on the law of cloud phone fault evolution - experiments show that 92% of faults such as memory leaks and CPU overloads will exhibit characteristic index fluctuations within 5 minutes. The window sliding step size is synchronized with the collection frequency (default 30 seconds) to ensure that adjacent windows overlap by 80%, which not only preserves the time-series continuity but also avoids interference from high-frequency jitter. For example, for the memory occupancy rate indicator, the window covers 10 consecutive collection points (5×60s / 30s), fully capturing the progressive fault process of "slow growth → rapid increase → threshold breakthrough".

[0061] Step A2, perform a sliding operation on the multi-dimensional performance indicators through a sliding time window, and calculate the statistical characteristic values of each performance indicator within the window.

[0062] Specifically, within each 5-minute window, 7 types of statistical characteristics are extracted for a single-dimensional indicator (such as disk I / O latency): mean, variance, skewness, kurtosis, maximum value, minimum value, slope (Δ indicator / Δ time), forming a 140-dimensional feature vector (20 indicators × 7 features). Taking the CPU overload scenario as an example, if the CPU mean within the window is continuously > 85% and the slope > 2% / minute, combined with a variance < 5% (stable high load), the risk of resource starvation can be predicted. For cross-dimensional indicator pairs (such as CPU usage rate and memory swap count), the co-features within the window are additionally calculated - such as the conditional probability distribution of the memory swap count when the CPU mean > 90%, capturing the implicit association of "CPU overload triggering memory swapping". This design breaks through the limitations of traditional single-dimensional analysis, and experiments show that it can improve the discrimination of complex fault characteristics by 23%.

[0063] Step A3, calculate the cross-dimensional indicator correlation based on the statistical characteristic values, and construct a multi-indicator correlation matrix using the indicator correlation.

[0064] Specifically, based on the statistical features within the window, an improved Pearson correlation coefficient (considering the normalization of the index dimension) can be used to calculate the correlation degree between any two indicators, forming a 20×20 symmetric matrix. For example, when the correlation degree between the CPU usage rate and the network throughput is greater than 0.7 (positively correlated), and the correlation degree with the disk I / O latency is less than -0.5 (negatively correlated), the typical scenario of "computation-intensive tasks causing network congestion and disk idleness" can be identified. Each element in the matrix is appended with a timestamp (the end time of the window), forming spatio-temporal correlation features with time series labels. Further, through threshold filtering (retaining connections with the absolute value of the correlation degree greater than 0.4), a sparse matrix (with an average non-zero element ratio of 31%) is generated, which reduces the computational complexity while retaining 96% of the key fault correlation patterns (such as the strong correlation that memory leakage must be accompanied by a sharp increase in the swap count). This matrix is directly used as the input for the subsequent CNN, providing a structured data basis for spatial feature extraction.

[0065] In the embodiment of the present application, based on the multi-index correlation matrix, a fault prediction is performed to obtain a fault prediction result, including the following steps B1 - B3:

[0066] Step B1: Extract the time series features in the multi-index correlation matrix and the spatial correlation features between multiple performance indicators.

[0067] Specifically, the time series features and the spatial correlation features are separated from the multi-index correlation matrix (a 20×20 sparse matrix with spatio-temporal labels). The time series features are extracted by a bidirectional LSTM layer: the input is a sliding window sequence of the matrix arranged according to timestamps (such as 10 consecutive 5-minute windows), and a 128-unit bidirectional LSTM captures the time evolution law of the indicator correlation degree - for example, in the case of a memory leakage scenario, the correlation degree between "memory occupancy - disk swap count" will gradually increase from 0.5 (initial) to 0.8 (deterioration), and the LSTM learns this progressive correlation enhancement pattern through backpropagation. The spatial features are extracted by a CNN: a 3×3 convolutional kernel scans the correlation matrix to capture the local correlation patterns across indicators, such as the triangular correlation of "CPU overload - network latency - instance migration frequency" (the convolutional kernel weights are encoded as [0.6, -0.3, 0.5]). The two types of features respectively retain the time series continuity (such as the correlation degree change curve in the past 30 minutes) and the spatial structure (such as the indicator dependency graph at the current moment), providing differentiated inputs for subsequent fusion.

[0068] Step B2: Determine the weighting ratio according to the current system load status, and fuse the time series features and the spatial correlation features according to the weighting ratio to obtain the fused features.

[0069] Specifically, according to the real-time system load status (determined by 5-dimensional load metrics such as the current number of active cloud mobile phone instances and the average session connection count), the fusion weights α / β (range 0.1 - 0.9) of temporal and spatial features are dynamically adjusted. For example:

[0070] High-load scenario (number of instances greater than 80% of the cluster capacity): α = 0.7, β = 0.3. Prioritize temporal features (such as the continuous upward trend of CPU usage rate) to avoid interference from spatial correlation noise for quick decision-making;

[0071] Low-load scenario (number of instances less than 30%): α = 0.3, β = 0.7. Focus on spatial features (such as the abnormal negative correlation between network latency and GPU utilization) to discover potential configuration problems.

[0072] The exponential smoothing algorithm is introduced for weight calculation and dynamically corrected according to the load fluctuations in the previous 5 windows (for example, when the load suddenly increases, α rises from 0.5 to 0.8 within 2 windows). The fusion method uses weighted splicing: the 128-dimensional temporal features (LSTM output) and the 64-dimensional spatial features (flattened after CNN convolution) are dimensionally allocated according to the weights to form a 256-dimensional fusion feature vector, which not only retains the temporal context but also highlights the spatial metric collaboration.

[0073] Step B3, input the fusion features into the fault prediction model, and output the fault type and the corresponding prediction confidence as the fault prediction result.

[0074] Specifically, input the fusion features into the LSTM-CNN hybrid model (trained with millions of samples, including 30-day fault annotation data), and output the probability distribution of 5 types of faults (memory leak, network congestion, CPU overload, storage bottleneck, hybrid fault) through the Softmax layer. For example, when both the "correlation between memory occupancy rate and swap times continuously greater than 0.7" (temporal) and the "spatial correlation diffusion between memory metrics and other metrics" (spatial) appear in the fusion features, the model outputs a confidence of 92% for memory leak and triggers the repair strategy of Embodiment 1. The prediction entropy value constraint is introduced for confidence calculation: if the entropy value output by Softmax is greater than 1.5 (indicating that the probabilities of multiple classes are close), the confidence is automatically reduced by 20% to avoid false repairs caused by fuzzy predictions. The output result synchronously carries the fault type (such as "CPU overload, prediction confidence 85%"), directly driving the policy matching of the repair decision engine (such as the task scheduling priority policy).

[0075] It should be noted that such as Figure 2As shown, the fault prediction model architecture is used for fault prediction and integrates the LSTM and CNN networks. Among them, the LSTM layer receives the time series performance metric data from the data acquisition layer, processes the bidirectional time series through a bidirectional LSTM with 128 units, extracts the time series features and transmits them to the feature fusion layer; the CNN layer receives the multi-metric correlation matrix generated by the feature engineering module, extracts the spatial correlation features using a 3×3 convolutional kernel, and also outputs to the feature fusion layer. Finally, the feature fusion layer performs weighted splicing on the time series features and spatial features to generate prediction features, and finally outputs the fault prediction result and transmits it to the repair decision engine to achieve the prediction and analysis of faults.

[0076] As an example, Figure 3 For the example structure diagram of the repair strategy decision tree, as Figure 3 shown, different repair processes are designed for three types of faults of cloud phones: for memory leaks, first judge whether the memory occupancy rate is > 90%, if satisfied, execute memory recovery, if successful, end the repair, if failed, isolate the instance and generate a diagnostic report; for network latency, first judge whether the P99 latency is > 200ms, if satisfied, adjust the QoS policy, if failed, try to switch the network path and trigger bandwidth expansion in turn; for CPU overload, first judge whether the CPU usage rate is > 95%, if satisfied, execute task scheduling, if successful, end, if failed, increase the instance resources and generate a performance optimization report. By hierarchically judging the fault conditions, executing the corresponding repair actions and subsequent processing, a clear decision path is formed to ensure that different types of faults are repaired according to the rules and targeted operation and maintenance is achieved.

[0077] Step S13, screen the target repair strategy that matches the fault prediction result from the multi-level repair strategy library, and execute the repair operation according to the target repair strategy to obtain the key index change rate.

[0078] In the embodiment of the present application, screening the target repair strategy that matches the fault prediction result from the multi-level repair strategy library includes the following steps C1 - C3:

[0079] Step C1, parse the fault type and prediction confidence level in the fault prediction result.

[0080] Specifically, binary decision factors are extracted from the fault prediction results: the fault type (such as "memory leak") and the prediction confidence. The prediction result string (such as "CPU overload, prediction confidence 85%") is parsed through regular expressions. The fault type is mapped to the classification label in the policy library, and the confidence value is stored in the context parameter of the decision engine. For example, when the model outputs "memory leak, confidence 92%", the system recognizes it as a trigger condition and marks the confidence level as "high" (≥90%); if the confidence is 75%, it is marked as "medium" (70%-90%). This parsing process strictly matches the metadata labels in the policy library (for example, each policy in the policy library contains {fault type, confidence threshold} attributes) to ensure the accuracy of subsequent filtering.

[0081] Step C2, determine the screening criteria according to the fault type and the prediction confidence, and traverse multiple preset repair strategies in the multi-level repair policy library to obtain candidate repair strategies that match the screening criteria.

[0082] Specifically, according to the fault type + confidence level, candidate strategies are filtered from the three-level policy library (emergency / conventional / conservative). For example: memory leak (high confidence), directly match the "memory recovery → isolate instance" strategy in Embodiment 1 (emergency level, the trigger condition requires a confidence of greater than or equal to 90%); memory leak (medium confidence), screen the memory recovery sub-strategy (conventional level, applicable to a confidence of 70%-90%), and exclude high-risk operations such as isolating instances; network latency (low confidence), only match the QoS adjustment strategy (conservative level, avoid high-cost operations such as switching network paths).

[0083] The confidence-risk association rule is introduced in the screening process: for every 10% reduction in confidence, the policy risk level is downgraded by one level (for example, high confidence allows operations that affect 5% of the cluster resources, and medium confidence is restricted to 2%). When traversing the policy library, 3-5 candidate strategies are quickly located through a SQL-like query (SELECT * FROM policy library WHERE fault type =? AND confidence threshold <=? ORDER BY risk level ASC) to form a priority queue.

[0084] Step C3, adjust the repair parameters in the candidate repair strategy to obtain the target repair strategy.

[0085] In the embodiment of the present application, Step C3 includes the following steps C31-C32:

[0086] Step C31, obtain the historical execution records of the candidate repair strategy.

[0087] Specifically, retrieve historical records strongly related to the candidate policy from the policy execution log database, with the time range limited to the most recent 72 hours (covering the typical fault cycle of cloud phones), including three types of core data: basic metadata (fault type, confidence level, execution time); operation records (such as the number of retries for memory recovery, specific values for bandwidth expansion); and effect feedback (change rate of memory occupancy rate 5 minutes after repair, instance recovery time). For example, when the candidate policy is memory recovery, obtain the most recent 20 execution records through SQL query, which include the detailed log of a certain recovery failure due to a high memory fragmentation rate (fragmentation rate 65%, duration 12 seconds, failure code 102). These records are stored in a distributed time series database (such as InfluxDB), indexed by policy ID + fault type, and the query latency is controlled within 50 ms to ensure real-time decision-making.

[0088] Step C32, extract the performance parameters from the historical execution records, and adjust the repair parameters in the candidate repair policy according to the performance parameters to obtain the target repair policy.

[0089] Specifically, extract three performance parameters from the historical records: average repair time (such as the average memory recovery time is 42 seconds, standard deviation 8 seconds): if the current cluster memory fragmentation rate > 50% (obtained in real time through the data acquisition layer), extend the single recovery duration from the default 10 seconds to 15 seconds, and increase the number of retries from 3 times to 5 times (calculation formula: number of retries = base value + fragmentation rate × 0.1, upper limit 5 times); success rate fluctuation (such as the success rates in the recent 3 times are 75% → 82% → 90%): if the success occurs continuously for 3 times, relax the trigger threshold of "isolating instances" from the memory occupancy rate > 95% to > 92%, and intervene in advance for prevention (reward mechanism based on reinforcement learning: +0.1 for each success, -0.3 for each failure); index recovery slope (such as the memory occupancy rate decline slope is 1.2% / second): if the current cluster average load > 80%, forcefully reduce the maximum number of "isolating instances" from 10 to 3 to avoid cascade failures caused by large-scale operations (safety constraint formula: isolation upper limit = number of cluster instances × (1 - load rate), upper limit ≤ 5 when the load rate > 80%).

[0090] Taking network latency repair as an example, if the historical records show that the success rate of the "switch network path" operation is only 60% when the P99 latency is greater than 300 ms (due to insufficient bandwidth of the alternative path), the system automatically adjusts the trigger condition to directly trigger bandwidth expansion when the P99 latency is greater than 250 ms, and at the same time increases the expansion threshold from 50 Mbps to 80 Mbps (bandwidth-latency correlation analysis based on historical successful cases: r = 0.78). After the parameter adjustment, the success rate of this policy is increased from 60% to 89%, and the MTTR is shortened from 3 minutes to 1 minute and 20 seconds, directly corresponding to the "shortening of the average repair time" in the patent technology effect.

[0091] Step S14, trigger the policy optimization mechanism to iteratively update the target repair policy according to the key indicator change rate until the key indicator change rate meets the preset dynamic balance condition.

[0092] In the embodiment of the present application, step S14 includes the following steps D1 - D4:

[0093] Step D1, calculate the key indicator change rate after the repair operation is executed.

[0094] As an example, based on the differential verification mechanism, taking the execution time of the repair operation as the reference point (t0), calculate the absolute change rate and trend change rate of the key indicator within 5 minutes after the repair (t0 + 300s). For example, for memory leak repair (Example 1), the key indicator is the memory occupancy rate, and the change rate formula is:

[0095]

[0096] If the memory occupancy rate before repair is 92% and it drops to 75% within 5 minutes after repair, then ΔM = -18.5%. At the same time, calculate the trend change rate to reflect the continuous effect after the repair:

[0097]

[0098] The system pre - defines 12 types of key indicators (such as CPU, memory, network P99 latency), and each failure type corresponds to 3 - 5 core indicators (memory leak corresponds to memory occupancy rate, swap times, number of processes). The data is sourced from the time - series database of Prometheus, and the latency is controlled within 200ms.

[0099] Step D2, compare the key indicator change rate with the dynamic threshold.

[0100] Specifically, the dynamic threshold is generated dynamically according to the failure type + cluster load. For example: Memory leak (high load): ΔM needs to be less than -15% (5% of memory is allowed to remain for warm start under high load); Memory leak (low load): ΔM needs to be less than -25% (complete cleaning is required under low load).

[0101] The threshold calculation formula is: Threshold = Baseline value × (1 + Load rate × 0.3), where the baseline value comes from successful repair cases of historical same - type failures (such as the average ΔM for successful memory leak repair is -22%). When comparing, if ΔM = -18% (high - load scenario) and meets the threshold (-15%), it is determined that the repair is effective; if ΔM = -12%, then trigger the policy update. This mechanism avoids the rigidity problem of traditional fixed thresholds (such as having to drop below 70%), and the measured repair compliance rate is increased by 41%.

[0102] Step D3, when the change rate of the key indicator does not reach the corresponding dynamic threshold, update the policy weight parameter of the target repair policy until the change rate of the key indicator reaches the dynamic threshold, and determine that the repair effect meets the preset dynamic balance condition.

[0103] Specifically, when the change rate does not reach the threshold, update the policy weight parameter through reinforcement learning. Taking the memory recovery policy as an example: the retry times weight w1 = 0.6 (affecting the retry times), and the isolation threshold weight w2 = 0.4 (affecting the isolation trigger condition); if ΔM = -12% (not reaching the standard), according to the historical record (3 successful retries last time), increase w1 to 0.8, and the next retry times change from 3 to 4, while w2 decreases to 0.2 (delaying the isolation trigger); after each adjustment, re-execute the repair until ΔM < -15%. The weight update uses an exponential decay learning rate. For example, the initial learning rate is 0.5, and it decays by 0.8 each iteration to ensure that the later adjustments tend to be stable. The policy parameters are stored in a distributed key-value database (such as Etcd), supporting real-time synchronization of all nodes within the cluster.

[0104] Step D4, when the change rate of the key indicator does not reach the dynamic threshold and the number of updates reaches the preset number, determine that the repair effect does not meet the preset dynamic balance condition.

[0105] Specifically, the system sets an iteration limit of 3 times (configurable). If ΔM still does not reach the standard after 3 adjustments (such as ΔM = -10% after memory leak repair), trigger the following operations: reduce the "historical success rate" of the current policy from 89% to 65%, and add the label "requires manual analysis"; automatically switch to the memory leak - forced isolation baseline policy in the backup policy library (regardless of confidence, directly isolate all abnormal instances); summarize the repair records, indicator change curves, and policy iteration logs, and push them to the operation and maintenance platform to trigger manual intervention. This mechanism avoids ineffective repair loops. For example, due to kernel version compatibility in a certain cluster, the memory recovery fails. After 3 iterations, the baseline policy is automatically switched, avoiding continuous performance deterioration.

[0106] In the embodiment of the present application, the method further includes:

[0107] Step S21, within a preset verification period after the repair operation is executed, inject traffic pressure data simulating the user behavior distribution into the repaired cloud mobile phone cluster, and monitor the composite verification indicators of the cloud mobile phone cluster.

[0108] In the embodiments of the present application, during the 5-minute verification period (matching the fault latency period) after the repair operation is executed, the system sends load data simulating user behaviors to the repaired cloud mobile phone cluster through the traffic injection engine. The data sources include: historical user session logs (such as CPU bursts during game hanging and short-term high network concurrency during application testing); pressure templates generated in real time (such as simulating 1,000 users starting the short video APP simultaneously). The injection strategy adopts stratified sampling: according to the current cluster load (obtained in real time through Prometheus), 120% of the peak traffic is injected under low load, and 80% of the base traffic is injected under high load to avoid overwhelming the system under repair. The monitored composite verification metrics include: CPU utilization volatility (±15% after repair is the safety margin), memory occupancy recovery curve (dropping below the threshold of 85% within 5 minutes), and user operation response time (P99 < 300 ms). For example, after a memory leak repair, a simulated behavior of "continuously opening 5 applications" is injected. If the memory occupancy rate rises from 75% to 88% (exceeding the safety margin), a policy adjustment is triggered.

[0109] Step S22: When the composite verification metric exceeds the preset safety margin, dynamically adjust the execution priority of the target repair policy.

[0110] In the embodiments of the present application, when the composite metric exceeds the safety margin (such as the network delay P99 rebounds from 180 ms after repair to 250 ms), the system reorders the repair policies through the reinforcement learning priority queue. Specific mechanism: According to the degree of metric overrun (such as a delay overrun of 50 ms → risk level L2) and the duration (the overrun is greater than 2 minutes → weight +0.3), calculate the policy priority coefficient (formula: priority = base level × (1 + overrun duration / 60 s)); for example, the original memory recovery policy has a priority of L3 (regular). If it is verified that the memory volatility is greater than 20%, it is upgraded to L1 (urgent). At the same time, the trigger condition for isolating instances is reduced from 95% memory occupancy to 90%; skip "memory recovery retry" through the decision tree and directly execute the isolation operation.

[0111] Step S23: If the adjusted composite verification metric continues to exceed the preset safety margin, then call the baseline repair template preset in the backup policy library to overwrite the target repair policy.

[0112] Specifically, if the composite index continuously exceeds the limit for two consecutive verification periods (10 minutes) (for example, the memory occupancy rate is stable at 92%), the system triggers the policy fusing mechanism: call the memory leak - forced isolation baseline template from the backup policy library (independent of the online policy library, storing historically effective solutions verified manually). The template has a fixed isolation threshold of 85% and a maximum number of isolated instances of 10 (1.5 times that of the regular policy); suspend dynamic optimization, and force the execution of the repair 3 times using the baseline template. During this period, parameter adjustment is disabled; record the reason for fusing (such as the policy not meeting the standard after 3 iterations) and the execution effect of the baseline template (such as the memory dropping to 70% after isolation), and push it to the operation and maintenance platform to trigger root cause analysis. For example, due to a kernel bug in the container host of a certain cluster, the memory recovery fails. After fusing, abnormal instances are forced to be isolated, avoiding a continuous 15 - minute performance degradation.

[0113] As an example, Figure 4 As shown, the closed - loop operation and maintenance process for real - time performance monitoring and fault repair of cloud mobile phones specifically includes: First, collect multi - dimensional performance indicators of the cloud mobile phone cluster, generate fault prediction features through feature engineering processing, and determine whether there is a fault through a hybrid prediction model. If a fault is predicted, enter the repair decision - making stage, select and execute a repair strategy, and then evaluate the effect by comparing the change rate of indicators before and after repair through a differential verification mechanism. If the repair is successful, optimize the strategy to form a closed loop; if it fails, adjust the strategy and execute it again; if no fault is predicted, continue continuous monitoring and cycle data collection. The entire process runs through the links of "data collection - fault prediction - repair execution - effect verification - strategy optimization", constructing a full - closed - loop intelligent operation and maintenance system for monitoring, prediction, repair, and verification, ensuring the stability and operation and maintenance efficiency of cloud mobile phone services.

[0114] In this embodiment, a cloud mobile phone intelligent operation and maintenance system is provided. Figure 5 It is the structural block diagram of the cloud mobile phone intelligent operation and maintenance system according to the embodiment of the present invention. Figure 5As shown in the figure, the core process of the system is as follows: First, the data collection layer collects the performance indicators of the cloud mobile phone cluster through Prometheus (an open-source monitoring system), a customized Exporter (a customized data collector), and a configurable collection frequency (default once every 30 seconds). Then, the feature engineering module processes the data, uses a 5-minute sliding window statistic to extract time series features, and analyzes the correlation of multiple indicators to generate composite features. Subsequently, the hybrid prediction model intervenes. The LSTM layer processes the time series data to extract time features, the CNN layer analyzes the spatial correlation features of multiple indicators, and finally, the two types of features are weighted and spliced through the feature fusion layer to generate a prediction result. The prediction result is input into the repair decision engine, and a repair strategy is generated through a policy matching unit (selects a policy according to the fault type and confidence level), a parameter optimization unit (adjusts parameters based on historical records), and a security constraint unit (ensures operation safety). Finally, the verification feedback module compares the indicator changes before and after repair through a differential verification mechanism, evaluates the repair effect, and optimizes the policy according to the result, forming a closed-loop management system from monitoring, prediction to repair and optimization.

[0115] In this embodiment, a cloud mobile phone intelligent operation and maintenance device is also provided. This device is used to implement the above-mentioned embodiment and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that realizes a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0116] This embodiment provides a cloud mobile phone intelligent operation and maintenance device, as Figure 6 shown, including:

[0117] An acquisition module 61, configured to collect multi-dimensional performance indicators of a cloud mobile phone cluster through a configurable collector at a preset frequency;

[0118] An analysis module 62, configured to analyze multi-dimensional performance indicators, obtain a multi-indicator correlation matrix characterizing the spatio-temporal correlation characteristics between indicators, and perform fault prediction based on the multi-indicator correlation matrix to obtain a fault prediction result;

[0119] A screening module 63, configured to screen a target repair strategy matching the fault prediction result from a multi-level repair strategy library, and perform a repair operation according to the target repair strategy to obtain a key indicator change rate;

[0120] An update module 64, configured to trigger a policy optimization mechanism to iteratively update the target repair strategy according to the key indicator change rate until the key indicator change rate meets a preset dynamic balance condition.

[0121] Furthermore, the analysis module 62 includes a calculation sub-module and a fusion sub-module;

[0122] A calculation sub-module, configured to set a sliding time window according to a preset length; perform a sliding operation on multi-dimensional performance metrics through the sliding time window, calculate the statistical eigenvalue of each performance metric within the window; calculate the cross-dimensional metric correlation based on the statistical eigenvalue, and construct a multi-metric correlation matrix using the metric correlation.

[0123] A fusion sub-module, configured to extract the temporal feature in the multi-metric correlation matrix and the spatial correlation feature between multiple performance metrics; determine a weighting ratio according to the current system load status, and fuse the temporal feature and the spatial correlation feature according to the weighting ratio to obtain a fused feature; input the fused feature into a fault prediction model, and output the fault type and the corresponding prediction confidence as the fault prediction result.

[0124] Further, a screening module 63, configured to parse the fault type and prediction confidence in the fault prediction result; determine a screening criterion according to the fault type and prediction confidence, and traverse multiple preset repair strategies in a multi-level repair strategy library to obtain candidate repair strategies that match the screening criterion; adjust the repair parameters in the candidate repair strategies to obtain a target repair strategy.

[0125] Further, the screening module 63 further includes an acquisition sub-module and an extraction sub-module;

[0126] The acquisition sub-module is configured to acquire the historical execution record of the candidate repair strategy;

[0127] The extraction sub-module is configured to extract the effectiveness parameter from the historical execution record, and adjust the repair parameter in the candidate repair strategy according to the effectiveness parameter to obtain a target repair strategy.

[0128] Further, an update module 64, configured to calculate the change rate of the key metric after the repair operation is executed; compare the change rate of the key metric with a dynamic threshold; when the change rate of the key metric does not reach the corresponding dynamic threshold, update the policy weight parameter of the target repair strategy until the change rate of the key metric reaches the dynamic threshold, and determine that the repair effect meets the preset dynamic balance condition; when the change rate of the key metric does not reach the dynamic threshold and the number of updates reaches the preset number, determine that the repair effect does not meet the preset dynamic balance condition.

[0129] Further, the device further includes: an injection module, configured to inject traffic pressure data simulating the user behavior distribution into the repaired cloud phone cluster within a preset verification period after the repair operation is executed, and monitor the composite verification metrics of the cloud phone cluster; when the composite verification metrics exceed the preset safety boundary, dynamically adjust the execution priority of the target repair strategy; if the adjusted composite verification metrics continuously exceed the preset safety boundary, then call the baseline repair template preset in the backup strategy library to overwrite the target repair strategy.

[0130] Please refer toFigure 7 , Figure 7 is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention. As shown in Figure 7 , the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system).

[0131] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.

[0132] Among them, the memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0133] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device presented by a kind of landing page of a small program, etc. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0134] The memory 20 can include a volatile memory, for example, a random access memory; the memory can also include a non-volatile memory, for example, a flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memories.

[0135] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0136] Embodiments of the present invention also provide a computer-readable storage medium. The method according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code that is originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code, and when the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0137] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for intelligent operation and maintenance of cloud mobile phones, characterized in that, The method includes: Collecting multi-dimensional performance metrics of a cloud phone cluster at a preset frequency through a configurable collector; Analyzing the multi-dimensional performance metrics to obtain a multi-index correlation matrix characterizing the spatio-temporal correlation characteristics among the metrics, and performing fault prediction based on the multi-index correlation matrix to obtain a fault prediction result; Screening a target repair strategy matching the fault prediction result from a multi-level repair strategy library, and performing a repair operation according to the target repair strategy to obtain a key index change rate; Triggering a strategy optimization mechanism according to the key index change rate to iteratively update the target repair strategy until the key index change rate meets a preset dynamic balance condition.

2. The method according to claim 1, wherein The analyzing the multi-dimensional performance metrics to obtain a multi-index correlation matrix characterizing the spatio-temporal correlation characteristics among the metrics includes: Setting a sliding time window according to a preset length; Performing a sliding operation on the multi-dimensional performance metrics through the sliding time window, and calculating statistical eigenvalue of each performance metric within the window; Calculating the cross-dimensional index correlation degree based on the statistical eigenvalue, and constructing a multi-index correlation matrix by using the index correlation degree.

3. The method according to claim 1, wherein The performing fault prediction based on the multi-index correlation matrix to obtain a fault prediction result includes: Extracting the time series characteristics in the multi-index correlation matrix and the spatial correlation characteristics among multiple performance metrics; Determining a weighting ratio according to the current system load status, and fusing the time series characteristics and the spatial correlation characteristics according to the weighting ratio to obtain a fused characteristic; Inputting the fused characteristic into a fault prediction model, and outputting the fault type and the corresponding prediction confidence as the fault prediction result.

4. The method according to claim 1, characterized in that, The screening a target repair strategy matching the fault prediction result from a multi-level repair strategy library includes: Analyzing the fault type and prediction confidence in the fault prediction result; Determining a screening criterion according to the fault type and the prediction confidence, and traversing multiple preset repair strategies in the multi-level repair strategy library to obtain candidate repair strategies matching the screening criterion; Adjusting the repair parameters in the candidate repair strategies to obtain a target repair strategy.

5. The method according to claim 4, wherein The adjusting the repair parameters in the candidate repair strategies to obtain a target repair strategy includes: Obtaining the historical execution record of the candidate repair strategy; Extracting the efficiency parameters from the historical execution record, and adjusting the repair parameters in the candidate repair strategies according to the efficiency parameters to obtain a target repair strategy.

6. The method according to claim 1, characterized in that The triggering a strategy optimization mechanism according to the key index change rate to iteratively update the target repair strategy until the key index change rate meets a preset dynamic balance condition includes: Calculating the key index change rate after the repair operation is executed; Comparing the key index change rate with a dynamic threshold; When the key index change rate does not reach the corresponding dynamic threshold, updating the strategy weight parameter of the target repair strategy until the key index change rate reaches the dynamic threshold, and determining that the repair effect meets the preset dynamic balance condition; When the key index change rate does not reach the dynamic threshold and the number of updates reaches a preset number, determining that the repair effect does not meet the preset dynamic balance condition.

7. The method according to claim 1, wherein The method further includes: Injecting traffic pressure data simulating the user behavior distribution into the repaired cloud phone cluster within a preset verification period after the repair operation is performed, and monitoring the composite verification metrics of the cloud phone cluster; When the composite verification metrics exceed a preset safety boundary, dynamically adjusting the execution priority of the target repair strategy; If the adjusted composite verification metrics continue to exceed the preset safety boundary, invoking a baseline repair template preset in the backup policy library to overwrite the target repair strategy.

8. A cloud mobile phone intelligent operation and maintenance device, characterized in that, The apparatus includes: An acquisition module, configured to acquire multi-dimensional performance metrics of a cloud phone cluster at a preset frequency through a configurable collector; An analysis module, configured to analyze the multi-dimensional performance metrics to obtain a multi-metric correlation matrix characterizing the spatio-temporal correlation characteristics among the metrics, and perform fault prediction based on the multi-metric correlation matrix to obtain a fault prediction result; A screening module, configured to screen a target repair strategy matching the fault prediction result from a multi-level repair policy library, and perform a repair operation according to the target repair strategy to obtain a key metric change rate; An update module, configured to trigger a policy optimization mechanism to iteratively update the target repair strategy according to the key metric change rate until the key metric change rate meets a preset dynamic balance condition.

9. A computer device, characterized in that, Including: A memory and a processor, where the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the method according to any one of claims 1 to 7.

Images