CN118337611A - 维护云手机的方法、装置、设备、存储介质及程序产品 - Google Patents

Abstract

本公开提供了维护云手机的方法、装置、电子设备、计算机可读存储介质及计算机程序产品，涉及云服务、风险监控和智能运维等人工智能技术领域。该方法的一具体实施方式包括：检测云手机的运行日志，确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；根据风险类型确定针对云手机的目标维护策略；执行目标维护策略。由此，能够在故障发生前对云手机进行干预、执行维护，能够提升云手机的运行稳定性。

Description

维护云手机的方法、装置、设备、存储介质及程序产品

技术领域

本公开涉及计算机技术领域，具体涉及云服务、风险监控和智能运维等人工智能技术领域，尤其涉及维护云手机的方法、装置、电子设备、计算机可读存储介质及计算机程序产品。

背景技术

随着计算机技术的发展，为了提升用户设备一侧的运算能力、使用体验，云手机(Cloud phone)技术应运而生。云手机，就是将云计算技术运用于网络终端服务，通过云服务器来实现“云服务”的手机系统。这种深度结合了网络服务的“手机”，能凭借自带的系统以及厂商架设的网络终端获取更强大的计算能力，来为用户所使用的手机提供更多功能。

在云手机系统下，用户可以使用用户设备来与云手机系统中的(云)服务器、其他终端设备进行通信，以利用其他设备来提供所需要的算力。由此，如何保障用户的使用体验，提升云手机(尤其是，云服务器)的运行稳定性，是值得关注和迫切需求的。

发明内容

本公开实施例提出了一种维护云手机的方法、装置、电子设备、计算机可读存储介质及计算机程序产品。

第一方面，本公开实施例提出了一种维护云手机的方法，包括：检测云手机的运行日志，确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；根据风险类型确定针对云手机的目标维护策略；执行目标维护策略。

第二方面，本公开实施例提出了一种维护云手机的装置，包括：风险点位检测单元，被配置成检测云手机的运行日志，确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；风险类型确定单元，被配置成响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；维护策略确定单元，被配置成根据风险类型确定针对云手机的目标维护策略；维护策略执行单元，被配置成执行目标维护策略。

第三方面，本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，该指令被至少一个处理器执行，以使至少一个处理器执行时能够实现如第一方面中任一实现方式描述的维护云手机的方法。

第四方面，本公开实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使计算机执行时能够实现如第一方面中任一实现方式描述的维护云手机的方法。

第五方面，本公开实施例提供了一种包括计算机程序的计算机程序产品，该计算机程序在被处理器执行时能够实现如第一方面中任一实现方式描述的维护云手机的方法。

本公开实施例提供的维护云手机的方法、装置、电子设备、计算机可读存储介质及计算机程序产品，可以通过检测云手机的运行日志，来确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；然后，响应于目标云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；然后，根据风险类型确定针对目标云手机的目标维护策略；最后，执行目标维护策略。

本公开基于对云手机的运行日志的检测和分析，来确定云手机是否存在发生故障的风险，并在存在风险时主动地对云手机进行干预、执行维护，以提升云手机的运行稳定性。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：

图1是本公开可以应用于其中的示例性系统架构；

图2为本公开实施例提供的一种维护云手机的方法的流程图；

图3为本公开实施例提供的一种确定参考日志数据的过程的流程图；

图4为本公开实施例提供的在一应用场景下的用于维护云手机的示例性架构的架构示意图；

图5为本公开实施例提供的一种维护云手机的装置的结构框图；

图6为本公开实施例提供的一种适用于执行维护云手机的方法的电子设备的结构示意图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。

此外，本公开涉及的技术方案中，所涉及的用户个人信息的(例如本公开后续涉及的运行日志和历史日志等等)获取、存储、使用、加工、运输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

图1示出了可以应用本公开的维护云手机的方法、装置、电子设备及计算机可读存储介质的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。例如，系统架构100可以被体现为云手机架构，服务器105可以被示例为提供云手机的“云服务器”，用户(图中未示出)可以通过终端设备101、102、103作为用户设备，来与服务器105进行通信，以使用和实现“云手机”。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。例如，用户可以通过在终端设备101、102、103中的应用，来向服务器105提供运算素材，并利用服务器105的算力来对这些运算素材进行处理后，由服务器105向终端设备101、102、103返回处理结果。

在一些场景中，终端设备101、102、103也可以被体现为用户对云手机(或者说，云手机的服务器)进行管理的(电子)设备。例如，终端设备101、102、103也可以被云服务和云手机服务的提供方的运维人员所使用，以利用终端设备101、102、103与服务器105进行通信，以实现对服务器105，或者说，云手机的管理和维护(例如，向服务器105提供用于执行更新的文件)。

相应地，终端设备101、102、103和服务器105上可以安装有各种用于实现两者之间进行信息通讯的应用，例如云服务类应用、远程管理类应用、即时通讯类应用等。

终端设备101、102、103和服务器105可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等；当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中，其可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块，在此不做具体限定。当服务器105为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器；服务器为软件时，可以实现成多个软件或软件模块，也可以实现成单个软件或软件模块，在此不做具体限定。

