論理的に説明できること

トラブルシューティングに疲れてくると、ありがちな推測や、目先の結論に飛びつきたくなります。
先日も現場でトラブルシュートをしていた連中が「原因は多分コレだ!」と言ってきたのですが、それは私には全く説得的なものではありませんでした。それが本当に原因だとすると、現象が起きているいくつかの環境に対する説明がつかないからです。
(その現象、同じOSでも、発生する環境と発生しない環境がありました。)
それを指摘したものの、どうやら聞く耳を持たないようでしたので、敢えて放置してみた所、案の定不発に終わりました。
その後、別の方向からアプローチを開始。ふたつの環境のGAC(Global Assembly Cashe)から、プログラムフォルダ(一般的には C:¥Program Files )の “Common Files¥Microsoft Shared”内まで。ファイルの比較をして見ました。
(ちょい技:コマンドプロンプトからテキストファイルにリダイレクトさせて、diffの類でテキスト比較すると結構シアワセ)
今回は、そこまでしなくても、あっというまに原因がわかりましたが、問題はそこから。
「なぜ、その差が生まれたのか?」
これを説明できなくては、また同じ現象が発生してしまいます。同じ現象が発生したら、また同じトラブルシュートをやることになります。これは避けたい。
そのためにも、
・なぜこの現象が起きたのか
・どのような条件で再現するのか
・再現する条件としない条件の違いは何か
などを、キチンと論理的に説明できる必要があります。
現象が再現する条件と再現しない条件を、両方「新たに構築できる」ぐらいにできると、もはや理想です。
「多分コレ」では、同じ現象が起きて、あろうことか違う原因だった時に苦労することになります。ただでさえトラブルシュートは厄介なわけですから、もう一回同じ問題を解きたいとは思いません。
確かに、回避策が見つかって、それで十分な場合も、実務上は多くあります。しかし、そうもいかない場合には、きちんとトラブルシュートしておく必要があるということです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam Protection by WP-SpamFree