いつもありがとうございます。
「サーバーが動かなくなった。とりあえず再起動しよう」
この判断、PCなら問題ありません。しかしサーバーでは、再起動した瞬間に「何が起きていたか」の証拠が消えてしまいます。
原因が分からないまま再起動すれば、同じ障害は必ず繰り返します。
この記事では、15年以上サーバーを運用してきた経験から、「とりあえず再起動」がなぜ危険なのか、そしてプロのサーバー管理者が障害発生時に最初にやることを5つのステップで解説します。
なぜ「とりあえず再起動」が危険なのか
PCが固まったら再起動。Windowsを使っていれば誰もがやっている習慣です。
しかし、サーバーでこの習慣をそのまま持ち込むと、大きな問題が3つ起きます。
1. ログ（証拠）が消える
サーバー障害の原因を特定するために最も重要なのは、障害発生時のログです。
メモリ上にしか残っていない情報、暴走していたプロセスの状態、一時ファイルに書き出されたエラー情報。これらは再起動した瞬間にすべて消えます。
たとえば、あるプロセスがメモリを4GB食いつぶしていたとしても、再起動後はその痕跡は残りません。
「何が原因だったのか」を後から調べようとしても、手がかりゼロの状態から始めることになります。
2. 原因不明のまま再発する
再起動で一時的に復旧しても、根本原因が残っている以上、同じ障害は必ず再発します。
私がセミナーで3,100名以上を指導してきた中で、「同じ障害が何度も起きるんです」という相談は本当に多いです。話を聞くと、ほぼ全員が「毎回、再起動で対処していた」と言います。
再起動は「治療」ではなく「問題の先延ばし」です。問題一時的に消えるだけで、原因は残ったままです。
3. サービス停止の影響が大きい
PCの再起動で困るのは自分だけですが、サーバーの再起動は利用者全員に影響します。
Webサーバー、データベース、メールサーバー。すべてのサービスが一斉に止まります。
業務時間内であれば、その間のアクセスや処理はすべてエラーになります。
本当に再起動が必要な場面はもちろんあります。しかし「とりあえず」で再起動するのは、影響範囲を把握しないまま全サービスを巻き込む行為です。
プロのトラブル初動｜5つのステップ
では、プロのサーバー管理者は障害が発生した時に何をするのか。
15年以上の運用経験から、私が実践している初動の5ステップをお伝えします。
1. 慌てない（深呼吸する）
精神論に聞こえるかもしれませんが、これが一番大事です。
障害が起きた時、焦って何かしようとすると必ずミスが増えます。私が現場でよく見かけるのが、慌ててコマンドを打ち間違えて状況を悪化させるケースです。
まず深呼吸をしましょう。10秒で構いません。「自分は今、焦っている」と自覚するだけで、判断の質は格段に上がります。
セミナーでも、演習中にエラーが出ると受講生の手が止まります。その時に私が最初に言うのは「大丈夫です。まず画面をよく見ましょう」です。慌てて何かを打つ前に、今の状態を正確に把握することが最優先です。
2. 現状を記録する（スクリーンショット、ログ保全）
次にやるのは「今の状態を記録すること」です。
ターミナルのスクリーンショットを撮る、エラーメッセージをテキストファイルにコピーする、時刻をメモする。この3つだけで十分です。
なぜ記録が先なのか。それは、この後の調査や対処で画面の状態が変わってしまうからです。
「さっき出ていたエラーメッセージ、何だったっけ？」
これを防ぐために、まず記録します。これは鉄則です。
3. ログを確認する
記録を取ったら、次はログの確認です。サーバーは「何が起きたか」をログに記録しています。
# システム全体の直近エラーログを確認する sudo journalctl -p err --since "30 minutes ago" # /var/log/messagesを確認する（従来の方法） sudo tail -100 /var/log/messages # 特定のサービスのログを確認する（例：httpd） sudo systemctl status httpd
「--since "30 minutes ago"」で直近30分に絞れば、関係のないログに埋もれることなく、原因に素早くたどり着けます。
4. 影響範囲を把握する
ログで原因の当たりがついたら、次は「どこまで影響しているか」を確認します。
# サービスの稼働状況を一覧で確認する sudo systemctl list-units --type=service --state=failed # メモリの使用状況を確認する free -m # ディスクの使用状況を確認する df -h # CPU負荷の高いプロセスを確認する ps aux --sort=-%cpu | head -10
この判断ができるかどうかで、対処の方針がまったく変わります。
Webサーバーだけの問題なら、そのサービスだけ再起動すれば済みます。サーバー全体のリソース不足なら、原因プロセスを特定して対処する必要があります。
5. 対処方針を決める
ここまでの情報が揃って、初めて「どうするか」を判断します。
・サービスが停止しているだけ → そのサービスだけを再起動する
・特定のプロセスが暴走している → そのプロセスをkillする
・ディスク容量が不足している → 不要ファイルを削除する
・原因が特定できない → 記録を残した上でサーバーを再起動する
最後の「原因不明なら再起動」は、ステップ1～4の記録がある場合にだけ許される判断です。
記録があれば、次に同じ障害が起きた時に「前回と同じパターンだ」と気づけます。
記録がなければ、毎回最初からの調査になります。
再起動が「正解」になる場面
ここまで「とりあえず再起動は危険」と言ってきましたが、再起動が正しい対処になる場面もあります。
カーネルアップデート後
Linuxカーネル（OSの中核部分）をアップデートした場合、新しいカーネルを有効にするには再起動が必要です。これはサービスの再起動では対応できません。
# カーネルアップデート後、再起動が必要か確認する needs-restarting -r
メモリリークが発生している場合
アプリケーションにメモリリーク（メモリを確保したまま解放しない不具合）がある場合、時間の経過とともにメモリが枯渇していきます。
根本的にはアプリケーションの修正が必要ですが、緊急対応として該当プロセスの再起動（またはサーバー全体の再起動）が有効です。
ただし、この場合も「メモリリークが原因である」という記録を残してから再起動することが大切です。
サーバーが完全にフリーズした場合
SSHでログインもできない、コンソールからも操作できない。完全にフリーズしている場合は、再起動以外に選択肢がありません。
この場合でも、再起動後に /var/log/ 配下のログを確認して、フリーズ直前に何が起きていたかを調べることが重要です。ディスクに書き込まれたログは再起動後も残っています。
新人時代の失敗から学んだこと
私が新人エンジニアだった頃の話です。
担当していたサーバーのWebサービスが応答しなくなりました。お客様からの問い合わせが入り、焦った私は真っ先にサーバーを再起動しました。
サービスは復旧しました。「よかった、直った」と安堵した私に、上司がこう言いました。
「で、原因は何だったの？」
答えられませんでした。
「再起動で直ったは報告じゃない。何が起きていて、何をしたから直ったのか。それが報告だ」
上司の言葉は厳しかったですが、正しかった。
再起動する前にログを見ていれば、原因を特定できたかもしれない。少なくとも「こういう状態だった」という記録は残せたはずです。
案の定、2週間後に同じ障害が再発しました。しかし今度は、上司に教わった通りに初動の記録を取りました。
原因は、あるPHPスクリプトが無限ループに近い状態になり、メモリを食いつぶしていたことでした。ログとプロセスの状態を記録していたから、特定できたのです。
あの時の上司の言葉は、今も私がセミナーで受講生に伝えていることです。
「再起動は最終手段。まずログを見ろ」
よくある質問
Q. 本当に緊急の場合でも、ログを見てから再起動すべきですか？
お客様への影響が深刻で一刻を争う場合は、まずサービスの復旧を優先してください。
ただし、その場合でも「再起動前にスクリーンショットを1枚撮る」だけで、後からの原因調査がまったく違います。10秒で終わる作業です。完全にフリーズしてスクリーンショットも撮れない場合は、再起動後に /var/log/ を確認してください。
Q. 「サービスの再起動」と「サーバーの再起動」は違うのですか？
まったく違います。
# サービスの再起動（httpdだけを再起動する） sudo systemctl restart httpd # サーバーの再起動（OS全体を再起動する） sudo reboot
サーバーの再起動は、OS全体を再起動するため、すべてのサービスが一時的に停止します。
まずはサービス単位の再起動で解決できないかを検討し、それでもダメな場合にサーバーの再起動を検討する。この順番が基本です。
Q. ログの量が多すぎて、どこを見ればいいか分かりません
journalctlの絞り込みオプションを活用してください。
# エラーレベル以上に絞る sudo journalctl -p err --since "30 minutes ago" # 特定のサービスに絞る sudo journalctl -u httpd --since "1 hour ago" # 末尾からリアルタイムで追いかける sudo journalctl -f
まとめ
| ポイント | 内容 |
|---|---|
| 再起動が危険な理由 | ログ（証拠）が消える・原因不明のまま再発する・全サービスに影響する |
| プロの初動 ステップ1 | 慌てない（深呼吸して冷静になる） |
| プロの初動 ステップ2 | 現状を記録する（スクリーンショット、エラーメッセージ、時刻） |
| プロの初動 ステップ3 | ログを確認する（journalctl -p err --since "30 minutes ago"） |
| プロの初動 ステップ4 | 影響範囲を把握する（free -m / df -h / ps aux） |
| プロの初動 ステップ5 | 対処方針を決める（サービス再起動 / プロセスkill / サーバー再起動） |
| 再起動が正解な場面 | カーネルアップデート後・メモリリーク・完全フリーズ |
トラブル対応の「型」を身につけませんか？
障害対応は場数がものを言いますが、基本の「型」を知っているだけで初動が変わります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
P.S
セミナーでは、実際にサーバーでエラーを起こして、その場で原因を特定する練習もします。「トラブル対応の経験を積みたい」という方には最適な環境です。
【Linuxセミナー】リナックスマスタープロセミナー
[Linuxサーバー構築の全体像｜初心者が知っておくべき手順と現場のリアル]
登録10秒／自動返信でDL／合わなければ解除3秒
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
- 次のページへ：短期でLinuxをマスターする人の共通点とは？
- 前のページへ：Linux未経験から年収1000万に変わったキャリア戦略
- この記事の属するカテゴリ：Linux学習ガイドへ戻る