インフラの障害対応で最初にやるべきこととは？どうしたらいいの？

こんにちは、InfraAcademyを運営しているryuです。

サーバーに接続できない。Webサイトが表示されない。監視から大量のアラートが届いた。

そんな状況になると、何かコマンドを打たなければと焦ってしまいますよね。

しかし、インフラの障害対応で最初にやるべきことは、サーバーを再起動することでも、設定ファイルを書き換えることでもありません。

最初に行うのは、今起きている事実を整理し、影響範囲を確認することです。

障害が発生した直後は、まだ原因が分かっていません。

原因が分からないまま変更を加えると、障害を広げたり、原因を調べるための情報を消したりする可能性があります。

この記事では、インフラ障害が発生したときに、最初に何を確認し、どのような順番で対応すればよいのかを初心者向けに解説します。

インフラ障害で最初にやるべきこと¶

先に結論からお伝えします。

障害が発生したときは、次の3つを最初に確認します。

この3つを整理するだけで、調査する範囲をかなり絞れます。

逆に、この確認をしないまま作業を始めると、見当違いの場所を調べ続けることになります。

最初にコマンドを打たなくてもよい¶

障害が起きると、すぐにtopやdf、pingを実行したくなります。

もちろん、これらのコマンドは障害調査で役立ちます。

ただ、先に考えてほしいことがあります。

そのコマンドで何を確認したいのでしょうか。

CPUが高いと予想してtopを打つのか、通信できないと予想してpingを打つのかでは、調査の意味が違います。

何となくコマンドを打つのではなく、仮説を持って確認することが大切です。

障害対応で焦って再起動してはいけない理由¶

サーバーに問題が起きたとき、再起動すれば直ることがあります。

実際に、プロセスが停止していたり、メモリを大量に消費していたりする場合は、再起動によって一時的に復旧するかもしれません。

しかし、すぐに再起動すると、障害の原因を調べるための情報が消えることがあります。

例えば、次のような情報です。

• 障害発生時に動いていたプロセス
• メモリやCPUの使用状況
• ネットワーク接続の状態
• 一時ファイルに出力されていたログ
• 再起動前のサービス状態

再起動後に正常になっても、なぜ障害が起きたのか分からなければ、また同じ障害が発生します。

そのため、緊急性が高くない場合は、最低限の状況を記録してから再起動を検討します。

再起動が必要な場面もある¶

もちろん、再起動してはいけないという意味ではありません。

業務への影響が大きく、一刻も早くサービスを復旧させる必要がある場合は、再起動や切り戻しを優先することもあります。

大切なのは、目的を決めることです。

原因調査を優先するのか、サービス復旧を優先するのか。

この判断をせずに、何となく再起動することが問題です。

障害が発生した時刻を記録する¶

障害対応では、発生時刻が非常に重要です。

ログを調べるときも、監視グラフを確認するときも、どの時間帯を見ればよいのか分からなければ調査が進みません。

まずは、次の内容を記録します。

障害を確認した時刻：10時23分
最初のアラート時刻：10時18分
最後に正常だった時刻：10時15分
確認したユーザー：複数ユーザー
表示されたエラー：502 Bad Gateway

障害を確認した時刻と、実際に障害が始まった時刻は同じとは限りません。

監視アラート、アクセスログ、利用者からの連絡などを確認し、できるだけ発生時刻を絞ります。

コマンドの実行結果も時刻と一緒に残す¶

調査中にコマンドを実行したら、結果だけでなく実行時刻も残しておきます。

Linuxでは、dateコマンドで現在時刻を確認できます。

date

例えば、次のように記録します。

10:30 date実行
10:31 systemctl status nginxを確認
10:32 nginxがfailedであることを確認
10:34 設定ファイルを確認

あとから振り返ったときに、いつ何を確認したのか分かります。

Linuxの時刻確認については、Linuxで時刻を確認・変更する方法でも解説しています。

影響範囲を確認する¶

次に、どこまで障害が広がっているのか確認します。

1人だけ使えないのか、全員が使えないのか。

特定の画面だけ使えないのか、Webサイト全体が使えないのか。

ここを間違えると、調査する場所も変わります。

例えば、1人だけログインできない場合は、そのユーザーのアカウントやブラウザに問題があるかもしれません。

全員がログインできない場合は、認証サーバーやデータベース、ネットワークなど、共通部分を疑います。

正常な部分も確認する¶

障害対応では、使えない部分だけを調べがちです。

しかし、使える部分を確認することも大切です。

