CN117632600A - 一种故障管理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供了一种故障管理方法、装置及电子设备，其中，该故障管理方法包括：接收异常告警信息，基于该异常告警信息，确定异常告警信息对应的目标告警类型，以及目标设备，针对不同的目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至目标设备中。其中，由于异常告警信息是基于运行异常的异常服务实例发出的，目标设备的运行资源能满足异常服务实例的运行需求，如此，选用本申请实施例，在服务实例发生异常时，可降低该异常的服务实例对原始运行设备上其他服务实例的影响，能够在用户未感知到故障存在的情况下，进行故障恢复，有效保障了用户使用体验。

Description

一种故障管理方法、装置及电子设备

技术领域

本申请涉及数据库领域，尤其涉及一种故障管理方法、装置及电子设备。

背景技术

在互联网技术领域中，服务是指由应用程序响应于用户需求提供的一个或多个软件功能的抽象概括，服务实例是一个应用的某个向用户提供的服务在实例化之后所得到的结果，一个实例中包含一个或多个容器，用于执行容器所具备的功能。通常，一个服务实例仅从属于一个服务，一个服务可包含一个或者多个服务实例，示例性的，通过视频软件响应于用户的观影需求提供的视频播放功能可以抽象概括为视频服务，该视频服务可通过多个实现视频播放功能的节点进行实现，该具体提供功能的节点即为视频服务的一个或者多个服务实例。

随着互联网技术的发展，互联网用户数量激增，用户对服务的需求与日俱增，这使得服务或提供服务的设备的稳定性成为影响用户体验的重要指标。若用户所需的服务或提供该服务的设备出现故障且无法快速止损恢复，将直接影响用户的使用体验。

现有的服务的故障异常处理方式，都是依赖于人工操作，由人工收到服务异常报警后，手动查找原因，然后确定故障的原因后进行故障恢复，此种处理方式故障恢复效率较低，无法保障用户的使用体验。

发明内容

有鉴于此，本申请实施例提供了一种故障管理方法、装置及电子设备，以自动处理用户所需服务出现的异常，保障用户的使用体验。

第一方面，本申请实施例提供了一种故障管理方法，其中，所述方法包括：

接收异常告警信息，其中，所述异常告警信息是基于运行异常的异常服务实例发出的；

基于所述异常告警信息，确定所述异常告警信息对应的目标告警类型，以及目标设备，所述目标设备的运行资源满足所述异常服务实例的运行需求；

针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中。

结合第一方面，在第二种可能的实施例中，所述目标告警类型包括资源类异常告警、健康指标类异常告警，所述资源类异常告警包括：机器资源异常告警、服务实例资源异常告警，所述健康指标类异常告警包括：机器整机健康指标异常告警、服务实例健康指标异常告警。

结合第一方面的第二种可能的实施例，在第三种可能的实施例中，所述方法还包括：

实时监测运行各服务实例的设备的运行指标，其中，所述设备的运行指标包括：所述设备的被占用的硬件资源指标、所述设备的通信指标；

若所述设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于所述第一运行指标，输出所述机器资源异常告警或所述机器整机健康指标异常告警。

结合第一方面的第二种可能的实施例，在第四种可能的实施例中，所述方法还包括：

实时监测各服务实例的运行指标，其中，所述服务实例的运行指标包括：所述服务实例占用的硬件资源指标、所述服务实例的读写效率；

若所述服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于所述第二运行指标，输出所述服务实例资源异常告警或者所述服务实例健康指标异常告警。

结合第一方面的第二种可能的实施例，在第五种可能的实施例中，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至所述目标设备中，其中，所述第一异常机器设备为所述机器资源异常告警对应的设备。

结合第一方面的第二种可能的实施例，在第六种可能的实施例中，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至所述目标设备中，其中，所述第二异常机器设备为所述机器整机健康指标异常告警对应的设备。

结合第一方面的第二种可能的实施例，在第七种可能的实施例中，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为服务实例资源异常告警，将所述服务实例资源异常的服务实例迁移至第一目标设备中，其中，所述第一目标设备为：运行服务实例的各个设备中，剩余资源量满足所述服务实例资源异常的服务实例的运行需求的目标设备；

若所述目标告警类型为服务实例健康指标异常告警，将所述服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，所述第二目标设备为：尚未运行服务实例的空闲设备。

第二方面，本申请实施例提供了一种故障管理装置，其中，所述故障管理装置包括：

接收模块，用于接收异常告警信息，其中，所述异常告警信息是基于运行异常的异常服务实例发出的；

故障分析模块，用于基于接收到的异常告警信息，确定所述异常告警信息对应的目标告警类型，以及目标设备，其中，所述目标设备的运行资源满足所述异常服务实例的运行需求；

扩缩容模块，用于针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，其中，所述目标设备的运行资源满足所述异常服务实例的运行需求。

