故障处理方法、装置、系统服务器及计算机可读存储介质与流程

本发明涉及计算机技术领域，具体涉及一种故障处理方法、装置、系统服务器及计算机可读存储介质。

背景技术：

随着服务器系统的规模和复杂程度越来越大，随时都会发生各种各样的故障，每个故障都可能导致系统发出一个或多个告警来通知运维人员，面对海量的告警数据，运维人员需要快速定位故障来源，以降低故障造成的损失。

告警类型可以分为系统型告警和业务型告警，对于业务型告警，很难确定告警原因。同时存在的多个告警之间可以存在关联关系，例如，一个系统型告警可以引发另一个业务型告警。

因此，如何确定告警之间的关联关系，以快速定位故障原因成为亟待解决的技术问题。

技术实现要素：

本发明实施例公开了一种故障处理方法、装置、系统服务器及计算机可读存储介质，可以确定系统告警事件与业务告警事件之间的关联关系，从而有利于根据系统告警事件与业务告警事件之间的关联关系快速定位故障原因。

第一方面，本发明实施例公开了一种故障处理方法，该方法应用于系统服务器，该方法可以包括：获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量，目标服务设备存在于系统服务器管理的服务设备中；根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率；针对前述各个系统告警事件，将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件；针对前述各种业务告警事件，将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

在一种实现方式中，根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率的具体实施方式可以为：在目标时间段中确定多个时间点，确定的多个时间点中相邻的两个时间点对应一个子时间段；获取在目标时间段中的相同时间点下，前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值；针对目标时间段中相邻的两个时间点，对后一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值，以及前一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值进行除法运算，将得到的结果作为前一个时间点和后一个时间点对应的子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率；根据目标时间段中所有子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

在一种实现方式中，该方法还可以包括：将与前述各个系统告警事件具有关联关系的业务告警事件的标识和该系统告警事件的标识关联存储于预设数据库。

在一种实现方式中，预设数据库中可以存储有第一系统告警事件的标识，该方法还可以包括：在发生第一系统告警事件时，从预设数据库中确定与第一系统告警事件的标识具有关联关系的第一业务告警事件的标识；根据第一系统告警事件的标识，获取第一系统告警事件的发生时间；根据发生时间和预设时长，确定发生时间段，发生时间段的开始时间为该发生时间，发生时间段的时长为预设时长；若在发生时间段中未发生第一业务告警事件的标识对应的第一业务告警事件，则在预设数据库中删除第一系统告警事件的标识和第一业务告警事件的标识之间的关联关系。

在一种实现方式中，预设数据库中可以存储有第二业务告警事件的标识，第二业务告警事件对应的故障原因可以包括第二业务告警事件对应的系统资源的使用发生异常，该方法还可以包括：当第二业务告警事件的数量大于第一预设数量时，获取第二业务告警事件对应的系统资源的使用情况信息，该使用情况信息包括系统资源的占用率和运行性能中的至少一种；将该使用情况信息发送给预设设备，以使预设设备输出该使用情况信息。

在一种实现方式中，预设数据库中可以存储有第二业务告警事件的标识，该方法还可以包括：当第二业务告警事件的数量大于第二预设数量时，从预设数据库中确定与第二业务告警事件的标识具有关联关系的第二系统告警事件的标识；获取第二系统告警事件的标识对应的解决方案信息；执行解决方案信息包括的步骤。

在一种实现方式中，执行解决方案信息包括的步骤之后，该方法还可以包括：获取第二系统告警事件的标识对应的检测程序；执行检测程序，得到检测结果，检测结果用于指示第二系统告警事件的标识对应的第二系统告警事件是否消失；若检测结果指示第二系统告警事件未消失，则输出提醒信息。

第二方面，本发明实施例公开了一种故障处理装置，该装置包括用于执行上述第一方面所述的方法的单元。

第三方面，本发明实施例公开了一种系统服务器，该系统服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行上述第一方面所述的方法。

通过实施本发明实施例，可以根据各个系统告警事件的告警数值以及各种业务告警事件的数量，得到各个系统告警事件的告警数值与各种业务告警事件的数量之间的平均波动比率，然后将平均波动比率位于预设波动比率范围内的业务告警事件确定为与系统告警事件具有关联关系的业务告警事件，进而将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因，即通过实施本发明实施例，有利于快速定位故障原因。

附图说明

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

图1是本发明实施例提供的一种故障处理方法的流程示意图；

图2是本发明实施例提供的另一种故障处理方法的流程示意图；

图3是本发明实施例提供的又一种故障处理方法的流程示意图；

图4是本发明实施例提供的一种故障处理装置的结构示意图；

