障害解析で必要なもの | さすらいコンサルの徒然なつぶやき

さすらいコンサルの徒然なつぶやき

まだまだ新米のコンサルですが、日々思うことなど書き綴ってます。ITだったりマネジメントだったり、たまに趣味だったり、仕事だったり。
読んでくださった方に、何かが伝わるといいなぁ

まずは事実の積み上げ

積み上げ中に、中途半端な想定を混ぜてしまうと混乱のもとです。

想定で資料を作ったら、その想定が別の想定を生み、

事実と全く違う答えを作ってしまいます。


そして想定した内容を事実と勘違いしてしまうと、

それを元に判断した結果、多大な無駄コストを発生させることも有るのです。


想定を元に、情報を収集するのはだいじです。


例えば、アプリでネットワークが切断された(disconnect)事象があった場合、

アプリから見るとサーバーが切断してきたように見えるかもしれません。


「これは対向のサーバーに問題があったのだ」という想定したとしましょう。


しかし実はアプリのリクエスト自体がネットワークのプロトコル上おかしくて

ネットワーク機器が切断しているかもしれません。


サーバーに問題があったということを裏付けるために、


・disconnectを出しているのが誰なのかを調査する。

・サーバーに到達しているのかログを確認する。


など、想定の裏付けをとる必要があるのです。



あと、前提を疑うこと。

前提があるあらば、その証跡を取って事実としなければなりません。


解析を進める場合、前提事項の整理の中で、


・設定してあ「るはず」

・配置されてい「るはず」

・確認してい「るはず」


「るはず」という部分があるならば、簡単に解析を進めてはいけません。


その部分は


・設定してい「た」

・配置されてい「た」

・確認してい「た」


確実にそうであったという確認の元、「た」(完了形)となっている必要があるのです。

資料化する場合はそのエビデンスも必要です。


特に商用環境の障害発生時は、問題の解決に向けて最速を求められることが多いです。

そんな場合こそ、事実を丁寧に積み重ねて、問題を絞り込んでいくことが大事なのです。


事実と想定の混在はしないようにしましょう。



先月ちょっとバタバタして、しばらくブログお休みしておりました。

そして気づくとブログ始めて1年が過ぎてました。

自分の備忘も兼ねて始めたブログですが、

思ったよりたくさん書くことが出来ました。

これからもボチボチ書いていきます。

興味がある記事だけでも、

眺めてあげて下さい。

m(_ _)m