CN110096406A - 一种故障事件发现方法和服务器 - Google Patents

Abstract

本申请提供了一种故障事件发现方法和服务器，其中，该方法包括：获取目标舆情数据；确定所述目标舆情数据所提及的故障事件；确定所述故障事件所匹配的类型，并将所述目标舆情数据关联于所述类型；对所述类型所关联的舆情数据的数量进行累计；在所述数量超出预设阈值的情况下，对所述类型进行故障提示。利用本申请实施例提供的技术方案，可以解决现有的故障事件发现方式无法有效对短时间内小范围的故障事件进行报警的技术问题，达到了对短时间内小范围的故障事件进行有效的发现和提示的技术效果。

Description

一种故障事件发现方法和服务器

技术领域

本申请属于互联网技术领域，尤其涉及一种故障事件发现方法和服务器。

背景技术

随着互联网技术的不断发展，软件承载的功能越来越多，软件也越来越复杂，这样也就导致软件本身的功能模块越来越多，可能出现的问题也变得越来越多。

为了使得可以及时发现软件所存在的问题，引入了基于用户对软件问题的反馈(也可以称之为舆情)实时发现软件所存在的故障和问题。

现有的基于舆情来确定软件故障事件的方式，一般是采用实时聚类分析的方式，来发现软件故障事件，并及时进行处理。例如，可以采用时间窗口的概念，对每个时间周期内的用户反馈的信息进行聚类分析，将反馈数量超出预定阈值的故障事件作为识别出的故障事件，以实现基于舆情的故障事件发现。例如：统计0到15分钟内的舆情信息，确定是否存在故障事件，然后统计1到16分钟内的舆情信息，确定是否存在故障事件，再统计2到17分钟内的舆情信息，确定是否存在故障事件。依次类推，以便实时发现***故障事件。

然而，上述这种方式仅能发现短时间内大范围的故障事件，无法有效识别出小范围内的故障事件(即，出现次数比较少的故障事件)。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请目的在于提供一种故障事件发现方法和服务器，可以实现对小范围应用故障事件的及时发现和报警。

本申请提供一种故障事件发现方法和服务器是这样实现的：

一种故障事件发现方法，所述方法包括：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型，并将所述目标舆情数据关联于所述类型；

对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

一种故障事件发现方法，所述方法包括：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型以及所述目标舆情数据的标定特征；

在所述舆情数据的标定特征符合预设的标定特征的情况下，对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型，并将所述目标舆情数据关联于所述类型；

对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

一种服务器，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型以及所述目标舆情数据的标定特征；

在所述舆情数据的标定特征符合预设的标定特征的情况下，对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述方法的步骤。

本申请提供的故障发现方法和服务器，对于聚类分析中舆情数量未超出预设数量的舆情数据，用于更新舆情数据数量，使得在一个故障事件发现周期中未达到报警条件的故障事件，可以在多个故障事件发现周期进行舆情数据的数量累加，从而可以发现小范围内的故障事件，避免了小范围的故障事件一直无法被发现和报警。通过上述方式解决了现有的故障事件发现方式无法有效对短时间内小范围的故障事件进行报警的技术问题，达到了对短时间内小范围的故障事件进行有效的发现和报警的技术效果。

附图说明

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

图1是本申请提供的故障事件发现***的架构示意图；

图2是本申请提供的故障事件发现数据转移流程示意图；

图3是本申请提供的故障事件发现一种实施例的流程示意图；

图4是本申请提供的一种具体场景的舆情数据示意图；

图5是本申请提供的另一种具体场景的舆情数据示意图；

图6是本申请提供的又一种具体场景的舆情数据示意图；

图7是本申请提供的故障事件发现服务器一种实施例的结构框图；

图8是本申请提供的故障事件发现装置的一种实施例的模块结构示意图；

图9是本申请提供的故障事件发现装置的另一种实施例的模块结构示意图；

图10是本申请提供的故障事件发现装置的又一种实施例的模块结构示意图。

具体实施方式

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