服务器105通过内置的各种应用可以提供各种服务，以可以提供远程运维的远程管理类应用为例，服务器105在运行该远程管理类应用时可实现如下效果：首先，服务器105可以通过网络104从终端设备101、102、103中接收远程运维指示，并基于该远程运维指示，来检测云手机的运行日志(如果云手机的云算力是利用服务器105所提供的，则该“运行日志”实际上可以服务器105本地所存储的记录服务器105运行状况的运行日志)，确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；然后，服务器105响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；然后，服务器105根据风险类型确定针对云手机的目标维护策略；最后，执行目标维护策略。

需要指出的是，服务器105除响应于从终端设备101、102、103通过网络104传输的远程运维指示来执行上述过程以外，还可以基于预先的配置，或者由用户所指示操作来执行上述过程。例如，用户可以通过直接与服务器105进行的交互，来指示服务器执行“检测云手机的运行日志，确定云手机当前是否处于风险点位”，以及执行在此之后的过程。又例如，服务器105可以基于预先的配置(例如，从服务器105被启动之后持续地，或者周期性地)，来执行“检测云手机的运行日志，确定云手机当前是否处于风险点位”，以及执行在此之后的过程。在此种情况下，示例性系统架构100也可以不包括终端设备101、102、103和网络104。

由于获取、检测云手机的运行日志可能需要占用较多的运算资源和较强的运算能力，因此本公开后续各实施例所提供的维护云手机的方法一般由拥有较强运算能力、较多运算资源的服务器105来执行，相应地，维护云手机的装置一般也设置于服务器105中。但同时也需要指出的是，在终端设备101、102、103也具有满足要求的运算能力和运算资源时，终端设备101、102、103也可以通过其上安装的远程管理类应用完成上述本交由服务器105做的各项运算，进而输出与服务器105同样的结果。尤其是在同时存在多种具有不同运算能力的终端设备的情况下，但远程管理类应用判断所在的终端设备拥有较强的运算能力和剩余较多的运算资源时，可以让终端设备来执行上述运算，从而适当减轻服务器105的运算压力，相应的，维护云手机的装置也可以设置于终端设备101、102、103中。类似地，在一些场景中，如果由终端设备101、102、103通过执行维护云手机的方法来实现对其本地的维护(例如，终端设备101、102、103作为其他的终端设备的“云服务提供端”)，则示例性系统架构100也可以不包括终端设备服务器105。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

请参考图2，图2为本公开实施例提供的一种维护云手机的方法的流程图，其中流程200包括以下步骤：

步骤201，检测云手机的运行日志，确定云手机当前是否处于风险点位；

本步骤旨在由维护云手机的方法的执行主体(例如图1所示的服务器105)来检测云手机的运行日志。为方便理解，在本公开的实施例中示例性地以服务器105作为提供云服务的云服务器进行示例，相应地，服务器105可以被示例为维护云手机的方法的执行主体，以“自动、自发地”对其本地的运行状况进行检测和维护，以实现“维护云手机，保障云手机运行稳定”的目的。执行主体可以在其本地维护有云手机的运行日志，例如，执行主体可以在提供云服务的过程中，持续地和/或周期地获取云手机的运行数据(例如，中央处理器的使用参数、内存的使用参数、网络通信速率和当前正在被使用的应用的情况等等)，以生成运行日志。

执行主体可以通过对云手机的运行日志进行检测，以确定云手机当前是否处于风险点位。风险点位可以被理解为，存在(用户所预期的、相较于普通标准过高的)故障发生风险的状态或者点位。执行主体可以通过比较运行日志中至少部分的日志数据与参考日志数据的相似度的方式，来确定云手机当前是否处于风险点位。参考日志数据可以基于历史故障的历史日志数据被确定，例如，预先可以当前运行的云手机和/或与该当前运行的云手机相似度满足要求(例如，硬件参数相似度)的其他云手机在历史运行中发生历史故障时，其发生历史故障的历史数据被确定。例如，可以在云手机在历史运行过程中，发生故障时的时刻点为基准，将发生该故障之前的一段预设时长确定为“风险区间”、“风险时长”。然后，将位于“风险区间”中的历史日志数据取出，作为参考日志数据留存。

后续，执行主体可以通过比较当前云手机的运行日志中的日志数据是否与参考日志数据相似度的方式，来确定当前云手机是否处于“风险点位”。或者说，执行主体可以通过分析参考日志数据是否在当前云手机的运行日志中被“复现”的方式，来确定当前云手机是否处于“风险点位”。

应当理解的是，在一些实施例中，执行主体也可以同时为“多个云手机”提供监测、维护服务，例如，执行主体可以同时对多个云手机各自对应的运行日志进行检测，以确定是是否有处于风险点位的“目标云手机”。相应地，执行主体可以对，或者，控制目标云手机执行下文将详细说明的后续维护过程。

为方便理解，处于风险点位的状态，可以被简单地理解为云手机处于故障发生之前的“该一段预设时长”内，云手机所处于的运行状态。由此，可以通过对“该一段预设时长”内的检测，来确定云手机是否可能会发生故障，即，云手机是否处于“风险点位”，如处于，则确定云手机高可信度地会发生故障(例如，故障发生率、发生可信度高于运维人员预先配置的发生率、可信度阈值)。