结合第二方面，在第二种可能的实施例中，所述目标告警类型包括资源类异常告警、健康指标类异常告警，所述资源类异常告警包括：机器资源异常告警、服务实例资源异常告警，所述健康指标类异常告警包括：机器整机健康指标异常告警、服务实例健康指标异常告警。

结合第二方面的第二种可能的实施例，在第三种可能的实施例中，所述装置还包括：

故障监测模块，用于实时监测运行各服务实例的设备的运行指标，其中，所述设备的运行指标包括：所述设备的被占用的硬件资源指标、所述设备的通信指标；

若所述设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于所述第一运行指标，输出所述机器资源异常告警或所述机器整机健康指标异常告警；

所述故障监测模块，还用于实时监测各服务实例的运行指标，其中，所述服务实例的运行指标包括：所述服务实例占用的硬件资源指标、所述服务实例的读写效率；

若所述服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于所述第二运行指标，输出所述服务实例资源异常告警或者所述服务实例健康指标异常告警；

所述扩缩容模块，具体用于若所述目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至所述目标设备中，其中，所述第一异常机器设备为所述机器资源异常告警对应的设备；

若所述目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至所述目标设备中，其中，所述第二异常机器设备为所述机器整机健康指标异常告警对应的设备；

若所述目标告警类型为服务实例资源异常告警，将所述服务实例资源异常的服务实例迁移至第一目标设备中，其中，所述第一目标设备为：运行服务实例的各个设备中，剩余资源量满足所述服务实例资源异常的服务实例的运行需求的目标设备；

若所述目标告警类型为服务实例健康指标异常告警，将所述服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，所述第二目标设备为：尚未运行服务实例的空闲设备。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：

处理器；以及

存储程序的存储器，

其中，所述程序包括指令，所述指令在由所述处理器执行时使所述处理器执行根据第一方面所述的故障管理方法。

第四方面，本申请实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使计算机执行根据第一方面所述的故障管理方法。

本申请的有益效果：

本申请实施例提供了一种故障管理方法、装置及电子设备，其中，该故障管理方法包括：接收异常告警信息，基于接收到的异常告警信息，确定异常告警信息对应的目标告警类型，以及目标设备，针对不同的目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至目标设备中。其中，由于异常告警信息是基于运行异常的异常服务实例发出的，目标设备的运行资源能满足异常服务实例的运行需求，如此，选用本申请实施例，能够在服务实例发生异常时，基于异常的服务实例发出的告警信息，自动将存在异常的服务实例迁移出原始的运行设备，降低该异常的服务实例对原始运行设备上其他服务实例的影响，且自动确定出能够满足该异常运行服务实例的运行需求的目标设备，运行该存在异常的服务实例，能够在用户未感知到故障存在的情况下，进行故障恢复，有效保障了用户使用体验。

附图说明

在下面结合附图对于示例性实施例的描述中，本申请的更多细节、特征和优点被公开，在附图中：

图1为本申请实施例提供的故障管理方法的一种可能的流程示意图；

图2为本申请实施例提供的故障管理方法的另一种可能的流程示意图；

图3为本申请实施例提供的故障管理方法的另一种可能的流程示意图；

图4为本申请实施例提供的故障管理方法的另一种可能的流程示意图；

图5为本申请实施例提供的故障管理方法的一种可能的实际应用流程示意图；

图6为本申请实施例提供的故障管理装置的一种可能的逻辑结构示意图；

图7为本申请实施例提供的电子设备的一种可能的逻辑结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施例。虽然附图中显示了本申请的某些实施例，然而应当理解的是，本申请可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本申请。应当理解的是，本申请的附图及实施例仅用于示例性作用，并非用于限制本申请的保护范围。

应当理解，本申请的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本申请的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。需要注意，本申请中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本申请中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本申请实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

随着互联网时代的高速发展以及移动互联网时代的到来，各大网站和平台的用户高速上涨，因此，需要服务能在异常场景下迅速发现并恢复。尤其在各大活动以及节日时，用户对服务的访问量激增，提供服务的服务器被高密度访问。此时，若用户所需的服务能够快速止损恢复，或者提供服务的服务器能做到不延迟、不中断、不宕机且快速响应用户访问需求，可有效保障用户的使用体验。

相关技术中，采用告警系统与人工维护相结合的方式来保障用户所需服务的稳定性。具体体现于由人工在接收到告警系统发出的异常告警后，手动根据异常告警信息迅速对出现的异常进行维护。此种采用告警系统与人工维护相结合的方式对人工响应速度、人工异常处理能力要求较高。若人工响应不及时或异常处理能力较差，将加重对用户的使用体验的负面影响。

有鉴于此，第一方面，本申请实施例提供了一种故障管理方法，用于自动处理用户所需服务出现的异常，进而保障用户的使用体验。其中，本申请实施例提供的故障管理方法可应用于任一具备故障管理能力的电子设备中，该电子设备包括但不限于：个人移动终端，计算机或者服务器设备等。

