CN117151726A - 故障的修复方法、修复装置、电子设备以及存储介质 - Google Patents

Abstract

本申请公开了一种故障的修复方法、故障的修复装置、电子设备以及计算机可读存储介质，该故障的修复方法包括：获取车辆联网服务在预设的至少一个检测项下的健康度；从每个目标检测项的异常信息中确定至少一个故障点；针对每个故障点，从预设的修复方案库中查找与故障点匹配的目标预设故障点，修复方案库中记录有至少一个预设故障点，以及每个预设故障点对应的修复方案；根据目标预设故障点所对应的修复方案修复第一故障点，第一故障点为查找到目标预设故障点的故障点。该方法通过提前感知修并复车端软件的潜在故障点，提高车端软件的鲁棒性，降低车端软件功能异常的客诉率，进而从根本上提升用户的售后体验，降低舆情风险。

Description

故障的修复方法、修复装置、电子设备以及存储介质

技术领域

本申请属于车辆技术领域，尤其涉及一种故障的修复方法、故障的修复装置、电子设备以及计算机可读存储介质。

背景技术

随着车辆智能化的发展，车辆集成的软件功能越来越丰富，这导致在车辆使用过程中，软件功能异常在客诉中占比率逐年上升。

通常，当用户发现软件功能异常时，只能先拨打客服热线反馈问题，在相关人员收到反馈问题后，将问题描述转换为客诉工单，并根据该客诉工单开展人工排查以解决问题。但在客诉处理过程中，因软件功能复杂、链路长以及集成度高等客观原因，容易出现响应慢、资源协调困难以及人工分析耗时等问题，这不仅使得客诉处置效率偏低，降低用户售后体验，而且容易造成舆情风险。

发明内容

本申请提供了一种故障的修复方法、故障的修复装置、电子设备及计算机可读存储介质，通过提前感知并复修车端软件的潜在故障点，提高车端软件的鲁棒性，以降低车端软件功能异常的客诉率，这能够从根本上提升用户的售后体验，降低舆情风险。

第一方面，本申请提供了一种故障的修复方法，该修复方法包括：

获取车辆联网服务在预设的至少一个检测项下的健康度，其中，每个检测项对应一个健康度；

从每个目标检测项的异常信息中确定至少一个故障点，目标检测项为各检测项中健康度低于预设阈值的检测项；

针对每个故障点，从预设的修复方案库中查找与故障点匹配的目标预设故障点，修复方案库中记录有至少一个预设故障点，以及每个预设故障点对应的修复方案；

根据目标预设故障点所对应的修复方案修复第一故障点，第一故障点为查找到目标预设故障点的故障点。

第二方面，本申请提供了一种故障的修复装置，该修复装置包括：

第一获取模块，用于获取车辆联网服务在预设的至少一个检测项下的健康度，其中，每个检测项对应一个健康度；

第一确定模块，用于从每个目标检测项的异常信息中确定至少一个故障点，目标检测项为各检测项中健康度低于预设阈值的检测项；

查找模块，用于针对每个故障点，从预设的修复方案库中查找与故障点匹配的目标预设故障点，修复方案库中记录有至少一个预设故障点，以及每个预设故障点对应的修复方案；

修复模块，用于根据目标预设故障点所对应的修复方案修复第一故障点，第一故障点为查找到目标预设故障点的故障点。

第三方面，本申请提供了一种电子设备，该电子设备包括存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，上述处理器执行上述计算机程序时实现如上述第一方面的方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现如上述第一方面的方法的步骤。

第五方面，本申请提供了一种计算机程序产品，上述计算机程序产品包括计算机程序，上述计算机程序被一个或多个处理器执行时实现如上述第一方面的方法的步骤。

本申请与现有技术相比存在的有益效果是：为了能够提前感知并修复车端软件的潜在故障点，对于车辆联网服务，可通过至少一个检测项来确定其健康状态，并得到每个检测项下的健康度；对于健康度低于预设阈值的每个检测项，可以认为车辆联网服务在这个检测项下存在异常信息，并可以根据该异常信息确定该检测项下的至少一个故障点。对于这样的检测项，可记作目标检测项。也就是说，任一检测项下的健康度低于预设阈值，都可确定为目标检测项，并确定每个目标检测项所对应的故障点，换句话说，故障点可能有多个。基于此，为了保障故障修复的全面性，对于每个故障点，可展开修复工作，即从构建好的修复方案库中查到与该故障点匹配的目标预设故障点，其中，修复方案库中记录有至少一个预设故障点，以及每个预设故障点所对应的修复方案。由此，对于能够查到目标预设故障点的故障点，也即第一故障点来说，可直接根据目标预设故障点所对应的修复方案进行修复，即实现自动感知并自动修复故障点。

