一种移动通信网络的工单风暴控制方法

霍龙浩，李尧辉，彭友斌

（中国移动通信集团广东有限公司，广州 510623）

一种移动通信网络的工单风暴控制方法

霍龙浩，李尧辉，彭友斌

（中国移动通信集团广东有限公司，广州 510623）

本文提出一种基于动态调整工单流向的工单风暴控制方法，该方法能根据设定的阈值自动拦截告警风暴，在形成工单风暴前以告警形式提醒监控人员、以及动态改变风暴涉及告警的派单流向，从而有效控制工单风暴。数据分析表明，该方法能有效实现工单风暴的智能化控制。

告警风暴；工单风暴检测；工单风暴控制；阈值

1 引言

近年来，通信网络发展迅猛，网络规模日益扩大及复杂化，尤其是4G快速建网进一步增加了全网的复杂性、异构性、扁平性[1]，一个故障或某一未知原因可能引发大量告警短时间内集中涌现，形成告警风暴，进而造成网管系统性能快速下降甚至系统崩溃等严重影响。此外，随着电信行业网络管理的智能化、集中化[2，3]，网管系统从设备采集告警后，大部分告警经过智能预处理自动透传到一线故障处理人员，由故障处理人员通过专用设备或专用手机软件获取工单信息再进行故障处理。在这种情况下，告警风暴会导致短时间内大量工单被透传到一线故障处理人员，形成工单风暴。按每张工单大小约100 kB计算，现场故障处理人员接收工单的设备处理能力在4G网络下最大带宽为20 Mbit/s，工单量超过204张/秒就可能会出现卡死情况，导致工单丢失而无法获知故障信息。因此，通过有效的方法对工单风暴进行控制、使故障处理人员能够快速准确地定位、处理故障，对于保障通信网络稳定运行、提供安全优质的通信服务至关重要。

本文提出一种基于动态调整工单流向的工单风暴控制方法，该方法根据历史统计数据自动计算出当前的阈值，综合监控平台则根据设定的阈值对采集的告警进行工单风暴检测，根据检测结果通知监控人员并动态改变工单流向，从而能够在工单风暴发生之前智能、及时、有效地控制工单的流向，避免大量工单直接透传到一线故障处理人员，提高故障处理效率。

2 告警风暴控制与工单风暴控制的区别

告警风暴防控能在一定程度上减少派单量。文献[4～9]中提出通过对告警进行相关性分析来快速定位告警根源，从而实现告警风暴的抑制。文献[10]提出利用计数方法来判断是否产生告警风暴，并提出一种改进的告警相关性分析算法用于预防告警风暴，而在告警风暴发生时则采用匹配规则和一系列的规则处理机制来确保网管系统处理告警风暴的效率。文献[11]中则提出一种告警分层过滤模型来达到快速发现、定位故障的目的，进而有效防止告警风暴。文献[12]的思想是通过对网络告警系统的软硬件架构各方面进行优化升级来提高网管系统应对告警风暴的能力。总体而言，这些方法都是通过网管层面的策略来对告警风暴进行控制，避免网管系统性能快速下降甚至崩溃，同时也可能一定程度减少工单量。但告警风暴控制方法不能完全避免工单风暴的产生，例如优化告警系统虽然能够提高故障定位、分析、处理的速度，但是当短时间内大量告警产生时，还是有可能会有大量工单被派给故障处理人员，此时还是会产生工单风暴。因此，工单风暴也无法简单套用告警风暴的控制方法进行控制。

现阶段主要是通过派单前手动抑制或者派单后在工单系统手动删单进行工单风暴的控制。派单前手动抑制由于是人工操作，难以短时间内抑制大量工单的自动派发；派单后在后台手动删单，除了人工操作具有的不便性外，批量删除工单还难以保证每个故障均有工单跟进，而且派单后如果工单已经下达给一线故障处理人员并且已经影响其正常处理故障，那么这时再进行手工删单也是为时已晚。因此，通过系统自动执行工单风暴智能检测，在工单风暴发生之前对监控人员进行告警通知并采取相应的应对措施，能更好有效抑制工单风暴。

3 工单风暴控制

下：第一，对采集后的告警进行工单风暴检测。第二，若检测判断没有工单风暴则按原流程派单、闭环处理；若检测到工单风暴则立即上报工单风暴告警通知监控人员，工单风暴告警主要包括下列信息：告警标题、省份、地区名称、设备厂家、网络分类、产生时间、工单风暴检测时段、工单风暴下预计派单量、当前阈值等。同时将原来派往一线故障处理人员的工单动态改变流向到预处理人员。第三，若检测到工单风暴，工单派到预处理人员，预处理人员可对工单进行人工仲裁、人工预处理后派单给故障处理人员处理故障进而闭环处理。若人工仲裁判定工单有集中性，且核查出由同一个故障或原因造成的批量工单派发，可以派一张单到一线故障处理人员处理该故障或解决该问题，其他工单等到故障或问题处理后直接申请报结闭环处理；若人工仲裁判定拦截的工单没有集中性（即工单风暴为误告），或者核查不出原因，可以将该部分工单全部派往一线故障处理人员，一线故障处理人员处理好工单故障或问题后可以申请报结闭环处理。具体的流程如图1所示。

