Stability risk assessment

Abstract

The present application provides a stability risk assessment method, a program product, an electronic device, and a storage medium. The method comprises: determining a target perceived abnormal event that has occurred to a target device, wherein the target perceived abnormal event is an abnormal event perceived by a user; and on the basis of the type of the perceived abnormal event, calculating a risk perception degree corresponding to the target device, wherein the risk perception degree is used for representing the perception degree of the user for the stability risk of the target device.

Description

[0001] Cross-references to related applications for stability risk assessment

[0002]

[0001] This disclosure claims priority to Chinese patent application No. 202410318263.0, filed on March 19, 2024, entitled “Evaluation Method, Program Product, Electronic Device, and Storage Medium for Stability Risk,” the entire text of which is incorporated herein by reference.

[0003]

[0002] The present application relates to the field of computer technology, and more particularly to the evaluation of stability risk.

[0004] With the rapid development of the Internet and advancements in information technology, there is an increasing demand for more efficient, flexible, and scalable computing resources, 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 stickiness and user experience for the device and, ultimately, the cloud computing platform.

[0005]

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

[0006]

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

[0007]

[0006] Specifically, the present application is achieved through the following technical solutions.

[0008]

[0007] According to a first aspect of an embodiment of the present application, a method for evaluating stability risk is provided, comprising: determining a target perceived abnormal event occurring on a target device, wherein the target perceived abnormal event is an abnormal event perceived by a user; and calculating a risk perception corresponding to the target device based on the type of the perceived abnormal event, wherein the risk perception is used to characterize the user's degree of perception of the stability risk of the target device.

[0008] According to a second aspect of an embodiment of the present application, a method for evaluating stability risk is provided, comprising: determining a target perceived abnormal event occurring on a target cloud server owned by a user on a cloud computing platform, wherein the target perceived abnormal event is an abnormal event occurring on the target cloud server and perceived by the user; and calculating a risk perception corresponding to the target cloud server based on the type of the perceived abnormal event, wherein the risk perception is used to characterize the user's degree of perception of the stability risk of the target cloud server.

[0009]

[0009] According to a third aspect of the embodiments of the present application, 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.

[0010]

[0010] According to a fourth aspect of an embodiment of the present application, 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.

[0011]

[0011] According to the fifth aspect of the embodiments of the present application, 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.

[0012]

[0012] In the technical solution provided by this application, by determining the target perceived abnormal event and its corresponding type, the risk perception level corresponding to the target device can be determined. Specifically, this application takes the user's experience of perceived abnormal events as a starting point, quantifies and summarizes the user's perception level of different types of perceived abnormal events, and makes the perception level objective and comprehensive.

[0013]

[0013] It should be understood that the above general description and the detailed description below are only exemplary and explanatory and cannot limit the present application.

[0014]

[0014] In order to more clearly illustrate the embodiments of the present application 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 described in the present application. For those skilled in the art, other drawings can also be obtained based on these drawings.

[0015]

[0015] FIG1 is a schematic diagram of the architecture of a stability risk assessment system shown in an exemplary embodiment of the present application;

[0016] FIG2 is a schematic flow chart of a stability risk evaluation method according to an exemplary embodiment of the present application;

[0017] FIG3 is a schematic diagram of a stability risk evaluation method shown in an exemplary embodiment of the present application;

[0018] FIG4 is a flow chart of another stability risk evaluation method according to an exemplary embodiment of the present application;

[0019] FIG5 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of the present application;

[0019]

[0020] FIG6 is a schematic structural diagram of a stability risk evaluation device according to an exemplary embodiment of the present application;

[0020]

[0021] FIG7 is a schematic diagram of the structure of another stability risk evaluation device shown in an exemplary embodiment of the present application.

[0021]

[0022] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different drawings represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present disclosure.

[0022]

[0023] It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this application. In some other embodiments, the methods may include more or fewer steps than those described in this application. Furthermore, a single step described in this application may be described as multiple steps in other embodiments, and multiple steps described in this application may be combined into a single step in other embodiments. It should be understood that although this application 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 information of the same type from one another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of this application. Depending on the context, the term "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0023]

[0024] 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, storage, and display, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. 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 portals are provided for users to choose to authorize or refuse.

[0024]

[0025] FIG1 is a schematic diagram of the architecture of a stability risk evaluation system shown in an exemplary embodiment of the present application. As shown in FIG1 , the system may include a server 11, a network 12, and several electronic devices 13 (eg, a PC (Personal Computer), a server), etc.