可以理解，在本申请中，对故障点进行修复是针对车端软件客诉的前置处理，能够让车辆联网服务更加稳定，减少车辆联网服务导致的车端软件功能异常，从而提高车端软件的鲁棒性。显然，该方法能够直接降低车端软件功能异常的客诉率，从根本上提升用户的售后体验，降低舆情风险。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的故障的修复方法的流程示意图；

图2是本申请实施例提供的故障的修复装置的结构示意图；

图3是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

相关技术中，随着车辆智能化的发展，车辆集成的软件功能越来越丰富，这导致车辆的使用过程中，软件功能异常在客诉中占比率逐年上升。

一般，用户发现软件功能异常，只能先拨打客服热线反馈问题，以等待问题被解决。相应地，在相关人员收到反馈问题后，将问题描述转换为客诉工单，并根据该客诉工单开展人工排查以解决问题。但在客诉处理过程中，因软件功能复杂、链路长以及集成度高等客观原因，容易出现响应慢、资源协调困难以及人工分析耗时等问题，这不仅使得客诉处置效率偏低，降低用户售后体验，而且容易造成舆情风险。

针对该问题，本申请在经过对大量客诉数据进行分析，发现大部分客诉问题都是常见问题。基于该分析结果，本申请提出了一种故障的修复方法以解决上述问题。该修复方法能够提前感知并自动修复车端软件的潜在故障点，提高车端软件的鲁棒性，进而降低车端软件功能异常的客诉率。在客诉率下降的情况下，能够释放宝贵的人力资源来攻克疑难或突发的客诉问题，能够从根本上提高客诉处理的效率，提升用户售后体验，从而极大地降低车企的舆情风险。下面将通过具体的实施例对本申请所提出的控制方法进行说明。

本申请实施例提供的故障的修复方法可应用于电子设备。例如应用于搭建有车辆联网服务的云端设备，或者应用于能够与云端设备通信的其他电子设备，例如手机、平板电脑、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

为了说明本申请所提出的技术方案，下面将以云服务器作为执行主体对各个实施例进行说明。

图1示出了本申请提供的故障的修复方法的示意性流程图，该故障的修复方法包括：

步骤110、云服务器获取车辆联网服务在预设的至少一个检测项下的健康度。

车辆联网服务一般搭建在云端，是车企提供的端到端的专属于车辆领域的服务，车端软件在应用过程中，经常会调用该车辆联网服务。由此，可以认为，车辆联网服务异常极有可能导致车端软件功能的异常。

为了降低车辆联网服务异常对车端软件所带来的不良影响，云服务器可对车辆联网服务做健康检查。车辆联网服务异常可能是多方面原因造成的，由此，云服务器可以对这些原因进行分类，构建至少一个维度的检测项；针对每个检测项，云服务器可获取车辆联网服务在该检测项下的健康度。也即，有多少个检测项，可以得到多少个健康度。其中，健康度用于指示检测项的健康状态，也即指示检测项是处于异常状态还是处于正常状态。

在一些实施例中，检测项可包括服务链路检测项、服务可用性检测项以及服务数据质量检测项等。车辆联网服务是通过多个应用程序的编程接口(ApplicationProgramming Interface，API)组装来实现业务的，其中，服务链路检测项是指业务上下游的API的相互调用的依赖关系。仅作为示例，应用程序(Application，App)的远程解锁服务的链路：App远控指令调用API云平台车辆中心远程指令解析API-云平台网关API-车端TBOX接收指令API。

服务项可用性检测项：指API被调用时是否返回错误码。

服务数据质量检测项：指API入参的参数在设计定义时的阈值的校验，以及API返回值结果在设计定义时的阈值的校验。

具体地，在检测项包括服务链路检测项、服务可用性检测项以及服务数据质量检测项的情况下，云服务器可获取得到三个健康度，三个健康度分别与这三个检测项一一对应。

步骤120、云服务器从每个目标检测项的异常信息中确定至少一个故障点。

