また、国土交通省側でのトラブル中に、たまたま自衛隊側でデータの
更新作業を 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 に書き込むことはできなかったり。
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:ん (スコア:0)
普通、限界チェックとかデータがただしいかチェックする部分で弾くと思いますし、サブの方に瞬時に移行できる体制で準備していればいいし、また複数の連動であれば旧データの送信方法で通信できるモードを入れておけば相手を変更せずにチェックできます。
両者をその状態
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:ん (スコア:0)
# しかも再開速かったし
Re:ん (スコア:1)
再開が早かったのはバグが直ったからなのだろうか?
前のシステムに戻したからなのだろうか?
ちょっと気になる
バグが直ったというのであれば素早い再開ってのはちょっと怖いかも
Re:ん (スコア:1)
参考資料 [srad.jp]
#続報をまだ見てないので、どの程度本当なのか分かりませんが…
-+- 想像力を超え「創造力」をも凌駕する、それが『妄想力』!! -+-
Re:ん (スコア:1)
ご指摘ありがとです。
そっか 前の奴に戻したんだ…
とりあえず安心かな
でも、修正版リリースしてまたコケたら…
せっかくだから 事前にリリース日発表してほしいもんだ
フローコントロール (スコア:0)
問題があれば福岡のフローコントロールセンター
がフローコントロールかけます。これは在空機
の数を制限するもので、要は離陸させない(だけ
ではないんですが)で交通渋滞を緩和させる。
ちなみに、ACCのサービスを受けて飛んで行く
飛行方式はIFR(かな
Re:ん (スコア:1, すばらしい洞察)
どう考えても、マニュアルがあったから7:30から一部運行再開が出来たんだと思うんですけど・・・。
というか、プロトコルの問題なのか?
バッチの統計処理って所から想像するに、多分デッドロックじゃないかなと思うけど。
Re:ん (スコア:0)
ひょっとして、統計処理で更新ロックしてる間抜けが居たのか?
言語とDBにもよるけど、COBOLでADBSとかなら、非宣言時に更新ロック掛かる気がする。
で、そのまま検索系のプログラム書いちゃうと、ロジック的なテストは問題無いけど、実環境の大量データ処
それは (スコア:0)
>#判る人だけ付いて来て下さい(w
>#私も昔やったのでAC
一部の人にはドコ製のマシンだったかは判っちゃいましたねえ。:-)
#/SなプログラマだったのでA.C.
Re:ん (スコア:0)
当然オンラインがとまるまで動かないから、それは関係ないのでは。
考えられるのは、バッジの検索系で無限ループに入り、リソース食い尽くした可能性。
リソースつぶしたのなら、当然オンライン系も連動でダメ。
バッチ処理をKillJ
システムのディスク (スコア:0)
システム2重というかちょっと言い替えて(つーかこの辺一連の
話見てるとNHKの説明も悪いんじゃないかと思われ。。。)
CPUは2つだとおもいますが、プログラムを格納してるディスク
は3だい以上もっているはず(多分。。。)
通常1CPUに1DISKつけて運用していて、(これで2台使用)
残り1台に旧バージョンがあって構成変更して再立ち上げすれば
もとに戻せる、但し、CPUの話であってプログラム変更の内容が
例えばインターフェースの追加とか伴う場合、現実に旧システム
のプログラムが理解していないものが現実に存在するため戻した
場合予期しない事態が起こる可能性があるため戻す
Re:NHKでやってた解説 (スコア:1)
>0700から始まる「統計プログラム」なるバッチ処理(?)の開始と共にダウンした。
これは午前7時のことですね。時刻表ライクな書き方ですね。
Re:NHKでやってた解説 (スコア:0)
# 存在を忘れた時から、ねじは巻き戻る
Re:NHKでやってた解説 (スコア:1)
この話のとおりだったら、テスト不足と言うより、変更が影響する範囲をそもそも見誤っていた (本来なら統計処理プログラムも変更しなければいけないのに気づいていなかった、ゆえにテストからも除外されていた) って感じでしょうか。
Re:NHKでやってた解説 (スコア:0)
今回のダウンと言う現象だけで言えばアホっぽいで良いのだけど、アホっぽいを状況をつくり出している理由がかなり難
Re:NHKでやってた解説 (スコア:0)
この業界、がドコをさしているかわかりませんが、今はコストダウンの名のもとに身の回りのすべてが安かろう悪かろうに突き進んでいる気がします
Re:NHKでやってた解説 (スコア:0)
ダウンサイジングといいます。