トラブルの恒久対処で本質を問えるか

システムは年末年始も動いているので無事無事故で運行しているシステムもあれば、こんなタイミングで「トラブルの？」というシステムもありますね。

で、トラブルがありましてそのトラブルの障害報告を読むとどこかで似た障害報告を読んだ記憶が……。

たぶん、この後は製品ベンダに問い合わせして、バグと判定されればパッチが出てくるのを待って適用して、経過観察して…となると思われますが、製品バグなら淡々と対処すればいいと思うのですが「それじゃあ今後どうするの？」という先を見据えた1つの事象に対する恒久対処の他に、同じようなことが起きないようにするためのトラブル防止の本質を考えた恒久対処をどう考えているか、を知りたいわけです。

事実を並べれば、

実績ある設計で実装した。
長年ノントラブルだった。
でも、トラブは起きた。
製品バグだった。

ワタシは「実績ある設計で実装した」というところに注目したいです。これは、同じような設計、実装していることを暗に言っていると理解します。ということは、潜在的にトラブル可能性を持っているシステムがあるということを示しています。

また、「製品バグ」ということが原因だったと確定すると、設計の良し悪しは検証もされないでことが終わる可能性があります。ここが気になるわけです。

実績ある設計だから、という主張は、ワタシの考えではトラブルが起きた時点でチャラなんです。トラブルが起きた実績のある設計、実装としか認識できない。

以上から、ワタシは次のことを期待するわけです。

既存で生きている同じ設計を実装しているシステムの有無の棚卸。
現存する場合に同様のトラブルが起きた場合の本番障害時の影響範囲、損害額
トラブルを加味した設計改善案の検討、追加テスト仕様案の検討

ここまでやって欲しいのは、1つ目と2つ目がリスク発現時の想定を把握するため。3つ目が将来のリスクを防止するため、です。