Service optimization method, system and device, computer program product and storage medium

Abstract

The embodiment of the invention provides a service optimization method, system and device, a computer program product and a storage medium. A new decision basis is introduced in the service optimization process, namely, the tolerance of clients to various stability problems existing in the cloud computing system. According to the embodiment of the invention, cascade connection between various stability problems existing in the cloud computing system and the tolerance determined in the embodiment can be realized, so that in the process of service optimization for the target customer, the stability of the cloud computing system can be improved on the basis of improving the stability of the cloud computing system, and the service optimization efficiency is improved. The target customer is helped to avoid the concerned stability problem as much as possible in the cloud computing system, so that the influence of the stability problem on the target customer is avoided as much as possible, and the service stability felt by the target customer can be further improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a service optimization method, system, device, computer program product, and storage medium. Background Technology

[0002] In cloud computing systems, a vast number of cloud resources, such as cloud servers, virtual machines, and containers, are running. These cloud resources serve numerous customers, so the service stability experienced by customers is a key indicator for measuring user experience.

[0003] Currently, cloud vendors are focusing on improving the stability of their cloud computing systems in order to provide customers with more stable cloud resources, thereby enhancing the service stability experienced by customers.

[0004] However, due to the massive amount of cloud resources in cloud computing systems, there are bottlenecks in the stability of cloud computing systems. Therefore, even if the stability of the cloud computing system itself has been improved as much as possible, the service stability experienced by customers is still insufficient. Summary of the Invention

[0005] This application provides a service optimization method, system, device, computer program product, and storage medium to improve the stability of services to customers.

[0006] This application provides a service optimization method, including:

[0007] Collect usage data generated during the process of target customers using the cloud computing system;

[0008] Based on the usage data, the tolerance level of the target customer for various stability issues in the cloud computing system is determined, so as to obtain the corresponding processing results for the target customer.

[0009] The processing results are used as a basis for decision-making to optimize services for the target customer in the cloud computing system.

[0010] This application also provides a service optimization system, including: a data collection layer, a data processing layer, and an optimization execution layer;

[0011] The data collection layer is used to collect usage records generated during the target customer's use of the cloud computing system;

[0012] The data processing layer records data based on the usage situation to determine the tolerance of the target customer for various stability issues existing in the cloud computing system, so as to obtain the corresponding processing result for the target customer.

[0013] The optimization execution layer is used to use the processing results as a decision-making basis to optimize services for the target customer in the cloud computing system.

[0014] This application also provides a computing device, including a memory, a processor, and a communication component;

[0015] The memory is used to store one or more computer instructions;

[0016] The processor is coupled to the memory and the communication component to execute one or more computer instructions for performing the aforementioned service optimization method.

[0017] This application also provides a computer-readable storage medium for storing a computer program, which, when executed by one or more processors, causes the one or more processors to perform the aforementioned service optimization method.

[0018] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the aforementioned service optimization method.

[0019] This application provides a service optimization scheme that introduces a new decision-making basis during the service optimization process—the customer's tolerance for various stability issues in the cloud computing system. In this application, usage records related to the target customer's needs during their use of the cloud computing system can be obtained. Based on these usage records, the target customer's tolerance for various stability issues in the cloud computing system is determined. These usage records can directly or indirectly reflect the stability issues that the target customer is concerned about, providing sufficient reference for determining the tolerance process in this application, thus more accurately determining the target customer's tolerance for various stability issues in the cloud computing system. Accordingly, a cascading relationship can be established between various stability issues in the cloud computing system and the tolerance determined in this embodiment. Thus, during service optimization for the target customer, while improving the stability of the cloud computing system itself, it helps the target customer avoid the stability issues they are concerned about as much as possible, thereby minimizing the impact of these stability issues on the target customer and further improving the service stability perceived by the target customer. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 A flowchart illustrating a service optimization method provided for an exemplary embodiment of this application;

[0022] Figure 2 A schematic diagram of the structure of a service optimization system provided for an exemplary embodiment of this application;

[0023] Figure 3 A logical diagram illustrating an optional implementation of a service optimization method provided for an exemplary embodiment of this application;

[0024] Figure 4 A logical diagram illustrating an optional implementation of a service optimization method provided for an exemplary embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this application, the following is a brief explanation of several technical concepts involved in this application.

[0028] Cloud computing systems can be understood as a computing model that utilizes the internet to enable convenient, on-demand access to shared computing facilities and storage devices, among other cloud resources, anytime, anywhere. Cloud computing systems are built by cloud vendors and offer a rich variety of cloud resources.

[0029] Cloud resources are a service model based on cloud computing, characterized by resource virtualization, dynamic allocation, and elastic scaling. Cloud resources have a wide range of applications and are suitable for various types of customers. For example, enterprises can use cloud resources in cloud computing systems to build websites and applications, and can also enjoy various cloud computing services provided by cloud service providers through cloud resources. Typical cloud resources include, but are not limited to, Elastic Cloud Servers (ECS), Virtual Machines (VMs), and containers, etc., which will not be further exemplified here.

[0030] As mentioned in the background section, cloud resources in cloud computing systems serve numerous customers. These customers use cloud resources to deploy their required work systems, such as applications and cloud computing services. Therefore, the service stability perceived by customers is a key indicator of user experience. Poor service stability will lead to a poor user experience. Currently, cloud vendors focus on improving the stability of the cloud computing system itself in order to provide customers with more stable cloud resources. For example, cloud vendors hope to reduce the downtime rate and frequency of downtime in the cloud computing system to improve the stability of cloud resources. However, due to the massive amount of cloud resources in the cloud computing system, there are bottlenecks in the stability of the cloud computing system itself. Therefore, even if the stability of the cloud computing system itself has been improved as much as possible, the service stability perceived by customers is still insufficient.

[0031] Therefore, this application proposes a service optimization scheme: introducing a new decision-making criterion during the service optimization process—the customer's tolerance for various stability issues in the cloud computing system—in order to improve the service stability perceived by the customer.

[0032] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0033] Figure 1 This is a flowchart illustrating a service optimization method provided for an exemplary embodiment of this application. Figure 2 This is a schematic diagram of the structure of a service optimization system provided for an exemplary embodiment of this application. (Reference) Figure 2 This method can be executed by a service optimization system. This service optimization system can be implemented as software, hardware, or a combination of both. It can be integrated into a computing device, which can be a single physical server or a server cluster; no specific limitation is made here. (Reference) Figure 1 The method may include:

[0034] Step 100: Collect usage data recorded by target customers during their use of the cloud computing system;

[0035] Step 101: Based on usage data, determine the tolerance of target customers for various stability issues in the cloud computing system in order to obtain the corresponding processing results for the target customers;

[0036] Step 102: Use the processing result as a basis for decision-making and optimize services for target customers in the cloud computing system.

[0037] This embodiment proposes categorizing stability issues in cloud computing systems. This embodiment does not limit the categorization angle or the names of the categorized types; in practical applications, it can be flexibly designed according to needs. Categorizing stability issues not only effectively reduces the number of processing steps required in this embodiment and lowers the computational load, but also ensures that the processing results more comprehensively cover the stability issues in the cloud computing system. By categorizing stability issues, specific stability problems can be identified, thereby providing a better basis for decision-making in the service optimization process.

[0038] For example, in this embodiment, the types of stability problems categorized may include downtime problems, operational and maintenance problems, and performance problems, and may also include CPU problems, memory problems, and network problems. No further examples are provided here to limit the types of stability problems.

[0039] Based on this, the technical concept of this embodiment proposes to determine the customer's tolerance for various stability issues existing in the cloud computing system. Here, tolerance can be understood as the degree to which the customer tolerates the impact of a certain type of stability issue on their working system when such an issue occurs in the cloud computing system.

[0040] In this embodiment, from the customer's perspective, the same customer may have different tolerances for different types of stability problems in the cloud computing system. From the perspective of a single type of stability problem, the impact of the same type of stability problem on different customers may be different.

[0041] Understandably, the lower a customer's tolerance for a certain type of stability issue, the greater the impact of that issue on the customer. In other words, the tolerance level in this embodiment reflects the scaling factor of the impact that a certain type of stability issue might be perceived by the customer. The lower the tolerance, the more amplified the impact will be in the customer's perception, and the lower the perceived service stability will be for the target customer.

[0042] Therefore, in this embodiment, it is proposed to determine the customer's tolerance for various stability issues in the cloud computing system. This can effectively perceive which type of stability issues the customer is more concerned about in the cloud computing system. Thus, the customer's feelings can be fully considered during the service optimization process, and the customer can be helped to avoid the stability issues they are concerned about as much as possible.

[0043] For ease of description, this embodiment will explain the technical solution from the perspective of the target customer. It should be understood that the target customer in this embodiment can refer to any customer using the cloud computing system. In other words, in this embodiment, the tolerance level for various stability issues existing in the cloud computing system can be determined for each customer using the cloud computing system, serving as a basis for service optimization decisions.

[0044] Based on the above technical concept, and referring to Figure 1 In step 100, usage records generated by the target customer during the use of the cloud computing system can be collected.

[0045] During their research, the inventors discovered that a wealth of usage data is generated when target customers use cloud computing systems. This usage data may arise from stability issues or changes in customer needs. It may be submitted voluntarily by target customers or annotated by cloud vendors or service providers' staff. This usage data contains a wealth of information, characterizing target customers' needs for cloud computing systems from multiple dimensions and directly or indirectly reflecting their tolerance for various stability issues.

