A service optimization method, system, device, computer program product and storage medium

Abstract

The embodiment of the application provides a service optimization method, system, device, computer program product and storage medium. A new decision basis, i.e., stability description information in the unit of cloud resources, is introduced in the service optimization process. The stability description information in the embodiment of the application is in the unit of cloud resources, so that the fine granularity of the stability description information can reach the cloud resource level. Accordingly, in the process of service optimization, the stability of the cloud computing system itself can be improved, and different cloud resources can more accurately avoid stability problems, so that the influence of the stability problems in the cloud computing system on the cloud resources is reduced, and the service stability perceived by the user side can be effectively 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 users. Therefore, the service stability experienced by users is a key indicator for measuring user experience.

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

[0004] Although the availability of cloud resources within a cloud computing system is already very high, some cloud resources still exist that are unavailable. If an unavailable cloud resource is allocated to a user, it may cause significant fluctuations in the service stability experienced by the user. Summary of the Invention

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

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

[0007] For any cloud resource to be described, obtain the tolerance of the cloud resource to stability issues existing in the cloud computing system;

[0008] Based on the tolerance level, stability description information is generated for the cloud resources;

[0009] Bind the stability description information to the cloud resource;

[0010] The stability description information is used as a basis for decision-making when optimizing services in the cloud computing system.

[0011] This application also provides a service optimization system, including: a data collection layer, a data processing layer, and a labeling layer;

[0012] The data collection layer is used to obtain the tolerance of any cloud resource to stability issues existing in the cloud computing system for any cloud resource to be described.

[0013] The data processing layer generates stability description information for the cloud resources based on the tolerance level.

[0014] The annotation layer is used to bind the stability description information to the cloud resource;

[0015] The stability description information is used as a basis for decision-making when optimizing services in the cloud computing system.

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

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

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

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

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

[0021] This application provides a service optimization scheme that proposes introducing a new decision-making basis during the service optimization process—stability description information at the cloud resource level. In this application, for any cloud resource to be described, the tolerance of the cloud resource to stability issues existing in the cloud computing system can be obtained; based on the obtained tolerance, stability description information is generated for the cloud resource; and the stability description information is bound to the cloud resource. The stability description information in this application is at the cloud resource level, which allows the granularity of the stability description information to reach the cloud resource level. Therefore, during the service optimization process, while improving the stability of the cloud computing system itself, it can help different cloud resources more accurately avoid stability issues, thereby reducing the impact of stability issues in the cloud computing system on cloud resources, and thus effectively improving the service stability perceived by the user. Attached Figure Description

[0022] 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:

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

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

[0025] Figure 3 A schematic diagram of an optional structure of a service optimization system provided in an exemplary embodiment of this application;

[0026] Figure 4 A schematic diagram illustrating an exemplary application scenario provided for an exemplary embodiment of this application;

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

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

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

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

[0031] 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 users. 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.

[0032] As mentioned in the background section, cloud resources in cloud computing systems serve numerous users. The cloud resources provided by cloud computing systems can be used to deploy the working systems required by users, such as applications and cloud computing services. Therefore, the service stability perceived by users 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 users with more stable cloud resources. For example, cloud vendors aim to reduce the downtime rate and frequency of downtime in the cloud computing system to improve the stability of cloud resources. Although the availability of cloud resources within a cloud computing system is already high, some unavailable cloud resources still exist, and these unavailable resources may cause significant fluctuations in the service stability perceived by users.

[0033] Therefore, this application proposes a service optimization scheme: introducing a new decision-making basis in the service optimization process—stability description information in units of cloud resources—in order to improve the service stability perceived by users.

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

[0035] 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:

[0036] Step 100: For any cloud resource to be described, obtain the tolerance of that cloud resource to stability issues existing in the cloud computing system;

[0037] Step 101: Based on the obtained tolerance, generate stability description information for cloud resources;

[0038] Step 102: Bind the stability description information to cloud resources as a basis for decision-making when optimizing services in the cloud computing system.

[0039] The stability description information in this embodiment can be used to describe the tolerance of cloud resources to stability issues existing in the cloud computing system. In other words, it can be used to reflect the degree of impact on the service stability perceived by the user when different stability issues occur on cloud resources.

[0040] This embodiment proposes categorizing stability issues in cloud computing systems. The categorization angle and type names are not limited in this embodiment; they can be flexibly designed as needed in practical applications. By categorizing stability issues, the stability description information in this embodiment can more comprehensively cover the stability problems in cloud computing systems. By categorizing stability issues, specific problem phenomena can be identified, thereby providing a better basis for decision-making in the service optimization process.

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

[0042] Based on this, the technical concept of this embodiment proposes to assess the tolerance for stability issues existing in the cloud computing system on a cloud resource basis. The tolerance assessed on a cloud resource basis can be understood as the degree of impact on the service stability perceived by the user when a certain type of stability issue occurs on the cloud resource.

[0043] In this embodiment, the user can be understood as the user of cloud resources. The cloud computing system can allocate cloud resources to the user, and various cloud services required by the user can be deployed on the cloud resources. The user side mentioned in this embodiment can be understood as the relevant communication terminal used by the user. It is worth noting that there can be multiple communication terminals on the user side, and the user side can handle different transactions through different communication terminals. For example, a user-side cloud management system can be used to manage cloud resources. A user-side operation and maintenance system can be used to monitor the operating status of cloud resources and provide operation and maintenance access points, etc. No further examples of user-side communication terminals are given here. In this embodiment, when related operations are involved on the user side, the specific communication terminal used by the user side is not limited; it can be selected as needed according to the actual deployment.

[0044] It's worth noting that the different cloud resources allocated to users in a cloud computing system are not equally important. Influenced by a combination of factors such as the user's computing scenario, scale, deployment type, system architecture, operational capabilities, focus, and level of importance, a portion of the cloud resources allocated to a user are typically critical. When these critical cloud resources encounter the aforementioned stability issues in the cloud computing system, the impact on the service stability perceived by the user is far greater than that of other cloud resources. Therefore, this embodiment proposes to assess the tolerance of cloud resources to stability issues in the cloud computing system on a per-resource basis. This allows for a more efficient and reasonable identification of these critical cloud resources during service optimization, thereby better helping the user protect the stability of these critical cloud resources and effectively improving the service stability perceived by the user.

[0045] In this embodiment, various implementation methods can be used to assess the tolerance for stability issues in the cloud computing system on a per-cloud-resource basis.

[0046] Some alternative implementations suggest that evaluation can be conducted on the user side. To this end, a documentation outlining the aforementioned stability issues identified in cloud computing systems can be provided. This documentation describes, from the perspective of cloud resources, the user-perceived phenomena such as fault manifestations or operational events corresponding to various stability issues, serving as a reference for user-side evaluation. On the user side, based on the fluctuations in service stability experienced when the phenomena described in the documentation occur on cloud resources, the tolerance of cloud resources for stability issues present in the cloud computing system can be assessed.

