サーバーがダウン：最初に確認すること、その順序

このガイドは、サーバー自体（運用している VPS、専用サーバー、クラウドサーバー）についてです。1 つのウェブサイトだけが失敗していて、マシン上のほかはすべて動いている場合、またはサイトが共有ホスティングにある場合は、代わりにガイドウェブサイトがダウンしたときの対処法から始めてください。ここでは、マシンを見ます。そもそも応答するか、中に入れるか、何が止まったか。

ステップ 1：何がダウンしているのか？

「サーバーがダウンしている」は、まったく異なる 3 つの状態を指す可能性があり、それぞれ対処法が異なります。まず、ご自身のものではないネットワークから、外部で確認してください。サーバー上のウェブサイトについては、ウェブサイトダウンチェッカーが、名前が名前解決されるか、ポートが応答するか、どのステータスコードが返るかを、数秒で教えてくれます。マシンについては、ご自身のパソコンから、ping とポートテストを使います。

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

結果は、あわせて読み取ります。

• ping も SSH もウェブポートも応答なし： マシンの電源が切れている、フリーズしている、または手前のネットワークがダウンしています。ステップ 2 へ。
• ping は応答し、SSH は応答しない： マシンは動いていますが、SSH がブロックまたは停止されているか、サーバーが過負荷で応答できません。ステップ 3 へ。
• SSH は動作し、ウェブサイトは動作しない： サーバーは問題なく、サービスが動いていません。ステップ 4 へ。

一部のサーバーは、意図的に ping を破棄します。ping が一度も動作したことがない場合は、ポートテストを頼りにしてください。

ステップ 2：何も応答しない

まず、プロバイダーのコントロールパネルまたはクラウドコンソールを開いてください。3 つの質問で、ほとんどのケースが 1 分で片付きます。

1. サーバーは稼働していますか？ 停止したインスタンス、停止されたアカウント、支払いの失敗は、外から見ると、障害とまったく同じに見えます。
2. 既知の障害はありませんか？ プロバイダーのステータスページで、お使いのリージョンやデータセンターを確認してください。
3. コンソールには何が表示されていますか？ ウェブコンソールやシリアルコンソールは、ネットワークがなくても、マシンの画面を表示します。カーネルパニック、「Out of memory: Killed process」の繰り返し、ファイルシステムチェックで止まった起動が、それぞれ問題の場所を教えてくれます。

マシンがフリーズしている場合、コンソールからの再起動で、たいてい復旧します。再起動する前に、コンソールのスクリーンショットを撮ってください。再起動すると、証拠は消えます。起動しない場合は、ほとんどのプロバイダーがレスキューシステムを提供しており、そこからディスクをマウントして、ログを読み、/etc/fstab や壊れたネットワーク設定を修復できます。

ステップ 3：ping は応答し、SSH は応答しない

マシンは生きているので、原因はその上にあります。コンソールを使ってログインし、よくある原因を確認します。

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

急いで追加したファイアウォールルール、数回のパスワード間違いの後にブロックされたご自身の IP アドレス、テストに失敗した SSH 設定の変更が、最も多い原因です。アドレスのブロックは sudo fail2ban-client set sshd unbanip YOUR_IP で解除します。SSH を再起動する前には、必ず sudo sshd -t を実行してください。SSH は動いているが、非常に遅いだけの場合は、サーバーが過負荷です。ステップ 4 へ。

ステップ 4：中に入れたら、4 つの数値を読む

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• 負荷（uptime）：CPU コア数をはるかに上回る場合、マシンは過負荷です。top や htop で、どのプロセスが原因かがわかります。
• メモリ（free -m）：空きメモリもスワップもなく、dmesg に「Killed process」がある場合は、カーネルが生き残るためにプロセスを停止したことを意味します。たいていは、データベースか PHP でした。
• ディスク（df -h）：満杯のディスクは、サーバーの問題の最も多い原因です。データベースが書き込みを止め、ログが止まり、セッションが失敗します。df -i は inode を確認します。数百万の小さなファイルがすべての inode を使い切っていると、数ギガバイトの空きがあっても、ディスクが「満杯」になることがあります。
• I/O エラーまたは読み取り専用のファイルシステム（dmesg に表示）：ディスク自体に問題があります。書き込みを止め、まだできるならバックアップを取り、プロバイダーに連絡してください。

安全に容量を空けるには、システムジャーナルと古いアーカイブから始めます。

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

空きを作るために、データベースのファイルやウェブサイトのファイルを削除してはいけません。

ステップ 5：どのサービスが、なぜ停止したか

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed は、エラーで停止したすべてのサービスを一覧表示します。そのサービスのジャーナルに理由が書かれています。すでに使用中のポート、設定ファイルの構文エラー、証明書の欠落、空き容量なし。再起動のたびに、設定をテストしてください（nginx -t、apachectl configtest、php-fpm -t）。そのうえで、sudo systemctl restart SERVICE で起動します。テストなしの再起動は、まだ半分動いていたサービスを落としてしまうことがあります。

ステップ 6：何が変わったか？

障害には原因があり、原因はたいてい直前の変更です。それを探します。

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

自動アップデート、再起動待ちの新しいカーネル、デプロイ、バックアップでディスクを満杯にした cron ジョブ、期限切れの証明書、他の誰かによる設定の編集。これらのいずれかが、障害が始まった時刻と一致すれば、手がかりが見つかったことになります。

同じサーバーの問題が繰り返されるとき

ディスクの満杯や停止したデータベースで一度ダウンしたサーバーは、また同じことを起こします。外部からのチェックは、いつダウンしたかを教えます。内部からのチェックは、その前に教えます。サーバーエージェントは、マシンの内部から、負荷、メモリ、ディスク、サービスを報告し、ディスクがしきい値を超えたときや、チェックを入れたサービスが停止したときに、まだ対処する時間があるうちに、アラートを出します。エージェントによるサーバー監視は、有料プランに含まれます。

午前 3 時にこれをやりたくないとき

サーバーがダウンしていて、自分でデバッグするより、修復を任せたい場合、Quick Fix が一般的な原因を定額で対応します。設定テストに合格した後で停止したサービスを再起動し、満杯のディスクを空け、期限切れの証明書を更新します。先にバックアップを取ります。それで足りない場合は、Deep Fix が 24 時間体制で引き継ぎ、15 分単位で請求し、料金は依頼の前に表示されます。どちらも、Responder、root での SSH、またはウェブスペースへの SSH アクセスを通じて動作します。詳細は、ページサーバーダウンの修復と緊急サーバーサポートをご覧ください。