[0046] refer to Figure 2 In this embodiment, a data collection layer can be set up in the service optimization system. Through the data collection layer, the data query interface provided by various data sources already deployed in the cloud computing system can be called to obtain the usage record data required in step 100 from these data sources.

[0047] In this embodiment, the data sources to be invoked can be set as needed in the data collection layer, and interface parameters such as the data fields to be obtained from different data sources can also be set as needed. Furthermore, this embodiment also supports modifying these settings in the data collection layer at any time to adjust the usage record data collected in step 100 as needed. For example, data sources can be added or deleted at any time, and data fields in the usage record data can be added or deleted at any time; further details are omitted here.

[0048] Therefore, in step 100 of this embodiment, a wealth of usage record data can be collected. This usage record data can provide a rich reference for the process of determining tolerance in this embodiment.

[0049] Continue to refer to Figure 1 In step 101, it is proposed that the tolerance for various stability issues in the cloud computing system can be determined for the target customer based on the collected usage data, so as to obtain the corresponding processing results for the target customer.

[0050] It is understood that the processing results obtained in step 101 can intuitively describe the target customer's tolerance for various stability issues in the cloud computing system. In this embodiment, the format for recording tolerance in the processing results is not limited. Optionally, the processing results may include the target customer's tolerance for each type of stability issue in the cloud computing system. Optionally, stability issue types with relatively high tolerance may not need to be included in the processing results. Regardless of the recording format, it can describe the target customer's tolerance for various stability issues in the cloud computing system; this embodiment does not provide further examples of recording formats.

[0051] refer to Figure 2 In this embodiment, a data processing layer can be set up in the service optimization system. Through the data processing layer, the usage record data can be analyzed, thereby determining the tolerance of target customers for various stability issues existing in the cloud computing system.

[0052] It is worth noting that, as mentioned earlier, the usage record data collected in step 100 of this embodiment contains a wealth of information. This information can indirectly or directly reflect the target customer's tolerance for various stability issues. Therefore, various implementation methods can be used to perceive the target customer's tolerance for various stability issues and quantify it to obtain the tolerance level in step 101. This embodiment does not limit the implementation method used to determine the tolerance level in step 101. When sufficient data has been collected and the quantification dimension (i.e., tolerance level) has been clearly defined, various implementation methods can complete the tolerance level determination operation in step 101. However, the accuracy of the determined tolerance level or the processing efficiency in the process may differ, but these differences do not affect the implementation of the technical concept in this application, nor do they affect the technical problems mentioned in the background art that this application solves.

[0053] The implementation methods that can be used in step 101 will not be described in detail here, but several optional implementation methods will be provided in subsequent embodiments.

[0054] At this point, for reference Figure 2 In step 101, a processing result can be generated for the target customer.

[0055] Furthermore, in this embodiment, the processing results corresponding to the target customer can be updated as needed. This further ensures the accuracy of the processing results for the target customer. To this end, in this embodiment, a timed mechanism or an active triggering mechanism can be used to control the execution timing of the aforementioned steps 100 and 101. Taking the timed mechanism as an example, in this embodiment, steps 100 and 101 can be automatically executed according to a timed cycle. In step 100, usage records generated in the recent period can be collected for the target customer to better reflect the target customer's recent usage needs. In this way, the processing results obtained in step 101 can better reflect the target customer's recent tolerance for various stability issues in the cloud computing system, and changes in the target customer's tolerance can be detected in a timely manner, thereby improving the accuracy of the processing results.

[0056] Here, the triggering method and execution time of steps 100 and 101 in this embodiment are not limited.

[0057] Continue to refer to Figure 1 In step 102, it is proposed that the processing results obtained in step 101 can be used as a basis for decision-making to optimize services for target customers in the cloud computing system.

[0058] As mentioned above, the processing results obtained in step 101 can reflect which type of stability issues the target customer is less tolerant of in the cloud computing system and how low their tolerance is. This can provide a new basis for decision-making in the service optimization process.

[0059] During their research, the inventors discovered that service optimization can encompass multiple dimensions, including resource allocation optimization and operation and maintenance strategy optimization. Based on the processing results obtained in step 101, in step 102, the processing results corresponding to the target customer can be used as the decision-making basis in the resource allocation optimization process, thereby enabling more reasonable allocation of cloud resources for the target customer. Furthermore, it can also be used as the decision-making basis in the operation and maintenance strategy optimization process, thereby enabling more reasonable operation and maintenance arrangements for the cloud resources used by the target customer.

[0060] The following are some service optimization operations that incorporate processing results as a basis for decision-making, to demonstrate the effect of improving service stability.

[0061] Service optimization operation 1

[0062] If the processing results indicate that the target customer has a high tolerance for performance issues, then when optimizing their operation and maintenance strategies, cloud vendors can schedule the deployment of various cloud service functions that might preempt cloud resources used by the target customer (a typical operation and maintenance scenario) during the target customer's off-peak workload periods. This helps the target customer avoid performance issues caused by these cloud service deployments. Since the target customer has less workload during off-peak periods, other workloads will not be affected, resulting in better service stability perceived by the target customer.

[0063] Service optimization operation 2

[0064] If the processing results indicate that the target customer has a high tolerance for downtime issues, then when optimizing resource allocation, cloud providers can distribute the Elastic Compute Service (ECS) required by the target customer across more physical servers, avoiding concentrating all ECS instances on a single physical server. This way, if one physical server experiences a downtime, fewer ECS instances will be affected for the target customer, and other ECS instances used by the target customer will remain unaffected. Consequently, the target customer will experience better service stability.

[0065] Service optimization operation 3

[0066] If the processing results indicate that the target customer has a high tolerance for performance issues, then when optimizing resource allocation, cloud providers can avoid deploying ECS ​​instances from other customers that frequently compete for physical resources on the physical servers where the target customer's Elastic Compute Service (ECS) is located. This ensures that the target customer's ECS instances can utilize sufficient physical resources, thereby guaranteeing more stable performance and resulting in better service stability for the target customer.

[0067] It should be understood that the above-described service optimization operations are exemplary and this embodiment is not limited thereto. Based on the aforementioned processing results constructed for the target customer in this embodiment, decision rules in the service optimization operations can be flexibly designed to fully utilize the processing results provided in this embodiment, thereby providing more refined assistance to the target customer in service optimization.

[0068] Here, no further examples will be given of service optimization operations performed based on the processing results provided in this embodiment.

[0069] In summary, this embodiment provides a service optimization scheme that introduces a new decision-making basis during the service optimization process—the customer's tolerance for various stability issues in the cloud computing system. In this embodiment, usage records related to the target customer's needs during their use of the cloud computing system can be obtained. Based on these usage records, the target customer's tolerance for various stability issues in the cloud computing system is determined. These usage records can directly or indirectly reflect the stability issues that the target customer is concerned about, providing sufficient reference for determining the tolerance process in this embodiment, thus more accurately determining the target customer's tolerance for various stability issues in the cloud computing system. Accordingly, a cascading mechanism can be established between various stability issues in the cloud computing system and the tolerance determined in this embodiment. Thus, during service optimization for the target customer, while improving the stability of the cloud computing system itself, it helps the target customer avoid the stability issues they are concerned about as much as possible, thereby minimizing the impact of these stability issues on the target customer and further improving the service stability perceived by the target customer.

[0070] In the above or following embodiments, based on usage data collected for the target customer, various implementation methods can be used to determine the target customer's tolerance for various stability issues existing in the cloud computing system. One optional implementation method is provided below.

[0071] In this optional implementation, it is proposed that: the usage record data can contain multiple data groups from different data sources, and the types of stability issues that different data groups are concerned with may not be exactly the same. Based on this, the tolerance level corresponding to the type of stability issue of concern can be determined for the target customer under each of the multiple data groups to obtain the tolerance description information corresponding to each of the multiple data groups; the tolerance description information corresponding to each of the multiple data groups is merged to obtain the target customer's tolerance for various stability issues existing in the cloud computing system.

[0072] Figure 3 This is a logical diagram illustrating an optional implementation of a service optimization method provided for an exemplary embodiment of this application. (Reference) Figure 3 The data sources involved in the usage record may include, but are not limited to: critical protection systems, customer relationship systems, lossy change risk avoidance systems, hot migration control systems, work order systems, operating system error event labeling systems, and proactive maintenance event labeling systems. No further examples of data sources will be provided here.

[0073] Different data sources record the target customers' usage of the cloud computing system from different usage needs. Therefore, the data groups corresponding to different data sources will reflect the target customers' tolerance for stability issues from different usage needs.

[0074] refer to Figure 3 In this optional implementation, the data collection layer of the service optimization system can collect usage record data from different data sources to form multiple data groups. Correspondingly, the data processing layer of the service optimization system can group the usage record data, allowing for independent data analysis within each data group. This enables a more comprehensive understanding of target customer feedback regarding each usage need.

[0075] Furthermore, the inventors discovered during their research that usage records collected from data sources are typically not customer-centric, but rather a mix of records from multiple customers. Therefore, in this optional implementation, a data preprocessing unit can be set up within the data processing layer of the service optimization system. This data preprocessing unit can organize the usage data collected from each data source in the data collection layer into customer-centric data. This allows for the creation of data groups corresponding to different customers under each data source. From the perspective of the target customer, the data preprocessing unit's organization operation according to the customer dimension yields multiple data groups corresponding to the target customer.

[0076] It is worth emphasizing that the data preprocessing unit can also perform other preprocessing operations on usage request data collected from different data sources, including but not limited to filtering and structuring, etc., which are not limited here and no further examples will be given. In practical applications, the preprocessing operations to be performed for different data sources can be set as needed, and the preprocessing operations set for different data sources can be different.