考虑到现有基于舆情发现故障事件的过程中，之所以会存在一些小范围内的故障事件无法被发现，是因为设置了一个阈值，如果在一个时间窗口周期内，某个故障事件的用户反馈数量低于预定的阈值，则这个故障事件不会被识别出来。例如，设置的数量阈值为15，时间窗口为30分钟。在0到30分钟内，故障事件X被反馈的次数为5，那么该故障事件X不会被识别出来，在1到31分钟，故障事件X被反馈的次数为6，那么该故障事件X也不会被识别出来……在10到40分钟，故障事件X被反馈的次数为13，因为小于15，那么该故障事件也不会被识别出来。由此可见，因现有的故障事件发现是以单个统计聚类分析周期内的次数作为故障事件识别依据的，这样就使得该故障事件在每个统计周期都是存在的，但因为不是集中被反馈或者不是集中故障事件的，而导致该故障事件一直无法被识别出来。

为此，考虑到如果将聚类分析得到的不符合确定故障事件条件的事件的次数进行一个记录，可以是记录在一个数据列表中，或者是记录在数据集合或者是一个索引表等等都可以。然后在下一个统计或者聚类周期中，如果发现该事件，则对该事件的出现次数进行更新，直至该事件满足故障事件确定的条件，生成对该故障事件的提示操作。

在本例中，提供了一种故障事件发现***，如图1所示，可以包括：多个客户端101、故障反馈平台102、故障发现服务器103、故障处理服务器104。

在一个实施方式中，其中，客户端101可以是客户操作使用的终端设备或者软件。具体的，客户端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能手表或者其它可穿戴设备等终端设备。当然，客户端也可以是能运行于上述终端设备中的软件。例如：手机淘宝、支付宝或者浏览器等应用软件。

用户在使用客户端上某个应用的时候，可能会发现该应用存在一些故障事件。例如，通过电商平台的拍照识别搜索功能，拍的照片一直无法上传以供识别。这时，用户可以在对该应用的问题反馈通道进行问题反馈，例如，用户可以输入：“拍照识别功能一直无法上传图片”，或者是采用截图拍照等方式反馈问题等等。对于用户的问题反馈，即可以作为舆情数据。对于用户输入的文字形式的舆情数据，可以是通过文字输入的方式，也可以是通过语音输入的方式，或者是用户从预先设置的可选项中选择故障事件等等。

上述的反馈通道可以是应用内自带的问题反馈功能，也可以是预先提供的一个问题反馈平台，用户可以通过该平台对应用中的故障事件进行人工反馈。在反馈的时候，可以是在平台上提交的一条回复信息、也可以是邮件反馈、或者是向预留的手机号发送短信消息的方式，对于用户如何上传舆情数据，本申请不作限定，可以根据实际需要选择。

在一个实施方式中，上述故障反馈平台102、故障发现服务器103和故障处理服务器104都是通过一个服务器实现，也可以通过不同的服务器实现，也可以是通过云服务器或者是服务器集群的方式实现，具体采用哪种方式实现可以根据实际需要选择。

上述故障反馈平台102可以用于集中用户的舆情数据(即用户反馈或上报的故障信息)，可以是一个应用对应一个故障反馈平台102，也可以是多个应用的舆情数据都集中在一个故障平台102上。故障反馈平台与多个客户端相连，用于集中来自各个客户端上报的故障事件信息。

故障发现服务器103与故障反馈平台102进行通信，用于从故障反馈平台获取舆情数据。在一个实施方式中，故障发现服务器103可以每隔预定时间从故障反馈平台102获取一定时间间隔内的舆情数据，也可以是故障反馈平台102一旦收到舆情数据就传送给故障发现服务器103。具体采用哪种方式，可以根据实际需要选择。

故障发现服务器103在获取到舆情数据之后，可以对数据进行聚类分析。例如，故障发现服务器103可以实时以当前时间至15分钟前的这个时间段内收到的舆情数据进行聚类分析，确定出用户反馈的故障事件数据中，存在哪些故障事件，以及各个故障事件被反馈的次数，如果某个故障事件在这15分钟内的反馈次数超出预设阈值，则可以对该故障事件进行提示，其中，该提示操作可是预警操作，也可以是显示以提醒的操作，具体的提示方式，本申请不作具体限定。

