Cloud service quality evaluation method and device, electronic equipment and storage medium

Abstract

The invention provides a cloud service quality evaluation method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining the operation index data of each level of a target cloud service, the operation index data comprising the index values of an infrastructure layer resource index, a platform layer service index and an application layer performance index; performing standardization processing on the operation index data; the evaluation weight is dynamically calculated based on the data distribution characteristics of all the operation indexes and a service topological graph, the data distribution characteristics are obtained by analyzing the statistical characteristics of the operation index data, and the service topological graph is obtained by analyzing the calling relation between services; generating a quality evaluation result according to the operation index data after standardization processing and the evaluation weight; and displaying the quality evaluation result in a multi-dimensional chart form. Therefore, the reliability and observability of the cloud service are improved.

Description

Technical Field

[0001] This application relates to the field of service quality assessment technology, and in particular to a cloud service quality assessment method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, the requirements for quality assessment of cloud services are becoming increasingly complex. Traditional software quality assessment methods are mainly geared towards monolithic applications or single testing phases, while modern cloud services (such as IaaS, PaaS, and SaaS) involve multi-layered architectures (infrastructure, platform, and application layers), and their quality assessment needs to cover multiple dimensions such as preventative capabilities, real-time monitoring capabilities, and fault recovery capabilities. Furthermore, the quality characteristics of different cloud service types vary significantly. For example, the high availability requirements of database services and the computational throughput requirements of big data services have different weights, making traditional static weighting assessment methods difficult to adapt to such dynamic needs.

[0003] Therefore, there is an urgent need for a quality capability assessment scheme that can collect multi-source data in real time, dynamically calculate weights, and intuitively display assessment results in order to improve the reliability and observability of cloud services. Summary of the Invention

[0004] This application provides a cloud service quality assessment method, apparatus, electronic device, and storage medium to provide a quality capability assessment scheme that can collect multi-source data in real time, dynamically calculate weights, and intuitively display assessment results.

[0005] Firstly, this application provides a cloud service quality assessment method, including:

[0006] Obtain operational indicator data for each layer of the target cloud service, including the indicator values ​​for infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators;

[0007] The operational indicator data are standardized.

[0008] The evaluation weights are dynamically calculated based on the data distribution characteristics and service topology diagram of each operational indicator. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operational indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships.

[0009] A quality assessment result is generated based on the standardized operational indicator data and the assessment weights.

[0010] The quality assessment results are presented in the form of multidimensional charts.

[0011] In one possible implementation, the dynamic calculation of evaluation weights based on the data distribution characteristics and service topology of each operational indicator includes:

[0012] The initial indicator weights are obtained based on the data distribution characteristics of each operational indicator;

[0013] By analyzing the in-degree, traffic weight, and fault propagation rate of each service node in the service topology graph, the service node topology influence factor is calculated.

[0014] Establish a mapping relationship between operational metrics and service nodes, where infrastructure layer resource metrics are mapped to host nodes, platform layer service metrics are mapped to corresponding service instance nodes, and application layer performance metrics are mapped to microservice nodes.

[0015] The dynamically adjusted evaluation weights are obtained by using the initial weights of each operational indicator and the topological influence factors of the corresponding mapping nodes.

[0016] In one possible implementation, obtaining the initial indicator weights based on the data distribution characteristics of each operating indicator includes:

[0017] The weights of the basic indicators are obtained by calculating the data distribution characteristics of each operational indicator using the entropy weight method.

[0018] Obtain predefined industry benchmark weights, which are statistically derived from historical evaluation data of similar cloud services;

[0019] The initial indicator weights are obtained by weighting and fusing the basic indicator weights with the industry benchmark weights.

[0020] In one possible implementation, the method further includes:

[0021] Determine the type attribute of the target cloud service;

[0022] Determine the weight correction coefficient based on the type attribute;

[0023] The evaluation weights are adjusted according to the weight adjustment coefficients to obtain the adjusted evaluation weights.

[0024] In one possible implementation, the standardization process for the operational indicator data includes:

[0025] The operational indicator data is subjected to unit standardization processing to obtain initial processed data;

[0026] The abnormal index data in the initial processing data are corrected to obtain intermediate processing data;

[0027] Based on the service tree information in the configuration management database, host-level operation metrics are associated with corresponding microservice instances to establish cross-level metric mapping relationships. The service tree information includes at least the attribution relationships between host nodes, container nodes, and microservice nodes. The association operation includes aggregating all underlying resource metrics that each microservice instance depends on.

[0028] In one possible implementation, after displaying the quality assessment results in the form of a multidimensional chart, the method further includes:

[0029] In response to the selection operation of the first target dimension, the associated indicator data corresponding to the first target dimension is retrieved from the pre-established indicator association library. The indicator association library includes at least one of business logic association, technology stack association, and time series association.