为了从不同的维度衡量车辆联网服务是否健康，对于每个维度，即每个检测项，云服务器可设置相应的健康度阈值，即预设阈值；通过将该检测项下的健康度与该预设阈值进行比较，可确定车辆联网服务在该维度下的健康状况。具体地，在某个检测项下，如果健康度阈值低于预设阈值，说明该检测项下，车辆联网服务的健康状况不佳，可记作目标检测项；为了调整车辆联网服务在每个目标检测项下的健康状况，针对每个目标检测项，可根据该检测项中存在的异常信息确定至少一个故障点。可以理解，有多少个目标检测项的健康度低于预设阈值，云服务器至少可确定出多少个故障点。

示例性的，对于每个目标检测项下故障点的确定过程，可以包括：将异常信息进行分类，每个分类确定一个故障点，那么有多少个分类，云服务器可确定出多少个异常点；或者，根据异常信息的危害程度划分危害等级，每个等级确定一个故障点，那么有多少个危害等级，云服务器可确定出多少个异常点。

可选地，对于不同的检测项来说，对应的预设阈值可以相同，也可以不同，具体地可根据实际需求确定，在本实施例不作限定。

步骤130、针对每个故障点，云服务器从预设的修复方案库中查找与故障点匹配的目标预设故障点。

为了能够自动修复各个故障点，云服务器可以预先构建修复方案库。该修复方案库中记录有至少一个预设故障点，该预设故障点可以是预判的故障点，即在未确定出该类故障点前，能够根据相关经验和预判结果提前给出修复方案的这类故障点；也可能是根据经验沉淀下来的历史故障点，即已被明确，且有成熟的修复方案的故障点。修复方案库中除了记录预设故障点，还记录有每个预设故障点对应的修复方案，以便于为前述步骤120中确定的故障点提供修复方案，实现自动修复。

具体地，为了实现自动修复，在确定各故障点后，针对每个故障点，云服务器可从修复方案库中查找与该故障点匹配的预设故障点，也即目标预设故障点。

优选地，修复方案库中记录的预设故障点越多越好，这样能够满足大部分故障点的修复需求。

步骤140、云服务器根据目标预设故障点所对应的修复方案修复第一故障点。

对于查找到目标预设故障点的故障点来说，云服务器可采用目标预设故障点所对应的修复方案来对该故障点进行修复，即实现对故障点的自动修复。可以理解，有的故障点能被自动修复，有的故障点不能被自动修复，为了将可自动修复的故障点和不可自动修复的故障点区别开来，可将查找到目标预设故障点的故障点记作第一故障点，未查找到目标预设故障点的故障点记作第二故障点。

本申请实施例中，为了降低车端软件功能异常的客诉率，云服务器可以通过对车辆联网服务进行健康检查，即通过不同检测项确定车辆联网服务是否健康；对于不健康的检测项，即目标检测项，云服务器可以确定其故障点；针对每个故障点，云服务器可以尝试从已有的修复方案中查找适配的修复方案对其进行自动修复。可以理解，在该过程中，故障点的修复是针对车端软件客诉的前置处理，能够让车辆联网服务更加稳定，减少车端软件的潜在故障点，从而提高车端软件的鲁棒性。显然，该修复方法可直接降低车端软件功能异常的客诉率，能够从根本上提升用户的售后体验，进而降低舆情风险。

在一些实施例中，为了确定车辆联网服务在各检测项下的健康度，针对每个检测项，云服务器可确定车辆联网服务的每个服务项在检测项下的告警级别、服务级别以及服务性能，从而基于各个服务项的告警级别、服务级别以及服务性能确定检测项的健康度。例如，通过查表方式，或者通过构建计算公式的计算方式来确定检测项的健康度。

在一些实施例中，云服务器可通过以下步骤来确定车辆联网服务在该检测项下的健康度：

步骤111、云服务器确定车辆联网服务的每个服务项在检测项下的告警级别、服务级别以及服务性能。

可以理解，车辆联网服务包括多个服务项，对于每个服务项，在不同的检测项下，对应了不同的告警级别、服务级别和服务性能。为了准确计算每个检测项下的健康度，云服务器可获取该检测项下每个服务项的告警级别、服务级别以及服务性能。其中，告警级别为相应的检测项下，服务项出现异常后对应的分值；服务级别为相应的检测项下，服务项的重要程度；服务性能为相应的检测项下，服务项的性能是否满足相应的性能指标。