例如，执行主体如果确定当前云手机的运行日志中存在一段时间内的目标日志数据与参考日志数据相同或者相似度超过预设的相似度阈值，则执行主体可以确定该“一段时间内”云手机处于风险点位。在实践中，该相似度阈值可以基于识别精度来被配置，例如，在期望云手机广泛地、频繁地被执行维护时，其可以被配置第一相似度阈值，在期望云手机被更精准地进行维护时，其可以被配置一个数值高于第一相似度阈值的第二相似度阈值。

需要指出的是，参考日志数据通常可以由上述执行主体直接从本地的存储设备获取，在一些场景中，其也可以从非本地的存储设备(例如图1所示的终端设备101、102、103)中被获取。本地的存储设备可以是设置在上述执行主体内的一个数据存储模块，例如服务器硬盘，在此种情况下，参考日志数据可以在本地快速读取到；非本地的存储设备还可以为其它任何被设置用于存储数据的电子设备，例如一些用户终端等，在此情况下，上述执行主体可以通过向该电子设备发送获取命令来获取所需的参考日志数据。

应当理解的是，上述仅以“服务器105”来示例“云手机”，在一些场景中，如果“云手机”架构中的用户侧的设备也被用户所允许、需求进行维护，则可以以类似地方式，来对用户侧的设备执行维护(例如，检测被示例为用户设备的“云手机”的运行日志，以确定其是否处于风险点位)，此处不再重复说明。

在本实施例的一些可选的实现方式中，在对云手机日志进行检测的过程中，为提升检测效率和检测质量，执行主体可以选择将运行日志中的一些“关键参数”作为目标参数，来执行检测。例如，执行主体可以选择将例如物理机硬件运行参数、应用包名信息、运行脚本信息和与用户设备的通信参数中的至少一项作为目标参数，执行检测，以提升检测质量和检测质量。即，执行主体在检测云手机的运行日志，确定云手机当前是否处于风险点位时，可以选择检测云手机的运行日志中的目标参数的方式，来确定云手机当前是否处于风险点位。由此，以避免采集了过多地参数造成资源浪费、对是否处于“风险点位”的分析产生干扰。

例如，物理机硬件运行参数可以包括提供运算能力的处理器占用率和运行温度等等，应用包名信息可以包括当前正在被云手机所使用的应用的名称和版本号等等，运行脚本信息可以包括已经被云手机加载的脚本和当前正在云手机中被执行的脚本的名称等等，与用户设备的通信参数可以包括与用户之间所使用的通信节点名称、使用的通信信道和通信信道的通信速率等等。

在一些实施例中，预先也可以选择基于历史日志数据来构建数据模型、分析模型，并以数据模型、分析模型作为参考日志数据。相应地，执行主体可以通过日志数据与该数据模型、分析模型的比较，来确定云手机当前是否处于风险定位，由此，以提升检测质量。

步骤202，响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；

在步骤201的基础上，本步骤旨在由上述执行主体在确定云手机(或者说，上文所讨论的目标云手机)处于风险点位的情况下，即，确定目标云手机“可能将发生故障”，执行主体对确定云手机当前处于风险点位时所使用的目标日志数据进行分析，以确定该风险点位的风险类型。例如，执行主体是基于[x1，x2]时间段的日志数据确定云手机处于风险点位的，则执行主体可以对[x1，x2]时间段的日志数据进行分析，以确定风险点位的风险类型。通常，风险点位的风险类型可以与后续发生的故障的类型相对应，例如，在基于A类型的故障确定出参考日志数据的情况下，该风险类型可以对应于A类型的故障。在一些实施例中，执行主体也可以基于对“目标日志数据”的独立分析，来确定可能发生的故障，并将分析结果作为风险类型。例如，执行主体可能基于对目标日志数据的分析出风险类型可能是硬件故障、应用故障、脚本故障等等。例如，执行主体可以基于“目标日志数据”确定处理器占用率和运行温度异常，相应地，执行主体确定风险类型为“硬件故障”。

步骤203，根据风险类型确定针对云手机的目标维护策略；

在步骤202的基础上，本步骤旨在由上述执行主体在确定风险类型后，来确定针对云手机的目标维护策略。在本公开的实施例中，可以预先基于风险类型确定有对应的维护策略。例如，预先可以确定一组维护策略，一组维护策略其中所包括的各个维护策略可以对应与不同的风险类型，或者说，基于可能发生的风险类型在配置维护策略后，实际构成该一组维护策略。例如，针对例如硬件故障的风险类型，维护策略可以是重新配置一个其他的云手机(服务器)，针对应用故障，则可以配置的维护策略为终止应用、更新应用、为应用提供所必须插件等等。

在一些实施例中，可以通过预先配置风险类型-维护策略映射表的方式，来提供、记录风险类型和维护策略之间的对应关系。相应地，执行主体可以通过这样的风险类型-维护策略映射表来确定与风险类型对应的目标维护策略。由此，可以通过提供配置风险类型-维护策略映射表的方式，使得执行主体具有自维护能力，能够自发地对云手机执行维护，降低维护成本。