[0047] Taking the aforementioned performance issue as an example, the corresponding documentation for the performance issue could be:

[0048]

[0049] It should be understood that the above description is merely exemplary, and this embodiment is not limited thereto; no further examples will be provided here.

[0050] Other alternative implementations have been proposed, and the service optimization system in this embodiment can also be used for evaluation. The evaluation scheme based on cloud resources is not limited here, but will be described in more detail in later embodiments.

[0051] Thus, in this embodiment, the tolerance of cloud resources to stability issues existing in the cloud computing system can be assessed on a unit basis.

[0052] Based on this, the technical concept of this embodiment further proposes to introduce a new decision-making basis in the service optimization process—stability description information in units of cloud resources.

[0053] refer to Figure 1 In this embodiment, in step 100, the tolerance of any cloud resource to stability issues existing in the cloud computing system can be obtained for any cloud resource to be described.

[0054] Here, any cloud resource to be described can be specified by the user. The cloud resource to be described can be understood as the cloud resource for which the service optimization system in this embodiment needs to perform stability description. In this embodiment, the cloud resource to be described is typically the cloud resource that needs to be given priority attention during service optimization. In other words, it is usually the important cloud resource mentioned earlier.

[0055] refer to Figure 2 In this embodiment, a data collection layer can be set up in the service optimization system. The data collection layer can be used to obtain the tolerance of any cloud resource to stability issues existing in the cloud computing system for any cloud resource to be described.

[0056] In this embodiment, the acquisition source corresponding to the acquisition operation in step 100 is not limited. For a cloud resource, in step 100, it is possible to acquire the cloud resource's tolerance to stability issues existing in the cloud computing system from one or more acquisition sources. Optionally, the acquisition source here can be a preset database used to store the tolerance evaluated by the user side; it can also be other communication terminals that store the tolerance evaluated on a per-cloud-resource basis. This is not limited here, and no further examples will be given.

[0057] After obtaining the cloud resource's tolerance for stability issues in the cloud computing system, in step 101, stability description information can be generated for the cloud resource based on the obtained tolerance.

[0058] refer to Figure 2 In this embodiment, a data processing layer can be set up in the service optimization system. The data processing layer can be used to generate stability description information for the cloud resource based on the obtained tolerance.

[0059] As mentioned earlier, there may be multiple tolerances obtained for the cloud resource in step 100. Based on this, in step 101, the obtained tolerances can be processed by sorting or analyzing to generate stability description information for the cloud resource.

[0060] Furthermore, in this embodiment, the stability description information corresponding to the cloud resource can be updated on demand. This is mainly because the user's demand for a certain cloud resource is dynamically changing; therefore, the stability description information on the cloud resource will also change dynamically. This on-demand update mechanism can effectively ensure the accuracy of the stability description information generated for the cloud resource. 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 a timed mechanism as an example, in this embodiment, steps 100 and 101 can be automatically executed according to a timed period. In this way, changes in the relevant tolerance assessed for the cloud resource can be detected in a timely manner, thereby improving the accuracy of the stability description information corresponding to the cloud resource.

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

[0062] Continue to refer to Figure 1 In step 102, it is proposed that the generated stability description information can be bound to the cloud resource as a basis for decision-making when optimizing services in the cloud computing system.

[0063] As mentioned above, the stability description information obtained in step 101 can reflect what type of stability problems occur in the cloud resource, which will cause fluctuations in the service stability perceived by the user. This can provide a new basis for decision-making in the service optimization process.

[0064] 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 stability description information obtained in step 101, in step 102, the stability description information, measured in units of cloud resources, can be used as a decision-making basis in the resource allocation optimization process, thereby enabling more reasonable cloud resource allocation for users; it can also be used as a decision-making basis in the operation and maintenance strategy optimization process, thereby enabling more reasonable operation and maintenance arrangements for cloud resources.

[0065] refer to Figure 2 In this embodiment, a labeling layer can be set in the service optimization system to bind the generated stability description information to the cloud resource.

[0066] The following provides several service optimization operations that incorporate stability description information in units of cloud resources as a basis for decision-making, demonstrating the effect on improving service stability.

[0067] Service optimization operation 1

[0068] If the stability description of a cloud resource provided to a user indicates a low tolerance for performance issues, then when optimizing its operation and maintenance strategy, the cloud provider can minimize the consumption of that resource by releasing various cloud service functions that might otherwise occupy it (a typical operation and maintenance scenario). This helps the cloud resource avoid performance issues caused by these cloud service function releases, thereby minimizing fluctuations in service stability perceived by the user.

[0069] Service optimization operation 2

[0070] If a cloud resource provided to a user indicates a low tolerance for downtime in its stability description, the cloud provider can deploy this resource on a physical server less prone to downtime during resource configuration optimization. This helps the cloud resource avoid downtime as much as possible, thereby minimizing fluctuations in service stability perceived by the user.

[0071] Service optimization operation 3

[0072] If the stability description of a cloud resource provided to a user indicates a low tolerance for performance issues, the cloud provider, when optimizing resource configuration, should avoid deploying other cloud resources that frequently compete for physical resources on the physical server where that cloud resource resides. This ensures that the cloud resource can utilize sufficient physical resources, thereby minimizing fluctuations in service stability perceived by the user.

[0073] It should be understood that the above-described service optimization operations are exemplary and this embodiment is not limited thereto. Based on the aforementioned stability description information constructed for cloud resources in this embodiment, decision rules in service optimization operations can be flexibly designed to fully utilize the stability description information provided in this embodiment, thereby enabling more refined service optimization.

[0074] Here, no further examples will be given of service optimization operations based on the stability description information provided in this embodiment, which is based on cloud resources.

[0075] In summary, this embodiment provides a service optimization scheme that proposes introducing a new decision-making basis during the service optimization process—stability description information at the cloud resource level. In this embodiment, for any cloud resource to be described, the tolerance of the cloud resource to stability issues existing in the cloud computing system can be obtained; based on the obtained tolerance, stability description information is generated for the cloud resource; and the stability description information is bound to the cloud resource. The stability description information in this embodiment is at the cloud resource level, which allows the granularity of the stability description information to reach the cloud resource level. Therefore, during service optimization, while improving the stability of the cloud computing system itself, it can help different cloud resources more accurately avoid stability issues, thereby reducing the impact of stability issues in the cloud computing system on cloud resources, and thus effectively improving the service stability perceived by the user.

[0076] The implementation form of the stability description information is not limited in the above or following embodiments. In this embodiment, a preferred implementation form is proposed: cloud resource tagging.

