ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

BCM・BCP苦労話コミュのANAシステム障害は BCMの対象?BIAは?

  • mixiチェック
  • このエントリーをはてなブックマークに追加
ANA5月27日のシステム障害で、改善対策に3億円、欠航の減収7億円以上

日経の情報から集約すると経緯は以下のようだった。
本26日午前9時 原因となった2系統あるうち1系統のスイッチが障害の兆候を示し始め、通信が断続的に途絶え始めた。メモリーが物理的に故障したが、完全にダウンしなかったため対処が遅れた(世界で4例しかない故障、メーカー談)。
27日未明 スイッチの状況が悪化し、通信がほとんどできない状態。結果メインフレーム側とスイッチ側のゲートウエイが負荷で通信停止。さらに、ゲートウエイのメインフレーム側のプログラムバグとスイッチ側の能力不足が追い討ち。
ANAの改善策は、(1)監視要員の増強、(2)スイッチのメモリー障害を自動で検知する機能の搭載、(3)スイッチの通信経路を2重化から4重化へ強化、(4)ICSのプログラム改善、(5)ATCPの能力増強。
また、長期的な対策として、バックアップ・システムや障害時の運用を根本的に見直す。今回のトラブルではバックアップを使っていない。本

exclamationシステム障害って、骨折が不運に重なり複雑骨折になるケースが多い、後から原因が判明すると。想定外の事態が発生すると、潜在問題が表面化する。しかし、不運だけでは片付けられない。

衝撃BCMから考えると、果たしてこれはBCPの対象なのであろうか? システムのバックアップを使うか、使わないがBCPかな。 部分的BCPくらいだし、もともとシステムの運用上、システム障害の対策が当然策定してあるから、その対策が起動して、回復を待つかバックアップを使うか、決めることになるのではないでしょうか。
電球もう一点考え直したいのが、BIAのプロセス再評価。このケースは、7億円の減収に3億円の対策費、で実質は10億円のインパクト。 仮にBIAの中にこのケースの想定つまり一日予約システムが停止する、があるとすると、インパクトの金額はいくらに決めていただろうか? 普通は7億でしょけど、欲をいえば10億の計算が事前に出来るとすばらしいですね。 でもやっぱりそりゃ無理ですね。

ちなみ最近のシステム系障害
6月10日 8:30 社会保険庁の年金システム障害
5月23日 JR東海とJR西日本の新幹線ネット予約サービスがダウン。
5月22日 6:30 JR東日本インターネット予約サービスがダウン。
5月12日 AM totoの販売システム障害
4月11日 13:41-21:51ゼロバンク(サークルKサンクスの子会社、ゼロネットワークスが提供するATMサービス)でATM障害
3月18日 早朝PASMOでトラブル
3月13日 りそな銀行と埼玉りそな銀行,ネットバンクに障害

コメント(4)

掲示板はあとから編集できないのですな。
上記トピック訂正です。がまん顔

欠航による減収金額は4億円でした。合計が7億円です。
すみません。
ある記事で、ANAとNTTの障害について以下(省略)があった。
映画ANAのケース 経緯
国内旅客システムでは,バックアップ(B/U)を使わなかった。システムが完全にダウンしていなかったため、空港のチェックイン端末からの入力が細々と処理されていた。
早い段階でB/Uに移行してれば良かったのだが、4年前にB/Uからメインに戻すプロセスで多重のトラブルがあった。【おそらくこのトラウマが、移行を躊躇させたのではないか。】実際、障害が大規模化した時点で,既に多くの旅客がメインのシステムでチェックインを済ませていたので、もしこれらがB/Uで処理されていたらそれらをメインに戻す際のトラブルの可能性を危惧したのかもしれない。
映画NTTのケース 経緯
「ひかり電話」がNTT東西間で通話できなくなった件では,バックアップが起動しなかった。実際にサーバーを運営するNTT東の子会社NTT-MEのB/U起動の設定はハードの故障に規定しあり、ソフトの障害は想定外だった。
一方NTT東の「フレッツ」のケースは、B/Uそのものが原因だった。一つのネットワークを構成するルーターの数が限界を超えてところに1台のルーターが故障したので、修理のため一時的に切り替えたバックアップ回線からメインへの切り戻しに伴って,エリア内のほとんどのルーターにおいてIPパケットの“行き先設定”の変更が発生。ルーターに過大な負荷がかかり,フレッツ網が麻痺した。