仅作为示例，假定检测项为服务链路检测项，首先，可以确定车辆联网服务所包括的各个服务项，假定有N个服务项；这N个服务项对应的服务链路如下表1所示。

表1服务项与服务链路的对应关系

序号	服务名称	封装链路
			1	服务项1	API1.0->API1.1->API1.2
2	服务项2	API2.0->API2.1->API2.2->API2.3->…
			…	…	…
N	服务项N	APIN.0->APIN.1->APIN.2->APIN.3->…

对于每个服务项，其封装链路中的每个API在调用过程中，如果出现异常，会返回不同的错误码。不同的错误码，其对整个封装链路的影响有所不同，具体地，这个影响可通过告警级别来表示。其中，各API的异常错误码对应的告警级别如下表2所示。

表2各API的异常错误码对应的告警级别

由上述两个表格可知，对于每个服务项，其告警级别需要根据对应的服务链路确定。以服务项1为例，假定其服务链路为API1.0->API1.1->API1.2经过家产，仅API1.2调用异常，返回了E001，那么可以确定服务项1的告警级别为L-1。

对于每个服务项，可以根据其在对应的检测项下的重要程度设定相应的服务级别。假定服务链路检测项对应的服务级别有3个，分别为O1、O2以及O3，各服务项与服务级别之间的对应关系参阅表3。

表3各服务项与服务级别的对应关系

序号	服务名称	服务级别
			1	服务项1	O1
2	服务项2	O3
			…	…	…
N	服务项N	O2

假定服务链路检测项对应的服务性能指标定义表如表4所示。

表4服务链路检测项对应的性能指标定义表

序号	性能指标名称	性能指标要求
			1	响应时间	≤200毫秒
2	请求成功率	≥99％
			3	并发量	≥300

对于每个服务项，其对应的性能指标如表5所示。

表5各服务项与性能指标的对应关系

对于每个服务项，可以根据基于表5中的性能指标进行相关检测，并将检测结果与表4中的性能指标要求进行比较，以确定该服务项的服务性能。假定服务性能包括达到，和未达到，服务项i的性能指标为并发量，经检测，并发量为500，显然500≥300，因此可以确定服务项i的服务性能为达到。

步骤112、云服务器基于预设的健康度公式和各个服务项的告警级别、服务级别以及服务性能计算检测项的健康度。

其中，检测项的健康度公式为：

其中，H为检测项的健康度，N为服务项的个数，L_n为第n个服务项的告警级别，O_n为第n个服务项的服务级别，P_n为第n个服务项的服务性能，Kn为第n个服务项的权重值。可以理解，健康度最后计算出来是一个值，因此告警级别、服务级别和服务性能均需要量化。

仅作为示例，API对应的告警级别L-1和L-2可分别量化为1和3；服务级别01、02以及03可分别量化为0.5、1以及2；服务性能对应的达到和未达到可分别量化为2和0。

对于权重值，仍以服务链路检测项为例，对于不同的服务项，可根据其在服务链路检测中的整体影响为其赋予不同的权重值。其中，各服务项与权重值之间的对应关系如表6所示。

表6各服务项与性能指标的对应关系

综上，在得到服务链路检测项下各服务项告警级别、服务级别以及服务性能所对应的值后，可以将这些值代如上述健康度计算公式中，以计算出该检测项的健康度。对于其他两个检测项，以此类推，在此不再赘述。

在本申请实施例中，针对每个检测项，可以自定义参数的值，进而结合健康度公式计算出健康度，能够从不同维度准确衡量车辆联网服务的健康度，进而提高故障修复的可靠性。

在一些实施例中，对于计算得到的健康度，是知道其具体值的。由此，云服务器可以直接将每项检测项对应的健康度与预设阈值相比较，以确定二者之间的大小关系；在某个健康度低于预设阈值的情况下，云服务器可直接将对应的检测项确定为目标检测项，以便于确定其故障点，及时修复。

在一些实施例中，云服务器还可以预先构建各检测项和健康度等级之间的对应关系表。在该关系表中，每个检测项对应有不同的服务项组合，每个服务项组合中，包括了各服务项以及，每个服务项对应的告警级别、服务级别以及服务性能。基于此，针对每个检测项，云服务器通过前述步骤111确定出车辆联网服务的每个服务项在该检测项下的告警级别、服务级别以及服务性能后，可以通过这些信息从关系表中确定该检测项的健康度等级。其中，健康度等级可作为健康度的表征参数，即通过健康度等级可以确定对应的检测项是否存异常。

