基站隐患挖掘方法、装置、设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种基站隐患挖掘方法、装置、设备及存储介质。

背景技术

为确保通话以及流量使用等业务的顺畅，需要对基站进行隐患挖掘。

现有对基站进行隐患挖掘过程中，是统一设置参数门限(参数门限的门限值基本是人工确定的)的，而统一设置参数门限，导致话务量以及流量特别少的基站与某些重保区域内(话务量以及流量特别多)的基站，投入同等的挖掘资源以及后续的处理资源，致使基站隐患处理效益低下。

发明内容

有鉴于此，本申请实施例提供一种基站隐患挖掘方法、装置、设备及存储介质，旨在解决现有基站隐患挖掘过程中，统一设置参数门限，致使基站隐患处理效益低下的技术问题。

本申请实施例提供了一种基站隐患挖掘方法，所述方法包括：

获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；

确定处于同一重要程度级别的基站；

按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

基于所述隐患挖掘结果，确定隐患响应策略。

在本申请的一种可能的实施方式中，所述运维数据至少包括资源数据、告警数据、投诉数据以及性能数据；

所述获取各个基站的运维数据的步骤，包括：

获取各个基站的资源数据，所述资源数据中至少包括基站的在线用户数、各个基站在预设单位时间内的话务量以及各个基站在预设单位时间内的流量；

获取各个基站的告警数据，所述告警数据至少包括各个基站在预设单位时间内的故障数以及最近故障间隔；

获取各个基站的投诉数据，所述投诉数据至少包括各个基站在预设单位时间内的投诉量；

获取各个基站的性能数据，所述性能数据至少包括各个基站的http访问时延以及http访问成功率。

在本申请的一种可能的实施方式中，所述基于所述各个基站的运维数据分别确定对应各基站的重要程度级别的步骤，包括：

基于包括所述在预设单位时间内的故障数、所述在预设单位时间内的投诉量、所述在预设单位时间内的业务量、所述在预设单位时间内的流量、所述最近故障间隔、所述在线用户数、所述http访问时延以及http访问成功率数据的运维数据，对各基站进行聚类处理，得到聚类结果；

基于所述聚类结果，对各基站按照重要程度进行分级，得到各基站的重要程度级别。

在本申请的一种可能的实施方式中，所述获取各个基站的告警数据，所述告警数据至少包括各个基站在预设单位时间内的故障数以及最近故障间隔的步骤，包括：

确定各个基站的类型，并确定各基站类型对应的告警标题；

基于所述告警标题，确定各个基站在预设单位时间内的故障数；

获取各个基站上次告警清除时间，基于所述告警清除时间，确定各个基站的最近故障间隔；

其中，所述获取各个基站的投诉数据，所述投诉数据至少包括各个基站在预设单位时间内的投诉量的步骤，包括：

确定投诉用户所在位置信息，将所述所在位置信息映射至对应的基站上，以确定各个基站在预设单位时间内的投诉量。

在本申请的一种可能的实施方式中，所述按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果的步骤，包括：

按照预设隐患指标，将处于重大级别的各基站，从高到低进行排名，得到第一排名，并基于所述第一排名，将排名在前第一预设百分比隐患区间的基站，作为第一隐患基站；

按照预设隐患指标，将处于重要级别的各基站按照同样的隐患指标，从高到低进行排名，得到第二排名，并基于所述第二排名，将排名在前第二预设百分比隐患区间的基站，作为第二隐患基站；

按照预设隐患指标，将处于一般级别的各基站按照同样的隐患指标，从高到低进行排名，得到第三排名，并基于所述第三排名，将排名在前第三预设百分比隐患区间的基站，作为隐患基站，其中，所述第一预设百分比大于所述第二预设百分比，所述第二预设百分比大于所述第三预设百分比。

在本申请的一种可能的实施方式中，所述预设隐患指标包括超长基站隐患指标或者超频基站隐患指标；

所述超长基站隐患指标包括：生命周期为在网的基站连续第一预设时长无流量、或者单次退服历时超第二预设时长；

所述超频基站隐患指标包括生命周期为在网的基站连续第三预设时长产生非工程退服、或者第四预设时长内非工程退服告警超预设次数。

