サーバー障害の一次切り分け手順

Linuxサーバーで異常を見つけたときは、すぐに復旧操作へ進む前に、発生時点の状態を同じ順序で確認します。このガイドでは、設定を変えずに状況を整理する一次切り分けに絞ります。

コマンドの利用可否や表示範囲は、OS、導入パッケージ、権限によって異なります。表示できない項目も、その事実と時刻を記録してください。

一次切り分けの目的

目的は、その場で原因を断定することではありません。症状、影響範囲、リソース、サービス、ネットワーク、ログを順番に確認し、次に詳しく調べる対象を絞ることです。複数の兆候がある場合も、観測した事実と推測を分けて記録します。

変更操作の前に状態を記録する理由

操作の前後を比較できるよう、最初に表示結果と確認時刻を残します。後から担当者が変わっても、どの症状が先に現れ、どの範囲まで確認済みかを追いやすくなります。確認中は設定や稼働状態を変える操作へ進まず、組織の障害対応手順と権限範囲を優先してください。

発生時刻・症状・影響範囲を整理する

• 最初に異常を確認した時刻と、その直前まで正常だった時刻
• 遅い、接続できない、処理が終わらないなど、観測できる症状
• 対象ホスト、サービス、利用者、拠点などの影響範囲
• 監視通知、利用者申告、直近作業との時間的な関係

時刻にはタイムゾーンも添えます。別システムのログと照合するときは、表示時刻の基準が同じか確認してください。

1. uptimeとloadを確認する

uptime

稼働時間と、直近1分・5分・15分のload averageを確認します。loadはCPU使用率そのものではなく、実行可能状態または割り込み不能状態にある処理数の平均です。CPU数で正規化されないため、単独の値だけで異常と断定せず、時間方向の変化と次のCPU・メモリ・ディスク確認を組み合わせます。

2. CPUを確認する

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu

CPU使用率が高い順にプロセスを並べ、特定の処理へ偏っていないかを確認します。ただし、%cpu はプロセスが起動してからのCPU時間を稼働時間で割った平均であり、瞬間的な使用率ではありません。最近CPU使用が増えたプロセスが上位に出ない可能性があるため、一度の結果だけで除外せず、時間を置いた再確認や監視の時系列データと比較します。コマンド欄には引数やパスが表示されることがあるため、共有前に機密情報が含まれていないか確認します。

CPU数、load average、実行待ち、I/O待ちまで詳しく調べる場合は、LinuxのCPU高負荷・load averageを切り分ける手順を参照してください。

3. memoryを確認する

free -h

物理メモリとswapの使用状況を読みやすい単位で確認します。free 列だけで判断せず、新しい処理に利用できる量の推定であるavailable とswapの使用状況も記録します。CPU確認の結果と突き合わせ、メモリ使用が偏るプロセスがないか確認します。

MemAvailable、swap in/out、プロセス別のRSS・VSZ、OOM記録まで調べる場合は、Linuxのメモリ不足・swap使用を切り分ける手順を参照してください。

4. disk容量とinodeを確認する

df -hT
df -i

df -hT でファイルシステム種別と容量を、df -i でinode使用状況を確認します。容量に余裕があってもinodeが不足している場合は新しいファイルを作れないことがあるため、両方を確認します。対象マウントポイントと使用率を記録し、組織で定めた監視しきい値があれば照合します。

使用量の多いディレクトリや削除済みopen fileまで調べる場合は、Linuxのディスク容量・inode不足を切り分ける手順を参照してください。

5. service状態を確認する

systemctl --failed
systemctl status <service> --no-pager

systemdを使う環境では、失敗状態のunitを一覧し、対象サービスの現在状態と直近メッセージを確認します。<service> は調査対象のunit名へ置き換えます。コンテナやsystemdを使わない環境では利用できないため、その場合は環境固有の監視画面やサービス管理方法を確認します。

unit設定、終了結果、対象serviceのjournalまで詳しく調べる場合は、Linuxのsystemdサービス失敗・journalctlログを切り分ける手順を参照してください。

6. network・listening port・routeを確認する

ip addr
ip route
ss -lntup

インターフェースに割り当てられたアドレス、経路、待受中のTCP/UDP socketを順に確認します。想定するアドレスと経路が表示されるか、対象サービスが想定ポートで待ち受けているかを照合します。権限によってss のプロセス情報が一部表示されない場合があります。

IPアドレスとプレフィックスの範囲を確認したい場合は、IPv4 CIDR計算を利用できます。

route、待受ポート、名前解決、ICMP、HTTP(S)まで詳しく調べる場合は、Linuxのネットワーク疎通・DNS・待受ポートを切り分ける手順を参照してください。

7. system logを確認する

journalctl -p err -b --no-pager

systemd journalを使う環境では、現在のbootに属するerror以上の優先度のメッセージを表示します。権限やjournal設定によって見える範囲が異なるため、出力がないことだけで問題なしとは断定しません。発生時刻の前後、対象サービス、ほかのリソース確認結果との時間的な対応を見ます。

症状別の次の確認先

情報共有時の機密情報に注意する

コマンド結果には、hostname、IPアドレス、ユーザー名、プロセス引数、ファイルパス、サービス名、log本文などが含まれる場合があります。第三者へ共有する前に、組織の規程に従い、認証情報、個人情報、内部構成を示す値がないか確認してマスクしてください。元データと共有用データを分け、マスク後も内容を見直します。

コマンド仕様の参照先

環境ごとの差やoptionの詳細は、導入されている版のmanualを優先してください。

• procps-ng: uptime(1)
• procps-ng: free(1)
• procps-ng: ps(1)
• GNU Coreutils: df invocation
• systemd: systemctl
• systemd: journalctl
• iproute2: ip-address(8)
• iproute2: ip-route(8)
• iproute2: ss(8)

関連ツール

• IPv4 CIDR計算 — アドレスとプレフィックスからネットワーク範囲を確認
• cron式生成・確認 — 5フィールドcron式と次回候補を確認

確認結果を継続して整理する

確認項目をチェックリスト化し、Windows/Linuxの収集結果とインシデント記録を同じ流れで整理したい場合は、サーバー障害一次切り分けキットの内容も確認できます。一次切り分けだけで結論を急がず、記録をそろえて担当チームへ引き継いでください。