在本例中，对于聚类分析出的反馈次数未超出预设阈值的故障事件，不是直接丢弃，而是对这些故障事件的故障事件类型以及反馈次数进行记录。后续有新的故障事件数据过来的时候，会基于新的故障事件数据，对该故障事件的反馈次数进行更新，并确认更新后的反馈次数是否符合预设阈值，如果达到预设阈值，则进行提示。

在一个实施方式中，故障发现服务器103可以是采用预先建立统计表的方式，在对舆情数据进行具备分析的时候，将分析出的所有故障事件类型及故障事件类型的反馈次数都更新到该统计表中，然后基于该统计表中记录的反馈次数，确定各个故障事件是否需要报警。对于进行了故障事件报警的故障事件，将该故障事件从统计表中删除，或者将该故障事件的反馈次数标记为0。且可以为故障事件设置一定的故障事件修复期，例如：1个小时，那么在从进行故障事件报警的一个小时内，所有该故障事件的舆情数据都不进行统计。这样通过对故障事件统计表的维护，即可实现对大范围小范围故障事件的发现，不会遗漏故障事件。在进行统计的时候，可以是采用相似性比对的方式，确定每个舆情数据所反馈的故障事件是哪个故障事件，如果舆情数据与某个故障事件的相似度超出预设相似度阈值，则为该故障事件的反馈次数加1。如果舆情数据与统计表中的每个故障事件都不相似，则可以认为是一个新的故障事件，可以将该故障事件新增进统计表中。在实现的时候，统计表最初可以是一张空表，也可以是已经预先设置一些故障事件类型的统计表，例如，可以将常见的故障事件先预置在统计表中，在得到舆情数据之后，到统计表中进行相似度匹配以及反馈次数更新即可。

然而值得注意的是，上述是以统计表(即，列表)为例进行的说明，这仅是一种示例性描述，在实际实现的时候，还可以采用其它的实现方式进行数据的统计和例句，例如，可以是数据库、舆情类型池等等都可以，具体的实现方式，本申请对此不作限定。

在另一个实施方式中，可以采用聚类分析的方式，即，每个故障事件发现周期都进行一次聚类分析。具体的，可以按照如图2所示的方式进行故障事件发现：

S201：获取用户反馈的舆情数据，其中，该舆情数据可以是用户通过例如手机上的应用或者电脑上的应用等提交到的用户反馈信息，可以是文字形式、语音形式的、图片形式的。

S202：基于相似性聚类算法(例如：kmediods的文本聚类算法)，对上述舆情数据分时间段进行实时聚类分析(例如当前时间至一小时这个时间段内的舆情数据)。

S203：通过聚类分析，使得按照文本具备相关性或相似性将舆情数据聚集到了不同的聚类集合中。

S204：对得到的多个聚类集合进行报警阈值判断，其中，该报警阈值可以是根据历史数据或者对历史数据的聚类分析得到的。

S205：对于超出报警阈值的聚类集合，将该聚类集合对应的故障事件类型进行报警。

S206：通过步骤202中的聚类算法，有一部分舆情数据在步骤203中已经被聚集到若干相似的聚类集合中，有一些舆情数据可能不属于任何一个聚类集合。

S207：对于步骤203中被聚类到一个聚类集合中的舆情数据，如果在进行报警阈值判断后，发现没有达到报警条件(即，未超出报警阈值)，那么对这些聚类集合不进行报警。

S209：将步骤S206和步骤S207中所得到的两部分舆情数据进行汇总，并与舆情模板中的舆情进行相似度对比。其中，舆情模板可以是需要定期维护的一份舆情列表，列表中记录有两个属性：舆情文本和与该舆情文本相似的舆情条数(即，故障事件类型和故障事件类型对应的反馈次数)。在***冷启动时，该舆情模板可以是空的，可以通过后续步骤211和步骤216对舆情模板进行更新。其中，步骤211对舆情模板属性的舆情条数进行更新，步骤116对舆情模板属性的舆情内容进行更新。

S208：经过步骤209中的相似度对比，如果达到了相似度阈值，则认为该条舆情数据和舆情模板中的舆情文本相似。

S211：对于步骤208中确定出的与舆情模板中的舆情文本相似的舆情数据，可以用其更新舆情模板，将相似的舆情文本的舆情数目增加1。