如图1所示，在一种可能的实施例中，本申请所提供的故障管理方法包括如下几个步骤：

S11、接收异常告警信息；

其中，该异常告警信息是基于运行异常的异常服务实例发出的。

S12、基于该异常告警信息，确定异常告警信息对应的目标告警类型，以及目标设备；

其中，该目标设备的运行资源满足该异常服务实例的运行需求。

S13、针对该目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至该目标设备中。

在本申请实施例中，由于异常告警信息是基于运行异常的异常服务实例发出的，目标设备的运行资源能满足异常服务实例的运行需求。因此，选用本申请实施例，能够在服务实例发生异常时，基于异常的服务实例发出的告警信息，自动将存在异常的服务实例迁移出原始的运行设备，降低该异常的服务实例对原始运行设备上其他服务实例的影响，且自动确定出能够满足该异常运行服务实例的运行需求的目标设备，运行该存在异常的服务实例，能够在用户未感知到故障存在的情况下，进行故障恢复，有效保障了用户使用体验。

下文将对上述步骤S11至步骤S13进行详细说明：

在步骤S11中，异常告警信息是针对各个为了向用户提供的服务，所运行的各服务实例的实时监测结果产生的。也即是说，在本申请实施例中，通过对运行向用户提供的服务的一个或多个服务实例进行实时监测，监测各服务实例的运行状态是否正常，若运行状态异常，则输出该异常告警信息。

其中，监测各服务实例的运行状态是否正常可通过监测服务实例所占用的资源情况、运行各服务实例的设备的健康情况来确定得到，其中，此处所提及的资源情况是指占用的计算资源、内存资源、通信信道资源等等资源的具体情况。示例性的，若运行服务实例的设备显示已经断电或者死机，表明该设备已经无法健康运行服务实例，处于一种异常的健康状态，此时可基于运行该服务实例的设备的健康情况，输出告警信息。

或者，若服务实例所占用的资源很大，或者超出了运行该服务实例的设备所能支持的最大资源量，则表明该服务实例存在无法运行于该设备中的风险，此时可基于该服务实例占用资源的情况，输出异常告警信息。

基于此，本申请实施例中，异常告警信息又细分为：资源类异常告警信息、健康指标类异常告警信息，资源类异常告警信息又包括：机器资源异常告警信息，服务实例资源异常告警信息，健康指标类异常告警信息又包括：机器整机健康指标异常告警信息、服务实例健康指标异常告警信息。

具体的，在一种可能的实施例中，可如图2所示，在执行步骤S11之前，本申请所提供的故障管理方法还包括如下步骤S21与步骤S22，以根据运行各服务实例的设备的健康状况，输出异常告警信息：

S21、实时监测运行各服务实例的设备的运行指标；

其中，该设备的运行指标包括：设备的被占用的硬件资源指标、该设备的通信指标等。

设备被占用的硬件资源指标包括：设备的CPU的被占用情况，设备的内存的被占用情况，设备的磁盘的被占用情况，设备的IO(Input Output，输入输出)端口被占用情况等等。其中，设备占用的硬件资源指标、通信指标等信息可通过查询设备的运行日志确定得到。

其中，设备被占用的硬件资源指标可以针对某一单一指标，也可以针对多个指标综合确定出一个综合性指标，具体需要监测的设备被占用的硬件资源指标的类型可根据实际项目或者实际需求进行灵活选择，本申请不作具体限定。

设备的通信指标包括：设备的IO读数据的效率、设备的IO的写数据的效率、设备的网络带宽等等。其中，设备的通信指标也可以针对某一单一指标，也可以是针对多个指标综合确定出的一个综合性指标，具体的通信指标的类型可根据实际项目或者实际需求进行灵活选择，本申请不作严格限定。其中，设备的通信指标等信息可通过查询设备的运行日志，或者通过监测设备的流量确定得到。

S22、若该设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于该第一运行指标，输出异常告警信息。

其中，该异常告警信息为：机器资源异常告警信息或者机器整机健康指标异常告警信息。预设设备健康运行指标条件为能够正常运行用户所需服务的各服务实例的硬件资源指标、通信指标条件。其中，预设设备健康指标条件可以根据设备的运行指标情况确定得到。

示例性的，在一种可能的应用场景中，机器资源异常告警信息，是基于如下一个或者多个预设设备健康指标条件输出得到的：

预设设备健康指标条件1：整机CPU监控使用率小于预设设备CPU使用率阈值。比如，整机CPU监控使用率大于90％，则第一运行指标为CPU的监控使用率，基于此，可输出机器资源异常告警，并在异常告警信息中携带具体异常告警的原因：CPU使用率超标。

预设设备健康指标条件2：整机内存使用率小于预设内存使用率阈值。比如，整机内存使用率大于70％，则第一运行指标为内存使用率，基于此，可输出机器资源异常告警，并在异常告警信息中携带具体异常告警的原因：内存使用率超标。