[0030] The related indicator data are displayed in the form of auxiliary charts.

[0031] In one possible implementation, after displaying the quality assessment results in the form of a multidimensional chart, the method further includes:

[0032] In response to the selection operation of the second objective dimension, the contribution rate of each operational indicator under the second objective dimension is determined;

[0033] The key influencing factors are identified as the operational indicators whose contribution rate is lower than the first preset threshold and whose actual value deviates from the target value by more than the second preset threshold.

[0034] The key influencing factors and corresponding improvement suggestions are presented.

[0035] Secondly, this application provides a cloud service quality assessment device, comprising:

[0036] The acquisition module is used to acquire operational indicator data of each layer of the target cloud service. The operational indicator data includes the indicator values ​​of infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators.

[0037] The processing module is used to standardize the operational indicator data;

[0038] The calculation module is used to dynamically calculate the evaluation weights based on the data distribution characteristics of each operating indicator and the service topology diagram. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operating indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships.

[0039] The generation module is used to generate quality assessment results based on the standardized operational indicator data and the assessment weights.

[0040] The display module is used to present the quality assessment results in the form of multi-dimensional charts.

[0041] In one possible implementation, the computing module is specifically used for:

[0042] The initial indicator weights are obtained based on the data distribution characteristics of each operational indicator;

[0043] By analyzing the in-degree, traffic weight, and fault propagation rate of each service node in the service topology graph, the service node topology influence factor is calculated.

[0044] Establish a mapping relationship between operational metrics and service nodes, where infrastructure layer resource metrics are mapped to host nodes, platform layer service metrics are mapped to corresponding service instance nodes, and application layer performance metrics are mapped to microservice nodes.

[0045] The dynamically adjusted evaluation weights are obtained by using the initial weights of each operational indicator and the topological influence factors of the corresponding mapping nodes.

[0046] In one possible implementation, the computing module is further configured to:

[0047] The weights of the basic indicators are obtained by calculating the data distribution characteristics of each operational indicator using the entropy weight method.

[0048] Obtain predefined industry benchmark weights, which are statistically derived from historical evaluation data of similar cloud services;

[0049] The initial indicator weights are obtained by weighting and fusing the basic indicator weights with the industry benchmark weights.

[0050] In one possible implementation, the computing module is further configured to:

[0051] Determine the type attribute of the target cloud service;

[0052] Determine the weight correction coefficient based on the type attribute;

[0053] The evaluation weights are adjusted according to the weight adjustment coefficients to obtain the adjusted evaluation weights.

[0054] In one possible implementation, the processing module is specifically used for:

[0055] The operational indicator data is subjected to unit standardization processing to obtain initial processed data;

[0056] The abnormal index data in the initial processing data are corrected to obtain intermediate processing data;

[0057] Based on the service tree information in the configuration management database, host-level operation metrics are associated with corresponding microservice instances to establish cross-level metric mapping relationships. The service tree information includes at least the attribution relationships between host nodes, container nodes, and microservice nodes. The association operation includes aggregating all underlying resource metrics that each microservice instance depends on.

[0058] In one possible implementation, the device further includes a first response module for:

[0059] In response to the selection operation of the first target dimension, the associated indicator data corresponding to the first target dimension is retrieved from the pre-established indicator association library. The indicator association library includes at least one of business logic association, technology stack association, and time series association.

[0060] The related indicator data are displayed in the form of auxiliary charts.

[0061] In one possible implementation, the device further includes a second response module for:

[0062] In response to the selection operation of the second objective dimension, the contribution rate of each operational indicator under the second objective dimension is determined;

[0063] The key influencing factors are identified as the operational indicators whose contribution rate is lower than the first preset threshold and whose actual value deviates from the target value by more than the second preset threshold.

[0064] The key influencing factors and corresponding improvement suggestions are presented.

[0065] Thirdly, this application provides an apparatus comprising: a processor and a memory, the processor being configured to execute a cloud service quality assessment program stored in the memory to implement the cloud service quality assessment method described in any one of the first aspects.

[0066] Fourthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the cloud service quality assessment method described in any one aspect.

[0067] Compared with the prior art, the technical solution provided in this application has the following advantages: First, the method provided in this application achieves a three-dimensional evaluation of cloud service quality through the collaborative analysis of multi-dimensional indicators of the infrastructure layer, platform layer, and application layer, overcoming the technical defects of traditional methods with single evaluation dimensions; second, the dynamic weight calculation mechanism based on data distribution characteristics and service topology diagram can adapt to different service types and architectural characteristics, solving the problem that static weight models cannot accurately reflect the key characteristics of services; finally, the evaluation results are presented visually through multi-dimensional charts, making service quality shortcomings and key influencing factors intuitively identifiable, greatly improving the diagnostic efficiency of operation and maintenance personnel. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0069] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0071] Figure 1 A flowchart illustrating an embodiment of a cloud service quality assessment method provided in this application;