例えば、Webサイトが表示されないとします。

このとき、次のように分けて確認します。

この結果から、サーバー全体やネットワーク全体ではなく、Webサーバー周辺に問題があると考えられます。

正常な範囲を除外すると、調査対象を狭くできます。

直前の変更を確認する¶

障害が発生したときは、直前に何が変わったのかを確認します。

インフラ障害は、何もしていないのに突然発生することもあります。

ただ、実際には設定変更、リリース、証明書更新、OSアップデートなどがきっかけになっていることも多いです。

次のような作業がなかったか確認します。

直前の変更と障害発生時刻が近ければ、最初に確認する価値があります。

ただし、直前の変更が必ず原因とは限りません。

思い込みで決めつけず、ログや設定を確認しながら判断します。

障害対応の基本的な流れ¶

最初の状況確認ができたら、次の順番で対応します。

状況確認
↓
影響範囲の確認
↓
関係者への共有
↓
原因の切り分け
↓
復旧方法の判断
↓
復旧確認
↓
原因調査と再発防止

会社やシステムによって手順は異なりますが、大きな流れは同じです。

ここからは、それぞれを詳しく見ていきましょう。

関係者へ早めに共有する¶

障害対応では、自分だけで抱え込まないことも大切です。

まだ原因が分かっていなくても、業務へ影響がある場合は早めに共有します。

最初の報告では、原因を断定する必要はありません。

分かっている事実と、まだ分かっていないことを分けて伝えます。

10時18分ごろから、Webサイトへアクセスできない状態です。
複数の利用者で同じ現象を確認しています。
サーバーへのSSH接続は可能です。
現在、Webサーバーとネットワークの状態を確認しています。
次回は10時45分を目安に状況を共有します。

原因が分からないから報告できない、ということはありません。

今何が起きていて、どこまで分かっているのかを伝えるだけでも、利用者や関係者は次の行動を考えられます。

推測を事実のように伝えない¶

調査中は、原因の候補がいくつも出てきます。

例えば、データベースが怪しい、ネットワークが怪しい、証明書が原因かもしれない。

しかし、確認できていないことを原因として報告すると、ほかの担当者も誤った前提で動いてしまいます。

事実と推測を分けて書きます。

事実：Webサーバーのプロセスが停止している
推測：設定変更後の再起動に失敗した可能性がある
確認中：設定ファイルとサービスログ

この書き方にすると、情報を受け取る側も状況を理解しやすくなります。

大きい範囲から小さい範囲へ切り分ける¶

原因を調べるときは、いきなり細かい設定ファイルを読むのではなく、大きい範囲から確認します。

例えば、Webサイトへ接続できない場合は、次の順番で考えます。

1. 自分だけの問題か、複数ユーザーで発生しているか
2. DNSで正しいIPアドレスを取得できるか
3. サーバーまで通信できるか
4. 必要なポートへ接続できるか
5. Webサーバーが起動しているか
6. アプリケーションが正常か
7. データベースへ接続できるか

最初からデータベースの中身を調べても、実際にはDNSの設定ミスだったということがあります。

通信確認には、pingコマンドを使うことがあります。

ping 192.168.1.10

ただし、pingに応答しない設定もあるため、pingが失敗しただけでサーバー停止とは判断できません。

詳しい見方は、pingコマンドの使い方と通信確認の方法で解説しています。

Linuxサーバーで最初に確認するコマンド¶

Linuxサーバーへ接続できる場合は、次のようなコマンドを使います。

date
uptime
free -h
df -h
systemctl --failed

それぞれの目的は以下です。

すべての障害で、このコマンドを機械的に実行する必要はありません。

ただ、サーバー全体の状態を短時間で把握するには役立ちます。

ログは障害発生時刻を基準に確認する¶

ログには大量の情報が記録されています。

最初からすべて読むと、どのメッセージが障害に関係しているのか分からなくなります。

先ほど記録した障害発生時刻を基準に、前後のログを確認します。

systemdで管理されているサービスなら、journalctlを使えます。

sudo journalctl --since "2026-07-14 10:10:00" \
  --until "2026-07-14 10:40:00"

Nginxのログを確認する場合は、次のように実行します。

sudo tail -n 100 /var/log/nginx/error.log

リアルタイムで追いかける場合は、-fを付けます。

sudo tail -f /var/log/nginx/error.log

ログの確認方法は、Linuxでログを監視するtailとlessの使い方でも解説しています。

エラーだけを探さない¶

