ネットワーク設計構築におけるトラブル
ネットワーク設計構築の中で、想定通りの結果となるかの検証を行いますが、その検証の中で想定とは異なる結果になる場合があります。
このような場合、想定とは異なる結果になる原因を特定し、対応策を導き出す必要があります。
このようなトラブルに遭遇したとき、松田がどのようにトラブルシューティングしているのかを記載します。
パターンをリスト化して全パターン試す
検証の結果というのは、機器の設定値とその周辺のネットワーク環境に基づいて決まります。
そこで、設定値または環境としてどのパターンがあり得るのかをリスト化し、全パターンについて検証し、結果を確認します。
とはいっても機器の設定項目は多数あるので、実際には対象とする設定値や環境は関係がありそうなものを選定して検証を行います。
この対象の選定を行うときは「○○という結果になったら、△ △ ということが言えるな」ということを考えて選定します。
対象の選定を適切にできるかどうかについては、論理的な思考力やナレッジをどの程度持っているのかによりますが、これは経験を積む中で鍛えていくしかないかもしれません。
このパターン化と検証を繰り返すことで徐々に原因に近づいていくことができます。
Google でひたすら検索する
発生している事象に関連するワードでひたすら Web 検索するということも良く行います。
使用する検索エンジンは Google 一択です。
よくあるトラブル事象についてはメーカがサポートサイトで情報公開していたり、メーカ公式のコミュニティサイトで質問されていたり、エンジニア個人がアウトプットしていたりします。
エラーメッセージで検索する
最もシンプルな検索方法は、機器で出力されたエラーメッセージでそのまま検索する方法です。
そのエラーメッセージについて記載されているページには、当然そのエラーメッセージの文字列が含まれているので検索でヒットする可能性が高くなります。
英語で検索する
対象機器にもよりますが、メーカが海外企業のネットワーク機器については、日本語よりも英語の方が情報が多く存在します。
英語が苦手な人も多いと思いますが、ブラウザとして Chrome を使用すれば、右クリックから「日本語に翻訳」機能があるため、それを使用すれば大体意味の分かる日本語に翻訳して表示することが可能です。または文章をコピーして Google 翻訳に投入しても良いです。
間接的に解決する方法を検索する
事象を解決する直接的な情報が無さそうな場合には、間接的に解決する方法を検索します。
例えば、ファイアウォール機器において通信が拒否されている場合に、拒否された詳細な理由が保存されたログファイルは存在しないか、デバッグ用のコマンドは無いかなどを探します。
できるだけ自分で解決する
想定外事象が発生したときに、自分で解決する方法と、有識者に相談する方法があります。
時間的余裕がどれだけあるかによって取るべき方法は異なると思いますが、可能な限り自分で解決する方が長期的に見て得策です。
自分で解決できた場合は自分の中で印象的に記憶に残りますが、人に頼って解決した場合は他人ごとになって記憶に残りづらくなります。また、自分で解決できた場合は自信にも繋がります。
自分で解決することを繰り返すことで、少しずつ問題解決能力が向上していきます。
自分一人でトラブルシューティングができるようになると人に依存しなくて済むのでストレスも低減できます。
簡単にあきらめない
中々解決できない場合もありますが、必死になっていると奇跡的に解決できる場合があります。
このとき得られるものは相当大きいです。知識・経験的な意味でも、気分的な意味でも。
同じトラブルは速攻で解決する
一度経験したトラブルについては、原因と解決策を明確に整理しておきます。
そうすることで同じトラブルに再度遭遇したときに速攻で解決することができます。
これができていない人が意外に多いように思います。
仕組みを理解することが最も効果的
これはトラブルが発生したときにどうこう出来る問題ではないですが、ネットワークや機器の仕組みを理解していると論理的にトラブルの原因を特定しやすくなるということです。
仕組みを理解していない場合、とりあえず思いついたことを実施して想定通りの結果になるかを確認する、ということをひたすら試みていくしかありません。
一方で仕組みを理解していると、「理論的にはこうだからこうやったら解決できるのではないか」という発想になり、より早く正解に辿り着く可能性が高くなります。
仕組みを理解するためには「とりあえず試してみて上手くいったからよかったよかった」で終わるのではなく、なぜ上手くいったのかを良く考えることです。これを日々行うかどうかで長期的に見て大きな差が生まれてきます。
トラブルシューティングの効率は業務全体の効率に直結する
ネットワーク設計構築業務において、トラブルシューティングにかける時間の長短は業務全体の効率に直結します。
一般的に工数の見積を行うときに、トラブルシューティングの時間は（明示的には）含めません。
※何かあったときのためのバッファという広い意味で含めるパターンはあります
従って、トラブルシューティングにかける時間が長くなればなるほどスケジュール的に厳しくなります。個人レベルでは残業が発生する可能性が高くなります。
逆に、トラブルシューティングを最短で終わらせることができればスケジュール的に厳しくなることは無く、個人レベルでは残業を最小限にできます。
このため、松田はトラブルを解決に導くためのナレッジが非常に重要だと考えているのです。