[0077] In other words, this embodiment designs a new cloud resource tag—a stability description tag. It can be understood that the stability description tag in this embodiment is essentially a cloud resource tag, but it describes the characteristics of cloud resources from a new perspective.

[0078] Cloud resource tags can be understood as identifiers for cloud resources. They can be used to classify, search, and aggregate cloud resources with the same characteristics from different dimensions, making cloud resource management easier.

[0079] Based on this, this embodiment proposes that, in step 101, a stability description tag can be created for the cloud resource based on the obtained tolerance level. That is, the stability description information in this embodiment can be implemented using a stability description tag. Correspondingly, in step 102, the stability description tag can be bound to the cloud resource as a cloud resource tag. Here, a tag management system can be invoked to bind the stability description tag to the cloud resource as a cloud resource tag.

[0080] The tag management system is an operations and maintenance service used for grouping and managing cloud resources. It manages cloud resource tags for various cloud resources, including adding and deleting tags. In this embodiment, an option for stability description tags can be added to the tag management system, thus supporting the addition of stability tags to cloud resources.

[0081] refer to Figure 2 In this embodiment, the labeling layer within the service optimization system can call the label management system to bind the stability description labels generated for cloud resources to the cloud resources.

[0082] In this embodiment, the number of corresponding relationships between stability description tags and stability problem types is not limited. The tolerance of cloud resources under multiple stability problem types can be described in one stability description tag. Of course, the tolerance of cloud resources under a certain stability problem type can also be described in one stability description tag. This is not limited here.

[0083] In summary, this embodiment proposes a new cloud resource tag—the stability description tag—and introduces this cloud resource tag as a decision-making basis in the service optimization process. In this way, during the service optimization process, the stability description tag bound to the cloud resource can be used to conveniently and quickly perceive the cloud resource's tolerance for stability issues, thereby making service optimization more convenient.

[0084] It is worth noting that the stability description tag is an optional implementation of the stability description information in this embodiment. In this embodiment, the stability description information can also adopt other implementation forms. Any implementation form that can be bound to cloud resources and can be queried is acceptable. No further examples are given here.

[0085] In the above or below embodiments, the user side can assess the tolerance of cloud resources to stability issues existing in the cloud computing system, and the implementation scheme adopted by the user side when performing the assessment is not limited.

[0086] In some optional implementations, manual evaluation is supported on the user side. User-side personnel can refer to the documentation mentioned above to manually assess the tolerance of relevant cloud resources to stability issues existing in the cloud computing system.

[0087] This optional implementation relies primarily on the human experience and subjective judgment of relevant personnel on the user side. Personnel can input the results of their manual evaluation into the target communication terminal on the user side used to support the tolerance assessment.

[0088] In other alternative implementations, the user side can leverage the data analysis capabilities of various data sources to automatically assess the tolerance levels of relevant cloud resources for stability issues present in the cloud computing system. To this end, the user side can pre-configure mapping rules between feedback data and tolerance levels for different stability issue types in the relevant data sources. The user side can trigger the data source to perform the evaluation operation through timed triggering or automatic triggering when new feedback data appears. In this case, the data source can automatically query user-level usage feedback data and organize it into cloud resource-level feedback data; according to the aforementioned pre-defined mapping rules, the data source can automatically assess the tolerance levels of relevant cloud resources for stability issues present in the cloud computing system.

[0089] The following are two example mapping rules:

[0090] Article 1: If a sub-account is responsible for computing scenarios such as virtual desktops, edge computing, or offline computing, and is basically insensitive to service interruptions and performance degradation, then the cloud resources under that sub-account can be assessed as having "high tolerance for downtime issues", "high tolerance for operational and maintenance issues", and "high tolerance for performance issues".

[0091] Article 2: If a cloud resource experiences a PANIC (Panic in Memory) system crash without loss of computation, and the cloud resource carries non-core / non-critical workloads, then the cloud resource can be assessed as having "high tolerance for downtime".

[0092] As can be understood from the above exemplary mapping rules, the mapping rules can indicate one or a group of cloud resources that need to be evaluated, and indicate what kind of tolerance should be evaluated when the cloud resources have certain feedback data.

[0093] As can be seen, this optional implementation scheme can effectively leverage the data analysis capabilities of the data source and the rich usage feedback data stored at the user level. Based on the mapping rules between user-configured feedback data and tolerance levels under different stability issue types, it can automatically assess the tolerance of relevant cloud resources to stability issues present in the cloud computing system. Further explanation of this user-side automatic assessment scheme using data sources will not be provided here.

[0094] In this optional implementation, there are no restrictions on the data source used. Figure 3 This is a schematic diagram of an optional structure for a service optimization system provided as an exemplary embodiment of this application. (Reference) Figure 3 For example, the data source used on the user side may include, but is not limited to, risk management systems.

[0095] The risk management system can be understood as a management service used by users to passively report risk issues they encounter. It may also have other names, such as a user-linked risk elimination system, but further examples of these names are not provided here. Cloud vendors can proactively initiate alerts, linkages, and communications with users through the risk management system, while users can passively report risk issues they encounter to the system. The feedback data that users input into the risk management system when reporting risk issues may include, but is not limited to, cloud resource identification information, the sub-account to which the cloud resource belongs, and the corresponding computing scenario, computing scale, deployment type, operational capabilities, and level of importance associated with that sub-account. Further examples of feedback data are not provided here.

[0096] Of course, in addition to the risk management system, users can also use various data sources such as the work order system, hot migration management system, and customer relationship management system, which will not be described in detail here. These data sources contain a wealth of usage feedback data, which users can choose as needed.

[0097] In this embodiment, the implementation scheme adopted by the user side when conducting independent evaluation is not limited. The two implementation schemes mentioned above are only exemplary and will not be further illustrated here.

[0098] In this embodiment, the user side can store the self-assessed tolerance levels in a preset database, serving as a source of tolerance information for the service optimization system when acquiring tolerance levels for cloud resources. Following the two optional implementation schemes described above, when using manual assessment, the user-side target communication terminal can store the manually assessed tolerance levels in the preset database; when using a data source for automatic assessment, the data source can directly store the assessment results in the preset database, or the data source can first submit the assessment results to the user-side target communication terminal, and then the target communication terminal stores the assessment results in the preset database.

[0099] It is worth noting that in this embodiment, the tolerance stored for different user sides can be isolated in the preset database to ensure that after receiving a stability description request from a user, the tolerance stored for the corresponding user side can be correctly queried.

[0100] Preferably, in this embodiment, the tolerance levels independently assessed by the user can be stored in a preset database according to an associative storage format of cloud resource filtering conditions and tolerance levels. Here, cloud resource filtering conditions are used to point to a group of cloud resources. This associative storage format can effectively reduce the storage complexity of tolerance levels, especially when a large number of cloud resources are allocated to the user. Cloud resources can be indicated in batches through simple cloud resource filtering conditions, eliminating the need for individual indication and effectively saving processing complexity.

[0101] Based on this, one optional implementation method is proposed in this embodiment:

[0102] For the service optimization system, in response to a stability description request, it can retrieve the cloud resource filtering conditions pre-configured for the stability description request from the preset database; and select cloud resources that meet the cloud resource filtering conditions from the cloud resources provided by the cloud computing system as the cloud resources to be described.

[0103] The stability description requests here can be generated through timed triggering or other methods. In the case of timed triggering, the service optimization system in this embodiment can periodically generate stability description information for cloud resources selected based on the stability description requests. Furthermore, stability description requests are typically user-centric; therefore, during the selection process, the scope of cloud resource selection can be narrowed down to the user dimension. For example, if the stability description request is generated for user A, then cloud resources that meet the cloud resource selection criteria can be selected from the cloud resources allocated to user A in the cloud computing system as the cloud resources requiring description.

[0104] refer to Figure 3 In the data collection layer, a cloud resource filtering unit may be included, which is used to filter cloud resources that meet the cloud resource filtering conditions from the cloud resources provided by the cloud computing system, and use them as the cloud resources to be described.

[0105] It is understood that in this embodiment, the user can use cloud resource filtering conditions to indicate in batches the cloud resources that the service optimization system in this embodiment describes. This can effectively improve the efficiency of cloud resource filtering, especially when a large number of cloud resources are allocated to the user, the improvement effect is even more significant.

[0106] The cloud resource filtering conditions supported in this embodiment are diverse, including but not limited to cloud resource lists, cloud resource name formats, sub-accounts, and cloud resource tags. The following will illustrate the process of filtering out the desired cloud resources based on several exemplary cloud resource filtering conditions.

[0107] Cloud resource list

[0108] For the cloud resource filtering unit, if the cloud resource filtering criteria include a cloud resource list, then the cloud resources indicated in the cloud resource list can be filtered from the cloud resources provided by the cloud computing system as the cloud resources to be described.

[0109] The cloud resource list contains identification information for a group of cloud resources, which can be used to point to a group of cloud resources. In this case, the cloud resource list clearly points to specific cloud resources, and the cloud resource filtering unit can identify each cloud resource pointed to by the cloud resource list as the cloud resource to be described.

[0110] Cloud resource name format

[0111] For the cloud resource filtering unit, if the cloud resource filtering criteria include the cloud resource name format, then cloud resources that conform to the cloud resource name format can be filtered from the cloud resources provided by the cloud computing system as the cloud resources to be described.

[0112] Different cloud resources allocated to users may have different computing scenarios, regions, and workloads. The cloud resource name format reflects these differences. Similar to the cloud resource tags mentioned earlier, the cloud resource name format can also distinguish which cloud resources share similarities. For example, cloud resources at the access layer typically use the following name format: [Region Abbreviation]-prod-router-[Date]-[Serial Number]. Another example is cloud resources handling transaction workloads, which typically use the following name format: [Region Abbreviation]-prod-trade-[Date]-[Serial Number]. Further examples are not provided here.

[0113] In this case, the cloud resource filtering unit can view the cloud resource name format corresponding to each cloud resource allocated to the user. If the name format of any cloud resource matches the cloud resource name format indicated in the cloud resource filtering conditions, then the cloud resource can be identified as the cloud resource to be described.

[0114] Sub-account

[0115] For the cloud resource filtering unit, if the cloud resource filtering criteria include sub-accounts, then the cloud resources belonging to the sub-accounts are filtered out from the cloud resources provided by the cloud computing system and used as the cloud resources to be described.

[0116] A user can have multiple sub-accounts, and each sub-account can be associated with multiple cloud resources. Based on this, when the cloud resource filtering criteria indicate a sub-account, the cloud resource filtering unit can identify the cloud resources associated with that sub-account as the cloud resources to be described.

[0117] Cloud resource tags

[0118] For the cloud resource filtering unit, if the cloud resource filtering criteria include cloud resource tags, then from the cloud resources provided by the cloud computing system, more specifically from the cloud resources provided to the user for whom the stability description request is targeted, the cloud resources with the indicated cloud resource tags are filtered out as the cloud resources to be described.

[0119] As mentioned earlier, cloud resources are bound to cloud resource tags. Based on this, the cloud resource filtering criteria can indicate the cloud resource tags, and the cloud resource filtering unit can identify the cloud resources provided to the aforementioned users and bound with the indicated cloud resource tags as the cloud resources to be described.

[0120] The cloud resource tags here can include basic tags and / or custom tags. Basic tags can be understood as the various tags already existing in the tag management system. The tag management system supports user-defined tags; therefore, users can apply for custom tags in the tag management system. In this embodiment, both basic tags and custom tags are supported. Furthermore, in this embodiment, the cloud resource tags indicated in the cloud resource filtering conditions can be one or more, and may also indicate whether all indicated cloud resource tags must be bound to the cloud resource for it to be selected. The cloud resource filtering unit can then filter according to the relevant requirements in the cloud resource filtering conditions.

[0121] It should be understood that the above-described cloud resource filtering conditions are merely exemplary, and this embodiment is not limited thereto. Regardless of the cloud resource filtering conditions, provided that the cloud resource filtering unit in this embodiment can recognize the prompt information, the cloud resource filtering unit can accurately filter out the cloud resources to be described based on the stability description request. No further examples are provided here.

[0122] Furthermore, in this embodiment, multiple cloud resource filtering conditions can be pre-configured for stability description requests. In a preset database, each cloud resource filtering condition is associated with and stored as "the tolerance level for stability issues in the cloud computing system assessed by the cloud resource pointed to by the filtering condition." The cloud resources selected under different filtering conditions may differ, but these different filtering conditions do not interfere with each other; in this embodiment, different cloud resource filtering conditions can be processed independently. Of course, if multiple cloud resource filtering conditions select the same cloud resource, the relevant tolerance levels can be appropriately used through the merging mechanism proposed later.

[0123] Continue to refer to Figure 3 In this embodiment, a tolerance acquisition unit can also be set in the data collection layer to acquire the tolerance of any cloud resource to stability issues existing in the cloud computing system for any cloud resource to be described.

[0124] In this embodiment, it is proposed that the service optimization system can obtain from the aforementioned preset database the tolerance of cloud resources for stability issues existing in the cloud computing system as assessed by the cloud resources pointed to by the cloud resource screening conditions.

[0125] Based on this, the preset database can serve as the first acquisition source in step 100. The tolerance acquisition unit can obtain the tolerance stored in association with the cloud resource filtering conditions from the preset database to obtain the first tolerance corresponding to any cloud resource to be described. Here, the tolerance obtained for cloud resources under the first acquisition source is collectively referred to as the first tolerance. It should be understood that the second tolerance and the third tolerance are also mentioned later, and the terms "first," "second," and "third" are mainly used to distinguish the acquisition sources.