图5是本发明实施例提供的一种系统服务器的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1，图1是本发明实施例提供的一种故障处理方法的流程示意图。该方法应用于系统服务器，该系统服务器可以用于管理多个服务设备。具体的，如图1所示，本发明实施例的故障处理方法可以包括但不限于如下步骤：

s101、系统服务器获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量。

其中，目标服务设备存在于系统服务器管理的服务设备中。在本发明实施例中，一个系统可以由多个服务设备实现的业务功能组成，为了维护各个服务设备的正常运行，可以通过选择目标参数，显示用户希望看到的一些指标，进而更好地了解服务设备的运行状况。其中，当用户希望了解目标服务设备的标识对应的目标服务设备的运行状况时，目标参数可以包括目标时间段和目标服务设备的标识。可选的，目标服务设备的标识的数量可以为一个或多个，每个标识用于唯一标识一个服务设备，目标时间段可以包括一个或多个时间段。当一个系统由5个服务设备实现的业务功能组成时，该系统的系统服务器可以用于管理这5个服务设备，这5个服务设备的系统告警信息均可以发送给系统服务器，以便系统服务器了解这5个服务设备的运行状况。当目标参数包括目标时间段和目标服务设备的标识时，目标服务设备的系统告警信息可以包括目标服务设备在目标时间段内发生的所有系统告警事件的告警数值，其中，系统告警事件是指系统中的某个或者某些部件发生故障后导致的告警事件，系统告警事件也可以称为信息技术(informationtechnology，it)告警事件，可选的，系统告警事件可以包括但不限于：中央处理器(centralprocessingunit，cpu)告警事件(如cpu占用率)、数据库告警事件(如结构化查询语言(structuredquerylanguage，sql)平均耗时、吞吐量、缓存命中率等)、内存告警事件(如内存使用率)和网络带宽告警事件(如网络带宽使用情况)中的一种或多种。告警数值可以用于表征系统告警事件的告警严重程度，告警数值越大可以表明系统告警事件的告警程度越严重，告警数值越小可以表明系统告警事件的告警程度越轻微。

在本发明实施例中，告警严重程度可以根据该告警事件可能产生后果的严重程度确定，例如，若告警事件a会造成灾难性事故(如系统完全无法工作)，必须立即消除告警事件a，则告警事件a的严重程度是破坏性的，此时，告警事件a的告警数值可以为40；若告警事件a会造成人员伤亡或者系统破坏(如系统的部分功能无法实现)，需要立即消除告警事件a，则告警事件a的严重程度是危险的，此时，告警事件a的告警数值可以为30；若告警事件a有可能造成较轻的伤害和损坏，应采取措施以消除或减轻告警事件a，则告警事件a的严重程度是临界的，此时，告警事件a的告警数值可以为20；若告警事件a不会造成伤害和损坏，即不需要采取措施，则告警事件a的严重程度是安全的，此时，告警事件a的告警数值可以为10。

在本发明实施例中，除了服务设备中产生的系统告警事件，服务设备对应的系统中还可以产生业务告警事件，业务告警事件可以是用户主观行为上报的故障导致的告警事件，一般地，用户上报事件可以是业务层面的一些故障，例如，用户上报事件可以包括但不限于登录失败、无法打开登录页面和无法付款中的一种或多种。在本发明实施例中，用户通过用户设备上报的业务告警事件可以统一发送给系统服务器，以便系统服务器汇总所有用户上报的业务告警事件，进而了解系统当前在业务层面存在的故障。当系统中的某个业务功能存在故障时，当前在使用该功能的所有用户均可以发现该故障，且均可以向系统服务器反馈该故障，因此，系统服务器可能会在短时间内接收到不同用户上报的相同业务告警事件，系统服务器通过统计上报该业务告警事件的用户数量(即该业务告警事件的数量)，可以确定该业务告警事件的告警严重程度。具体的，该业务告警事件的数量越多可以表明该业务告警事件的告警程度越严重，该业务告警事件的数量越少可以表明该业务告警事件的告警程度越轻微。需要说明的是，系统服务器在短时间内也可以接收到不同用户发送的不同的业务告警事件，例如，用户1在时间段a内向系统服务器反馈业务告警事件a，用户2在时间段a内向系统服务器反馈业务告警事件b。

在一种实现方式中，用户通过用户设备向系统服务器反馈业务告警事件的方式可以有以下两种：第一种，用户通过用户设备直接向系统服务器反馈业务告警事件；第二种，用户通过用户设备向第一服务设备反馈业务告警事件，然后由第一服务设备将该业务告警事件发送给系统服务器，其中，当用户反馈业务告警事件时，表明系统中的某个功能发生故障，第一服务设备可以是用于实现该功能的服务设备。

需要说明的是，目标服务设备在目标时间段内发生的各个系统告警事件可以是目标服务设备在目标时间段内新发生的系统告警事件，也可以是目标服务设备在目标时间段内存在且还未处理的系统告警事件，也就是说，系统服务器获取的系统告警事件既可以包括在目标时间段内新发生的系统告警事件，也可以包括在目标时间段之前新发生的、且在目标时间段内仍存在且还未处理的系统告警事件。

还需要说明的是，系统服务器和系统服务器管理的服务设备可以是独立的物理实体，或者，系统服务器管理的服务设备可以存在于系统服务器内部，也就是说，服务设备可以是系统服务器的组成部分。

在本发明实施例中，服务设备可以是终端设备，也可以是服务器。其中，该终端设备可以是智能手机、平板电脑、个人计算机(personalcomputer，pc)、智能电视、智能手表、车载设备、可穿戴设备、未来第五代移动通信技术(the5thgeneration，5g)网络中的终端设备等，本发明实施例对此不作限定。

在一种实现方式中，系统服务器可以获取在系统服务器中显示的操作界面上的用户操作，并根据该用户操作确定目标参数，目标参数可以包括目标服务设备的标识和目标时间段。例如，系统服务器可以在操作界面上显示管理的所有服务设备的标识，以及目标时间段的输入框，当用户点击其中一个或多个标识时，确定用户需要了解所点击的标识对应的服务设备的运行状态，并且用户还可以在目标时间段的输入框中输入任意的时间段(例如当日晚上7点到8点)，这样系统服务器可以获取晚上7点到8点之间用户所选择的服务设备的运行状况信息。在一种实现方式中，当用户仅选择了标识，但是并未输入目标时间段时，系统服务器可以采用默认的目标时间段。在一种实现方式中，默认的目标时间段可以是前一日24小时或者前三日24小时，默认的目标时间段可以由用户自定义设置，本发明实施例对此不作限定。

在一种实现方式中，系统服务器可以基于大数据分析方法对各个服务设备在每日24小时内各个时间段内发生的各个系统告警事件的告警数值进行分析，以确定在哪个时间段内和/或哪个服务设备中发生的系统告警事件的数量最多(或者告警数值最大)，若在第一时间段内和/或第二服务设备中发生的系统告警事件的数量最多(或者告警数值最大)，则系统服务器可以将第一时间段作为目标时间段，并将第二服务设备作为目标服务设备。同理，系统服务器可以基于大数据分析方法对每日24小时内接收到的各种业务告警事件的数量进行分析，以确定在哪个时间段内接收到的业务告警事件的数量最多，若在第二时间段内接收到的业务告警事件的数量最多，则系统服务器可以将第二时间段作为目标时间段。例如，若基于大数据分析方法确定出服务设备1和服务设备2发生的系统告警事件最多，则系统服务器可以将服务设备1和服务设备2作为目标服务设备。又如，若基于大数据分析方法确定出在晚上7至8点发生的系统告警事件最多，则系统服务器可以将晚上7至8点作为目标时间段。通过这种方式，用户可以了解更易发生故障的服务设备1和服务设备2的运行状况(或者用户可以了解更易发生故障的晚上7至8点时间段对应的运行状况)，进而更加及时地修复发生的故障，从而有利于提高系统的稳定性。系统服务器通过大数据分析方法分析历史系统告警事件和历史业务告警事件，从而自动确定出目标时间段和目标服务设备，有利于提高确定目标时间段和目标服务设备的效率，并有利于提高故障处理效率和系统稳定性。

在一种实现方式中，当系统服务器基于大数据分析方法确定出第一时间段和/或第二服务设备之后，系统服务器可以在操作界面中显示第一时间段内和/或第二服务设备，以便用户选择是否将显示的第一时间段作为目标时间段(和/或是否将显示的第二服务设备作为目标服务设备)，若用户选择不将显示的第一时间段作为目标时间段(和/或不将显示的第二服务设备作为目标服务设备)，则系统服务器可以根据用户接下来的操作确定目标时间段和目标服务设备。

在一种实现方式中，目标参数还可以包括目标频率，系统服务器可以按照目标频率获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并按照目标频率获取系统服务器在目标时间段内接收到的各种业务告警事件的数量。例如，目标服务设备为服务设备1，目标时间段为2019年1月31日，目标频率为1小时，则可以在系统服务器的显示界面中显示在2019年1月31日内每小时获取到的服务设备1中发生的各个系统告警事件的告警数值，以及接收到的各种业务告警事件的数量。在一种实现方式中，对于时间比较敏感的系统告警事件或者业务告警事件(如较短时间内会发生较大数量变化的系统告警事件或者业务告警事件(如网页访问量在某些特定时间或者在短时间内会发生极大变化))，可以将目标频率设置的较小，通过这种方式，可以更准确地展示出系统告警事件或者业务告警事件随时间的变化情况。

s102、系统服务器根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

