ANA日本全日空航空公司Oracle 4节点RAC集群性能问题所引发的航空系统故障

 

 

ANA全日空是日本最大的航空公司,亦是世界上少有的五星级航空公司之一。全日空的主要机场位于成田国际机场、东京国际机场、关西国际机场及大坂国际机场。

 

ana01

 

在3月22日上午8:20开始由于系统故障,羽田、大阪以及福冈等地区的机场出现日本国内航线无法办理登机手续的问题。由此,一部分航线被迫取消,大量航班延误。

 

 3月30日、ANAホールディングス(ANAHD)傘下の全日本空輸は30日、22日に発生したシステム不具合を踏まえ、30日付で役員の報酬減額処分を実施したと発表した。全日空の篠辺修社長を1カ月20%、内薗幸一副社長と幸重孝典執行役員を10%の減額とした。写真は都内で2013年1月撮影(2016年 ロイター/Toru Hanai)

 

在ANA的记者会上已经发布了相关事故原因。因为全日本航空的系统故障,导致了刚刚结束节假日连休的机场陷入了混乱状态。

在当日上午11点半左右,系统修复完成。然后办理搭乘手续的业务也终于得以恢复。对此,全日空航空公司表示:“非常抱歉,给大家添麻烦了。”

根据全日本航空给出的数据,受到系统故障影响,羽田机场的航线总计取消116条航班。大约对一万五千人造成影响。

 

QQ截图20160406135309

 

全日空在上个月24号也同样出现了类似的问题,导致全国的机场约30分钟无法办理搭乘手续。

 

具消息人士指出本次的故障是由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致。而并非有网友指出的是ORACLE RAC心跳网络的交换器出现了故障而出现了ORA-29740错误。

 

有日本本土的消息人士指出此次故障时由于ANA的核心业务系统,一个4节点的ORACLE RAC中;由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致,导致其中一个节点出现严重的性能问题。运维工程师在接到系统告警和投诉后进入了慌乱状态,按照既定的故障诊断手册来修复也完全修复不好。于是到处打电话问对应方法,得到的回答也都与手册相同。

 

对于Oracle数据库你是否有这样一本故障诊断手册? 还没有?

下载 《ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册》: http://t.cn/Rq4BzBY

 

日本本土的网友对此次全日空的系统故障吐槽说:

 

这时,像我这样的系统工程师都会发出这样的感叹:”哎呀,出现这样的故障的话,现场估计乱得不得了吧?“(我想现场如今就像祭典一样,,系统工程师们要三天不眠不休进行修复工作。而且就算完成了修复,之后还有一系列的工作……)

实际上,比起影响,我更在意幕后的一些隐情。这时说起来可能有点不太准确,但我想,如今在系统故障现场还是一派繁忙景象吧。系统工程师倒是要多少有多少,但我想还没有哪个项目能像这次大故障一样如此繁忙吧。(受到此次影响的客人们也感到非常麻烦吧。)

现场状况用”祭典盛景“来形容是最好不过了。控制中心聚集了大量人员,几乎动员了公司内部所有战斗力量。再没哪次故障能汇集这么多人才了。(在此进行一系列会议,大家在白板上激烈讨论了故障过程、原因、以及修复对策。)

以往办公室都是比较安静的,但故障时,却是一片异样的繁忙盛景。经历过一次故障,系统工程师的能力可以连升很多级。由于大家目标一致,努力奋进于是就出现了这样的景象。(虽然善后要更加令人头疼……)

由此,这次的主题就是介绍系统工程师现场会遭遇的各种情况。

 

是否是系统供应商的人为失误!?

 

这次4台服务器同时终止的原因可能就是因为人为错误。

无论是硬件或者软件出现问题都不可能造成如此的故障。果然原因只可能是人为失误。报导中提到,“控制四台服务器的设备出现了故障”,可能还误操作了负载均衡器SLB。

果然无论最后是操作系统还是终止系统,最终还是人为使然。

无论对设备以及软件进行怎样的优化,也会由于人的使用方法以及使用顺序错误导致出错。并且,无论如何都需要定期维护,维护的同时也经常伴随着误操作的危险。当然,接触到系统的工作也都有一定的操作顺序,因为都会对其进行反复检查,所以基本不会有问题,但并不是不可能发生。

只要基于人来操作的话,无论如何都是会发生错误的。如果这样的失误重复多次,就会导致如这次一样的大规模的故障。

并不是我反复强调,而是系统的确是无法避免地会出现故障。

当然,我们每天也在为了不再出现这样的情况而努力着,但仅凭现在的技术水平来说,还是必须要人工操作的,所以还是必然会有类似故障发生。

我希望大家能够理解,不理解现状,却一味地抨击系统工程师“不像话”的无知评论家以及无良媒体是多么可恶。我对媒体和评论家这些人一提到就开始批判的态度也是实在没有办法,想说什么就说什么,明明自己没有一点点相关知识。

即使修复了系统故障也不会就此终止

我认为,作为全日本航空的系统供应商应该会非常头疼,希望他们好好努力啊。因为即使修复了故障,之后的善后工作也非常麻烦。

修复了基础层的系统后,应用团队就登场了。由于系统故障,需要确认的问题实在太多了:数据状态如何?现有数据是否完好?是否可以继续进行业务?等等等等。

估计至少得通宵达旦2-3天吧。之前提到过的不可思议的祭典状态还将持续。不仅是修复工作最集中的时候,其他时候系统工程师也必须时刻保持昂扬的战斗状态。

之后,就需要检讨这次故障的对策以及开始道歉了。

虽然我们都认为系统故障是不应该发生的,但还是希望大家能够理解,系统是不可能永远不发生故障的。希望大家做的不仅仅是谴责,也不要认为系统正常运行是理所当然的。但这次的故障影响波及范围实在太广泛了,这也是我们必须反省的。

 

 


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *