Oliverによる
2003年03月01日 16時51分の掲載
３台で多数決を部門より。
３台で多数決を部門より。
kamuy 曰く、 "本日の朝方(2003/03/01 07:10～07:30?)、埼玉にあるという国内の全ての航空管制を司る制御コンピュータが停止したことにより、一時全ての航空機が離陸出来なくなるというトラブルが発生したとのこと。(幾つもソースはあるでしょうが、取り敢えず読売新聞)。テレビなどのニュースから聞こえてくるのは「二系統あるコンピュータシステムが、二系統共に同時にダウンしたらしい」「本日未明、当該システムの一部に変更を実施したらしい」というハナシで、どうもエンバグしたような感じです。
バグ混入というのも何ともお粗末なハナシではありますが、せっかく二系統あるのにその両方を同時に書き替えてしまったこととか、そもそも、今の日本の過密なスケジュールが、たった一カ所にしかない、たかだか二系統のシステムによって運用されていたという事実に、ビックリしてしまいました。
/.J的に、そもそもどのような構成にするべきか、また、今後はどのように対策していくべきか、意見など戦わせてみてはいかがでしょうか?"
毎日新聞の記事のほうがもうちょっと詳しい。
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
だれも言及してないけど… (スコア:4, すばらしい洞察)
ACC の中のひとたちの対応はかなり素晴らしいものであった んじゃないでしょうか。電話連絡による飛行計画書データの 伝達とか、飛行間隔の変更による安全性の確保とか、いくつ かの回避策を非常にスムーズに実施して、システムダウンから 20 分後には制約付きとはいえ離陸の再開に至っているわけで。 また障害情報も適宜に公開されていたと思います。
迷惑をこうむった方々は腹にすえかねるものもあるでしょう が、人命にかかわるレベルの問題でこれだけの危機管理が 手際良くなされたことは、最近珍しいことではないかと。
＜ぼそ＞
それくらい、最近は情けない話が多いと云うことか？
＜／ぼそ＞
…だからといって、事故調査が甘くなってはこまりますけど ね。墜落事故相当の厳しい調査がされて欲しいですね。
--- Toshiboumi bugbird Ohta
航空管制なんぞ全然わからんから、 (スコア:3, 参考になる)
こんな [mlit.go.jp] ページがみっかった。
だれか写真からメーカーが解ったりしないのかな。
# 知合いはSE やってて管制装置の部門にいるが、これの原因じゃないよなあ。
Re:画像見た感じでは…(あたり) (スコア:2, 参考になる)
ここ [nas.co.jp] に論文があります(PDF)。ちょっとぐぐって見つけました。
親コメント
二系統ともダウンというと (スコア:2, 参考になる)
あの時も二系統とも同じシステムだったので、不正なデータ混入などソフト的な障害には対応できなかったような。
ハードウェア障害の対策として同じタイプを複数系統用意するってのはよく聞きますが、
ソフトウェア障害(って言い方でよいのか？)対策として、別種の系を用意してるとこってどんなところがあるんでしょうか？
Re:二系統ともダウンというと (スコア:2, 参考になる)
あるとすると、多数決方式をとる場合ぐらいかと。例えば、ここ [teu.ac.jp]の5.3(a)にある、列車制御のシステムとか。列車制御がそういう構成ということを考えると、航空管制もそうであってもおかしくない気もしますが。
ただ、多数決のために、別種の系を持つと言うことは、ソフトの開発コストが倍になる訳で、普通のシステムではまずやらないと思いますが。
親コメント
毎日がまとめた記事によると… (スコア:2, 参考になる)
航空管制トラブル：事前テスト不十分 新旧プログラム相性悪く [mainichi.co.jp]
過去にも何度か似たようなことをやらかしている割に、その教訓は全然生かされてないようで。
つか、やっぱりシステム設計に問題有り、だよな。
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
親コメント
NHKでやってた解説 (スコア:2, 参考になる)
・自衛隊(防衛庁?)との連携のためにシステムの一部を書き替えた。
・このシステムの書き換えは、主・副の両方を同時に実施しなくてはならない設計であった。
・システム書き替え後、0700から始まる「統計プログラム」なるバッチ処理(?)の開始と共にダウンした。
・システムダウン後、旧来のシステムに書き戻したところ正常に復旧した。
ってコトのようで、思いっきりソフト的な障害のようですね。
新しいシステムに問題があったのか、「統計プログラム」ってのに潜んでいたバグが顕在化したのかは分かりませんが、主・副を同時に変更するしかないシステム設計なんてーアホっぽいところに問題があるような気がします。
(あー、私は素人ですので、「そんなこたぁーない」のかもしれませんし、「現場ではそんなこと言ってられない」ってコトがあるかもしれませんが…)
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:ん (スコア:2, すばらしい洞察)
当然そのデータは弾きますよ。そのデータだけを無効化して他のデータは
取り込み続けるか、そこでファイル取り込みを中止するかは、リカバリ作業の
容易さと、どれくらい時間なら取り込み処理を送らせてよいかによります。
> また複数の連動であれば旧データの送信方法で通信できるモードを
> 入れておけば相手を変更せずにチェックできます。
まぁ言うのは簡単なんだけどねぇ…。
こけるまでに自衛隊から取り込んだデータはどうします?
自衛隊に「システム更新後から AM5:00 までに送ったファイルを古い
ファイル形式で送りなおしてくれ」と言うとしましょう。もし自衛隊側で
流通済のデータにフラグを立てるような処理をしていたら? それを元に
戻す作業を行って、古いデータを送り直さなければならない。
自衛隊システム側では、同じデータを国土交通省以外にも送信して
いるとしたら? 単純にフラグを戻すと同じデータを他のシステムに
対しても送ってしまったりとか (まーそれは設計が悪いんだけど)。
また、国土交通省側でのトラブル中に、たまたま自衛隊側でデータの
更新作業を 2回行った結果、A のデータを B に更新し、さらに C に
更新したとしましょう。自衛隊側では B の情報を 03:00 に fileB
に含めて送信し、、さらに C の情報を 04:00 に fileC に含めて
送信したと。
ところが国土交通省側は「fileB と fileC を旧フォーマットで送り直して
くれ」と言う。でも、そのときの自衛隊側のシステム内ではデータ内容は
C の状態になっている (例えば、A は許可申請、B は許可申請の内容修正、
C は申請取消だと思いねぇ)。ここで B と C の情報を送り直すのは
(作り方にもよりますが) 結構ホネです。
その時点の情報だけでなく、他のシステムへ送信した内容も DB に記録
しておけって? もちろんやろうと思えばできますが、開発ボリューム、
ディスクサイズ、管理工数、バックアップ時間、すべてが増大します。
つまり金がかかると。
送信した fileB・fileC を元に、旧フォーマットに変換するコンバータを
作ればいいって? 作れますけど、当然変換後のファイルを取り込めるか
どうかテストしなければいけない。単に取り込めたら OK じゃなくて、
取り込んだデータに対して各機能が正常に機能するかまで調べなければ
ならない。結構な手間と時間と金がかかります。
仮に旧フォーマットを用意してもらって、旧フォーマット取り込み
プログラム (DB に書き込むプログラム) を動かせたとしましょう。
でも既に DB にも項目を追加してしまっていると。例えば Oracle8
なんかは追加した項目は削除できなかったりします。追加した
項目に NOT NULL 制約なんか付けてたりすると、旧プログラムで
新 DB に書き込むことはできなかったり。
# あ、これはウチのシステムだったらどうなるかってことで。管制
# システムの事情などは全く知りません。
> 実際難しいかどうかが問題ではなくトラブルが発生した場合、
> 復旧可能かどうかが問われているのであって停止してしまうの
> ではダメダメですよ。
違います。すべては費用対効果です。何があっても停止しないシステム、
つまり稼働率 100% を求めるのは現在の人間の技術では不可能です。
稼働率 99% なら年に 87時間はダウンが許されています。これくらい
なら結構安くすむかもしれない。
でも 99.9999% なら (1年に 5分しかダウンしちゃいけない) かなり
金かかりますよ。運用だって複数人の人が 24時間体制で常駐して
いなければならない。保守部品だって全パーツをあらかじめ 2セット
くらいは用意しておかないと安心できない。
どこまでやるかは「そこまで金をかけてシステムを運用する価値が
あるかどうか」で決まります。プログラマも SIer も稼働率 100%
を目指して頑張っていますが、100% はどうやっても無理だってことは
知ってる。だって設計・実装・テスト、すべて人間がやることだもん。
人間がミスしないはずはない。バグがないシステムなんてありえない。
長々と書きましたが結局何が言いたいかというと、
「システムを止めない安全な方法があるなら頼むから教えてくれ。
ただし安上がりな方法をキボンヌ」
ってことで。
親コメント
どこのどいつが (スコア:1)
まさかテスト機に修正版をいれたつもりが本番機にいれちゃったとかいう落ちじゃないよな？
Re:どこのどいつが (スコア:3, 参考になる)
重要なのは、変更後など、それが想定されると時、重要なシステムであればあるほど、これまで使っていたシステムにすぐ戻せる、代替策がある等のリスクヘッジな部分なのではないかと。
最終的には運行支援システムなどなくても管制できるような仕組みはあるわけですが、それではさばけない量のトラフィックを商売にしている、というのが現実ですので、もっと即時対応できる体制で臨むべきだったのでしょうね。
20年前ですが、某社システムで私の会社の別プロジェクトの開発済みパッケージの本番運用をはじめたのですが、
既存システムと一部データ不整合があり、それでも、システムそのものは正常に「エラー表示」をして処理を続行していました。が、数分でそのエラー表示が大量になってしまい、表示処理をし切れなくて、結果、別システムの方、しかも、オンラインシステムがダウンとなってしまった覚えがあります。すぐに旧版から立ち上げなおしたので10分ほどのダウンですみましたが。
＃ちなみに、今回一番の被害者は、突然便名表示が出なくなってビビった管制官でしょう。おつかれさまです。
みんつ
親コメント
webでの運行状況公開 (スコア:1)
友人が羽田で悪戦苦闘（今日、ANAで千歳行き）
そこで、国内線運行状況をのぞいてみたら
エラーばっかし・・・問い合わせが殺到しているの
かしらん。
ちなみに、JALは表示されるのですが全便遅れておりますの
表示だけでした。欠航便が表示されるだけかなりましかと
思いますが。
******* plup "fiction" ********
卒業旅行 (スコア:1)
今の時期は１万円で乗り放題だしね～
卒業旅行シーズンだしね～
このような目に遭遇した人も多いのでは？
脊髄反射 (スコア:1)
# 一時期政府向けシステムも開発してましたよね、あそこは。
# 納入先は富士通だったかな。
-- ラテール部参加者募集中
確認してみます。 (スコア:1)
確認しました。 (スコア:3, 興味深い)
毎日新聞の記事ですが比較的ここ [mainichi.co.jp] が的を得ていると思います。
実は今後の調査結果を確認しなければ解りませんが、
定時処理と新プログラムの相性を確認しなかった可能性
等を指摘しています。
通常空港で管制卓に便名を表示させるARTSと言うシステム等は
バージョンアップ時などは両系に違うバージョンがインストールされ
新バージョンがこければ、瞬時に稼働実績のある旧バージョンに
切り戻す事が出来るようになっています。
今回のFDPシステムの2重化は両系ともに同じシステムを
走らせ2つの処理結果のマッチングを持って信頼性を
保つようなシステムになっているそうです。
その為片系がこけたからと言って瞬時に切り替える事は
出来なかったかもしれません。
しかしFDPはバージョンアップの際に旧バージョンを
保持する事が出来る設計になっているようなので
障害発生時に一刻も早く切り戻す事が出来れば
被害を最小限に食い止める事が出来たかもしれません・・
当然我々はミスのない作業を目指します。
しかし本当に必要なのはお客様に迷惑をかけない事。
今回のようにシステムの設計変更などトラブルが
発生する可能性のある場合、不測の事態が発生した時
如何に短時間で運用を再開させる事が出来るか、
そこに基本があるような気がします。
実際私は某空港で管制卓のキーアサインの全面変更などを
仕切った経験もその作業が途中でトラブった経験もあります。
その時は確かに真っ青になりました。
しかし我々に求められるのはただ震えてるだけの
無能な指揮官ではありません定められたバックオンリミット
までにリトライするか現状に復旧させるかの判断なのです。
動くモノを利用者に提供するそれが私たちの仕事なのですから。
(こんな事を書くとあの時一緒に戦ってくれた仲間たちに
何を偉そうに(笑)と頭を叩かれそうですが・・)
実際私の知り合いの奥さんが実家への帰省の際に
今回の事件に巻き込まれました。
私も一日遅ければ同様に東京から帰れず巻き込まれて いました・・・
業界人として、1ユーザーとして他人事では有りません。
親コメント
Re:もうそろそろ2015年かぁ (スコア:1)
＃単なるフォールトトレランスだとばかり…。
written by こうふう
親コメント
Re:もうそろそろ2015年かぁ (スコア:1)
マイノリティ・リポートがまちがっているとはかぎらないという説。
親コメント
Re:二系統 (スコア:2, 興味深い)
ニュースでちょっといってましたが、このバックアップはシステム復旧に3時間以上かかるときしか稼動しない、ってことだそうです。
今回は2時間で回復したので、伊丹のシステムは使わなかったって言ってました。
システム止まった責任は、それはそれで追及するとして、飛行機の運航に支障が生じたのは運用体制の問題といえるでしょうね。
せっかくバックアップシステムがあっても稼動しないのなら意味なし。
親コメント
電子連動1形は3重多数決回路 (スコア:1)
クロックで駆動し、その出力をハードウエア多数決回路経由で
出力させていました。3重刑の出力が不一致になると、多数の
2重系で動作させ、さらにその2重系で不一致が発生すると出力
停止になるようになっていました。
まあ、64KByteのプログラムなので、ソフトウエアバグを考慮
しなくて良かった時代の話ですが....
親コメント