S210：经过步骤S211的更新操作之后，可以检查舆情模板中的各个舆情文本以及对应的舆情数目，判断舆情数目是否达到报警阈值。

S213：对于步骤210中达到报警阈值的舆情文本，进行故障事件报警，即报警发生了与舆情文本相关的故障事件。

S212：经过步骤209的相似度对比之后，会存在一些没有达到相似度阈值的舆情数据。

S215：定期对步骤212中所得到的舆情数据进行检测。

S216：通过对步骤215中的舆情数据的检测过程，可以对舆情列表进行更新，增加一些需要关注的舆情文本。

S214：将步骤216中整理得到的进一步关注的舆情补充到舆情模板，以及将步骤211中需要更新的相关舆情数目更新到舆情模板中。

S217：对于不需要更新舆情模板的舆情数据，可以丢弃不进行处理。

即，对获取的预定时间周期内的所有舆情数据进行聚类分析，将相似的舆情数据(即，表征同一类故障事件的数据)划分到一个类别中，并统计各类别舆情数据的数量，如果某个类别中的数量超出预设阈值，则对该类别对应的故障事件进行报警。对于没有被聚类至任何一个类别中的舆情数据，将该舆情数据与预设的舆情模板(即，故障事件类型和反馈次数对照表)中的各个故障事件进行相似性比较，如果存在相似度超出预设阈值的故障事件类型，则通过该舆情数据对该相似的故障事件类型的反馈次数进行更新。如果更新后的反馈次数超出预设阈值，则进行提示。

如图3所示，为本例所提供的故障事件发现的方法流程示意图。在获取到预定时间内的舆情数据(例如：0到15分钟的舆情数据)之后，可以对这些数据(舆情数据11、舆情数据21、舆情数据31……舆情数据2m、舆情数据3q)进行聚类分析，以便将相似的舆情数据划分到同一聚类集合中(例如：舆情数据11、舆情数据12……舆情数据1n划分到第一集合中，舆情数据21、舆情数据22……舆情数据2m划分到第二集合中，舆情数据31、舆情数据32……舆情数据3q划分到第三集合中)，然后，可以对各个集合中的舆情数据的数量进行统计，可以确定出第一集合中数量是超出报警阈值的，因此可以对集合1对应的故障事件1进行报警。而对于第二集合和第三集合都是没有超出报警阈值的，因此可以将其增加至预设的舆情列表中，该列表中可以记录有故障事件文本及对应的反馈次数。

在下一个故障事件周期中，可以获取下一个时间内的舆情数据(例如1到16分钟的舆情数据)，对这些数据进行聚类分析，将超出报警阈值的故障事件进行报警。假设在这个过程中又发现了故障事件1，那么可以确定故障事件1是否是已经进行报警的故障事件以及生成报警时间到目前为止是否超出预设周期，如果已经报警，且报警时间未超出预设周期，则对该报警丢弃不管。对于未超出报警阈值的故障事件，则到舆情列表中进行相似度匹配，确定是否存在相似的舆情文本，如果存在，则对舆情列表中相应的舆情文本对应的舆情数据的数量进行更新。并进一步确定更新后的舆情数量是否达到故障事件阈值，如果达到，则进行报警。

下面结合一个具体场景对上述故障事件发现方法进行说明，然而，值得注意的是该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

以手淘的舆情反馈为例，如图4所示，在3月26日开始，有收到用户舆情反馈：“拍立淘服务”不可用，然而由于反馈次数很少，因此，通过舆情的聚类分析无法有效聚类发现该故障事件。如图5所示，在3月27日、3月28日、3月29日又持续有用户反馈“拍立淘服务不可用”。

通过在3月26日开始收到用户舆情反馈：“拍立淘服务不可用”时，就将该故障事件增加至舆情列表中，在后续“3月27日、3月28日、3月29日”出现有用户反馈“拍立淘服务不可用”时，可以到舆情列表中进行相似度比对，在该舆情的数量超出预设阈值时，可以进行故障事件报警：拍立淘发生故障事件，从而可以实现对这种反馈比较分散的故障事件的发现和报警。