在本申请的一种可能的实施方式中，所述基于所述隐患挖掘结果，确定隐患响应策略的步骤，包括：

基于所述隐患挖掘结果，确定待处理基站，并确定待处理基站的处理优先级；

根据所述优先级，上报不同的等待处理指令给处理人员，以供所述处理人员先后处理不同基站的隐患。

本申请还提供一种基站隐患挖掘装置，所述装置包括：

获取模块，用于获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；

第一确定模块，用于确定处于同一重要程度级别的基站；

隐患模块，用于按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

第二确定模块，用于基于所述隐患挖掘结果，确定隐患响应策略。

本申请还提供一种基站隐患挖掘系统，所述基站隐患挖掘系统包括如上述任一项方法所述的核验组件，所述基站隐患挖掘系统还包括：

后端平台，所述后端平台用于：收集各个用户的第一防疫数据，所述防疫数据中包括各用户的第一人脸信息；还用于基于核验组件的识别码信息反馈所述第一用户的第一防疫数据；还用于接收所述核验组件发送的最高质量评分对应的人脸信息，并基于所述最高质量评分对应的人脸信息更新所述第一防疫数据，还用于接收所述核验组件基于采集模式采集的第一用户的目标人脸信息，并基于所述目标人脸信息更新所述第一防疫数据；

门禁设备，所述门禁设备用于：在接收到所述核验组件的开启指令时，开启门禁以放行所述第一用户或者所述第二用户。

本申请还提供一种基站隐患挖掘设备，所述基站隐患挖掘设备为实体节点设备，所述基站隐患挖掘设备包括：存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的所述基站隐患挖掘方法的程序，所述基站隐患挖掘方法的程序被处理器执行时可实现如上述所述基站隐患挖掘方法的步骤。

为实现上述目的，还提供一种存储介质，所述存储介质上存储有基站隐患挖掘程序，所述基站隐患挖掘程序被处理器执行时实现上述任一所述的基站隐患挖掘方法的步骤。

本申请提供一种基站隐患挖掘方法、装置、设备及存储介质，与现有基站隐患挖掘过程中，统一设置参数门限，致使基站隐患处理效益低下相比，在本申请中，获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；确定处于同一重要程度级别的基站，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；基于所述隐患挖掘结果，确定隐患响应策略。在本申请中，基于各个基站的运维数据，对基站进行包括重大级别、重要级别以及一般级别的分级，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，即对不同级别的基站按照不同的隐患区间进行基站的隐患挖掘，可以理解，话务量以及流量特别少的基站与话务量以及流量特别多的基站，两者的运维数据不同，因而级别不同，因而隐患区间不同，即隐患挖掘结果不同，基于不同的隐患挖掘结果，很显然，对应投入不同等的处理资源，避免基站隐患处理效益低下。

附图说明

图1为本申请基站隐患挖掘方法的第一实施例的流程示意图；

图2为本申请基站隐患挖掘方法第一实施例中步骤S10的细化流程示意图；

图3为本申请实施例方案涉及的硬件运行环境的设备结构示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请实施例提供一种基站隐患挖掘方法，在本申请基站隐患挖掘方法的第一实施例中，参照图1，所述方法包括：

步骤S10，获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；

步骤S20，确定处于同一重要程度级别的基站；

步骤S30，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

步骤S40，基于所述隐患挖掘结果，确定隐患响应策略。

本实施例旨在：提升基站隐患处理效益。

具体步骤如下：

步骤S10，获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；

在本实施例中，基站隐患挖掘方法可以应用于基站隐患挖掘装置，该基站隐患挖掘装置属于基站隐患挖掘系统，该基站隐患挖掘系统属于基站隐患挖掘设备。

在本实施例中，该基站隐患挖掘系统设置在计算机、手持终端或者其他终端设备上。

在本实施例中，获取各个基站的运维数据的方式包括：

方式一：各个基站实时上报运维数据，以供基站隐患挖掘装置获取；

方式二：基站隐患挖掘装置在接收到采集运维数据的采集指令时，将采集指令发送给采集区域内的基站，以供采集区域内的基站上报运维数据。

在本实施例中，运维数据包括各个类型的数据，具体可以是资源类型、告警类型、投诉类型以及性能类型等。