ログを見るときは、errorという文字だけを検索しがちです。

しかし、障害の原因が必ずエラーとして記録されるとは限りません。

例えば、設定の読み込み、サービスの停止、接続先の変更など、正常なメッセージの中に原因が残っていることもあります。

障害発生前から順番に読み、何が変わったのかを確認しましょう。

復旧と原因調査を分けて考える¶

障害対応では、サービスを復旧させることと、原因を調べることを分けて考えます。

例えば、新しい設定を反映した直後にWebサーバーが停止したとします。

原因を完全に調べるには時間がかかるかもしれません。

しかし、以前の設定へ戻せば、短時間で復旧できる可能性があります。

この場合は、まず切り戻してサービスを復旧し、そのあとで新しい設定の問題を調査します。

復旧方法にはリスクがある¶

再起動、設定の切り戻し、別サーバーへの切り替えなど、どの復旧方法にもリスクがあります。

実行する前に、次を確認します。

• 何が変わるのか
• 利用者への影響はあるか
• 元に戻せるか
• データが失われないか
• 作業後に何を確認するか

復旧作業そのものが、新しい障害を起こすこともあります。

そのため、急いでいるときほど、実行する内容を短くてもよいので記録します。

復旧したら終わりではない¶

サービスが表示されるようになると、障害対応が終わったように感じます。

しかし、復旧後の確認も必要です。

Webサイトなら、トップページが表示されるだけでなく、ログイン、検索、登録、決済など、重要な機能を確認します。

監視アラートが消えたか、ログに同じエラーが続いていないかも確認します。

さらに、利用者へ復旧したことを共有します。

11時05分にWebサービスの復旧を確認しました。
設定を直前の状態へ切り戻しています。
ログインと主要画面の表示を確認済みです。
原因の詳細は引き続き調査します。

復旧時刻と確認した内容を残しておくと、あとで障害報告を作成しやすくなります。

エンジニア歴10年で感じた障害対応の大切なこと¶

私はエンジニアとして10年以上、サーバーやネットワーク、Webシステムのトラブルに関わってきました。

その中で感じるのは、障害対応が速い人は、最初から原因を当てられる人ではないということです。

状況を整理し、確認した事実を一つずつ積み上げられる人です。

経験が少ないころは、知っているコマンドをたくさん実行すれば、原因へ近づけると思っていました。

しかし、関係のないコマンドを打ち続けると、情報が増えすぎて、かえって分からなくなることがあります。

また、直前に変更した場所が怪しいと思い込み、ほかの可能性を見落としたこともあります。

障害対応では、知識だけでなく、事実と推測を分ける力が必要です。

分からないことを、分かったふりをする必要はありません。

分からないことを明確にし、次に何を確認すれば分かるのかを考えることが大切です。

インフラ障害対応でやってはいけないこと¶

最後に、初心者の方が特に注意したい行動を整理します。

特に、複数の設定を一度に変更しないことは重要です。

1つ変更したら結果を確認し、改善しなければ元へ戻す。

この繰り返しによって、どこに原因があるのか少しずつ絞れます。

インフラ障害が起きたときの確認手順まとめ¶

インフラ障害が発生したとき、最初にやるべきことはコマンドを打つことではありません。

何が起きているのか、どこまで影響しているのか、直前に何が変わったのかを整理することです。

その後、次の順番で進めます。

1. 障害発生時刻と現象を記録する
2. 影響範囲と正常な範囲を確認する
3. 関係者へ現在の状況を共有する
4. 大きい範囲から原因を切り分ける
5. ログや監視情報を確認する
6. 復旧方法とリスクを判断する
7. 復旧後に主要な機能を確認する
8. 原因調査と再発防止を行う

障害が起きると、早く直さなければと焦ります。

しかし、焦って手を動かすより、最初の数分で状況を整理した方が、結果的に早く復旧できることがあります。

障害対応は、正解のコマンドを暗記する作業ではありません。

現象を確認し、仮説を立て、1つずつ確かめる作業です。

障害対応を実際に練習したい方へ¶

障害対応は、記事を読んだだけですぐにできるようになるものではありません。

Linuxを操作し、サービスを起動・停止し、ログを確認する経験が必要です。

InfraAcademyでは、ブラウザ上のLinux環境を使いながら、Linuxの基本操作からサーバー構築まで学習できます。

Linuxの基礎から始めたい方は、Linux入門講座を確認してみてください。

サービス管理やログ確認まで学びたい方は、Linux中級講座やサーバー構築講座がおすすめです。