再如图6所示，在10月22日、10月24日用户都反馈了同样的问题“搜索发现出现问题”，那么当该舆情累计到一定数量时，即可进行自动报警，以便及时对该故障事件进行处理。

在上例中，主要是以对某个应用的所有的舆情数据数量进行集中统计，以确定是否存在故障事件。然而，在实际实现的时候，有时候可能这种故障事件的发生是地域性，或者是目标人群性的，或者仅是在某些类型的终端中才会发生的故障事件。例如，例如，有一百个人反馈打不开首页，那可能是个小问题，但是如果某个城市的某个区有一百人反馈打不开首页，那么可能就是个大的问题，或者说某个群体，例如，一百个注册时候账号中未实名注册的用户反馈打不开首页，或者是用某一款手机的有一百人反馈打不开首页，那么这个问题可能就会比较大。

为了可以及时发现这种层面的问题，可以对舆情数据进行基于地域性或者设备类型的分类，从而及时发现问题，即，可以对同一类型的故障事件，进行进一步细化的分类，从而使得判断结果更有针对性，更准确。

基于此，在本例中，提供了一种故障事件发现方法，可以包括如下步骤：

S1：获取目标舆情数据；

S2：确定所述目标舆情数据所提及的故障事件；

S3：确定所述故障事件所匹配的类型以及所述目标舆情数据的标定特征；

S4：在所述舆情数据的标定特征符合预设的标定特征的情况下，对所述类型所关联的舆情数据的数量进行累计；

S5：在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

其中，上述的标定特征可以包括但不限于以下至少之一：地域特征、设备特征、账号特征等，然而，值得注意的是，上述所列举的标定特征仅是一种示意性表述，在实际实现的时候，也可以有其它的标定特征，例如：人群特征、所使用的网络特征等等，都可以作为标定特征。

因为将舆情数据又按照标定特征进行了进一步的细分，从而使得可以及时发现某些区域或者某些群体特征的故障事件，从而更为及时有些的对故障事件进行处理。

本申请实施例所提供的方法实施例可以在服务器、计算机集群或者类似的运算装置中执行。以运行在服务器上为例，图7是本发明实施例的一种故障事件发现方法的服务器的硬件结构框图。如图7所示，服务器10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器10还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本发明实施例中的短信息的发送方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的短信息的发送方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输模块106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在硬件层面，该服务器可以包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务实现装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图8，在软件实施方式中，该故障事件发现装置应用于服务器中，可以包括：获取模块801、确定模块802、更新模块803和报警模块804。其中：

获取模块801，用于获取目标舆情数据；

确定模块802，用于确定所述目标舆情数据所提及的故障事件；

更新模块803，用于确定所述故障事件所匹配的类型，并将所述目标舆情数据关联于所述类型，对所述类型所关联的舆情数据的数量进行累计；

报警模块804，用于在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

在一个实施方式中，确定所述故障事件所匹配的类型，可以包括：确定舆情列表中是否存在与所述故障事件对应的类型，其中，所述舆情列表中存储有类型以及各类型所关联的舆情数据的数量。

在一个实施方式中，上述舆情列表可以包括但不限于以下至少之一：数据集合、数组、表格、索引表。

在一个实施方式中，上述获取模块801可以包括：获取单元，用于获取预设时间长度内的舆情数据；分析单元，用于按照故障事件类型对所述预定时间长度内的舆情数据进行聚类分析；生成单元，用于根据聚类分析结果，将对应故障事件类型的舆情数据数量未超出预设阈值的舆情数据作为目标舆情数据。

在一个实施方式中，报警模块还可以在按照类型对所述预定时间长度内的舆情数据进行聚类分析之后，根据聚类分析结果，对类型所关联的舆情数据的数量超出预设阈值的类型进行故障提示。

在一个实施方式中，上述装置还可以包括：添加模块，用于在不存在与所述故障事件匹配的类型的情况下，为所述故障事件设置类型；将设置的类型增加至舆情列表中。

请参考图9，在软件实施方式中，该故障事件发现装置应用于服务器中，还可以是包括：

获取模块901，用于获取舆情数据；

划分模块902，用于对所述舆情数据进行聚类分析，将舆情数据划分为多个数据集合；