预设设备健康指标条件3：IO写入速率小于预设写入速率阈值。比如，IO写入速率大于70％，则第一运行指标为IO写入速率，基于此，可输出机器资源异常告警，并在异常告警信息中携带具体异常告警的原因：IO写入速率超标。

另外，在另一种可能的应用场景中，机器健康指标异常告警信息，是基于如下一个或者多个预设设备健康运行指标条件输出的：

预设设备健康指标条件4：运行服务实例的设备是否存在异常重启，若存在异常重启，则第一运行指标为异常重启，基于此，输出机器健康指标异常告警信息，并在异常告警信息中携带具体异常告警的原因：机器异常重启。

预设设备健康指标条件5：运行服务实例的设备是否断电，若断电，则第一运行指标为断电，基于此，输出机器健康指标异常告警信息，并在异常告警信息中携带具体异常告警的原因：机器断电。

预设设备健康指标条件6：运行服务实例的设备是否死机，若存在死机，则第一运行指标为死机，基于此，输出机器健康指标异常告警信息，并在异常告警信息中携带具体异常告警的原因：机器死机。

预设设备健康指标条件7：运行服务实例的设备的k8s(kubernetes，一种可移植容器的编排管理工具)是否挂了，若k8s挂了，则第一运行指标为：k8s挂了，基于此，输出机器健康指标异常告警信息，并在异常告警信息中携带具体异常告警的原因：k8s挂了。

预设设备健康指标条件8：运行服务实例的设备的docker(一种用于创建、管理和编排的服务实例的容器)是否存在异常，若存在异常，则第一运行指标为：docker异常，基于此，输出机器健康指标异常告警信息，并在异常告警信息中携带具体异常告警的原因：docker异常。

针对其他设备的被占用的硬件资源指标、通信指标对应的预设设备健康指标条件，可根据实际应用需求，结合上述指标条件设计得到，本申请不再一一赘述。

在一种可能的实施例中，异常告警中携带的异常告警原因，可通过预设的编码替代对应的异常告警原因，以便执行步骤S11以及执行步骤S12时能够基于接收到的异常告警消息中携带的异常告警编码，确定对应的异常告警的原因。

或者，在另一种可能的实施例中，可如图3所示，在执行步骤S11之前，本申请所提供的故障管理方法，还包括如下步骤S31与步骤32，以根据各服务实例占用资源的情况，输出异常告警信息：

S31、实时监测各服务实例的运行指标；

其中，服务实例的运行指标包括：服务实例占用的硬件资源指标、服务实例的读写效率。

其中，服务实例占用的硬件资源指标包括：目标服务实例占用设备的CPU的情况、目标服务实例占用设备的内存情况、目标服务实例占用设备的IO情况等等。示例性的，服务实例占用硬件资源指标可以为：目标服务实例占用CPU的核数。其中，服务实例占用的硬件资源指标通过监测各服务所处的端口，监控各服务所处的存储位置以及监控各服务在CPU中所占的进程等方式确定得到。

服务实例的读写效率包括：服务实例通过IO端口读取/写入CPU的效率，服务实例通过IO端口读取/写入内存的效率等等。其中，服务实例的读写效率可通过流量监控、日志监控以及进程监控等方式确定得到。

S32、若服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于该第二运行指标，输出异常告警信息。

其中，该异常告警信息为：服务实例资源异常告警信息或者服务实例健康指标异常告警信息。预设服务实例健康运行指标条件为：用户所需的服务的各服务实例的正常运行资源条件以及读取/写入条件。其中，预设服务实例健康运行指标条件可以根据各服务实例的运行指标情况确定得到。

示例性的，在一种可能的应用场景中，服务实例资源异常告警信息，是基于如下一个或者多个预设服务实例健康指标条件输出得到的：

预设服务实例健康指标条件1：服务实例的CPU监控使用率小于预设服务实例CPU使用率阈值。比如，服务实例申请使用的CPU为4核的，实际该服务实例使用CPU的量超出了4核，为6核。此时，第二运行指标为服务实例的CPU的监控使用率，基于此，可输出服务实例资源异常告警，并在异常告警信息中携带具体异常告警的原因：服务实例CPU使用率超标。

具体的，服务实例资源异常告警信息以及服务实例健康指标异常告警信息，具体输出方法，与机器资源告警信息或者机器健康指标异常告警信息输出方法相类似，均是基于正常运行指标条件，输出异常的服务实例的告警信息。具体的输出异常的服务实例的告警信息的方法，可参考机器资源异常告警信息或者机器健康指标异常告警信息的输出方法，本文不再重复赘述。

选用本申请实施例，可通过实时监测运行服务实例的设备是否正常、健康地运行，或者实时监测服务实例是否正常、健康地运行，来判断服务实例在运行过程中是否存在异常运行的情况。进一步的，基于存在的异常情况，输出对应的异常告警信息，以助于后续基于输出的异常告警信息，采取相对应的服务实例迁移方案，从而保障在用户无感的情况下，对存在故障的服务实例进行恢复。