電球教訓
1 一つは障害の影響範囲を極小化することだ。
ANAは過去のトラブルを契機に,障害が全システムに及ばないようにしていた。
NTT東も,波及範囲の限定とルーターの負荷軽減を図ろうとしていた矢先だった。ひかり電話の東西間接続についても,1台の制御サーバーでの運用を改めるなどバックアップの強化を検討しているという。
2 もう一つが,あえて「止める」ことではないだろうか。
ITへの依存度が高まる中,24時間365日止めることが難しいシステム(NTTやANAや金融業)は世の中にたくさんある。ここまで大規模化してしまったネットワークやシステムは,いったん動き出すと止めるのは難しい。

 しかしバックアップが実環境できちんと動くのか,事業継続計画(BCP)の観点からバックアップが業務と連携できているのか,メインのシステムを止めて定期的な確認が必要ではないだろうか。もちろん、メインを止めるにも一定のリスクが伴うし、作業のコストもかかる。ただ、コストだけ見れば1回の大規模障害による影響に比べれば軽微なものだ。
 止める必要があるかどうか、一番分かっているのは現場かもしれない。ITやサービス部門の社員,委託先のITベンダーが障害の予兆を発見したら,大規模トラブルに至る前にネットワークやシステムを止めることを進言する“勇気”も必要だろう。

むかっ(怒り)スロー人は、システムのBCP構築の問題点が露呈したのではないかと思います。B/Uに移行することはある程度準備はされていると思うのだが、実はB/Uからメインに戻るところまでは準備はそれほど出来ていない状況が原因だと考えます。
なぜなら、システムは従来コンティンジェンシー・プランを準備してきたわけです。つまりバックアップがあれば、いざという時にはB/Uでシステムが動くので大丈夫、だったわけです。もちろんそれでよかったわけです。
しかし、BCPではB/Uだけですまないのが実情です。記事の提案にもあるが、実際に止めて業務と連携した定期的な訓練をすることが要求されているわけで、そのためには統合的なBCPが必要です。ITもB/Uから脱却して、BCPに移行する思考の改革が必要です。
ちっ(怒った顔)その上で、はじめて「止める勇気」がテーマになります。今の状況でいきなり止める勇気を発揮すると、当然業務や経営陣から猛反対される結果になります。
スロー人の経験からいえば、少しずつ訓練を始めることで、実際に止めることの意義が浸透し始めます。止めるかどうかの議論の段階では予想もしない効果が発見できるのですが、経験では。

長文書くのは大変ではなかったですか?大変内容が濃く、興味持って読まさせていただきました。ありがとうございます。

車、電車、船、飛行機などの人を乗せるものは、定期点検が義務づけされています。
なぜなら何かあったら人命に関わることですから。

ITが巨大化し、無しでは社会のシステムが動かなくなるまでになった現代において、巨大化したシステムにおいて、日々のメンテナンスはもちろん必然ですが、やはり定期的な大きなメンテナンス、補修は必然だと私は思います。巨大化したからこそ。

システムを止める勇気。私もその通りだと思います。これこそBCMが活かせるものだと思います。

追伸:今日、BCAOの勉強会に参加しました。次回において、リスクマネージメントにおいての発表をすることとなりました。
まなぶさん
ありがとうございます。長文は確かにチョット大変でした。
こういう実際のケースから学ばないと、前には行かないですよね。
それに本心は他人の失敗だから、冷静に評価できます。これが自分の会社の出来事だと、とても冷静には考えられません。


BCAOの発表がんばってください。リスクマネージメントはいつかはテーマにしたい話題です。良かったら、この掲示板のテーマにさせてください。あとでメッセージでください。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

BCM・BCP苦労話 更新情報

BCM・BCP苦労話のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。