過去にAIブームは何度かありましたが、今回のブームは今後の技術進展に対して結構期待できるものになっていると思います。

なにより一般ユーザが触れるものになってきたという点ですね。インターネットで調べれば、AIがチャットで使われてたり、質問に答えてくれたり、画像を生成してくれたり、非IT系の人たちが目の当たりに出来ることが多くなったのが大きいです。

やはり社会に評価されないと価値が生まれず、価値が生まれないと普及せず稼げないので、投資もされなくなってしまいます。

さて、前置きが長くなってしまいましたが、私もAIに「ITエンジニアに聞きたいことはないか」と問うてみました。すると、問題解決のアプローチを教えてほしいと言われました。

漠然とした質問なのでネットワークに絞ってまとめてみたいと思います。

ステップ1：似た事象を経験したことがあるか

まず私は似た事象を経験したことがあるか考えます。ある場合は同様の原因が考えられますので、その調査をします。具体的にはログを見たり、設定値の確認をしたりします。

ステップ2：設計の確認

トラブルシューティングでは誤認識が一番怖い、と言うか無駄な時間を使ってしまうと思ってます。

「こうなるはずだ」と思っていてもそれが勘違いで、不要なトラシューばかりをしてしまい、無駄に時間だけが過ぎてしまうのは大変もったいないことです。

そのため、改めて設計を確認し、その後のトラブルシューティングが効率的に進むようにします。

ステップ3：L3レイヤの確認

やっと技術的な観点になってきます。本当にちゃんと時間を使ってしっかりトラブルシューティングするためには、L1レイヤ（物理層）から順を追って状況を確認していくのが美しいと思いますが、トラブルシューティングは大抵時間がありません。

そこでまずL3レイヤの確認をします。L3レイヤが正常、例えばPingが通る場合には、L1とL2はほぼ問題ないでしょう。それが確認できればL3およびL4以降の確認をします。

ステップ4：L4レイヤ以上の確認

ここからは原因が考えられすぎて具体的に話すことが難しいのですが、ACLやFirewallで引っかかって無いかを確認します。プロトコルやポートレベルの確認ですね。

ステップ5：L7の確認

どんな通信かにもよりますが、ネットワークに問題がない、つまり接続性はあってFirewall等で拒否した形跡もないとなると、通信の中身の問題になってきます。

例えば、TCP確立のための3ウェイハンドシェイクで躓いているとか、送信側の要求を受信側がドロップしている等です。

NW観点でトラブルシューティングを進めるためにはパケットキャプチャを取って通信の中身を見る必要が出てきます。

大抵の場合は、このステップにくるより少し前にサーバのチームにエスカレをします。私の感覚だとL3で疎通性が確認できた頃にはサーバチームに伝えます。トラブルシューティングは早くしないとお客さんも怒ってしまうので。

ステップX：お祈り

最後の最後、どうしようもない時はサーバの再起動ですね。ロジカルではありませんが、これで動くことは往々にしてあります。エンジニアとしてはモヤモヤで終わるんですけどね。

最後に

私の経験によると、L1やL2でトラブることは稀で、大抵はL3かそれより上のレイヤでおかしくなってます。L1は物理層なので、明らかに壊れていればLEDは点灯しませんし、インターフェースもダウンステータスになるので分かりやすいです。L2も基本的な設定を抑えてちゃんと設定すれば大丈夫です。ちなみに、これは完全断の話で断続的な事象はタチが悪く厄介です。

あとはもう経験の有無でアプローチが変わる気がします。ただ一つ言えることはやみくもにトラブルシューティングをするのは一番ダメです。技術力もつかない運任せの方法だからです。上記ステップXでは運任せは許されますが、ステップXに至るまでは、それなりのロジックをもって対応することが一番大切だと思います。でないと技術力が養われないのはもちろん、トラブルシューティングの過程を誰にも説明できなくなってしまいます。