[0072] Figure 2 A flowchart illustrating an embodiment of another cloud service quality assessment method provided in this application;

[0073] Figure 3 A block diagram illustrating an embodiment of a cloud service quality assessment device provided in this application;

[0074] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0075] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0076] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0077] Figure 1 This is a flowchart illustrating an embodiment of a cloud service quality assessment method provided in this application. Figure 1 As shown, the method includes the following steps:

[0078] Step 101: Obtain the operational indicator data of each layer of the target cloud service. The operational indicator data includes the indicator values ​​of infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators.

[0079] Target cloud service: refers to the cloud computing service instance to be evaluated, including types such as IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service).

[0080] Operational metrics data refer to quantitative parameters that reflect the operational status of cloud services, including: infrastructure layer resource metrics: physical / virtual resource usage (such as CPU utilization, memory usage); platform layer service metrics: middleware service performance data (such as database QPS, message queue latency); application layer performance metrics: business application performance (such as API response time, error rate).

[0081] In this embodiment, full-stack operational metrics data of the target cloud service can be obtained through a unified acquisition framework based on OpenTelemetry Collector. This framework adopts a modular design of "unified acquisition agent + adapter mode". Here, acquisition agent refers to a lightweight data acquisition program (such as OpenTelemetry Collector) deployed on each node; adapter refers to a protocol conversion module for different data sources (such as JMX adapter, Prometheus adapter).

[0082] The infrastructure layer collects resource metrics such as CPU, memory, and disk of VMs / containers through agents such as Node Exporter; the platform layer obtains managed service metrics such as RDS database connection count and CosmosDB request unit consumption through the native monitoring interfaces of various cloud services (such as AWS CloudWatch and Azure Monitor); and the application layer collects runtime metrics such as JVM heap memory usage and thread pool status through JMX adapters and APM probes, ultimately forming a complete metric dataset covering the IaaS, PaaS, and SaaS three-layer architecture.

[0083] Step 102: Standardize the operational indicator data.

[0084] The standardization process in this application embodiment is used to convert heterogeneous data into a unified and comparable format. Specifically, it may include the following steps: performing unit standardization processing on the operational indicator data to obtain initial processed data; performing correction processing on abnormal indicator data in the initial processed data to obtain intermediate processed data; and establishing a cross-level indicator mapping relationship by associating host-level operational indicators with corresponding microservice instances based on service tree information in the configuration management database. The service tree information at least includes the attribution relationship between host nodes, container nodes, and microservice nodes. The association operation includes aggregating all underlying resource indicators that each microservice instance depends on.

[0085] This solution first standardizes the units of the collected raw data, for example, converting time units to milliseconds and storage units to GB, effectively eliminating dimensional differences between data from different sources. Then, anomaly detection algorithms based on sliding windows and statistical models (such as the 3σ principle) automatically correct anomalous data that suddenly drops to zero or exceeds limits. For example, values ​​exceeding physical limits (such as CPU utilization > 100%) are discarded, and values ​​that suddenly drop to zero are replaced with the average of the preceding and following 5 minutes, significantly improving data quality and reliability. Finally, through the service tree information of the CMDB (Configuration Management Database), host-level metrics are associated with microservices, achieving precise correlation between metrics from the infrastructure layer to the application layer. This builds a monitoring system that spans the entire cloud service stack, significantly improving the efficiency of fault diagnosis and resource tracking in complex cloud environments and solving the technical challenge of fragmented metric correlation in traditional solutions.

[0086] Step 103: Dynamically calculate the evaluation weights based on the data distribution characteristics and service topology diagram of each operating indicator. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operating indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships.

[0087] Data distribution characteristics: used to characterize the statistical properties of index values, quantified by dispersion (such as standard deviation), skewness, kurtosis, etc.

[0088] Service topology graph: A weighted directed graph representing the call relationships between services. Nodes are service instances, and edges represent call dependencies.

[0089] In this embodiment, the evaluation weights are dynamically calculated based on the data distribution characteristics of each operational indicator and the service topology diagram, thereby enabling adaptation to different service types and architectural characteristics.

[0090] The specific method for dynamically calculating evaluation weights based on the data distribution characteristics and service topology of each operational indicator will be explained in detail through the following examples, and will not be elaborated here.

[0091] Step 104: Generate quality assessment results based on the standardized operational indicator data and the assessment weights.

[0092] Quality assessment results refer to multi-dimensional quantitative scores, including: basic capabilities (such as availability); performance (such as throughput); and reliability (such as fault tolerance).

