广东XXX电信基站中断没有断站告警问题分析报告

kfod520

一、
问题描述问题描述：广东XXX电信8月10日凌晨出现基站中断，到上午8点才恢复，而告警台上没有断站告警和信令链路中断告警。
网元信息：BSC6680 V300R007C01SPC300
二、
问题分析问题结论：告警被人为屏蔽，导致问题时间段不上报相关告警。
分析过程：1、
问题场景分析：
通过反馈的信息确认问题发生的现象，现场反馈8月10号凌晨基站中断，我们可以通过其反馈的告警信息看到在10号凌晨2点有基站MLPPP中断告警，到上午8点才恢复，期间还伴随了操作维护中断告警


可以确认，期间该基站是中断了，而从反馈的告警文件中确实没有看到相关信令链路中断的1310告警以及基站断站的27020告警。
2、
告警和日志分析：
检查现场反馈的8月10号13点备份的数据库，查看当前1310告警与27020的配置都是没有被屏蔽的：

再次查看Warn进程日志，发现相关基站基本都是配置了1X&DO两条链路，而两条信令链路都同时断了：

根据27020告警与1310告警的关系，即两条链路同时上报1310告警，那么系统将屏蔽1310告警的上报，直接上报该基站的27020告警，所以此时系统中没有信令链路告警是正常的，但是应该可以看到1571号基站的27020告警才对，而目前的系统中却没有看到。
3、
接着我们对比新旧告警数据库的配置发现在8月9号备份的告警库中其27020告警的屏蔽位是屏蔽状态

也就是说27020告警从8月9号2点到10号13点期间，其屏蔽状态发生了变化，而产品可以提供修改其状态的命令是【SET ALMMSK】设置告警屏蔽标志命令，根据这条线索我们随即开始分析现场的操作日志。
4、
让现场通过强制发送日志方式反馈了8月10号的全部操作日志，使用关键字搜索，并未发现有记录过【SET ALMMSK】命令，但除此之外，系统是没有另外渠道来修改此标志的，是否是该命令的记录被人为删除了？
5、
再次对反馈的操作日志进行排列比对，从8月9日0点开始一直比对到8月10日14点，发现在序列号是54836和54838两个号码之间少了一个54837的命令序列码


根据命令上下之间的关系可以发现，该命令时段发生在8月10日的上午8点36分到9点10分之间。我们系统执行命令的序列是连续的，只有在被人为删除的情况下才会出现不连续的状况。
6
往前追查,在7月30日15点24分出现过27020的告警,可判定在告警屏蔽的设定时间在7月30日-8月9日之间,再查询7月30日往后的日志, 发现序列号是38850和38852两个号码之间少了一命令序列码
38850
2
1246070
zj_admin
10.254.90.9---告警管理系统
Y2011M07D31H15N37S24
38851 //此命令缺失
这里应该是做了屏蔽的 但是被删掉了


38852
2
1264399
emscomm
10.254.89.143
Y2011M08D01H01N59S58
由此可判断在7月31日15点37分-8月1日01点59分这段时间内有人为删除操作记录.

7
分析小结：
经过上述分析，问题情况已经很明确了：在8月10日凌晨2点到8点这段时间，基站中断，但是由于1X和DO都断了，系统将直接上报27020告警，而现场在8月10日8点36分之前其27020告警是一直被屏蔽的，所以告警台上一直无法看到这些断站上报27020告警。
在8月10日8点36分到9点10分之间，现场通过命令将27020告警解屏蔽，后又将该操作记录删除，导致无法从命令日志中查询。
三、
规避措施参考解决方案。
四、
解决方案在需要观察告警时间段，请不要屏蔽相关告警.