本发明涉及计算机领域，尤其是涉及一种网络故障原因定位的方法及装置。
背景技术：
对于大多数网络终端上依靠网络传输数据的进程而言，网络质量的好坏可直接影响用户体验。当网络质量较差时，会造成这些进程的延迟较大甚至无法使用。然而，网络质量可能受地域、运营商、服务器等多种因素影响，开发者往往很难及时定位到网络质量差的具体原因。
目前定位网络故障主要依靠舆情监控，即是通过用户的反馈进行分析，定位故障发生的原因。例如，网络终端内某款app的用户里，仅大量上海市中国移动用户反馈该app使用过程中出现网络延迟大或无法正常使用的情况，则证明了上海市中国移动运营商存在网络故障，但这样的故障定位方式较为被动，滞后时间久。
技术实现要素：
本发明的目的在于提供一种网络故障原因定位的方法及装置，该方法和装置采用更为主动地方式定位网络故障原因。
为实现上述发明目的之一，本发明一实施方式提供了一种网络故障原因定位的方法，所述方法包括：
接收一分析周期内若干网络终端上传的上报数据，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间；
根据上报数据获得的信息，分别计算在地区维度和运营商维度的各个组合下每种网络连接类型的平均建立连接所耗时间，获得若干条聚合数据，每条聚合数据包括地区信息、运营商信息，以及对应的平均建立连接所耗时间；
将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。
作为本发明一实施方式的进一步改进，根据每条上报数据获得其对应网络终端的地区信息、运营商信息步骤具体包括：
根据上报数据中网络终端的地址信息，获得与网络终端的地址信息对应的地区信息和运营商信息。
作为本发明一实施方式的进一步改进，根据比对结果和地区信息、运营商信息，定位网络故障步骤具体包括：
根据地区信息和运营商信息，定位平均建立连接所耗时间超出对应基准数据允许的波动区间的聚合数据对应的无线网络故障。
作为本发明一实施方式的进一步改进，所述方法还包括：
计算样本周期内接收到的所有样本数据分别在匹配的地区维度与运营商维度各种组合下，每种网络连接类型对应的平均建立连接所耗时间，作为基准数据。
作为本发明一实施方式的进一步改进，所述样本周期不短于所述分析周期。
作为本发明一实施方式的进一步改进，所述聚合数据中地区信息可为地区集合或单一地区，所述聚合数据中运营商信息可为运营商集合或单一运营商。
作为本发明一实施方式的进一步改进，根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障步骤包括：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和运营商集合，则判定为所述分析周期内所述指定进程的服务器端发生网络故障。
作为本发明一实施方式的进一步改进，根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障步骤包括
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区和运营商集合，则判定为所述分析周期内所述第一地区发生网络故障。
作为本发明一实施方式的进一步改进，根据比对结果和地区信息、运营商信息，定位网络故障步骤包括：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和第一运营商，则判定为所述分析周期内所述第一运营商发生网络故障。
作为本发明一实施方式的进一步改进，根据比对结果和地区信息、运营商信息，定位网络故障步骤包括：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区、第一运营商，则判定为所述分析周期内所述第一地区的所述第一运营商发生网络故障。
为实现上述发明目的之一，本发明一实施方式提供了一种网络故障原因定位的的模块，所述模块包括：
获取模块，用于接收一分析周期内若干网络终端上传的上报数据，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间；
计算模块，用于根据上报数据获得的信息，分别计算在地区维度和运营商维度的各个组合下每种网络连接类型的平均建立连接所耗时间，获得若干条聚合数据，每条聚合数据包括地区信息、运营商信息，以及对应的平均建立连接所耗时间；
决策模块，用于将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。
作为本发明一实施方式的进一步改进，所述获取模块还用于：
根据上报数据中网络终端的地址信息，获得与网络终端的地址信息对应的地区信息和运营商信息。
作为本发明一实施方式的进一步改进，所述决策模块用于：
根据地区信息和运营商信息，定位平均建立连接所耗时间超出对应基准数据允许的波动区间的聚合数据对应的无线网络故障。
作为本发明一实施方式的进一步改进，所述计算模块还用于：
计算样本周期内接收到的所有样本数据分别在匹配的地区维度与运营商维度各种组合下，每种网络连接类型对应的平均建立连接所耗时间，作为基准数据。
作为本发明一实施方式的进一步改进，所述样本周期不短于所述分析周期。
作为本发明一实施方式的进一步改进，所述聚合数据中地区信息可为地区集合或单一地区，所述聚合数据中运营商信息可为运营商集合或单一运营商。
作为本发明一实施方式的进一步改进，所述决策模块用于：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和运营商集合，则判定为所述分析周期内所述指定进程的服务器端发生网络故障。
作为本发明一实施方式的进一步改进，所述决策模块用于：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区和运营商集合，则判定为所述分析周期内所述第一地区发生网络故障。
作为本发明一实施方式的进一步改进，所述决策模块用于：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和第一运营商，则判定为所述分析周期内所述第一运营商发生网络故障。
作为本发明一实施方式的进一步改进，所述决策模块用于：
若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区、第一运营商，则判定为所述分析周期内所述第一地区的所述第一运营商发生网络故障。
相对于现有技术，本发明的网络故障原因定位的方法及装置，可通过采集网络终端上传的上报数据，并对上报数据进行分析比对，主动地判断网络情况及定位网络故障原因，使网络故障原因定位更加迅速及时。
附图说明
图1是本发明一实施方式中网络故障原因定位的系统架构图。
图2是本发明一实施方式中网络故障原因定位方法的流程图。
图3是本发明一示例的根据聚合数据和基准数据定位网络故障原因的方法的流程图。
图4是本发明一实施方式中网络故障原因定位装置的模块图。
具体实施方式
以下将结合附图所示的具体实施方式对本发明进行详细描述。但这些实施方式并不限制本发明，本领域的普通技术人员根据这些实施方式所做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。
如图1所示，在本发明一实施方式中，所述网络故障原因定位的系统包括：服务器10，若干网络终端20。所述若干网络终端20的运营商可相同或不同(例如中国联通、中国电信、中国移动等)，且所述若干网络终端20可与所述服务器10通信，向所述服务器10上传上报数据。所述服务器10接收到所述终端20的上报数据后，可根据所述上报数据进行网络故障原因的定位。
如图2所示，在本发明一实施方式中，所述网络故障原因定位的方法包括：
s1、接收一分析周期内若干网络终端上传的上报数据，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间；
s2、根据上报数据获得的信息，分别计算在地区维度和运营商维度的各个组合下每种网络连接类型的平均建立连接所耗时间，获得若干条聚合数据，每条聚合数据包括地区信息、运营商信息，以及对应的平均建立连接所耗时间；
s3、将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。
在本实施方式中，网络终端内发出网络请求的进程可为系统进程、指定app的进程等，以下以指定app(所谓指定app即是需要监控网络质量的app)为例进行说明。
所述指定app内可集成有埋点sdk。通过该集成的埋点sdk，使得当所述指定app发出网络请求时，可同时向该指定的app对应的服务器发送上报数据。
当与该指定app对应的服务器收集到上报数据后，可根据所述上报数据的内容，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间。
具体地，所述上报数据包括网络终端的地址信息(例如ip地址等)，以及网络终端内发出网络请求的进程和相应服务器之间的建立连接所耗时间。在本实施方式中，可根据上报数据中网络终端的地址信息，获得与网络终端的地址信息对应的地区信息和运营商信息。
在本实施方式中，可将一条上报数据转换为一条中间信息。其中，每一条中间信息可包括：地区信息、运营商信息、网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间，例如：北京市、中国联通、32ms。当然，所述中间信息还可以包括其他信息，如网络终端的操作系统，特定app的版本号等。为方便说明，下文主要以由地区信息、运营商信息、网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间构成的中间信息为例进行详述。
在本实施方式中，将分析周期(例如一个小时)内接收到的上报数据(以当前时间作为参考，即是将上一分析周期接收到的上报数据)所转换得到的若干中间信息进行聚合，以得到若干条聚合数据。可以理解，若分析周期越短，则故障原因定位越及时。当然，每一个分析周期的时间可相同，也可不同。
具体地，该聚合是分别在地区维度和运营商维度的各个组合下进行的，所述聚合数据中地区信息可为地区集合或单一地区，所述聚合数据中运营商信息可为运营商集合或单一运营商。
在本实施方式中，所述组合可包括：地区集合(各个地区的汇总)、运营商集合(各个运营商的汇总)的单个组合；各个地区分别与运营商集合配对的多个组合；地区集合分别与各个运营商配对的多个组合；各个地区分别与各个运营商配对的多个组合。当然，在其他实施方式中，所述组合中也可以不包括含地区集合和/或运营商集合的组合，后续可根据需要，将对应地区与对应运营商的组合合并即可。
另外，在各个组合下将若干中间信息聚合，在本实施方式中，可分别计算在地区维度和运营商维度的各个组合下每种网络连接类型(例如，都是通过3g网络联网、都是通过4g网络联网，都是通过wifi网络联网等)的平均建立连接所耗时间(建立连接所耗时间总和/样本数)，以组成若干条聚合数据。其中，每条聚合数据包括：地区信息、运营商信息、网络连接类型，以及计算出的与该地区信息和运营商信息匹配的相同网络连接类型的平均建立连接所耗时间，当然，聚合数据还可包括对应的样本数，例如，以下的聚合数据为各部分按照顺序分别是地区信息、网络连接类型、运营商信息、平均建立连接所耗时间、样本数：
北京市，4g，中国联通：34ms，32条；
上海市，3g，中国移动：106ms，36条；
地区集合，4g，中国移动：36ms，68593条；
北京市，3g，运营商集合：98ms，69653条；
地区集合，4g，运营商集合：59ms，69854265条
……。
本实施方式中，在获得聚合数据后，可将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。例如，根据地区信息和运营商信息，定位平均建立连接所耗时间超出对应基准数据(相同网络连接类型、相同地区信息、相同运营商信息的基准数据)允许的波动区间的聚合数据对应的网络故障。
如图3所示，具体地决策规则为：
判断地区集合、运营商集合对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和运营商集合，则判定为所述分析周期内所述指定进程的服务器端发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内所述进程的服务器端发生网络故障。
判断第一地区、运营商集合对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区和运营商集合，则判定为所述分析周期内所述第一地区发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该地区发生网络故障。
判断地区集合、第一运营商对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和第一运营商，则判定为所述分析周期内所述第一运营商发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该运营商发生网络故障。
判断第一地区、第一运营商对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区、第一运营商，则判定为所述分析周期内所述第一地区的所述第一运营商发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该地区的该运营商发生网络故障。
当然，如果各条聚合数据中平均建立连接所耗时间都没有超过对应的基准数据允许的波动区间，则说明分析周期内各聚合数据对应的地区、运营商、服务器网络正常。
为方便理解，下述分别从地区、运营商的各种组合下举例说明。
2016年3月15日下午3点至4点一个小时(一分析周期)对应的上报数据所产生的其中一条聚合数据为：北京市，4g，中国联通：34ms，32条；其对应的基准数据是：北京市，4g，中国联通：36ms，15032条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长2ms，而预设的基准数据允许的波动区间为向上波动50％，即阈值为36ms*1.5＝54ms，如此，可判断在2016年3月15日下午3点至4点内北京市中国联通网络为正常，详细地，可判断在2016年3月15日下午3点至4点内北京市中国联通网络为正常。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：地区集合，4g，运营商集合：59ms，69854265条；其对应的基准数据是：地区集合，4g，运营商集合：30ms，70845631条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长29ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为30ms*1.5＝45ms，如此，可判断在2016年3月15日下午3点至4点内该特定app的服务器端发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：北京市，3g，运营商集合：98ms，69653条；其对应的基准数据是：北京市，3g，运营商集合：46ms，804876条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长52ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为46ms*1.5＝69ms，如此，可判断在2016年3月15日下午3点至4点内北京市地区发生网络故障，详细地，可判断在2016年3月15日下午3点至4点内北京市地区的3g网络发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：地区集合，拨号上网，中国移动：36ms，68593条；其对应的基准数据是：地区集合，拨号上网，中国移动：10ms，648871条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长26ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为10ms*1.5＝15ms，如此，可判断在2016年3月15日下午3点至4点内中国移动发生网络故障，详细地，可判断在2016年3月15日下午3点至4点内中国移动拨号上网发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据：上海市，3g，中国移动：106ms，36条；其对应的基准数据是：上海市，3g，中国移动：52ms，13241条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长54ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为52ms*1.5＝78ms，如此，可判断在2016年3月15日下午3点至4点内上海市中国移动网络发生故障，详细地，可判断在2016年3月15日下午3点至4点内的上海市的中国移动3g网络发生网络故障。
进一步地，在本实施方式中，所述方法还包括：
计算样本周期(例如一周时间)内接收到的所有样本数据分别在匹配的地区维度与运营商维度各种组合下，每种网络连接类型对应的平均建立连接所耗时间，作为基准数据。
在本实施方式中，所述样本周期不短于所述分析周期。一般地，所述样本周期需长于所述分析周期。其中，地区维度、运营商维度各种组合，样本数据与各组合中地区信息、运营商信息的匹配方式(先将样本数据转换为中间信息，再根据中间信息中的地区信息和运营商信息进行匹配)，以及计算平均建立连接所耗时间的方式，与上述对上报数据的处理同理，在此不再赘述。
如图4所示，在本发明一实施方式中，所述网络故障原因定位的装置包括：
获取模块100，用于接收一分析周期内若干网络终端上传的上报数据，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间；
计算模块200，用于根据上报数据获得的信息，分别计算在地区维度和运营商维度的各个组合下每种网络连接类型的平均建立连接所耗时间，获得若干条聚合数据，每条聚合数据包括地区信息、运营商信息，以及对应的平均建立连接所耗时间；
决策模块300，用于将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。
在本实施方式中，网络终端内发出网络请求的进程可为系统进程、指定app的进程等，以下以指定app(所谓指定app即是需要监控网络质量的app)为例进行说明。
所述指定app内可集成有埋点sdk。通过该集成的埋点sdk，使得当所述指定app发出网络请求时，可同时向该指定的app对应的服务器发送上报数据。
当与该指定app对应的服务器收集到上报数据后，可根据所述上报数据的内容，获得每条上报数据对应的地区信息、运营商信息，以及网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间。
具体地，所述上报数据包括网络终端的地址信息(例如ip地址等)，以及网络终端内发出网络请求的进程和相应服务器之间的建立连接所耗时间。在本实施方式中，可根据上报数据中网络终端的地址信息，获得与网络终端的地址信息对应的地区信息和运营商信息。
在本实施方式中，可将一条上报数据转换为一条中间信息。其中，每一条中间信息可包括：地区信息、运营商信息、网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间，例如：北京市、中国联通、32ms。当然，所述中间信息还可以包括其他信息，如网络终端的操作系统，特定app的版本号等。为方便说明，下文主要以由地区信息、运营商信息、网络终端内发出网络请求的指定进程和相应服务器之间的建立连接所耗时间构成的中间信息为例进行详述。
在本实施方式中，将分析周期(例如一个小时)内接收到的上报数据(以当前时间作为参考，即是将上一分析周期接收到的上报数据)所转换得到的若干中间信息进行聚合，以得到若干条聚合数据。可以理解，若分析周期越短，则故障原因定位越及时。当然，每一个分析周期的时间可相同，也可不同。
具体地，该聚合是分别在地区维度和运营商维度的各个组合下进行的，所述聚合数据中地区信息可为地区集合或单一地区，所述聚合数据中运营商信息可为运营商集合或单一运营商。
在本实施方式中，所述组合可包括：地区集合(各个地区的汇总)、运营商集合(各个运营商的汇总)的单个组合；各个地区分别与运营商集合配对的多个组合；地区集合分别与各个运营商配对的多个组合；各个地区分别与各个运营商配对的多个组合。当然，在其他实施方式中，所述组合中也可以不包括含地区集合和/或运营商集合的组合，后续可根据需要，将对应地区与对应运营商的组合合并即可。
另外，在各个组合下将若干中间信息聚合，在本实施方式中，可分别计算在地区维度和运营商维度的各个组合下每种网络连接类型(例如，都是通过3g网络联网、都是通过4g网络联网，都是通过wifi网络联网等)的平均建立连接所耗时间(建立连接所耗时间总和/样本数)，以组成若干条聚合数据。其中，每条聚合数据包括：地区信息、运营商信息、网络连接类型，以及计算出的与该地区信息和运营商信息匹配的相同网络连接类型的平均建立连接所耗时间，当然，聚合数据还可包括对应的样本数，例如，以下的聚合数据为各部分按照顺序分别是地区信息、网络连接类型、运营商信息、平均建立连接所耗时间、样本数：
北京市，4g，中国联通：34ms，32条；
上海市，3g，中国移动：106ms，36条；
地区集合，4g，中国移动：36ms，68593条；
北京市，3g，运营商集合：98ms，69653条；
地区集合，4g，运营商集合：59ms，69854265条
……。
本实施方式中，在获得聚合数据后，可将每一条聚合数据与预存的相同网络连接类型、相同地区信息、相同运营商信息的基准数据比对，并根据比对结果以及对应聚合数据中的地区信息、运营商信息，定位网络故障。例如，决策模块300用于：根据地区信息和运营商信息，定位平均建立连接所耗时间超出对应基准数据(相同网络连接类型、相同地区信息、相同运营商信息的基准数据)允许的波动区间的聚合数据对应的网络故障。
如图3所示，所述决策模块300用于：
判断地区集合、运营商集合对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和运营商集合，则判定为所述分析周期内所述指定进程的服务器端发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内所述进程的服务器端发生网络故障。
判断第一地区、运营商集合对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区和运营商集合，则判定为所述分析周期内所述第一地区发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该地区发生网络故障。
判断地区集合、第一运营商对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为地区集合和第一运营商，则判定为所述分析周期内所述第一运营商发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该运营商发生网络故障。
判断第一地区、第一运营商对应的平均建立连接所耗时间是否超过对应的基准数据允许的波动区间，若平均建立连接所耗时间超过对应的基准数据允许的波动区间的聚合数据中地区信息和运营商信息为第一地区、第一运营商，则判定为所述分析周期内所述第一地区的所述第一运营商发生网络故障。当然，若以当前时间作为参考，即是判定为上一个分析周期内该地区的该运营商发生网络故障。
当然，如果各条聚合数据中平均建立连接所耗时间都没有超过对应的基准数据允许的波动区间，则说明分析周期内各聚合数据对应的地区、运营商、服务器网络正常。
为方便理解，下述分别从地区、运营商的各种组合下举例说明。
2016年3月15日下午3点至4点一个小时(一分析周期)对应的上报数据所产生的其中一条聚合数据为：北京市，4g，中国联通：34ms，32条；其对应的基准数据是：北京市，4g，中国联通：36ms，15032条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长2ms，而预设的基准数据允许的波动区间为向上波动50％，即阈值为36ms*1.5＝54ms，如此，可判断在2016年3月15日下午3点至4点内北京市中国联通网络为正常，详细地，可判断在2016年3月15日下午3点至4点内北京市中国联通网络为正常。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：地区集合，4g，运营商集合：59ms，69854265条；其对应的基准数据是：地区集合，4g，运营商集合：30ms，70845631条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长29ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为30ms*1.5＝45ms，如此，可判断在2016年3月15日下午3点至4点内该特定app的服务器端发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：北京市，3g，运营商集合：98ms，69653条；其对应的基准数据是：北京市，3g，运营商集合：46ms，804876条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长52ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为46ms*1.5＝69ms，如此，可判断在2016年3月15日下午3点至4点内北京市地区发生网络故障，详细地，可判断在2016年3月15日下午3点至4点内北京市地区的3g网络发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据为：地区集合，拨号上网，中国移动：36ms，68593条；其对应的基准数据是：地区集合，拨号上网，中国移动：10ms，648871条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长26ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为10ms*1.5＝15ms，如此，可判断在2016年3月15日下午3点至4点内中国移动发生网络故障，详细地，可判断在2016年3月15日下午3点至4点内中国移动拨号上网发生网络故障。
2016年3月15日下午3点至4点一个小时(一个分析周期)对应的上报数据所产生的其中一条聚合数据：上海市，3g，中国移动：106ms，36条；其对应的基准数据是：上海市，3g，中国移动：52ms，13241条。可以看出，该对应的基准数据的网络连接类型、地区信息、运营商信息需要与比对的聚合数据相同。在本示例中，该条聚合数据的建立连接所耗时间比基准数据长54ms，而预设基准数据允许的波动区间为向上波动50％，即上线阈值为52ms*1.5＝78ms，如此，可判断在2016年3月15日下午3点至4点内上海市中国移动网络发生故障，详细地，可判断在2016年3月15日下午3点至4点内的上海市的中国移动3g网络发生网络故障。
进一步地，在本实施方式中，所述计算模块200还用于：
计算样本周期(例如一周时间)内接收到的所有样本数据分别在匹配的地区维度与运营商维度各种组合下，每种网络连接类型对应的平均建立连接所耗时间，作为基准数据，并存储于存储模块400中。当然，所述存储模块400还可用于存储上报数据、中间信息、聚合数据等。
在本实施方式中，所述样本周期不短于所述分析周期。一般地，所述样本周期需长于所述分析周期。其中，地区维度、运营商维度各种组合，样本数据与各组合中地区信息、运营商信息的匹配方式(先将样本数据转换为中间信息，再根据中间信息中的地区信息和运营商信息进行匹配)，以及计算平均建立连接所耗时间的方式，与上述对上报数据的处理同理，在此不再赘述。
综上所述，本发明的网络故障原因定位的方法及装置，可主动地判断网络情况及定位网络故障原因，使网络故障原因定位更加迅速及时。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置，装置和模块的具体工作过程，可以参考前述方法实施方式中的对应过程，在此不再赘述。
在本发明所提供的几个实施方式中，应该理解到，所揭露的装置，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所展示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块展示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施方式方案的目的。
另外，在本发明各个实施方式中的各功能模块可以集成在一个决策模块中，也可以是各个模块单独物理存在，也可以2个或2个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本发明各个实施方式所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施方式仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施方式对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施方式技术方案的精神和范围。