トラブルシューティング

読み：とらぶるしゅーてぃんぐ　／　英語表記：troubleshooting

ネットワークの不具合の原因を突き止めて解決する作業。思いつきで手を動かすのではなく、問題の定義 → 情報収集 → 切り分け → 仮説の検証の順に、論理的に進めることが大切である。

イマシルちゃんの解説

トラブルシューティングは、ネットワークの不具合の原因を調べて解決する作業だよ。
お医者さんが症状を聞いてから検査するように、まず誰がいつから何に困っているかを確かめるんだ。
例えば一台だけ遅いのか、同じ回線を使う全員が遅いのかで、調べる場所が変わるよ。
機器の記録であるログや通信量を調べ、正常なときと比べて原因の候補を絞っていくの。
候補が見つかったら確かめる方法を考え、対策後に症状が消えたかも確認するんだ。
根拠と結果を記録しておけば、同じ問題が起きたときの対応にも役立つよ。

より深い解説

基本の4ステップ

ステップ	やること	問いかけの例
1. 問題の定義	症状を具体的に言葉にする	何ができないのか。誰が、いつ、どこで困っているのか
2. 情報収集	事実を集める	利用者への聞き取り、機器のログ、通信量のグラフ、設定
3. 切り分け	原因の範囲を絞り込む	全員か一部か。いつもか特定の時間帯か。どの区間で起きているか
4. 仮説の立案と検証	原因の候補を立て、データで確かめる	○○が原因なら、△△のログに□□が出ているはず

解決したら、対策を実施して症状が消えたことを確認し、原因と対策を記録して再発の防止に役立てる。

聞き取りで押さえる観点

症状の「パターン」は、原因を絞り込む最大の手がかりになる。

観点	例	示唆すること
時間帯	毎朝の決まった時間だけ起きる	利用が集中したときの容量の不足（帯域、テーブル、セッション数など）
範囲	全員か、一部か	全員なら共通の部分（回線、中心の機器）。一部なら個別の要因か、資源の取り合い
規則性	特定の端末か、不特定の端末か	不特定なら、端末ではなく、共有の資源が足りずに「たまたま」溢れた端末が失敗している可能性
サービス	外部のサービスだけか、内部のサービスもか	内部が正常なら、インターネットへの出口（回線、NAPT、プロキシなど）を疑う
症状の種類	つながらない（タイムアウト）か、遅いか	つながらないなら資源の枯渇や遮断、遅いなら帯域の不足や遅延

切り分けの考え方

方法	内容
区間で分ける	端末 → 無線LAN → スイッチ → ルータ → 回線 → インターネット → サーバの、どこで問題が起きているかを調べる
層で分ける	物理層（リンクは上がっているか）→ データリンク層 → ネットワーク層（pingは通るか）→ アプリケーション層、と下から確かめる
比較する	正常に使えている端末や時間帯と、問題が起きている端末や時間帯を比べる
変更点を探す	最近、何が変わったか（設定の変更、利用者の増加、新しい使い方の開始）

仮説を立てて確かめる例

症状	仮説	確かめるデータ
毎朝、多数の生徒が一斉に外部のサービスを使うと遅い	インターネットの回線の帯域が足りない	ルータの外側のポートの通信量が、ある値で頭打ちになっていないか
同じ時間帯に、一部かつ不特定の端末だけログイン画面が出ない	ルータのNAPTの変換テーブルが足りない	ルータのシステムログに、変換テーブルが満杯になった記録がないか
ルータのCPU負荷は低いのに速度が出ない	機器の処理能力ではなく、回線（契約）が上限	事業者への問い合わせ、契約の種類（ベストエフォートか）

ここで大切なのは、1つの仮説に飛びつかず、症状の特徴をすべて説明できる仮説を考えることである。たとえば「遅い」だけなら帯域の不足で説明できるが、「一部の端末だけがつながらない」という症状は、帯域の不足だけでは説明しにくく、別の資源の不足を疑うきっかけになる。

午後での問われ方

問われ方	答え方のポイント
ある仮説を立てた理由	聞き取った症状のうち、どの特徴が、その仮説を示しているかを答える
グラフやログから読み取れること	頭打ち、急増、時刻の一致など、事実を正確に読み取る
必要な設定値の計算	1台あたりの使用量 × 台数など、条件を整理して計算する
改善策	仮説で特定した原因に、直接効く対策を選ぶ（回線の契約の変更、テーブルの拡張、保持時間の調整など）