相应地，执行主体可以从一组维护策略中选取与风险类型所对应的目标维护策略，以期基于该目标维护策略的指示来维护云手机，以对“未来可能发生的故障”提前执行维护、处理。

例如，对于因服务器105与应用不适配所导致的应用故障，其可以通过“更换服务器”的目标维护策略被维护。例如，对于因应用版本不适格、缺少环境控件所导致的应用故障，其可以通过“下发版本补丁、配置支持控件”的目标维护策略被维护。例如，对于因处理器部分损坏所产生运算能力不足所导致的“硬件故障”，则可以通过“中止、暂缓部分运算”的目标维护策略被维护。

步骤204，执行目标维护策略。

在步骤203的基础上，本步骤旨在由上述执行主体在确定出目标维护策略后，基于该目标维护策略的指示来执行、实现该目标维护策略，以实现对云手机的维护。例如，目标维护策略可以是重新配置一个其他的云手机(服务器)时，执行主体可以将本地所存有的用户数据迁移至该其他的云手机，并在完成迁移后控制用户所使用的用户设备与该其他的云手机建立通信，以利用该其他的云手机来为用户提供云手机服务。

例如，执行主体可以基于目标维护策略所指示的内容构建执行进程，并通过执行该执行进程的方式来执行目标维护策略，以实现对云手机的维护工作。

本公开实施例提供的维护云手机的方法，基于对云手机的运行日志的检测和分析，来确定云手机是否存在发生故障的风险，并在存在风险时主动地对云手机进行干预、执行维护，以提升云手机的运行稳定性。

在本实施例的一些可选的实现方式中，参考日志数据基于以下方式被确定：获取参考云手机发生参考历史故障时所被记录的历史运行日志；基于历史运行日志中位于目标时长区间内的历史日志数据，确定参考日志数据，确定参考日志数据，其中，目标时长区间的区间终点位于参考历史故障的发生时刻。

具体地，执行主体可以在确定参考云手机(例如，上文所讨论的当前的云手机以及与该当前的云手机的配置相似度满足要求的其他云手机)后，获取参考云手机发生参考历史故障时所被记录的历史运行日志。然后，执行主体可以在该历史运行日志中确定实际发生故障的第一时刻，并以该第一时刻为终点，向历史时间方向“划取”一个目标时长区间，即，目标时长区间的区间终点位于参考历史故障的发生时刻。目标时长区间的长度可以基于预先配置的“有参考价值的时间长度”来被确定。在一些实施例中，基于云手机的配置的差异，“有参考价值的时间长度”可以被差异性地确定，或者说，“有参考价值的时间长度”实际可以与云手机的配置所对应。

进一步地，执行主体可以采集历史运行日志中位于目标时长区间内的历史日志数据，并将其直接作为参考日志数据，或者通过对这些历史日志数据的分析和处理，来得到参考日志数据。由此，执行主体可以通过对已经发生故障的云手机的历史运行日志的分析，来确定故障发生前的云手机的状态，以使得后续可以基于云手机当前的运行状态与该故障发生前的云手机的状态的比较，确定云手机是否可能将发生故障，以实现对发生故障的“预检测”。由此，通过“预检测”，执行主体可以对于可能发生故障、处于风险点位的云手机提前地执行维护，以保障云手机系统的运行稳定性。

在本实施例的一些可选的实现方式中，如上文所讨论的，在基于历史运行日志中位于目标时长区间内的历史日志数据，确定参考日志数据时，实际上可以基于对历史日志数据的加工、分析，来得到参考日志数据，以提升参考日志数据的价值和可用性。例如，可以选择基于历史运行日志中位于目标时长区间内的历史日志数据，拟合参考数据曲线，并将参考数据曲线作为参考日志数据。由此，后续执行主体在执行比较时，可以将日志数据同样拟合成日志数据曲线后，基于日志数据曲线和参考数据曲线之间的比较(例如，比较两条曲线的相似度、重合部分的重合度等是否达到阈值要求)的方式，来确定参考数据曲线是否被包括于日志数据曲线之中，进而确定是否存在云手机是否处于风险点位。例如，如果参考数据曲线被包括于日志数据曲线之中，则云手机在该被包括的部分可以被确定为处于风险点位。由此，利用可以利用拟合曲线的方式来汇总、收集数据，来便利比较和提升检测效率。

在一些实施例中，为了更好地保障云手机运行稳定，可以通过扩宽历史故障收集范围的方式，来扩宽执行主体的检测场景和检测能力。例如，可以通过对多个历史故障的历史日志数据的分析和总结，来使得执行主体可以对多个历史故障所对应的风险均具有检测能力。由此，可以选择聚类收集到的历史故障，以“分类”的历史故障维度，配置参考日志数据，由此，以提升执行主体检测能力的同时，避免因执行“重复类型的历史故障”的检测导致浪费运算资源。

为方便理解，将结合图3进行说明。图3为本公开实施例提供的一种确定参考日志数据的过程的流程图，其中流程300包括以下步骤：

步骤301，获取参考云手机发生各个参考历史故障时所被记录的历史运行日志；