[0077] In this optional implementation, the types of stability issues to be concerned with for different data groups can not be exactly the same. This is mainly because the usage requirements involved in the usage record data provided by different data sources are different, and the stability issues involved in different usage requirements are not exactly the same. Therefore, in this optional implementation, the types of stability issues to be concerned with for different data groups can not be exactly the same. For a data group, the types of stability issues to be concerned with can be all or some of the stability issues that exist in the cloud computing system.

[0078] Here, the types of stability issues that different data groups are concerned with can be set according to actual needs. The types of stability issues that different data groups are concerned with may not be exactly the same. No specific limitation is made here, but will be illustrated in the following text.

[0079] Furthermore, in this optional implementation, it is proposed that: based on the mapping relationship between the data source and the processing logic, the processing logic to be followed can be determined for each of the multiple data groups, and the processing logic indicates the type of stability problem of concern; for any one of the multiple data groups, in accordance with the determined processing logic, the corresponding tolerance for the type of stability problem of concern can be determined for the target customer.

[0080] In other words, in this optional implementation, different processing logic can be set for different data groups to adapt to their data characteristics. The processing logic can be understood as the process flow for determining tolerance levels. This processing logic can be pre-defined in the service optimization system, as shown in the reference... Figure 3 A group processing unit can be set up in the data processing layer. The group processing unit can select the processing logic to be followed for each data group corresponding to the target customer, and determine the corresponding tolerance for the stability problem type of the data group that the target customer is concerned about based on the selected processing logic.

[0081] It is worth emphasizing that after determining the tolerance for each data group, a tolerance is obtained; however, this tolerance is not the same as the tolerance within the processing result of step 101. In this optional implementation, tolerance description information can be generated for each data group, which includes the tolerance obtained for each data group. Based on this, the tolerance description information corresponding to multiple data groups can be merged to obtain the target customer's tolerance for various stability issues in the cloud computing system. Figure 3 Examples of various stability issues existing in cloud computing systems are listed as stability issue types 1, 2, ..., n. The tolerance obtained here is the tolerance within the processing result of step 101.

[0082] refer to Figure 3 A merging unit can be set up in the data processing layer. The aforementioned grouping processing unit can provide the tolerance description information corresponding to each of the multiple data groups to the merging unit. The merging unit can then merge these tolerance description information to obtain the target customer's tolerance for various stability issues in the cloud computing system.

[0083] By merging operations, feedback from target customers under different usage needs can be summarized and analyzed, thereby more accurately determining the tolerance of target customers for each type of stability issue in the cloud computing system.

[0084] In summary, this embodiment proposes a processing mechanism that groups and then merges usage data. This mechanism better adapts to the characteristics of data from different data sources and independently analyzes the feedback from target customers regarding their varying usage needs. Furthermore, the tolerance determination operations for different data groups can be performed in parallel, effectively ensuring processing efficiency. The final merging operation fully considers the feedback from target customers regarding their different usage needs, thereby more reasonably determining the tolerance for various stability issues in the cloud computing system for target customers, improving the rationality and accuracy of the processing results.

[0085] It is worth noting that the above implementation method is only optional. Other implementation methods can also be used to determine the tolerance of target customers for various stability issues existing in the cloud computing system. For example, usage records collected for target customers can be input into a large language model. With the help of the data analysis capabilities of the large language model, the tolerance of target customers for various stability issues can be perceived and quantified as tolerance levels. Other implementation methods will not be elaborated on here, nor will more examples of implementation methods be provided.

[0086] In the above or below embodiments, as mentioned above, for any one of the multiple data groups corresponding to the target customer, the tolerance level corresponding to the type of stability problem of concern can be determined for the target customer in accordance with the determined processing logic.

[0087] Figure 4 This is a logical diagram illustrating an optional implementation of a service optimization method provided as an exemplary embodiment of this application. The following is in conjunction with... Figure 4 For several exemplary data sources, an exemplary scheme is described for executing processing logic under any data group corresponding to the target customer.

[0088] refer to Figure 4 The service optimization system provided in this embodiment can initiate quantization for different data sources. After quantization is initiated, the corresponding data can be retrieved from the data source and the data group can be sorted out.

[0089] critical protection system

[0090] If the data source corresponding to the data group is a critical security system, then according to the key fields indicated in the corresponding processing logic, based on the field values ​​of each critical security task record in the data group under the key fields, the tolerance corresponding to any target stability problem type indicated for concern in the processing logic can be determined for each critical security task record. For any target stability problem type of concern in the processing logic, the tolerance distribution can be statistically analyzed based on the tolerance corresponding to each critical security task record under the target stability problem type. Based on the tolerance distribution, the corresponding tolerance for the target customer under the target stability problem type can be determined. The target stability problem types indicated for concern in the processing logic can be one or more; in the case of multiple types, the tolerance corresponding to each target customer under multiple target stability problem types can be determined in this way.

[0091] The critical protection system can be understood as a network security guarantee service provided by cloud vendors during major events or holidays. The critical protection system aims to ensure the stable operation of customers' work systems during critical periods, preventing security incidents such as network attacks, virus infections, and network failures. Customers can apply to become critical protection customers. The critical protection system records the identity identifier of critical protection customers, the types of critical protection packages they have applied for, and the critical protection tasks they have submitted. Based on this, this embodiment proposes that this useful data (i.e., ...) can be queried from the critical protection system periodically. Figure 4 The information shown in the document includes key protection tasks, customer and package information, etc., as mentioned above. Figure 3 The data preprocessing unit shown can filter out critical protection tasks under critical protection package types that have been completed and have low reference value, such as "assistance tasks" and "critical event maintenance". Of course, other preprocessing can also be performed. After that, critical protection tasks can be aggregated according to customer dimensions, thereby organizing the data groups of target customers under the critical protection system as a data source.

[0092] It's worth mentioning that a customer can apply to become a critical insurance customer multiple times, and the type of critical insurance package selected each time can be different. During their time as a critical insurance customer, the customer can submit multiple critical insurance tasks. Within the data group organized for the target customer under the critical insurance system data source, there can be records of each critical insurance task corresponding to the target customer, and these critical insurance task records are all associated with the critical insurance package type.

[0093] Based on this, in this embodiment, the package type field can be used as the required key field in the processing logic corresponding to the critical protection system as the data source; and attention should be paid to all types of stability problems existing in the cloud computing system. Thus, in this embodiment, for any critical protection task record in the data group, the target critical protection package type recorded under the package type field can be queried; from the tolerance mapping relationship indicated in the processing logic, the tolerance mapped to the target critical protection package type under each target stability problem type can be queried, which is used as the tolerance corresponding to the critical protection task record under each target stability problem type.

[0094] The aforementioned tolerance mapping relationship can be preset in the processing logic. This tolerance mapping relationship sets the corresponding tolerance for each type of critical protection package under each type of stability issue of concern. Taking the stability issue types categorized in cloud computing systems, including downtime issues, operation and maintenance issues, and performance issues, as an example, and taking a critical protection package type, "Advanced Customized Package," as an example, the tolerance mapping state for this critical protection package type can be:

[0095] Types of critical insurance packages Downtime Issues - Tolerance Operations and maintenance issues - tolerance Performance issues - tolerance Premium Customized Packages Low high uncertain

[0096] In this way, for each critical protection task record contained in the data set, the tolerance under each type of stability problem of the target of interest can be obtained. That is, the tolerance is determined from the dimension of critical protection task records.

[0097] Switching to the stability issue type dimension allows you to statistically analyze the tolerance distribution for each target stability issue type that is of interest in this processing logic.

[0098] Optionally, tolerance levels can be used to represent tolerance. Here, there is no limitation on the number of tolerance levels or the representation method. For example, as shown in the tolerance mapping relationship above, tolerance can be divided into two tolerance levels: high and low. A special tolerance level, "uncertain," can also be defined. Of course, besides using level names to represent tolerance levels, other representation methods can be used. For example, numerical ranges can be used; for instance, tolerance can be divided into two tolerance levels: [100, 50] and [49, 1]. No further examples are provided here.

[0099] One approach to statistically analyzing the tolerance distribution is to: for any type of target stability problem of interest in the processing logic, count the number of critical protection task records at different tolerance levels to obtain the tolerance distribution corresponding to that type of target stability problem.

[0100] Following the example of the tolerance mapping relationship above, for the target stability problem type of "downtime problem," we can count the number of critical protection task records with a "high" tolerance and the number of critical protection task records with a "low" tolerance. In this way, we can obtain the tolerance distribution under the "downtime problem."

[0101] The processing logic can also indicate the quantitative relationship from the tolerance distribution to the tolerance level, that is, what kind of tolerance distribution should be quantified into what kind of tolerance level. This quantitative relationship can be flexibly designed according to actual needs. Here is an example of a quantitative relationship: if there is only one tolerance level with a non-zero number of critical protection task records, then that tolerance level is determined as the tolerance level corresponding to the target customer under the target stability problem type.

[0102] Based on this, for any target stability issue type indicated as a concern in the processing logic, the tolerance level corresponding to that target stability issue type can be determined for the target customer based on the number of critical protection task records under different tolerance levels. An exemplary judgment rule could be: if only one tolerance level has a non-zero number of critical protection task records, then that tolerance level is determined as the target customer's tolerance level for that target stability issue type; otherwise, the target customer's tolerance level for that target stability issue type can be configured as uncertain.