具体数据属于何种类型，可以经由设置信息确定。

其中，所述运维数据至少包括资源数据、告警数据、投诉数据以及性能数据；

参照图2，所述获取各个基站的运维数据的步骤，包括：

步骤S11，获取各个基站的资源数据，所述资源数据中至少包括基站的在线用户数、各个基站在预设单位时间内的话务量以及各个基站在预设单位时间内的流量；

在本实施例中，运维数据至少包括资源数据(资源参数的数据值构成)、告警数据(告警参数的数据值构成)、投诉数据(投诉参数的数据值构成)以及性能数据(性能参数的数据值构成)，当然，还可以包括其他类型的数据，而由于运维数据至少包括资源数据、告警数据、投诉数据以及性能数据，而不只是单一的某一类型的数据，因而，能够准确全面地对基站进行重要程度的划分。

在本实施例中，资源数据中至少包括基站的在线用户数、各个基站在预设单位时间内的话务量以及各个基站在预设单位时间内的流量；

基站的在线用户数可以是基站的实时在线用户数目，也可以是最大在线用户数。

其中，预设单位时间可以是15分钟、1小时、1天或者7天等。

因而，当预设单位时间内为15分钟时，各个基站在预设单位时间内的话务量可以是各个基站在15分钟内的话务量，当预设单位时间内为1小时，各个基站在预设单位时间内的话务量为各个基站在1小时内的话务量，当预设单位时间内为1天时，各个基站在预设单位时间内的话务量为各个基站在1天内的话务量，当预设单位时间内为7天时，各个基站在预设单位时间内的话务量为各个基站在7天内的话务量。

同样地，当预设单位时间内为15分钟时，各个基站在预设单位时间内的流量可以是各个基站在15分钟内的流量，当预设单位时间内为1小时，各个基站在预设单位时间内的流量为各个基站在1小时内的流量，当预设单位时间内为1天时，各个基站在预设单位时间内的流量为各个基站在1天内的流量，当预设单位时间内为7天时，各个基站在预设单位时间内的流量为各个基站在7天内的流量。

步骤S12，获取各个基站的告警数据，所述告警数据至少包括各个基站在预设单位时间内的故障数以及最近故障间隔；

获取各个基站的告警数据，告警数据至少包括各个基站在预设单位时间内的故障数，同样地，当预设单位时间内为15分钟时，各个基站在预设单位时间内的故障数可以是各个基站在15分钟内的故障数，当预设单位时间内为1小时，各个基站在预设单位时间内的故障数为各个基站在1小时内的故障数，当预设单位时间内为1天时，各个基站在预设单位时间内的故障数为各个基站在1天内的故障数，当预设单位时间内为7天时，各个基站在预设单位时间内的故障数为各个基站在7天内的故障数。

其中，最近故障间隔为基站上次告警清除时间至当前时刻的时间时长。

步骤S13，获取各个基站的投诉数据，所述投诉数据至少包括各个基站在预设单位时间内的投诉量；

获取各个基站的投诉数据，告投诉数据至少包括各个基站在预设单位时间内的投诉量，同样地，当预设单位时间内为15分钟时，各个基站在预设单位时间内的投诉量可以是各个基站在15分钟内的投诉量，当预设单位时间内为1小时，各个基站在预设单位时间内的投诉量为各个基站在1小时内的投诉量，当预设单位时间内为1天时，各个基站在预设单位时间内的投诉量为各个基站在1天内的投诉量，当预设单位时间内为7天时，各个基站在预设单位时间内的投诉量为各个基站在7天内的投诉量。

步骤S14，获取各个基站的性能数据，所述性能数据至少包括各个基站的http访问时延以及http访问成功率。

在本实施例中，性能数据至少包括各个基站的http访问时延(预设单位时间内的http访问时延平均值)以及http访问成功率(预设单位时间内的访问成功率平均值)。

基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别。

在本实施例中，重要程度级别还可以是其他的分级方式，如重要程度级别可以是重要级别，非重要级别。

在本实施例中，重要程度级别的划分可以根据配置信息确定。

在本实施例中，重大级别的级别高于重要级别，重要级别的级别高于一般级别。

在本实施例中，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别的方式可以是：