[0025]

[0026] Server 11 may be an object requiring stability risk assessment. Server 11 may be a physical server containing an independent 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 application program through a corresponding cloud server instance. When a stability risk is detected on any cloud server, the operating system and / or application program in the corresponding instance of the cloud server will experience anomalies, which will be perceived by users to varying degrees.

[0026]

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

[0027]

[0028] Furthermore, in the technical solutions of one or more embodiments of the present application, the relevant program for implementing the stability risk assessment method of the present embodiment may also be deployed on electronic device 13. Electronic device 13 can then interact with server 11 to obtain relevant data on server 11 for performing stability risk assessment, thereby facilitating the assessment of the stability risk of server 11 based on the relevant program and the relevant data. 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 implemented via network 12, which may include various types of wired or wireless networks, and this application is not limited thereto.

[0028]

[0029] FIG2 is a flow chart of a stability risk evaluation method shown in an exemplary embodiment of the present application. The method specifically includes the following steps.

[0029]

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

[0030]

[0031] 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 provides 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 scenario of the cloud computing platform. For example, in a public cloud scenario, the cloud computing platform may be managed by a third-party service provider, and users can rent the cloud computing resources used by the cloud computing platform to build their own target cloud servers. In another example, in a private cloud scenario, the target cloud server can be directly owned and managed by the user and deployed directly on the cloud computing platform. This is particularly suitable for scenarios where data privacy and security are more sensitive. Of course, even if the target device is not a cloud server in the cloud computing platform, it can be maintained and provided to the user by the corresponding device manager. The device manager can be a third-party service provider or the user itself.

[0031]

[0032] The definition of a target-perceived abnormal event depends on whether the target device is perceived by the user. For example, assuming the cloud server is capable of identifying an abnormal event occurring on a target cloud server provided to a user, if the abnormal event impacts the operating status or functionality of the target cloud server instance, the user can perceive it, and in this case, the abnormal event is considered a perceived abnormal event. Conversely, if the abnormal event does not impact the operating status or functionality of the target cloud server instance, the user cannot perceive or determine that an abnormal event has occurred on the target cloud server, and in this case, the abnormal event is considered an unperceived abnormal event. Specifically, a target-perceived abnormal event can be obtained using at least one of the following methods:

[0032]

[0033] The first approach involves actively monitoring the operating status of the target devices to detect Class I perceived abnormal events. The target devices can be categorized based on different usage scenarios. For example, for a cloud computing platform, the monitored target devices may be the target cloud server and / or its associated physical server. Alternatively, for a local computing platform, the monitored target devices may be the corresponding physical server. The operating status includes, but is not limited to, application operating parameters, processor utilization, memory usage, and network data transmission rate of the instances running on the target cloud server and / or its associated physical server. If any of these operating statuses do not match the expected state, a Class I perceived abnormal event can be determined.

[0033]

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

[0034]

[0035] The second method involves receiving feedback from the operator regarding a second type of perceived anomaly event. This second type of perceived anomaly event is generated by the operator during the operation and maintenance of the target device. The operator is responsible for assisting users with operation and maintenance management. For example, using data migration, a common operation and maintenance method in cloud computing platforms, hot or cold migration can be used to preemptively migrate instance resources running on the user's target cloud server from at-risk physical servers to healthy physical servers, thereby mitigating the risk of target cloud server unavailability. Of course, this risk can also be caused by a first type of perceived anomaly event. However, hot migration may fail if the instance is experiencing peak usage, excessive load, lacks inventory, or if underlying vulnerabilities in the target cloud server are triggered. This failure can indicate the occurrence of a second type of perceived anomaly event.

[0035]

[0036] It should be noted that the main difference between hot migration and cold migration is that the target cloud server does not need to be shut down during hot migration, while it does during cold migration. This may cause functional interruption on the corresponding instance. Therefore, before cold migration, the operation and maintenance party usually needs to ask the user for permission by sending a notification. Behaviors similar to the above notification also essentially fall into the second category of perceived abnormal events mentioned above.

[0036]

[0037] The third method involves receiving a user-triggered third-category perceptible abnormal event. This third-category perceptible abnormal event 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.

[0037]

[0038] Step S204: Calculate 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.

[0038]

[0039] By determining the type of target perceived abnormal event, the corresponding risk perception of the target device can be determined based on the type. This 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, users are more likely to feel anxious about the stability risk of the target cloud server, which in turn damages user stickiness and user experience.

