アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
東証の障害は? (スコア:1)
これら一連の騒動にも「納期合わせの裏技」が一枚噛んでいるのでしょうか?
それとも十分な納期と人材があったにもかかわらず,見逃された穴が原因で起きた事故だと見るべきなのでしょうか?
大規模システムの設計に詳しい識者の見解が聞きたいです.
「納期合わせの裏技」が社会問題として取り上げられていない所を見ると,「裏技」の使用は暗黙の了解事項なのでしょうかねぇ…?
#来年新米社会人
Re:東証の障害は? (スコア:2, すばらしい洞察)
11月のケースはソフト改修後初めての月次処理で発覚する程度のミスで、それこそ「納期あわせ」というか十分な試験がされていなかったということでしょう。
実際には「理想条件(正しい手順で、遺漏なくソフト改修が完了した状態)」での試験すらしていないとは考えにくいので、その理想条件を満たすために現場での改修作業時(後)に現場で行うべき手順が漏れたというケースであると思われます。
#尤も最悪の場合、試験でも実は同様のバグは発生していたけど
#現場と同等の環境を構築するだけの社内(正確には部署内)リソースがなく
#いつもその処理については正常に動かすこと自体が出来ないため
#「ま、ここは大丈夫だろう」とか見逃されるケースもありうる
#部署で同等のマシンを持っていないとか、1台しかなくて2重化が確認できないとか
#大規模システムではよくある話…
#障害がクリティカルな結果に繋がるシステムでも、中の人が慣れでやってるとね
みずほ証券のケースは(東証側システムに話を絞りますが)"新規上場株""大量の誤発注""一部約定成立"などの複合条件が仕様漏れしていたのではないかと思われます。
だとすると試験項目にもそのパターンは盛り込まれないまま成績書も東証側に承認・納品された可能性が高く、であれば納期あわせの裏技云々というよりは上流工程の検討漏れがそのまま通ってしまったケースではないかと想像します。
業務に精通した発注側が指摘しないと、思いもつかないパターンというのは沢山あるある…。
Re:東証の障害は? (スコア:1)
逆に受注者側がチェック漏れ指摘するってケースを多々見ているんですが…(苦笑)
Re:東証の障害は? (スコア:0)