障害対応の手順の考え方
障害対応はやみくもに触るのではなく、決まった順序で切り分けると速く確実です。まず「いつ・何が・どう変わったか」を現象として正確につかみ、次にログを確認して手がかりを探します。続いてCPU・メモリ・ディスクといったリソースの全体像を見て、最後に怪しいプロセスやサービスを個別に深掘りします。推測で設定を変える前に、観測した事実を積み上げるのが鉄則です。
障害対応とは、勘で当てる作業ではない。観測した事実を順番に積み上げて、原因を1つずつ消し込んでいく作業だ。決まった順序で切り分ける――この型を身につけておくと、慌てる場面でも落ち着いて、速く確実に原因へたどり着ける。
サーバやアプリの調子が悪いとき、つい手が伸びるのが「とりあえず再起動」や「たぶんここだろうと設定を書き換える」だ。だが、これはいちばんやってはいけない一手である。
運よく直ることはある。だが原因が分からないまま直れば、同じ障害がまた起きる。推測で触った変更が、新たな問題を生むこともある。
型がないと、直ったのか偶然なのかも分からないまま、同じ障害を何度も踏むことになる。やみくもに触る前に、まず順序を決める。
📝 まず、何が起きているのかを言葉にする
最初にやるべきは、何が起きているのかを言葉で正確に書き出すことだ。「いつから」「何が」「どう変わったか」の3点をはっきりさせる。
たとえば「14時頃から」「Webサイトの表示が」「ときどき非常に遅い」といった具合だ。『遅い』『つながらない』『落ちる』は症状がまったく違う。ここを曖昧にしたまま調べ始めると遠回りになる。
あわせて、障害の直前に何か変更（デプロイ、設定変更、アクセス急増など）がなかったかを思い出す。多くの障害は「直前に変えたこと」が引き金だ。変更点が分かれば、原因のほとんどが見える。
ここで uptime を打つと、サーバがいつ起動したか（再起動していないか）と、現在の混み具合の目安であるロードアベレージを一目で確認できる。現象把握の出発点になる。
🔎 ログ・全体・個別の順で掘る
現象がつかめても、いきなり個別のプロセスをいじってはいけない。広いところから順に絞り込むのが鉄則だ。
次に見るのはログである。障害の原因は記録として残っていることが多い。systemd環境なら journalctl で各サービスのログを横断的に読める。
journalctl が読みに行く先は、journald というログ収集の仕組みだ。サービスごとに別々のファイルを探し回らなくても、同じコマンドで串刺しに確認できる。
とくに journalctl -p err --since today のように深刻度と時刻で絞れば、今日出たエラーだけを一発で抜き出せる。エラーや警告の行が、原因へまっすぐ導いてくれることがよくある。
ログに決定的な手がかりがなければ、次はリソースの全体像を見る。CPU・メモリ・ディスクのどれかが限界に達していないかを top や free、df で俯瞰し、システム全体のどこが詰まっているか（ボトルネック）の当たりを付ける。
ボトルネックとは、ある一箇所が全体の足を引っ張って性能を頭打ちにしている状態のことだ。たとえばCPUに余裕があっても、ディスクが遅ければ全体はそのディスクの速さで頭打ちになる。
どこがボトルネックかを特定できれば、対処すべき場所と方向がはっきり定まる。
全体像で「CPUが張り付いている」「メモリが枯渇している」「特定のディスクが満杯」といった当たりが付いたら、最後にその原因となっている個別のプロセスやサービスを深掘りする。
CPUを食っている犯人を top で特定する、ディスクを埋めているディレクトリを du で掘る、待ち受けポートを ss で確認する、といった具合に、絞り込んだ対象だけを精密に調べる。
この「広く見てから狭く掘る」順序が大切だ。逆に最初から個別を疑うと、見当違いのプロセスをいじって時間を浪費しがちになる。
☝ 変更は一度に1つだけ
原因の見当が付いて対処に移るときの鉄則が、「変更は一度に1つだけ」だ。
設定変更・サービス再起動・パラメータ調整などを同時にいくつもやると、仮に直っても何が効いたのか分からない。知見が残らない。
1つ変えるたびに、本当に現象が改善したかを検証する。検証も「たぶん直った」ではなく、最初に書き出した現象（遅い・つながらない等）が実際に解消したかを、同じ手順を再現して確かめる。
直っていなければ、変更を元に戻してから次の仮説に移る。こうすると状態がこんがらがらない。
あわせて、設定ファイルを書き換えるときは cp httpd.conf httpd.conf.bak のように変更前のバックアップを取っておく。いつでも元に戻せて安心だ。
🗒 観測した事実を、時刻つきで残す
切り分けと並行して大切なのが、観測した事実を時刻つきで書き残すことだ。
「14:05 uptime でロードアベレージ12を確認（4コア）」「14:08 journalctl にOOMの記録あり」のように、打ったコマンド・出力の要点・時刻をメモしていく。
これには3つの効能がある。1つ目は、同じ調査を二度繰り返す無駄を防げること。
2つ目は、複数人で対応するとき「誰が何を確認済みか」を共有でき、作業の重複や見落としを防げること。
3つ目は、収束後に原因と対処を報告したり、再発防止策を立てたりする際の確かな証拠になることだ。
記憶や勘ではなく観測した事実だけを根拠にすると、報告に説得力が出る。次に同じ障害が起きたときの対応も速くなる。慌てている場面ほど、この記録の習慣が後で効いてくる。
🚨 本番障害で、この型はどう効くか
この手順は、本番障害のような切迫した場面でこそ威力を発揮する。焦って手を動かしたくなる。
だが、まず uptime と journalctl で現象とログを押さえ、top と free、df で全体を俯瞰し、当たりが付いてから個別を掘る――という流れを最初の数分でなぞるだけで、対応の質が大きく変わる。
調べた事実は、コマンドの出力や時刻も含めてメモに残しておく。後から原因を報告したり、再発防止策を考えたりするときの証拠になる。
とくにチームで対応する場面では、「何を観測し、何を試し、結果どうだったか」を共有できると、二重作業や見落としを防げる。
障害対応は属人的な勘ではなく、再現できる手順に落とし込めるスキルだ。まずはこの型を体に染み込ませることが、すべての出発点になる。つまずいたら、まず uptime で現象を押さえるところから始めればいい。