Evaluation method for stability risk, program product, electronic device, and storage medium

Abstract

The invention provides a stability risk evaluation method, a program product, electronic equipment and a storage medium, and the method comprises the steps: determining a target inductive abnormal event generated by target equipment, the target inductive abnormal event being an abnormal event perceived by a user; and calculating a risk perception degree corresponding to the target device according to the type of the sensitive abnormal event, wherein the risk perception degree is used for representing a perception degree of a user on a stability risk of the target device.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a stability risk evaluation method, program product, electronic device, and storage medium. Background Art

[0002] With the rapid development of the internet and advancements in information technology, the demand for more efficient, flexible, and scalable computing resources continues to grow, leading to the emergence of devices such as cloud servers. These devices may experience stability risks due to hardware failures, device aging, software defects, or network anomalies. These risks can be perceived by users and affect user engagement and user experience for the device and, ultimately, the cloud computing platform.

[0003] In related technologies, user feedback on device usage is typically collected through user interviews or questionnaires. This feedback, combined with trends in indicators such as the device's work order rate, purchase conversion rate, and depreciation rate, can be used to determine whether the device presents significant stability risks perceived by users. Based on this feedback, appropriate mitigation measures are then implemented to mitigate user perceptions of stability risks. However, interviews and questionnaires rely heavily on user subjective experiences, and user coverage cannot be guaranteed, leading to biased user feedback. Summary of the Invention

[0004] In view of this, this specification provides a stability risk evaluation method, program product, electronic device and storage medium to address the deficiencies in the related art.

[0005] Specifically, this specification is implemented through the following technical solutions:

[0006] According to a first aspect of an embodiment of this specification, a method for evaluating stability risk is provided, comprising:

[0007] Determining a target perceptible abnormal event occurring on the target device, where the target perceptible abnormal event is an abnormal event perceptible to a user;

[0008] The risk perception degree corresponding to the target device is calculated according to the type of the perceived abnormal event, and the risk perception degree is used to represent the user's perception degree of the stability risk of the target device.

[0009] According to a second aspect of the embodiments of this specification, a method for evaluating stability risk is provided, comprising:

[0010] For a target cloud server owned by a user on a cloud computing platform, determining a target perceived abnormal event that occurs on the target cloud server, where the target perceived abnormal event is an abnormal event that occurs on the target cloud server and is perceived by the user;

[0011] The risk perception degree corresponding to the target cloud server is calculated according to the type of the perceived abnormal event, where the risk perception degree is used to represent the user's perception degree of the stability risk of the target cloud server.

[0012] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program / instruction is stored. When the program / instruction is executed by a processor, the steps of the method described in the first aspect or the second aspect are implemented.

[0013] According to the fourth aspect of the embodiments of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect or the second aspect are implemented.

[0014] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect or the second aspect.

[0015] In the technical solution provided in this specification, by determining the target perceived abnormal event and the corresponding type, the risk perception corresponding to the target device can be determined. Among them, this specification takes the user's experience of perceived abnormal events as the starting point, quantifies and summarizes the user's perception level of different types of perceived abnormal events, so that the perception level is objective and comprehensive.

[0016] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0018] Figure 1 This is a schematic diagram of the architecture of a stability risk assessment system shown in an exemplary embodiment of this specification;

[0019] Figure 2 This is a flow chart of a stability risk evaluation method shown in an exemplary embodiment of this specification;

[0020] Figure 3is a schematic diagram of a stability risk evaluation method shown in an exemplary embodiment of this specification;

[0021] Figure 4 is a flow chart of another stability risk evaluation method shown in an exemplary embodiment of this specification;

[0022] Figure 5 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification;

[0023] Figure 6 This is a schematic structural diagram of a stability risk assessment device shown in an exemplary embodiment of this specification;

[0024] Figure 7 It is a structural diagram of another stability risk evaluation device shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0025] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of this specification.

[0026] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments. It should be understood that although this specification may use terms such as first, second, and third to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish between information of the same type. For example, first information may also be referred to as second information, and similarly, second information may be referred to as first information, without departing from the scope of this specification. Depending on the context, the term "if" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0027] 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, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0028] Figure 1 This is a schematic diagram of the architecture of a stability risk evaluation system shown in an exemplary embodiment of this specification. Figure 1 As shown, the system may include a server 11, a network 12, several electronic devices 13 (eg, a PC (Personal Computer), a server), and the like.

[0029] Server 11 may be an object requiring stability risk assessment. Server 11 may be a physical server containing a standalone host, or a virtual server hosted by a host cluster. Server 11 may also be equipped with a cloud computing platform that provides cloud servers for users. Each cloud server can independently run its own operating system and applications through a corresponding cloud server instance. When a stability risk is detected on any cloud server, the operating system and / or application in the corresponding instance of the cloud server will experience anomalies, which will be perceived by users at varying levels of sensitivity.

[0030] In the technical solutions of one or more embodiments of this specification, the server 11 may be deployed with relevant functions for implementing the stability risk evaluation method of this embodiment. For example, a program for evaluating stability risk may be run to evaluate the stability risk of the server 11 itself.

[0031] Furthermore, in the technical solutions of one or more embodiments of this specification, the relevant programs implementing the stability risk assessment method of this embodiment may also be deployed on electronic device 13. Electronic device 13 can then interact with server 11 to obtain relevant data on server 13 for evaluating stability risk, thereby enabling the evaluation of the stability risk of server 11 to be performed based on the relevant data and through the relevant programs. The interaction between electronic device 13 and server 11 may specifically rely on data transmission between electronic device 13 and server 11. This data transmission may be achieved via network 12, which may include various types of wired or wireless networks, and this specification does not limit this.

