Method, device, equipment, storage medium and program product for maintaining cloud phone

Abstract

The present disclosure provides a method, device, electronic device, computer-readable storage medium, and computer program product for maintaining cloud phones, and relates to the fields of artificial intelligence technology such as cloud services, risk monitoring, and intelligent operation and maintenance. A specific implementation of the method includes: detecting the operation log of the cloud phone, determining whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical failures; in response to the cloud phone currently being at a risk point, analyzing the target log data to determine the risk type of the risk point; determining the target maintenance strategy for the cloud phone based on the risk type; and executing the target maintenance strategy. In this way, it is possible to intervene and perform maintenance on the cloud phone before a failure occurs, and the operational stability of the cloud phone can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, specifically to the field of artificial intelligence technologies such as cloud services, risk monitoring, and intelligent operation and maintenance, and especially to methods, devices, electronic devices, computer-readable storage media, and computer program products for maintaining cloud phones. Background Art

[0002] With the advancement of computing technology, cloud phone technology has emerged to enhance the computing power and user experience of user devices. Cloud phones apply cloud computing technology to network terminal services, using cloud servers to deliver "cloud services" to mobile phone systems. These deeply integrated "phones" leverage their own operating systems and vendor-provided network terminals to gain enhanced computing power, providing users with more functionality.

[0003] In a cloud phone system, users can use their devices to communicate with the cloud server and other terminal devices in the cloud phone system, thereby utilizing other devices to provide the required computing power. Therefore, how to ensure the user experience and improve the operational stability of cloud phones (especially cloud servers) is a matter of concern and urgent need. Summary of the Invention

[0004] The embodiments of the present disclosure provide a method, device, electronic device, computer-readable storage medium, and computer program product for maintaining a cloud phone.

[0005] In the first aspect, an embodiment of the present disclosure proposes a method for maintaining a cloud phone, including: detecting the operation log of the cloud phone, determining whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical failures; in response to the cloud phone currently being at a risk point, analyzing the target log data, and determining the risk type of the risk point; determining a target maintenance strategy for the cloud phone based on the risk type; and executing the target maintenance strategy.

[0006] In the second aspect, an embodiment of the present disclosure proposes a device for maintaining a cloud phone, comprising: a risk point detection unit, configured to detect the operation log of the cloud phone, and determine whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical failures; a risk type determination unit, configured to analyze the target log data in response to the cloud phone currently being at a risk point, and determine the risk type of the risk point; a maintenance strategy determination unit, configured to determine a target maintenance strategy for the cloud phone based on the risk type; and a maintenance strategy execution unit, configured to execute the target maintenance strategy.

[0007] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that when the at least one processor executes, it can implement the method for maintaining a cloud phone as described in any implementation method in the first aspect.

[0008] In a fourth aspect, an embodiment of the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, which are used to enable a computer to implement the method for maintaining a cloud phone as described in any implementation method in the first aspect when executed.

[0009] In a fifth aspect, an embodiment of the present disclosure provides a computer program product comprising a computer program, which, when executed by a processor, can implement the method for maintaining a cloud phone as described in any implementation manner in the first aspect.

[0010] The method, device, electronic device, computer-readable storage medium and computer program product for maintaining a cloud phone provided by the embodiments of the present disclosure can determine whether the cloud phone is currently at a risk point by detecting the operation log of the cloud phone, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical failures; then, in response to the target cloud phone currently being at a risk point, the target log data is analyzed to determine the risk type of the risk point; then, a target maintenance strategy for the target cloud phone is determined based on the risk type; finally, the target maintenance strategy is executed.

[0011] The present disclosure is based on the detection and analysis of the cloud phone's operation log to determine whether the cloud phone is at risk of failure, and actively intervenes in the cloud phone and performs maintenance when there is a risk to improve the operation stability of the cloud phone.

[0012] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other features, objects and advantages of the present disclosure will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

[0014] Figure 1 is an exemplary system architecture in which the present disclosure may be applied;

[0015] Figure 2 A flowchart of a method for maintaining a cloud phone provided in an embodiment of the present disclosure;

[0016] Figure 3 A flowchart of a process for determining reference log data provided by an embodiment of the present disclosure;

[0017] Figure 4 A schematic diagram of an exemplary architecture for maintaining a cloud phone in an application scenario provided by an embodiment of the present disclosure;

[0018] Figure 5 A structural block diagram of a device for maintaining a cloud phone provided in an embodiment of the present disclosure;

[0019] Figure 6 A schematic structural diagram of an electronic device suitable for executing a method for maintaining a cloud phone provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. It should be noted that the embodiments in the present disclosure and the features in the embodiments can be combined with each other unless there is a conflict.

[0021] In addition, in the technical solutions involved in this disclosure, the acquisition, storage, use, processing, transportation, provision and disclosure of user personal information involved (such as the operation logs and historical logs involved in this disclosure later, etc.) are in compliance with the relevant laws and regulations and do not violate public order and good morals.

[0022] Figure 1An exemplary system architecture 100 is shown to which embodiments of the method, apparatus, electronic device, and computer-readable storage medium for maintaining a cloud phone disclosed herein may be applied.

[0023] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for a communication link between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc. For example, the system architecture 100 may be embodied as a cloud phone architecture, and the server 105 may be exemplified as a "cloud server" that provides a cloud phone. Users (not shown in the figure) can communicate with the server 105 through the terminal devices 101, 102, 103 as user devices to use and implement the "cloud phone".