其中，前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率可以用于表征系统告警事件和业务告警事件之间的关联程度，例如，若系统告警事件1的告警数值与业务告警事件2的数量之间的平均波动比率与1之间的差值的绝对值越小，则表明系统告警事件1与业务告警事件2之间的关联程度越高；同理，若系统告警事件1的告警数值与业务告警事件2的数量之间的平均波动比率与1之间的差值的绝对值越大，则表明系统告警事件1与业务告警事件2之间的关联程度越低。需要说明的是，系统告警事件与业务告警事件之间的关联程度越高，表明系统告警事件与业务告警事件之间具有关联关系，也就是说，系统告警事件与业务告警事件之间会相互影响，例如，在产生系统告警事件且未产生业务告警事件时，若该系统告警事件与该业务告警事件具有关联关系，则一段时间后会因为系统告警事件导致业务告警事件的产生。同理，系统告警事件与业务告警事件之间的关联程度越低，表明系统告警事件与业务告警事件之间不具有关联关系，也就是说，系统告警事件与业务告警事件之间是相互独立的，不会相互影响。

在一种实现方式中，系统服务器根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率的具体实施方式可以为：在目标时间段中确定多个时间点，确定的多个时间点中相邻的两个时间点对应一个子时间段；获取在目标时间段中的相同时间点下，前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值；针对目标时间段中相邻的两个时间点，对后一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值，以及前一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值进行除法运算，将得到的结果作为前一个时间点和后一个时间点对应的子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率；根据目标时间段中所有子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

例如，若目标时间段为2019年1月31日晚上8-12点，则可以在目标时间段中确定5个时间点(8点、9点、10点、11点和12点)，其中，8-9点(或9-10点、10-11点和11-12点)组成一个时间段。若2019年1月31日内获取的系统告警事件包括系统告警事件1，获取的业务告警事件包括业务告警事件1和业务告警事件2，且系统告警事件1的告警数值、业务告警事件1的数量和业务告警事件2的数量随时间变化(8:00:00～12:00:00)的情况如表1所示。

表1系统告警事件1的告警数值、业务告警事件1的数量和

业务告警事件2的数量随时间变化的情况

根据表1中记载的数据，可以计算得到在8点(和9点、10点、11点和12点)下，系统告警事件1的告警数值与业务告警事件1的数量之间的比值，以及系统告警事件1的告警数值与业务告警事件2的数量之间的比值，见表2所示。

表2相同时间点下系统告警事件的告警数值与

各个业务告警事件的数量之间的比值

系统服务器在得到相同时间点下系统告警事件的告警数值与各个业务告警事件的数量之间的比值之后，可以针对8-12点中的每个时间段(以8-9点时间段为例)，对该时间段中后一个时间点(即9点)下系统告警事件1的告警数值与各种业务告警事件(即业务告警事件1和业务告警事件2)的数量之间的比值，以及对该时间段中前一个时间点(即8点)下系统告警事件1的告警数值与各种业务告警事件(即业务告警事件1和业务告警事件2)的数量之间的比值进行除法运算，将得到的结果作为前一个时间点和后一个时间点对应的子时间段(即8-9点时间段)下系统告警事件1的告警数值与各种业务告警事件的数量之间的波动比率。得到8-12点中的每个时间段(即8-9点、9-10点、10-11点和11-12点)下系统告警事件1的告警数值与各种业务告警事件的数量之间的波动比率之后，可以将8-12点中的每个时间段下系统告警事件1的告警数值与各种业务告警事件的数量之间的波动比率之和与8-12点包括的时间段数量(即4个时间段)之间的差值作为8-12点下系统告警事件1的告警数值与各种业务告警事件的数量之间的平均波动比率，进一步的，可以将8-12点下系统告警事件1的告警数值与各种业务告警事件的数量之间的平均波动比率作为系统告警事件1的告警数值与各种业务告警事件的数量之间的平均波动比率。

s103、针对前述各个系统告警事件，系统服务器将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件。

其中，平均波动比率位于预设波动比率范围内可以表明该系统告警事件与业务告警事件之间的关联程度越高，同理，平均波动比率不位于预设波动比率范围内可以，也就是说，可以认为该系统告警事件与业务告警事件之间不具有关联关系。平均波动比率位于预设波动比率范围内可以表明该系统告警事件的告警数值与业务告警事件的数量呈较为相同的变化规律，因此，可以认为，该系统告警事件的告警数值会影响该业务告警事件的数量，即表明该系统告警事件与业务告警事件之间具有关联关系。在一种实现方式中，预设波动比率范围可以是系统服务器自动设置的，也可以是用户自定义的，本申请实施例对此不作限定。例如，预设波动比率范围可以是[0.9，1.1]、[0.8，1.2]或者其他范围。