[0093] In this embodiment, standardized operational indicator data and dynamically calculated evaluation weights are comprehensively calculated to generate multi-dimensional quality evaluation results through a weighted aggregation algorithm. Specifically, a hierarchical weighted model is adopted: First, a triple calculation is performed on each operational indicator data (indicator value × dynamic weight × topology influence coefficient). For example, if the CPU utilization rate is 85%, the CPU weight is 0.35, and the CPU topology coefficient is 1.5, then the CPU score = 85% × 0.35 × 1.5 = 44.6 points. Second, dimensional aggregation is performed, configuring hierarchical weight coefficients according to IaaS / PaaS / SaaS service types (e.g., IaaS layer resource indicator weight 0.6), and calculating the weighted score of each quality dimension. Finally, a weakness compensation is implemented, increasing the total score by 20% for dimensions below the threshold (e.g., 60 points), forming a three-dimensional evaluation matrix containing the original score, weighted score, and compensation score.

[0094] Step 105: Present the quality assessment results in the form of a multidimensional chart.

[0095] Multidimensional charts: Charts that can display more than 3 dimensions at the same time, such as 3D radar charts. The front-end uses React + D3.js to implement the page, and the back-end uses the FastAPI framework.

[0096] In this embodiment of the application, the evaluation results are displayed through a visualization system in the form of multi-dimensional charts. Taking a three-dimensional radar chart as an example, each axis of the radar chart represents a quality dimension (such as "fault recovery capability"). The scale value on the axis shows the score of that dimension (such as 0-100 points). The severity of the problem can be intuitively presented through the color gradient (red-yellow-green). For example, red indicates very serious, yellow indicates needing attention, and green indicates normal.

[0097] In another embodiment of this application, after step 105, the following steps may be included: in response to the selection operation of the first target dimension, retrieving the associated indicator data corresponding to the first target dimension from a pre-established indicator association library, wherein the indicator association library includes at least one of business logic association, technology stack association, and time series association; and displaying the associated indicator data in the form of an auxiliary chart.

[0098] Metric Relationship Library: A knowledge base used to store multidimensional relationships between metrics, including: Business logic relationships: metric dependencies based on service call chains (e.g., API call latency from order service to payment service); Technology stack relationships: the impact of shared underlying resources on metrics (e.g., multiple containers competing for host CPU); Time series relationships: correlations in metric fluctuations discovered through historical data analysis (e.g., increased disk IOPS accompanied by increased API latency).

[0099] Auxiliary charts: Derivative visualization components used to supplement the main view, including: Heatmap: showing resource contention related to the technology stack; Call chain topology: presenting the business logic related paths; Dual-axis trend chart: comparing changes in time-series related indicators.

[0100] In this embodiment, when a user selects a dimension (such as a low "API response" score) in the main view (e.g., a radar chart), the system retrieves relevant metrics from the metric association library. If it's a business issue, a call chain topology diagram is displayed (e.g., payment gateway timeout affecting order services); if it's a technical issue, a resource heatmap is displayed (e.g., container CPU contention); if it's a time-series anomaly, a metric trend comparison chart is presented (e.g., the correlation between database QPS surges and API latency fluctuations). All related data is generated through a pre-built real-time analysis pipeline to ensure the response speed of drill-down analysis.

[0101] This solution achieves precise localization and root cause analysis of cloud service quality issues through a pre-built multi-dimensional indicator association library and an intelligent visualization engine. When a user selects a specific evaluation dimension, the system can automatically identify and display underlying indicators that have potential causal relationships with it based on business logic, technology stack, and time-series correlations. It also intuitively presents the problem propagation path through auxiliary charts such as heatmaps and call chain topology diagrams, enabling operations and maintenance personnel to quickly distinguish different fault types such as business logic defects, resource contention, or time-series anomalies, thereby improving the efficiency of fault diagnosis in complex cloud environments. At the same time, the accuracy of correlation analysis is optimized through continuous self-learning of the knowledge base.

[0102] In another embodiment of this application, after step 105, the following steps may be included: in response to the selection operation of the second target dimension, determining the contribution rate of each operating indicator under the second target dimension; identifying operating indicators whose contribution rate is lower than a first preset threshold and whose actual value deviates from the target value by more than a second preset threshold as key influencing factors; and displaying the key influencing factors and corresponding improvement suggestions.

[0103] Contribution rate: The relative influence of an indicator on a dimension score. The formula is: Contribution rate = (Indicator weight × Indicator standardized value) / Dimension total score.

[0104] First preset threshold: the contribution rate qualification line (e.g., 15%), below which the influence is considered weak.

[0105] The second preset threshold is the deviation of the indicator from the tolerance range (e.g., ±20%). Any deviation exceeding this range is considered abnormal.