[0024] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. For example, users can use applications on terminal devices 101, 102, and 103 to provide computing materials to server 105, which then processes these computing materials using the computing power of server 105. Server 105 then returns the processing results to terminal devices 101, 102, and 103.

[0025] In some scenarios, terminal devices 101, 102, and 103 may also be embodied as (electronic) devices used by users to manage cloud phones (or, in other words, cloud phone servers). For example, terminal devices 101, 102, and 103 may also be used by operation and maintenance personnel of cloud service and cloud phone service providers to communicate with server 105 using terminal devices 101, 102, and 103 to manage and maintain server 105 or, in other words, the cloud phone (for example, providing files for executing updates to server 105).

[0026] Accordingly, various applications for realizing information communication between the terminal devices 101 , 102 , 103 and the server 105 may be installed, such as cloud service applications, remote management applications, instant messaging applications, etc.

[0027] Terminal devices 101, 102, 103 and server 105 can be either hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices with display screens, including but not limited to smartphones, tablet computers, laptop computers, and desktop computers. When terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules, or as a single software or software module, and are not specifically limited here. When server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software or software modules, or as a single software or software module, and are not specifically limited here.

[0028] The server 105 can provide various services through various built-in applications. Taking the remote management application that can provide remote operation and maintenance as an example, the server 105 can achieve the following effects when running the remote management application: First, the server 105 can receive remote operation and maintenance instructions from the terminal devices 101, 102, and 103 through the network 104, and based on the remote operation and maintenance instructions, detect the operation log of the cloud phone (if the cloud computing power of the cloud phone is provided by the server 105, then the "operation log" can actually be the operation log stored locally on the server 105 to record the operating status of the server 105), and determine whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical faults; then, in response to the cloud phone currently being at a risk point, the server 105 analyzes the target log data and determines the risk type of the risk point; then, the server 105 determines the target maintenance strategy for the cloud phone according to the risk type; finally, executes the target maintenance strategy.

[0029] It should be noted that, in addition to executing the above process in response to remote operation and maintenance instructions transmitted from the terminal devices 101, 102, and 103 through the network 104, the server 105 can also execute the above process based on a pre-configuration or an operation indicated by the user. For example, the user can instruct the server to execute "detecting the operation log of the cloud phone, determining whether the cloud phone is currently at a risk point", and executing the subsequent process by directly interacting with the server 105. For another example, the server 105 can execute "detecting the operation log of the cloud phone, determining whether the cloud phone is currently at a risk point", and executing the subsequent process based on a pre-configuration (for example, continuously or periodically after the server 105 is started). In this case, the exemplary system architecture 100 may also not include the terminal devices 101, 102, 103 and the network 104.

[0030] Because obtaining and detecting the cloud phone's operation logs may require significant computing resources and significant computational power, the cloud phone maintenance methods provided in the subsequent embodiments of this disclosure are generally performed by server 105, which possesses significant computing power and resources. Accordingly, the cloud phone maintenance apparatus is generally also located within server 105. However, it should also be noted that, if terminal devices 101, 102, and 103 also possess sufficient computing power and resources, terminal devices 101, 102, and 103 may also utilize remote management applications installed thereon to perform the aforementioned operations delegated to server 105, thereby outputting the same results as server 105. This is particularly true in situations where multiple terminal devices with varying computing power coexist, and if the remote management application determines that the terminal device in question possesses significant computing power and resources, it may allow the terminal device to perform the aforementioned operations, thereby appropriately alleviating the computational burden on server 105. Accordingly, the cloud phone maintenance apparatus may also be located within terminal devices 101, 102, and 103. Similarly, in some scenarios, if the terminal devices 101, 102, and 103 implement local maintenance by executing the cloud phone maintenance method (for example, the terminal devices 101, 102, and 103 serve as the "cloud service provider" of other terminal devices), the exemplary system architecture 100 may also not include the terminal device server 105.

[0031] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0032] Please refer to Figure 2 , Figure 2 This is a flowchart of a method for maintaining a cloud phone provided by an embodiment of the present disclosure, wherein process 200 includes the following steps:

[0033] Step 201: Check the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point;