例如，若系统告警事件1的告警数值与业务告警事件1的数量之间的平均波动比率为0.95，系统告警事件1的告警数值与业务告警事件2的数量之间的平均波动比率为0.7，且预设波动比率范围为[0.9，1.1]，则可以确定系统告警事件1的与业务告警事件1之间具有关联关系，而系统告警事件1的与业务告警事件2之间不具有关联关系。

s104、针对前述各种业务告警事件，系统服务器将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

具体的，在确定系统告警事件和业务告警事件之间的关联关系之后，系统服务器可以获取系统告警事件的故障原因，并将该系统告警事件的故障原因作为与该系统告警事件具有关联关系的业务告警事件的故障原因，进一步的，根据业务告警事件的故障原因可以快速修复故障，进而消除该业务告警。由于业务告警事件一般是由系统告警事件导致的，因此系统告警事件的故障原因可以是对应的业务告警事件的故障原因。通过这种方式，可以快速定位故障原因，从而有利于提高故障处理效率。在一种实现方式中，系统服务器可以从本地存储器中获取系统告警事件的故障原因，也可以从云端获取系统告警事件的故障原因，本发明实施例对此不做限定。在一种实现方式中，系统告警事件的故障原因可以包括某硬件损坏或者某硬件运行发生故障。

通过实施本发明实施例，可以根据各个系统告警事件的告警数值以及各种业务告警事件的数量，得到各个系统告警事件的告警数值与各种业务告警事件的数量之间的平均波动比率，然后将平均波动比率位于预设波动比率范围内的业务告警事件确定为与系统告警事件具有关联关系的业务告警事件，进而将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因，即通过实施本发明实施例，可以快速定位故障原因，从而有利于提高故障处理效率。

请参阅图2，图2是本发明实施例提供的另一种故障处理方法的流程示意图。该方法应用于系统服务器，该系统服务器可以用于管理多个服务设备。具体的，如图2所示，本发明实施例的故障处理方法可以包括但不限于如下步骤：

s201、系统服务器获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量。

s202、系统服务器根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

s203、针对前述各个系统告警事件，系统服务器将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件。

s204、针对前述各种业务告警事件，系统服务器将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

需要说明的是，步骤s201～步骤s204的执行过程可以分别参见图1中步骤s101～步骤104中的具体描述，在此不赘述。

s205、系统服务器将与前述各个系统告警事件具有关联关系的业务告警事件的标识和该系统告警事件的标识关联存储于预设数据库，预设数据库中存储有第一系统告警事件的标识。

具体的，在确定系统告警事件和业务告警事件之间的关联关系之后，可以存储该关联关系，以便后续从预设数据库中查询某系统告警事件和某业务告警事件之间是否具有关联关系。由于业务告警事件一般是由系统告警事件导致的，因此在产生业务告警事件时，系统服务器可以在预设数据库中查询是否存在与产生的业务告警事件存在关联关系的系统告警事件，若存在，则可以通过消除该系统告警事件，进而达到消除该业务告警事件的目的。通过这种方式，可以根据系统告警事件与业务告警事件之间的关联关系快速定位故障原因，有利于提高故障处理效率。

在一种实现方式中，预设数据库可以是系统服务器中的物理数据库，也可以是云端数据库，本发明实施例对此不作限定。需要说明的是，步骤s204和步骤s205的执行顺序不分先后，可以先执行步骤s204，后执行步骤s205；也可以先执行步骤s205，后执行步骤s204；也可以同时执行步骤s204和s205。

在一种实现方式中，系统服务器还可以将各个业务告警事件的故障原因存储于预设数据库，通过这种方式，针对具有关联关系的系统告警事件和业务告警事件，可以仅在预设数据库中存储一份故障原因，这样可以有效节省存储资源。

在本发明实施例中，当预设数据库中存储有第一系统告警事件的标识时，表明至少存在一种业务告警事件与第一系统告警事件具有关联关系，也就是说，预设数据库中至少存储有一条记录，该记录为第一系统告警事件的标识相关联的业务告警事件的标识。

s206、在发生第一系统告警事件时，系统服务器从预设数据库中确定与第一系统告警事件的标识具有关联关系的第一业务告警事件的标识。

具体的，在发生第一系统告警事件时，系统服务器可以从预设数据库中查询与第一系统告警事件的标识具有关联关系的第一业务告警事件的标识。第一业务告警事件的标识对应的第一业务告警事件与第一系统告警事件具有关联关系。

s207、系统服务器根据第一系统告警事件的标识，获取第一系统告警事件的发生时间。

在本发明实施例中，系统服务器在获取第一系统告警事件的告警数值时，还可以获取第一系统告警事件的发生时间。

s208、系统服务器根据发生时间和预设时长，确定发生时间段，发生时间段的开始时间为该发生时间，发生时间段的时长为预设时长。