[0106] In this embodiment, when a user selects a dimension, the system automatically calculates the contribution rate of all indicators under that dimension and filters out abnormal indicators that simultaneously meet the criteria of "low contribution (e.g., <15%)" and "high deviation (e.g., exceeding the target value by 20%)" as key influencing factors. Then, it displays the indicators in a layered manner through a floating window: the upper layer lists the problematic indicators (e.g., "database query latency contribution rate of 12% and exceeding the standard by 35%), and the lower layer pushes pre-set improvement suggestions (e.g., "optimize SQL index #123"). The improvement suggestions can be obtained by matching key influencing factors in the operation and maintenance knowledge base.

[0107] This solution achieves precise location of cloud service quality issues and automated repair suggestion generation through dynamic contribution rate calculation and dual threshold screening mechanism: when users select a specific evaluation dimension, the system automatically identifies key indicators that have a significant impact on the current dimension score and deviate seriously from expectations, and intuitively presents the root cause of the problem and targeted improvement measures through an interactive floating window, enabling operation and maintenance personnel to quickly focus on core issues and obtain actionable solutions, greatly shortening the decision cycle of fault diagnosis and repair, and adapting to the operation and maintenance requirements of different business scenarios through the ability to dynamically adjust preset thresholds.

[0108] The technical solution provided in this application firstly achieves a three-dimensional evaluation of cloud service quality through the collaborative analysis of multi-dimensional indicators at the infrastructure layer, platform layer, and application layer, overcoming the technical shortcomings of traditional methods with only one evaluation dimension. Secondly, the dynamic weight calculation mechanism based on data distribution characteristics and service topology diagrams can adapt to different service types and architectural characteristics, solving the problem that static weight models cannot accurately reflect key service characteristics. Finally, the evaluation results are presented visually through multi-dimensional charts, making service quality shortcomings and key influencing factors intuitively identifiable, significantly improving the diagnostic efficiency of operation and maintenance personnel.

[0109] Figure 2 A flowchart illustrating an embodiment of another cloud service quality assessment method provided in this application. Figure 2 The process shown is in Figure 1 Based on the illustrated process, the following steps are included:

[0110] Step 201: Obtain the initial indicator weights based on the data distribution characteristics of each operating indicator.

[0111] Data distribution characteristics: refers to the statistical characteristics of operational indicator data, including at least one of the statistical measures of indicator value dispersion, skewness and kurtosis.

[0112] In one embodiment, step 201 may include the following steps: calculating the data distribution characteristics of each operational indicator using the entropy weight method to obtain initial indicator weights. This scheme uses the entropy weight method to transform data distribution characteristics into weights, with indicators exhibiting greater volatility (such as sudden changes in CPU utilization) receiving higher weights. This automatically increases the weights of abnormal indicators, enabling the evaluation model to quickly respond to dynamic changes in the cloud environment.

[0113] In another embodiment, step 201 may include the following steps: calculating the data distribution characteristics of each operating indicator using the entropy weight method to obtain the basic indicator weight; obtaining a predefined industry benchmark weight, which is obtained based on historical evaluation data of similar cloud services; and weighting and fusing the basic indicator weight with the industry benchmark weight to obtain the initial indicator weight.

[0114] This embodiment optimizes data distribution by introducing industry benchmark weights based on data distribution characteristic analysis: First, the weight W1 reflecting real-time data fluctuations is calculated using the entropy weight method. Then, it is dynamically integrated with a preset industry experience weight W2 (e.g., a query latency weight of 0.5 in database services) according to a certain ratio (formula: initial index weight W3 = αW1 + (1-α)W2). Here, α is automatically adjusted based on index stability to balance real-time performance and experience. In this way, the industry benchmark weights can be used as prior knowledge, preventing drastic weight changes due to short-term data fluctuations and improving the robustness of the evaluation results.

[0115] Step 202: Calculate the service node topology influence factor by analyzing the in-degree, traffic weight and fault propagation rate of each service node in the service topology graph.

[0116] Service topology graph: A directed weighted graph representing the call relationships between various components in a cloud service, where: Nodes: service instances (such as microservices, databases), Edges: call dependencies, and weights reflect the probability of traffic or fault propagation.

[0117] Topology Influence Factor: Quantifies the criticality of a node in the topology, based on: In-degree: Nodes called by more services have higher weight; Traffic weight: Edges that transmit large amounts of traffic have a greater impact; Fault propagation rate: Normalized value of the number of times a historical fault has propagated.

[0118] This embodiment analyzes the criticality of service nodes in the overall architecture from multiple dimensions and calculates the topology impact factor:

[0119] Node connection analysis: Count the total number of times each service node is called by other services (in-degree) and the number of times it actively calls other services (out-degree). Perform logarithmic processing on the connection count to avoid excessively large values ​​for a few core nodes. For example, the payment service is called by 8 services and calls 3 services, with an in-degree of 11 and a weight of log(12) = 1.08.

[0120] Traffic weighting assessment: Analyze the actual traffic ratio between nodes and calculate the weighted average of inbound and outbound traffic. For example, 60% of the traffic from the order service flows to the payment service, and 40% flows to the inventory service.

[0121] Fault Impact Assessment: The probability of fault propagation is calculated based on historical operational data, and the latest propagation rate is updated using a sliding window algorithm. For example, the historical probability of a database failure causing payment service outages is 75%.

[0122] Finally, a comprehensive calculation is performed: the three dimensions mentioned above are combined in a preset ratio (such as 4:3:3) to form the final influence factor, ensuring that key nodes in the architecture receive higher weight.

[0123] Step 203: Establish the mapping relationship between operation indicators and service nodes. Among them, infrastructure layer resource indicators are mapped to host nodes, platform layer service indicators are mapped to corresponding service instance nodes, and application layer performance indicators are mapped to microservice nodes.

[0124] This embodiment achieves cross-layer metric association through a three-layer precise mapping: infrastructure layer resource metrics (such as CPU and memory) are bound to host nodes via host agents and CMDB; platform layer service metrics (such as database connection count and message queue latency) are associated with corresponding service instance nodes via the service registry; and application layer performance metrics (such as API response time) are mapped to microservice instances based on distributed tracing data (such as OpenTelemetry Trace). This process ensures that each operational metric can be traced back to a specific service component. For example, 80% of the CPU utilization of a physical server can be allocated to the microservices it hosts according to the container quota ratio, forming a complete monitoring chain from underlying resources to upper-layer business.

[0125] Step 204: Using the initial index weights of each operating index and the topological influence factors of the corresponding mapping nodes, obtain the dynamically adjusted evaluation weights.

[0126] This embodiment dynamically combines the initial index weights with the topology influence factor and calculates the final weights using a weight amplification formula (e.g., W_final=W_initial×(1+λ·T_k)). Here, W_final is the evaluation weight, W_initial is the initial index weight, λ is a configurable amplification coefficient (e.g., 0.2), and T_k is the topology influence factor of the service node.

[0127] For example, the initial CPU weight of the core database node is 0.4, which increases to 0.52 after adding a topology factor of 1.5, while the weight of the edge log service is only slightly adjusted from 0.3 to 0.33. This mechanism ensures that anomalies in critical nodes of the architecture (such as the database on which the payment service depends) have a greater impact on the overall score, while preventing excessive skewness through a weight cap (such as 1.0), so that the evaluation results reflect both real-time data characteristics and the differences in the importance of the system architecture.

[0128] In another embodiment of this application, the method may further include the following steps: determining the type attribute of the target cloud service; determining a weight correction coefficient based on the type attribute; and correcting the evaluation weight based on the weight correction coefficient to obtain the corrected evaluation weight.

[0129] Type attribute: Essential characteristic tags used to classify cloud services, including at least one of the following categories: Infrastructure as a Service, Platform as a Service, or Software as a Service classified by service level; Computing Service, Storage Service, or Network Service classified by business function; Core Business Service or Auxiliary Service classified by criticality level.

[0130] In applications, the type attributes of target cloud services can be automatically identified through multiple dimensions: First, the service level (IaaS / PaaS / SaaS) is determined by parsing the infrastructure orchestration template (such as Terraform) and service mesh configuration; then, the business function is determined based on the indicator feature pattern (such as CPU-intensive, IO-intensive); next, the key level (core / auxiliary) is marked by combining the SLA policy library and call chain analysis, and finally a three-dimensional combined type label (such as "PaaS-level core database service") is generated. The identification process is fully automated and has an accuracy of over 92%, providing accurate type basis for subsequent weight correction.

[0131] Weight adjustment coefficient: Preset adjustment parameters based on service type, for example: Database service: latency indicator weight increase coefficient = 1.5; Batch computing service: CPU weight coefficient = 1.2.

[0132] This embodiment dynamically optimizes weights based on service type: First, it identifies the type attribute of the target cloud service (such as "PaaS-level core database service") based on CMDB tags and business rules. Then, it matches the weight correction coefficient corresponding to the type attribute (such as latency indicator weight × 1.5) from the pre-set rule base. Finally, it multiplies the weight correction coefficient with the evaluation weight to obtain the corrected evaluation weight, so that the core indicators of key service scenarios (such as financial transaction systems) receive higher evaluation weights, ensuring that the quality evaluation results are strictly matched with the business importance.

[0133] This solution addresses the issue of insufficient sensitivity of general evaluation models in specific business scenarios. For example, it increases the query latency weight of database services from 0.5 to 0.75, significantly enhancing the detectability of key anomalies.

[0134] Figure 2 The process shown achieves precision and intelligence in cloud service quality assessment through multi-level dynamic weight calculation: First, initial weights are objectively generated based on data distribution characteristics to avoid human bias; second, the criticality of nodes is quantified through service topology analysis, giving higher weight to core service failures in the assessment; third, a complete monitoring chain from infrastructure to applications is established through cross-level indicator mapping to ensure that problems are traceable; finally, combined with dynamic weight adjustment, the output reflects both real-time data characteristics and architectural importance. Compared with traditional static assessment methods, this significantly improves the accuracy of key anomaly detection and the efficiency of fault location, while also supporting real-time dynamic weight calculation for massive indicators.

[0135] Figure 3 This is a block diagram illustrating an embodiment of a cloud service quality assessment device provided in this application. Figure 3 As shown, the device includes:

[0136] The acquisition module 31 is used to acquire the operation indicator data of each layer of the target cloud service, including the indicator values ​​of infrastructure layer resource indicators, platform layer service indicators and application layer performance indicators.

[0137] Processing module 32 is used to standardize the operational indicator data;

[0138] The calculation module 33 is used to dynamically calculate the evaluation weights based on the data distribution characteristics and service topology diagram of each operating indicator. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operating indicator data, and the service topology diagram is obtained by parsing the inter-service call relationships.

[0139] The generation module 34 is used to generate quality assessment results based on the standardized operational indicator data and the assessment weights.

[0140] Display module 35 is used to display the quality assessment results in the form of multi-dimensional charts.

[0141] In one possible implementation, the computing module is specifically used for:

[0142] The initial indicator weights are obtained based on the data distribution characteristics of each operational indicator;

[0143] By analyzing the in-degree, traffic weight, and fault propagation rate of each service node in the service topology graph, the service node topology influence factor is calculated.

[0144] Establish a mapping relationship between operational metrics and service nodes, where infrastructure layer resource metrics are mapped to host nodes, platform layer service metrics are mapped to corresponding service instance nodes, and application layer performance metrics are mapped to microservice nodes.

[0145] The dynamically adjusted evaluation weights are obtained by using the initial weights of each operational indicator and the topological influence factors of the corresponding mapping nodes.

[0146] In one possible implementation, the computing module is further configured to:

[0147] The weights of the basic indicators are obtained by calculating the data distribution characteristics of each operational indicator using the entropy weight method.

[0148] Obtain predefined industry benchmark weights, which are statistically derived from historical evaluation data of similar cloud services;

[0149] The initial indicator weights are obtained by weighting and fusing the basic indicator weights with the industry benchmark weights.

[0150] In one possible implementation, the computing module is further configured to:

[0151] Determine the type attribute of the target cloud service;

[0152] Determine the weight correction coefficient based on the type attribute;

[0153] The evaluation weights are adjusted according to the weight adjustment coefficients to obtain the adjusted evaluation weights.

[0154] In one possible implementation, the processing module is specifically used for:

[0155] The operational indicator data is subjected to unit standardization processing to obtain initial processed data;

[0156] The abnormal index data in the initial processing data are corrected to obtain intermediate processing data;

[0157] Based on the service tree information in the configuration management database, host-level operation metrics are associated with corresponding microservice instances to establish cross-level metric mapping relationships. The service tree information includes at least the attribution relationships between host nodes, container nodes, and microservice nodes. The association operation includes aggregating all underlying resource metrics that each microservice instance depends on.

[0158] In one possible implementation, the device further includes a first response module for:

[0159] In response to the selection operation of the first target dimension, the associated indicator data corresponding to the first target dimension is retrieved from the pre-established indicator association library. The indicator association library includes at least one of business logic association, technology stack association, and time series association.

[0160] The related indicator data are displayed in the form of auxiliary charts.

[0161] In one possible implementation, the device further includes a second response module for:

[0162] In response to the selection operation of the second objective dimension, the contribution rate of each operational indicator under the second objective dimension is determined;

[0163] The key influencing factors are identified as the operational indicators whose contribution rate is lower than the first preset threshold and whose actual value deviates from the target value by more than the second preset threshold.

[0164] The key influencing factors and corresponding improvement suggestions are presented.

[0165] like Figure 4As shown in the figure, this application provides a device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0166] Memory 113 is used to store computer programs;