方式一：确定各个基站对应运维参数的权重(影响力值)以及运维参数的参数值，进而确定对应各基站的重要程度级别。

方式二：将各个基站输入至预设模型中，基于预设模型，确定对应各基站的重要程度级别。其中，该预设模型是经由即由重要程度级别标签，对预设训练数据进行迭代训练后，能够准确确定运维参数对应预设重要程度级别的模型。

步骤S20，确定处于同一重要程度级别的基站；

在得到各个基站的重要程度级别后，确定处于同一重大级别的基站，确定处于同一重要级别的基站，确定处于同一一般级别的基站。

步骤S30，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

具体地，按照预设隐患指标，将同一重大级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

按照预设隐患指标，将同一重要级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

按照预设隐患指标，将同一一般级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果。

其中，隐患区间指的是预设隐患指标关联的区间。

步骤S40，基于所述隐患挖掘结果，确定隐患响应策略。

在得到隐患挖掘结果后，确定隐患响应策略(隐患应急策略)。

所述基于所述隐患挖掘结果，确定隐患响应策略的步骤，包括：

步骤S41，基于所述隐患挖掘结果，确定待处理基站，并确定待处理基站的处理优先级；

在得到隐患挖掘结果后，确定同一重大级别内的第一待处理基站，确定同一重要级别内的第二待处理基站，并确定同一一般级别内的第三待处理基站。

其中，第一待处理基站的优先级高于第二待处理基站的优先级，第二待处理基站的优先级高于第三待处理基站的优先级。

步骤S42，根据所述优先级，上报不同的等待处理指令给处理人员，以供所述处理人员先后处理不同基站的隐患。

在本实施例中，在得到优先级后，根据所述优先级，上报不同的等待处理指令给处理人员，以供所述处理人员先后处理不同基站的隐患。

不同的等待处理指令可以是最紧急的处理指令，次等紧急的处理指令或者一般紧急的处理指令。

本申请提供一种基站隐患挖掘方法、装置、设备及存储介质，与现有基站隐患挖掘过程中，统一设置参数门限，致使基站隐患处理效益低下相比，在本申请中，获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；确定处于同一重要程度级别的基站，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；基于所述隐患挖掘结果，确定隐患响应策略。在本申请中，基于各个基站的运维数据，对基站进行包括重大级别、重要级别以及一般级别的分级，按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，即对不同级别的基站按照不同的隐患区间进行基站的隐患挖掘，可以理解，话务量以及流量特别少的基站与话务量以及流量特别多的基站，两者的运维数据不同，因而级别不同，因而隐患区间不同，即隐患挖掘结果不同，基于不同的隐患挖掘结果，很显然，对应投入不同等的处理资源，避免基站隐患处理效益低下。

进一步地，基于本申请中第一实施例，提供本申请的另一实施例，在该实施例中，

所述基于所述各个基站的运维数据分别确定对应各基站的重要程度级别的步骤，包括：

步骤A1，基于包括所述在预设单位时间内的故障数、所述在预设单位时间内的投诉量、所述在预设单位时间内的业务量、所述在预设单位时间内的流量、所述最近故障间隔、所述在线用户数、所述http访问时延以及http访问成功率数据的运维数据，对各基站进行聚类处理，得到聚类结果；

步骤A2，基于所述聚类结果，对各基站按照重要程度进行分级，得到各基站的重要程度级别。

在本实施例中，基于15分钟内的故障数、1小时内的故障数、1天内的故障数、7天内的故障数、15分钟内的投诉量、1小时内的投诉量、1天内的投诉量、7天内的投诉量、15分钟内的话务量、1小时内的话务量、1天内的话务量、7天内的话务量、15分钟内的流量、1小时内的流量、1天内的流量、7天内的流量、最近故障间隔、在线用户数、http访问时延、http访问成功率、对各基站进行聚类处理，得到聚类结果，也即，得到重要程度分级的聚类结果，在本实施例中，聚类的方式可以是：利用高斯混合算法、K－means聚类算法、DBSCAN算法，或者其他无监督聚类算法分别对基站数据进行聚类，在聚类后，还人工抽样验证聚类结果的合理性，最终将基站分为三类(三级)：重大、重要、一般。