[0034] This step is intended to be performed by the execution subject of the method for maintaining the cloud phone (e.g. Figure 1The server 105 shown in the figure is used to detect the operation log of the cloud phone. For ease of understanding, in the embodiments of the present disclosure, the server 105 is exemplified as a cloud server providing cloud services. Accordingly, the server 105 can be exemplified as the execution subject of the method for maintaining the cloud phone, so as to "automatically and spontaneously" detect and maintain its local operation status to achieve the purpose of "maintaining the cloud phone and ensuring the stable operation of the cloud phone". The execution subject can maintain the operation log of the cloud phone locally. For example, the execution subject can continuously and / or periodically obtain the operation data of the cloud phone (for example, the usage parameters of the central processing unit, the usage parameters of the memory, the network communication rate and the status of the currently used application, etc.) in the process of providing cloud services to generate an operation log.

[0035] The execution entity can determine whether the cloud phone is currently at a risk point by checking the operation log of the cloud phone. The risk point can be understood as a state or point where there is a risk of failure (expected by the user and too high compared to the normal standard). The execution entity can determine whether the cloud phone is currently at a risk point by comparing the similarity of at least part of the log data in the operation log with the reference log data. The reference log data can be determined based on the historical log data of historical failures. For example, when the currently running cloud phone and / or other cloud phones that meet the requirements of similarity with the currently running cloud phone (for example, hardware parameter similarity) have historical failures in their historical operation, the historical data of their historical failures is determined. For example, the time point when the failure occurred in the historical operation of the cloud phone can be used as a reference, and a preset time period before the failure occurred can be determined as a "risk interval" or "risk duration". Then, the historical log data in the "risk interval" is taken out and retained as reference log data.

[0036] Subsequently, the executing entity can determine whether the current cloud phone is at a "risk point" by comparing the log data in the current cloud phone's operation log with the reference log data for similarity. In other words, the executing entity can determine whether the current cloud phone is at a "risk point" by analyzing whether the reference log data is "reproduced" in the current cloud phone's operation log.

[0037] It should be understood that in some embodiments, the execution entity can also provide monitoring and maintenance services for "multiple cloud phones" simultaneously. For example, the execution entity can simultaneously check the corresponding operation logs of multiple cloud phones to determine whether there is a "target cloud phone" at risk. Accordingly, the execution entity can, or control the target cloud phone to perform the subsequent maintenance process described in detail below.

[0038] For ease of understanding, the state of being at a risk point can be simply understood as the operating state of the cloud phone within the "preset period of time" before the failure occurs. Therefore, by detecting within the "preset period of time", it can be determined whether the cloud phone is likely to fail, that is, whether the cloud phone is at a "risk point". If it is, it is determined that the cloud phone will fail with high confidence (for example, the failure occurrence rate and occurrence confidence are higher than the occurrence rate and confidence threshold pre-configured by the operation and maintenance personnel).

[0039] For example, if the execution entity determines that the target log data in the current cloud phone's operation log is identical to the reference log data within a period of time or the similarity exceeds a preset similarity threshold, the execution entity can determine that the cloud phone is at a risk point during this "period of time". In practice, the similarity threshold can be configured based on recognition accuracy. For example, when the cloud phone is expected to be maintained extensively and frequently, it can be configured with a first similarity threshold. When the cloud phone is expected to be maintained more accurately, it can be configured with a second similarity threshold with a value higher than the first similarity threshold.

[0040] It should be noted that the reference log data can usually be obtained directly from a local storage device by the execution subject. In some scenarios, it can also be obtained from a non-local storage device (such as Figure 1 The local storage device can be a data storage module provided in the execution subject, such as a server hard disk. In this case, the reference log data can be quickly read locally. The non-local storage device can also be any other electronic device configured to store data, such as some user terminals. In this case, the execution subject can obtain the required reference log data by sending a obtain command to the electronic device.

[0041] It should be understood that the above only uses "server 105" as an example of "cloud phone". In some scenarios, if the user-side device in the "cloud phone" architecture is also allowed and required to be maintained by the user, the user-side device can be maintained in a similar manner (for example, the operation log of the "cloud phone" exemplified as the user device is detected to determine whether it is at a risk point). The explanation will not be repeated here.

[0042] In some optional implementations of this embodiment, in the process of detecting the cloud phone log, in order to improve the detection efficiency and detection quality, the execution subject may choose to use some "key parameters" in the operation log as target parameters to perform the detection. For example, the execution subject may choose to use at least one of the physical machine hardware operation parameters, application package name information, operation script information, and communication parameters with the user device as target parameters to perform the detection to improve the detection quality and detection quality. That is, when the execution subject detects the cloud phone's operation log and determines whether the cloud phone is currently at a risk point, it may choose to detect the target parameters in the cloud phone's operation log to determine whether the cloud phone is currently at a risk point. In this way, it is possible to avoid wasting resources due to the collection of too many parameters and interfering with the analysis of whether it is at a "risk point".

[0043] For example, the physical machine hardware operating parameters may include the processor occupancy and operating temperature that provides computing power, etc., the application package name information may include the name and version number of the application currently being used by the cloud phone, etc., the running script information may include the name of the script that has been loaded by the cloud phone and the name of the script currently being executed in the cloud phone, etc., and the communication parameters with the user device may include the name of the communication node used between the user, the communication channel used, and the communication rate of the communication channel, etc.

[0044] In some embodiments, a data model or analysis model can be pre-built based on historical log data, and used as a reference for the log data. Accordingly, the execution entity can compare the log data with the data model or analysis model to determine whether the cloud phone is currently at risk, thereby improving detection quality.

[0045] Step 202: In response to the cloud phone currently being at a risk point, analyzing the target log data to determine the risk type of the risk point;

[0046] On the basis of step 201, this step is intended to be carried out by the above-mentioned execution subject, when it is determined that the cloud phone (or the target cloud phone discussed above) is at a risk point, that is, when it is determined that the target cloud phone "may fail", the execution subject analyzes the target log data used when determining that the cloud phone is currently at a risk point to determine the risk type of the risk point. For example, if the execution subject determines that the cloud phone is at a risk point based on the log data of the [x1, x2] time period, the execution subject can analyze the log data of the [x1, x2] time period to determine the risk type of the risk point. Generally, the risk type of the risk point can correspond to the type of subsequent failure. For example, when the reference log data is determined based on a type A failure, the risk type can correspond to a type A failure. In some embodiments, the execution subject can also determine the possible failure based on an independent analysis of the "target log data" and use the analysis result as the risk type. For example, the execution subject may determine that the risk type based on the analysis of the target log data may be a hardware failure, an application failure, a script failure, etc. For example, the execution subject may determine that the processor occupancy rate and operating temperature are abnormal based on the “target log data”, and accordingly, the execution subject determines that the risk type is “hardware failure”.

[0047] Step 203: Determine a target maintenance strategy for the cloud phone based on the risk type;

[0048] On the basis of step 202, this step is intended to determine the target maintenance strategy for the cloud phone after the above-mentioned execution entity determines the risk type. In the embodiment of the present disclosure, the corresponding maintenance strategy can be determined in advance based on the risk type. For example, a group of maintenance strategies can be determined in advance, and each maintenance strategy included in a group of maintenance strategies can correspond to different risk types, or in other words, after the maintenance strategy is configured based on the possible risk types, the group of maintenance strategies is actually constituted. For example, for risk types such as hardware failures, the maintenance strategy can be to reconfigure another cloud phone (server), and for application failures, the maintenance strategy that can be configured is to terminate the application, update the application, provide the necessary plug-ins for the application, and so on.

[0049] In some embodiments, a preconfigured risk type-maintenance policy mapping table can be used to provide and record the correspondence between risk types and maintenance policies. Accordingly, the executing entity can use this risk type-maintenance policy mapping table to determine the target maintenance policy corresponding to the risk type. Thus, by providing a configured risk type-maintenance policy mapping table, the executing entity can have self-maintenance capabilities, enabling it to spontaneously perform maintenance on the cloud phone, thereby reducing maintenance costs.

[0050] Accordingly, the executing entity can select a target maintenance strategy corresponding to the risk type from a set of maintenance strategies, in order to maintain the cloud phone based on the instructions of the target maintenance strategy, so as to perform maintenance and processing in advance for "possible future failures".

[0051] For example, an application failure caused by incompatibility between server 105 and the application can be addressed using the targeted maintenance strategy of "replacing the server." For example, an application failure caused by an incompatible application version or a lack of environmental controls can be addressed using the targeted maintenance strategy of "issuing version patches and configuring support controls." For example, a "hardware failure" caused by insufficient computing power due to partial processor damage can be addressed using the targeted maintenance strategy of "suspending or temporarily suspending some operations."

[0052] Step 204: Execute the target maintenance strategy.

[0053] Based on step 203, this step is intended to have the aforementioned execution entity, after determining the target maintenance strategy, execute and implement the target maintenance strategy based on the instructions of the target maintenance strategy to achieve maintenance of the cloud phone. For example, the target maintenance strategy may be that when reconfiguring another cloud phone (server), the execution entity can migrate the locally stored user data to the other cloud phone, and after the migration is complete, control the user device used by the user to establish communication with the other cloud phone, so as to utilize the other cloud phone to provide cloud phone services to the user.

[0054] For example, the execution subject may construct an execution process based on the content indicated by the target maintenance policy, and execute the target maintenance policy by executing the execution process to achieve maintenance work on the cloud phone.

[0055] The method for maintaining a cloud phone provided by the embodiment of the present disclosure is based on the detection and analysis of the operation log of the cloud phone to determine whether the cloud phone is at risk of failure, and actively intervenes in the cloud phone and performs maintenance when there is a risk to improve the operation stability of the cloud phone.

[0056] In some optional implementations of this embodiment, the reference log data is determined based on the following method: obtaining the historical operation log recorded when the reference cloud phone occurs a reference historical failure; determining the reference log data based on the historical log data within the target time interval in the historical operation log, and determining the reference log data, wherein the end point of the target time interval is located at the time when the reference historical failure occurs.

[0057] Specifically, the execution subject can obtain the historical operation log recorded when the reference cloud phone has a reference historical failure after determining the reference cloud phone (for example, the current cloud phone discussed above and other cloud phones whose configuration similarity with the current cloud phone meets the requirements). Then, the execution subject can determine the first moment when the failure actually occurred in the historical operation log, and use the first moment as the end point to "draw" a target duration interval in the historical time direction, that is, the end point of the target duration interval is at the moment when the reference historical failure occurred. The length of the target duration interval can be determined based on a pre-configured "time length with reference value". In some embodiments, based on the differences in the configurations of the cloud phones, the "time length with reference value" can be determined differently, or in other words, the "time length with reference value" can actually correspond to the configuration of the cloud phone.

[0058] Furthermore, the execution entity can collect historical log data within the target time interval from the historical operation log and use it directly as reference log data, or obtain reference log data by analyzing and processing these historical log data. Thus, the execution entity can determine the state of the cloud phone before the failure by analyzing the historical operation log of the cloud phone that has already failed, so that it can subsequently determine whether the cloud phone is likely to fail based on the comparison of the current operating state of the cloud phone with the state of the cloud phone before the failure, thereby achieving "pre-detection" of the failure. Thus, through "pre-detection", the execution entity can perform maintenance in advance for cloud phones that may fail and are at risk points to ensure the operational stability of the cloud phone system.

[0059] In some optional implementations of this embodiment, as discussed above, when determining the reference log data based on the historical log data within the target time interval in the historical operation log, the reference log data can actually be obtained based on the processing and analysis of the historical log data to enhance the value and availability of the reference log data. For example, it is possible to fit a reference data curve based on the historical log data within the target time interval in the historical operation log, and use the reference data curve as the reference log data. Thus, when the subsequent execution subject performs the comparison, it can fit the log data into the log data curve, and then determine whether the reference data curve is included in the log data curve based on the comparison between the log data curve and the reference data curve (for example, comparing the similarity of the two curves, the overlap of the overlapping parts, etc. to see whether the threshold requirements are met), and then determine whether the cloud phone is at a risk point. For example, if the reference data curve is included in the log data curve, the cloud phone can be determined to be at a risk point in the included part. Thus, the curve fitting method can be used to aggregate and collect data to facilitate comparison and improve detection efficiency.

[0060] In some embodiments, in order to better ensure the stable operation of the cloud phone, the detection scenarios and detection capabilities of the execution subject can be broadened by expanding the scope of historical fault collection. For example, by analyzing and summarizing the historical log data of multiple historical faults, the execution subject can have the ability to detect the risks corresponding to multiple historical faults. Therefore, it is possible to select clustered historical faults collected and configure reference log data based on the "classified" historical fault dimension. In this way, while improving the detection capability of the execution subject, it is possible to avoid wasting computing resources due to the execution of "repeated types of historical faults" detection.

[0061] For ease of understanding, we will combine Figure 3 Provide explanation. Figure 3 A flowchart of a process for determining reference log data provided by an embodiment of the present disclosure, wherein process 300 includes the following steps:

[0062] Step 301: Obtain historical operation logs recorded when various reference historical failures occurred in the reference cloud phone;

[0063] Specifically, similar to the method discussed above, after determining the reference cloud phone, the historical operation logs recorded when each reference historical failure occurred in the reference cloud phone can be obtained.

[0064] Step 302: fitting a reference data curve based on the historical log data within the target duration interval in the historical operation log;

[0065] Specifically, similar to the method discussed above, for multiple reference historical faults, the reference data curve corresponding to the reference historical faults can be fitted based on the historical log data within the target time interval in the historical operation log corresponding to the reference historical faults.

[0066] Step 303 , clustering the multiple reference historical faults based on similarity comparison results of the reference data curves corresponding to the multiple reference historical faults to obtain at least one clustering result;

[0067] Specifically, clustering is performed based on the similarity between the reference data curves corresponding to the reference historical faults obtained in step 302, and at least one clustering result is obtained. For example, a cluster center can be determined from the reference data curves that have not been clustered. Clustering is then performed based on the similarity between each historical reference route curve and the cluster center. Accordingly, a corresponding clustering result can be ultimately obtained based on the cluster center.

[0068] In practice, the clustering result usually corresponds to the “fault type” and the “fault transmission reason”. For example, the clustering result may be “hardware fault”.

[0069] Step 304: fitting each reference data curve belonging to the same clustering result to obtain a cluster reference data curve corresponding to the clustering result;

[0070] Specifically, after obtaining the clustering results based on step 304 above, the reference data curves belonging to the same clustering result can be fitted to obtain a cluster reference data curve corresponding to the clustering result. Specifically, the cluster reference data curve can be, for example, an average of the reference data curves, or a curve determined based on the "overlap" between the reference data curves. Thus, the cluster reference data curve can be used to more clearly provide the "features" or "trends" of the log data belonging to a fault category.

[0071] Step 305: Use the clustered reference data curve as reference log data.

[0072] Specifically, the cluster reference data curve can be selected as the reference log data, so that the execution entity can use the cluster reference data curve to use "class" as a reference standard to determine whether the cloud phone is at a risk point.

[0073] In some embodiments, when determining the target maintenance strategy for the cloud phone based on the risk type, in addition to the method of using the risk type-maintenance strategy mapping table discussed above, the method discussed above can also be replaced or supplemented by training a neural network or model. Specifically, the execution entity can pre-configure the initial gradient boosting algorithm model (for example, XGBoost), and then train it with the sample risk type (for example, the risk type determined based on reference historical failures) as input and the sample maintenance strategy (for example, the pre-configured processing strategy corresponding to the risk type) as output to obtain the trained gradient boosting algorithm model. Trained gradient boosting algorithm model. The input risk type can be processed to obtain the target maintenance strategy corresponding to it.

[0074] Accordingly, the executing entity can choose to input the risk type into the trained gradient boosting algorithm model for processing, generating a target maintenance strategy corresponding to the risk type. Thus, the gradient boosting algorithm is used to analyze and determine the maintenance strategy, improving efficiency while leveraging the model's ability to prevent overfitting and high model generalization to improve the accuracy of the target maintenance strategy.

[0075] On the basis of any of the above embodiments, the execution subject can also communicate the risk type and target maintenance strategy to the target device based on a pre-configured and maintained communication address with the target device (for example, the cloud phone's operation and maintenance, management user, for example, the terminal device used by the cloud phone service provider's operation and maintenance personnel), so as to provide the user, such as the operation and maintenance personnel, with the determined risk type and the corresponding target maintenance strategy. In this way, the operation and maintenance personnel can decide whether to execute the "target maintenance strategy" based on the information provided, so as to avoid mishandling caused by the execution subject through manual confirmation and intervention, and improve the operational stability of the cloud phone.

[0076] Accordingly, when the user device returns a confirmation indication for the risk type and the corresponding target maintenance policy provided by the execution subject, the execution subject may actually execute the target maintenance policy in response to the execution confirmation indication communicated back from the target device.

[0077] In some optional implementations of this embodiment, the execution entity may continue to monitor the operating status of the cloud phone after the execution process of the target maintenance policy is completed to determine whether the cloud phone has "actually" avoided the failure based on the execution of the target maintenance policy. For example, the execution entity may continue to monitor the operating status of the cloud phone in response to the completion of the execution process of the target maintenance policy.

[0078] Accordingly, if the executing entity detects that a target failure corresponding to the risk type occurs in the cloud phone, that is, after the executing entity determines that the execution process of the target maintenance policy is completed, the execution result of the "target maintenance policy" actually fails to avoid the occurrence of failures corresponding to the risk point and risk type, the executing entity can respond to this and determine whether the maintenance policy has been successfully executed based on the analysis of the maintenance log associated with the target maintenance policy. For example, the executing entity can determine whether the maintenance policy has been successfully executed by analyzing the maintenance log corresponding to the execution process of the target maintenance policy, or the "maintenance log" corresponding to the execution process of the target maintenance policy in the log data. For example, the executing entity can determine whether each sub-process in the execution process of the target maintenance policy has been successfully executed and loaded based on the maintenance log.

[0079] Accordingly, the execution entity, in response to the maintenance log indicating that the target maintenance policy was successfully executed, can, for example, communicate a prompt message to the target device in response to determining, based on the maintenance log, that each sub-process in the execution process of the target maintenance policy has been successfully executed. This prompt message indicates that the target maintenance policy needs to be updated. Thus, if the execution entity determines that the target maintenance policy was successfully executed but a fault has not been eliminated or avoided, the execution entity can communicate with, for example, an operations and maintenance personnel to assist them in determining whether the configured maintenance policy is actually "effective" and whether it needs to be updated. This assists personnel in updating maintenance policies that have failed or whose effects do not meet expectations.

[0080] In some optional implementations of this embodiment, the execution entity may further communicate the maintenance log to the target device in response to the maintenance log indicating that the target maintenance policy was not successfully executed (e.g., some sub-processes were not successfully executed). This assists operation and maintenance personnel in using the maintenance log to analyze and understand the reasons why the target maintenance policy was not executed.

[0081] To deepen understanding, this disclosure also provides a specific implementation solution in combination with a specific application scenario, see Figure 4 An architectural diagram of an exemplary architecture 400 is shown.

[0082] In architecture 400, terminal device 103 can be exemplified as the (electronic) device used by maintenance personnel, and server 105 can be exemplified as the cloud server providing cloud phone services (or, in other words, server 105 can be exemplified as a cloud phone). At the same time, for ease of understanding, service 105 can also be exemplified as the execution entity of the cloud phone maintenance method. In other words, while serving as a cloud phone, server 105 can also maintain itself by executing the cloud phone maintenance method discussed above.

[0083] In architecture 400, terminal device 103 can first determine reference log data by executing S401. For example, terminal device 103 can be used by operation and maintenance personnel to determine reference log data based on the analysis results of historical operation logs recorded when a reference cloud phone has a reference historical failure. For example, terminal device 103 can obtain a set of reference log data 420 based on executing S401. Next, terminal device 103 can execute S402 to provide a set of reference log data 420 to server 105 for use by server 105.

[0084] Accordingly, the server 105 may first execute S411 to obtain the local (or local) operation log 430 of the server 105 .

[0085] Then, the server 105 may compare the operation log 430 with a set of reference log data 420 by executing S412 to determine whether the server 105 is currently at a “risk point”.

[0086] Next, server 105 may execute S413 to analyze target log data in operation log 430 (i.e., log data recorded in at least a portion of operation log 430 that is referenced and determined to be used when the server 105 is at a risk point) in response to the server 105 being at a risk point. Accordingly, server 105 may determine the risk type of the risk point based on executing S413.

[0087] Furthermore, the server 105 may execute S414 to determine a target maintenance strategy 435 according to the risk type determined in S413. For example, the target maintenance strategy may be one of a set of maintenance strategies (not shown in the figure).

[0088] Next, the server 105 may execute S415 to execute the target maintenance strategy 435 to implement maintenance work on itself, thereby avoiding the occurrence of failures corresponding to the risk type of the risk point.

[0089] In addition, after executing the target maintenance strategy to perform self-maintenance, that is, after completing S415 , the server 105 may further execute S416 to continuously detect its own operating status.

[0090] Subsequently, if the server 105 finds that the target fault (i.e., the fault corresponding to the risk type of the risk point) still occurs when detecting its operating status, it can execute S417 to obtain the maintenance log 440 when executing the target maintenance policy 435. Then, the server 105 executes S418 to analyze the maintenance log 440 to determine whether the target maintenance policy 435 was successfully executed.

[0091] If the server 105 determines based on S418 that the target maintenance policy 435 is successfully executed, it may choose to execute S419a to communicate prompt information to the terminal device 103 indicating that the target maintenance policy 435 needs to be updated.

[0092] Accordingly, if the server 105 determines based on S418 that the target maintenance policy 435 has not been successfully executed, it may choose to execute S419b to provide the terminal device 103 with a communication maintenance log 440, so that the operation and maintenance personnel on the terminal device 103 side can analyze the maintenance log 440 and assist them in determining the reason why the target maintenance policy 435 has not been successfully executed.

[0093] Further references Figure 5As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a device for maintaining a cloud phone. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0094] like Figure 5 As shown, the apparatus 500 for maintaining a cloud phone in this embodiment may include: a risk point detection unit 501, a risk type determination unit 502, a maintenance strategy determination unit 503, and a maintenance strategy execution unit 504. The risk point detection unit 501 is configured to detect the operation log of the cloud phone and determine whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of historical faults; the risk type determination unit 502 is configured to analyze the target log data in response to the cloud phone currently being at a risk point and determine the risk type of the risk point; the maintenance strategy determination unit 503 is configured to determine a target maintenance strategy for the cloud phone according to the risk type; and the maintenance strategy execution unit 504 is configured to execute the target maintenance strategy.

[0095] In this embodiment, in the apparatus for maintaining a cloud phone 500, the specific processing of the risk point detection unit 501, the risk type determination unit 502, the maintenance strategy determination unit 503 and the maintenance strategy execution unit 504 and the technical effects thereof can be referred to respectively. Figure 2 The relevant descriptions of steps 201-204 in the corresponding embodiment are not repeated here.

[0096] In some optional implementations of this embodiment, the reference log data is determined based on the following method: obtaining the historical operation log recorded when the reference cloud phone occurs a reference historical failure; determining the reference log data based on the historical log data within the target time interval in the historical operation log, wherein the end point of the target time interval is at the time when the reference historical failure occurs.

[0097] In some optional implementations of this embodiment, reference log data is determined based on historical log data in the historical operation log that is within the target time interval, including: fitting a reference data curve based on historical log data in the historical operation log that is within the target time interval; and using the reference data curve as reference log data.

[0098] In some optional implementations of this embodiment, there are multiple reference historical faults, and the reference data curve is used as reference log data, including: clustering the multiple reference historical faults based on the similarity comparison results of the reference data curves corresponding to the multiple reference historical faults to obtain at least one clustering result; fitting each reference data curve belonging to the same clustering result to obtain a cluster reference data curve corresponding to the clustering result; and using the cluster reference data curve as the reference log data.

[0099] In some optional implementations of this embodiment, the risk point detection unit 501 is further configured to detect target parameters in the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point, wherein the target parameters include at least one of the following: physical machine hardware operation parameters, application package name information, operation script information and communication parameters with the user device.

[0100] In some optional implementations of this embodiment, the maintenance strategy determining unit 503 is further configured to determine a target maintenance strategy corresponding to the risk type in a pre-configured risk type-maintenance strategy mapping table.

[0101] In some optional implementations of this embodiment, the maintenance strategy determination unit 503 is further configured to input the risk type into the gradient boosting algorithm model for processing to generate a target maintenance strategy corresponding to the risk type, wherein the gradient boosting algorithm model is pre-trained using sample risk types as input and sample maintenance strategies as output.

[0102] In some optional implementations of this embodiment, the maintenance policy execution unit 504 includes: a maintenance policy communication subunit, configured to communicate the risk type and target maintenance policy to the target device based on a preconfigured communication address; and a maintenance policy execution subunit, executing the target maintenance policy in response to an execution confirmation indication communicated back from the target device.

[0103] In some optional implementations of this embodiment, the device 500 also includes: a cloud phone status detection unit, configured to continuously detect the operating status of the cloud phone in response to the completion of the execution process of the target maintenance policy; a maintenance policy execution detection unit, configured to determine whether the maintenance policy is successfully executed based on the analysis of the maintenance log associated with the target maintenance policy in response to detecting that a target failure corresponding to the risk type occurs in the cloud phone; a maintenance policy update prompt unit, configured to communicate prompt information to the target device in response to the maintenance log indicating that the target maintenance policy is successfully executed, wherein the prompt information is used to indicate that the target maintenance policy needs to be updated.

[0104] In some optional implementations of this embodiment, the apparatus 500 further includes: a maintenance log communication unit configured to communicate the maintenance log to the target device in response to the maintenance log indicating that the target maintenance policy is not successfully executed.

[0105] This embodiment exists as an apparatus embodiment corresponding to the above-mentioned method embodiment. The apparatus for maintaining a cloud phone provided in this embodiment determines whether the cloud phone is at risk of failure based on the detection and analysis of the cloud phone's operation log, and proactively intervenes in and performs maintenance on the cloud phone when there is a risk, so as to improve the operational stability of the cloud phone.

[0106] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0107] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided as examples only and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0108] like Figure 6 As shown, the device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the device 600 can also be stored in the RAM 603. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0109] Various components in device 600 are connected to I / O interface 605, including an input unit 606, such as a keyboard, mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a magnetic disk, optical disk, etc.; and a communication unit 609, such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows device 600 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0110] The computing unit 601 can be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 601 performs the various methods and processes described above, such as the method for maintaining a cloud phone. For example, in some embodiments, the method for maintaining a cloud phone can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the method for maintaining a cloud phone described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform the method for maintaining a cloud phone by any other appropriate means (e.g., by means of firmware).