[0126] Following the examples of cloud resource selection criteria provided above, the process of obtaining tolerance will be further illustrated.

[0127] Cloud resource list

[0128] In this case, the tolerance for storage associated with the cloud resource list applies to all cloud resources pointed to by the cloud resource list.

[0129] For the tolerance acquisition unit, it can retrieve the tolerance levels associated with the cloud resource list from the preset database, and determine that each cloud resource pointed to by the cloud resource list corresponds to the acquired tolerance level. That is, each cloud resource pointed to by the cloud resource list corresponds to the same tolerance level.

[0130] Cloud resource name format

[0131] In this scenario, different cloud resource name formats will be mapped to different tolerance levels. A pre-defined database stores the mapping rules between cloud resource name formats and tolerance levels. These mapping rules can be configured by the user.

[0132] For the tolerance acquisition unit, the tolerance that maps to the cloud resource name format corresponding to the cloud resource can be determined based on the mapping rules, and used as the first tolerance for the cloud resource.

[0133] For example, if a cloud resource allocated to a user conforms to the cloud resource name format of [region abbreviation]-prod-router-[date]-[serial number], and based on the mapping rules, the tolerance for this cloud resource name format is "low tolerance for downtime issues", then the first tolerance for this cloud resource under the stability issue type of "downtime issues" can be obtained as "low".

[0134] Sub-accounts and cloud resource tags

[0135] Similar to the aforementioned cloud resource list, the tolerance for storage associated with a sub-account applies to all cloud resources pointed to by that sub-account. The tolerance for storage associated with a cloud resource tag applies to all cloud resources pointed to by that tag. The acquisition process is similar to that of the aforementioned cloud resource list and will not be detailed here.

[0136] At this point, for reference Figure 3 In this embodiment, the cloud resource filtering unit and the tolerance acquisition unit can work together to obtain a first tolerance from a preset database for any cloud resource to be described.

[0137] It is worth noting that, as mentioned earlier, multiple cloud resource filtering conditions can be configured for a stability description request, and multiple cloud resource filtering conditions may filter the same cloud resource. Therefore, from the perspective of a cloud resource, under any stability problem type, the first tolerance obtained from the first source may be one or more.

[0138] In this embodiment, in addition to storing the relevant tolerance levels that the user has independently assessed in the aforementioned preset database, the user can also create stability description information in units of cloud resources and bind it to the cloud resources independently.

[0139] In this embodiment, stability description information that the user independently binds to cloud resources can be used as the second source of information in step 100. To this end, this embodiment proposes:

[0140] For any cloud resource to be described, query whether the cloud resource already has stability description information created by the cloud management system. If so, convert the stability description information into a tolerance level for stability issues existing in the cloud computing system to obtain the second tolerance level for that cloud resource. Here, the tolerance level obtained for the cloud resource from the second acquisition source is collectively referred to as the second tolerance level.

[0141] Referring to the description in the foregoing embodiments, the stability description information can be implemented using stability description tags. Based on this, referring to... Figure 3 The user-side cloud management system can call the aforementioned tag management system to bind stability description tags to relevant cloud resources.

[0142] The cloud management system can be understood as a management service used to control cloud resources. It provides a user interface that supports cloud resource creation and attribute configuration for managing cloud resources.

[0143] Based on this, the cloud management system can display the stability description tag options designed in this embodiment in the user interface. In response to a cloud resource selection operation, the cloud management system can determine one or a group of cloud resources to be tagged; it can also create a tagging request in response to a tag selection operation. The cloud management system can send this tagging request to the tag management system to request the tag management system to bind the selected stability description tag to the selected cloud resource.

[0144] As mentioned earlier, stability description tags are a type of cloud resource tag, and their data format is no longer tolerance. Therefore, this embodiment proposes that the service optimization system can convert stability description tags into tolerance for stability problems existing in the cloud computing system, as a second tolerance for the cloud resource.

[0145] Further, refer to Figure 3 This embodiment also proposes that the service optimization system can assess the tolerance of cloud resources for stability issues existing in the cloud computing system.

[0146] Therefore, this embodiment proposes: in response to a tolerance assessment request, a third tolerance level for stability issues existing in the cloud computing system can be assessed for the target cloud resource indicated by the tolerance assessment request; the target cloud resource is also referred to as the cloud resource to be described.

[0147] refer to Figure 3 Users can submit tolerance assessment requests through the cloud management system mentioned above.

[0148] Here, the tolerance assessment request may include cloud resource screening criteria, so that the service optimization system in this embodiment can determine which target cloud resources need to be assessed for a third tolerance level. For details on cloud resource screening criteria, please refer to the preceding text; they will not be elaborated upon here.

[0149] In this embodiment, the implementation method used by the service optimization system to evaluate the third tolerance is not limited.

[0150] In some alternative implementations, the service optimization system can automatically filter out the target cloud resources indicated by the tolerance assessment request; the staff corresponding to the service optimization system can manually assess the third tolerance level of the target cloud resources for the stability issues existing in the cloud computing system.

[0151] In other alternative implementations, the aforementioned "mapping rules between feedback data and tolerance" can be configured into the service optimization system. The service optimization system can automatically filter out the target cloud resources indicated by the tolerance assessment request; it can also query and organize feedback data of the target resource dimension from various data sources; and based on the mapping rules and the queried feedback data, it can automatically assess the third tolerance of the target cloud resources for stability issues existing in the cloud computing system.

[0152] This document will not provide further examples or explanations regarding the implementation of the third tolerance level in the service optimization system.

[0153] Based on this, the tolerance level assessed by the service optimization system can be used as the third source of information in step 100. The target cloud resources supported by the tolerance assessment request are also considered as the cloud resources to be described.

[0154] In summary, in this embodiment, the service optimization system can obtain the tolerance of any cloud resource to stability issues existing in the cloud computing system from multiple sources. This can fully incorporate the tolerance independently assessed by the user through different channels, as well as the tolerance assessed by the service optimization system, as the basis for generating stability description information in this embodiment, thereby effectively improving the accuracy and rationality of the stability description information.

[0155] In the above or following embodiments, various implementation methods can be used to generate stability description information for cloud resources based on the obtained tolerance. One optional implementation method is provided below.

[0156] refer to Figure 3 In this optional implementation, it is proposed that a merging unit can be set in the data processing layer.

[0157] For the merging unit, if multiple tolerances are obtained for any cloud resource to be described under any stability problem type, then the target tolerance corresponding to the cloud resource under the stability problem type is determined based on the multiple tolerances; and stability description information is generated for the cloud resource based on the target tolerance.