在本发明实施例中，确定了系统告警事件和业务告警事件之间的关联关系后，后期还可以验证关联关系的准确性。具体的，若查询预设数据库得到第一系统告警事件与第一业务告警事件存在关联关系，则表明第一系统告警事件可能会引发第一业务告警事件。但是第一系统告警事件不一定会立即引发第一业务告警事件，判断第一系统告警事件是否引发第一业务告警事件的方式可以为：若在发生时间段中发生第一业务告警事件，则表明第一系统告警事件会引发第一业务告警事件，即第一系统告警事件与第一业务告警事件之间的确具有关联关系。同理，若在发生时间段未发生第一业务告警事件，则表明第一系统告警事件不会引发第一业务告警事件，即第一系统告警事件与第一业务告警事件之间不具有关联关系。

其中，预设时长是指系统告警事件引发业务告警事件之间的延迟时长，即由发生该系统告警事件到发生业务告警事件之间的时长。在一种实现方式中，预设时长可以是系统服务器默认设置的，也可以是用户自定义的，本申请实施例对此不作限定。

s209、若在发生时间段中未发生第一业务告警事件的标识对应的第一业务告警事件，则系统服务器在预设数据库中删除第一系统告警事件的标识和第一业务告警事件的标识之间的关联关系。

具体的，若在发生时间段中未发生第一业务告警事件的标识对应的第一业务告警事件，则表明第一系统告警事件不会引发第一业务告警事件，即第一系统告警事件与第一业务告警事件之间不具有关联关系，此时，系统服务器可以在预设数据库中删除第一系统告警事件的标识和第一业务告警事件的标识之间的关联关系。

在一种实现方式中，系统服务器判断在发生时间段中是否发生第一业务告警事件的标识对应的第一业务告警事件的具体实施方式可以为：系统服务器获取发生时间段对应的日志信息，查询该日志信息据中是否存在第一业务告警事件的标识，若不存在，则表明在发生时间段中未发生第一业务告警事件；若存在，则表明在发生时间段中发生了第一业务告警事件。其中，发生时间段对应的日志信息记录了所有在发生时间段中新发生的业务告警事件的标识。

在本发明实施例中，系统服务器确定了系统告警事件和业务告警事件之间的关联关系后，后期还可以验证关联关系的准确性，具体的，在发生时间段中未发生第一业务告警事件时，系统服务器在预设数据库中删除第一系统告警事件的标识和第一业务告警事件的标识之间的关联关系，可以提高预设数据库中记录的关联关系的准确性。

请参阅图3，图3是本发明实施例提供的又一种故障处理方法的流程示意图。该方法应用于系统服务器，该系统服务器可以用于管理多个服务设备。具体的，如图3所示，本发明实施例的故障处理方法可以包括但不限于如下步骤：

s301、系统服务器获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量。

s302、系统服务器根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

s303、针对前述各个系统告警事件，系统服务器将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件。

s304、针对前述各种业务告警事件，系统服务器将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

s305、系统服务器将与前述各个系统告警事件具有关联关系的业务告警事件的标识和该系统告警事件的标识关联存储于预设数据库，预设数据库中存储有第二业务告警事件的标识，第二业务告警事件的故障原因包括第二业务告警事件对应的系统资源的使用发生异常。

需要说明的是，步骤s301～步骤s304的执行过程可以分别参见图1中步骤s101～步骤104中的具体描述，步骤s305的执行过程可以参见图2中步骤s205中的具体描述，在此不赘述。

在本发明实施例中，当预设数据库中存储有第二业务告警事件的标识时，表明至少存在一种系统告警事件与第二业务告警事件具有关联关系，也就是说，预设数据库中至少存储有一条记录，该记录为第二业务告警事件的标识相关联的系统告警事件的标识。在本发明实施例中，预设数据库中存储的各个业务告警事件(如第二业务告警事件)的告警原因可以包括该业务告警事件对应的系统资源的使用发生异常，业务告警事件对应的系统资源可以指与该业务告警事件具有关联关系的系统告警事件对应的系统资源，该系统资源的使用发生异常时，会导致产生系统告警事件，该系统告警事件会引发业务告警事件。例如，物理数据库发生异常时，会产生数据库告警事件(即系统告警事件)，数据库告警事件会引发无法显示数据的告警事件(即业务告警事件)。

s306、当第二业务告警事件的数量大于第一预设数量时，系统服务器获取第二业务告警事件对应的系统资源的使用情况信息，该使用情况信息包括系统资源的占用率和运行性能中的至少一种。