[0032] Figure 2 FIG. 1 is a flow chart of a stability risk assessment method according to an exemplary embodiment of the present specification. The method specifically includes the following steps:

[0033] Step S202: determining a target perceptible abnormal event occurring on the target device, where the target perceptible abnormal event is an abnormal event perceptible to a user.

[0034] A target device is an electronic device used to provide computing resources to users to implement corresponding logical functions. For example, a cloud computing platform is used to provide corresponding cloud computing resources for users to deploy corresponding cloud servers (hereinafter referred to as target cloud servers). The deployment of cloud servers may vary depending on the service scenarios of the cloud computing platform. For example, when the cloud computing platform corresponds to a public cloud scenario, the cloud computing platform can be managed by a third-party service provider, and users can rent the cloud computing resources used by the cloud computing platform to build the target cloud server they own. For another example, when the cloud computing platform corresponds to a private cloud scenario, the target cloud server can be directly owned and managed by the user and directly deployed on the cloud computing platform. This is particularly suitable for situations that are more sensitive to data privacy and security. Of course, even if the target device is not a cloud server in the cloud computing platform, the target device can be maintained by the corresponding device manager and provided to the user. The device manager can be a third-party service provider or the user himself.

[0035] The definition of a target-perceived abnormal event depends on whether the target device is perceived by the user. Taking a cloud server as an example, assuming that the cloud computing platform can determine the abnormal event that has occurred on the target cloud server provided to the user, then when the abnormal event affects the operating status or function implementation on the target cloud server instance, it can be perceived by the user. At this time, the abnormal event can be called a perceived abnormal event. On the contrary, when the abnormal event does not affect the operating status or function implementation on the target cloud server instance, the user will not be able to perceive and determine that an abnormal event has occurred on the target cloud server. At this time, the abnormal event can be called an unperceived abnormal event. Specifically, the target-perceived abnormal event can be obtained in at least one of the following ways:

[0036] The first method is to actively monitor the operating status of the target device to obtain the first type of perceived abnormal events. The target devices can be divided according to different usage scenarios. For example, for a cloud computing platform, the target device to be monitored can be the target cloud server and / or its physical server. For another example, for a local computing platform, the target device to be monitored can be the corresponding physical server. Of course, the operating status includes but is not limited to the application operating parameters, processor utilization, memory occupancy, and network data transmission rate of the instance running on the target cloud server and / or its physical server. When any operating status does not match the expected expected status, it can be determined that a first type of perceived abnormal event has occurred.

[0037] It should be noted that the degree of match between the aforementioned operating state and the aforementioned expected state can directly or indirectly reflect the severity of the first category of perceived anomaly events. For example, a cloud computing platform can handle first category perceived anomaly events of varying severity differently based on pre-set judgment policies. For example, assuming the target cloud server's preset memory threshold is 80%, a user notification may be issued if the memory occupancy rate remains above 95% for at least three minutes. Alternatively, if the memory occupancy rate exceeds 80% for no more than 30 seconds but remains below 90%, no user notification may be issued, although the user may still perceive the first category of perceived anomaly events to a lesser extent through the actual usage of instances running on the target cloud server. In short, actions similar to the aforementioned notifications essentially fall under the aforementioned first category of perceived anomaly events.

[0038] The second method is to receive feedback from the operation and maintenance party on the second type of perceived abnormal events, which are generated by the above-mentioned operation and maintenance party during the operation and maintenance process of the above-mentioned target device. Among them, the operation and maintenance party is responsible for helping users with operation and maintenance management. Taking data migration, a common operation and maintenance method in cloud computing platforms, as an example, hot migration or cold migration operation and maintenance methods can be used to migrate the instance resources running on the user's target cloud server from the risky physical server to the normal physical server in advance, thereby avoiding the risk of the target cloud server being unavailable. Of course, this risk may also be caused by the first type of perceived abnormal events. However, when the above-mentioned instance is at peak usage, the load is too high, the inventory resources are missing, or the underlying vulnerability of the target cloud server is triggered, the above-mentioned hot migration may fail to execute. This failure can be used to determine that the second type of perceived abnormal event has occurred.

[0039] It should be noted that the main difference between the above-mentioned hot migration and cold migration is that the target cloud server does not need to be shut down during hot migration, but needs to be shut down during cold migration, which may cause functional interruption on the corresponding instance. Therefore, before cold migration, the operation and maintenance party usually needs to ask the user and obtain permission by sending a notification. Behaviors similar to the above-mentioned notifications essentially also belong to the second type of perceived abnormal events mentioned above.

[0040] The third method is to receive a user-triggered third-category perceptible abnormal event, which is triggered by a user-submitted complaint ticket. If a user is dissatisfied with the impact and losses caused by a perceived first-category perceptible abnormal event and / or a perceived second-category perceptible abnormal event, they can proactively submit a complaint ticket through the target device's designated complaint channel, such as the cloud computing platform to which the cloud server belongs. Upon receiving the complaint ticket, the cloud computing platform can determine that a third-category perceptible abnormal event has occurred.

[0041] Step S204 : calculating the risk perception level corresponding to the target device according to the type of the perceived abnormal event, where the risk perception level is used to represent the user's perception of the stability risk of the target device.

[0042] By determining the type of the target perceived abnormal event, the risk perception corresponding to the target device can be determined based on the type. The risk perception can be used to evaluate the user's perception of the stability risk of the target cloud server. The higher the risk perception, the higher the user's perception of the stability risk of the target cloud server. Therefore, the user is more likely to feel anxious about the stability risk of the target cloud server, which in turn damages user stickiness and user experience.

[0043] Specifically, the risk perception level corresponding to the target perceived abnormal event type can be determined by pre-defined correspondences between the type of perceived abnormal event and the risk perception level. This has the advantage of being simple and easy to understand in setting the risk perception level. Of course, for target devices in complex scenarios, the calculated risk perception level is often affected by factors other than the event type, and the original correspondence will result in the risk perception level being constrained by the total number of perceived abnormal event types. This specification provides another approach to this problem, namely, introducing a calculable perceived factor between the type of perceived abnormal event and the risk perception level.

[0044] In one embodiment, a target perceptible factor corresponding to a target perceptible abnormal event can be determined based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor, and the risk perception corresponding to the target device can be calculated based on the target perceptible factor; wherein the perceptible factor is related to the user's degree of perception of the corresponding type of perceptible abnormal event. Taking the above-mentioned cloud computing platform as an example, after obtaining a target perceptible abnormal event, the cloud computing platform can determine the corresponding target perceptible factor based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor. wherein the correspondence can be stored locally on the cloud computing platform or in a non-volatile storage device corresponding to another network address, and this specification does not limit this.

[0045] The types of the above-mentioned target-perceived abnormal events can be classified into any of the following:

[0046] Unavailability event: The target device is unavailable. For example, the physical server to which the target CVM belongs is down, or the instance running on the target CVM is stuck or crashes abnormally, causing the operating system and applications deployed by users on the target CVM to be interrupted.

[0047] Operation failure event: An operation failed on the target device. As mentioned above, this operation could be the failure of the operator to automatically perform a hot migration of the target cloud server.

[0048] Instance damage events: This refers to performance fluctuations in the instance running on the target device, which can lead to interruptions in the operating system and applications deployed on the target device. This type of target-perceived abnormal event can be differentiated based on the instance damage scenario, such as whether the instance is damaged during normal operation or during a hot migration.

[0049] Abnormal notification event: refers to the operation of the target device or the preset notification push device sending a notification to the user in the above-mentioned first type of perceived abnormal event or second type of perceived abnormal event.

[0050] User complaint event: This refers to a user proactively sending a complaint ticket regarding the target device to the target device's complaint channel.

[0051] Each of the above types can be further divided into specific types of abnormal events, such as those shown in Table 1 below, which will not be described in detail in this manual.

[0052] Different target-sensed abnormal events can be combined. For example, the above-mentioned abnormal notification event can be combined with an unavailability event, an operation and maintenance failure event, or an instance damage event to be described as a whole event.

[0053] At the same time, different target-sensed abnormal events can affect each other. For example, when an instance running on a target cloud server is damaged, it is often accompanied by instance lag or even crash. This specification does not limit this.

[0054] In addition, different types of target sensed abnormal events can be marked with corresponding event identifiers, so that after the target device determines the target sensed abnormal event, it can identify the corresponding event type according to the event identifier and further determine the sensed factor below.

[0055] The following combination Figure 3 ,In the case that the target device is a cloud server in the cloud computing platform, the ,methods for determining the abnormal events sensed by each type of target are introduced ,in a modular manner, such as Figure 3 As mentioned above, the following modules are included in the diagram:

[0056] Downtime determination module 301: This module can determine the operating status of the physical server by querying the physical server status database. When it is found that the physical server has been down, a corresponding abnormality notification can be sent to the user.

[0057] Instance lag determination module 302: This module can determine the operating status of the physical server and the operating status of the cloud server instance by querying the physical server status database and the cloud server instance status database. When it is found that one or more operating states are abnormal, such as abnormal memory usage of the physical server, increased network latency, etc., it can be determined that the cloud server instance is lag.

[0058] Instance abnormality determination module 303: This module can determine whether the instance system image has an abnormality or the instance crashes during the migration process by querying the cloud server instance status database. If the judgment result is yes, the user can be notified.

[0059] Performance impairment determination module 304: This module can determine whether the performance of the instance fluctuates during operation by querying the cloud server instance status database. When it is detected that the jitter lasts for a long time or has a large impact, the user can be notified.

[0060] Migration damage determination module 305: This module can determine whether the instance has performance anomalies or jitters during the hot migration process by querying the cloud server instance status database. If the judgment result is yes and the damage is higher than the preset damage threshold, the user can be notified.

[0061] Automatic hot migration failure determination module 306: The operation and maintenance platform corresponding to this module can query the operation and maintenance status database to determine that the above-mentioned physical server may be at risk of downtime, and then hot migrate the instance running on the target cloud server. If the automatic hot migration failure is detected, a cold migration notification will be sent to the customer.

[0062] Complaint ticket classification module 307: This module can filter out complaint tickets related to unavailability events, instance damage events, and operation and maintenance failure events from customer tickets received from the cloud computing platform through the user ticket database to determine user complaint events.

[0063] As mentioned above, the notification sending behaviors involved in the above multiple modules can be regarded as separate abnormal notification events, or as sub-events in the overall event obtained by combining them with unavailability events, operation and maintenance failure events, or instance damage events.