[0167] In one embodiment of this application, when the processor 111 executes a program stored in the memory 113, it implements the cloud service quality assessment method provided in any of the foregoing method embodiments, including:

[0168] Obtain operational indicator data for each layer of the target cloud service, including the indicator values ​​for infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators;

[0169] The operational indicator data are standardized.

[0170] The evaluation weights are dynamically calculated based on the data distribution characteristics and service topology diagram of each operational indicator. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operational indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships.

[0171] A quality assessment result is generated based on the standardized operational indicator data and the assessment weights.

[0172] The quality assessment results are presented in the form of multidimensional charts.

[0173] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the cloud service quality assessment method provided in any of the foregoing method embodiments.

[0174] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0175] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0176] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0177] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for evaluating the quality of cloud services, characterized in that, The method includes: Obtain operational indicator data for each layer of the target cloud service, including the indicator values ​​for infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators; The operational indicator data are standardized. The evaluation weights are dynamically calculated based on the data distribution characteristics and service topology diagram of each operational indicator. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operational indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships. A quality assessment result is generated based on the standardized operational indicator data and the assessment weights. The quality assessment results are presented in the form of a multidimensional chart with weighted evaluation.

2. The method according to claim 1, characterized in that, The dynamic calculation of evaluation weights based on the data distribution characteristics and service topology of each operational indicator includes: The initial indicator weights are obtained based on the data distribution characteristics of each operational indicator; By analyzing the in-degree, traffic weight, and fault propagation rate of each service node in the service topology graph, the service node topology influence factor is calculated. Establish a mapping relationship between operational metrics and service nodes, where infrastructure layer resource metrics are mapped to host nodes, platform layer service metrics are mapped to corresponding service instance nodes, and application layer performance metrics are mapped to microservice nodes. The dynamic evaluation weights are obtained by using the initial weights of each operational indicator and the topological influence factors of the corresponding mapping nodes.