需要强调的是，在本实施例中，聚类的目的在于：通过聚类，将基站按照其重要程度进行分级。

进一步地，基于本申请中第一实施例和第二实施例，提供本申请的另一实施例，在该实施例中，所述获取各个基站的告警数据，所述告警数据至少包括各个基站在预设单位时间内的故障数以及最近故障间隔的步骤，包括：

步骤B1，确定各个基站的类型，并确定各基站类型对应的告警标题；

在本实施例中，基站的类型可以是2G基站、4G基站、5G基站。

在确定基站的类型后，确定各基站类型对应的告警标题。

其中，2G基站退服标题或者告警标题：BCF FAULTY(BCF告警)、站点ABIS控制链路断、BTS O&M LINK FAILURE(BTS O&M LINK告警)以及OML故障告警。

4G基站退服标题或者告警标题：BASE STATION FAULTY(基站告警)、HeartbeatFailure(心跳故障)、基站退出服务、NE O&M CONNECTIONFAILURE(NE O&M连接故障)、NE3SWS AG EN T NOT RE SPO N D ING TO REQUESTS(请求无法响应告警)、网元断链告警、网元连接中断、No connectionto BTS(连接不上BTS)；

5G基站退服标题或者告警标题：gNodeB退服告警、基站DU退服、HeartbeatFailure(心跳故障)。

步骤B2，基于所述告警标题，确定各个基站在预设单位时间内的故障数；

在本实施例中，通过直接读取告警标题的方式，确定各个基站在预设单位时间内的故障数。

步骤B3，获取各个基站上次告警清除时间，基于所述告警清除时间，确定各个基站的最近故障间隔；

具体地，最近故障间隔＝该基站上一次非工程退服类告警清除时间－该基站上一次非工程退服类告警发生时间。

其中，所述获取各个基站的投诉数据，所述投诉数据至少包括各个基站在预设单位时间内的投诉量的步骤，包括：

步骤C1，确定投诉用户所在位置信息，将所述所在位置信息映射至对应的基站上，以确定各个基站在预设单位时间内的投诉量。

在本实施例中，将投诉用户所在位置信息映射到对应的基站上，以计算单位时间内该基站的投诉量。

在本实施例中，通过准确确定故障数、最近故障间隔以及投诉量，为准确确定隐患挖掘结果奠定基础。

进一步地，基于本申请中第一实施例、第二实施例和第三实施例，提供本申请的另一实施例，在该实施例中，所述预设隐患指标包括超长基站隐患指标或者超频基站隐患指标；

所述超长基站隐患指标包括：生命周期为在网的基站连续第一预设时长如连续30天无流量、或者单次退服历时超第二预设时长如单次退服历时超48小时；

所述超频基站隐患指标包括生命周期为在网的基站连续第三预设时长如连续7天产生非工程退服(指的是因故障退服，而不是人为退服)、或者第四预设时长内如一天内非工程退服告警超预设次数如超20次。

其中，所述基站隐患挖掘方法还包括：

所述按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果的步骤，包括：

步骤D1，按照预设隐患指标，将处于重大级别的各基站，从高到低进行排名，得到第一排名，并基于所述第一排名，将排名在前第一预设百分比隐患区间的基站，作为第一隐患基站；

步骤D2，按照预设隐患指标，将处于重要级别的各基站按照同样的隐患指标，从高到低进行排名，得到第二排名，并基于所述第二排名，将排名在前第二预设百分比隐患区间的基站，作为第二隐患基站；

步骤D3，按照预设隐患指标，将处于一般级别的各基站按照同样的隐患指标，从高到低进行排名，得到第三排名，并基于所述第三排名，将排名在前第三预设百分比隐患区间的基站，作为隐患基站，其中，所述第一预设百分比大于所述第二预设百分比，所述第二预设百分比大于所述第三预设百分比。

在本实施例中，将月作为时间维度，挖掘超长基站隐患(隐患指标)，其中超长基站隐患是指连续N天零流量或者单次非工程退服历时超M小时的基站。

则统计任一月份所有基站连续零流量的最大天数，算作该基站连续零流量天数，统计该月该基站非工程退服类告警最大的历时算作该基站退服历时。