[0064] For the specific values ​​of the above-mentioned perceptible factors, this specification can be associated and determined based on the user's perception of the corresponding type of perceptible abnormal events. Taking Table 1 as an example, Table 1 is a table of the correspondence between the types of perceptible abnormal events and perceptible factors:

[0065] Table 1

[0066]

[0067]

[0068] Those skilled in the art will understand that the perceived factors in Table 1 are positively correlated with the user's level of perception of the corresponding type of perceived abnormal event, i.e., the higher the level of perception, the higher the perceived factor. This specification can also set the perceived factor to be negatively correlated with the user's level of perception of the corresponding type of perceived abnormal event, i.e., the higher the level of perception, the lower the perceived factor. In this case, the risk perception below will also be negatively correlated with the user's level of perception of the stability risk of the target cloud server. To avoid confusion in the description, the following will uniformly assume that the perceived factors are positively correlated with the user's level of perception of the corresponding type of perceived abnormal event.

[0069] The perceived factors corresponding to different perceived abnormal events have relationships in terms of size and ratio. Among them, the user sending a complaint ticket data corresponding to sequence number 1 is a user complaint event. Considering that sending a complaint ticket is an active behavior of the user, it means that the user has been seriously disturbed. Therefore, compared with other perceived abnormal events, it has a stronger perception level. The unexpected downtime and abnormal crash of the instance corresponding to sequence numbers 2 and 3 are unavailable events, and both will inevitably lead to the unavailability of the cloud server. Therefore, the perceived factor size is second only to the user complaint event. The events corresponding to sequence numbers 4-7 are combined events of operation and maintenance operation failure events and abnormal notification events. They are subdivided according to the response time of the abnormal notification event and the migration result. Among them, the first time range is closer to the sending time point of the cold migration notification than the second time range. For example, the first time range is after the cold migration notification. The first time range is 0 to 4 hours, and the second time range is 4 to 48 hours after the cold migration notification. This means that the shorter the time after receiving the cold migration notification, the higher the perception level. Secondly, if the cloud server unavailability problem does not occur after the cold migration notification, the user's perception level is relatively low. In this case, the case of responding to the cold migration notification within the preset response time range has a higher perception level than the case of not responding. The preset response time range can be 0 to 48 hours after receiving the cold migration notification. As for the damage of the instance corresponding to sequence number 8, which is an instance damage event, and the lag of the instance corresponding to sequence number 9, which is an unavailability event, since the negative impact of the two on the instances running on the cloud server is relatively small, the corresponding perception factors are relatively low.

[0070] The above shows the relationship between the perceived factors for different perceived abnormal event types in terms of size. The relationship in terms of ratio can be set based on actual scenarios. For example, if users file an average of two complaint tickets for every three unexpected downtimes experienced by a cloud server, this means that users perceive an average of 1.5 perceived disruptions from unexpected downtimes, which is sufficient to drive them to proactively file a targeted complaint ticket to express their dissatisfaction with these perceived disruptions. Therefore, the ratio of the perceived factors for "users filing complaint tickets" to "unexpected instance downtime" can be set to 3:2. Similarly, the perceived factors for other event types can be calculated. This manual will not elaborate on this further.

[0071] After the target sensitive factor is determined, the risk perception level corresponding to the target cloud server may be calculated based on the target sensitive factor.

[0072] The calculation of the above risk perception needs to take into account the number of abnormal events perceived by the target.

[0073] In one embodiment, if there is only one type of target perceived abnormal event, the product of its corresponding perceived factor and the scale parameter of the target cloud server can be directly used as the risk perception. The scale parameter of the target cloud server can be information such as the number of virtual processor cores, memory size, or bandwidth size of the cloud server. For ease of explanation, the number of virtual processor cores vcpu_count is uniformly used as the scale parameter below, and the perceived factor corresponding to the target perceived abnormal event is α. The calculation formula for risk perception is as follows:

[0074] Risk Perception = vcpu_count * α (Formula 1)

[0075] For example, if a user rents a target cloud server with 8 virtual processor cores and only one instance of the target cloud server is damaged, then the result table 1 can determine that the risk perception level of the target cloud server is 8*20=160.

[0076] In another embodiment, there are multiple types of target sensed abnormal events. The maximum sensed factor can be determined from the sensed factors corresponding to the multiple abnormal events, and the product of the maximum sensed factor and the scale parameter of the target cloud server is used as the risk perception. As mentioned above, there is a causal relationship between multiple target sensed abnormal events, and they often appear together. If the causal relationship of each of the multiple target sensed abnormal events is taken into account in the calculation process of risk perception, the risk perception will be too large to cause the result to be distorted. Therefore, the target device can select the maximum sensed factor from the n sensed factors, rather than all or part of the sensed factors, to ensure the accuracy of risk perception. The calculation formula of risk perception is as follows:

[0077] Risk perception = vcpu_count*max(α1, α2, ..., αn) (Formula 2)

[0078] Furthermore, the direct calculation of risk perception in the above embodiment ignores the influence of other factors, such as the user and target device, on risk perception, which can cause the risk perception to deviate from the actual situation. This application introduces the concept of correction weights and improves the above formula into a weighted calculation, thereby meeting the need for accurate risk perception in complex scenarios.

