系统故障信息的通知方法、装置、存储介质及计算机设备与流程

本申请涉及通信技术领域，具体而言，本申请涉及一种系统故障信息的通知方法、装置、存储介质及计算机设备。

背景技术：

网络系统实现了对各种电信设备的集中管理，而告警管理是网管系统提供给用户的一个重要功能，允许用户通过告警管理接收电信设备告警、查看告警原因、处理设备故障和统计网络告警信息等，发现和预测网络故障和保证在网络出现故障的时候能够及时恢复网络的正常运行，减少电信设备故障带来的损失。网管系统收到电信设备告警的时候尽可能及时通知相关设备维护人员也是告警管理的重要功能。

现有技术中，当前的网管系统在接收到告警之后把告警信息通过短消息或邮件通知给设备维护人员。但有时设备维护人员或责任人员由于未处于工作岗位或携带通讯设备，导致所述告警信息无法及时送达至责任人员，不能进行告警信息的有效送达，进而延误维修时机，导致巨大的经济损失。

技术实现要素：

本申请提供了一种系统故障信息的通知方法、系统故障信息的通知装置、计算机可读存储介质及计算机设备，以提高系统故障信息送达告警用户的效率。

本申请实施例首先提供了一种系统故障信息的通知方法，包括：

对告警用户的社交圈信息进行智能学习，获取所述告警用户的通知分析模型；

当接收到系统故障信息时，根据当前时间信息、用户地理位置信息及所述通知分析模型获取系统故障信息的最佳通知方式和最佳通知路径；

通过所述最佳通知方式和最佳通知路径将所述系统故障信息发送至所述告警用户。

在一种实施例中，所述根据告警用户的社交圈信息进行智能学习的步骤之前，还包括：

收集所述告警用户的社交圈信息，所述社交圈信息包括：告警用户的通讯录、通话记录、即时消息记录、相关日志信息、告警人员历史通知行为及对应的时间信息。

在一种实施例中，若告警用户存在历史通知行为数据，所述获取所述告警用户的通知分析模型的步骤之后，还包括：

调取所述告警用户的历史通知行为数据优化所述通知分析模型。

在一种实施例中，所述根据告警用户的社交圈信息进行智能学习，获取所述告警用户的通知分析模型的步骤，包括：

根据时间信息及告警用户当前的地理位置信息确定告警用户当前的用户状态；

获取告警用户在各种用户状态下的紧急联系人，将其作为该种用户状态下的最佳通知路径；

统计各种用户状态下，所述社交圈信息中告警用户的行为数据，获取告警用户在该用户状态下使用频次最高的联系方式，并将其作为最佳通知方式；

建立用户状态、最佳通知方式及最佳通知路径的关联关系，获得告警用户的通知分析模型。

在一种实施例中，所述获取告警用户在各种用户状态下的紧急联系人的步骤，包括：

学习告警用户的社交圈信息，获得与告警用户联系频率最高的联系人，将该联系人设为该种用户状态下的紧急联系人。

在一种实施例中，所述获取告警用户在该用户状态下使用频次最高的联系方式，并将其作为最佳通知方式的步骤，包括：

获取各种用户状态下告警用户与其紧急联系人之间的社交信息，获取该用户状态下使用频次最高的联系方式，将其作为最佳通知方式。

进一步地，本申请实施例还提供了一种系统故障信息的通知方法，包括：

接收到表征系统出现故障的系统故障信息，将所述系统故障信息发送至预先建立关联的告警用户；

预设时间段内未接收到所述告警用户的响应信息，根据上述任一项技术方案所述的系统故障信息的通知方法将系统故障信息发送至告警用户。

进一步地，本申请实施例还提供了一种系统故障信息的通知装置，包括：

学习模块，用于对告警用户的社交圈信息进行智能学习，获取所述告警用户的通知分析模型；

获取模块，用于当接收到系统故障信息时，根据当前时间信息、用户地理位置信息及所述通知分析模型获取系统故障信息的最佳通知方式和最佳通知路径；

发送模块，用于通过所述最佳通知方式和最佳通知路径将所述系统故障信息发送至所述告警用户。