仅作为示例，假定健康度等级包括正常、良好以及异常，若某个检测项的健康度等级为正常或良好，则说明该检测项不存在异常信息，可以认为其健康度高于或等于预设阈值；但如果该检测项的健康度等级为异常时，那么说明该检测项存在异常信息，可以认为其健康度低于预设阈值，将该检测项确定为目标检测项。

应理解，健康度的确定可以选取多种方式，至于具体选用哪种方式，可根据实际情况确定，在本申请中不作限定。

在一些实施例中，修复方案库有多个，不同的修复方案库中记录有不同类型的预设故障点。多个修复方案库可满足软件和硬件的故障点修复需求，能够提高自动修复的全面性。具体地，上述步骤130具体包括：

步骤131、云服务器基于预设的查找顺序从各修复方案库中查找目标预设故障点。

之所以设置多个修复方案库，是为了将不同类型对故障点进行划分，将不同类型的故障点所对应的修复方案集中到一起，以便于查找目标预设故障点。可以理解，不同的修复方案库，其所记录的预设故障点之间没有覆盖关系。因此，如果从一个修复方案库中查找不到目标预设故障点，那就需要从剩余的所有修复方案库中查找目标预设故障点。相应地，云服务器在一个修复方案库中查找到目标预设故障点后，可停止对其他修复方案库进行查找。基于各修复方案库的特性，要提高故障点的修复效率，各修复方案库的查找顺序很重要。

因并不清楚故障点属于哪种类型，所以无法直接基于故障点的类型从固定的修复方案库中查找目标预设故障点。故此，为了能够提高故障点的修复效率，可从车端软件的历史客诉信息中汲取经验。

仅作为示例，可从历史客诉信息中确定预设故障点在不同类型被投诉的概率，基于预设故障点的各类型进行概率排序，并基于该排序设定查找顺序。例如，概率最高对应的类型，并将记录该类型的预设故障点的修复方案库的查找顺序设定为最高；相反，概率最低的类型，将记录该类型的预设故障点的修复方案库的查找顺序设定为最低。通过该方法设定的查找顺序，云服务器能够优先查找最可能记录有目标预设故障点的修复方案，从而提高预设故障点的查找效率。

步骤132、云服务器若从任一修复方案库中查找到目标预设故障点，则将故障点确定为第一故障点。

如果云服务器从任意一个修复方案库中查找到目标预设故障点，那么可以停止查找操作。相应地，说明该故障点可以被修复，也即可以将其记作第一故障点，以执行前述步骤140。

步骤132、云服务器若从所有修复方案库中均未查找到目标预设故障点，则将故障点确定为第二故障点。

但如果遍历了所有的修复方案库，云服务器都没能查找到目标预设故障点，说明现有的修复方案库中没记录该故障点所对应的修复方案，也即这个故障点之前没有出现过，无法进行自动修复，此时，可以将其记作第二故障点，以执行前述实施例中的相关步骤。

在本申请实施例中，结合客诉经验确定不同修复方案库的查找顺序，通过该查找顺序查找故障点的目标预设故障点，能够提高目标预设故障点的查找效率；对于不同的查找情况，采用不同的修复手段，也能够提高故障点修复的全面性和可靠性。

在一些实施例中，多个修复方案库包括业务中心修复方案库、数据操作修复方案库、中间件修复方案库、数据库修复方案库以及计算资源修复方案库，查找顺序为：业务中心修复方案库→数据操作修复方案库→中间件修复方案库、数据库修复方案库以及计算资源修复方案库。故此，前述步骤131具体包括：

步骤1311、云服务器从业务中心修复方案库中查找目标预设故障点。

首先，考虑到业务中心异常引起的车端软件功能异常的情况最为常见。由此，在存在故障点的情况下，云服务器优先从业务中心修复方案库中查找目标预设故障点。其中，业务中心包括用户中心、消息中心以及车辆中心等。

步骤1312、云服务器若从业务中心修复方案库中未查找到目标预设故障点，则从数据操作修复方案库查找目标预设故障点。

其次，考虑到数据操作引起的车端软件功能异常的情况较为常见。由此，如果没能在存在概率最大的业务中心修复方案库中查找到目标预设故障点，云服务器可以数据操作修复方案库查找目标预设故障点。其中，数据操作包括数据的增加、删除、修改以及查找。