[0039]

[0040] Specifically, the risk perception level corresponding to the target perceived abnormal event type can be determined using a predefined correspondence between the type of perceived abnormal event and the risk perception level. This approach has the advantage of simplifying the risk perception level setting and making it easy to understand. Of course, for target devices in complex scenarios, the calculated risk perception level is often affected by factors other than the event type. Furthermore, the existing correspondence results in the risk perception level being constrained by the total number of perceived abnormal event types. This application provides an alternative approach to this problem, namely, introducing a calculable perceived factor between the type of perceived abnormal event and the risk perception level.

[0040]

[0041] In one embodiment, a target sensitive factor corresponding to a target sensitive abnormal event can be determined based on a predefined correspondence between the type of sensitive abnormal event and the sensitive factor, and the risk perception level corresponding to the target device can be calculated based on the target sensitive factor. The sensitive factor is related to the user's level of awareness of the corresponding type of sensitive abnormal event. Taking the aforementioned cloud computing platform as an example, after obtaining a target sensitive abnormal event, the cloud computing platform can determine the corresponding target sensitive factor based on the predefined correspondence between the type of sensitive abnormal event and the sensitive factor. The correspondence can be stored locally on the cloud computing platform or in a non-volatile storage device associated with another network address, although this application is not limited thereto.

[0041]

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

[0042]

[0043] Unavailable event: The target device is unavailable. For example, the physical server to which the target cloud server belongs is down, or the instance running on the target cloud server is stuck or crashes abnormally, resulting in the risk of interruption of the operating system and applications deployed by users on the target cloud server.

[0043]

[0044] Operation failure event: An operation for the target device fails. As mentioned above, this operation can specifically be the failure of the operator to automatically hot migrate the target cloud server.

[0044]

[0045] 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 categorized based on the instance damage scenario, such as whether the instance is damaged during normal operation or during a hot migration.

[0045]

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

[0046]

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

[0047]

[0048] 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 application.

[0048]

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

[0049]

[0050] 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 application does not limit this.

[0050]

[0051] In addition, different types of target sensed abnormal events may 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.

[0051]

[0052] 3 , in the case where the target device is a cloud server in a cloud computing platform, a method for determining various types of target sensed abnormal events is described in a modular manner. As shown in FIG3 , the figure includes the following modules.

[0052]

[0053] 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 downtime, a corresponding abnormality notification can be sent to the user.

[0053]

[0054] Instance stall determination module 302: This module can determine the operating status of the physical server and the cloud server instance by querying the physical server status database and the cloud server instance status database. If one or more operating statuses are found to be abnormal, such as abnormal memory usage of the physical server or increased network latency, it can be determined that the cloud server instance has stalled.

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

[0054]

[0056] 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 significant impact, the user can be notified.

[0055]

[0057] Migration damage determination module 305: This module can determine whether the instance has performance abnormalities 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.

[0056]

[0058] Automatic hot migration failure determination module 306: The operation and maintenance platform corresponding to this module can determine the risk of downtime of the above-mentioned physical server by querying the operation and maintenance status database, and can then perform hot migration on 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.

[0057]

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

[0058]

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

[0059]

[0061] For the specific values ​​of the above-mentioned perceptible factors, this application 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 correspondence between the types of perceptible abnormal events and perceptible factors: Table 1

[0060]

[0062] Those skilled in the art will appreciate that the sensitivity factor in Table 1 is positively correlated with the user's level of awareness of the corresponding type of perceived abnormal event; that is, the higher the level of awareness, the higher the sensitivity factor. This application may also set the sensitivity factor to be negatively correlated with the user's level of awareness of the corresponding type of perceived abnormal event; that is, the higher the level of awareness, the lower the sensitivity factor. In this case, the risk perception level described below will also be negatively correlated with the user's level of awareness of the stability risk of the target cloud server. To avoid confusion in the description, the following description will assume that the sensitivity factor is positively correlated with the user's level of awareness of the corresponding type of perceived abnormal event.

[0061]