3. The method according to claim 2, characterized in that, The process of obtaining initial indicator weights based on the data distribution characteristics of each operational indicator includes: The weights of the basic indicators are obtained by calculating the data distribution characteristics of each operational indicator using the entropy weight method. Obtain predefined industry benchmark weights, which are statistically derived from historical evaluation data of similar cloud services; The initial indicator weights are obtained by weighting and fusing the basic indicator weights with the industry benchmark weights.

4. The method according to claim 2, characterized in that, After obtaining the dynamically adjusted evaluation weights by utilizing the initial indicator weights of each operational indicator and the topological influence factors of the corresponding mapping nodes, the process further includes: Determine the type attribute of the target cloud service; Determine the weight correction coefficient based on the type attribute; The evaluation weights are adjusted according to the weight adjustment coefficients to obtain the adjusted evaluation weights.

5. The method according to claim 1, characterized in that, The standardization process for the operational indicator data includes: The operational indicator data is subjected to unit standardization processing to obtain initial processed data; The abnormal index data in the initial processing data are corrected to obtain intermediate processing data; Based on the service tree information in the configuration management database, host-level operation metrics are associated with corresponding microservice instances to establish cross-level metric mapping relationships. The service tree information includes at least the attribution relationships between host nodes, container nodes, and microservice nodes. The association operation includes aggregating all underlying resource metrics that each microservice instance depends on.

