IT系会社員ブロガー

某IT企業に勤める40代会社員の雑記帳

ANAシステム障害の真相??

ANAの障害の件、日経コンピュータの記者の節穴眼が更新されましたね。

itpro.nikkeibp.co.jp

 

ちなみに前回、この障害について私が思うことを書いたのは以下。

breakthrough1020.hateblo.jp

 

日経コンピュータ日経BP)の記事は何を突っ込んだらよいのやら...

 

そもそもシステム構成図ですが、ストレージは、おそらくFC(FiberChannel)なのに、サーバとストレージのFC間に、今回の障害原因であるシスコのイーサネットEthernet)スイッチであるCatalyst 4948Eが接続されている。

障害原因もOracle RACの Inter Connect で利用しているCatalyst 4948Eと書いているのに大丈夫?

日経BPのこの記事を書いた記者は、ユ◯シス「エアラインリザベーション」を読む前に、Oracle RACの仕組みくらい理解したら良いと思いますよ。RACなんて、10年以上も前から存在する枯れた仕組みです。

 

記事には経緯がつらつらと書かれているが、そもそもシステム構成さえ理解せずに聞いているのでメチャクチャ。

なので、おそらく正しいだろうと思うのはANA広報の言葉から判断すると、

  • 「完全に停止したわけでなく、動作が不安定になった」
  • 「(取り寄せた代替機は)同一型番、同一ファームウエア」
  • 「(予備機は)事前(の健全性の)確認ができない状況だった」
  • 「(故障機を予備機ではなく代替機と)推定交換」

これが正しければ、Oracle RACのInter Connect は完全に冗長化されておらず、Catalyst 4948Eは、もしかするとシングル構成だった可能性もありますね。

日経BPの記者は、なぜそこを聞かないの?

 

  • 「本番環境と同等の作りにしてあるテスト環境に(故障機の?)スイッチを持ち込んでテストしたところ、異常が再現した。シスコが原因を特定した」

これが一番理解不能。「動作が不安定」な状況が、何の処理も実施されていない、殆どデータが流れていない環境で「異常が再現」するはずがない!

日経BPの記者は、そこをなぜ掘り下げない!

読者が一番聞きたいのはそこです。

 

  • 「スイッチが故障シグナルを出さない場合でもDBサーバーからスイッチ故障を検知できるよう改善した」

Inter Connect経由でのICMP(Ping)監視をJP1かMC/SGで設定しただけでしょ。

MC/SGで検知しても仕方ないので、おそらくJP1でしょう。

そんなことは再発防止策でなく、そもそもやってなかったことが問題で、根本原因は別。

 

  • 「世界初の事象であり、機器固有の問題である可能性が高いという報告を受けている」

”世界初”、よく聞く話しですね。"機器固有の問題"、これもよく聞きますね。

メーカお決まりのトークスクリプトですね。

日経BPの記者は、スイッチのファーム(IOS)が最新だったかをなぜ聞かない?

 

そもそもANAは2007年5月に同じシスコのスイッチでハングアップして障害を起こしているのに、教訓を得られていないのですね。

「メーカーによると同様の問題は世界で4例しかない。スイッチが完全にダウンしなかったため対処が遅れた」

4例もあるのに...

itpro.nikkeibp.co.jp

 

「世界初」「日本初」「過去に発生したことがない」「過去に事例がない」バグ情報を共有する「世界初のバグ情報共有UG(ユーザグループ)」があります。

シ◯コだけなく、ハードウェア(H◯、I◯Mなど)、ソフトウェア(◯racleなど)を網羅しており、参加企業は、それぞれの「世界初」のバグ経験をすると、その情報を共有します。(紹介制、メーカは参加不可)

 紹介制なので、入会されたい方は、ご連絡ください(笑)

 

判明、ANAシステム障害の真相 」って、日経BPの記者は、もっとIT勉強した方がよいよ。必死で記事の修正を繰り返しているようですが。

日経BPにお金を払っているのがバカらしくなってくるな。