ＡＮＡのトラブルから考えること

ＡＮＡのトラブルですが、ニュースによるとＡＮＡは２週間ほど前に、ホストコンピュータと端末を結んでいる「国内旅客系」と呼ばれるシステム６系統のうち３系統の更新を行ったそうです。マスコミによってはソフトウェアと報道しているところもあるようですが、どうやら更新したのはハードウェアのようです。この３系統の処理速度がダウンしトラブルが発生、この３系統をもとの状態に戻したら復旧したようです。

この作業がどうしてやられているかは下記に解説されています。

ＡＮＡ、脱メインフレームで７０億円削減へ
国内線の予約・発券システムをオープン系に全面再構築

この記事にも書いてある通り、今回のトラブルの原因と考えられるハードウェア交換は、既存システムのメインフレームとして使われていた日本ユニシスのITASCA3800という大型汎用計算器を、同社の新型のCS380Dに変更する作業の一環のものと思われます。メインフレームそのものの交換だったのか、あるいはメインフレームの交換は済んでいて周辺機器の交換だったのかはわかりません。

ANAは2003年3月21日にも同様なトラブルを起しています。調査の結果が出ないと原因はわかりませんが、今回のトラブルは現象としては前回のトラブルに似てはいますが、技術的には今回の方がずいぶんややこしいトラブルだったと思われます。今回のトラブルは２６日にも起きていたというニュースも流れています（大事には至らなかったので調査＆様子見にしたということでしょう）。その兆候を見逃したことで、大きなトラブルを未然に防ぐことができなかったということになります。

今回のＡＮＡのトラブルで大迷惑を被った人もたくさんいると思いますが、現在のコンピュータ依存の社会には落とし穴があるということは認識しておいた方が良さそうだと改めて強く思いました。いったん問題が起こると、いくら当事者に文句を言っても無駄です。かえって復旧を遅らすことにもなりかねません。常々自分でもこうした事態に直面したときに、問題を解決できる（自分の目的を果たせる）セフティネットを考えておかなければならないなと思いました。

おそらく、これから多くの企業で、中枢のシステムを入れ替えるという作業が進んでいくものと思われます。団塊の世代の技術者が作り上げてきたシステムが老朽化し、新しい技術を使ったシステムへの入れ替えが進んでいくだろうと思います。そうした中で、私たちの生活に密着した重要なシステムが大きなトラブルを起こす可能性は十分にあります。

コンピュータは作ったプログラムに従うわけですが、プログラムの本数が増え全体が複雑になってくると、簡単なミスが不可解な現象を起こすことが多々あります。こうしたことを解決できるのは、経験豊富なシステムエンジニアなのですが、おそらく多くの技術者が定年退職で現場を去っているでしょう。

コンピュータの利用によっていろいろと便利になっていきますが、システムはKeep it simple and stupid(KISSの法則）を守らないと駄目ですね。

２６日にテレビでアイザック・アジモフ原作の映画「アイ・ロボット」をやっていましたが、これを見た次の日に起ったトラブルだったので、いろいろと考えてしまいました。

さて、自分は結局、ＪＲ東北新幹線「はやて」～特急「スーパー白鳥」で何とか函館に辿り着きました。

家を出たのが１３：００、函館に到着したのが２２：００ですから、今日は９時間ずっと電車に乗っていたことになります。飛行機なら１７：３０にはついているわけですから、４時間半余計にかかったことになります。

でも、４時間半遅れで済んでしまうのもすごいです。ＪＲも確実にスピードアップしています。

新幹線が無理なら、早朝６時過ぎに着く、寝台特急でも良いかなと思っていました。ＪＲで函館まで帰ってきたのは８年ぶりぐらいです。久しぶりに青函トンネルをくぐりました。まぁ、飛行機代も全額もどってくるし、久しぶりにＪＲでゆっくり旅が出来たので良しとします（＾＾）

ところで、今日のＡＮＡのＳＦＣの窓口の女性の担当者の対応はすばらしかったです。チケットのキャンセル手順について自分の要望を伝えたのですが、どうやら通常では対応できない可能性がありそうだったらしく、すぐに上司に確認、自分がどのように対処すれば良いのかすぐに答えが出ました。彼女の対応が親切でなかったら、「ＪＲでゆっくり旅が出来たので良しとします」とは思えず後味の悪い一日になっていたことでしょう。

人気blogランキングへ