6. The method according to claim 1, characterized in that, Following the presentation of the quality assessment results in the form of multidimensional charts, the following is also included: In response to the selection operation of the first target dimension, the associated indicator data corresponding to the first target dimension is retrieved from the pre-established indicator association library. The indicator association library includes at least one of business logic association, technology stack association, and time series association. The related indicator data are displayed in the form of auxiliary charts.

7. The method according to claim 1, characterized in that, After displaying the quality assessment results in a multidimensional chart format, the method further includes: In response to the selection operation of the second objective dimension, the contribution rate of each operational indicator under the second objective dimension is determined; The key influencing factors are identified as the operational indicators whose contribution rate is lower than the first preset threshold and whose actual value deviates from the target value by more than the second preset threshold. The key influencing factors and corresponding improvement suggestions are presented.

8. A cloud service quality assessment device, characterized in that, The device includes: The acquisition module is used to acquire operational indicator data of each layer of the target cloud service. The operational indicator data includes the indicator values ​​of infrastructure layer resource indicators, platform layer service indicators, and application layer performance indicators. The processing module is used to standardize the operational indicator data; The calculation module is used to dynamically calculate the evaluation weights based on the data distribution characteristics of each operating indicator and the service topology diagram. The data distribution characteristics are obtained by analyzing the statistical characteristics of the operating indicator data, and the service topology diagram is constructed by parsing the inter-service call relationships. The generation module is used to generate quality assessment results based on the standardized operational indicator data and the assessment weights. The display module is used to present the quality assessment results in the form of multi-dimensional charts.

9. A device, characterized in that, include: A processor and a memory, the processor being configured to execute a cloud service quality assessment program stored in the memory to implement the cloud service quality assessment method according to any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the cloud service quality assessment method according to any one of claims 1-7.

Images