具体地，与上文所讨论的方式相类似，可以在确定参考云手机后，获取参考云手机发生各个参考历史故障时所被记录的历史运行日志。

步骤302，基于历史运行日志中位于目标时长区间内的历史日志数据，拟合参考数据曲线；

具体地，与上文所讨论的方式相类似，可以针对多个参考历史故障，分别基于参考历史故障对应的历史运行日志中位于目标时长区间内的历史日志数据，拟合与参考历史故障所对应的参考数据曲线。

步骤303，基于多个参考历史故障各自对应的参考数据曲线的相似度比较结果，对多个参考历史故障执行聚类，得到至少一个聚类结果；

具体地，在基于上述步骤302得到参考历史故障各自对应的参考数据曲线的相似度执行聚类，并得到至少一个聚类结果。例如，可以从未被执行聚类的参考数据曲线中确定一个聚类中心，然后基于各个历史参考路线曲线与该聚类中心的相似度，执行聚类。相应地，可以基于该聚类中心，最终得到对应的聚类结果。

在实践中，该聚类结果通常与“故障的类型”和“故障发送的原因”所实际对应，例如，聚类结果可以是“硬件故障”。

步骤304，拟合属于同一个聚类结果的各个参考数据曲线，得到与聚类结果对应的聚类参考数据曲线；

具体地，在基于上述步骤304得到聚类结果后，可以将属于同一个聚类结果的各个参考数据曲线拟合，以得到与该聚类结果所对应的聚类参考数据曲线。即，聚类参考数据曲线可以例如平均各个参考数据曲线，或基于各个参考数据曲线之间所具有的“重合部分”来确定出的曲线。由此，以利用聚类参考数据曲线来更明显地提供属于一个故障类别下的日志数据“特征”，或者说，“趋势”。

步骤305，将聚类参考数据曲线作为参考日志数据。

具体地，可以选择将聚类参考数据曲线作为参考日志数据，由此，以使得执行主体可以利用聚类参考数据曲线以“类”作为参考标准，来确定云手机是否处于风险点位。

在一些实施例中，在根据风险类型确定针对云手机的目标维护策略时，除上文所讨论的利用风险类型-维护策略映射表的方式外，还可以通过训练神经网络、模型的方式，作为上文所讨论的方式的替代或者补充。具体地，执行主体可以预先配置初始的梯度增强算法模型(例如，XGBoost)后，以样本风险类型(例如，基于参考历史故障确定出的风险类型)作为输入、样本维护策略(例如，预先配置的对应于风险类型的处理策略)作为输出，对其进行训练，以得到训练后的梯度增强算法模型。训练后的梯度增强算法模型。可以对输入的风险类型进行处理，以得到与其对应的目标维护策略。

相应地，执行主体可以选择将风险类型输入至该训练好的梯度增强算法模型进行处理，生成与风险类型对应的目标维护策略。由此，利用梯度增强算法来分析、确定维护策略，以提升效率的同时，利用模型具有的防止过拟合能力和高模型泛化能力来提升目标维护策略的准确度。

在上述任一实施例的基础上，执行主体还可以基于预先配置、维护有与目标用户设备(例如，云手机的运维、管理用户，例如，云手机服务提供商的运维人员所使用的终端设备)的通信地址，将风险类型和目标维护策略通信至目标用户设备，以向例如运维人员的用户提供确定出的风险类型和对应的目标维护策略。由此，运维人员可以基于被提供的信息，来决策是否执行“目标维护策略”，以通过人工确认、介入的方式，避免执行主体所产生的误处理，提升云手机运行稳定性。

相应地，在用户设备针对执行主体提供的风险类型和对应的目标维护策略返回有确认指示时，执行主体可以响应于从目标设备通信回执行确认指示，实际执行目标维护策略。

在本实施例的一些可选的实现方式中，执行主体在目标维护策略的执行进程完成后，仍可以持续检测云手机的运行状态，以确定云手机实际上是否基于目标维护策略的执行而“实际地”避免了故障。例如，执行主体可以响应于目标维护策略的执行进程完成，持续检测云手机的运行状态。

相应地，执行主体如果检测到云手机发生与风险类型对应的目标故障，即，执行主体在确定目标维护策略的执行进程完毕后，“目标维护策略”的执行结果实际上未能避免风险点位、风险类型所对应的故障的发生，执行主体可以对此响应，并基于对目标维护策略相关联的维护日志的分析，确定维护策略是否被成功执行。例如，执行主体可以通过分析目标维护策略的执行进程所对应的维护日志，或者，日志数据中对应于目标维护策略的执行进程的“维护日志”，来确定维护策略是否被成功执行。例如，执行主体可以基于维护日志确定目标维护策略的执行进程中的每个子进程是否均已成功被执行、加载。

相应地，执行主体响应于维护日志指示目标维护策略被成功执行，例如，执行主体可以响应于基于维护日志确定目标维护策略的执行进程中的每个子进程均已成功被执行，向目标设备通信提示信息。该提示信息用于指示目标维护策略需要被更新。由此，执行主体可以在确定目标维护策略被成功执行的，却未排除、避免故障的情况下，向例如运维人员通信，以辅助运维人员参考所配置的维护策略是否实际“有效”，是否需要对这些维护策略进行更新。由此，以辅助人员对失效、效果难抵预期的维护策略执行更新。

