この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「とりあえずログを見る」「ネットで検索する」「再起動してみる」——そういった動き方をしているうちは、トラブルのたびに時間を溶かし続けることになります。
この記事では、20年以上Linuxサーバーを現場で運用してきた経験から、トラブル切り分けを素早く終わらせる「仮説と検証」の思考法を解説します。コマンドの使い方より先に、この考え方を身につけた方が、現場での問題解決速度は確実に上がります。
この記事のポイント
・トラブル切り分けは「仮説を立てて検証する」繰り返しで進める
・「最後に変更した箇所」から疑うのが最速の出発点になる
・ログ・プロセス・ネットワークの3層を順番に確認する習慣を持つ
・「再現手順を確認する」ことが原因特定の精度を大きく上げる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「動いていたのに動かない」——この状況をどう読むか
サーバーのトラブルには大きく2種類あります。ひとつは「最初から動かなかった」もの。もうひとつは「昨日まで動いていたのに、今日は動かない」もの。
この区別が、切り分けのスタート地点を決めます。
「昨日まで動いていた」なら、必ず何かが変わっています。ソフトウェアのアップデート、設定ファイルの変更、ディスク容量の逼迫、証明書の期限切れ——原因は必ず「変化」の中にあります。
私が現場でよく使う最初の問いはこれです。
「最後に変えたのは何ですか？」
この一言で、調査範囲が劇的に絞られます。担当者が「何も変えていません」と答えたとしても、OSの自動アップデートやNTPのズレ、cronの実行タイミングなど、人の手が入っていない変化が原因であることも多いです。「変化を探す」という姿勢から切り分けをスタートさせる習慣は、20年以上の運用経験の中で一番重要だと実感しています。
仮説と検証のサイクルが問題解決を加速させる
トラブル切り分けで最もやってはいけないのが、「なんとなく」操作することです。コマンドを打ちながら「これが原因かな？」と漠然と思っているだけでは、たとえ問題が解決しても「なぜ直ったか」が分かりません。同じ問題が再発した時に、また同じ時間を費やすことになります。
正しい切り分けのサイクルはこうです。
1. 症状を具体的に言語化する
「なんか遅い」「つながらない」ではなく、もっと具体的にします。・どのコマンドを実行した時にエラーが出るか
・エラーメッセージは何か
・いつから発生しているか（初回？最近？特定の時間帯？）
・特定のユーザーや接続元だけで起きているか、全員に起きているか
この情報を整理するだけで、原因の候補が半分以下に絞られることがほとんどです。セミナーで受講生が持ち込むトラブルを見ていても、「症状を具体化できた瞬間に原因が見える」ケースは少なくありません。
2. 仮説を1つに絞って検証する
「DNSかもしれない、firewallかもしれない、Apacheの設定かもしれない」と複数の可能性を同時に追うと、何が原因で直ったのか分からなくなります。仮説は1つに絞って検証します。たとえば「DNSが原因だと仮説を立てたなら、まずDNSだけを確認する」。
# DNSの名前解決が正しく動いているかを確認する $ dig www.example.com @8.8.8.8 # 自サーバーのDNS設定を確認する $ cat /etc/resolv.conf # ローカルのnslookupで名前解決テスト $ nslookup www.example.com
3. 変更をひとつずつ行い、効果を確認する
「ついでにこっちも直そう」と複数の設定を同時に変えると、どれが効いたか分からなくなります。変更は必ず1つずつ。変更後は必ず動作確認。これを守るだけで、切り分けの精度は格段に上がります。
私がSE時代に先輩から言われた言葉が今でも刺さっています。「一手ずつ指せ。将棋でも麻雀でも、複数手を同時に動かす人間には理由が説明できない」。その通りだと思います。
ログ・プロセス・ネットワークの3層で確認する
仮説を立てたら、実際にどこを見るかが重要です。私が現場で使う基本の3層チェックを紹介します。第1層：ログを確認する
まず最初にログを見ます。エラーメッセージには、原因が書いてあることが多いからです。# systemdのサービスログ（最新50行） $ journalctl -u apache2 -n 50 # システム全体のログをリアルタイム監視 $ journalctl -f # Apacheのエラーログ $ tail -100 /var/log/httpd/error_log # syslogの確認 $ tail -100 /var/log/messages
第2層：プロセスとリソースを確認する
ログで明確な手がかりが得られない場合は、プロセスとシステムリソースを確認します。# サービスの動作状態を確認 $ systemctl status apache2 # プロセスの存在確認 $ ps aux | grep apache2 # CPU・メモリの使用状況 $ top # または $ vmstat 1 5 # ディスク使用量（満杯になっていないか） $ df -h $ du -sh /var/log/*
第3層：ネットワーク接続を確認する
第1層・第2層で問題が見つからなければ、ネットワーク層を確認します。# ポートが開いているか確認 $ ss -tlnp | grep 80 # ファイアウォールのルール確認 $ firewall-cmd --list-all # 接続テスト（サーバー自身から） $ curl -I http://localhost # 名前解決の確認 $ dig example.com
「再現させる」ことが原因特定の精度を上げる
切り分けで意外と見落とされるのが「問題を意図的に再現させる」という作業です。「たまに遅くなる」「ランダムにエラーが出る」という断続的な問題は、原因を直接見られないと特定が難しくなります。そういう時は、問題が発生する条件を特定することが先決です。
・特定の時間帯だけ起きる → cronや自動バッチが原因の可能性
・特定のユーザーだけ起きる → 権限やホームディレクトリの問題
・特定のファイルを操作した時だけ起きる → パーミッションやSELinuxの可能性
「条件を絞ると原因が見える」という原則は、ハードウェアのトラブルでも、ソフトウェアのバグでも同じです。セミナーで受講生に「どういう状況の時に起きるか、絞り込んでみてください」と伝えると、多くの場合はそこで問題が解決することもあります。再現条件の特定が、すでに答えへのショートカットになっているからです。
確認した内容は必ず記録する
切り分けの途中で「今どこまで確認したか」が分からなくなる経験はありませんか。特に複数人で対応している場合、情報が共有されないまま同じ調査を二重でやることも起きます。私が現場でやっていたのは、ターミナルのscriptコマンドでログをそのまま記録することです。
# 作業ログを記録開始 $ script /tmp/troubleshoot_$(date +%Y%m%d_%H%M).log # 記録終了 $ exit
まとめ
トラブル切り分けの思考法を整理すると、以下の表になります。| ステップ | やること | ポイント |
|---|---|---|
| 症状の言語化 | いつ・誰に・どんな症状か具体化 | 「なんかおかしい」は禁止 |
| 変化の特定 | 最後に変更した箇所を確認 | 「何も変えていない」を疑う |
| 仮説の検証 | 1つに絞って確認・外す繰り返し | 複数同時は禁止 |
| 3層チェック | ログ → プロセス → ネットワーク | この順で確認する |
| 再現条件の特定 | いつ・どんな操作で起きるか絞る | 条件を絞ると原因が見える |
| 記録 | 確認した内容をscriptで残す | 再発時の資産になる |
関連記事として、以下もぜひ参考にしてください。
・「エラーが出たら嬉しい」と言えるエンジニアが最速で伸びる理由
・Linuxの「動いている」を信じすぎると痛い目に遭う理由
トラブルを素早く解決できるエンジニアへ。まずは基礎を体系的に固めませんか？
トラブル切り分けの思考法は、Linuxの基礎知識がしっかり身についていてこそ活きます。「なんとなく動かしている」状態を卒業するために、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxの学習スタイルを自分に合わせる方法｜現役講師が語る「型通り」を捨てた方が伸びる人の特徴
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます