障害対応の手順の考え方
障害対応はやみくもに触るのではなく、決まった順序で切り分けると速く確実です。まず「いつ・何が・どう変わったか」を現象として正確につかみ、次にログを確認して手がかりを探します。続いて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 で全体を俯瞰し、当たりが付いてから個別を掘る——という流れを最初の数分でなぞるだけで、対応の質が大きく変わります。調べた事実は、コマンドの出力や時刻も含めてメモに残しておくと、後から原因を報告したり、再発防止策を考えたりするときの証拠になります。とくにチームで対応する場面では、「何を観測し、何を試し、結果どうだったか」を共有できると、二重作業や見落としを防げます。障害対応は属人的な勘ではなく、再現できる手順に落とし込めるスキルだ——そう捉えて、まずはこの型を体に染み込ませることが、すべての出発点になります。