实现工单风暴控制的重点是如何在触发工单风暴前及时的发现、响应，并以告警形式提醒监控人员，从而有效的拦截工单风暴。

基于动态调整工单流向的工单风暴控制方法的主要步骤如

图1 工单风暴控制流程

其中，工单风暴检测的具体流程如图2所示。

图2 工单风暴检测流程

（1）采集告警。

（2）匹配派单规则：将采集到的告警与派单规则进行匹配，是否符合派单规则以是否生成一张单作为标准。对于压缩衍生规则，衍生告警会产生一张新的单，因此包含在统计范围内；符合追加规则的告警、衍生告警的子告警由于会追加到已有工单，则不会产生新的单，因此不纳入统计范围内。派单规则改变时，系统应能自动识别更新，按新的派单规则实现上述检测。

（3）统计预计派单量：对符合派单规则的告警按预计派单时间归入相应的三元组维度（地区名称-设备厂家-网络分类）的相应时间段，按检测时间间隔t1进行检测时段t2内预计派单量的统计，从而统计出各维度各时间段的预计派单量。

（4）判断是否存在工单风暴：根据历史工单数据的规律，将每个维度一天的时间进行分段，不同的时间段设置不同的阈值，这些设定好的阈值会周期性的进行更新（一般一个月更新一次）。对于各维度各时间段的预计派单量，如果超过预先设定的阈值，则认为该时间段该维度内即将存在工单风暴；否则，认为没有工单风暴。

4 性能分析

对于本文所提出基于动态调整工单流向的工单风暴控制方法，本文主要从实际运行成效和阈值的有效性来对其性能进行分析。

4.1 工单风暴控制的现有成效

将该方法运用于实际生产的各种网络类型中，能有效拦截工单风暴。比如，在201X年T月24日T+1 h 30 min拦截了某地1-某品牌-LTE无线、某地2-某品牌-LTE无线、某地3-某品牌-LTE无线三个维度的工单风暴告警，分别拦截了2 917、2 117、774张工单；将拦截的工单派到预处理人员后，预处理人员对工单进行人工仲裁、人工预处理判定告警是由某个网元补丁加载工程引起的，于是在厂家网管告警消除时对工单进行了批量报结。工单风暴控制有效阻止工单直接在短时间内集中派往一线故障处理人员，防止故障处理设备崩溃、影响故障处理进程。

以T-T+1月的触发情况进行分析，各网络类型的触发情况如图3所示。

从图3可见，工单风暴控制在网络架构扁平化的LTE无线中效果最为突出，LTE无线工单风暴涉及单量约为GSM无线的4倍。

图3 各网络类型T-T+1月工单风暴触发情况分析

拦截的工单中，有7成的工单风暴是由于故障原因、工程原因、网管原因导致的，这几类原因造成的批量工单通常可以只派一张单描述清楚问题，待处理好后，告警已消除的工单会由系统自动申请报结，其余告警仍未消除的少量工单则由监控人员手动升级移交至对应的维护单位。停电退服、天气等原因导致的工单量只占了3成，这部分工单需要直接升级移交至对应的维护单位进行处理。可见，工单风暴控制所拦截的大部分工单（工程原因、网管原因、故障原因导致的）均可以批量报结而不用直接全部派给一线代维人员。

4.2 阈值的有效性分析

由上文的分析可知，工单风暴的检测是基于阈值的。如果阈值选取不合理，则工单风暴的检测对于防止工单风暴并不能起到很好的作用。如果阈值选取过大，会容易发生漏告，不能及时检测到风暴告警；如果阈值过小，可能会导致频繁触发工单风暴告警。因此，阈值的合理选取直接关系到工单风暴控制的效果。

首先分析划分阈值生效时段的合理性，即为何要对每个维度一天的时间划分不同的阈值生效时段。下面以“某地-某品牌-GSM无线”这一个维度为例进行分析。根据T月份的报表数据画出“某地-某品牌-GSM无线”这一个维度在有效派单时间（6：00～23：00）内每个小时的预计派单量统计图。其中每个小时都分别对派单量按0～10，11～20，21～30，31～40，40以上这5个区域分段，统计每个分段的频数，并计算各个分段的频数占每小时总频数的百分比。