具体的，当第二业务告警事件的数量大于第一预设数量时，表明第二业务告警事件的告警程度较严重，此时，系统服务器可以根据第二业务告警事件的故障原因获取第二业务告警事件对应的系统资源的使用情况信息，进而根据使用情况信息以确定导致第二业务告警事件的故障，并修复故障，进而消除第二业务告警事件。在本申请实施例中，由于第二业务告警事件的故障原因和与第二业务告警事件具有关联关系的第二系统告警事件的故障原因相同，因此，消除第二业务告警事件的同时也能达到消除第二系统告警事件的目的。其中，第一预设数量可以是系统服务器默认设置的，也可以是用户自定义的，本发明实施例对此不作限定。使用情况信息可以包括但不限于系统资源的占用率、运行性能、cpu占用率、sql平均耗时、sql吞吐量、sql缓存命中率、内存使用率和网络带宽使用情况中的一种或多种。

s307、系统服务器将该使用情况信息发送给预设设备，以使预设设备输出该使用情况信息。

具体的，系统服务器获取第二业务告警事件对应的系统资源的使用情况信息之后，可以将该使用情况信息发送给预设设备，以使预设设备输出该使用情况信息。其中，预设设备可以是运维人员操作的设备，通过这种方式，运维人员可以通过观察使用情况信息，以定位导致第二业务告警事件的故障，相较于运维人员通过预设设备主动向系统服务器获取使用情况信息的方式，系统服务器将使用情况信息主动推送给预设设备，可以使得运维人员更及时的查看使用情况信息，有利于提高故障处理效率。其中，预设设备可以是终端设备，也可以是服务器。

在一种实现方式中，预设数据库中可以存储有第二业务告警事件的标识，当第二业务告警事件的数量大于第二预设数量时，系统服务器可以从预设数据库中确定与第二业务告警事件的标识具有关联关系的第二系统告警事件的标识；并获取第二系统告警事件的标识对应的解决方案信息；执行该解决方案信息包括的步骤。

其中，第二系统告警事件的标识对应的解决方案信息可以用于消除第二系统告警事件。具体的，通过执行该解决方案信息包括的步骤可以消除第二系统告警事件。第二系统告警事件的标识对应的解决方案信息可以是从云端获取的，也可以是系统服务器预先存储的，本发明实施例对此不作限定。在一种实现方式中，第二预设数量和第一预设数量可以相同，也可以不同。当第二预设数量和第一预设数量不同时，第二预设数量可以大于第一预设数量。当第二预设数量大于第一预设数量时，相较于第二业务告警事件的数量大于第一预设数量且小于第二预设数量时第二业务告警事件的告警严重程度，第二业务告警事件的数量大于第二预设数量时第二业务告警事件的告警严重程度较高，此时，系统服务器执行该解决方案信息包括的步骤，可以更及时地消除第二业务告警事件。

在一种实现方式中，系统服务器在执行解决方案信息包括的步骤之后，还可以获取第二系统告警事件的标识对应的检测程序；执行该检测程序，得到检测结果，检测结果用于指示第二系统告警事件的标识对应的第二系统告警事件是否消失；若检测结果指示第二系统告警事件未消失，则输出提醒信息。

在本发明实施例中，系统服务器在执行解决方案信息包括的步骤之后，还可以检测第二业务告警事件是否消除，若消除，则表明通过该解决方案信息成功消除第二业务告警事件；若未消除，则表明通过解决方案信息并未消除第二业务告警事件。通过解决方案信息并未消除第二业务告警事件的原因可能是通过解决方案信息不能消除第二业务告警事件，或者通过解决方案信息原本可以消除第二业务告警事件，但是由于其他原因(如执行解决方案信息包括的步骤过程中发生一些故障)导致本次通过解决方案信息并未消除第二业务告警事件。若通过解决方案信息并未消除第二业务告警事件，则系统服务器可以输出提醒信息，以提示用户重新执行解决方案信息包括的步骤(或者采用其他方法)以消除第二业务告警事件；同时，提醒信息还可以提示用户确定导致通过解决方案信息并未消除第二业务告警事件的原因，若原因是通过解决方案信息不能消除第二业务告警事件，则可以进一步获取可以消除第二业务告警事件的解决方案信息。

通过实施本发明实施例，当第二业务告警事件的数量大于第一预设数量时，系统服务器获取第二业务告警事件对应的系统资源的使用情况信息，并将该使用情况信息发送给预设设备，以使预设设备输出该使用情况信息。可以使得运维人员根据预设设备输出的使用情况信息定位导致第二业务告警事件的故障，有利于提高故障处理效率。

请参见图4，图4是本发明实施例提供的一种故障处理装置的结构示意图，具体的，如图4所示，该故障处理装置40，可以包括：

获取单元401，用于获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量，目标服务设备存在于系统服务器管理的服务设备中；

处理单元402，用于根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率；

确定单元403，用于针对前述各个系统告警事件，将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件；

处理单元402，还用于针对前述各种业务告警事件，将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

