トラブル解決の方法論
プログラムであれ、NWであれ、クラウドであれ、オンプレであれ、およそシステムの構築にはトラブル発生がつきものである。トラブル解決には２通りの方向性がある。「できないこと」を確認するアプローチ「できること」を確認するアプローチだ。
できないことを確認するアプローチ
「できないこと」というトラブル事象そのものから、ボトムアップ式にトラブル原因までさかのぼっていく方式がこちら。「できないこと」の事実の積み重ねが有効なのは、事前にトラブル発生要因の絞り込みができている場合である。
できることを確認するアプローチ
「どこまでならできるのか」「どこからできないのか」の線引をはっきりさせるアプローチがこちらだ。最も基本的な機能からトップダウンでトラブルが発生していく事象まで確認内容を細分化していく。
どちらを採用すべきか？
多くの場合はトラブル原因は事前に想定していのと全く違うことが多い。「DB更新のロジック誤りだと思って調べてみたら、そもそも対象となるデータそのものが存在していなかった場合」などだ。この場合ボトムアップ式だとそもそも全く見当違いの方向に走り続けている可能性がある。そうなるとどれだけ時間とコストをかけてもそもそも解決にいたらない。
そのためトラブル対応のコツはボトムアップ式に「何ができないか」を確認するのではなく、トップダウン的に「何がどこまでならできるているか」を確認するべき。上の例でいえば「DBプロセスは起動しているし、DBにアクセスはできているし、DBの更新処理が正しく動作している場合としていない場合がある。していないのはXXXのリソースにアクセスする場合のみである」など。
範囲を絞りきった後の最後の一手
「本当はXXXであるべきなのに、なぜか〜になっている」というところまで迫ったらできるだけデバックで取得できる情報を増やすこと。例えばアクセスログの代わりに、wiresharkですべてのパケットの中身を確認するなどだ。
追記
最後の一手に使える手段の多寡が解決能力の違いを生む
- 日本語のドキュメントでなく英語のドキュメントを読む
- ソースコードを読む