[0103] Continuing the previous example, if the number of critical protection task records with a tolerance level of "high" under the "downtime problem" is non-zero, while the number of critical protection task records with a tolerance level of "low" under the "downtime problem" is zero, then the tolerance of the target customer under the "downtime problem" for this data group can be determined as "high". In special cases, if the number of critical protection task records with tolerance levels of "high" and "low" under the "downtime problem" are both non-zero or both are zero, then the tolerance of the target customer under the "downtime problem" for this data group can be determined as "uncertain".

[0104] It should be understood that the above-mentioned quantitative relationship is only exemplary, and this embodiment is not limited thereto. It can be flexibly set and adjusted according to the actual situation, and no further examples will be given here.

[0105] In summary, under the data group corresponding to the critical protection system as the data source, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0106] Furthermore, under the data group corresponding to the critical protection system as the data source, the following is also proposed:

[0107] The system can deduplicate the types of critical insurance packages contained in the data group; use the remaining critical insurance package types as the tolerance reasons for the target customers; and associate the tolerance reasons and the identification information of the data source corresponding to the data group with the tolerance description information corresponding to the data group.

[0108] The tolerance reason can be used to characterize why a customer has a tolerance level for a certain type of stability issue recorded in the processing results of this embodiment. Here, the customer's tolerance level for a certain type of stability issue is due to their subscription to a certain type of critical protection package. The data source indicates which data source provided the usage data records based on the tolerance level, reflecting the origin of the tolerance reason. Linking the tolerance reason and data source to the tolerance description information can provide more decision-making basis during subsequent service optimization. This allows service optimization to fully consider the specific tolerance reasons of the target customer, and the usage needs dimension from which the tolerance reason originates. This enables more targeted efforts to help the target customer avoid the stability issues they are concerned about by avoiding the tolerance reason, resulting in better service optimization effects.

[0109] Customer relationship system

[0110] If the data source corresponding to the data group is the customer relations system, then according to the key fields indicated in the corresponding processing logic and the target stability problem type of concern, each customer relations record in the data group is classified according to the field values ​​under the key fields to obtain the target stability problem type to which each customer relations record is classified; for any target stability problem type of concern in the processing logic, the corresponding tolerance level for the target customer is determined according to the number of customer relations records classified under the target stability problem type.

[0111] The customer relationship management (CRM) system is a system used by cloud vendors to manage customer information. When customers encounter various faults or usage problems, they can report them to the CRM system. Relevant personnel from the cloud vendor or cloud service provider can then handle these issues based on the reported information, including maintenance and other measures, to help customers resolve problems. All these steps are recorded as visible data in the CRM system. In this embodiment, relevant data can be collected from the CRM system and organized into a customer-centric data group. This data group may contain customer relationship records, some of which contain fields that reflect tolerance for stability issues. These fields are designated as key fields in the processing logic.

[0112] Based on this, customer relationship records within the data group can be categorized according to the field values ​​under the key fields, so as to classify the customer relationship records under the target stability problem type that the processing logic is concerned with.

[0113] Optionally, in this embodiment, the complaint reason field can be used as the required key field in the processing logic corresponding to the customer relations system data source; and all stability problem types existing in the cloud computing system can be monitored. Thus, in this embodiment, for any customer relations record in the data group, the target complaint reason recorded under the complaint reason field can be determined; based on the classification relationship between the complaint reason and the stability problem type indicated in the processing logic, the customer relations record can be classified under the stability problem type associated with the target complaint reason, thereby completing the classification operation of the customer relations record.

[0114] The processing logic pre-defines the categorization relationship between complaint reasons and stability problem types; that is, it specifies which complaint reason can be categorized under which stability problem type. For example, the processing logic can classify complaint reasons such as "too many disk errors," "too frequent downtime," and "local disk maintenance" under the stability problem type of "downtime issues." It should be understood that these complaint reasons and categorization relationships are exemplary, and this embodiment is not limited to them.

[0115] In this way, the target stability problem type can be determined for each customer relationship record within the data set. A customer relationship record can be classified into one or more target stability problem types, which is not limited here.

[0116] Based on the classification results, the process can be further transformed into a tolerance determination operation under the stability problem type. Within the data group corresponding to the customer relations system data source, tolerance levels can also be used to characterize tolerance. Therefore, an exemplary tolerance determination operation could be: for any target stability problem type of interest in this processing logic, the corresponding tolerance level for the target customer under the target stability problem type can be determined based on the number of customer relations records classified under that target stability problem type.

[0117] An exemplary judgment rule could be: if the number of customer relationship records categorized under a target stability issue type is non-zero, then the minimum tolerance level can be determined as the target customer's tolerance level under that target stability issue type. In other words, in this exemplary tolerance determination operation, if there are customer relationship records under a certain target stability issue type, then the tolerance level under that target stability issue type can be determined as the minimum tolerance level, such as "low" in the previous example. This is mainly because if a customer has filed a complaint, it indicates that their tolerance for the relevant stability issue is very low, which deserves attention during service optimization. Optionally, if the number of customer relationship records categorized under that target stability issue type is zero, then the target customer's tolerance level under that target stability issue type in that data group can be set to "uncertain" or "high," etc., without limitation.

[0118] In this way, under the data group corresponding to the customer relationship system data source, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0119] Furthermore, under the data group corresponding to the customer relationship system as the data source, the following is also proposed:

[0120] The system can deduplicate the complaint reasons contained in the data group; use the remaining complaint reasons as the tolerance reasons corresponding to the target customer; and associate the tolerance reasons and the identification information of the data source corresponding to the data group with the tolerance description information corresponding to the data group.

[0121] Linking tolerance descriptions to tolerance reasons and data sources provides more decision-making basis for subsequent service optimization. This allows service optimization to fully consider the specific tolerance reasons of target customers and the usage needs dimensions from which these reasons originate. Consequently, it enables more targeted efforts to help target customers avoid the stability issues they are concerned about by avoiding those tolerance reasons, resulting in better service optimization effects.

[0122] Detrimental Change Risk Avoidance System

[0123] If the data source corresponding to the data group is a lossy change risk avoidance system, then based on whether there are lossy change risk avoidance records in the data group corresponding to the target customer, the tolerance level corresponding to the target stability problem type that is of concern in the processing logic can be determined for the target customer.

[0124] A lossy change can be understood as a change operation that results in a loss of cloud resource performance. For example, some changes may lead to increased network latency or packet loss, which are considered lossy changes. A lossy change risk avoidance system is used to record customer complaints about lossy changes. When a lossy change affects a customer's workload, the customer will file a complaint with the lossy change risk avoidance system. Therefore, the system typically records a list of customers who have filed complaints about lossy changes, and it usually also records the off-peak periods authorized by the customer. These off-peak periods represent the customer's low workload and can provide a reference for the timing of implementing lossy changes.

[0125] Having understood the data source of the lossy change risk aversion system, it's comprehensible that the existence of lossy change risk aversion records corresponding to the target customer within this data set indicates that the target customer has previously filed a complaint regarding lossy changes. Therefore, this suggests that the target customer has a relatively low tolerance for various stability issues caused by lossy changes (i.e., the target stability issue types of concern in the processing logic). Consequently, the processing logic instructs that in this case, the target customer's tolerance level for the relevant target stability issue types can be set to a specified degree to indicate that the target customer has a relatively low tolerance for these types of issues.

[0126] Based on this, an exemplary judgment rule could be: if there are records of risk avoidance of loss-making changes corresponding to the target customer in the data group, the tolerance of the target customer under the target stability problem type that the processing logic focuses on can be set to a specified level, so as to characterize that the target customer has a relatively low tolerance under the target stability problem type that is of concern.

[0127] Optionally, following the previous point, a tolerance level can be used to represent tolerance. Based on this, the specified level here can be the lowest tolerance level, indicating that the target customer has a relatively low tolerance for the type of stability issues related to the target object. Of course, other tolerance levels can also be set; there are no restrictions here, as long as they can indicate that the target customer has a relatively low tolerance for the type of stability issues related to the target object.

[0128] In this exemplary judgment rule, it is also proposed that if there is no record of risk avoidance of lossful changes corresponding to the target customer in the data group, it means that the target customer may not have filed a complaint about lossful changes. In this case, the tolerance level of the target customer under the type of target stability problem of concern can be set to the highest tolerance level, or set to uncertain, or other tolerance levels, to indicate that the target customer has a relatively high tolerance level under the type of target stability problem of concern.

[0129] Optionally, within the data group corresponding to the data source "lossy change risk avoidance system," the target stability issue type can be set to a performance-related issue type, such as the "performance issue" mentioned earlier. This is mainly because customer complaints are usually due to perceived abnormal fluctuations in the performance of cloud resources; therefore, performance-related issue types can be the primary focus under this data source.

[0130] In this way, under the data group corresponding to the data source of the lossy change risk avoidance system, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0131] Furthermore, under the data group corresponding to the data source of the lossy change risk avoidance system, the following is also proposed:

[0132] If a data group contains records of lossy change risk aversion corresponding to the target customer, the target preset parameters are used as the tolerance reason for the target customer. These preset parameters characterize the target customer as a customer who averts lossy change risk. The tolerance reason and the identification information of the data source corresponding to the data group are then associated with the tolerance description information corresponding to that data group. In other words, the customer attribute of lossy change risk aversion can be used as the tolerance reason for the target customer.