在执行步骤S21～S22和/或，执行步骤S31～S32过程中，可以是机房监测设备不断实时监测到的各服务实例的运行状态、运行各服务实例的设备的运行状态，然后基于运行异常的异常服务实例发出异常告警信息。如此，在执行步骤S11时，通过接收机房监测设备发出的异常告警信息，以助于后续基于接收到的异常告警信息，自动确定存在异常的对象是服务实例本身，还是运行服务实例的设备。

在一种可能的实施例中，异常告警信息中携带有异常告警的目标告警类型，基于此，在执行步骤S12时，可基于携带的异常告警的目标告警类型，可确定出具体存在异常的对象。以及基于异常的服务实例对象所需的运行资源需求，确定出可运行该异常服务实例的目标设备。

其中，目标设备的运行资源包括：CPU核数、内存容量、磁盘容量、I/O端口数、读写数据的效率等等。在本申请实施例中，服务实例所需的运行资源需求包括：CPU核数、内存容量、磁盘容量、I/O端口数、读写数据的效率等等。在执行步骤S12时，确定可运行异常服务实例的目标设备的具体过程，是基于服务实例所需的运行资源需求，比如CPU核数，内存大小以及磁盘容量大小，同资源池中各设备当前剩余可用的运行资源进行比较，确定出当前剩余可用的运行资源大于异常服务实例所需的运行资源需求的设备，即为目标设备。

基于步骤S12确定得到的目标设备，在一种可能的实施例中，在执行步骤S13时，可通过如下步骤实现：

S131、若目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至目标设备中，其中，第一异常机器设备为机器资源异常告警对应的设备。

在本申请实施例中，若目标告警类型为机器资源异常告警，则表明该设备的资源无法支撑服务的使用，于是，可通过将资源需求量最大的服务实例迁移至目标设备以解决设备资源不足的问题。

示例性的，第一步：通过对资源使用量进行排序，按照服务的描述信息中的资源信息进行排序，确定出各服务实例所占用的资源情况。第二步，将资源占用量最大的服务实例筛选出来。第三步，在资源池中筛选出可支持该资源占用量最大的服务实例(假设该服务实例为服务实例A)运行的目标设备。具体通过服务的端口、部署路径、资源需求等等服务描述信息，确定出目标设备。比如，剩余资源量至少为此服务实例A的当前需求的2倍，比如，该服务实例A需要2核4G，但是该服务实例A当前已经使用量已经超到了3核6G，此时，确定空闲资源需超过6核16G的目标设备(假设为目标设备A)。第四步，根据该服务实例A的描述信息以及目标设备A的机器信息，将该服务实例A迁移至目标设备A中，由目标设备A继续运行该服务实例A。

在另一种可能的实施例中，在执行步骤S13时，还可通过如下步骤实现：

S132、若目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至目标设备中，其中，第二异常机器设备为机器整机健康指标异常告警对应的设备。

在本申请实施例中，若目标告警类型为机器健康指标异常告警，则表明该设备存在故障，于是，需要将该故障的设备上运行的各服务实例迁移至可用的目标设备中。

示例性的，在执行步骤S21以及步骤S22时，实时监测到机器1出现异常断电，此时基于该情况输出异常告警信息，即输出携带有异常告警原因为异常断电的机器健康指标异常告警信息，并将此机器健康指标异常告警信息发送至故障监测模块。由故障监测模块执行步骤S11以及步骤S12，接收该机器健康指标异常告警信息，并基于携带的异常告警原因，可判断出该机器1无法正常运行各服务实例，也即是说，运行于机器1上的各服务实例均出现异常。

如此，可以是需要确定出一台全新的机器1-1，并将原本运行于机器1上的各服务实例迁移至该全新的机器1-1上。或者，可以确定出资源池中能够满足机器1上各服务实例的运行资源需求的目标设备1-2、目标设备1-3、目标设备1-4···，然后将各服务实例分别迁移至各目标设备中。

同理，可通过获取故障机器1上各个服务实例的描述信息，以及待迁移的机器信息，将故障机器1中的各服务实例迁移至新的目标设备中。此外，还可控制原故障机器1关闭，并发送故障提醒信息，以提醒维护人员对故障机器1进行维修。

在另一种可能的实施例中，在执行步骤S13时，还可通过如下步骤实现：

S133、若目标告警类型为服务实例资源异常告警，将服务实例资源异常的服务实例迁移至第一目标设备中，其中，第一目标设备为：运行服务实例的各个设备中，剩余资源量满足所述服务实例资源异常的服务实例的运行需求的目标设备；