在本实施例的一些可选的实现方式中，执行主体还可以响应于维护日志指示目标维护策略未被成功执行(例如，部分的子进程未被执行成功)，向目标设备通信维护日志。由此，以辅助运维人员利用维护日志来分析、理解目标维护策略未被执行的原因。

为加深理解，本公开还结合一个具体应用场景，给出了一种具体的实现方案，请参见如图4所示的示例性架构400的架构示意图。

在架构400中，示例性地可以以终端设备103作为运维人员所使用的(电子)设备，服务器105作为提供云手机服务的云服务器(或者说，将服务器105示例为云手机)。同时，为方便理解，一并将服务105示例为维护云手机的方法的执行主体。也就是说，服务器105在作为云手机的同时，可以通过执行上文所讨论的维护云手机的方法，来对其自身实现维护。

在架构400中，终端设备103首先可以通过执行S401，来确定参考日志数据。例如，终端设备103可以被运维人员所使用，并根据对参考云手机发生参考历史故障时所被记录的历史运行日志执行的分析结果，以确定参考日志数据。例如，终端设备103可以基于执行S401，来得到一组参考日志数据420。接下来，终端设备103可以执行S402，来将一组参考日志数据420提供至服务器105，以供服务器105所使用。

相应地，服务器105可以首先执行S411，来获取服务器105本地(或者说，本机)的运行日志430。

然后，服务器105可以通过执行S412，来比较运行日志430和一组参考日志数据420，以确定服务器105当前是否处于“风险点位”。

接下来，服务器105可以执行S413，以响应于其处于风险点位的情况，分析运行日志430中的目标日志数据(即，被参考、确定为其处于风险点位时所使用的至少部分的运行日志430中所记录的日志数据)。相应地，服务器105可以基于执行S413来确定风险点位的风险类型。

进一步地，服务器105可以执行S414，来根据S413确定出的风险类型，确定目标维护策略435。例如，目标维护策略可以是一组维护策略(图中未示出)中的一项。

接下来，服务器105可以执行S415，来执行该目标维护策略435，以实现对自身的维护工作。由此，以期望避免风险点位的风险类型所对应的故障发生。

此外，服务器105在执行目标维护策略以进行自身维护之后，即执行完成S415之后，还可以执行S416，以对其自身的运行状态持续进行检测。

后续，如果服务器105在检测其运行状态时发现目标故障(即，风险点位的风险类型所对应的故障)仍发生时，其可以执行S417，来获取执行目标维护策略435时的维护日志440。然后，服务器105通过执行S418，来分析维护日志440，确定目标维护策略435是否被成功执行。

如果服务器105基于S418确定目标维护策略435被成功执行，则其可以选择执行S419a，来向终端设备103通信用于指示目标维护策略435需要被更新的提示信息。

相应地，如果服务器105基于S418确定目标维护策略435没有被成功执行，则其可以选择执行S419b，来向终端设备103提供、通信维护日志440，以供终端设备而103侧的运维人员对维护日志440进行分析、辅助其确定目标维护策略435没有被成功执行的原因。

进一步参考图5，作为对上述各图所示方法的实现，本公开提供了一种维护云手机的装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图5所示，本实施例的维护云手机的装置500可以包括：风险点位检测单元501、风险类型确定单元502、维护策略确定单元503和维护策略执行单元504。其中，风险点位检测单元501，被配置成检测云手机的运行日志，确定云手机当前是否处于风险点位，其中，风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，参考日志数据基于历史故障的历史日志数据被确定；风险类型确定单元502，被配置成响应于云手机当前处于风险点位，分析目标日志数据，确定风险点位的风险类型；维护策略确定单元503，被配置成根据风险类型确定针对云手机的目标维护策略；维护策略执行单元504，被配置成执行目标维护策略。

在本实施例中，维护云手机的装置500中：风险点位检测单元501、风险类型确定单元502、维护策略确定单元503和维护策略执行单元504的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201-204的相关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，参考日志数据基于以下方式被确定：获取参考云手机发生参考历史故障时所被记录的历史运行日志；基于历史运行日志中位于目标时长区间内的历史日志数据，确定参考日志数据，其中，目标时长区间的区间终点位于参考历史故障的发生时刻。

在本实施例的一些可选的实现方式中，基于历史运行日志中位于目标时长区间内的历史日志数据，确定参考日志数据，包括：基于历史运行日志中位于目标时长区间内的历史日志数据，拟合参考数据曲线；将参考数据曲线作为参考日志数据。

在本实施例的一些可选的实现方式中，存在多个参考历史故障，将参考数据曲线作为参考日志数据，包括：基于多个参考历史故障各自对应的参考数据曲线的相似度比较结果，对多个参考历史故障执行聚类，得到至少一个聚类结果；拟合属于同一个聚类结果的各个参考数据曲线，得到与聚类结果对应的聚类参考数据曲线；将聚类参考数据曲线作为参考日志数据。