针对重大基站，第一隐患基站(第一超长基站)为对应连续零流量天数是所有重大基站的前5％(前第一预设百分比)的基站，或者对应的退服历时是所有重大基站的前5％(前第一预设百分比)的基站。

例如将基站按连续零流量天数从高到底排序，假设重大基站总共有100个，则前5个基站为第一隐患基站(第一超长基站)。

针对重大基站，第二隐患基站(第二超长基站)为对应连续零流量天数是所有重大基站的前1％(前第二预设百分比)的基站，或者对应的退服历时是所有重大基站的前1％(前第二预设百分比)的基站。

例如将基站按连续零流量天数从高到底排序，假设重大基站总共有100个，则前1个基站为第一隐患基站(第二超长基站)。

针对一般基站，第三隐患基站(第三超长基站)为对应连续零流量天数是所有一般基站的前0.1％(前第三预设百分比)的基站，或者对应的退服历时是所有一般基站的前0.1％(前第三预设百分比)的基站。

例如将基站按连续零流量天数从高到底排序，假设重大基站总共有1000个，则前1个基站为第一隐患基站(第三超长基站)。

在本实施例中，将月作为时间维度，挖掘超频基站隐患(隐患指标)，其中超频基站是指连续X天非工程退服(每天产生过至少1次退服类告警)或者单天退服次数超过Y次。

统计任一月份所有基站每天上报非工程退服类告警次数，其中，连续上报告警(告警次数均大于0)的最大天数作为该基站连续退服天数，最大次数作为该基站单天退服次数。

针对重大基站，第一隐患基站(第一超频基站)为对应连续退服天数是所有重大基站的前5％(前第一预设百分比)的基站或者对应的单天退服次数是所有重要基站的前5％(前第一预设百分比)的基站。

例如将基站按连续退服天数从高到底排序，假设重大基站总共有100个，则前5个基站为第一隐患基站(第一超频基站)。

针对重要基站，第二隐患基站(第二超频基站)为对应连续退服天数是所有重要基站的前1％(前第二预设百分比的基站)，或者对应的单天退服次数是所有重要基站的前1％的基站(前第二预设百分比)。

针对一般基站，第三隐患基站(第三超频基站)为对应连续退服天数是所有重要基站的前1％(前第三预设百分比的基站)，或者对应的单天退服次数是所有重要基站的前1％的基站(前第三预设百分比)。

在本实施例中，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果，以节约后续的隐患处理资源。

参照图3，图3是本申请实施例方案涉及的硬件运行环境的设备结构示意图。

如图3所示，该基站隐患挖掘设备可以包括：处理器1001，存储器1005，通信总线1002。通信总线1002用于实现处理器1001和存储器1005之间的连接通信。

可选地，该基站隐患挖掘设备还可以包括用户接口、网络接口、摄像头、RF(RadioFrequency，射频)电路，传感器、WiFi模块等等。用户接口可以包括显示屏(Display)、输入子模块比如键盘(Keyboard)，可选用户接口还可以包括标准的有线接口、无线接口。网络接口可以包括标准的有线接口、无线接口(如WI－FI接口)。

本领域技术人员可以理解，图3中示出的基站隐患挖掘设备结构并不构成对基站隐患挖掘设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图3所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块以及基站隐患挖掘程序。操作系统是管理和控制基站隐患挖掘设备硬件和软件资源的程序，支持基站隐患挖掘程序以及其它软件和/或程序的运行。网络通信模块用于实现存储器1005内部各组件之间的通信，以及与基站隐患挖掘系统中其它硬件和软件之间通信。

在图3所示的基站隐患挖掘设备中，处理器1001用于执行存储器1005中存储的基站隐患挖掘程序，实现上述任一项所述的基站隐患挖掘方法的步骤。

本申请基站隐患挖掘设备具体实施方式与上述基站隐患挖掘方法各实施例基本相同，在此不再赘述。

本申请还提供一种基站隐患挖掘装置，所述装置包括：

获取模块，用于获取各个基站的运维数据，基于所述各个基站的运维数据分别确定对应各基站的重要程度级别，其中，所述重要程度级别包括重大级别、重要级别以及一般级别；

第一确定模块，用于确定处于同一重要程度级别的基站；