[0133] In addition, the aforementioned off-peak window information can also be associated with the tolerance description information corresponding to the array. In the subsequent service optimization process, the off-peak window authorized by the target customer can be fully considered, and unavoidable stability issues can be controlled within the off-peak window as much as possible, thereby minimizing the impact of stability issues on the target customer.

[0134] Thermal migration control system

[0135] If the data source corresponding to the data group is a hot migration control system, then based on whether there is a hot migration control record in the data group corresponding to the target customer, the tolerance for the target customer under the type of target stability problem that is of concern in the processing logic can be determined.

[0136] Live migration, also known as dynamic migration or real-time migration, is a technology that migrates running cloud resources, such as virtual machines, from one physical server to another without interrupting service. There are many reasons why live migration is necessary, such as physical server downtime, which will not be discussed further here.

[0137] A live migration control system can be used to record control information related to live migration. In this embodiment, the system serves as a data source, from which a list of customers whose services have been impaired or who are prohibited from live migration due to live migration can be collected and organized into customer-level data groups. Thus, if a target customer is on the collected customer list, the data group organized for that target customer will contain live migration control records. These records may include customer identification and the reason for the control record.

[0138] Having understood the live migration control system as a data source, it's comprehensible that the existence of live migration control records corresponding to the target customer within this data set indicates that the target customer is relatively resistant to live migration. Therefore, this suggests a low tolerance for various stability issues caused by live migration (i.e., the target stability issue types of concern in the processing logic). Consequently, the processing logic instructs that in this case, the target customer's tolerance for the relevant target stability issue types can be set to a specified level to represent a low tolerance for those issues.

[0139] Based on this, an exemplary judgment rule could be: if there is a hot migration control record corresponding to the target customer in the data group, the tolerance of the target customer under the target stability problem type of concern in the processing logic can be set to a specified level to characterize that the target customer has a relatively low tolerance under the target stability problem type of concern.

[0140] Optionally, following the previous point, a tolerance level can be used to represent tolerance. Based on this, the specified level here can be the lowest tolerance level, indicating that the target customer has a relatively low tolerance for the type of stability issues related to the target object. Of course, other tolerance levels can also be set; there are no restrictions here, as long as they can indicate that the target customer has a relatively low tolerance for the type of stability issues related to the target object.

[0141] In this exemplary judgment rule, it is also proposed that if there is no hot migration control record corresponding to the target customer in the data group, it means that the target customer may not be resistant to hot migration. In this case, the tolerance level of the target customer under the type of target stability problem of concern can be set to the highest tolerance level, or set to uncertain, or other tolerance levels, to characterize that the target customer has a relatively high tolerance level under the type of target stability problem of concern.

[0142] Optionally, under the data group corresponding to the hot migration management system data source, the type of stability issue of interest can be set to a performance-related issue type, such as the "performance issue" mentioned above. This is mainly because customers resist hot migration because they perceive abnormal fluctuations in the performance of cloud resources. Therefore, under this data source, performance-related issue types can be the primary focus.

[0143] In this way, under the data group corresponding to the data source of the thermal migration control system, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0144] Furthermore, under the data group corresponding to the data source of the thermal migration control system, the following is also proposed:

[0145] If a hot migration control record corresponding to a target customer exists in the data group, the reason for the occurrence of the control record contained in the hot migration control record is used as the tolerance reason corresponding to the target customer; the tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group; wherein, the reason for the occurrence of the control record includes one or more reasons, such as when the customer complains about the service being damaged due to hot migration, and when hot migration needs to be prohibited based on various factors.

[0146] In practical applications, a uniform set of characteristic parameters can be used to characterize the reason for customer complaints when service is impaired due to hot migration; different characteristic parameters can be used to distinguish different factors that lead to prohibition of hot migration, thus serving as different reasons for tolerance.

[0147] Work order system

[0148] If the data source corresponding to the data group is the work order system, then according to the key fields indicated in the corresponding processing logic and the target stability problem type of concern, each work order record in the data group is classified according to the field values ​​under the key fields to obtain the target stability problem type to which each work order record is classified; for any target stability problem type of concern in the processing logic, the corresponding tolerance for the target customer is determined according to the number of work order records classified under the target stability problem type.

[0149] A ticketing system is a management system used by cloud vendors to support customer feedback on issues encountered during use. Customers can report various faults or usage obstacles to the ticketing system. Relevant personnel from the cloud vendor or cloud service provider can then handle these issues based on the reported information, including maintenance and other measures, to help customers resolve the problems. All these steps are recorded as visible data in the ticketing system. Currently, the ticketing system supports customers submitting tickets through various channels, such as the cloud service console or mobile office platform, which are not limited here. In this embodiment, ticketing records submitted by customers through various channels can be collected from the ticketing system and organized into a customer-centric data group. This data group may contain ticketing records, and some fields in the ticketing records can reflect tolerance for stability issues; these fields are designated as key fields in the processing logic.

[0150] Based on this, the work order records in the data group can be categorized according to the field values ​​under the key fields, so as to classify the work order records under the target stability problem type that the processing logic is concerned with.

[0151] Optionally, in this embodiment, the work order reason field can be used as the required key field in the processing logic corresponding to the work order system as the data source; and all stability problem types existing in the cloud computing system can be monitored. Thus, in this embodiment, for any work order record in the data group, the reason for initiating the work order recorded under the work order reason field can be determined; based on the classification relationship between the complaint reason indicated in the processing logic and the stability problem type, the work order record can be classified under the stability problem type associated with the target complaint reason, thereby completing the classification operation of the work order record.

[0152] The processing logic pre-defines the categorization relationship between work order initiation reasons and stability problem types; that is, it specifies which work order initiation reason can be categorized under which stability problem type. For example, the processing logic can classify work order initiation reasons such as "network jitter" and "bandwidth impairment" under the stability problem type of "performance problem." It should be understood that these work order initiation reasons and categorization relationships are exemplary, and this embodiment is not limited to them.

[0153] In this way, the target stability problem type can be determined for each work order record within the data group. A work order record can be classified into one or more target stability problem types, which is not limited here.

[0154] Based on the classification results, the process can continue to determine the tolerance level under the stability problem type. Within the data group corresponding to the work order system data source, tolerance levels can also be used to characterize tolerance. Therefore, an exemplary tolerance determination operation could be: for any target stability problem type of interest in this processing logic, based on the number of work order records classified under that target stability problem type, determine the corresponding tolerance level for the target customer under that target stability problem type.

[0155] An exemplary judgment rule could be: if the number of work order records categorized under a target stability problem type exceeds a first threshold, then the minimum tolerance level can be determined as the target customer's tolerance level under that target stability problem type. In other words, in this exemplary tolerance determination operation, if the number of work order records categorized under a certain target stability problem type exceeds the aforementioned first threshold, then the tolerance level under that target stability problem type can be determined as the minimum tolerance level, such as "low" in the previous example. The first threshold here can be set as needed, for example, it can be set to 10.

[0156] This exemplary judgment rule further proposes that if the number of work order records categorized under the target stability problem type is lower than the aforementioned first threshold but higher than the second threshold, where the first threshold is greater than the second threshold, then the tolerance level of the target customer under this data group for the target stability problem type can be set to the next higher tolerance level than the lowest tolerance level, such as the aforementioned "high" tolerance level, etc., without limitation here. Of course, if the number of work order records categorized under the target stability problem type does not meet the quantity requirements under any tolerance level, then the tolerance level of the target customer under this data group for the target stability problem type can be set to "uncertain," etc., without limitation here.

[0157] In this way, under the data group corresponding to the work order system as the data source, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0158] Furthermore, under the data group corresponding to the work order system as the data source, the following is also proposed:

[0159] The system can deduplicate the reasons for initiating work orders in a data group; use the remaining reasons for initiating work orders as the tolerance reasons for the target customer; and associate the tolerance reasons and the identifier information of the data source corresponding to the data group with the tolerance description information corresponding to the data group.

[0160] In practical applications, considering the diverse range of values ​​for the "Cause" field in the work order system, it is preferable to normalize these values ​​during the process of organizing data groups for target customers. Normalization can be understood as grouping similar field values ​​under the same work order initiation reason. This results in more standardized work order initiation reasons recorded under the "Cause" field within the data group, fewer possible field values, and greater efficiency in the aforementioned work order record classification process based on the "Cause" field. Furthermore, fewer types of tolerable reasons will be identified within this data group, effectively saving computational resources.

[0161] Operating System Error Event Labeling System

[0162] If the data source corresponding to the data group is an operating system error event labeling system, then based on whether there are manually labeled records of operating system error events corresponding to the target customer in the data group, the corresponding tolerance for the target customer under the type of target stability problem that the processing logic is concerned with is determined.

[0163] Operating system error events (PANICs) are runtime errors that force the operating system into an abnormal termination state when encountering unsolvable problems. The operating system error event labeling system is a management system where cloud vendors proactively help customers manually label operating system error events. In simpler terms, some customers may not report operating system error events because they are unaware of them or because their architecture has excellent fault tolerance. In such cases, cloud vendors can proactively help these customers manually label the events.

[0164] Based on this, in this embodiment, a list of customers who have manually labeled operating system error events can be collected from this data source and organized into a customer-dimensional data group.

[0165] It is understandable that if there are manually annotated records of operating system error events corresponding to the target customer in the data set, it indicates that the target customer has a relatively high tolerance for operating system error events. Accordingly, in this embodiment, it is assumed that the target customer also has a relatively high tolerance for stability problems caused by operating system error events.

[0166] Based on this, an exemplary judgment rule could be: if there are manually annotated records of operating system error events corresponding to the target customer in the data set, determine that the target customer's tolerance for the type of stability problem that the processing logic is concerned with is "not concerned", so as to characterize that the target customer has a relatively high tolerance for the type of stability problem caused by operating system error events.

[0167] In this exemplary judgment rule, it is also proposed that if there are no manually annotated records of operating system error events corresponding to the target customer in the data group, it can be determined that the tolerance of the target customer under the type of target stability problem that the processing logic is concerned with is uncertain.

[0168] Optionally, under the data group corresponding to the operating system error event identification system data source, considering that the stability problems caused by operating system error events usually have a similar effect to the crash problem, the target stability problem type of concern can be set to the problem type related to crash, such as the "crash problem" mentioned above, without limitation here.

[0169] In this way, under the data group corresponding to the operating system error event identification system data source, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0170] Furthermore, under the data group corresponding to the operating system error event identification system as the data source, the following is also proposed:

[0171] The reasons for not actively reporting the manually annotated records of operating system error events can be used as tolerance reasons; the tolerance reasons and the identification information of the data source can be associated with the tolerance description information corresponding to the array.

[0172] Here, the reasons for not proactively reporting may include, but are not limited to, customer types such as test customers and fault drill customers, as well as architecture types such as fault tolerance mechanisms, etc. No specific limitations are set here.

[0173] Proactive Operation and Maintenance Event Labeling System

[0174] If the data source corresponding to the data group is the proactive maintenance event labeling system, and there are manual labeling records of proactive maintenance events corresponding to the target customer in the data group, the field values ​​under the key fields indicated in the processing logic are found from the manual labeling records of proactive maintenance events. The tolerance level set for the field values ​​in the processing logic is determined as the tolerance level of the target customer under the type of target stability problem that the processing logic focuses on. Among them, the key fields include the event tag field, and different field values ​​under the event tag field are used to distinguish the different acceptance levels of customers for proactive maintenance events.

[0175] Proactive maintenance events refer to maintenance events initiated by the cloud vendor. These events may cause service disruptions for customers. Customers affected by proactive maintenance events may proactively report them, for example, by filing complaints in the aforementioned customer service system. However, some customers, while affected by proactive maintenance events, may not have proactively reported them. For these customers, the cloud vendor can proactively perform manual labeling. The manually labeled data may include, but is not limited to, the customer's identity identifier and event tags related to the proactive maintenance event.

[0176] Based on this, in this embodiment, a list of customers who have manually labeled proactive maintenance events can be collected from the maintenance event labeling system and organized into a customer-dimensional data group.

[0177] It's worth noting that under this data source, the customer's failure to proactively report events does not necessarily mean that the customer is completely tolerant of proactive maintenance events. Moreover, the aforementioned event tags typically describe the customer's level of acceptance of proactive maintenance events, and different event tags can be used to distinguish different levels of customer acceptance of proactive maintenance events. For example, common event tags include "service is fault-tolerant," "containerized deployment," "automatic response after timeout," and "high customer concern," etc., without further examples here.

[0178] Under the data group corresponding to this data source, the event label field can be set as a key field in the processing logic, and the tolerance level of different field values ​​under the event label can be set for the type of stability problem of the target of concern.

[0179] Optionally, under the data group corresponding to this data source, considering that the stability issues caused by proactive maintenance events usually have a certain similarity to the impact of maintenance issues, the target stability issue type of the processing logic can be set to a maintenance-related issue type, such as the "maintenance issue" mentioned above, without limitation here.

[0180] For example, following the event tags in the above example, the tolerance level corresponding to "High Customer Concern" under "Operational Issues" can be "Low"; the tolerance level corresponding to "Automatic Response After Timeout" under "Operational Issues" can be "High"; while the tolerance level corresponding to event tags such as "Service is Fault-Tolerant" and "Containerized Deployment" under "Operational Issues" can be set to "Uncertain". This is merely an example, and this embodiment is not limited thereto.

[0181] In this way, under the data group corresponding to the proactive operation and maintenance event identification system, the tolerance of the target customer under each type of target stability problem of concern can be determined, thereby obtaining the tolerance description information corresponding to the data group.

[0182] Furthermore, under the data group corresponding to the proactive operation and maintenance event identification system as the data source, the following is also proposed:

[0183] Event tags contained in the manually annotated records of proactive maintenance events can be used as tolerance reasons; the tolerance reasons and the identification information of the data source can be associated with the tolerance description information corresponding to the array.

[0184] In this embodiment, besides using tolerance levels to characterize tolerance, other types of quantitative representation can also be used, such as concern levels. A higher concern level indicates a lower tolerance for stability issues, which is the opposite of a higher tolerance level. No further limitations are imposed here, nor will any further examples of quantitative representation types be provided.

[0185] In summary, this embodiment provides exemplary solutions for determining tolerance levels for target customers within data groups, targeting several exemplary data sources. As can be seen from the description of the above exemplary solutions, this embodiment can collect abundant usage record data from diverse data sources. Furthermore, appropriate processing logic can be employed within data groups corresponding to different data sources to adapt to the characteristics of the data sources and the types of stability issues they cause, thereby enabling more efficient and accurate tolerance level determination within each data group.

[0186] In the above or following embodiments, various implementation methods can be used to merge the tolerance description information corresponding to multiple data groups. An exemplary merging scheme is provided below.

[0187] In this exemplary merging scheme, the following is proposed:

[0188] For any type of stability problem existing in a cloud computing system, it can filter target tolerance description information that focuses on that type of stability problem from multiple tolerance description information;

[0189] Following the preset screening order, check in turn whether the tolerance described in the tolerance description information of each target for the type of stability problem meets the selection criteria.

[0190] The tolerance levels that meet the selection criteria will be used as the corresponding tolerance levels for the target customers under the type of stability issue.

[0191] As mentioned earlier, the types of stability problems corresponding to different data groups may not be exactly the same. Therefore, some data groups may only focus on certain types of stability problems existing in the cloud computing system. In response, this embodiment proposes that for any type of stability problem existing in the cloud computing system, the target tolerance description information focusing on that type of stability problem can be first screened as the merging basis for tolerance determination.

[0192] This paper proposes an on-demand troubleshooting mechanism. For any type of stability problem in a cloud computing system, the tolerance level in one of the target tolerance descriptions will be selected as the processing result for that type of stability problem.

[0193] The screening order here can be flexibly set as needed, and this embodiment does not limit it. An exemplary screening order may be: setting the priority order among data groups and the order among tolerance levels; according to the order of tolerance levels, under each tolerance level, sequentially screening the tolerance description information corresponding to multiple data groups according to the aforementioned priority order. Following this exemplary screening order, an exemplary selection condition may be: if the tolerance in a certain data group is consistent with the tolerance level currently being screened, then it can be determined that the tolerance description information meets the selection condition.

[0194] For example, taking the stability issue type of "downtime problem" as an example, we can first check the "high" tolerance level, and check the tolerance description information of the data group under the corresponding data source in the following priority order: critical protection system - customer service system - operating system error event identification system - work order system. When a tolerance level of "high" or equivalent is found, the tolerance level recorded in the tolerance description information for the stability issue type of "downtime problem" can be used as the corresponding handling result for the target customer under the stability issue type of "downtime problem".

[0195] In this example, if no tolerance description information matching the selection criteria is found at the "low" tolerance level, the next higher tolerance level, "high," can be checked, and another round of checks can be performed according to the above priority order. In this way, ultimately, a recorded tolerance can be selected from the tolerance description information constructed for the target customer as the corresponding handling result for the target customer under the stability problem type of "downtime issue."

[0196] Furthermore, in this embodiment, the tolerance reasons and data source identifiers associated with the selected tolerance description information can be linked to the processing results of the target customer under the corresponding stability issue type. This information can refine the decision-making basis during service optimization, thereby enabling more precise assistance to the target customer in avoiding the stability issues they are concerned about during service optimization.

[0197] In summary, the exemplary merging scheme proposed in this embodiment can adopt an on-demand screening approach. For various stability issues existing in the cloud computing system, an appropriate tolerance level can be selected from the tolerance description information constructed for the target customer as the processing result. This comprehensively considers the tolerance levels perceived based on various data sources, thereby more reasonably determining the various stability issues existing in the cloud computing system for the target customer.

[0198] Of course, other merging schemes can also be used in this embodiment. For example, for any type of stability problem in the cloud computing system, the tolerance recorded in the tolerance description information constructed for the target customer for that stability problem type can be averaged or medianized to obtain the corresponding processing result for the target customer under that stability problem type. In this embodiment, the merging scheme is not limited, and no further examples are given here.

[0199] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0200] Figure 5 This is a schematic diagram of the structure of a computing device provided for another exemplary embodiment of this application. For example... Figure 5 As shown, the computing device includes: a memory 50, a processor 51, and a communication component 52.

[0201] Processor 51, coupled to memory 50 and communication component 52, is used to execute computer programs in memory 50 for:

[0202] Collect usage data generated during the process of target customers using the cloud computing system;

[0203] Based on the usage data, the tolerance level of the target customer for various stability issues in the cloud computing system is determined, so as to obtain the corresponding processing results for the target customer.

[0204] The processing results are used as a basis for decision-making to optimize services for the target customer in the cloud computing system.

[0205] In an optional embodiment, the usage record data includes multiple data groups from different data sources, and the types of stability issues corresponding to different data groups are not entirely the same; when the processor 51 determines the tolerance of the target customer for various stability issues existing in the cloud computing system based on the usage record data, it may specifically be used to:

[0206] Under the multiple data groups, the tolerance level corresponding to the type of stability issue of concern is determined for each target customer, so as to obtain the tolerance description information corresponding to each of the multiple data groups;

[0207] The tolerance description information corresponding to each of the multiple data groups is merged to obtain the target customer's tolerance for various stability issues existing in the cloud computing system.

[0208] In an optional embodiment, when the processor 51 determines the tolerance level corresponding to the type of stability issue of concern for each target customer under the plurality of data groups, it may specifically be used to:

[0209] Based on the mapping relationship between the data source and the processing logic, the processing logic to be followed is determined for each of the multiple data groups, and the processing logic indicates the type of stability issues of concern.

[0210] For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern.

[0211] In an optional embodiment, when the processor 51 determines the tolerance level for the target customer under the type of stability issue of concern for any one of the plurality of data groups, in accordance with the determined processing logic, it may specifically be used to:

[0212] If the data source corresponding to the data group is a critical protection system, then according to the key fields indicated in the processing logic, based on the field values ​​of each critical protection task record in the data group under the key fields, the tolerance corresponding to any target stability problem type indicated in the processing logic is determined for each critical protection task record.

[0213] Based on the tolerance levels corresponding to the target stability problem types recorded for each critical protection task, the tolerance distribution is statistically analyzed.

[0214] Based on the tolerance distribution, determine the corresponding tolerance for the target customer under the target stability problem type.

[0215] In an optional embodiment, when the processor 51 determines the tolerance corresponding to any target stability problem type indicated for concern in the processing logic for each critical protection task record based on the field values ​​under the key field in the data group, it may specifically be used to:

[0216] For any critical protection task record in the data group, query the target critical protection package type recorded in the package type field of the critical protection task record;

[0217] From the tolerance mapping relationship indicated in the processing logic, query the tolerance that maps to the target critical protection package type under each target stability problem type, and record it as the corresponding tolerance of the critical protection task under each target stability problem type.

[0218] In an optional embodiment, a tolerance level is used to characterize the tolerance; when the processor 51 calculates the tolerance distribution for any target stability problem type of interest in the processing logic, based on the tolerance recorded by each critical protection task under the target stability problem type, it can be specifically used for:

[0219] For any target stability problem type of interest in the processing logic, the number of critical protection task records under different tolerance levels is counted to obtain the tolerance distribution corresponding to the target stability problem type.

[0220] Based on the tolerance distribution, when determining the corresponding tolerance for the target customer under the type of target stability problem, it can be specifically used for:

[0221] Based on the number of critical protection task records under different tolerance levels, the corresponding tolerance level for the target customer under the target stability problem type is determined.

[0222] In an alternative embodiment, processor 51 may also be used for:

[0223] Deduplicatize the critical insurance package types contained in the data group;

[0224] The remaining types of critical insurance packages will be used as the tolerance reasons for the target customers.

[0225] The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

[0226] In an optional embodiment, when the processor 51 determines the tolerance level for the target customer under the type of stability issue of concern for any one of the plurality of data groups, in accordance with the determined processing logic, it may specifically be used to:

[0227] If the data source corresponding to the data group is the customer relations system, then according to the key fields indicated in the processing logic and the target stability problem type of concern, each customer relations record in the data group is classified according to the field values ​​under the key fields to obtain the target stability problem type to which each customer relations record is classified.

[0228] For any target stability issue type of interest in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of customer relationship records classified under the target stability issue type.

[0229] In an optional embodiment, when the processor 51 categorizes customer relationship records according to the field values ​​under the key fields contained in the data group, it may specifically be used to:

[0230] For any customer relationship record in the data set, determine the target complaint reason recorded under the complaint reason field;

[0231] Based on the classification relationship between the complaint cause and the stability problem type indicated in the processing logic, the customer service record is classified under the stability problem type associated with the target complaint cause, thereby completing the classification operation of the customer service record.

[0232] In an optional embodiment, a tolerance level is used to characterize tolerance. When the processor 51 determines the corresponding tolerance level for the target customer under any target stability problem type of interest in the processing logic, based on the number of customer relationship records classified under the target stability problem type, it can be specifically used for:

[0233] For any target stability issue type of interest in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of customer relationship records classified under the target stability issue type.

[0234] In an alternative embodiment, processor 51 may also be used for:

[0235] The reasons for complaints contained in the data set are deduplicated;

[0236] The remaining reasons for complaints will be used as the corresponding reasons for tolerance for the target customer.

[0237] The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

[0238] In an optional embodiment, a tolerance level is used to characterize tolerance. When the processor 51 determines the corresponding tolerance for the type of stability problem of concern for the target customer for any one of the plurality of data groups, according to the determined processing logic, it can be specifically used for:

[0239] If the data source corresponding to the data group is a lossy change risk avoidance system, then based on whether there is a lossy change risk avoidance record in the data group corresponding to the target customer, the tolerance level corresponding to the target stability problem type of concern in the processing logic is determined for the target customer.

[0240] In an alternative embodiment, processor 51 may also be used for:

[0241] If there is a record of risk aversion to loss of change corresponding to the target customer in the data group, the target preset parameter is used as the tolerance reason corresponding to the target customer. The target preset parameter is used to characterize that the target customer belongs to the risk aversion to loss of change category.

[0242] The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

[0243] In an optional embodiment, a tolerance level is used to characterize tolerance. When the processor 51 determines the corresponding tolerance for the type of stability problem of concern for the target customer for any one of the plurality of data groups, according to the determined processing logic, it can be specifically used for:

[0244] If the data source corresponding to the data group is a hot migration control system, then based on whether there is a hot migration control record corresponding to the target customer in the data group, the tolerance corresponding to the target stability problem type of concern in the processing logic is determined for the target customer.

[0245] In an alternative embodiment, processor 51 may also be used for:

[0246] If a hot migration control record corresponding to the target customer exists in the data group, the cause of the control record contained in the hot migration control record shall be used as the tolerance reason corresponding to the target customer.

[0247] The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group;

[0248] The reasons for the occurrence of the control record include customer complaints when service is impaired due to hot migration, and one or more reasons for prohibiting hot migration based on various factors.

[0249] In an optional embodiment, when the processor 51 determines the tolerance level for the target customer under the type of stability issue of concern for any one of the plurality of data groups, in accordance with the determined processing logic, it may specifically be used to:

[0250] If the data source corresponding to the data group is the work order system, then each work order record is classified according to the work order initiation reason recorded in the work order reason field of each work order record contained in the data group, so as to obtain the target stability problem type to which each work order record is classified.

[0251] For any stability issue type of concern in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of work order records classified under the stability issue type.

[0252] In an optional embodiment, when the processor 51 determines the tolerance level for the target customer under the type of stability issue of concern for any one of the plurality of data groups, in accordance with the determined processing logic, it may specifically be used to:

[0253] If the data source corresponding to the data group is an operating system error event labeling system, then based on whether there are manually labeled records of operating system error events corresponding to the target customer in the data group, the tolerance corresponding to the target customer under the target stability problem type of the processing logic is determined.

[0254] In an optional embodiment, a tolerance level is used to characterize tolerance. When the processor 51 determines the corresponding tolerance for the type of stability problem of concern for the target customer for any one of the plurality of data groups, according to the determined processing logic, it can be specifically used for:

[0255] If the data source corresponding to the data group is the proactive operation and maintenance event labeling system, then if there is a proactive operation and maintenance event manual labeling record corresponding to the target customer in the data group, the field value under the key field indicated in the processing logic is searched from the proactive operation and maintenance event manual labeling record.

[0256] The tolerance level set for the field value in the processing logic is determined as the tolerance level of the target customer under the type of target stability problem that the processing logic focuses on;

[0257] The key fields include an event tag field, and the different values ​​of the fields under the event tag field are used to distinguish the different levels of customer acceptance of proactive maintenance events.

[0258] In an optional embodiment, when the processor 51 merges the tolerance description information corresponding to each of the plurality of data groups to obtain the target customer's tolerance for various stability issues existing in the cloud computing system, it may specifically be used to:

[0259] For any type of stability problem existing in the cloud computing system, target tolerance description information that focuses on the type of stability problem is selected from the plurality of tolerance description information;

[0260] According to the preset screening order, check in turn whether the tolerance described in the tolerance description information of each target for the stability problem type meets the selection criteria;

[0261] The tolerance levels that meet the selection criteria are identified and used as the corresponding tolerance levels for the target customer under the stability issue type.

[0262] In one optional embodiment, the various stability issues existing in the cloud computing system include one or more of the following: downtime issues, operation and maintenance issues, and performance issues.

[0263] In an optional embodiment, when the processor 51 uses the processing result as a decision basis to optimize services for the target customer in the cloud computing system, it may specifically be used to:

[0264] The processing results are used as the basis for decision-making to optimize resource configuration and / or operation and maintenance strategies for the target customer in the cloud computing system.

[0265] Furthermore, such as Figure 5 As shown, the computing device also includes other components such as a power supply component 53. Figure 5 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 5 The components shown.

[0266] It is worth noting that the technical details of the above embodiments of the computing device can be found in the description of the service optimization system in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0267] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can implement the steps in the above method embodiments.

[0268] Accordingly, this application also provides a computer program product, which, when executed, can implement the steps in the above method embodiments.

[0269] The above Figure 5 The memory in a computer is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks.