若目标告警类型为服务实例资源异常告警，则表明该服务实例所使用的资源量超出了原本自身申请使用的资源量。具体产生此种情形的原因为：服务异常日志数据暴增，或者用户对该服务的请求量出现了暴增。此时，此类服务实例会抢占所处运行设备上的资源，为了减少此类服务实例对其他各正常运行的服务实例的影响，针对此类服务实例资源异常告警，本申请实施例通过在资源池中筛选出可满足该异常的服务实例的运行资源需求的目标设备，然后根据该服务实例的具体部署方式，初始化待迁移的目标设备的环境变量，并根据服务描述信息和待迁移的目标设备信息，将该存在资源异常的服务实例迁移至目标服务设备中。此外，整个过程中，需等待该服务实例从原运行设备上下线后，方可将该存在资源异常的服务实例迁移至目标设备中。

S134、若目标告警类型为服务实例健康指标异常告警，将服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，第二目标设备为：尚未运行服务实例的空闲设备。

针对此类服务实例健康指标异常告警，表明了该服务实例属于内部原因导致的异常，为了避免该异常影响其他运行于同一设备上的其他服务实例，需要将该存在健康指标异常的服务实例(假设为服务实例A)，迁移至尚未运行服务实例的空闲设备中。

示例性的，在执行步骤S31以及步骤S32时，实时监测到运行于设备A上的服务实例A出现进程挂掉了，此时基于该异常情况输出异常告警信息，即输出携带有异常告警原因为进程异常挂掉的服务健康指标异常告警，并将此服务健康指标异常告警信息发送至故障监测模块。由故障监测模块执行步骤S11以及步骤S12，接收该服务实例健康指标异常告警信息，并基于该服务实例健康指标异常告警信息携带的异常告警原因，可判断出该服务实例A的进程挂掉了，无法运行于该设备A上。在执行步骤S12时，可根据服务实例A所需的运行资源，确定出一台运行资源满足该服务实例运行需求的空设备，然后根据该服务实例A的描述信息以及确定出的第二目标设备的机器信息，将该服务实例A迁移至第二目标设备中。

在一种可能的实施例中，本申请所提供的故障管理方法的执行主体为单一电子设备，由执行主体内的各个子模块分别执行上述各步骤。

在一种可能的实施例中，本申请所提供的故障管理方法的执行主体为故障管理系统，该故障管理系统由多个电子设备组合而成，在本申请实施例中，可如图4所示，故障管理系统可包括：资源池41、监控系统42、故障分析处理机器人43、扩缩容系统44。

具体的，在此实施例中，通过监控系统42执行上述步骤S21～S22和/或步骤S31～S32，以监测资源池41中运行的各个服务(服务A～服务E)的状态，以及各运行各服务的机器(机器1～机器3)的状态，基于监测结果发送异常告警信息至故障分析处理机器人43。

然后，由故障分析处理机器人43执行上述步骤S11、步骤S12，通过接收子系统接收异常告警信息，结合各设备的状态进行分析，确定出可用的目标设备，将目标设备的地址信息以及资源状态发送至扩缩容系统44。最后，由扩缩容系统44执行上述步骤S13，基于接收到的信息，将存在异常的异常服务迁移至目标设备中。

在一种可能的应用场景中，可如图5所示，本申请所提供的故障管理方法可通过图5所示的流程进行故障管理。其中，通过接收到的异常告警信息，判断告警范围，属于机器层面的告警，还是服务级别的告警。

对于机器层面的告警，进一步判断机器告警的类型属于资源类的告警，还是机器健康类的告警。对于资源类的告警，通过对该机器上所有服务资源使用量进行排序，获取资源占用量最大的服务，然从资源池中筛选出适合这个服务扩容的机器，并获取该服务的描述信息，然后将服务描述信息与目标设备信息传递到扩缩容系统，最终由扩缩容系统进行故障迁移。对于机器健康类的告警，通过获取机器上所有服务描述信息，然后初始化一台新机器的环境部署条件，将该新机器的环境部署条件修改与旧机器保持一致，然后关闭问题机器，并等待修理。最后，获取各服务的描述信息，然后将服务描述信息与目标设备信息传递到扩缩容系统，最终由扩缩容系统进行故障迁移。

对于服务级的告警，通过告警信息分析，进一步判断告警类型，属于服务健康指标异常告警，还是服务资源异常告警。对于服务资源异常告警，从资源池中筛选出适合这个服务扩容的机器，并获取该服务的描述信息，然后将服务描述信息与目标设备信息传递到扩缩容系统，最终由扩缩容系统进行故障迁移。对于服务健康指标异常告警，直接在资源池内获取一台空机器，然后获取该异常服务的描述信息，然后将服务描述信息与目标设备信息传递到扩缩容系统，最终由扩缩容系统进行故障迁移。

其中，扩缩容系统44将异常的服务实例或者服务迁移至目标设备中的过程，可以形象理解为，目标设备是桶，服务实例是桶内装的元素，扩缩容系统44在执行上述步骤S13时，可通过如下具体步骤实现：

S41、判断所有服务实例中，各个服务实例占用的资源占比分布。比如16核的、8核的、4核的、2核的、1核的各自有多少个。

S42、将服务实例的CPU按照耗时，分别放入不同的集合中。