[0158] Referring to the above embodiments, for any cloud resource to be described, the data collection layer may obtain the corresponding tolerance for the cloud resource from multiple acquisition sources. Therefore, the cloud resource may have multiple tolerances under a certain stability problem type. In this optional implementation, a merging mechanism is proposed to organize the target tolerance corresponding to the cloud resource under a single stability problem type.

[0159] 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, tolerance can be divided into two tolerance levels: high and low, or a special tolerance level: uncertain. Of course, besides using level names to represent tolerance levels, other representation methods can be used, such as using numerical ranges. For example, tolerance can be divided into two tolerance levels: [100, 50] and [49, 1]. No further examples are provided here.

[0160] Of course, besides tolerance levels, other types of quantitative representations can be used to characterize tolerance, such as concern levels. A higher concern level indicates a lower tolerance for stability issues in cloud resources, which is the opposite of a high tolerance level. No further examples of quantitative representation types will be provided here.

[0161] Based on this, an exemplary merging mechanism could be:

[0162] For any cloud resource to be described, if among the multiple tolerance levels obtained for that cloud resource under any stability problem type, there is a first tolerance level and a second tolerance level, then a fourth tolerance level is determined for the cloud resource based on the first and second tolerance levels; this fourth tolerance level is then determined as the target tolerance level for that cloud resource under that stability problem type. For explanations regarding the first and second tolerance levels, please refer to the preceding text; they will not be repeated here.

[0163] In this scenario, for this type of stability issue, tolerance levels have been obtained for the cloud resource from both the first and second acquisition sources. In a preferred embodiment, the second tolerance level obtained for the cloud resource, i.e., the tolerance level obtained from the second acquisition source, can be used as the fourth tolerance level. In other words, if the user has independently bound a stability description tag to the cloud resource, the tolerance level derived from that stability description tag for this type of stability issue can be used as the aforementioned target tolerance level for the cloud resource.

[0164] In this exemplary merging mechanism, a selection process is first performed based on the source of information. That is, the tolerance levels obtained from the aforementioned first and second sources are given priority. As mentioned earlier, both the first and second sources store evaluation results provided by the user side. Therefore, this allows the user's evaluation of cloud resources to be incorporated into the construction of stability description information, thereby ensuring that the stability description information fully reflects the user's expectations for the stability of cloud resources.

[0165] In this exemplary merging mechanism, it is also proposed that: for any cloud resource to be described, if among the multiple tolerances obtained by the cloud resource under any stability problem type, there is no second tolerance but there are multiple first tolerances, then based on the priority order among the different cloud resource screening conditions used when obtaining multiple first tolerances, the first tolerance obtained under the cloud resource screening condition with the highest priority is selected as the target tolerance of the cloud resource under the stability problem type.

[0166] In this exemplary merging mechanism, if a second tolerance level corresponding to the stability type cannot be obtained for the cloud resource from the second source, the selection is further optimized based on the priority order of the cloud resource screening conditions. That is, the first tolerance level obtained for the cloud resource under the higher priority cloud resource screening conditions is preferentially selected as the target tolerance level for the cloud resource under the stability problem type.

[0167] The cloud resource filtering criteria may include, but are not limited to, cloud resource lists, mapping rules between cloud resource name formats and tolerance levels, sub-accounts, and cloud resource tags. An exemplary priority order of different cloud resource filtering criteria from highest to lowest could be: cloud resource tags, cloud resource name formats, cloud resource lists, and sub-accounts. For details regarding cloud resource filtering criteria, please refer to the relevant descriptions in the foregoing embodiments; they will not be repeated here.

[0168] In this exemplary merging mechanism, it is further proposed that:

[0169] For any cloud resource to be described, if among the multiple tolerances obtained for the cloud resource under any stability problem type, the first tolerance and the second tolerance are not included, but the third tolerance is included, then the third tolerance is selected as the target tolerance for the cloud resource under that stability problem type.

[0170] In this scenario, the user side has not assessed the tolerance level for this type of stability issue for the cloud resource. However, the service optimization system has. Therefore, the third tolerance level assessed by the service optimization system can be used as the target tolerance level for this type of stability issue for the cloud resource. Since the service optimization system also conducts its assessment based on user feedback data, the assessed third tolerance level can accurately reflect the cloud resource's tolerance for relevant stability issues, thus effectively ensuring the accuracy of the target tolerance level.

[0171] In this way, based on the above-mentioned selection rules proposed in the exemplary merging mechanism, the tolerance level independently assessed by the user can be selected first. This ensures that the user's proactive expectations for the stability of cloud resources are given priority during the service optimization process, and can be supplemented by the user's objective prediction of the stability expectations of cloud resources during the service optimization system. This helps cloud resources avoid major stability issues more accurately during the service optimization process, thereby improving the service stability perceived by the user.

[0172] It's worth noting that besides the optimal selection, other methods can be used to achieve merging in the above merging mechanism. For example, the average of multiple tolerances can be calculated as the target tolerance, etc., but further examples are not provided here. Regardless of the method, the tolerances obtained from different sources for the same cloud resource under a certain stability problem type can be comprehensively considered, thereby more reasonably determining the target tolerance for the cloud resource as the basis for generating stability description information. This effectively ensures the rationality and accuracy of the stability description information.

[0173] In summary, this embodiment provides an optional implementation for generating stability description information for cloud resources based on the acquired tolerance levels. Furthermore, it proposes that the service optimization system can also assess the tolerance levels of cloud resources and participate in the tolerance merging process as a source of information. This enriches the sources of tolerance information at the cloud resource level, enabling a more multi-dimensional assessment of cloud resources and further improving the rationality and accuracy of the stability description information generated for cloud resources.

[0174] In the above or below embodiments, the stability description information may include information in other dimensions besides tolerance.

[0175] This embodiment proposes that, for any cloud resource to be described, the reasons for the cloud resource's tolerance to stability problems existing in the cloud computing system can be obtained; and the reasons for tolerance can be added to the stability description information corresponding to the cloud resource.

[0176] The tolerance reason can be used to characterize why a cloud resource exhibits a certain level of tolerance for a particular stability problem type, as recorded in the stability description information of this embodiment. For example, if a cloud resource has a high tolerance for downtime issues, the reason for this tolerance is that the sub-account to which the cloud resource belongs is essentially unaware of service interruptions and performance degradation. Therefore, the tolerance reason for the cloud resource under downtime issues can be determined as: the sub-account is unaware.

[0177] The above-mentioned reasons for tolerance are merely exemplary, and this embodiment is not limited thereto; no further examples will be given here.

