一次莫名其妙的故障……

Java技术迷

共 3660字,需浏览 8分钟

 ·

2022-08-25 18:33

粉丝福利:文末送书
大家好,我是小乐,一名普通的网络工程师。

前段时间,我看到新闻,说是日本、加拿大等地接连爆出通信网络故障,引发了大规模的网络中断。心惊之余,我也想起,就在不久前,我也遇到了一个非常诡异的网络故障,差点引发重大事故。

这个故障,到现在我还心有余悸。

今天,我就给大家讲讲我的故事——

我所就职的单位,是一家大型国企。平时,我主要负责网络维护的相关工作。

在我单位的网络中,有各种不同的业务,有的业务对网络实时性和可靠性要求很高。

因为年代久远,单位大部分业务所使用的网络设备,是某国外大厂的设备(姑且称之为S司设备吧,下同)。

我们单位的网络规模极其庞大,因S司的私有生成树协议已经先入为主,所以,目前很难将整张网进行国产设备替换。

故障发生在今年疫情中的某一天。

那天,单位轮岗上班,在岗人员较少。临近下班时,我正在执行巡检任务。突然,单位的综合监控系统开始“铛铛铛的告警,对话框点完一个又出来另一个,冒个没完。

仔细一看,告警的设备一大堆,其中一个提示:某业务核心网络交换机(姑且称之为9型机吧)-B机的IP地址可用性异常!

情况紧急,我和办公室的几个同事赶紧下楼,直奔机房。慌乱之中,同事的鞋都差点跑丢了。

到了机房,值班的同事兴师问罪:

“都快下班了,what are you 弄啥捏?

“冤枉啊,我们啥也没干!

来到心交换机B机的机柜前,定睛一看:我擦,整个设备除了电源灯,其它灯全都不亮了!啥情况这是?!

同事赶紧拿来了笔记本,接上Console线,登陆系统。结果,屏幕上只有“>”符号,根本没有出现熟悉的命令交互界面!

这套系统是A机和B机双机备份。我们赶紧用Console线接A机——谢天谢地,A机一切正常。

这些年,我们定期会对核心设备做切换演练,验证单机独立支撑网络。现在看来,没有白做。

有A机顶着,业务总算没有中断,我们也可以长吁一口气。

心理踏实些之后,我们赶紧就联系了保修公司。在等待之余,我们也在机房想办法,进行一些故障恢复尝试。

坦率地说,我干了十多年的网工,交换机板卡故障遇到了不少,整个设备宕机还是第一次遇到呢。

我先尝试把引擎拔出来,又重新插回去,设备没有反应。干脆,我祭出了重启大法,直接对整个设备进行断电。

薅掉四条电源线,等了半分钟,然后,重新插回去。运气不错,console界面开始显示自检。十多分钟后,设备启动完毕,一切恢复正常!果然……还是重启大法最好用啊!

故障虽然恢复了,问题原因要找到啊。于是,show tech,把日志啊配置啊一堆材料收集齐,发给了保修公司。保修公司再去找S司开“case(上报问题,建立故障单)。

结果,就在等待反馈的过程中,还没过几天,核心交换机-A机也出问题了!

故障现象完全一致:状态灯全灭,系统无响应。

有了上次的经验,这次我们直接断电重启。十多分钟后,A机恢复正常,生成树切了,热备网关切了,对业务稍稍有影响,但总体可控,影响不大。

这就让人很纳闷了——上次是B机,这次是A机。难不成,这个故障和新冠一样,还会相互传染?A机B机变成了难兄难弟?S司设备现在这么不靠谱了吗?这才用了三年多,怎么就宕机罢工了呢?

当时,我们甚至把原因都想到了太阳身上。

因为,此前曾经有一次,使用S司的另外一型号设备,出现业务板卡故障。case给出的结论,就是近期太阳活动频繁,黑子耀斑啥的,造成设备内部信号紊乱,引发业务板卡重启(囧)。为此,我还特意收藏了中科院国家天文台太阳活动预报中心的网站,有事没事就上去看看(又囧)。


一边怪太阳,一边加紧催促S司尽快跟进case

结果,case出来了,我们所有人简直无语。

case”说,这是一个已知BUG,问题出在固态硬盘上。

原来,在这个9型机系列交换机的引擎上,使用了某光的某版本固态硬盘。这个硬盘在累计使用28224小时后,会自动锁死,从而导致引擎宕机。注意,是累计小时,就算关机重启也不会清零。

28224小时,掐指一算,1176天,差不多就是3年多一点的时间。

我们这两个发生故障的核心网络交换机,就是三年前启动的。相差几天宕机,可能是当时进机房加电时间不一样。

用人话来说,就是:“这机器有个定时炸弹,到了三年多的时间,就会爆炸!

这叫神马玩意?!?!

无语之外,我们赶紧排查了所有的在网运行设备。结果发现,同样还有几台这个系列交换机,正在使用。