S43、确认每台设备的CPU分布比例，按照整体比例做判断，比如总核数是32核，那么最小实例数就是16核一个，8核一个，4核一个，2核一个，1核两个，最小实例数位6，最大实例数位17(一个16核其他全为1核)等。

S44、开始服务实例迁移，计算机器上部署一个大核实例和多个小核实例至该机器CPU满，如果大核实例数在小核实例数用完之后，如果还有剩余，则返回大核剩余实例数。将剩余实例继续放在下一列迁移，比如16核和1核是一对，1核用完了16核还有，那么16核放在8核的集合中继续成对迁移，假设1核有剩余，那么1核放在2核的集合中继续迁移，通常默认4c核为最好的实例，因为4c核的实例最容易迁移。

选用本申请实施例，可在无需人工操作的情况下，自动根据不同的异常告警信息，分别判断是将单一服务实例迁移至目标设备中，还是将机器上的各服务实例或者占用运行资源最大的服务实例迁移至目标设备中，然后在用户无感的情况下，将存在异常的服务实例或者服务设备进行维护，很好地解决了现有服务实例维护方案效率较低的问题。

第二方面，本申请实施例提供了一种故障管理装置，如图6所示，该装置600包括如下几个部分：

接收模块601，用于接收异常告警信息，其中，异常告警信息是基于运行异常的异常服务实例发出的。

故障分析模块602，用于基于接收到的异常告警信息，确定异常告警信息对应的目标告警类型，以及目标设备，其中，目标设备的运行资源满足异常服务实例的运行需求。

扩缩容模块603，用于针对目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至目标设备中，其中，目标设备的运行资源满足异常服务实例的运行需求。

在一种可能的实施例中，目标告警类型包括资源类异常告警、健康指标类异常告警，资源类异常告警包括：机器资源异常告警、服务实例资源异常告警，健康指标类异常告警包括：机器整机健康指标异常告警、服务实例健康指标异常告警。

在一种可能的实施例中，该装置600还包括：

故障监测模块604，用于实时监测运行各服务实例的设备的运行指标，其中，设备的运行指标包括：设备的被占用的硬件资源指标、设备的通信指标；

若设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于第一运行指标，输出机器资源异常告警或机器整机健康指标异常告警。

在一种可能的实施例中，故障监测模块604，还用于实时监测各服务实例的运行指标，其中，服务实例的运行指标包括：服务实例占用的硬件资源指标、服务实例的读写效率；

若服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于第二运行指标，输出服务实例资源异常告警或者服务实例健康指标异常告警。

在一种可能的实施例中，扩缩容模块603，具体用于若目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至目标设备中，其中，第一异常机器设备为机器资源异常告警对应的设备。

在一种可能的实施例中，扩缩容模块603，具体用于若目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至目标设备中，其中，第二异常机器设备为机器整机健康指标异常告警对应的设备。

在一种可能的实施例中，扩缩容模块603，具体用于若目标告警类型为服务实例资源异常告警，将服务实例资源异常的服务实例迁移至第一目标设备中，其中，第一目标设备为：运行服务实例的各个设备中，剩余资源量满足服务实例资源异常的服务实例的运行需求的目标设备。

在一种可能的实施例中，扩缩容模块603，具体用于若目标告警类型为服务实例健康指标异常告警，将服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，第二目标设备为：尚未运行服务实例的空闲设备。

本申请示例性实施例还提供一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器。所述存储器存储有能够被所述至少一个处理器执行的计算机程序，所述计算机程序在被所述至少一个处理器执行时用于使所述电子设备执行根据本申请实施例的方法。

本申请示例性实施例还提供一种存储有计算机程序的非瞬时计算机可读存储介质，其中，所述计算机程序在被计算机的处理器执行时用于使所述计算机执行根据本申请实施例的方法。

本申请示例性实施例还提供一种计算机程序产品，包括计算机程序，其中，所述计算机程序在被计算机的处理器执行时用于使所述计算机执行根据本申请实施例的方法。

参考图7，现将描述可以作为本申请的服务器或客户端的电子设备700的结构框图，其是可以应用于本申请的各方面的硬件设备的示例。电子设备旨在表示各种形式的数字电子的计算机设备，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

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

电子设备700中的多个部件连接至I/O接口705，包括：输入单元706、输出单元707、存储单元708以及通信单元709。输入单元706可以是能向电子设备700输入信息的任何类型的设备，输入单元706可以接收输入的数字或字符信息，以及产生与电子设备的用户设置和/或功能控制有关的键信号输入。输出单元707可以是能呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。存储单元708可以包括但不限于磁盘、光盘。通信单元709允许电子设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据，并且可以包括但不限于调制解调器、网卡、红外通信设备、无线通信收发机和/或芯片组，例如蓝牙TM设备、WiFi设备、WiMax设备、蜂窝通信设备和/或类似物。

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

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

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

如本申请使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

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

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

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

Claims (12)