[0178] Of course, in the case mentioned in the above embodiments where the service optimization system assesses the tolerance level for cloud resources, this embodiment also supports assessing the associated tolerance reasons simultaneously with the tolerance level assessment. This embodiment does not limit the implementation method of assessing tolerance reasons. Optionally, a mapping rule between feedback data and tolerance reasons can be configured in the service optimization system. This way, while mapping tolerance levels based on feedback data, tolerance reasons can also be mapped based on the same feedback data. For example, complaint reasons, work order initiation reasons, etc., in the feedback data used when mapping tolerance levels can be mapped as tolerance reasons, etc. The implementation method of assessing tolerance reasons in the service optimization system is not limited here, nor are further examples provided.

[0179] In summary, this embodiment allows for the association of tolerance reasons with stability description information. This provides more decision-making support during subsequent service optimization, enabling the optimization process to fully consider the specific tolerance reasons corresponding to cloud resources. This allows for more targeted efforts to avoid related stability issues by specifically addressing these tolerance reasons, resulting in better service optimization outcomes.

[0180] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, 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. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish tolerance levels from different sources and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0181] Figure 4 This is a schematic diagram illustrating an exemplary application scenario provided for an exemplary embodiment of this application. The following is combined with... Figure 4 The application scenarios shown illustrate the service optimization method provided in this application. Figure 4 In the provided exemplary application scenario, taking user A as an example, the cloud computing system allocates numerous cloud resources to user A.

[0182] refer to Figure 4 The general process of a service optimization plan may include:

[0183] 1. Users can continuously provide usage feedback data to data sources such as the risk management system; the data source can assess the tolerance level for the portion of cloud resources allocated to user A based on the usage feedback data.

[0184] 2. Data sources can store the evaluation results in the database according to the association format of cloud resource filtering conditions-tolerance for future use.

[0185] 3. The user-side cloud management system can independently create stability description tags for some of user A's cloud resources, and bind the created stability description tags to the corresponding cloud resources by calling the tag management system.

[0186] 4. The scheduled task system can periodically send stability description requests for user A to the service optimization system. In response to the stability description requests, the service optimization system can retrieve relevant stability reference data (cloud resource filtering conditions and tolerance of associated storage) stored for user A from the database.

[0187] 5. The service optimization system can filter out a set of cloud resources that meet the cloud resource filtering criteria from the cloud resources allocated to user A; and associate the tolerance corresponding to the cloud resource filtering criteria with each cloud resource pointed to by the cloud resource filtering criteria.

[0188] 6. The service optimization system can query the tag management system. If one or more cloud resources selected in step 5 have been bound with stability description tags in step 3, then the stability description tags bound to these cloud resources will be converted into tolerance.

[0189] 7. The service optimization system takes cloud resources as the unit, merges the tolerance obtained from the database and the tolerance converted based on the bound stability description tags, and obtains the tolerance corresponding to the cloud resources.

[0190] 8. Based on the tolerance determined for cloud resources in step 7, create stability description tags for each cloud resource.

[0191] 9. Optimize system call tags and associate them with cloud resources to bind stability description tags.

[0192] 10. When optimizing services for user A in a cloud computing system, the stability description tags bound to user A's cloud resources can be used as a basis for decision-making. This will help the cloud resources avoid stability issues with low tolerance, thereby improving the service optimization effect for user A.

[0193] As described in the application scenario, the service optimization solution provided in this embodiment offers a cloud resource-level, user-evaluable, highly accurate, and systematic stability description tagging capability. This provides a decision-making basis for service optimization aspects such as service stability construction, operation and maintenance strategy optimization, and refined cloud resource configuration as perceived by the user. Moreover, it can abstract and map complex and invisible user characteristics such as user-side computing scenarios, computing scale, deployment form, system architecture, and cloud resource importance into simple, easy-to-use, and visible stability description tags, which is of great significance for improving the service stability perceived by the user.

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

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

[0196] For any cloud resource to be described, obtain the tolerance of the cloud resource to stability issues existing in the cloud computing system;

[0197] Based on the tolerance level, stability description information is generated for the cloud resources;

[0198] Bind the stability description information to the cloud resource;

[0199] The stability description information is used as a basis for decision-making when optimizing services in the cloud computing system.

[0200] In an optional embodiment, when the processor 51 generates stability description information for the cloud resource based on the tolerance, it may specifically be used to:

[0201] Based on the tolerance level, a stability description tag is created for the cloud resource as the stability description information;

[0202] When the stability description information is bound to the cloud resource, it can be specifically used for:

[0203] The tag management system is invoked to bind the stability description tag as a cloud resource tag to the cloud resource.

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

[0205] In response to receiving a stability description request, the cloud resource filtering conditions pre-configured for the stability description request are retrieved from a preset database;

[0206] From the cloud resources provided by the cloud computing system, cloud resources that meet the cloud resource filtering criteria are selected as the cloud resources to be described.

[0207] In an optional embodiment, when the processor 51 filters cloud resources that meet the cloud resource filtering criteria from the cloud resources provided by the cloud computing system as the desired cloud resources, it may specifically be used to:

[0208] If the cloud resource filtering criteria include a cloud resource list, then the cloud resources indicated in the cloud resource list are filtered from the cloud resources provided by the cloud computing system as the cloud resources to be described.

[0209] If the cloud resource filtering criteria include cloud resource name format, then cloud resources whose names conform to the cloud resource name format are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described.

[0210] If the cloud resource filtering criteria include sub-accounts, then cloud resources belonging to the sub-accounts are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described.

[0211] If the cloud resource filtering criteria include cloud resource tags, then cloud resources bound to the cloud resource tags are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described.

[0212] The cloud resource tags include basic tags and / or custom tags.

[0213] In an optional embodiment, when the processor 51 obtains the tolerance of any cloud resource to stability issues existing in the cloud computing system for any cloud resource to be described, it may specifically be used to:

[0214] From the preset database, obtain the tolerance level of the storage associated with the cloud resource filtering conditions to obtain the first tolerance level corresponding to any cloud resource to be described.

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

[0216] For any cloud resource to be described, query whether the cloud resource has already been bound with stability description information created by the cloud management system, which is used to manage the cloud resource;

[0217] If so, the stability description information already bound to the cloud resource is converted into a tolerance level for stability issues existing in the cloud computing system, so as to obtain a second tolerance level corresponding to the cloud resource.

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

[0219] In response to receiving a tolerance assessment request, assess a third tolerance level for stability issues present in the cloud computing system for the target cloud resource indicated in the tolerance assessment request;

[0220] The target cloud resource is determined to be the cloud resource to be described.

[0221] In an optional embodiment, when the processor 51 generates stability description information for the cloud resource based on the tolerance, it may specifically be used to:

[0222] For the cloud resource, if multiple tolerances are obtained under any stability problem type, then based on the multiple tolerances, the target tolerance corresponding to the cloud resource under the stability problem type is determined;

[0223] Based on the target tolerance, the stability description information is generated for the cloud resources.

