国内の航空管制が一時全停止 138
ストーリー by Oliver
3台で多数決を 部門より
3台で多数決を 部門より
kamuy 曰く、 "本日の朝方(2003/03/01 07:10~07:30?)、埼玉にあるという国内の全ての航空管制を司る制御コンピュータが停止したことにより、一時全ての航空機が離陸出来なくなるというトラブルが発生したとのこと。(幾つもソースはあるでしょうが、取り敢えず読売新聞)。テレビなどのニュースから聞こえてくるのは「二系統あるコンピュータシステムが、二系統共に同時にダウンしたらしい」「本日未明、当該システムの一部に変更を実施したらしい」というハナシで、どうもエンバグしたような感じです。
バグ混入というのも何ともお粗末なハナシではありますが、せっかく二系統あるのにその両方を同時に書き替えてしまったこととか、そもそも、今の日本の過密なスケジュールが、たった一カ所にしかない、たかだか二系統のシステムによって運用されていたという事実に、ビックリしてしまいました。
/.J的に、そもそもどのような構成にするべきか、また、今後はどのように対策していくべきか、意見など戦わせてみてはいかがでしょうか?"
毎日新聞の記事のほうがもうちょっと詳しい。
だれも言及してないけど… (スコア:4, すばらしい洞察)
ACC の中のひとたちの対応はかなり素晴らしいものであった んじゃないでしょうか。電話連絡による飛行計画書データの 伝達とか、飛行間隔の変更による安全性の確保とか、いくつ かの回避策を非常にスムーズに実施して、システムダウンから 20 分後には制約付きとはいえ離陸の再開に至っているわけで。 また障害情報も適宜に公開されていたと思います。
迷惑をこうむった方々は腹にすえかねるものもあるでしょう が、人命にかかわるレベルの問題でこれだけの危機管理が 手際良くなされたことは、最近珍しいことではないかと。
<ぼそ>
それくらい、最近は情けない話が多いと云うことか?
</ぼそ>
…だからといって、事故調査が甘くなってはこまりますけど ね。墜落事故相当の厳しい調査がされて欲しいですね。
--- Toshiboumi bugbird Ohta
航空管制なんぞ全然わからんから、 (スコア:3, 参考になる)
こんな [mlit.go.jp] ページがみっかった。
だれか写真からメーカーが解ったりしないのかな。
# 知合いはSE やってて管制装置の部門にいるが、これの原因じゃないよなあ。
画像見た感じでは… (スコア:1)
恐らくメインシステムは日電ベースかな?
あと、ODPのCRTの球はソニー特注の正方形ブラウン管じゃなかったかな?
/* Kachou Utumi
I'm Not Rich... */
Re:画像見た感じでは…(あたり) (スコア:2, 参考になる)
ここ [nas.co.jp] に論文があります(PDF)。ちょっとぐぐって見つけました。
Re:画像見た感じでは… (スコア:1)
ソフトの改変によるデグレートで二重系が落とせるなら、
クラックされてもアウトだな…。ダイハードが現実になっ
てしまうようなことがないようにしてもらいたいもんです。
もしかして、テロリストの研究対象にならんように、
コンピュータの輸出規制って中古機にこそ必要か!?
#なんとなく関係者が近めにいそうな気がするのでID
みんつ
二系統ともダウンというと (スコア:2, 参考になる)
あの時も二系統とも同じシステムだったので、不正なデータ混入などソフト的な障害には対応できなかったような。
ハードウェア障害の対策として同じタイプを複数系統用意するってのはよく聞きますが、
ソフトウェア障害(って言い方でよいのか?)対策として、別種の系を用意してるとこってどんなところがあるんでしょうか?
Re:二系統ともダウンというと (スコア:2, 参考になる)
あるとすると、多数決方式をとる場合ぐらいかと。例えば、ここ [teu.ac.jp]の5.3(a)にある、列車制御のシステムとか。列車制御がそういう構成ということを考えると、航空管制もそうであってもおかしくない気もしますが。
ただ、多数決のために、別種の系を持つと言うことは、ソフトの開発コストが倍になる訳で、普通のシステムではまずやらないと思いますが。
Re:二系統ともダウンというと (スコア:1)
でもって維持費は倍以上(汗
毎日がまとめた記事によると… (スコア:2, 参考になる)
航空管制トラブル:事前テスト不十分 新旧プログラム相性悪く [mainichi.co.jp]
過去にも何度か似たようなことをやらかしている割に、その教訓は全然生かされてないようで。
つか、やっぱりシステム設計に問題有り、だよな。
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:二系統ともダウンというと (スコア:1, 興味深い)
もっとも、複数のバージョンが混在してる状況はオペレーターの操作ミスの原因となりかねないので、運用者的にはあまり歓迎されないかも。
やっぱあんまり現実的じゃないか… (スコア:0)
金かかるけど。
安全制御で考えるハード障害対策 (スコア:1, 参考になる)
現在、コンピュータを高信頼化する一般的な方法は、次のような
ものである。ハードウエア故障については主として独立2重系を
用いている。
最も厳密な2重系は、異なったメーカーのCPUを同期させてバス
ラインの段階でデータの照合チェックを行う密結合のもであり、
最も疎な結合の2重系は、異なったメーカーのコンピュータで異
なったソフトウエアを用いて同じ入力で実行させ、最終的な出力
を照合させるものである。どちらの場合も、出力が異なった場合
の後の処置は、そのシステムによりそれぞれ異なる。
#独立3重系(ソフトもハードも異なる3系統)というものまでは見たことがある..
Re:安全制御で考えるハード障害対策 (スコア:1)
もちろん直接見たことはないですが。
Re:安全制御で考えるハード障害対策 (スコア:1, 興味深い)
そのうち一つは人間系ですね。
Re:安全制御で考えるハード障害対策 (スコア:1)
宇宙線や振動などの影響で故障しやすいこと、故障しても修理ができないこと、故障したら地上に帰れなくなること等を考えたらそのくらいは当然ですね。
参考: GUIDANCE, NAVIGATION AND CONTROL [nasa.gov]
Re:安全制御で考えるハード障害対策 (スコア:1)
多重化されていてもアウトという場合がありますが。
TVのニュース(TBS)によると、防衛庁とのリンク部分の
修正で問題があったようで。
******* plup "fiction" ********
Re:二系統ともダウンというと (スコア:1)
Re:二系統ともダウンというと (スコア:1)
できれば乗員乗客も。
料金? いやん。
〜◍
NHKでやってた解説 (スコア:2, 参考になる)
・自衛隊(防衛庁?)との連携のためにシステムの一部を書き替えた。
・このシステムの書き換えは、主・副の両方を同時に実施しなくてはならない設計であった。
・システム書き替え後、0700から始まる「統計プログラム」なるバッチ処理(?)の開始と共にダウンした。
・システムダウン後、旧来のシステムに書き戻したところ正常に復旧した。
ってコトのようで、思いっきりソフト的な障害のようですね。
新しいシステムに問題があったのか、「統計プログラム」ってのに潜んでいたバグが顕在化したのかは分かりませんが、主・副を同時に変更するしかないシステム設計なんてーアホっぽいところに問題があるような気がします。
(あー、私は素人ですので、「そんなこたぁーない」のかもしれませんし、「現場ではそんなこと言ってられない」ってコトがあるかもしれませんが…)
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:NHKでやってた解説 (スコア:1, すばらしい洞察)
> 問題があるような気が
ところが実際やってみると、結構難しいわけで。
例えば外部 (自衛隊) とのインタフェースはファイルで行っていると
しましょう。今回、流通する項目を 1つ増やしたとしましょう。
で、正は項目追加に対応したと。副は正が落ちたときに備えて
修正しないと。
さー、正が落ちました。どうしましょう。
副でファイルを取り込もうとしても、こっちはインタフェースが
違うので取り込めません。自衛隊に古い形式で送ってもらう?
それなら当然自衛隊側も新インタフェースと旧インタフェース
の両方を送れるように準備しておかなくてはいけません。
これで手間が 2倍。
また、単純にシステムが A、B、C の機能を持っていて、今回 A'、B'、C' に
機能強化したとします。A' がこけたら A に戻せるようにした場合、A、B'、C'
という組合せになります。その組合せで動くかどうかテストをやって
おかなければならない。
でも事前にどこがこけるかなんてわからないから、A+B'+C'、A'+B+C'、
A'+B'+C、A+B+C'、A+B'+C、A'+B+C のテストもやっておかないと。
当然正常に移行できた場合の A'+B'+C' もやっておく必要があります。
それができないなら全体を戻す (A+B+C にする) わけですが、
同時に自衛隊側のシステムも戻さないといけない。多分他にも
連係しているシステムはたくさんあるでしょうし、自衛隊の方に
関連しているシステムでも元に戻さないと。そして元に戻すのに
一体何時間かかることやら。
そのまま復旧作業を続けた方が早いなんてことになるかも。
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% はどうやっても無理だってことは
知ってる。だって設計・実装・テスト、すべて人間がやることだもん。
人間がミスしないはずはない。バグがないシステムなんてありえない。
長々と書きましたが結局何が言いたいかというと、
「システムを止めない安全な方法があるなら頼むから教えてくれ。
ただし安上がりな方法をキボンヌ」
ってことで。
Re:ん (スコア:1)
> ただし安上がりな方法をキボンヌ」
今回もそうですけど、運行が止まるのはぜんぜんマシだと思います。
システムのバグがトリガになって死人がでることだけは防げるようになってて欲しいです。
そこはコスト削減って言われると、うすら寒いですよね。
-- yuno
Re:ん (スコア:1)
再開が早かったのはバグが直ったからなのだろうか?
前のシステムに戻したからなのだろうか?
ちょっと気になる
バグが直ったというのであれば素早い再開ってのはちょっと怖いかも
Re:ん (スコア:1)
参考資料 [srad.jp]
#続報をまだ見てないので、どの程度本当なのか分かりませんが…
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:ん (スコア:1)
ご指摘ありがとです。
そっか 前の奴に戻したんだ…
とりあえず安心かな
でも、修正版リリースしてまたコケたら…
せっかくだから 事前にリリース日発表してほしいもんだ
Re:ん (スコア:1, すばらしい洞察)
どう考えても、マニュアルがあったから7:30から一部運行再開が出来たんだと思うんですけど・・・。
というか、プロトコルの問題なのか?
バッチの統計処理って所から想像するに、多分デッドロックじゃないかなと思うけど。
Re:NHKでやってた解説 (スコア:1)
>0700から始まる「統計プログラム」なるバッチ処理(?)の開始と共にダウンした。
これは午前7時のことですね。時刻表ライクな書き方ですね。
Re:NHKでやってた解説 (スコア:1)
この話のとおりだったら、テスト不足と言うより、変更が影響する範囲をそもそも見誤っていた (本来なら統計処理プログラムも変更しなければいけないのに気づいていなかった、ゆえにテストからも除外されていた) って感じでしょうか。
どこのどいつが (スコア:1)
まさかテスト機に修正版をいれたつもりが本番機にいれちゃったとかいう落ちじゃないよな?
Re:どこのどいつが (スコア:1, すばらしい洞察)
しててもトラブルが出るときは出る。
結局は、どうゆうテストをしたか。
または、どうゆうテストしか出来なかったか。
いくらテストしたって不充分な方法なら意味が無い。
システム的な条件で、完璧なテストが出来ない場合だって有る。
Re:どこのどいつが (スコア:1)
場合によっては首にもなるでしょう。
# 言い訳にはなりませんよ。
元のコメントも、言い訳で使ってるのではなく、
テスト項目の洗い出しには、気をつけろよと、
言っているのではないでしょうか ?
Re:どこのどいつが (スコア:3, 参考になる)
重要なのは、変更後など、それが想定されると時、重要なシステムであればあるほど、これまで使っていたシステムにすぐ戻せる、代替策がある等のリスクヘッジな部分なのではないかと。
最終的には運行支援システムなどなくても管制できるような仕組みはあるわけですが、それではさばけない量のトラフィックを商売にしている、というのが現実ですので、もっと即時対応できる体制で臨むべきだったのでしょうね。
20年前ですが、某社システムで私の会社の別プロジェクトの開発済みパッケージの本番運用をはじめたのですが、
既存システムと一部データ不整合があり、それでも、システムそのものは正常に「エラー表示」をして処理を続行していました。が、数分でそのエラー表示が大量になってしまい、表示処理をし切れなくて、結果、別システムの方、しかも、オンラインシステムがダウンとなってしまった覚えがあります。すぐに旧版から立ち上げなおしたので10分ほどのダウンですみましたが。
#ちなみに、今回一番の被害者は、突然便名表示が出なくなってビビった管制官でしょう。おつかれさまです。
みんつ
Re:どこのどいつが (スコア:1)
ただ、テスト項目なんて、疑い出せばどこまでも肥大化するんで、ほとんど偶然が上手く重なって無事故で済んでるだけってことも多いんですけどね
だから、本音では、元ACのコメントには賛同なんですが、一般的にはその本音は言い訳として処罰されるのが常なのでね
Re:どこのどいつが (スコア:1)
システムズ アプローチ という考え方からすれば、当事者個人の首を飛ばしても何の「解決」にもならんので、
そんなことに現抜かす暇があったら、「解決」策を考えましょうね、という話になるようです。
つまり、再発防止のために考えたり調べたりすべきことは山のように有るだろうね、と。
そういうことを判ってない古い組織は、今日も「責任」者の首を飛ばして暫しの安心感を得るのでしょうね。
その失敗から学べるはずだった情報をみすみす捨てて。
ああやだやだ。なんと非科学的な…
Re:首切りしないと (スコア:1)
だったら尚のこと、クビ切り即適切、でもないでしょ。
>首切りしないと 結局は『原因追求する必要は無い』となってしまうんで
それは「やりかたが」馬鹿だからでは?
クビ切りしないのと追求しないのとをイコールにしてしまう「やりかた」が。(体制と言い換えてもいいかも。)
責めるべきはそれのほうでは?
責めるために必要な知能(笑)を持ち合わせていない集団だというなら、その後どうなろうが自業自得だし。
>誰も責任をまともに取らなかったから、経済的に立ち行かなくなって来ている国の人間なら解っている事かと思ったが。
クビを切るべき奴を未だ切っていない問題と、
クビを切ってもしょーがない奴を早々に切ってしまう問題とは、
また別なのでは?
それぞれが別個の現場で生じている問題なのだから、一緒にならない。
大臣だか官僚だかにはクビ切ったほうが良いんだろうなと思う奴は(俺から見ても)そりゃ居るけど、
それは「技術的」要請として、なんだよね。
こいつに「任せても無駄or逆効果」だから降板してくれよ、という感じで。
だって、狭義(?)の「責任」者つまり旗印を取り替えただけじゃ、
また同じ失敗になるだけかもじゃん。
てゆーか経済云々についてはまさにその慢性的な状況を呈してるわけで。
#大きな一発の失敗の「責任」者は、後で教訓を得るために、捨てないほうが良い場合がしばしばあるのだろう。
#一方、大きくない(?)失敗を慢性的に続けてる「責任」者は、本当に駄目なのだろう。参考にもならなかろう。
ま、経済については、単純に「こいつは駄目だ」と思った"瞬間"に即決でクビ切りをするだけだと、
日本全部が程なく「そして誰もいなくなった」になるのが、オチだろうな。
まさか不景気の責任を取るに相応しい決定的な少数の技術的キーマンが居るわけじゃなかろうから。
むしろ「キーマンを倒せば解決」という幻想に囚われるほうが、非生産的というか危険というか。
だからこそシステムズアプローチには価値が有るわけで。
それとも完全放任自由経済で行く?
うまくバランスするかそれとも全員が程なく討ち死にするかは知らないし、
全員死なないまでも「かなり多くの」人が不幸になるかどうかも知らないけど。
#貧富の差って奴ね。そして貧すれば貪する。犯罪だかテロだかが跋扈し…
Re:どこのどいつが (スコア:1)
それに対するコードの正誤って部分は抑えられるかも知れませんが
仕様に付いてのテストでは、それなりに肥大化する傾向があるかと思います。
ただ、今回の件は「修正バージョンを入れたら全体が止まった」って
感じの様ですんで、テスト不足の感は否めないかと思いますが。
無茶な納期を押し付けられたりってのは良くある話のような気もするし
そうすると仕様定義とテストに皺寄せが来るような気がします。
気持ちはわかりますが (スコア:1)
精度や仕事の質が問題になるのは最初から分かりきっているのですから(それはどうしてもお国柄が出てきます)、それに対する対処は単純なような気がしますが、どうでしょうか。
普通一般の日本人は想像もしないような思想の元に、彼らの多くは労働しています。そんな彼らを理解しようと努力するのがまず先決だと思います。
又、それは自分の部下に良い仕事をしてもらう事と何も変わらない事です。
#「本当」に気持ちはわかるのですが
webでの運行状況公開 (スコア:1)
友人が羽田で悪戦苦闘(今日、ANAで千歳行き)
そこで、国内線運行状況をのぞいてみたら
エラーばっかし・・・問い合わせが殺到しているの
かしらん。
ちなみに、JALは表示されるのですが全便遅れておりますの
表示だけでした。欠航便が表示されるだけかなりましかと
思いますが。
******* plup "fiction" ********
卒業旅行 (スコア:1)
今の時期は1万円で乗り放題だしね~
卒業旅行シーズンだしね~
このような目に遭遇した人も多いのでは?
大当たりの出張 (スコア:1)
行先と航空会社によっては最大3時間の遅れと言ってましたが、私が乗ったJAL福岡-->羽田は40分+チェックインした乗客の乗り遅れで40分の計80分の遅れですみました。
空港ロビーでNHKニュースを見て詳細(?)を知りましたが、某所に収めた製品の不具合対策で出張していた身としては、他人事ではないとゾッとしました。
# 昨日いきなり現地から呼び出されて出張したけどID
----tm-hal-----
我々はM$だ
お前達の知識と技術を吸収し、お前達の企業を買収する
抵抗は無意味だ
ただ今帰ってきました (スコア:1)
朝一(7:10発)にのって最終(20:10発:いずれもスカイマーク)に乗りましたが。。。
離陸直前に、飛行機内にアナウンスが流れ、私は「あー、『お客様のお呼び出し』とかかなー」と思ったら、「7:05に、管制塔のプログラムが全国的にダウン」と言われて、思わず笑っちゃいました。
その後、30分ほど経っても復旧しなかったので「携帯を使っても構いません」のアナウンス。これで本当に見通しが立たない重大な出来事が起こったんだな、と感じました。
帰りの羽田は年末年始のような感じでした。ダイヤはむちゃくちゃ、ころころ搭乗口が変わっていましたし、払い戻しなども列が出来てました。
余談ですが、帰りの羽田に向かう途中、山手線の人身事故に遭遇してしまいました。
きっと、今日、私が東京に行ったことが原因なんだろう、と思います。みなさん、すいません。
Re:卒業旅行 (スコア:1)
3月1日のANA一日乗り放題 [ana.co.jp]ですね。私は飛行機ヲタなので今日は一日乗り放題を使って東京→熊本を往復(行って、同じ飛行機で帰ってくる)したのですが、定刻の4時間遅れで大変でした。
私は単に同じ飛行機で帰ってくるだけだったのでそれほど問題なかったのですが、一日乗り放題を活用しようと複雑な乗り継ぎプランを立てていた人は大変だったようです。また、そうした複雑な乗り方をする人の応対をする航空会社の係員もかなり大変そうでした。ANAは非常に運が悪いとしかいいようがないですね。明日移行の機体のやりくりもあるし、今頃徹夜でプランを立ててる人たちもいるんでしょうね。
ところで今日の遅延ですが、朝のトラブルに加えて、乗客の搭乗口への集まりが悪いということも遅延を増大させる要因になっていたように思います。というのも、普段ならば皆出発時刻を確認してそれを目安にゲートに集まるものですが、今日は一体いつ出発するのか見当がつかないという状況で、どこかに行っていてなかなか搭乗口に現れない人が多く、出発がさらに遅れていたという感触です。
電光掲示板の内容が実際と食い違っているなど、あちこちに混乱が見られたので、ああいう状況でいかに乗客に正確な情報を素早く提示できるか、というのが重要だなと思った次第です。
脊髄反射 (スコア:1)
# 一時期政府向けシステムも開発してましたよね、あそこは。
# 納入先は富士通だったかな。
-- ラテール部参加者募集中
確認してみます。 (スコア:1)
確認しました。 (スコア:3, 興味深い)
毎日新聞の記事ですが比較的ここ [mainichi.co.jp] が的を得ていると思います。
実は今後の調査結果を確認しなければ解りませんが、
定時処理と新プログラムの相性を確認しなかった可能性
等を指摘しています。
通常空港で管制卓に便名を表示させるARTSと言うシステム等は
バージョンアップ時などは両系に違うバージョンがインストールされ
新バージョンがこければ、瞬時に稼働実績のある旧バージョンに
切り戻す事が出来るようになっています。
今回のFDPシステムの2重化は両系ともに同じシステムを
走らせ2つの処理結果のマッチングを持って信頼性を
保つようなシステムになっているそうです。
その為片系がこけたからと言って瞬時に切り替える事は
出来なかったかもしれません。
しかしFDPはバージョンアップの際に旧バージョンを
保持する事が出来る設計になっているようなので
障害発生時に一刻も早く切り戻す事が出来れば
被害を最小限に食い止める事が出来たかもしれません・・
当然我々はミスのない作業を目指します。
しかし本当に必要なのはお客様に迷惑をかけない事。
今回のようにシステムの設計変更などトラブルが
発生する可能性のある場合、不測の事態が発生した時
如何に短時間で運用を再開させる事が出来るか、
そこに基本があるような気がします。
実際私は某空港で管制卓のキーアサインの全面変更などを
仕切った経験もその作業が途中でトラブった経験もあります。
その時は確かに真っ青になりました。
しかし我々に求められるのはただ震えてるだけの
無能な指揮官ではありません定められたバックオンリミット
までにリトライするか現状に復旧させるかの判断なのです。
動くモノを利用者に提供するそれが私たちの仕事なのですから。
(こんな事を書くとあの時一緒に戦ってくれた仲間たちに
何を偉そうに(笑)と頭を叩かれそうですが・・)
実際私の知り合いの奥さんが実家への帰省の際に
今回の事件に巻き込まれました。
私も一日遅ければ同様に東京から帰れず巻き込まれて いました・・・
業界人として、1ユーザーとして他人事では有りません。
緊急動員 (スコア:0)
Re:もうそろそろ2015年かぁ (スコア:1)
#単なるフォールトトレランスだとばかり…。
written by こうふう
Re:もうそろそろ2015年かぁ (スコア:1)
マイノリティ・リポートがまちがっているとはかぎらないという説。
電子連動1形は3重多数決回路 (スコア:1)
クロックで駆動し、その出力をハードウエア多数決回路経由で
出力させていました。3重刑の出力が不一致になると、多数の
2重系で動作させ、さらにその2重系で不一致が発生すると出力
停止になるようになっていました。
まあ、64KByteのプログラムなので、ソフトウエアバグを考慮
しなくて良かった時代の話ですが....
Re:二系統 (スコア:2, 興味深い)
ニュースでちょっといってましたが、このバックアップはシステム復旧に3時間以上かかるときしか稼動しない、ってことだそうです。
今回は2時間で回復したので、伊丹のシステムは使わなかったって言ってました。
システム止まった責任は、それはそれで追及するとして、飛行機の運航に支障が生じたのは運用体制の問題といえるでしょうね。
せっかくバックアップシステムがあっても稼動しないのなら意味なし。