我们用case给出的命令,查看了一下累计小时。我勒个去,果然有一对支撑重要业务的交换机,到28224小时还有两天!更要命的是,这对交换机的累计时间是完全一样!也就是说,两天后,两台机器很可能会同时宕机!

这简直是要了我们的命。对于我们的业务运行,是毁灭性的灾难。

赶紧仔细S司的解决方案。S司给出的方案有两个:

1、升级NXOS系统;
2、升级某光SSD的固件。

短时间内对关键交换机进行关停升级是不现实的。于是,我们选择了升级SSD固件的方案。

到了临近28224小时的那天,大伙儿在办公室里如坐针毡,简直就是等待宣判。我坐不住,干脆跑去机房,蹲在机柜前,等着薅电源线。

幸运的是,到了28225小时,系统一切正常!看来,升级固件还是有用的!我们同事瞬时欢呼雀跃!

以上就是故障的整个过程。现在回想起来,我的手心都还在冒汗。

事实上,S司的这个故障隐患是极大的。这个9型机系列交换机,定位就是数据中心级核心网络交换,各大企业都会将它用在非常重要的业务上。

况且,核心设备基本上都是双机同时加电测试。三年内,基本不会主动去升级软件版本。这个重大缺陷,极有可能导致双机同时宕机,带来的危害是难以想象的!

最让人生气的,不是产品缺陷。因为产品有bug也是很正常的事情。

让人生气的是,S司明明知道这个bug,却不告知客户!他们卖出这么多设备,难道就没有建立客户档案吗?就没有进行设备售后跟踪吗?小设备就算了,这种大型关键设备,难道卖出去就啥事也不管了吗?

作为一家正常的公司,在发现缺陷后,应该查看产品或客户销售记录,积极主动通知客户,尽快规避或解决吧?下个通知单,有那么难吗?

我个人认为,通信网络设备也应该像汽车领域一样,建立召回机制。如果发生重大缺陷,厂商应该给国家有关部门备案,然后启动召回机制。

现在,通信网络设备是和水、电一样重要的基础设施,关乎国家安全、企业安全和消费者安全。厂商有义务建立更完善的跟踪和回访机制,监督售出设备的运行健康,保证网络安全。

好了,我的故事就讲到这里吧。

作为一名网络工程师,我讲这个故事,主要是为了分享经验,让大家引以为戒。

此外,也希望外界对我们网工多一些理解,多一些支持。现在网络产品很多,故障现象层出不穷,厂商有时候也有意无意回避一些产品缺陷,给我们挖坑。

我们已经很难了,不要每次出事都让我们背锅,可以嘛?

——全文完——

注:文中小乐为化名。
👇👇👇👇👇

赠书福利来袭啦

联合北京大学出版社为大家送福利

推荐理由:国内首本成体系的kerberos域网络安全教程,填补域网络安全书籍空白。域网络安全非常重要,但是市场上关于域网络安全的图书都是国外引进,并不完全适应我国企业需求,本书则从国内企业的实际需求出发,介绍符合实际的攻防对抗方案,更有参考价值

推荐理由:本书以简单易懂的文字,搭配轻松诙谐的原创漫画,让更多人理解什么是元宇宙的 “宏架构”,了解从原子到比特的逻辑,明白智能合约、数学及NFT之间的关系,用图片解析未来世界,让你轻松走进虚实共生的数字时空,解锁人类新文明,设计属于自己的元宇宙

推荐理由:当前AI图书市场,理论知识与实践经验的脱节,是很多书籍的缺点。本书立足于理论,从实例入手,将理论知识和实际应用结合,目标是让读者能够快速地熟悉人工智能中经典算法

推荐理由:本书知识点全覆盖,案例翔实,实战型强。主要内容包括:立项、需求分析、系统设计、详细参数设计、测试、维护和团队分工合作整个硬件生命周期所有关键节点的内容,把所有的关键节点有序组织起来,高效、高质量地完成硬件开发工作

推荐理由:人工智能被广泛应用和普及,极大地提高了人们学习和工作的效率。而要深入理解人工智能,必须全面理解底层各类机器学习算法的基本原理。只有全面掌握机器学习的基础知识,才能更好地理解、提高和驾驭人工智能的各种应用
截止时间:2022 年 8 月 23 日 16:00  整  
 兑奖时间:2022 年 8 月 24 日 16:00截止 

#留言有礼# 以上的书你喜欢吗?分享一下你想要这本书的理由!或者你对本文的见解,活动截止时小编选出10位幸运小锦鲤,中奖者可获得实体书籍一本,我们包邮赠送~

  

1、社区纠纷不断:程序员何苦为难程序员?

2、该死的单元测试,写起来到底有多痛?

3、互联网人为什么学不会摆烂

4、为什么国外JetBrains做 IDE 就可以养活自己,国内不行?区别在哪?

5、相比高人气的Rust、Go,为何 Java、C 在工具层面进展缓慢?

6、让程序员早点下班的《技术写作指南》

点在看

浏览 15
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报