[0224] In an optional embodiment, when determining the target tolerance of the cloud resource under the stability problem type based on the plurality of tolerances, the processor 51 may specifically be used to:

[0225] If the plurality of tolerances includes the first tolerance and the second tolerance, then a fourth tolerance is determined for the cloud resource based on the first tolerance and the second tolerance;

[0226] The fourth tolerance level is determined as the target tolerance level.

[0227] In an optional embodiment, when determining the target tolerance of the cloud resource under the stability problem type based on the plurality of tolerances, the processor 51 may specifically be used to:

[0228] If the plurality of tolerances does not include the second tolerance, but includes a plurality of the first tolerances, then based on the priority order among the different cloud resource filtering conditions used when obtaining the plurality of first tolerances, the first tolerance obtained under the cloud resource filtering condition with the highest priority is selected as the target tolerance.

[0229] In one optional embodiment, the cloud resource filtering criteria include a cloud resource list, cloud resource name format, sub-account, and cloud resource tags; the priority order of different cloud resource filtering criteria from highest to lowest includes cloud resource tags, cloud resource name format, cloud resource list, and sub-account.

[0230] In an optional embodiment, when determining the target tolerance of the cloud resource under the stability problem type based on the plurality of tolerances, the processor 51 may specifically be used to:

[0231] If the first tolerance and the second tolerance are not included in the plurality of tolerances, but the third tolerance is included, then the third tolerance is selected as the target tolerance.

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

[0233] To determine the reasons why the cloud resources tolerate stability issues present in the cloud computing system;

[0234] Add the reasons for the tolerance to the stability description information.

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

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

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

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

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

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

[0241] The above Figure 5 The 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.

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

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

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

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

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

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

[0248] 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: For any cloud resource to be described, obtain the tolerance of the cloud resource to stability issues existing in the cloud computing system; Based on the tolerance level, stability description information is generated for the cloud resources; Bind the stability description information to the cloud resource; The stability description information is used as a basis for decision-making when optimizing services in the cloud computing system.

2. The method according to claim 1, characterized in that, Based on the tolerance level, stability description information is generated for the cloud resources, including: Based on the tolerance level, a stability description tag is created for the cloud resource as the stability description information; Binding the stability description information to the cloud resource includes: The tag management system is invoked to bind the stability description tag as a cloud resource tag to the cloud resource.

3. The method according to claim 1 or 2, characterized in that, Also includes: In response to receiving a stability description request, the cloud resource filtering conditions pre-configured for the stability description request are retrieved from a preset database; From the cloud resources provided by the cloud computing system, cloud resources that meet the cloud resource filtering criteria are selected as the cloud resources to be described.

4. The method according to claim 3, characterized in that, From the cloud resources provided by the cloud computing system, cloud resources that meet the cloud resource filtering criteria are selected as the cloud resources to be described, including: If the cloud resource filtering criteria include a cloud resource list, then the cloud resources indicated in the cloud resource list are filtered from the cloud resources provided by the cloud computing system as the cloud resources to be described. If the cloud resource filtering criteria include cloud resource name format, then cloud resources whose names conform to the cloud resource name format are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described. If the cloud resource filtering criteria include sub-accounts, then cloud resources belonging to the sub-accounts are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described. If the cloud resource filtering criteria include cloud resource tags, then cloud resources bound to the cloud resource tags are filtered from the cloud resources provided by the cloud computing system and used as the cloud resources to be described. The cloud resource tags include basic tags and / or custom tags.

5. The method according to claim 3, characterized in that, For any cloud resource described herein, obtain the tolerance of the cloud resource to stability issues existing in the cloud computing system, including: From the preset database, obtain the tolerance level of the storage associated with the cloud resource filtering conditions to obtain the first tolerance level corresponding to any cloud resource to be described.

6. The method according to claim 5, characterized in that, Also includes: For any cloud resource to be described, query whether the cloud resource has already been bound with stability description information created by the cloud management system, which is used to manage the cloud resource; If so, the stability description information already bound to the cloud resource is converted into a tolerance level for stability issues existing in the cloud computing system, so as to obtain a second tolerance level corresponding to the cloud resource.

7. The method according to any one of claims 1-2 or 4-6, characterized in that, Also includes: In response to receiving a tolerance assessment request, assess a third tolerance level for stability issues present in the cloud computing system for the target cloud resource indicated in the tolerance assessment request; The target cloud resource is determined to be the cloud resource to be described.

8. The method according to claim 7, characterized in that, Based on the tolerance level, stability description information is generated for the cloud resources, including: For the cloud resource, if multiple tolerances are obtained under any stability problem type, then based on the multiple tolerances, the target tolerance corresponding to the cloud resource under the stability problem type is determined; Based on the target tolerance, the stability description information is generated for the cloud resources.

9. The method according to claim 8, characterized in that, Based on the multiple tolerance levels, the target tolerance level for the cloud resource under the type of stability problem is determined, including: If the plurality of tolerances includes the first tolerance and the second tolerance, then a fourth tolerance is determined for the cloud resource based on the first tolerance and the second tolerance; The fourth tolerance level is determined as the target tolerance level.

10. The method according to claim 8, characterized in that, Based on the multiple tolerance levels, the target tolerance level for the cloud resource under the type of stability problem is determined, including: If the second tolerance is not included among the plurality of tolerances, but the first tolerance is included, then based on the priority order among the different cloud resource screening conditions used when obtaining the plurality of first tolerances, the first tolerance obtained under the cloud resource screening condition with the highest priority is selected as the target tolerance.

11. The method according to claim 10, characterized in that, The cloud resource filtering criteria include a cloud resource list, cloud resource name format, sub-account, and cloud resource tags; the priority order of different cloud resource filtering criteria from highest to lowest is cloud resource tags, cloud resource name format, cloud resource list, and sub-account.

12. The method according to claim 8, characterized in that, Based on the multiple tolerance levels, the target tolerance level for the cloud resource under the type of stability problem is determined, including: If the first tolerance and the second tolerance are not included in the plurality of tolerances, but the third tolerance is included, then the third tolerance is selected as the target tolerance.

13. The method according to any one of claims 1-2, 4-6, or 8-12, characterized in that, Also includes: To determine the reasons why the cloud resources tolerate stability issues present in the cloud computing system; Add the reasons for the tolerance to the stability description information.

14. A service optimization system, characterized in that, include: Data collection layer, data processing layer, and annotation layer; The data collection layer is used to obtain the tolerance of any cloud resource to stability issues existing in the cloud computing system for any cloud resource to be described. The data processing layer generates stability description information for the cloud resources based on the tolerance level. The annotation layer is used to bind the stability description information to the cloud resource; The stability description information is used as a basis for decision-making when optimizing services in the cloud computing system.

15. 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-13.

16. 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-13.

17. 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-13.

Images