[0063] The perceptible factors corresponding to different perceptible abnormal events have relationships in terms of size and ratio. Among them, sequence number 1 corresponds to the user filing a complaint ticket, which is a user complaint event. Considering that filing a complaint ticket is a user's active behavior, it indicates that the user has experienced a relatively serious perceptible disturbance. Therefore, it has a higher perception level than other perceptible abnormal events. Sequence numbers 2 and 3 correspond to unexpected instance downtime and abnormal instance crashes, which are unavailability events. Both inevitably lead to cloud server unavailability. Therefore, their perceptibility factor is second only to the user complaint event. Sequence numbers 4-7 correspond to a combination of operation and maintenance failure events and abnormal notification events. They are subdivided based on the response time and migration results of abnormal notification events. Among them, the first time range is closer to the time when the cold migration notification is sent than the second time range. For example, the first time range is 0-4 hours after the cold migration notification, and the second time range is 4-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 does not occur after the cold migration notification, the user's perception level is relatively low. In this case, responding to the cold migration notification within the preset response time range (which can be 0 to 48 hours after receiving the cold migration notification) has a higher perceived level than not responding. The damage to the instance corresponding to sequence number 8 is an instance damage event, and the lag of the instance corresponding to sequence number 9 is an unavailability event. Because both have relatively minor negative impacts on instances running on the cloud server, their perceived factors are relatively low.

[0062]

[0064] The above shows the relationship between the perceived factors corresponding to different perceived abnormal event types in terms of magnitude. The relationship in terms of ratio can be set based on actual scenarios. For example, if users file an average of two complaint tickets regarding downtime for every three unexpected downtimes experienced by a cloud server, this means that users perceive an average of 1.5 instances of perceived disruption caused by unexpected downtimes before actively initiating a targeted complaint ticket to express their dissatisfaction with the perceived disruption. Therefore, the ratio of the perceived factors for "users filing complaint tickets" to "unexpected instance downtime" can be determined to be 3:2. Similarly, the perceived factors for other event types can be calculated. This application will not be further elaborated here.

[0063]

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

[0064]

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

[0065]

[0067] In one embodiment, if there is only one type of target perceived abnormal event, the risk perception can be directly calculated by multiplying the corresponding perceived factor by the target cloud server's scale parameter. The target cloud server's scale parameter can include information such as the number of virtual processor cores, memory size, or bandwidth size. For ease of explanation, the number of virtual processor cores, vcpu_count, is used as the scale parameter below. The perceived factor corresponding to the target perceived abnormal event is a. The risk perception is calculated as follows: Risk Perception = vcpu_count * a (Formula 1)

[0066]

[0068] 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 risk perception level of the target cloud server can be determined to be 8*20=160 from the result table 1.

[0067]

[0069] In another embodiment, there are multiple types of target-sensed abnormal events. The maximum sensitive factor can be determined from the sensitive factors corresponding to the multiple abnormal events, and the product of the maximum sensitive factor and the scale parameter of the target cloud server can be used as the risk perception. As previously mentioned, multiple target-sensed abnormal events have a causal relationship and often occur together. If the causal relationship of each of the multiple target-sensed abnormal events is factored into the risk perception calculation, the risk perception will be too large, resulting in distorted results. Therefore, the target device can select the maximum sensitive factor from the n sensitive factors, rather than all or a portion of the sensitive factors, to ensure the accuracy of the risk perception. The risk perception calculation formula is as follows: Risk Perception = vcpu_count * max(a1, a2 > an) (Formula 2)

[0068]

[0070] Furthermore, the direct calculation of risk perception in the above embodiment ignores the influence of other factors, such as the user and the target device, on risk perception, causing 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.

[0069]

[0071] In one embodiment, a corresponding correction weight can be determined for risk perception. Specifically, the target device can determine the correction weight based on user attributes, such as the level of the user's account registered on the target device and the user's enterprise; target device attributes, such as the server model and operating hours; instance characteristics of the instance running on the target device, such as the cloud server scale and the service type selected by the user when using the cloud server; and / or event characteristics of the target-sensed abnormal events affecting the target device, such as the frequency of events, the time since the last occurrence, and the duration of the impact of the current event. The correction weight is then used to correct the risk perception value. The correction weight represents the degree of influence of these other factors on risk perception and can therefore be used to correct the risk perception calculated using the sensitivity factor, thereby maximizing the accuracy of the risk perception.

[0070]

[0072] For example, if user A's cloud server on a cloud computing platform experiences a 6-hour downtime, and user B's cloud server experiences a 1-hour downtime, then the risk perception associated with user A's cloud server is clearly 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. This 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 is not a limitation in this application.

[0071]

[0073] The above-mentioned value correction process is to perform a 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.

[0072]