步骤1313、云服务器若从数据操作修复方案库中未查找到目标预设故障点，则分别从中间件修复方案库、数据库修复方案库以及计算资源修复方案库查找到目标预设故障点。

最后，考虑到中间件、数据库以及计算资源引起的车端软件功能异常的情况较为少见，且概率都差不多。由此，云服务器可以同时通过从中间件修复方案库、数据库修复方案库以及计算资源修复方案库查找到目标预设故障点。并且，可以理解，并发式查找也能够减少目标预设故障点的查找时间，提高查找效率。

本申请实施例通过业务中心修复方案库→数据操作修复方案库→中间件修复方案库、数据库修复方案库以及计算资源修复方案库的查找顺序，能够提高目标预设故障点的查找效率。

在一些实施例中，对于每个第二故障点，即不可自动修复的故障点，或者说未查找到目标预设故障点的故障点，为了提高修复方法的全面性，可建立告警工单，以便于相关人员通过人工修复的方式来修复该第二故障点。

在一些实施例中，为了提高修复方案对各类型的故障点的覆盖度，进而提高故障点的自动修复率，在基于第二故障点建立告警工单之后，修复方法还包括：

步骤A1、云服务器获取告警工单所对应的人工修复方案。

步骤A2、云服务器基于第二故障点的故障类型从多个修复方案库中确定待更新的目标修复方案库。

步骤A3、云服务器基于第二故障点和人工修复方案更新目标修复方案库。

告警工单在生成后，云服务器可通过预设的方式提醒相关人员进行人工处理，例如将告警工单推送给管理员，以方便管理员分配相应的运维人员对第二故障进行修复。相应地，在告警工单完成人工处理后，有相应的人工修复方案，为了提高修复方案对各类型的故障点的覆盖度，进而提高故障点的自动修复率，可以将该人工修复方案更修至的修复方案库中。为了提高修复方案更新的准确性，可以先根据第二故障点的类型确定出待更新的目标修复方案库，并将第二故障点和人工修复方案更新至目标修复方案库中，以保障相同类型的故障点记录至同一个修复方案库中。

在本申请实施例中，云服务器获取第二故障点对应的人工修复方案，并将第二故障点和对应的人工修复方案更新至匹配的修复方案库中，能够提高修复方案对各类型的故障点的覆盖度。通过该方法，不仅能够对故障点形成良性闭环处置，随着预设故障点和对应的修复方案的累积，还可以逐步减少人工干预，理想的状态下，能够实现全自动维护。

在一些实施例中，为了及时发现并修复故障点，从而降低用户对车端软件故障的感知率，该修复方法还包括：

步骤B1、在所有故障点都被修复后，基于预设时间间隔返回前述步骤110及其后续步骤。

在所有故障点都被修复后，说明此次修复已经结束。在该情形下，云服务器可以通过轮询的方式执行前述各实施例所对应步骤，以确保新的故障点被及时感知和修复。具体地，轮询的预设时间间隔可以根据经验设定，在本申请实施例中不作限定。

在一些实施例中，可以理解，虽然通过遍历修复方案库的方式可以将各故障点区分为第一故障点和第二故障点，以便于采取不同的修复手段进行修复。但在实际的应用场景下，各历修复方案库中的数据会逐渐累积，越来越多，仅依靠遍历的方式，难以在海量的数据中查找到目标数据。这将导致修复所需时间会越来越长，降低修复效率。

基于此，为了提高修复效率，在各修复方案库中的数据累积到一定程度，可以采用训练完成的修复模型为每个新确定的故障点进行自动修复。具体地，训练完成的修复模型可以为每个新确定的故障点查找匹配的预设故障点，对于查找到匹配的预设故障点的每个新确定的故障点，可采用与其匹配的预设故障点所对应的修复方案来对其进行自动修复。

可选地，在各修复方案库中的数据累积到一定程度后，可认为训练修复模型的样本数据已经充足。故此，对于预先构建好的修复模型，可以根据各修复方案库中所有的预设故障点和所有的预设故障点对应的修复方案来训练该修复模型，直至该修复模型收敛，得到训练完成的修复模型。