进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机可以执行上述任一项技术方案所述的系统故障信息的通知方法的步骤。

更进一步地，本申请实施例还提供了一种计算机设备，所述计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任意一技术方案所述的系统故障信息的通知方法的步骤。

与现有技术相比，本申请提供的方案至少具备如下优点：

本申请实施例提供的系统故障信息的通知方法，通过对告警用户的社交圈进行智能学习，获得不同时间段及用户地理位置信息对应的系统故障信息的最佳通知方式和通知路径，通过最佳通知方式和最佳通知路径将系统故障信息发送至告警用户，提高告警用户获知系统故障信息的效率，避免由于系统故障信息无法迅速有效地传达至告警人员引起的损失。

本申请实施例提供的系统故障信息的通知方法，通过通知分析模型获得将系统故障信息送达告警用户的最佳通知方式和最佳通知路径，通过数据分析能达到快速找到告警人员处理系统故障问题，同时避免重复多次将系统告警信息发送至告警人员，造成对告警人员的打扰和资源的浪费。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请一个实施例提供的系统故障信息的通知方法的实施环境图；

图2为本申请一个实施例提供的系统故障信息的通知方法的流程示意图；

图3为本申请一个实施例提供的获取所述告警用户的通知分析模型的流程示意图；

图4为本申请另一个实施例提供的获取最佳通知途径及最佳通知方式的流程示意图；

图5为本申请另一个实施例提供的系统故障信息的通知方法的流程示意图；

图6为本申请一种实施例提供的系统故障信息的通知装置的结构示意图；

图7为本申请一种实施例提供的计算机设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

可以理解，本申请所使用的术语“第一”、“第二”等可在本文中用于描述各种元件，但这些元件不受这些术语限制。这些术语仅用于将第一个元件与另一个元件区分。举例来说，在不脱离本申请的范围的情况下，可以将第一直播视频图像称为第二直播视频图像，且类似地，可将第二直播视频图像称为第一直播视频图像。第一直播视频图像和第二直播视频图像两者都是直播视频图像，但其不是同一个直播视频图像。

本领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非被特定定义，否则不会用理想化或过于正式的含义来解释。

图1为一个实施例中提供的系统故障信息的通知方法的实施环境图，在该实施环境中，包括用户终端、服务器端。

本实施例中服务器端可以为通过对告警用户的社交圈进行智能学习，获取所述告警用户的通知分析模型，所述通知分析模型用于识别不同时间及用户地理位置信息对应的最佳通知方式和最佳通知路径，当接收到系统故障信息时，根据当前时间信息及所述通知分析模型获取系统故障信息当前的最佳通知方式和最佳通知路径；通过所述当前的最佳通知方式和最佳通知路径将所述系统故障信息发送至所述用户终端。

需要说明的是，用户终端可为智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此。服务器端可为计算机设备。服务器端与用户终端可以通过蓝牙、usb(universalserialbus，通用串行总线)或者其他通讯连接方式进行网络连接，本申请在此不做限制。

在一个实施例中，图2为本申请实施例提供的系统故障信息的通知方法的流程示意图，该系统故障信息的通知方法可以应用于上述的计算机设备中，包括如下步骤：

步骤s210，对告警用户的社交圈信息进行智能学习，获取所述告警用户的通知分析模型；

步骤s220，当接收到系统故障信息时，根据当前时间信息、用户地理位置信息及所述通知分析模型获取系统故障信息的最佳通知方式和最佳通知路径；

步骤s230，通过所述当前的最佳通知方式和最佳通知路径将所述系统故障信息发送至所述告警用户。

其中，告警用户是系统故障信息的相关责任人员，在系统出现故障时，需要告警人员及时获知系统故障信息，以便尽快对系统故障进行维修。本申请实施例所述的系统可以是软件系统、硬件设备系统等，其中，系统故障信息，可以是系统中某一局部程序或局部设备出现异常。

本申请实施例中提供的系统故障信息的通知方法，通过对告警用户的社交圈进行智能学习，获得各个时间段、用户地理位置信息对应的系统故障信息的最佳通知方式和通知路径，通过最佳通知方式和最佳通知路径将系统故障信息发送至告警用户，提高告警用户获知系统故障信息的效率，避免由于系统故障信息无法迅速有效地传达至告警人员引起的不利影响。

本申请实施例，通过通知分析模型获得将系统故障信息送达告警用户的最佳通知方式和最佳通知路径，通过数据分析能达到快速找到告警人员处理系统故障问题，同时避免重复多次将系统告警信息发送至告警人员，造成对告警人员的打扰和资源的浪费。

为了更清楚本申请提供的系统故障信息的通知方案及其技术效果，接下来以多个实施例对其具体方案进行详细阐述。

在一种实施例中，在步骤s210的根据告警用户的社交圈信息进行智能学习的步骤之前，包括：获取所述告警用户的社交圈信息，所述社交圈信息包括：告警用户的通讯录、通话记录、即时消息记录及相关日志信息。所述相关日志信息包括日志发布和推送平台上与告警用户相关的日志信息，如朋友圈信息、空间信息、微博信息、博客信息及其他社交平台上的共享信息等。

根据所述社交圈信息获得告警用户的个人信息，告警信息的家庭圈信息、朋友信息、告警人员的通知方式喜好等信息，以便基于获得的告警用户信息进行最佳通知方式及最佳通知路径的获取。

步骤s210中告警用户的通知分析模型可以通过如下方式获得：调取告警用户的社交圈信息进行智能学习，通过深度学习，如神经网络等学习方法提取各社交圈中特征参数，获得通知分析模型中各特征参数的权重系数，其中，特征参数如时间信息，地理位置信息、用户状态信息、联系人信息等等，获得告警用户在特征参数下的最佳通知方式和最佳通知路径。获得的通知分析模型能够接收输入的告警用户的社交圈信息，输出不同特征参数对应的最佳通知方式及最佳通知路径信息，如不同时间信息对应的最佳通知方式和通知路径，不同地理位置信息对应的最佳通知方式和通知路径，不同用户状态对应的最佳通知方式和通知路径等。

本申请实施例利用告警用户的社交圈信息进行模型训练，获得告警用户的通知分析模型，以便后续接收到任一告警用户的社交圈信息之后迅速获得该系统故障信息在各时间段对应的最佳通知方式和最佳通知路径，提高告警用户获知系统故障信息的效率。

进一步地，步骤s210中获取所述告警用户的通知分析模型之后，还包括：调取告警用户的历史通知行为数据及优化所述通知分析模型。

具体地，首先根据告警用户的社交圈信息进行智能学习，获取通知分析模型，若告警用户存在历史通知行为，即该告警用户之前接收过系统故障消息的通知，则调取该历史通知行为信息，利用告警用户的历史通知行为信息进行通知分析模型的修正，获得优化后的通知分析模型。

本申请实施例通过历史通知行为数据进行通知分析模型的优化，有利于完善通知分析模型，获得的最佳通知方式及通知路径更为精准，有利于提高获得最佳通知方式及通知路径的准确度及效率。

在一种实施例中，可以通过如下方式获取告警用户的通知分析模型，其流程示意图如图3所示，包括如下步骤：

s2101，根据时间信息及告警用户当前的地理位置信息确定告警用户当前的用户状态；

s2102，获取告警用户在各种用户状态下的紧急联系人，将其作为该种用户状态下的最佳通知路径；

s2103，统计各种用户状态下，所述社交圈信息中告警用户的行为数据，获取告警用户在该种用户状态下使用频次最高的联系方式，并将其作为最佳通知方式；

s2104，建立用户状态、最佳通知方式及最佳通知路径的关联关系，获得告警用户的通知分析模型。