隐患模块，用于按照预设隐患指标，将同一重要程度级别内的基站，按照对应同样的隐患区间进行基站的隐患挖掘，得到隐患挖掘结果；

第二确定模块，用于基于所述隐患挖掘结果，确定隐患响应策略。

在本申请的一种可能的实施方式中，所述运维数据至少包括资源数据、告警数据、投诉数据以及性能数据；

所述获取模块包括：

第一获取单元，用于获取各个基站的资源数据，所述资源数据中至少包括基站的在线用户数、各个基站在预设单位时间内的话务量以及各个基站在预设单位时间内的流量；

第二获取单元，用于获取各个基站的告警数据，所述告警数据至少包括各个基站在预设单位时间内的故障数以及最近故障间隔；

第三获取单元，用于获取各个基站的投诉数据，所述投诉数据至少包括各个基站在预设单位时间内的投诉量；

第四获取单元，用于获取各个基站的性能数据，所述性能数据至少包括各个基站的http访问时延以及http访问成功率。

在本申请的一种可能的实施方式中，所述获取模块还包括：

聚类单元，用于基于包括所述在预设单位时间内的故障数、所述在预设单位时间内的投诉量、所述在预设单位时间内的业务量、所述在预设单位时间内的流量、所述最近故障间隔、所述在线用户数、所述http访问时延以及http访问成功率数据的运维数据，对各基站进行聚类处理，得到聚类结果；

分级单元，用于基于所述聚类结果，对各基站按照重要程度进行分级，得到各基站的重要程度级别。

在本申请的一种可能的实施方式中，所述第二获取单元包括：

第一确定子单元，用于确定各个基站的类型，并确定各基站类型对应的告警标题；

第二确定子单元，用于基于所述告警标题，确定各个基站在预设单位时间内的故障数；

获取定子单元，用于获取各个基站上次告警清除时间，基于所述告警清除时间，确定各个基站的最近故障间隔；

其中，所述第三获取单元包括：

第三确定子单元，用于确定投诉用户所在位置信息，将所述所在位置信息映射至对应的基站上，以确定各个基站在预设单位时间内的投诉量。

在本申请的一种可能的实施方式中，所述隐患模块包括：

第一排名单元，用于按照预设隐患指标，将处于重大级别的各基站，从高到低进行排名，得到第一排名，并基于所述第一排名，将排名在前第一预设百分比隐患区间的基站，作为第一隐患基站；

第二排名单元，用于按照预设隐患指标，将处于重要级别的各基站按照同样的隐患指标，从高到低进行排名，得到第二排名，并基于所述第二排名，将排名在前第二预设百分比隐患区间的基站，作为第二隐患基站；

第三排名单元，用于按照预设隐患指标，将处于一般级别的各基站按照同样的隐患指标，从高到低进行排名，得到第三排名，并基于所述第三排名，将排名在前第三预设百分比隐患区间的基站，作为隐患基站，其中，所述第一预设百分比大于所述第二预设百分比，所述第二预设百分比大于所述第三预设百分比。

在本申请的一种可能的实施方式中，所述预设隐患指标包括超长基站隐患指标或者超频基站隐患指标；

所述超长基站隐患指标包括：生命周期为在网的基站连续第一预设时长无流量、或者单次退服历时超第二预设时长；

所述超频基站隐患指标包括生命周期为在网的基站连续第三预设时长产生非工程退服、或者第四预设时长内非工程退服告警超预设次数。

在本申请的一种可能的实施方式中，所述第二确定模块包括：

确定单元，用于基于所述隐患挖掘结果，确定待处理基站，并确定待处理基站的处理优先级；

上报单元，用于根据所述优先级，上报不同的等待处理指令给处理人员，以供所述处理人员先后处理不同基站的隐患。

本申请基站隐患挖掘装置的具体实施方式与上述基站隐患挖掘方法各实施例基本相同，在此不再赘述。

本申请实施例提供了一种存储介质，且所述存储介质存储有一个或者一个以上程序，所述一个或者一个以上程序还可被一个或者一个以上的处理器执行以用于实现上述任一项所述的基站隐患挖掘方法的步骤。

本申请存储介质具体实施方式与上述基站隐患挖掘方法各实施例基本相同，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加硬件平台的方式来实现，也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。