从图4中的数据分布情况可以看到，每个小时内，预计派单量在0～10内的占比都是最高的，占到95%以上；而根据工单风暴的检测流程我们知道发生工单风暴告警主要是在预计派单量超过阈值时，所以0～10内的派单量的占比情况可以忽略，实际中更多的是考虑预计派单量在30以上的情况。因此在划分“某地-某品牌-GSM无线”的阈值生效时段时，可将一天划分为6：00～8：00（不含8点整），8：00～9：00（不含9点整），9：00～23：00（不含23点整）。

其次要分析的是阈值的计算方法的有效性，通过M、M+1月的历史报表数据计算出各维度的阈值，将其应用于M+2月份和M+3月份的工单风暴检测。例如，对201X年M+2月和M+3月的工单风暴触发记录从误告率和直接报结率两个方面进行分析。其中，误告率是指不具有集中性的工单数量与拦截的总工单数量的比值；而直接报结率则是指经人工仲裁判定可以直接申请批量报结的工单数量与拦截的总的工单数量的比值。显然，误告率越低，则说明工单风暴控制的成效越好；同样，直接报结率越高，也说明工单风暴控制的成效越好。

从图5可见，8月和9月的总体直接报结率为81.67%，大部分工单能直接报结。其中，直放站、本地骨干、本地汇聚直接报结率较高达100%，LTE无线直接报结率也高达97.94%，这得益于LTE网络结构的扁平化，一个问题引起大量底层设备工单的概率较大，因此大部分情况只要解决该问题即可直接报结而无需下派大量工单。

从总体直接报结率看，提出的工单风暴控制在实际应用中可以有效避免大量工单直接派发至一线故障处理人员，达到工单风暴控制的目的。

图4 某地-某品牌-GSM无线每天每小时的预计派单量分段统计图

图5 工单风暴控制的工单直接报结率

5 总结

本文针对现有的工单风暴控制方法智能性差、效率低、时延大等缺陷，提出一种基于动态调整工单流向的工单风暴控制方法，该方法可以实现基于阈值的智能工单风暴检测，在检测的基础上进一步通过动态调整工单流向预处理人员，对由同一个故障或原因造成的批量工单派发，选择只派一张单到一线故障处理人员，而其余工单只需等故障或问题处理后直接申请报结即可，这样既不会因为短时间内聚集大量工单而造成一线故障处理人员的工单处理终端崩溃，又可保证故障得到及时有效的解决，从而有效控制工单风暴的形成。通过对运行数据分析表明，能有效拦截故障、工程、网管等原因造成的工单风暴，误告率低、直接报结率高，能对工单风暴实现及时、智能、有效控制。

[1] 汪丁鼎， 龚追飞． TD-SCDMA的长期演进——TDLTE[J]． 移动通信， 2008(32)：33-38．

[2] 王洋． 集中监控模式下的信息通信网络故障管理探索与实践[J]． 电信科学， 2015(31)：164-170．

[3] 温国权． 广东电信集中告警管理系统规划与设计[D]．广州：华南理工大学， 2014．

[4] 梅玉洁． 通信网网管告警过滤机制的研究与应用[D]．南昌：南昌大学， 2006．

[5] 胡奇． 通信管理网告警控制机制的研究应用[D]． 吉林：吉林大学， 2007．

[6] 杨一兵． 移动通信网络告警及其关联性分析[D]． 哈尔滨：哈尔滨工程大学， 2008．

[7] 石永革， 梅玉洁， 石峰． 通信网网管告警过滤机制的研究与应用[J]． 计算机工程与设计， 2008(29)：2169-2171．

[8] 石永革， 石峰． 通信网告警影响性分析机制的研究与应用[J]．微计算机信息， 2008(24)：76-78．

[9] 李海青． 综合网管系统中告警风暴的抑制[J]． 科技传播，2011， (16)．

[10] 刘远超． 通信网告警相关性应用的研究[D]． 天津：天津理工大学，2012．

[11] 徐润萍， 李淑静． 电力通信网告警分层过滤机制的设计[J]．国外电子元器件， 2008：47-48．

[12] 甘雯， 文锋， 宫大鹏， 等． 应对告警风暴告警的系统优化策略[J]． 电信科学， 2015(5)．

A scheme of work orders storm control on mobile communication network

HUO Long-hao, LI Yao-hui, PENG You-bin
(China Mobile Communications Group Guangdong Co., Ltd., Guangzhou 510623, China)

This paper presents a new work orders storm control method based on dynamic adjustment of work orders' flow direction.The method can automatically intercept the warning storm based on the preset threshold. Italerts the monitoring personnel and dynamically changesinvolved work orders'flow direction. In this way,the work orders storm can be effectively controlled. Data analysis shows that the method can effectively realize the intelligent control of the work orders storm. Keywords warning storm; the work orders storm detection; the work orders storm control; threshold

TN929.5

A

1008-5599（2016）09-0071-05

2016-06-07