[0111] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0112] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0113] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0114] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0115] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0116] A computer system may include a client and a server. The client and server are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host, a host product within a cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosts and virtual private server (VPS) services. Servers may also be classified as distributed system servers or servers integrated with blockchain.

[0117] According to the technical solution of the embodiment of the present disclosure, based on the detection and analysis of the operation log of the cloud phone, it is determined whether the cloud phone is at risk of failure, and when there is a risk, the cloud phone is actively intervened and maintenance is performed to improve the operation stability of the cloud phone.

[0118] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions provided by this disclosure can be achieved. This is not limited herein.

[0119] The above specific embodiments do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.

Claims

1. A method for maintaining a cloud phone, comprising: Detecting the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of the historical fault, and the reference log data is determined based on the following method: obtaining the historical operation log recorded when the reference cloud phone has a reference historical fault; determining the reference log data based on the historical log data in the historical operation log that is within a target time interval, including: fitting a reference data curve based on the historical log data in the historical operation log that is within the target time interval; using the reference data curve as the reference log data, wherein the end point of the target time interval is located at the time of occurrence of the reference historical fault; In response to the cloud phone currently being at the risk point, analyzing the target log data to determine the risk type of the risk point; Determining a target maintenance strategy for the cloud phone based on the risk type; The target maintenance strategy is executed.