在本实施例的一些可选的实现方式中，风险点位检测单元501，进一步被配置成，检测云手机的运行日志中的目标参数，确定云手机当前是否处于风险点位，其中，目标参数包括以下至少一项：物理机硬件运行参数、应用包名信息、运行脚本信息和与用户设备的通信参数。

在本实施例的一些可选的实现方式中，维护策略确定单元503，进一步被配置成，在预先配置的风险类型-维护策略映射表中，确定与风险类型对应的目标维护策略。

在本实施例的一些可选的实现方式中，维护策略确定单元503，进一步被配置成，将风险类型输入至梯度增强算法模型进行处理，生成与风险类型对应的目标维护策略，其中，梯度增强算法模型预先被利用样本风险类型作为输入、样本维护策略作为输出被训练。

在本实施例的一些可选的实现方式中，维护策略执行单元504，包括：维护策略通信子单元，被配置成基于预先配置的通信地址，将风险类型和目标维护策略通信至目标用户设备；维护策略执行子单元，响应于从目标设备通信回执行确认指示，执行目标维护策略。

在本实施例的一些可选的实现方式中，装置500还包括：云手机状态检测单元，被配置成响应于目标维护策略的执行进程完成，持续检测云手机的运行状态；维护策略执行检测单元，被配置成响应于检测到云手机发生与风险类型对应的目标故障，基于对目标维护策略相关联的维护日志的分析，确定维护策略是否被成功执行；维护策略更新提示单元，被配置成响应于维护日志指示目标维护策略被成功执行，向目标设备通信提示信息，其中，提示信息用于指示目标维护策略需要被更新。

在本实施例的一些可选的实现方式中，装置500还包括：维护日志通信单元，被配置成响应于维护日志指示目标维护策略未被成功执行，向目标设备通信维护日志。

本实施例作为对应于上述方法实施例的装置实施例存在，本实施例提供的维护云手机的装置，基于对云手机的运行日志的检测和分析，来确定云手机是否存在发生故障的风险，并在存在风险时主动地对云手机进行干预、执行维护，以提升云手机的运行稳定性。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图6所示，设备600包括计算单元601，其可以根据存储在只读存储器(ROM)602中的计算机程序或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序，来执行各种适当的动作和处理。在RAM 603中，还可存储设备600操作所需的各种程序和数据。计算单元601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

设备600中的多个部件连接至I/O接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理，例如维护云手机的方法。例如，在一些实施例中，维护云手机的方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到RAM 603并由计算单元601执行时，可以执行上文描述的维护云手机的方法的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行维护云手机的方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPS，Virtual Private Server)服务中存在的管理难度大，业务扩展性弱的缺陷。服务器也可以分为分布式系统的服务器，或者是结合了区块链的服务器。

根据本公开实施例的技术方案，基于对云手机的运行日志的检测和分析，来确定云手机是否存在发生故障的风险，并在存在风险时主动地对云手机进行干预、执行维护，以提升云手机的运行稳定性。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开提供的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (23)

1.一种维护云手机的方法，包括：

检测云手机的运行日志，确定所述云手机当前是否处于风险点位，其中，所述风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，所述参考日志数据基于历史故障的历史日志数据被确定；

响应于所述云手机当前处于所述风险点位，分析所述目标日志数据，确定所述风险点位的风险类型；

根据所述风险类型确定针对所述云手机的目标维护策略；

执行所述目标维护策略。

2.根据权利要求1所述的方法，其中，所述参考日志数据基于以下方式被确定：

获取参考云手机发生参考历史故障时所被记录的历史运行日志；

基于所述历史运行日志中位于目标时长区间内的历史日志数据，确定所述参考日志数据，其中，所述目标时长区间的区间终点位于所述参考历史故障的发生时刻。

3.根据权利要求2所述的方法，其中，所述基于所述历史运行日志中位于目标时长区间内的历史日志数据，确定所述参考日志数据，包括：

基于所述历史运行日志中位于目标时长区间内的历史日志数据，拟合参考数据曲线；

将所述参考数据曲线作为所述参考日志数据。

4.根据权利要求3所述的方法，其中，存在多个所述参考历史故障，所述将所述参考数据曲线作为所述参考日志数据，包括：

基于所述多个参考历史故障各自对应的参考数据曲线的相似度比较结果，对所述多个参考历史故障执行聚类，得到至少一个聚类结果；

拟合属于同一个聚类结果的各个参考数据曲线，得到与聚类结果对应的聚类参考数据曲线；

将所述聚类参考数据曲线作为所述参考日志数据。

5.根据权利要求1所述的方法，其中，所述检测云手机的运行日志，确定所述云手机当前是否处于风险点位，包括：

检测云手机的运行日志中的目标参数，确定所述云手机当前是否处于风险点位，其中，所述目标参数包括以下至少一项：物理机硬件运行参数、应用包名信息、运行脚本信息和与用户设备的通信参数。

6.根据权利要求1所述的方法，其中，所述根据所述风险类型确定针对所述云手机的目标维护策略，包括：

在预先配置的风险类型-维护策略映射表中，确定与所述风险类型对应的目标维护策略。