[0074] For example, suppose a user rents ten cloud servers on a cloud computing platform. Three of them 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 the user's 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)]

[0073]

[0075] For example, if risk perception focuses on the actual duration of a target perceptible abnormal event affecting users, the ratio of the total duration of the target cloud server being affected by the target perceptible abnormal event (EventTimevm) on that day to the total duration of the target cloud server's survival (LifeTimevm) 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: Risk Perception = Ev ^ ntTimevm * vcpu count^max (od, a2,.an) (Formula 3) LifeTimevm —

[0075]

[0076] For example, if risk perception doesn't 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, and used as the correction weight to correct the original risk perception. The formula for calculating risk perception is as follows: od, a2, .an) (Formula 4)

[0076]

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

[0077]

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

[0078]

[0079] In one embodiment, the risk perception may have a corresponding valid time period. For example, for a target perceived abnormal event occurring on a given day, the risk perception calculated based on its perceived factor will also have a valid time period corresponding to that day. Specifically, the target device may aggregate at least a portion of the calculated risk perception to obtain a temporal trend of risk perception within a preset dimension for display and / or risk analysis. The risk perception may be statistically analyzed and presented based on daily, weekly, monthly, quarterly, or annual charts during display and / or risk analysis to highlight temporal trends. The preset dimensions may include: user, user group, device model, instance type, and device scale. As previously mentioned, device scale includes, but is not limited to, the model and quantity of devices such as processors and memory. If no restrictions are placed on the preset dimensions, the aggregated results can be viewed as the changing trends in the degree of stability risk perception of each target cloud server owned by all users on the cloud computing platform. Conversely, if specific restrictions are placed on the preset dimensions, user profiles can be determined based on the changing trends in the degree of stability risk perception of some users towards cloud servers, or the changing trends in the degree to which users perceive stability risks for some cloud servers can be analyzed, thereby implementing targeted stability management measures for negative trends. For example, if the daily risk perception of user A shows an increasing trend, the physical server that owns the cloud server owned by user A can be temporarily upgraded or directly replaced with another physical server with higher performance and stability, thereby effectively reducing user A's perception of stability risk.

[0079]

[0080] In reality, risk perception alone cannot accurately indicate the primary cause of user perception of the target cloud server's stability risk through perceived abnormal events. Therefore, this application further categorizes perceived abnormal events into specific categories to clarify the primary cause of user perception of the stability risk, thereby facilitating efficient subsequent governance. Classification refers to the division of perceived abnormal events into the categories mentioned above.

[0080]

[0081] In one embodiment, the cloud computing platform can categorize and analyze the percentage of perceived abnormal events. Based on the categorized statistical results, it can prioritize stability management recommendations for those perceived abnormal events requiring management. Management requirements can be determined based on factors such as the number of events, the number of affected users, and event priority. The number of events directly reflects the most frequent perceived abnormal events, facilitating accurate location and maintenance by target device maintainers. For example, if a high proportion of unavailability events are caused by cloud server downtime, the cloud computing platform may prioritize downtime management for stability optimization. Alternatively, if a large number of abnormal notification events occur too close to the time of an operation and maintenance failure, the platform may determine that the lead time for abnormal notification events is insufficient, and consideration may be given to optimizing the success rate of the operation and maintenance operations or increasing the lead time for notifications. 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: A cloud computing platform has 10 users. Among them, 20 cloud servers rented by the first user experience downtime, and 2 cloud servers rented by users 2 to 10 experience instance damage. Although the number of events indicates that the cloud computing platform should optimize for downtime management, the proportion of affected people indicates that instance damage management should be prioritized as a stability optimization direction. The dimension of event priority combines the priorities of different events or the various contents of the first preset dimension mentioned above. Taking the 10 users mentioned above as an example, assuming that the priority of the downtime event is 2 and the priority of other events is 1, then if a cloud server rented by four users respectively goes down and a cloud service instance rented by the remaining six users is damaged, it can be determined through the formula (4*2) > (6*1) that the downtime event with a smaller number of events and a smaller number of affected people has a higher event priority. Therefore, downtime management should be used as a direction for stability optimization. In short, the characteristic of this dimension is that it can refine the strategy for determining stability management recommendations to the greatest extent, thereby improving the accuracy of the determined stability management recommendations.

[0081]

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

[0082]

[0083] FIG4 is a flow chart of another stability risk evaluation method according to an exemplary embodiment of the present application. The method specifically includes the following steps.

