インフラエンジニアのトラブルシューティング入門｜障害対応の思考プロセスと手順を現役講師が解説
インフラエンジニアの
トラブルシューティング入門
障害対応の思考プロセスと手順
「障害が起きた瞬間、頭が真っ白になった」「とりあえず再起動してしまった」——現場1〜2年目に起きやすいこの状況は、思考の「型」を持っていないことが原因です。この記事では、障害対応の5段階フレーム・NW／サーバー障害の切り分け手順・エスカレーション判断の基準・記録の残し方まで、未経験〜2年目向けに解説します。
この記事でわかること
📋 目次
1. 「障害対応が苦手」な人に共通するパターン
よくある行動パターン
- とりあえず再起動してしまう——原因究明より先に手を動かしてしまう
- 「なんかおかしい」で止まる——症状を言語化できずに切り分けが始まらない
- 直前の変更を確認しない——「最後に何を変えたか」を問わずに調査する
- 一度に複数の変更を試す——何が効いたかわからなくなる
- エスカレーションのタイミングがわからない——抱えすぎて障害が長引く
🔖 「再起動の前に記録」は鉄則
再起動によって障害は復旧することがありますが、「何が原因だったか」のログ・証拠が消えます。再起動前に各種ログ（syslog・イベントログ・アプリケーションログ）を手元に保存しておくことが、根本原因を調査するために重要です。
2. 障害対応の5段階フレーム——思考の「型」を持つ
3. STEP 1：状況把握・事実確認——「5つの問い」
① どんな症状か？
「繋がらない」「遅い」「エラーが出る」など症状を具体的に言語化する。「なんかおかしい」では切り分けが始まらない。
② いつから起きているか？
「最初に気づいた時刻」と「最後に正常だった時刻」を確認する。「最後に正常だった時刻」の直前に何かがあれば、それが原因の候補になる。
③ どこで・誰に起きているか？
「特定の1台か・複数台か・全体か」「特定のユーザーか・全員か」「特定のネットワークか・全体か」を確認する。
④ 最後に変えたことは何か？
設定変更・ソフトウェアのアップデート・ケーブルの抜き差し・ネットワーク機器の再起動・クラウドの設定変更など、直前の変更作業を確認する。障害の多くは「直前の変更に起因する」ことが現場では多い。
⑤ エラーメッセージ・ログには何と書いてあるか？
画面のエラーメッセージ・syslog・イベントログを確認する。「エラーメッセージを読まずに対応する」は最も避けるべき行動。
⚠️ 「症状」と「原因」を混同しない
「サーバーが落ちた」は症状です。「HDDが故障した」が原因の一例です。状況把握の段階では「症状の事実を確認する」ことに集中し、原因の決めつけをしないことが重要です。
4. STEP 2：影響範囲の特定——「正常な境界を探す」
| 確認する視点 | 確認する内容 | 絞り込める原因 |
|---|---|---|
| 台数の範囲 | 1台のみか・同じ構成の複数台か・全台か | 1台のみ→その機器固有の問題。全台→共通インフラ（スイッチ・DNSサーバー・ルーターなど）の問題 |
| ユーザーの範囲 | 特定のユーザーのみか・全ユーザーか・特定部署か | 特定ユーザーのみ→アカウント・認証・クライアント側の問題。全ユーザー→サーバー・ネットワーク側の問題 |
| ネットワークセグメント | 特定のVLAN・サブネットのみか・複数セグメントか | 特定セグメントのみ→そのセグメントを担当するスイッチ・ルーター・ACLが疑われる |
| アプリケーション | 特定のアプリのみか・全アプリか・OS自体が問題か | 特定アプリのみ→そのアプリケーション・ミドルウェアの問題。OS全体→OSレベルの問題 |
| 時間帯・条件 | 特定の時間帯・条件で発生するか・常時発生するか | 特定時間帯→負荷・バッチ処理・定期実行タスクとの関連を調査。常時→恒常的な設定・構成の問題 |
5. STEP 3：切り分けの手順——NW障害・サーバー障害別
ネットワーク障害の切り分け手順
| 確認ステップ | 使うコマンド・確認方法 | 確認内容・判断基準 |
|---|---|---|
| 物理層の確認（L1） | 機器のLEDランプ確認・ケーブルの抜き差し | リンクLEDが点灯しているか。点灯していない場合はケーブル・NIC・ポートを疑う |
| 自分自身のIPを確認（L3） | ip a（Linux）/ ipconfig（Windows） | IPアドレスが正しく設定されているか。169.254.x.xはDHCPが取得できていない状態 |
| デフォルトGWへのping（L3） | ping [GWのIPアドレス] | 到達できれば自分のNIC・ケーブル・スイッチポートは正常。到達できなければこの範囲に問題がある |
| 対象サーバー・機器へのping（L3） | ping [対象IPアドレス] | 到達できればL3は正常。できなければ経路・ルーティング・ACLを疑う |
| ルーティングテーブルの確認 | ip route show（Linux）/ route print（Windows） | 対象の宛先への経路が設定されているか。デフォルトルートが正しく設定されているか |
| ポート・サービスの確認（L4〜L7） | ss -tlnp（Linux）/ telnet [IP] [ポート番号] | pingは通るがサービスに繋がらない場合、対象のポートでサービスが起動しているか・ファイアウォールで遮断されていないかを確認 |
| DNS解決の確認 | nslookup [ホスト名] / dig [ホスト名] | ホスト名でアクセスできない場合、IPで直接アクセスできるかを確認。IPで繋がればDNSの問題 |
🔑 切り分けの「鉄則」：一度に複数の変更をしない
障害対応中に「これも試してみよう」と同時に複数の設定変更をすると、「どの変更で直ったか」がわからなくなります。一つの仮説を確認したら、その結果を記録してから次の確認に進む習慣が重要です。特に本番環境では「一手一手記録しながら進む」ことが原則です。
サーバー障害の切り分け手順
| 確認ステップ | 使うコマンド・確認方法 | 確認内容・判断基準 |
|---|---|---|
| サーバーへのログイン確認 | SSH接続・コンソール接続を試みる | ログインできれば、OS自体は動いている。ログインできなければOSレベルまたはネットワーク側の問題 |
| リソース使用状況の確認 | top / free -m / df -h | CPU使用率・メモリ使用量・ディスク使用量が異常に高い場合はリソース枯渇を疑う。特にディスク100%はサービス停止の直接原因になる |
| プロセスの稼働確認 | systemctl status [サービス名] / ps aux | grep [プロセス名] | 対象サービス（WebサーバーDBなど）が起動しているか。停止していれば起動ログを確認する |
| システムログの確認 | journalctl -xe / tail -100 /var/log/syslog | 障害発生時刻前後のログにエラー・警告が出ていないか。「OOM killer」「disk full」「segfault」などのキーワードを確認 |
| アプリケーションログの確認 | 各アプリケーションのログファイルを確認（例：/var/log/nginx/error.log） | アプリケーション固有のエラーが出ていないか。エラーコード・スタックトレースを記録する |
| 直近の変更履歴確認 | last / rpm -qa -last / apt list –installed | 最近ログインしたユーザー・パッケージのインストール・更新の履歴を確認し、障害発生時刻と照合する |
6. STEP 4：エスカレーション——判断の基準と報告の仕方
エスカレーション判断の3段階
多数のユーザーに影響・売上・業務に直接影響する障害・セキュリティインシデントの可能性がある・原因がまったくわからない状態。「自分で解決しようとする時間」自体がリスクです。手元の情報をまとめてすぐに上長に連絡する。
5つの問いと切り分けを試みたが原因が特定できない。上長に状況を報告しながら一緒に調査する段階。
エスカレーション時の報告の型
📋 エスカレーション報告の型（5点セット）
- ①症状：「○○サーバーにSSHで接続できない状態が続いています」
- ②発生時刻・影響範囲：「○時○分頃から・対象は○○環境の全ユーザー」
- ③確認したこと：「pingは通る・サービスが停止している・ログに××のエラーが出ています」
- ④試したこと：「サービスの再起動を試みたが復旧せず」
- ⑤現在の状況・判断に迷っていること：「××の設定変更を試みるべきか判断できず、エスカレーションしました」
💡 エスカレーションは「諦め」ではない
「自分で解決できなかった＝能力不足」ではありません。適切なタイミングで適切な情報を持ってエスカレーションする能力は、現場では高く評価されます。「いつ・何を・どう伝えてエスカレーションしたか」を記録しておくことで、自分の判断力の成長を振り返ることができます。
7. STEP 5：記録・再発防止——障害対応をキャリアに変える
- 「障害対応メモ」を習慣にする：業務日報・個人のノートに、今日対応した障害の「症状・原因・対処・気づき」を3〜5行でまとめる。この積み重ねが「障害対応の引き出し」になる
- 「判断に迷った点」を記録する：「なぜこの判断をしたか・どこで迷ったか」を残しておくと、次回同じ場面で迷いにくくなる。また1年後に読み返すと自分の成長が確認できる
- 手順書の不備を見つけたら更新を提案する：「手順書の通りにやったが解決しなかった」場合、そのギャップを手順書に追記・更新することを提案する。これは現場への貢献として評価される
- スキルシートに「障害対応経験」として書く準備をする：「NW障害の一次切り分けを担当・月平均○件のアラート対応・手順書の更新実績あり」という形で記録しておくと、転職・社内評価の場面でアピールできる実績になる
🔖 「障害対応の経験」は構築フェーズへの最短ルート
「運用監視は地味」と思われがちですが、障害対応の経験はインフラエンジニアとしての実力を証明する最も確かな実績の一つです。記録を残しながら経験を積み上げることで、構築フェーズへのステップアップが現実になります。
8. よくある疑問（FAQ）
Q. 障害対応中に焦ってしまい、思考が止まります。どうすればいいですか？
A. 「焦り」は技術力の問題ではなく「何をすべきかわからない状態」から来ることがほとんどです。「最初にやること」を事前に決めておくことが有効です。この記事の「5つの問い」を手元にメモしておき、障害が起きたらそれを見て一つずつ確認する——というだけで、思考が止まりにくくなります。
Q. 原因がわからないまま時間が経ってしまいました。どこでエスカレーションすればよかったですか？
A. 「15〜30分経っても原因が絞り込めない」がエスカレーションの目安です。特に「5つの問いに答え、L1〜L3を確認し、ログも見たが原因が特定できない」という状態になったら、迷わず上長に報告してください。
Q. 手順書がない障害はどう対応すればいいですか？
A. 手順書がない場合こそ、この記事で紹介した「5段階フレーム」と「切り分け手順」を使ってください。OSI参照モデルの下から順に確認していくことで、手順書なしでも系統立てて対応できます。また、その対応記録を手順書として残すことで、チームの資産になります。
9. まとめ
- 「障害対応が苦手」の原因は技術不足より「考える順番を知らない」こと。思考の型を持つことで、技術知識が不完全でもある程度対応できるようになる
- 5段階フレームを体に染み込ませる：状況把握→影響範囲→仮説と切り分け→対処とエスカレーション→記録。この順番で動く習慣が障害対応力の土台
- 最初は「5つの問い」を手元にメモしておく：何が・いつから・どこで・直前の変更・エラーメッセージ——これだけで切り分けの半分は進む
- ネットワーク障害はL1→L3→L4〜L7の順で確認：物理→IP到達性→ルーティング→ポート・サービス→DNS
- サーバー障害はリソース→プロセス→ログ→変更履歴の順で確認：CPU・メモリ・ディスクのどれかが枯渇していないかを最初に見る習慣
- エスカレーションは早めが正解：「影響が広い・15〜30分経っても絞り込めない」→迷わずエスカレーション
- 記録が経験をキャリアに変える：対応した障害のメモを残し、スキルシートに書ける実績にする
「障害対応の型」を一緒に身につけませんか
「現場で障害対応を経験しているが整理できていない」
「トラブルシューティングをもっと体系的に学びたい」
「自分の経験をどうスキルシートに書けばいいか相談したい」