2. The method according to claim 1, wherein There are a plurality of reference historical faults, and using the reference data curve as the reference log data includes: performing clustering on the plurality of reference historical faults based on similarity comparison results of the reference data curves corresponding to the plurality of reference historical faults to obtain at least one clustering result; Fitting each reference data curve belonging to the same clustering result to obtain a cluster reference data curve corresponding to the clustering result; The cluster reference data curve is used as the reference log data.

3. The method according to claim 1, wherein The detecting the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point includes: Detect target parameters in the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point, wherein the target parameters include at least one of the following: physical machine hardware operation parameters, application package name information, operation script information and communication parameters with the user device.

4. The method according to claim 1, wherein Determining a target maintenance strategy for the cloud phone according to the risk type includes: In a pre-configured risk type-maintenance strategy mapping table, a target maintenance strategy corresponding to the risk type is determined.

5. The method according to claim 1, wherein Determining a target maintenance strategy for the cloud phone according to the risk type includes: The risk type is input into a gradient boosting algorithm model for processing to generate a target maintenance strategy corresponding to the risk type, wherein the gradient boosting algorithm model is pre-trained using sample risk types as input and sample maintenance strategies as output.

6. The method according to any one of claims 1 to 5, wherein The executing the target maintenance strategy includes: Communicating the risk type and the target maintenance policy to the target device based on a preconfigured communication address; In response to an execution confirmation indication being communicated back from the target device, the target maintenance policy is executed.

