2016年3月22日に、全日空・ANAでのシステムトラブルがあり、約390便が欠航し、7万人への影響を受ける。 その翌週、2016年4月1日に、今度は日本航空・JALでもシステムトラブルが発生。
「重量計算システム」トラブル
今回の「重量計算システム」とは違うと思うが、 先日、沖縄行きの日本航空・JAL便を利用した際、 「重量計算」不具合で、出発が遅れたことがある。
このときは、飛行機に搭載されているシステム不具合のようで 重量バランスが計算できないので、離陸できないとのこと。 結局、30分ぐらいして、出発した。
機材トラブル
機材トラブルといえば、 20年ほど前にアメリカに行った時の話。
ノースウェスト航空(デルタ航空と合併)に搭乗した時の話。
そのときは、日本航空・JALのマイル修行なんてしておらず、 幼い頃の経験から、日本の航空会社よりも、外資航空会社を愛用していた。
席についてもまったく動き様子がなく、 どうしたのだろうと思った頃、
「システムトラブルで再起動をしている」
という機長からのアナウンス。
その後、しばらくしても、動かない。
そして、ふたたび機長からのアナウンス。
「基板を入れ替えるので、今エンジニアを呼んだ」
なにやら改修工事が行われ、 それで、ようやく出発できた。
もう20年ぐらい前の話なので、 正確な時間などは忘れてしまったが、 おそらく1−2時間ぐらいは、遅れたのではないか。
金融のシステムは「データ加工工場」
今回のANAのシステムトラブルの原因は、ネットワークスイッチの故障。 そして、日本航空・JALは、データ滞留(そもそもソフトウェアの不具合？)。
それを見て、昔新卒で入社した、シンクタンクのITコンサルタントの仕事を思い出す。
クライアントは、金融大手。
あまり細かいことは言えないし、一般的なことになるが。
金融のシステムには、平日の昼間の時間帯は、 お金の預け入れや、金融商品の購入・売却など、 かなりの量のデータが流れている。
たとえば、株式の買付・売却などは、 取引所などから注文出来データが来て、 それを上流から下流へ流していき、関連部署のDBに反映されていく。
それを見て、「金融」の内側というのは、データ加工工場なんだなと思った。
今は、だいぶ変わっているかもしれないが、 動いているシステムの中身は、ロジック的に非常にシンプルな作りになっていて、 基本的には、データベースの書き込み・参照しかしていない。 当初思い描いていたよりも、原理が単純で、拍子抜けしたのを覚えている。
システムの「可用性」
システムにおいて、重要なのは、いかに「可用性」を高めるかということ。 万が一に備えて、システムの冗長性というのを用意する。
このサーバーがダメになったら代替機で運用、 メインのネットワークが落ちたら、別のネットワークとか。 そのときの最終手段は「電話で行う」というがあり、お客さまの注文処理を優先させることだった。
システムダウンして、業務が行えなかった場合、 たしか、クライアントの金融大手にペナルティを払い、それも億単位だったかと思う。
システムが動いているかどうかの監視体制もすごく、24時間監視しているし、 そのための監視システムまで作ってしまい、商品化までしてしまった。
UNIXをかじったことがある人ならば、その監視システムの中身にびっくりすると思う。 ぼくは、その単純な仕組みにビックリし、そんなの監視システムとして製品になってしまうのかと感心した。
旅行業におけるシステム
よくわからない話の展開になったが、 JALの「重量管理システム」トラブルの中身を見て、こんなことを感じたという話。
移動という手段では、
自転車 < 車 < 電車 ＜ 飛行機 < 宇宙船
という順に、重要度が増していき、 バックアップシステムを用意したり、監視をする人たちも増えていき、 その移動を支えるコストは増大する。
社会の中にあるシステムの影響度合いというのは、様々である。 このブログもそうだが、止まっても、それほど害がないものと、 業務系のシステムのように、被害が大きいものもある。
昔、とあるIT開発会社の社長の話を聞いた際に、
「生命にかかわるシステムの受託開発は受けない」
ということを言っていた。
そのときは、たしか学生のときに聞いていて、「なんでだろう？」という感想だったが、 社会に出てみると、その意味がわかるようになる。
今回の場合、飛行機の旅客のみなさんへの被害がかなり大きい。
いかに早く復旧させるか、あるいは、代替手段で対応するか、ということだと思う。
このブログ内の「マイル修行」特集ページはこちら↓
マイル修行日記： http://www.8888km.net/p/blog-page_1.html
3ヶ月でノンステータス会員からJGCプレミア会員に達成
No Comments