可选地，为了让形成良性闭环，对于未被修复模型自动修复的新确定的故障点，在其被人工修复后，可将该新确定的故障点和该新确定的故障点对应的人工修复方案添加至样本数据中，再次对修复模型进行迭代训练。这样，通过不断添加样本，迭代训练修复模型，可以让修复模型扩展对不同场景下的故障点的覆盖度，提高修复率；随着数据样本的丰富，在良性循环中，可逐步减少人工干预，让修复模型实现自动运行维护。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例的故障的修复方法，图2示出了本申请实施例提供的故障的修复装置2的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图2，该故障的修复装置2包括：

第一获取模块21，用于获取车辆联网服务在预设的至少一个检测项下的健康度，其中，每个检测项对应一个健康度；

第一确定模块22，用于从每个目标检测项的异常信息中确定至少一个故障点，目标检测项为各检测项中健康度低于预设阈值的检测项；

查找模块23，用于针对每个故障点，从预设的修复方案库中查找与故障点匹配的目标预设故障点，修复方案库中记录有至少一个预设故障点，以及每个预设故障点对应的修复方案；

修复模块24，用于根据目标预设故障点所对应的修复方案修复第一故障点，第一故障点为查找到目标预设故障点的故障点。

可选地，修复装置2还可以包括：

建立模块，用于在从预设的修复方案库中查找与故障点匹配的目标预设故障点之后，基于第二故障点建立告警工单，第二故障点为未查找到目标预设故障点的故障点。

可选地，第一获取模块21可以包括：

第一确定单元，用于针对每个检测项，确定车辆联网服务的每个服务项在检测项下的告警级别、对象级别以及服务性能；

获取单元，用于各个服务项的告警级别、对象级别以及服务性能确定检测项的健康度。

可选地，修复方案库有多个，不同的修复方案库中记录有不同类型的预设故障点；查找模块23可以包括：

查找单元，用于基于预设的查找顺序从各修复方案库中查找目标预设故障点；

第二确定单元，用于若从任一修复方案库中查找到目标预设故障点，则将故障点确定为第一故障点；

第三确定单元，用于若从所有修复方案库中均未查找到目标预设故障点，则将故障点确定为第二故障点。

可选地，多个修复方案库包括业务中心修复方案库、数据操作修复方案库、中间件修复方案库、数据库修复方案库以及计算资源修复方案库；查找单元具体的用于：

从业务中心修复方案库中查找目标预设故障点；

若从业务中心修复方案库中未查找到目标预设故障点，则从数据操作修复方案库查找目标预设故障点；

若从数据操作修复方案库中未查找到目标预设故障点，则分别从中间件修复方案库、数据库修复方案库以及计算资源修复方案库查找到目标预设故障点。

可选地，修复装置2还可以包括：

第二获取模块，用于获取告警工单所对应的人工修复方案；

第二确定模块，用于基于第二故障点的故障类型从多个修复方案库中确定待更新的目标修复方案库；

更新模块，用于基于第二故障点和人工修复方案更新目标修复方案库。

可选地，修复装置2还可以包括：

循环模块，用于在所有故障点都被修复后，基于预设时间间隔触发计算模块21的执行。

可选地，修复装置2还可以包括：

训练模块，用于在基于第二故障点和人工修复方案更新目标修复方案库之后，将所有预设故障点和所有预设故障点对应的修复方案作为样本数据，训练预先构建的修复模型，得到训练完成的修复模型；训练完成的修复模型，用于为每个新确定的故障点查找匹配的预设故障点，并对查找到匹配的预设故障点的每个新确定的故障点进行自动修复。

需要说明的是，上述装置/单元之间的信息交互和执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

图3为本申请一实施例提供的电子设备的物理层面的结构示意图。如图3所示，该实施例的电子设备3包括：至少一个处理器30(图3中仅示出一个)处理器、存储器31以及存储在存储器31中并可在至少一个处理器30上运行的计算机程序32，处理器30执行计算机程序32时实现上述任意故障的修复方法实施例中的步骤，例如图1所示出的步骤110-140。

所称处理器30可以是中央处理单元(Central Processing Unit，CPU)，该处理器30还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器31在一些实施例中可以是电子设备3的内部存储单元，例如电子设备3的硬盘或内存。存储器31在另一些实施例中也可以是电子设备3的外部存储设备，例如电子设备3上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。

进一步地，存储器31还可以既包括电子设备3的内部存储单元也包括外部存储设备。存储器31用于存储操作装置、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如计算机程序的程序代码等。存储器31还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在电子设备/电子设备上运行时，使得电子设备/电子设备执行时实现可实现上述各个方法实施例中的步骤。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，上述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/电子设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/网络设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/网络设备实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种故障的修复方法，其特征在于，所述修复方法包括：