[0270] The above Figure 5 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0271] The above Figure 5The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0272] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0274] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0275] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0276] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0277] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0278] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A service optimization method, characterized in that, include: Collect usage data generated during the process of target customers using the cloud computing system; Based on the usage data, the tolerance level of the target customer for various stability issues in the cloud computing system is determined, so as to obtain the corresponding processing results for the target customer. The processing results are used as a basis for decision-making to optimize services for the target customer in the cloud computing system.

2. The method according to claim 1, characterized in that, The usage record data contains multiple data groups from different data sources, and the types of stability issues corresponding to different data groups are not entirely the same; based on the usage record data, the tolerance for various stability issues existing in the cloud computing system is determined for the target customer, including: Under the multiple data groups, the tolerance level corresponding to the type of stability issue of concern is determined for each target customer, so as to obtain the tolerance description information corresponding to each of the multiple data groups; The tolerance description information corresponding to each of the multiple data groups is merged to obtain the target customer's tolerance for various stability issues existing in the cloud computing system.

3. The method according to claim 2, characterized in that, Under the multiple data groups, the corresponding tolerance for the type of stability issue of concern is determined for each target customer, including: Based on the mapping relationship between the data source and the processing logic, the processing logic to be followed is determined for each of the multiple data groups, and the processing logic indicates the type of stability issues of concern. For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern.

4. The method according to claim 3, characterized in that, For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern, including: If the data source corresponding to the data group is a critical protection system, then according to the key fields indicated in the processing logic, based on the field values ​​of each critical protection task record in the data group under the key fields, the tolerance corresponding to any target stability problem type indicated in the processing logic is determined for each critical protection task record. Based on the tolerance levels corresponding to the target stability problem types recorded for each critical protection task, the tolerance distribution is statistically analyzed. Based on the tolerance distribution, determine the corresponding tolerance for the target customer under the target stability problem type.

5. The method according to claim 4, characterized in that, Based on the field values ​​of each critical protection task record in the data set under the key fields, determine the corresponding tolerance for each critical protection task record under any target stability problem type indicated for concern in the processing logic, including: For any critical protection task record in the data group, query the target critical protection package type recorded in the package type field of the critical protection task record; From the tolerance mapping relationship indicated in the processing logic, query the tolerance that maps to the target critical protection package type under each target stability problem type, and record it as the corresponding tolerance of the critical protection task under each target stability problem type.

6. The method according to claim 4 or 5, characterized in that, Tolerance levels are used to characterize tolerance; for any target stability problem type of concern in the processing logic, the tolerance distribution is statistically analyzed based on the tolerance levels corresponding to each critical protection task under the target stability problem type, including: For any target stability problem type of interest in the processing logic, the number of critical protection task records under different tolerance levels is counted to obtain the tolerance distribution corresponding to the target stability problem type. Based on the tolerance distribution, determine the corresponding tolerance for the target customer under the target stability problem type, including: Based on the number of critical protection task records under different tolerance levels, the corresponding tolerance level for the target customer under the target stability problem type is determined.

7. The method according to claim 4, characterized in that, Also includes: Deduplicatize the critical insurance package types contained in the data group; The remaining types of critical insurance packages will be used as the tolerance reasons for the target customers. The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

8. The method according to claim 3, characterized in that, For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern, including: If the data source corresponding to the data group is the customer relations system, then according to the key fields indicated in the processing logic and the target stability problem type of concern, each customer relations record in the data group is classified according to the field values ​​under the key fields to obtain the target stability problem type to which each customer relations record is classified. For any target stability issue type of interest in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of customer relationship records classified under the target stability issue type.

9. The method according to claim 8, characterized in that, Based on the field values ​​of each customer relationship record contained in the data group under the key fields, each customer relationship record is categorized, including: For any customer relationship record in the data set, determine the target complaint reason recorded under the complaint reason field; Based on the classification relationship between the complaint cause and the stability problem type indicated in the processing logic, the customer service record is classified under the stability problem type associated with the target complaint cause, thereby completing the classification operation of the customer service record.

10. The method according to claim 8 or 9, characterized in that, Tolerance levels are used to characterize tolerance. For any target stability issue type of interest in the processing logic, the corresponding tolerance level for the target customer under the target stability issue type is determined based on the number of customer relationship records classified under that target stability issue type, including: For any target stability issue type of interest in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of customer relationship records classified under the target stability issue type.

11. The method according to claim 9, characterized in that, Also includes: The reasons for complaints contained in the data set are deduplicated; The remaining reasons for complaints will be used as the corresponding reasons for tolerance for the target customer. The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

12. The method according to claim 3, characterized in that, Tolerance levels are used to characterize tolerance. For any one of the multiple data groups, following the determined processing logic, the corresponding tolerance level for the target customer under the type of stability issue of concern is determined, including: If the data source corresponding to the data group is a lossy change risk avoidance system, then based on whether there is a lossy change risk avoidance record in the data group corresponding to the target customer, the tolerance level corresponding to the target stability problem type of concern in the processing logic is determined for the target customer.

13. The method according to claim 12, characterized in that, Also includes: If there is a record of risk aversion to loss of change corresponding to the target customer in the data group, the target preset parameter is used as the tolerance reason corresponding to the target customer. The target preset parameter is used to characterize that the target customer belongs to the risk aversion to loss of change category. The tolerance reasons, the off-peak window authorized by the target customer recorded in the lossy change risk avoidance record, and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group.

14. The method according to claim 3, characterized in that, Tolerance levels are used to characterize tolerance. For any one of the multiple data groups, following the determined processing logic, the corresponding tolerance level for the target customer under the type of stability issue of concern is determined, including: If the data source corresponding to the data group is a hot migration control system, then based on whether there is a hot migration control record corresponding to the target customer in the data group, the tolerance corresponding to the target stability problem type of concern in the processing logic is determined for the target customer.

15. The method according to claim 14, characterized in that, Also includes: If a hot migration control record corresponding to the target customer exists in the data group, the cause of the control record contained in the hot migration control record shall be used as the tolerance reason corresponding to the target customer. The tolerance reason and the identification information of the data source corresponding to the data group are associated with the tolerance description information corresponding to the data group; The reasons for the occurrence of the control record include customer complaints when service is impaired due to hot migration, and one or more reasons for prohibiting hot migration based on various factors.

16. The method according to claim 3, characterized in that, For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern, including: If the data source corresponding to the data group is the work order system, then each work order record is classified according to the work order initiation reason recorded in the work order reason field of each work order record contained in the data group, so as to obtain the target stability problem type to which each work order record is classified. For any stability issue type of concern in the processing logic, the tolerance level corresponding to the target customer under the target stability issue type is determined based on the number of work order records classified under the stability issue type.

17. The method according to claim 3, characterized in that, For any one of the multiple data groups, following the determined processing logic, determine the corresponding tolerance level for the target customer under the type of stability issue of concern, including: If the data source corresponding to the data group is an operating system error event labeling system, then based on whether there are manually labeled records of operating system error events corresponding to the target customer in the data group, the tolerance corresponding to the target customer under the target stability problem type of the processing logic is determined.

18. The method according to claim 3, characterized in that, Tolerance levels are used to characterize tolerance. For any one of the multiple data groups, following the determined processing logic, the corresponding tolerance level for the target customer under the type of stability issue of concern is determined, including: If the data source corresponding to the data group is the proactive operation and maintenance event labeling system, then if there is a proactive operation and maintenance event manual labeling record corresponding to the target customer in the data group, the field value under the key field indicated in the processing logic is searched from the proactive operation and maintenance event manual labeling record. The tolerance level set for the field value in the processing logic is determined as the tolerance level of the target customer under the type of target stability problem that the processing logic focuses on; The key fields include an event tag field, and the different values ​​of the fields under the event tag field are used to distinguish the different levels of customer acceptance of proactive maintenance events.

19. The method according to claim 2, characterized in that, The tolerance descriptions corresponding to the multiple data groups are merged to obtain the target customer's tolerance for various stability issues in the cloud computing system, including: For any type of stability problem existing in the cloud computing system, target tolerance description information that focuses on the type of stability problem is selected from the plurality of tolerance description information; According to the preset screening order, check in turn whether the tolerance described in the tolerance description information of each target for the stability problem type meets the selection criteria; The tolerance levels that meet the selection criteria are selected as the corresponding tolerance levels for the target customer under the type of stability problem.

20. The method according to any one of claims 1-5, 7-9 or 11-19, characterized in that, The stability issues existing in the cloud computing system include one or more of the following: downtime issues, operation and maintenance issues, and performance issues.

21. The method according to any one of claims 1-5, 7-9 or 11-19, characterized in that, Using the processing results as a basis for decision-making, service optimization is performed for the target customer in the cloud computing system, including: The processing results are used as the basis for decision-making to optimize resource configuration and / or operation and maintenance strategies for the target customer in the cloud computing system.

22. A service optimization system, characterized in that, include: Data collection layer, data processing layer, and optimization execution layer; The data collection layer is used to collect usage records generated during the target customer's use of the cloud computing system; The data processing layer records data based on the usage situation to determine the tolerance of the target customer for various stability issues existing in the cloud computing system, so as to obtain the corresponding processing result for the target customer. The optimization execution layer is used to use the processing results as a decision-making basis to optimize services for the target customer in the cloud computing system.

23. A computing device, characterized in that, Includes memory, processor, and communication components; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for performing the service optimization method according to any one of claims 1-21.

24. A computer-readable storage medium for storing a computer program, characterized in that, When the computer program is executed by one or more processors, the one or more processors perform the service optimization method according to any one of claims 1-21.

25. A computer program product, characterized in that, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the service optimization method according to any one of claims 1-21.

Images