7. The method according to claim 6, further comprising: In response to the completion of the execution process of the target maintenance policy, continuously detecting the operating status of the cloud phone; In response to detecting that a target failure corresponding to the risk type occurs in the cloud phone, determining whether the maintenance policy is successfully executed based on an analysis of a maintenance log associated with the target maintenance policy; In response to the maintenance log indicating that the target maintenance policy is successfully executed, a prompt message is communicated to the target device, wherein the prompt message is used to indicate that the target maintenance policy needs to be updated.

8. The method according to claim 7, further comprising: In response to the maintenance log indicating that the target maintenance policy was not successfully executed, the maintenance log is communicated to the target device.

9. A device for maintaining a cloud phone, comprising: A risk point detection unit is configured to detect the operation log of the cloud phone and determine whether the cloud phone is currently at a risk point, wherein the similarity between the target log data associated with the risk point and the reference log data exceeds a preset similarity threshold, and the reference log data is determined based on the historical log data of the historical fault, and the reference log data is determined based on the following method: obtaining the historical operation log recorded when the reference cloud phone has a reference historical fault; determining the reference log data based on the historical log data in the historical operation log that is within a target time interval, including: fitting a reference data curve based on the historical log data in the historical operation log that is within a target time interval; using the reference data curve as the reference log data, wherein the end point of the target time interval is located at the time of occurrence of the reference historical fault; a risk type determination unit, configured to, in response to the cloud phone currently being at the risk point, analyze the target log data and determine the risk type of the risk point; a maintenance strategy determining unit, configured to determine a target maintenance strategy for the cloud phone according to the risk type; The maintenance strategy execution unit is configured to execute the target maintenance strategy.