7.根据权利要求1所述的方法，其中，所述根据所述风险类型确定针对所述云手机的目标维护策略，包括：

将所述风险类型输入至梯度增强算法模型进行处理，生成与所述风险类型对应的目标维护策略，其中，所述梯度增强算法模型预先被利用样本风险类型作为输入、样本维护策略作为输出被训练。

8.根据权利要求1-7中任一项所述的方法，其中，所述执行所述目标维护策略，包括：

基于预先配置的通信地址，将所述风险类型和所述目标维护策略通信至目标用户设备；

响应于从所述目标设备通信回执行确认指示，执行所述目标维护策略。

9.根据权利要求8所述的方法，还包括：

响应于所述目标维护策略的执行进程完成，持续检测所述云手机的运行状态；

响应于检测到所述云手机发生与所述风险类型对应的目标故障，基于对所述目标维护策略相关联的维护日志的分析，确定所述维护策略是否被成功执行；

响应于所述维护日志指示所述目标维护策略被成功执行，向所述目标设备通信提示信息，其中，所述提示信息用于指示所述目标维护策略需要被更新。

10.根据权利要求9所述的方法，还包括：

响应于所述维护日志指示所述目标维护策略未被成功执行，向所述目标设备通信所述维护日志。

11.一种维护云手机的装置，包括：

风险点位检测单元，被配置成检测云手机的运行日志，确定所述云手机当前是否处于风险点位，其中，所述风险点位所关联的目标日志数据与参考日志数据的相似度超过预设的相似度阈值，所述参考日志数据基于历史故障的历史日志数据被确定；

风险类型确定单元，被配置成响应于所述云手机当前处于所述风险点位，分析所述目标日志数据，确定所述风险点位的风险类型；

维护策略确定单元，被配置成根据所述风险类型确定针对所述云手机的目标维护策略；

维护策略执行单元，被配置成执行所述目标维护策略。

12.根据权利要求11所述的装置，其中，所述参考日志数据基于以下方式被确定：

获取参考云手机发生参考历史故障时所被记录的历史运行日志；

基于所述历史运行日志中位于目标时长区间内的历史日志数据，确定所述参考日志数据，其中，所述目标时长区间的区间终点位于所述参考历史故障的发生时刻。

13.根据权利要求12所述的装置，其中，所述基于所述历史运行日志中位于目标时长区间内的历史日志数据，确定所述参考日志数据，包括：

基于所述历史运行日志中位于目标时长区间内的历史日志数据，拟合参考数据曲线；

将所述参考数据曲线作为所述参考日志数据。

14.根据权利要求13所述的装置，其中，存在多个所述参考历史故障，所述将所述参考数据曲线作为所述参考日志数据，包括：

基于所述多个参考历史故障各自对应的参考数据曲线的相似度比较结果，对所述多个参考历史故障执行聚类，得到至少一个聚类结果；

拟合属于同一个聚类结果的各个参考数据曲线，得到与聚类结果对应的聚类参考数据曲线；

将所述聚类参考数据曲线作为所述参考日志数据。

15.根据权利要求11所述的装置，其中，所述风险点位检测单元，进一步被配置成，检测云手机的运行日志中的目标参数，确定所述云手机当前是否处于风险点位，其中，所述目标参数包括以下至少一项：物理机硬件运行参数、应用包名信息、运行脚本信息和与用户设备的通信参数。

16.根据权利要求11所述的装置，其中，所述维护策略确定单元，进一步被配置成，在预先配置的风险类型-维护策略映射表中，确定与所述风险类型对应的目标维护策略。

17.根据权利要求11所述的装置，其中，所述维护策略确定单元，进一步被配置成，将所述风险类型输入至梯度增强算法模型进行处理，生成与所述风险类型对应的目标维护策略，其中，所述梯度增强算法模型预先被利用样本风险类型作为输入、样本维护策略作为输出被训练。

18.根据权利要求11-17中任一项所述的装置，其中，所述维护策略执行单元，包括：

维护策略通信子单元，被配置成基于预先配置的通信地址，将所述风险类型和所述目标维护策略通信至目标用户设备；

维护策略执行子单元，响应于从所述目标设备通信回执行确认指示，执行所述目标维护策略。

19.根据权利要求18所述的装置，还包括：

云手机状态检测单元，被配置成响应于所述目标维护策略的执行进程完成，持续检测所述云手机的运行状态；

维护策略执行检测单元，被配置成响应于检测到所述云手机发生与所述风险类型对应的目标故障，基于对所述目标维护策略相关联的维护日志的分析，确定所述维护策略是否被成功执行；

维护策略更新提示单元，被配置成响应于所述维护日志指示所述目标维护策略被成功执行，向所述目标设备通信提示信息，其中，所述提示信息用于指示所述目标维护策略需要被更新。

20.根据权利要求19所述的装置，还包括：

维护日志通信单元，被配置成响应于所述维护日志指示所述目标维护策略未被成功执行，向所述目标设备通信所述维护日志。

21.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-10中任一项所述的维护云手机的方法。

22.一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行权利要求1-10中任一项所述的维护云手机的方法。

23.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-10中任一项所述的维护云手机的方法。