[0083]

[0084] Step S402: 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.

[0084]

[0085] Step S404: Calculate the risk perception level corresponding to the target cloud server 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 cloud server.

[0085]

[0086] Optionally, the determination of the target perceived abnormal event occurring in the target cloud server includes at least one of the following: actively monitoring the operating status of the target cloud server and / or its physical server to obtain a first type of perceived abnormal event; receiving a second type of perceived abnormal event fed back by the operation and maintenance party, wherein the second type of perceived abnormal event is generated by the operation and maintenance party during the operation and maintenance process of the target cloud server and / or its physical server; receiving a third type of perceived abnormal event triggered by a user, wherein the third type of perceived abnormal event is triggered by a complaint ticket submitted by a user.

[0086]

[0087] Optionally, the type of the target perceived abnormal event is any one of the following: unavailability of the target cloud server, damage to the instance running on the target cloud server, failure of an operation and maintenance operation for the target cloud server, an abnormal notification event, and a user complaint event.

[0087]

[0088] Optionally, calculating the risk perception level corresponding to the target cloud server based on the type of the perceived abnormal event includes: determining a target perception factor corresponding to the target perceived abnormal event based on a predefined correspondence between the type of the perceived abnormal event and the perception factor; wherein the perception factor is related to the user's perception level of the corresponding type of perceived abnormal event; and calculating the risk perception level corresponding to the cloud server based on the target perception factor.

[0088]

[0089] Optionally, calculating the risk perception corresponding to the cloud server based on the target sensitive factor includes: when there is only one type of target sensitive abnormal event, multiplying the corresponding target sensitive factor by the scale parameter of the target cloud server as the risk perception; when there are multiple types of target sensitive abnormal events, determining a maximum sensitive factor from the target sensitive factors corresponding to the multiple types of target sensitive abnormal events; and multiplying the product of the maximum sensitive factor and the scale parameter of the target cloud server as the risk perception.

[0089]

[0090] Optionally, the above method further includes: determining a corresponding correction weight for the risk perception; performing weighted calculation on the risk perception according to the determined correction weight, and replacing the calculation result with the risk perception.

[0090]

[0091] Optionally, the risk perception has a corresponding valid time period; the method also includes: aggregating at least a portion of the risk perception generated on the cloud computing platform to obtain a trend of risk perception changing over time under preset dimensions for display and / or risk analysis; wherein the preset dimensions include: users, user groups, physical server models, instance types, and cloud server scales.

[0091]

[0092] Optionally, the method further includes: classifying and counting the perceived abnormal events occurring on the cloud computing platform; and generating corresponding stability management suggestions for the perceived abnormal events that require management based on the obtained classification and statistical results.

[0092]

[0093] Figure 5 is a schematic diagram of the structure of an electronic device in an exemplary embodiment. Referring to Figure 5 , at the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other necessary hardware. The processor reads the corresponding computer program from the non-volatile storage into the internal memory and then executes it, forming a stability risk assessment device at the logical level. Of course, in addition to software implementations, this application does not exclude other implementations, such as logic devices or a combination of software and hardware. In other words, the execution of the following processing flow is not limited to individual logic units; it can also be hardware or logic devices.

[0093]

[0094] Corresponding to the aforementioned embodiment of the method for evaluating stability risk, the present application also provides an embodiment of an apparatus for evaluating stability risk.

[0094]

[0095] Please refer to Figure 6, which is a schematic diagram illustrating the structure of a stability risk assessment device according to an exemplary embodiment. As shown in Figure 6, in a software implementation, the device may include: a device event determination unit 61, configured to determine a target perceived abnormal event occurring on a target device, where the target perceived abnormal event is an abnormal event perceived by a user; and a device risk perception calculation unit 62, configured to calculate the risk perception corresponding to the target device based on the type of the perceived abnormal event. The risk perception indicates the user's perception of the stability risk of the target device.

[0095]

[0096] Optionally, the device event determination unit 61 is specifically configured to perform at least one of the following: actively monitor the operating status of the target device to obtain a first type of perceived abnormal event; receive 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 process of the target device; and receive a third type of perceived abnormal event triggered by a user, where the third type of perceived abnormal event is triggered by a complaint work ticket submitted by the user.

[0096]

[0097] Optionally, the type of the target perceived abnormal event is any one of the following: unavailability of the target device, damage to the instance running on the target device, failure of an operation and maintenance operation for the target device, an abnormal notification event, and a user complaint event.