1.一种故障管理方法，其特征在于，所述方法包括：

接收异常告警信息，其中，所述异常告警信息是基于运行异常的异常服务实例发出的；

基于所述异常告警信息，确定所述异常告警信息对应的目标告警类型，以及目标设备，所述目标设备的运行资源满足所述异常服务实例的运行需求；

针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中。

2.根据权利要求1所述的方法，其特征在于，所述目标告警类型包括资源类异常告警、健康指标类异常告警，所述资源类异常告警包括：机器资源异常告警、服务实例资源异常告警，所述健康指标类异常告警包括：机器整机健康指标异常告警、服务实例健康指标异常告警。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

实时监测运行各服务实例的设备的运行指标，其中，所述设备的运行指标包括：所述设备的被占用的硬件资源指标、所述设备的通信指标；

若所述设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于所述第一运行指标，输出所述机器资源异常告警或所述机器整机健康指标异常告警。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

实时监测各服务实例的运行指标，其中，所述服务实例的运行指标包括：所述服务实例占用的硬件资源指标、所述服务实例的读写效率；

若所述服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于所述第二运行指标，输出所述服务实例资源异常告警或者所述服务实例健康指标异常告警。

5.根据权利要求2所述的方法，其特征在于，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至所述目标设备中，其中，所述第一异常机器设备为所述机器资源异常告警对应的设备。

6.根据权利要求2所述的方法，其特征在于，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至所述目标设备中，其中，所述第二异常机器设备为所述机器整机健康指标异常告警对应的设备。

7.根据权利要求2所述的方法，其特征在于，所述针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至所述目标设备中，包括：

若所述目标告警类型为服务实例资源异常告警，将所述服务实例资源异常的服务实例迁移至第一目标设备中，其中，所述第一目标设备为：运行服务实例的各个设备中，剩余资源量满足所述服务实例资源异常的服务实例的运行需求的目标设备；

若所述目标告警类型为服务实例健康指标异常告警，将所述服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，所述第二目标设备为：尚未运行服务实例的空闲设备。

8.一种故障管理装置，其特征在于，所述故障管理装置包括：

接收模块，用于接收异常告警信息，其中，所述异常告警信息是基于运行异常的异常服务实例发出的；

故障分析模块，用于基于接收到的异常告警信息，确定所述异常告警信息对应的目标告警类型，以及目标设备，其中，所述目标设备的运行资源满足所述异常服务实例的运行需求；

扩缩容模块，用于针对所述目标告警类型，按照预设故障调度策略，将运行异常的异常服务实例迁移至目标设备中，其中，所述目标设备的运行资源满足所述异常服务实例的运行需求。

9.根据权利要求8所述的装置，其特征在于，所述目标告警类型包括资源类异常告警、健康指标类异常告警，所述资源类异常告警包括：机器资源异常告警、服务实例资源异常告警，所述健康指标类异常告警包括：机器整机健康指标异常告警、服务实例健康指标异常告警。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

故障监测模块，用于实时监测运行各服务实例的设备的运行指标，其中，所述设备的运行指标包括：所述设备的被占用的硬件资源指标、所述设备的通信指标；

若所述设备的各项运行指标中存在不满足预设设备健康运行指标条件的第一运行指标，基于所述第一运行指标，输出所述机器资源异常告警或所述机器整机健康指标异常告警；

所述故障监测模块，还用于实时监测各服务实例的运行指标，其中，所述服务实例的运行指标包括：所述服务实例占用的硬件资源指标、所述服务实例的读写效率；

若所述服务实例的运行指标中存在不满足预设服务实例健康运行指标条件的第二运行指标，基于所述第二运行指标，输出所述服务实例资源异常告警或者所述服务实例健康指标异常告警；

所述扩缩容模块，具体用于若所述目标告警类型为机器资源异常告警；将第一异常机器设备上运行的占用资源最大的服务实例迁移至所述目标设备中，其中，所述第一异常机器设备为所述机器资源异常告警对应的设备；

若所述目标告警类型为机器整机健康指标异常告警，将第二异常机器设备上运行的各服务实例迁移至所述目标设备中，其中，所述第二异常机器设备为所述机器整机健康指标异常告警对应的设备；

若所述目标告警类型为服务实例资源异常告警，将所述服务实例资源异常的服务实例迁移至第一目标设备中，其中，所述第一目标设备为：运行服务实例的各个设备中，剩余资源量满足所述服务实例资源异常的服务实例的运行需求的目标设备；

若所述目标告警类型为服务实例健康指标异常告警，将所述服务实例健康指标异常的服务实例迁移至第二目标设备中，其中，所述第二目标设备为：尚未运行服务实例的空闲设备。

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

处理器；以及

存储程序的存储器，

其中，所述程序包括指令，所述指令在由所述处理器执行时使所述处理器执行根据权利要求1-7中任一项所述的方法。

12.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使计算机执行根据权利要求1-7中任一项所述的方法。