アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
確認してみます。 (スコア:1)
確認しました。 (スコア:3, 興味深い)
毎日新聞の記事ですが比較的ここ [mainichi.co.jp] が的を得ていると思います。
実は今後の調査結果を確認しなければ解りませんが、
定時処理と新プログラムの相性を確認しなかった可能性
等を指摘しています。
通常空港で管制卓に便名を表示させるARTSと言うシステム等は
バージョンアップ時などは両系に違うバージョンがインストールされ
新バージョンがこければ、瞬時に稼働実績のある旧バージョンに
切り戻す事が出来るようになっています。
今回のFDPシステムの2重化は両系ともに同じシステムを
走らせ2つの処理結果のマッチングを持って信頼性を
保つようなシステムになっているそうです。
その為片系がこけたからと言って瞬時に切り替える事は
出来なかったかもしれません。
しかしFDPはバージョンアップの際に旧バージョンを
保持する事が出来る設計になっているようなので
障害発生時に一刻も早く切り戻す事が出来れば
被害を最小限に食い止める事が出来たかもしれません・・
当然我々はミスのない作業を目指します。
しかし本当に必要なのはお客様に迷惑をかけない事。
今回のようにシステムの設計変更などトラブルが
発生する可能性のある場合、不測の事態が発生した時
如何に短時間で運用を再開させる事が出来るか、
そこに基本があるような気がします。
実際私は某空港で管制卓のキーアサインの全面変更などを
仕切った経験もその作業が途中でトラブった経験もあります。
その時は確かに真っ青になりました。
しかし我々に求められるのはただ震えてるだけの
無能な指揮官ではありません定められたバックオンリミット
までにリトライするか現状に復旧させるかの判断なのです。
動くモノを利用者に提供するそれが私たちの仕事なのですから。
(こんな事を書くとあの時一緒に戦ってくれた仲間たちに
何を偉そうに(笑)と頭を叩かれそうですが・・)
実際私の知り合いの奥さんが実家への帰省の際に
今回の事件に巻き込まれました。
私も一日遅ければ同様に東京から帰れず巻き込まれて いました・・・
業界人として、1ユーザーとして他人事では有りません。