【会見詳報】ANA障害の原因判明、「世界4例のスイッチ故障がきっかけ、対応も遅れた」
全日本空輸（ANA）は6月13日夕方、国土交通省で記者会見を開き、5月末に国内線システムで発生させた大規模障害の原因について報告した。会見に臨んだANAの長瀬眞（ながせ・しん）専務取締役執行役員は「障害発生からログの分析を続けてきた。このような事態が起こらぬよう再発の防止に努め、信頼の回復に努めたい」と述べ、IT推進室長の佐藤透執行役員が詳細を説明していった（写真1）。 障害が起こったのは、旅客の予約・搭乗手続きや手荷物管理をするチェックイン・システムのうち国内部分。27日未明から朝にかけて処理能力の低下が深刻となり、羽田空港にはチェックインを待つ乗客であふれかえった。結局、羽田では午後3時頃から同6時まで発便をすべて欠航させる羽目に陥った。 原因を作ったのは、チェックイン端末をつなぐためのネットワーク機器だった。障害前日の26日午前9時。朝から2系統あるうち1系統のスイッチが障害の兆候を
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」（同）。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日本で8700台を販売しているが、今回の不具合は初めての事象と聞いている」（ANA広報）。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー
Unwinding Uber’s Most Efficient Service
Illustration by Champa LoA few weeks ago, Uber posted an article detailing how they built their “highest query per second service using Go”. The article is fairly short and is required reading to understand the motivation for this post. I have been doing some geospatial work in Golang lately and I was hoping that Uber would present some insightful approaches to working with geo data in Go. What I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