第一报警模块903，用于对所述多个数据集合中舆情数据数量超出预设阈值的数据集合进行故障报警；

更新模块904，用于根据所述多个数据集合中舆情数据数量未超出预设阈值的数据集合，对舆情列表进行更新；

第二报警模块905，用于根据更新后的舆情列表确定是否需要进行故障事件报警。

请参考图10，在软件实施方式中，该故障事件发现装置应用于服务器中，还可以包括：

第一获取模块1001，用于获取目标舆情数据；

第二获取模块1002，用于获取所述目标舆情数据对应的故障事件类型，以及所述目标舆情数据的标定特征；

更新模块1003，用于对所述对应的故障事件类型且符合所述标定特征的舆情数据数量进行更新；

报警模块1004，用于在更新后的舆情数据数量超出预设阈值的情况下，对所述对应的故障事件类型且符合所述标定特征的故障事件类型进行故障事件报警。

在一个实施方式中，所述标定特征包括：地域特征、设备特征、账号特征。

本申请提供的故障事件发现方法和服务器，通过设置舆情列表，对于聚类分析中舆情数量未超出预设数量的舆情数据，用于更新舆情数据的数量，使得在一个故障事件发现周期中未达到报警条件的故障事件，可以在多个故障事件发现周期进行舆情数据的数量累加，从而可以发现小范围内的故障事件，避免了小范围的故障事件一直无法被发现和报警。通过上述方式解决了现有的故障事件发现方式无法有效对短时间内小范围的故障事件进行报警的技术问题，达到了对短时间内小范围的故障事件进行有效的发现和报警的技术效果。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的硬件的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，也可以通过数据迁移的实施过程中体现出来。该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机***环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器***、基于微处理器的***、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何***或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (13)

1.一种故障事件发现方法，其特征在于，所述方法包括：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型，并将所述目标舆情数据关联于所述类型；

对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

2.根据权利要求1所述的方法，其特征在于，确定所述故障事件所匹配的类型，包括：

确定舆情列表中是否存在与所述故障事件对应的类型，其中，所述舆情列表中存储有类型以及各类型所关联的舆情数据的数量。

3.根据权利要求2所述的方法，其特征在于，所述舆情列表包括以下至少之一：数据集合、数组、表格、索引表。

4.根据权利要求1所述的方法，其特征在于，获取目标舆情数据包括：

获取预设时间长度内的舆情数据；

按照类型对所述预设时间长度内的舆情数据进行聚类分析；

根据聚类分析结果，将对应类型的舆情数据数量未超出预设阈值的舆情数据作为目标舆情数据。

5.根据权利要求4所述的方法，其特征在于，在按照类型对所述预定时间长度内的舆情数据进行聚类分析之后，所述方法还包括：

根据聚类分析结果，对类型所关联的舆情数据的数量超出预设阈值的类型进行故障提示。

6.根据权利要求1所述的方法，其特征在于，在确定所述故障事件所匹配的类型的过程中，所述方法还包括：

在不存在与所述故障事件匹配的类型的情况下，为所述故障事件设置类型；

将设置的类型增加至舆情列表中。

7.一种故障事件发现方法，其特征在于，所述方法包括：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型以及所述目标舆情数据的标定特征；

在所述舆情数据的标定特征符合预设的标定特征的情况下，对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

8.根据权利要求7所述的方法，其特征在于，所述标定特征包括以下至少之一：地域特征、设备特征、账号特征。

9.一种服务器，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现权利要求1至6中任一项所述的方法。

10.一种服务器，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取目标舆情数据；

确定所述目标舆情数据所提及的故障事件；

确定所述故障事件所匹配的类型以及所述目标舆情数据的标定特征；

在所述舆情数据的标定特征符合预设的标定特征的情况下，对所述类型所关联的舆情数据的数量进行累计；

在所述数量超出预设阈值的情况下，对所述类型进行故障提示。

11.根据权利要求10所述的服务器，其特征在于，所述标定特征包括以下至少之一：地域特征、设备特征、账号特征。

12.一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现权利要求1至6中任一项所述方法的步骤。

13.一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现权利要求7至8中任一项所述方法的步骤。