获取车辆联网服务在预设的至少一个检测项下的健康度，其中，每个所述检测项对应一个所述健康度；

从每个目标检测项的异常信息中确定至少一个故障点，所述目标检测项为各所述检测项中所述健康度低于预设阈值的检测项；

针对每个所述故障点，从预设的修复方案库中查找与所述故障点匹配的目标预设故障点，所述修复方案库中记录有至少一个预设故障点，以及每个所述预设故障点对应的修复方案；

根据所述目标预设故障点所对应的修复方案修复第一故障点，所述第一故障点为查找到所述目标预设故障点的所述故障点。

2.如权利要求1所述的故障的修复方法，其特征在于，所述获取车辆联网服务在预设的至少一个检测项下的健康度，包括：

针对每个所述检测项：

确定所述车辆联网服务的每个服务项在所述检测项下的告警级别、服务级别以及服务性能；

基于各个所述服务项的所述告警级别、所述服务级别以及所述服务性能确定所述检测项的健康度。

3.如权利要求1所述的故障的修复方法，其特征在于，所述修复方案库有多个，不同的所述修复方案库中记录有不同类型的所述预设故障点；所述从预设的修复方案库中查找与所述故障点匹配的目标预设故障点，包括：

基于预设的查找顺序从各所述修复方案库中查找所述目标预设故障点；

若从任一所述修复方案库中查找到所述目标预设故障点，则将所述故障点确定为所述第一故障点；

若从所有所述修复方案库中均未查找到所述目标预设故障点，则将所述故障点确定为第二故障点。

4.如权利要求3所述的故障的修复方法，其特征在于，多个所述修复方案库包括业务中心修复方案库、数据操作修复方案库、中间件修复方案库、数据库修复方案库以及计算资源修复方案库，所述基于预设的查找顺序从各所述修复方案库中查找所述目标预设故障点，包括：

从所述业务中心修复方案库中查找所述目标预设故障点；

若从所述业务中心修复方案库中未查找到所述目标预设故障点，则从所述数据操作修复方案库查找所述目标预设故障点；

若从所述数据操作修复方案库中未查找到所述目标预设故障点，则分别从所述中间件修复方案库、所述数据库修复方案库以及所述计算资源修复方案库查找到所述目标预设故障点。

5.如权利要求1至4任一项所述的故障的修复方法，其特征在于，在所述从预设的修复方案库中查找与所述故障点匹配的目标预设故障点之后，所述修复方法还包括：

基于第二故障点建立告警工单，所述第二故障点为未查找到所述目标预设故障点的所述故障点。

6.如权利要求5所述的故障的修复方法，其特征在于，在所述基于第二故障点建立告警工单之后，所述修复方法还包括：

获取所述告警工单所对应的人工修复方案；

基于所述第二故障点的故障类型从多个所述修复方案库中确定待更新的目标修复方案库；

基于所述第二故障点和所述人工修复方案更新所述目标修复方案库。

7.如权利要求6所述的故障的修复方法，其特征在于，在所述基于所述第二故障点和所述人工修复方案更新所述目标修复方案库之后，还包括：

将所有所述预设故障点和所有所述预设故障点对应的修复方案作为样本数据，训练预先构建的修复模型，得到训练完成的修复模型；所述训练完成的修复模型，用于为每个新确定的故障点查找匹配的预设故障点，并对查找到匹配的预设故障点的每个所述新确定的故障点进行自动修复。

8.一种故障的修复装置，其特征在于，包括：

第一获取模块，用于获取车辆联网服务在预设的至少一个检测项下的健康度，其中，每个所述检测项对应一个健康度；

第一确定模块，用于从每个目标检测项的异常信息中确定至少一个故障点，所述目标检测项为各所述检测项中所述健康度低于预设阈值的检测项；

查找模块，用于针对每个所述故障点，从预设的修复方案库中查找与所述故障点匹配的目标预设故障点，所述修复方案库中记录有至少一个预设故障点，以及每个所述预设故障点对应的修复方案；

修复模块，用于根据所述目标预设故障点所对应的修复方案修复第一故障点，所述第一故障点为查找到所述目标预设故障点的所述故障点。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的故障的修复方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的故障的修复方法。