[0097]

[0098] Optionally, the device risk perception calculation unit 62 is specifically configured to: determine a target sensitive factor corresponding to the target sensitive abnormal event based on a predefined correspondence between the type of sensitive abnormal event and the sensitive factor; wherein the sensitive factor is related to the user's perception level of the corresponding type of sensitive abnormal event; and calculate the risk perception corresponding to the target device based on the target sensitive factor.

[0098]

[0099] Optionally, the device risk perception calculation unit 62 is specifically configured to: when there is only one type of target perceived abnormal event, use the product of the corresponding target perceived factor and the scale parameter of the target device as the risk perception; when there are multiple types of target perceived abnormal events, and the number of the abnormal events is multiple; determine a maximum perceived factor from the perceived factors corresponding to the multiple abnormal events; and use the product of the maximum perceived factor and the scale parameter of the target device as the risk perception.

[0099]

[0100] Optionally, the device further includes: a value correction unit, configured to determine a corresponding correction weight for the risk perception; perform weighted calculation on the risk perception according to the determined correction weight, and replace the calculation result with the risk perception.

[0100]

[0101] Optionally, the risk perception has a corresponding valid time period; the device also includes: a trend acquisition unit, which is used to aggregate at least a portion of the risk perception generated on the target device to obtain the trend of risk perception changing over time under preset dimensions for display and / or risk analysis; wherein the preset dimensions include: users, user groups, device models, instance types, and device scales.

[0101]

[0102] Optionally, the apparatus further includes: an event classification and statistics unit, configured to classify and count the perceived abnormal events occurring in the target device; and, based on the obtained classification and statistics results, preferentially generate corresponding stability management suggestions for the perceived abnormal events that require management.

[0102]

[0103] Please refer to Figure 7, which is a schematic diagram illustrating the structure of another stability risk assessment device according to an exemplary embodiment. As shown in Figure 7, in a software implementation, the device may include a cloud server event determination unit 71, configured to determine, for a target cloud server owned by a user on a cloud computing platform, a target-perceived abnormal event occurring on the target cloud server. The target-perceived abnormal event is an abnormal event that occurs on the target cloud server and is perceived by the user.

[0103]

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

[0104]

[0105] Optionally, the cloud server event determination unit 71 includes at least one of the following: actively monitoring the operating status of the target cloud server and / or its physical server to obtain a first type of perceived 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 process of the target cloud server and / or its physical server; and receiving a third type of perceived abnormal event triggered by a user, where the third type of perceived abnormal event is triggered by a complaint work ticket submitted by the user.

[0105]

[0106] Optionally, the type of the target perceived abnormal event is any one of the following: unavailability of the target cloud server, damage to the instance running on the target cloud server, failure of an operation and maintenance operation for the target cloud server, an abnormal notification event, and a user complaint event.

[0106]

[0107] Optionally, the cloud server risk perception calculation unit 72 is specifically configured to: determine a target sensitive factor corresponding to the target sensitive abnormal event based on a predefined correspondence between the type of sensitive abnormal event and the sensitive factor; wherein the sensitive factor is related to the user's perception of the corresponding type of sensitive abnormal event; and calculate the risk perception corresponding to the target cloud server based on the target sensitive factor.

[0108] Optionally, the cloud server risk perception calculation unit 72 is specifically configured to: when there is only one type of target perceived abnormal event, use the product of the corresponding target perceived factor and the scale parameter of the target cloud server as the risk perception; when there are multiple types of target perceived abnormal events, determine a maximum perceived factor from the target perceived factors corresponding to the multiple types of target perceived abnormal events; and use the product of the maximum perceived factor and the scale parameter of the target cloud server as the risk perception.

[0107]

[0109] Optionally, the device further includes: a value correction unit, configured to determine a corresponding correction weight for the risk perception; and perform weighted calculation on the risk perception according to the determined correction weight, so that the calculation result replaces the risk perception.

[0108]

[0110] Optionally, the risk perception has a corresponding valid time period; the device also includes: a trend acquisition unit, used to aggregate at least a portion of the risk perception generated on the target cloud server, and obtain the trend of risk perception changing over time under preset dimensions for display and / or risk analysis; wherein, the preset dimensions include: users, user groups, cloud server models, instance types, and cloud server scales.

[0109]

[0111] Optionally, the device further includes: an event classification and statistics unit, configured to classify and count the perceived abnormal events occurring in the target cloud server; and to preferentially generate corresponding stability management suggestions for the perceived abnormal events that require management based on the obtained classification and statistics results.

[0110]

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

[0111]

[0113] In addition, the present application 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.

[0112]

[0114] The present application also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the implementation process of the corresponding steps in the above method.

[0113]

[0115] The present application also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the corresponding steps of the above method when executing the program.

[0114]

[0116] Since the apparatus embodiments generally correspond to the method embodiments, reference will be made to the description of the method embodiments for relevant details. The apparatus embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present application. Persons of ordinary skill in the art can understand and implement the present invention without inventive effort.

[0115]

[0117] Embodiments of the subject matter and functional operations described herein can be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware including the structures disclosed herein and their structural equivalents, or a combination of one or more thereof. Embodiments of the subject matter described herein can 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 for execution by, or control of the operation of, a data processing apparatus. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagated signal, such as a machine-generated electrical, optical, or electromagnetic signal, generated to encode information and transmit it to a suitable receiver apparatus for execution by the data processing apparatus. A computer storage medium can 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 thereof.

[0116]

[0118] The processes and logic flows described herein 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).

[0117]

[0119] 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 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 mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or will be operatively coupled to such mass storage devices to receive data from them, transfer data to them, or both. However, a computer need not include such devices. Furthermore, a computer may 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.

[0118]

[0120] Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile 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 may be supplemented by, or incorporated in, special purpose logic circuitry.

[0119]

[0121] While this application contains many specific implementation details, these should not be construed as limiting the scope of any invention or the scope of what is claimed, but rather as describing features of specific embodiments of particular inventions. Certain features described in the context of multiple embodiments within this application may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, while features may function in certain combinations as described above and even initially claimed as such, one or more features from a claimed combination may in some cases be removed from that combination, and a claimed combination may be directed to subcombinations or variations of those subcombinations.

[0120]

[0122] Similarly, while operations are depicted in a particular order in the figures, this should not be understood as requiring that these operations be performed in the particular order shown, or in sequential order, or that all illustrated operations be performed, in order to achieve the desired results. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, 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 may generally be integrated together in a single software product or packaged into multiple software products.

[0121]

[0123] 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 or sequential sequence shown to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0122]

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

Claims

Claims 1. A stability risk assessment method, comprising: 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, wherein: The determining of the target perceived 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 perceived abnormal event; receiving a second type of perceived abnormal event fed back by the 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 process of the target device; receiving a third type of perceived abnormal event triggered by a user, 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, wherein: The type of the target perceived abnormal event is any one 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, an abnormal notification event, and a user complaint event.

4. The method according to claim 1, wherein: Calculating the risk perception level corresponding to the target device based on the type of the perceived abnormal event includes: determining a target perception factor corresponding to the target perceived abnormal event based on a predefined correspondence between the type of the perceived abnormal event and the perception factor; wherein the perception factor is related to a user's perception level of the corresponding type of perceived abnormal event; and calculating the risk perception level corresponding to the target device based on the target perception factor.

5. The method according to claim 4, wherein: The calculating the risk perception corresponding to the target device based on the target sensitive factor includes: when there is only one type of target sensitive abnormal event, taking the product of its corresponding target sensitive factor and the scale parameter of the target device as the risk perception; when there are multiple types of target sensitive abnormal events, determining the maximum sensitive factor from the target sensitive factors corresponding to the multiple types of target sensitive abnormal events; and taking the product of the maximum sensitive factor and the scale parameter of the target device as the risk perception.

6. The method according to claim 1, further comprising: 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, wherein: The risk perception has a corresponding valid time period; the method also includes: aggregating at least a portion of the risk perception generated on the target device to obtain a trend of risk perception changing over time under preset dimensions for display and / or risk analysis; wherein the preset dimensions include: user, user group, device model, instance type, and device scale.

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

9. A stability risk assessment method comprising: 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, wherein: Calculating the risk perception level corresponding to the target cloud server based on the type of the perceived abnormal event includes: determining a target perception factor corresponding to the target perceived abnormal event based on a predefined correspondence between the type of the perceived abnormal event and the perception factor; wherein the perception factor is related to the user's perception level of the corresponding type of perceived abnormal event; and calculating the risk perception level corresponding to the target cloud server based on the target perception factor.

11. A computer-readable storage medium having a computer program / instruction stored thereon, wherein: 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, wherein: 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