アカウント名:
パスワード:
「他行のATM(現金自動受払機)経由の取引は盲点だった。想像力が及ばず、リハーサル項目からも抜け落ちていた」。三菱東京UFJ銀の幹部は統合作業の不備を認めた。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
復旧スピードはかなり早いといえるのでは (スコア:4, 参考になる)
9時に業務開始、障害発覚、業務停止、障害原因特定、修正、(テスト?)、緊急リリース、業務再開(11:55)
だいたい、これだけのことが間にあると思われるわけで、
漢字←→カナ変換が障害原因だとすぐにわかったというのが気になるけど、
修正による影響範囲が見えないなかでの当日リリースに踏み切ったのはかなりの判断力が要されるだろう。
適用後に重要な障害も聞かないわけで、とりあえず問題なく運用できている?ところをみると、今回のマネジメント層の判断力はかなり評価できるのでは、と思う。
Re:復旧スピードはかなり早いといえるのでは (スコア:2, 参考になる)
=-=-= The Inelegance(無粋な人) =-=-=
Re:復旧スピードはかなり早いといえるのでは (スコア:1)
これだけの規模をトラブルなしで済ます方が難しい・・・とか言っちゃいけないのか。仕事人としては。
でも
http://mainichi.jp/select/biz/news/20080513ddm008020126000c.html [mainichi.jp]
これには違和感。テストケースって理詰めで洗い出すもんじゃないの?
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:復旧スピードはかなり早いといえるのでは (スコア:5, 興味深い)
>これには違和感。テストケースって理詰めで洗い出すもんじゃないの?
自行分の機能については、仕様書ベースでのテストケース洗い出しをやって入念にレビューできるが
他行ATMへの電文についてテストするには、他行ATMの電文シミュレータを必要とする。
(通常、電文シミュレータなんてものは自行機能の正常性、リグレッション確認のために使用される1ツールとみなされ着目されないこと多し。)
今回のケースをベンダー側で予知するには、他行ATMの電文シミュレータそのもののテスト、更改が必要だったと考えられる。
もちろん理詰めで洗い出せばわかることだけど、外部との接続性についての問題になってしまうため、
開発ベンダーだけでなく銀行側でも他行データとの摺り合わせだとかテスト項目チェックをやっていくことになり、一気にコストが膨大になり現実的ではないと妄想。
現実的ではないコストを振れないので、ほんとは想像できてたけど、想像力が足りずと言い訳するしかない。
Re:復旧スピードはかなり早いといえるのでは (スコア:2, 興味深い)
結局実データで走らせてみないと分からない。
実データで走らせても、そのテスト範囲に含まれてないパターンが来たら分からない。
いつでもどこでもそんな感じ。
昔はいい加減だったからクリティカルな個人情報たっぷりの実データも
当たり前のように持ち出して試験環境に叩き込んでましたね。内緒だけど。
Re:復旧スピードはかなり早いといえるのでは (スコア:1, 参考になる)
対外のOpenは午前7時ですよ。(一部だけとは言え)5時間近く動かなかったのが早いと言うなら、昔富士銀行が全面停止したのも、回復早かったってことになっちゃいますね。
Re: (スコア:0)
影響範囲も糞もない。
後者の問題は、その日の取引が終了するまで手が出せず……です。