步骤s2101中根据时间信息及告警用户当前的地理位置信息确定告警用户当前的用户状态，可以通过如下示例的方式进行确定：当前时间为2018年12月28日上午10点钟，根据告警用户的工作时间段判断当前时间为告警用户的工作时间，获取告警用户当前的地理位置信息，若告警用户当前位置处于预设的公司位置范围内，则表明告警用户当前的用户状态为工作状态。再如：当前时间为2018年12月30日上午11点，根据告警用户的工作时间段判断当前时间为告警用户的休息时间，获取告警用户当前的地理位置信息，若告警用户位于居住地区域范围，告警用户处于休息状态。

告警用户的最佳通知方式及最佳通知途径与用户状态息息相关，如告警用户处于工作状态，则通过其同事进行系统故障信息有效传达的成功概率大大提高，且成本小。若告警用户处于休息状态，则通过其家人进行系统故障信息传达的成功率会大于同事，因此首先通过步骤s2101提供的方案进行用户状态的判断非常有必要。

接下来的实施例用于阐述获得不同用户状态下的最佳通知方式及最佳通知路径。

一种实施例中，调取各种用户状态下，告警用户的社交圈信息中用户与外界沟通的行为数据，统计其中使用频次最高的联系方式，所述联系方式如：电话、即时信息、短信、邮件等，将使用频次最高的联系方式作为该种用户状态下的最佳通知方式。对该方案的示例如下：告警用户当前处于工作状态，统计该种用户状态下，所有联系方式的使用频次，如工作状态下，告警用户电话的使用次数为3次，即时信息的使用次数为8次，邮件的使用次数为7次，则该告警用户在工作状态下的最佳通知方式为即时信息。进一步地，若一种用户状态的时间很长，还可以统计各联系方式的使用时段，如工作时段内的前两个小时，用户使用频次最高的联系方式为即时信息，接下来的两个小时中，用户使用频次最高的联系方式为邮件，则进一步可以根据时间信息确定该种用户状态对应的最佳通知方式。

步骤s2102中获取告警用户在各种用户状态下的紧急联系人，将其作为该种用户状态下的最佳通知路径，步骤s2102与步骤s2103之间没有明显的先后顺序，分别获得告警用户的最佳通知路径及最佳通知方式即可。

一种实施例中，步骤s2102中获取告警用户在各种用户状态下的紧急联系人的步骤，包括：

s21021，学习告警用户的社交圈信息获得与告警用户联系最为密切的联系人，将其作为紧急联系人，设定该紧急联系人为最佳通知途径。

具体地，调取并学习告警用户的社交圈信息，统计每种用户状态下与告警信息联系最为密切的联系人，即联系最为频繁的联系人，将该联系人设置为紧急联系人。学习告警用户的通讯录、即时沟通软件信息等信息获得告警用户的个人信息及社会关系，如获知告警用户是否已婚，若已婚，获得其配偶的联系方式，以便后续将其配偶作为紧急联系人时，快速联系到该紧急联系人。

根据学习告警用户的社交圈信息获得与告警用户联系最为密切的用户，将其作为紧急联系人，如告警用户当前处于工作状态，则通过社交圈获得与其联系最为密切的同事，将其作为紧急联系人，将该紧急联系人设为最佳通知路径，根据获得的最佳通知路径进行系统故障信息的传达。再如检测到告警用户当前处于在家休息状态，通过个人信息获得其居家状态下的紧急联系人，可以为其家人或朋友，将该紧急联系人设为最佳通知路径。

当然，各种用户状态下的紧急联系人也可以通过告警用户自定义，该种通过用户自定义紧急联系人的方式不依赖智能学习过程，无需调用学习大量社交圈信息，降低获得紧急联系人的时间成本。

另一实施例中，获得各种用户状态下对应的紧急联系人，并将该紧急联系人作为最佳通知路径之后，更进一步，步骤s2103中获取告警用户在该用户状态下使用频次最高的联系方式，并将其作为最佳通知方式的步骤通过如下方式实现：s21031，获得与告警用户与该紧急联系人之间最常用的联系方式，将该联系方式作为该紧急联系人的最佳通知方式。

基于上述实施例，本申请还提供了一种获取最佳通知途径及最佳通知方式的方案，其流程示意图如图4所示，包括如下步骤：s21021，学习告警用户的社交圈信息获得与告警用户联系最为密切的联系人，将其作为紧急联系人，设定该紧急联系人为最佳通知途径；s21031，获得与告警用户与该紧急联系人之间最常用的联系方式，将该联系方式作为该紧急联系人的最佳通知方式。