在一种实现方式中，处理单元402用于根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率时，具体可以用于：在目标时间段中确定多个时间点，确定的多个时间点中相邻的两个时间点对应一个子时间段；获取在目标时间段中的相同时间点下，前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值；针对目标时间段中相邻的两个时间点，对后一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值，以及前一个时间点下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的比值进行除法运算，将得到的结果作为前一个时间点和后一个时间点对应的子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率；根据目标时间段中所有子时间段下前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的波动比率，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率。

在一种实现方式中，故障处理装置40还可以包括存储单元404，存储单元404，用于将与前述各个系统告警事件具有关联关系的业务告警事件的标识和该系统告警事件的标识关联存储于预设数据库。

在一种实现方式中，预设数据库中可以存储有第一系统告警事件的标识，确定单元403还可以用于：在发生第一系统告警事件时，从预设数据库中确定与第一系统告警事件的标识具有关联关系的第一业务告警事件的标识；获取单元401还可以用于：根据第一系统告警事件的标识，获取第一系统告警事件的发生时间；确定单元403还可以用于：根据发生时间和预设时长，确定发生时间段，发生时间段的开始时间为该发生时间，发生时间段的时长为预设时长；故障处理装置40还可以包括删除单元405，删除单元405可用于若在发生时间段中未发生第一业务告警事件的标识对应的第一业务告警事件，则在预设数据库中删除第一系统告警事件的标识和第一业务告警事件的标识之间的关联关系。

在一种实现方式中，预设数据库中可以存储有第二业务告警事件的标识，第二业务告警事件的故障原因可以包括第二业务告警事件对应的系统资源的使用发生异常，获取单元401还可以用于：当第二业务告警事件的数量大于第一预设数量时，获取第二业务告警事件对应的系统资源的使用情况信息，该使用情况信息包括系统资源的占用率和运行性能中的至少一种；故障处理装置40还可以包括发送单元406，发送单元406可以用于将该使用情况信息发送给预设设备，以使预设设备输出该使用情况信息。

在一种实现方式中，预设数据库中可以存储有第二业务告警事件的标识，确定单元403还可以用于：当第二业务告警事件的数量大于第二预设数量时，从预设数据库中确定与第二业务告警事件的标识具有关联关系的第二系统告警事件的标识；获取单元401还可以用于：获取第二系统告警事件的标识对应的解决方案信息；处理单元402还可以用于：执行解决方案信息包括的步骤。

在一种实现方式中，获取单元401还可以用于：获取第二系统告警事件的标识对应的检测程序；处理单元402还可以用于：执行检测程序，得到检测结果，检测结果用于指示第二系统告警事件的标识对应的第二系统告警事件是否消失；故障处理装置40还可以包括输出单元407，输出单元407可以用于若检测结果指示第二系统告警事件未消失，则输出提醒信息。

本发明实施例和图1-图3所示方法实施例基于同一构思，其带来的技术效果也相同，具体原理请参照图1-图3所示实施例的描述，在此不赘述。

请参阅图5，图5是本发明实施例提供的一种系统服务器的结构示意图。该系统服务器50可以包括存储器501、处理器502和网络接口503，存储器501、处理器502和网络接口503通过一条或多条通信总线连接。其中，网络接口503受处理器502的控制用于收发消息。

存储器501可以包括只读存储器和随机存取存储器，并向处理器502提供指令和数据。存储器501的一部分还可以包括非易失性随机存取存储器。

处理器502可以是中央处理单元(centralprocessingunit，cpu)，该处理器502还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器，可选的，该处理器502也可以是任何常规的处理器等。其中：

存储器501，用于存储程序指令。

处理器502，用于调用存储器501中存储的程序指令，以用于：

获取目标服务设备在目标时间段内发生的各个系统告警事件的告警数值，并获取系统服务器在目标时间段内接收到的各种业务告警事件的数量，目标服务设备存在于系统服务器管理的服务设备中；

根据前述各个系统告警事件的告警数值以及前述各种业务告警事件的数量，得到前述各个系统告警事件的告警数值与前述各种业务告警事件的数量之间的平均波动比率；

针对前述各个系统告警事件，将平均波动比率位于预设波动比率范围内的业务告警事件确定为与该系统告警事件具有关联关系的业务告警事件；

针对前述各种业务告警事件，将与业务告警事件具有关联关系的系统告警事件的故障原因作为该业务告警事件的故障原因。

需要说明的是，图5对应的实施例中未提及的内容以及各个步骤的具体实现方式可参见图1-图3所示实施例以及前述内容，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序包括程序指令，程序指令被处理器执行时，使处理器执行如图1-图3所示方法实施例中所执行的步骤。

以上所揭露的仅为本发明的部分实施例而已，当然不能以此来限定本发明之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本发明权利要求所作的等同变化，仍属于发明所涵盖的范围。