10. The device according to claim 9, wherein There are a plurality of reference historical faults, and using the reference data curve as the reference log data includes: performing clustering on the plurality of reference historical faults based on similarity comparison results of the reference data curves corresponding to the plurality of reference historical faults to obtain at least one clustering result; Fitting each reference data curve belonging to the same clustering result to obtain a cluster reference data curve corresponding to the clustering result; The cluster reference data curve is used as the reference log data.

11. The device according to claim 9, wherein The risk point detection unit is further configured to detect target parameters in the operation log of the cloud phone to determine whether the cloud phone is currently at a risk point, wherein the target parameters include at least one of the following: physical machine hardware operation parameters, application package name information, operation script information and communication parameters with the user device.

12. The device according to claim 9, wherein The maintenance strategy determination unit is further configured to determine a target maintenance strategy corresponding to the risk type in a pre-configured risk type-maintenance strategy mapping table.

13. The device according to claim 9, wherein The maintenance strategy determination unit is further configured to input the risk type into a gradient boosting algorithm model for processing to generate a target maintenance strategy corresponding to the risk type, wherein the gradient boosting algorithm model is pre-trained using sample risk types as input and sample maintenance strategies as output.

14. The device according to any one of claims 9 to 13, wherein: The maintenance strategy execution unit includes: a maintenance strategy communication subunit configured to communicate the risk type and the target maintenance strategy to a target device based on a preconfigured communication address; The maintenance policy execution subunit executes the target maintenance policy in response to an execution confirmation instruction communicated back from the target device.

15. The apparatus according to claim 14, further comprising: a cloud phone status detection unit, configured to continuously detect the operating status of the cloud phone in response to completion of the execution process of the target maintenance policy; a maintenance policy execution detection unit configured to, in response to detecting that a target failure corresponding to the risk type occurs in the cloud phone, determine whether the maintenance policy is successfully executed based on an analysis of a maintenance log associated with the target maintenance policy; The maintenance policy update prompt unit is configured to communicate prompt information to the target device in response to the maintenance log indicating that the target maintenance policy is successfully executed, wherein the prompt information is used to indicate that the target maintenance policy needs to be updated.

16. The apparatus according to claim 15, further comprising: A maintenance log communication unit is configured to communicate the maintenance log to the target device in response to the maintenance log indicating that the target maintenance policy was not successfully executed.

17. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for maintaining a cloud phone according to any one of claims 1 to 9.

18. A non-transitory computer-readable storage medium storing computer instructions, wherein when the computer instructions are executed by a computer, the steps of the method according to any one of claims 1 to 9 are implemented.

19. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the method for maintaining a cloud phone according to any one of claims 1 to 9.

Images