[0079] In one embodiment, a corresponding correction weight can be determined for risk perception. Specifically, the target device can determine the above correction weight based on the user's attribute characteristics, such as the level of the user's account registered in the target device and the user's enterprise, the attribute characteristics of the target device, such as the server model and the length of time it has been working, the instance characteristics of the instance running on the target device, such as the scale of the cloud server and the type of service selected by the user when using the cloud server, and / or the event characteristics of the target perceived abnormal event to which the target device is subjected, such as the frequency of the event, the length of time since the last occurrence, and the duration of the impact of this event, and then the risk perception is corrected according to the determined correction weight. Among them, the correction weight characterizes the degree of influence of the above-mentioned other aspects on the risk perception, and therefore can be used to correct the risk perception obtained by calculating the perceived factor, thereby ensuring the accuracy of the risk perception to the greatest extent.

[0080] Assume that user A's cloud server on a cloud computing platform experiences a 6-hour downtime event, while user B's cloud server experiences a 1-hour downtime event. The risk perception corresponding to user A's cloud server is obviously higher than that of user B's cloud server. To reflect this, a corresponding correction weight can be determined based on a preset weighting strategy. For example, the correction weight for user A's cloud server is 1.6, and the correction weight for user B's cloud server is 1.1. The above-mentioned weighting strategy can be implemented based on, for example, the corresponding relationship between the correction weight and the duration of the downtime event, or based on a pre-trained machine learning model, and this application does not limit this.

[0081] The above-mentioned value correction process is to perform weighted calculation on the risk perception according to the determined correction weight, and replace the calculation result with the risk perception. The following explanation is given using a cloud server as an example.

[0082] For example, suppose a user rents ten cloud servers on a cloud computing platform, three of which are Model A and the remaining seven are Model B. Model A has higher performance and is suitable for handling the user's most important logical functions, so its corresponding correction weight is 1.2. Model B has lower performance and is suitable for handling less important logical functions, so its corresponding correction weight is 0.8. Therefore, the user's total risk perception of the ten cloud servers is [1.2 * (risk perception of the first Model A cloud server + risk perception of the second Model A cloud server + risk perception of the third Model A cloud server)] + [0.8 * (risk perception of the first Model B cloud server + risk perception of the second Model B cloud server + ... + risk perception of the seventh Model A cloud server)].

[0083] For example, if risk perception focuses on the actual duration of a target perceptible abnormal event affecting users, then the ratio of the total duration EventTimevm that the target cloud server is affected by the target perceptible abnormal event on that day to the total duration LifeTimevm that the target cloud server survives on that day can be used as the correction weight and combined with the original risk perception to perform correction. The formula for calculating risk perception is as follows:

[0084]

[0085] For example, if the risk perception does not consider the impact of different cloud server sizes, the denominator can be the divisor of the number of virtual processor cores WVcpu of the corresponding cloud server, which can be used as the correction weight and the original risk perception value for correction. The calculation formula for the above risk perception is as follows:

[0086]

[0087] In summary, the method of correcting the risk perception value through the above-mentioned correction weights can improve the flexibility in calculating the risk perception while ensuring the accuracy of the risk perception in different scenarios.

[0088] The timeliness of risk perception can be defined in this specification to ensure that the analysis results of risk perception can show a trend of change over time, and through trend analysis, the current stability risks can be discovered in time.

[0089] In one embodiment, the above-mentioned risk perception may have a corresponding valid time period. For example, for a target perceived abnormal event occurring on a certain day, the valid time period of the risk perception calculated by its perceived factor also corresponds to that day. Specifically, the target device may aggregate at least a portion of the risk perception generated by the calculation to obtain the trend of risk perception changing over time under a preset dimension for display and / or risk analysis; wherein, the above-mentioned risk perception may be statistically analyzed and presented in the form of daily, weekly, monthly, quarterly or annual lines in the display and / or risk analysis, so as to highlight the trend of time change. The above-mentioned preset dimensions may include: users, user groups, device models, instance types, and device scale. As mentioned above, the device scale includes but is not limited to the model and quantity of devices such as processors or memory. If there are no restrictions on the preset dimensions, the aggregation results can be regarded as the changing trend of the degree of perception of the stability risk of each target cloud server owned by all users in the cloud computing platform. Conversely, if specific restrictions are placed on the preset dimensions, user profiles can be determined based on the changing trend of the degree of perception of the stability risk of cloud servers by some users, or the changing trend of the degree to which some cloud servers are perceived by users as having stability risks can be analyzed, so as to take targeted stability governance measures for negative changing trends. For example, if the daily risk perception of user A shows an increasing trend, then the physical server to which the cloud server owned by user A belongs can be temporarily configured and upgraded, or directly replaced with other physical servers with higher performance and stability, thereby effectively reducing user A's perception of stability risks.

[0090] In fact, risk perception is difficult to indicate what kind of perceived abnormal events users mainly use to perceive the stability risk of the target cloud server. Therefore, this manual further classifies and counts perceived abnormal events to clarify what kind of perceived abnormal events users use to perceive the above stability risks, so as to facilitate efficient subsequent governance. Among them, the so-called classification refers to the division of perceived abnormal events according to the types of perceived abnormal events mentioned above.

[0091] In one embodiment, the cloud computing platform can classify and analyze the generated perceived abnormal events, and based on the obtained classification and statistical results, give priority to generating corresponding stability governance recommendations for perceived abnormal events that have governance needs. The so-called governance needs can be determined based on dimensions such as the number of events, the number of affected users, and the priority of events. The dimension of the number of events can directly reflect the perceived abnormal events that occur the most frequently, thereby facilitating the accurate positioning and maintenance of the target equipment by the maintenance party. For example, if the proportion of unavailable events caused by cloud server downtime is large, the cloud computing platform can determine the optimization direction of stability as downtime governance. For example, when the time points of a large number of abnormal notification events are too close to the time points of the operation and maintenance operation failure events, it can be determined that the notification lead time of the abnormal notification events is insufficient, and consideration can be given to optimizing the success rate of the operation and maintenance operations or increasing the above-mentioned notification lead time. The dimension of the number of affected users can be used to prevent the risk perception of a small number of users from interfering with the risk perception of the majority of other users when a large number of target devices owned by the same target experience an abnormal event. For example, there are 10 users on the cloud computing platform. Among them, the 20 cloud servers rented by the first user experience a downtime, and the instances of the two cloud servers rented by the second to tenth users are damaged. Although the cloud computing platform should optimize stability by managing downtime based on the number of events, it should prioritize managing instance damage based on the proportion of the affected people. For the dimension of event priority, it combines the priorities of different events or the various contents in the first preset dimension mentioned above. Taking the above 10 users as an example, assuming that the priority of the downtime event is 2 and the priority of other events is 1, then when a cloud server rented by 4 users respectively goes down and an instance of a cloud service rented by the remaining 6 users is damaged, it can be judged through the formula (4*2)>(6*1) that the downtime events with a smaller number of events and a smaller number of affected people have a higher event priority. Therefore, downtime governance is needed as a direction for stability optimization. In short, the characteristic of this dimension is that it can refine the determination strategy of stability governance recommendations to the greatest extent, thereby improving the accuracy of the determined stability governance recommendations.

[0092] Furthermore, the target device can generate a corresponding analysis report based on the above-mentioned classification statistical results for users to obtain and review regularly, and enable them to give personal governance suggestions based on the current analysis results. Of course, considering that the professional capabilities and report analysis capabilities of different users are different, the above-mentioned personal governance suggestions can only be used as auxiliary suggestions for reference by the device manager of the corresponding target device.

[0093] Figure 4FIG. 1 is a flow chart of another stability risk evaluation method according to an exemplary embodiment of the present specification, which specifically includes the following steps:

[0094] Step S402 : determining, for a target cloud server owned by a user on a cloud computing platform, a target-perceivable abnormal event occurring on the target cloud server, where the target-perceivable abnormal event is an abnormal event occurring on the target cloud server and being perceived by the user.

[0095] Step S404: Calculate the risk perception level corresponding to the target cloud server according to the type of the perceived abnormal event. The risk perception level is used to represent the user's perception of the stability risk of the target cloud server.

[0096] Optionally, determining a target-perceived abnormal event occurring on the target cloud server includes at least one of the following:

[0097] Actively monitor the operating status of the target cloud server and / or its physical servers to obtain a first type of perceptible abnormal event;

[0098] Receiving a second type of perceived abnormal event reported by an operation and maintenance party, where the second type of perceived abnormal event is generated by the operation and maintenance party during the operation and maintenance of the target cloud server and / or its physical server;

[0099] A third type of perceived abnormal event triggered by a user is received, where the third type of perceived abnormal event is triggered by a complaint work order submitted by the user.

[0100] Optionally, the type of the target sensed abnormal event is any of the following:

[0101] The target cloud server is unavailable, the instance running on the target cloud server is damaged, the operation and maintenance operation for the target cloud server fails, abnormal notification events and user complaint events.

[0102] Optionally, the calculating the risk perception level corresponding to the target cloud server according to the type of the perceived abnormal event includes:

[0103] Determining a target perceptible factor corresponding to the target perceptible abnormal event based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor; wherein the perceptible factor is related to the user's degree of perceptibility to the corresponding type of perceptible abnormal event;

[0104] The risk perception level corresponding to the cloud server is calculated according to the target perceived factor.

[0105] Optionally, calculating the risk perception level corresponding to the cloud server according to the target perceived factor includes:

[0106] In the case where there is only one type of target-perceived abnormal event, the product of its corresponding target-perceived factor and the scale parameter of the target cloud server is used as the risk perception;

[0107] In the case where there are multiple types of target felt abnormal events, a maximum felt factor is determined from the target felt factors corresponding to the multiple types of target felt abnormal events; and the product of the maximum felt factor and the scale parameter of the target cloud server is used as the risk perception.

[0108] Optionally, the above method further includes:

[0109] Determining corresponding correction weights based on the risk perception;

[0110] The risk perception is weightedly calculated according to the determined correction weight, and the calculation result is replaced with the risk perception.

[0111] Optionally, the risk perception has a corresponding valid time period; the method further includes:

[0112] Aggregating at least a portion of the risk perceptions generated on the cloud computing platform to obtain a trend of risk perceptions changing over time under a preset dimension for display and / or risk analysis;

[0113] Among them, the preset dimensions include: users, user groups, physical server models, instance types, and cloud server scales.

[0114] Optionally, the method further includes:

[0115] Classify and count the abnormal events that occur on the cloud computing platform;

[0116] Based on the obtained classification statistical results, corresponding stability governance recommendations are generated for perceived abnormal events that require governance.

[0117] Figure 5 This is a schematic structural diagram of an electronic device in an exemplary embodiment. Figure 5 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other required hardware. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a stability risk assessment device at the logical level. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0118] Corresponding to the aforementioned embodiment of the method for evaluating stability risk, this specification also provides an embodiment of an apparatus for evaluating stability risk.

[0119] Please refer to Figure 6 , Figure 6 It is a structural diagram of a stability risk evaluation device shown in an exemplary embodiment.

[0120] like Figure 6 As shown, in a software implementation, the device may include:

[0121] A device event determination unit 61 is configured to determine a target perceptible abnormal event occurring on a target device, wherein the target perceptible abnormal event is an abnormal event perceptible to a user;

[0122] The device sensitive factor determining unit 62 is configured to calculate the risk perception corresponding to the target device according to the type of the sensitive abnormal event, where the risk perception is used to represent the user's perception of the stability risk of the target device.

[0123] Optionally, the device event determining unit 61 is specifically configured to perform at least one of the following:

[0124] Actively monitoring the operating status of the target device to obtain a first type of sensed abnormal event;

[0125] receiving a second type of perceived abnormal event fed back by an operation and maintenance party, where the second type of perceived abnormal event is generated by the operation and maintenance party during the operation and maintenance of the target device;

[0126] A third type of perceived abnormal event triggered by a user is received, where the third type of perceived abnormal event is triggered by a complaint work order submitted by the user.

[0127] Optionally, the type of the target sensed abnormal event is any of the following:

[0128] The target device is unavailable, the instance running on the target device is damaged, the operation and maintenance operation for the target device fails, abnormal notification events and user complaint events.

[0129] Optionally, the device sensitive factor determining unit 62 is specifically configured to:

[0130] Determining a target perceptible factor corresponding to the target perceptible abnormal event based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor; wherein the perceptible factor is related to the user's degree of perceptibility to the corresponding type of perceptible abnormal event;

[0131] The risk perception level corresponding to the target device is calculated according to the target sensitive factor.

[0132] Optionally, the device sensitive factor determining unit 62 is specifically configured to:

[0133] In the case where there is only one type of target perceptible abnormal event, the product of its corresponding target perceptible factor and the scale parameter of the target device is used as the risk perception;

[0134] In the case where there are multiple types of target perceived abnormal events, the number of the abnormal events is multiple; a maximum perceived factor is determined from the perceived factors corresponding to the multiple abnormal events; and a product of the maximum perceived factor and a scale parameter of the target device is used as the risk perception.

[0135] Optionally, the device further includes:

[0136] a value correction unit, configured to determine a corresponding correction weight for the risk perception;

[0137] The risk perception is weightedly calculated according to the determined correction weight, and the calculation result is replaced with the risk perception.

[0138] Optionally, the risk perception has a corresponding valid time period; the device further includes:

[0139] a trend acquisition unit, configured to aggregate at least a portion of the risk perceptions generated on the target device to obtain a trend of risk perceptions changing over time under a preset dimension for display and / or risk analysis;

[0140] The preset dimensions include: user, user group, device model, instance type, and device scale.

[0141] Optionally, the device further includes:

[0142] An event classification and statistics unit, configured to classify and count the abnormal events that occur on the target device;

[0143] Based on the obtained classification statistical results, corresponding stability governance recommendations are generated for perceived abnormal events that require governance.

[0144] Please refer to Figure 7 , Figure 7 It is a structural diagram of another stability risk evaluation device shown in an exemplary embodiment.

[0145] like Figure 7 As shown, in a software implementation, the device may include:

[0146] The cloud server event determination unit 71 is used to determine a target perceived abnormal event that occurs on a target cloud server owned by a user on a cloud computing platform. The target perceived abnormal event is an abnormal event that occurs on the target cloud server and is perceived by the user.

[0147] The cloud server risk perception calculation unit 72 is used to calculate the risk perception corresponding to the target cloud server according to the type of the perceived abnormal event, and the risk perception is used to represent the user's perception of the stability risk of the target cloud server.

[0148] Optionally, the cloud server event determination unit 71 includes at least one of the following:

[0149] Actively monitor the operating status of the target cloud server and / or its physical servers to obtain a first type of perceptible abnormal event;

[0150] Receiving a second type of perceived abnormal event reported by an operation and maintenance party, where the second type of perceived abnormal event is generated by the operation and maintenance party during the operation and maintenance of the target cloud server and / or its physical server;

[0151] A third type of perceived abnormal event triggered by a user is received, where the third type of perceived abnormal event is triggered by a complaint work order submitted by the user.

[0152] Optionally, the type of the target sensed abnormal event is any of the following:

[0153] The target cloud server is unavailable, the instance running on the target cloud server is damaged, the operation and maintenance operation for the target cloud server fails, abnormal notification events and user complaint events.

[0154] Optionally, the cloud server risk perception calculation unit 72 is specifically configured to:

[0155] Determining a target perceptible factor corresponding to the target perceptible abnormal event based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor; wherein the perceptible factor is related to the user's degree of perceptibility to the corresponding type of perceptible abnormal event;

[0156] The risk perception level corresponding to the target cloud server is calculated according to the target perception factor.

[0157] Optionally, the cloud server risk perception calculation unit 72 is specifically configured to:

[0158] In the case where there is only one type of target-perceived abnormal event, the product of its corresponding target-perceived factor and the scale parameter of the target cloud server is used as the risk perception;

[0159] In the case where there are multiple types of target felt abnormal events, a maximum felt factor is determined from the target felt factors corresponding to the multiple types of target felt abnormal events; and the product of the maximum felt factor and the scale parameter of the target cloud server is used as the risk perception.

[0160] Optionally, the device further includes:

[0161] a value correction unit, configured to determine a corresponding correction weight for the risk perception;

[0162] The risk perception is weightedly calculated according to the determined correction weight, so that the calculation result replaces the risk perception.

[0163] Optionally, the risk perception has a corresponding valid time period; the device further includes:

[0164] a trend acquisition unit, configured to aggregate at least a portion of the risk perceptions generated on the target cloud server to obtain a trend of risk perceptions changing over time under a preset dimension for display and / or risk analysis;

[0165] Among them, the preset dimensions include: users, user groups, cloud server models, instance types, and cloud server scales.

[0166] Optionally, the device further includes:

[0167] An event classification and statistics unit, configured to classify and count the abnormal events that occurred on the target cloud server;

[0168] Based on the obtained classification statistical results, corresponding stability governance recommendations are generated for perceived abnormal events that require governance.

[0169] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0170] In addition, this specification also provides a computer program product, including a computer program / instruction, which implements the implementation process of the corresponding steps in the above method when executed by a processor.

[0171] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the implementation process of the corresponding steps in the above method.

[0172] This specification also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the corresponding steps in the above method when executing the program.

[0173] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0174] Embodiments of the subject matter and functional operations described in this specification may be implemented in the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier to be executed by a data processing device or to control the operation of the data processing device. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information and transmit it to a suitable receiver device for execution by the data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0175] The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform the corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0176] Computers suitable for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of processing unit. Typically, the processing unit will receive instructions and data from a read-only memory and / or random access memory. The basic components of a computer include a processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more large-capacity storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or the computer will be operably coupled to such large-capacity storage devices to receive data from them or to transmit data to them, or both. However, a computer does not necessarily have such a device. In addition, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0177] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0178] Although this specification includes many specific implementation details, these should not be interpreted as limiting the scope of any invention or the scope of protection claimed, but are mainly used to describe the features of specific embodiments of specific inventions. Certain features described in multiple embodiments within this specification may also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features may work in certain combinations as described above and even initially claimed as such, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may point to a sub-combination or a variation of the sub-combination.

[0179] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that these operations be performed in the particular order shown or performed sequentially, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

[0180] Thus, specific embodiments of the subject matter have been described. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0181] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A stability risk assessment method, characterized in that: include: Determining a target perceptible abnormal event occurring on a target device, wherein the target perceptible abnormal event is an abnormal event perceptible to a user; The risk perception degree corresponding to the target device is calculated according to the type of the perceived abnormal event, and the risk perception degree is used to represent the user's perception degree of the stability risk of the target device.

2. The method according to claim 1, characterized in that Determining the target sensed abnormal event occurring in the target device includes at least one of the following: Actively monitoring the operating status of the target device to obtain a first type of sensed abnormal event; receiving a second type of perceived abnormal event fed back by an operation and maintenance party, where the second type of perceived abnormal event is generated by the operation and maintenance party during the operation and maintenance of the target device; A third type of perceived abnormal event triggered by a user is received, where the third type of perceived abnormal event is triggered by a complaint work order submitted by the user.

3. The method according to claim 1, characterized in that The type of the target perceived abnormal event is any of the following: The target device is unavailable, the instance running on the target device is damaged, the operation and maintenance operation for the target device fails, abnormal notification events and user complaint events.

4. The method according to claim 1, wherein The calculating the risk perception level corresponding to the target device according to the type of the sensed abnormal event includes: Determining a target perceptible factor corresponding to the target perceptible abnormal event based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor; wherein the perceptible factor is related to the user's degree of perceptibility to the corresponding type of perceptible abnormal event; The risk perception level corresponding to the target device is calculated according to the target sensitive factor.

5. The method according to claim 4, characterized in that Calculating the risk perception level corresponding to the target device according to the target sensitive factor includes: In the case where there is only one type of target perceptible abnormal event, the product of its corresponding target perceptible factor and the scale parameter of the target device is used as the risk perception; In the case that there are multiple types of target felt abnormal events, a maximum felt factor is determined from the target felt factors corresponding to the multiple types of target felt abnormal events; and the product of the maximum felt factor and the scale parameter of the target device is used as the risk perception.

6. The method according to claim 1, characterized in that Also includes: Determining corresponding correction weights based on the risk perception; The risk perception is weightedly calculated according to the determined correction weight, and the calculation result is replaced with the risk perception.

7. The method according to claim 1, characterized in that The risk perception has a corresponding valid time period; the method further includes: Aggregating at least a portion of the risk perceptions generated on the target device to obtain a trend of risk perceptions changing over time under a preset dimension for display and / or risk analysis; The preset dimensions include: user, user group, device model, instance type, and device scale.

8. The method according to claim 1, characterized in that The method further comprises: Classify and count the abnormal events that occur on the target device; Based on the obtained classification statistical results, corresponding stability governance recommendations are generated for perceived abnormal events that require governance.

9. A method for evaluating stability risk, characterized in that: include: For a target cloud server owned by a user on a cloud computing platform, determining a target perceived abnormal event that occurs on the target cloud server, where the target perceived abnormal event is an abnormal event that occurs on the target cloud server and is perceived by the user; The risk perception degree corresponding to the target cloud server is calculated according to the type of the perceived abnormal event, where the risk perception degree is used to represent the user's perception degree of the stability risk of the target cloud server.

10. The method according to claim 9, characterized in that The calculating the risk perception level corresponding to the target cloud server according to the type of the perceived abnormal event includes: Determining a target perceptible factor corresponding to the target perceptible abnormal event based on a predefined correspondence between the type of perceptible abnormal event and the perceptible factor; wherein the perceptible factor is related to the user's degree of perceptibility to the corresponding type of perceptible abnormal event; The risk perception level corresponding to the target cloud server is calculated according to the target perception factor.

11. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the program / instruction is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images