该种确定最佳通知方式及通知路径方案可以适用于任一种用户状态下最佳通知方式及通知路径方案的获取。该种确定最佳通知方式的方案，首先确定紧急联系人，基于确定后的紧急联系人对应获得与该紧急联系人的最佳通知方式，获取到的通知方式更加具有针对性，有利于提高系统故障信息的传达效率。

进一步地，本申请实施例还提供了一种系统故障信息的通知方法，其流程示意图如图5所示，包括如下步骤：

s510，接收到表征系统出现故障的系统故障信息，将所述系统故障信息发送至预先建立关联的告警用户；

s520，预设时间段内未接收到所述告警用户的响应信息，根据上述任一技术方案所述的系统故障信息的通知方法将系统故障信息发送至告警用户。

当检测到系统出现故障时，或接收到表征系统出现故障的系统故障信息时，查找该系统或故障点的局部设备、局部程序的相关责任人员，其中，相关责任人员已预先与系统建立关联关系，并将表征系统出现故障的系统故障信息发送至该相关责任人员处，即将系统故障信息发送至告警人员。

若系统将系统故障信息发送至告警用户，但预设时间内并未接收到针对该系统故障信息的响应信息，则通过本申请上述实施例提供的系统故障信息的通知方案进行系统故障信息的通知，若预设时间内接收到针对该系统故障信息的响应信息，如收到告警用户发回的表示正在处理或处理措施的反馈信息，或者检测到故障点已恢复正常或者故障点处于维修状态，则表明该系统故障信息已成功送达告警用户端。

本申请实施例提供的系统故障信息的通知方法，在接收到系统故障信息时，首先将其直接发送至告警用户端，在预设时间段内未接收到响应信息时，再将系统故障信息通过其他的通知方式和通知路径，将系统故障信息发送至告警用户。该种方案能够快速将系统故障信息告知告警人员，以便及时处理系统故障问题，同时也减少对非告警人员的打扰。

以上为本申请提供的系统故障信息的通知方法实施例，针对于该方法，下面阐述与其对应的系统故障信息的通知装置的实施例。

本申请实施例还提供了一种系统故障信息的通知装置，其结构示意图如图6所示，包括学习模块610、获取模块620、发送模块630，具体如下：

学习模块610，用于根据告警用户的社交圈信息进行智能学习，获取所述告警用户的通知分析模型；

获取模块620，用于当接收到系统故障信息时，根据当前时间信息、用户地理位置信息及所述通知分析模型获取系统故障信息的最佳通知方式和最佳通知路径；

发送模块630，用于通过所述当前的所述最佳通知方式和最佳通知路径将所述系统故障信息发送至所述告警用户。

关于上述实施例中的系统故障信息的通知装置，其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

进一步地，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时实现上述任意一项所述的系统故障信息的通知方法。其中，所述存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。可以是只读存储器，磁盘或光盘等。

更进一步地，本申请实施例还提供一种计算机设备，所述计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任意一项所述的系统故障信息的通知方法。

图7是根据一示例性实施例示出的一种用于计算机设备700的框图。例如，计算机设备700可以被提供为一服务器。参照图7，计算机设备700包括处理组件722，其进一步包括一个或多个处理器，以及由存储器732所代表的存储器资源，用于存储可由处理组件722的执行的指令，例如应用程序。存储器732中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件722被配置为执行指令，以执行上述系统故障信息的通知方法的步骤。

计算机设备700还可以包括一个电源组件726被配置为执行计算机设备700的电源管理，一个有线或无线网络接口750被配置为将计算机设备700连接到网络，和一个输入输出(i/o)接口758。计算机设备700可以操作基于存储在存储器732的操作系统，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm或类似。应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解的是，在本申请各实施例中的各功能单元可集成在一个处理模块中，也可以各个单元单独物理存在，也可以两个或两个以上单元集成于一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。