この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxの現場では、このフレーズをよく耳にする。エラーが出ても、次に確認すると正常に動いている。忙しい中で優先度を下げ、「また出たら考えよう」と先送りにしてしまう。
この記事では、そんな「再現しない問題」を様子見し続けた結果、本番サーバーが深夜に突然クラッシュした私自身の経験を元に、間欠障害（不定期に発生する障害）との正しい向き合い方を解説する。20年以上Linuxサーバーを運用してきた経験から、間欠障害を解決するために必ず実践している3つの習慣をお伝えする。
この記事のポイント
・「再現しない」問題を放置すると、必ず最悪のタイミングで本番が崩壊する
・間欠障害の解決は「エラーが出た瞬間の状態を記録する」ことから始まる
・sarやjournalctlで定点観測を続け、症状のパターンをつかむことが重要
・時間帯・周期・リソース閾値で再現条件を絞り込めば、根本原因は必ず見つかる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「再現しない」を放置するとどうなるか
間欠障害が危険な理由は、「症状が出ていない時間帯は完全に正常に見える」という点にある。ほとんどの間欠障害は、何らかのリソース不足やタイミングの問題が根本原因になっている。
・メモリリーク：少しずつ消費が増え、ある閾値を超えると症状が出る
・ディスクの断続的な消費：空き容量が徐々に減少し、臨界点で一気に問題が表面化する
・cronやバッチとの競合：特定の時間帯に負荷が集中し、他のサービスを圧迫する
・ネットワーク機器の不安定：断続的なパケットロスや遅延が時折発生する
これらは全て、「今は大丈夫」という状態が長期間続いた後に、突然臨界点を超える。それが深夜だったり、月末の繁忙期だったり、システムにとって最悪のタイミングで必ず起こる。
私がセミナーで3,100名以上を指導してきた中で、「間欠障害を放置していて大きな障害を起こした」という経験を持つエンジニアは、想像以上に多い。問題は「再現しない」ことではなく、「記録しない」ことにある。
私が経験した間欠障害の実態
1. 「たまにWebサーバーの応答が遅くなる」という報告
当時、私が管理していたのは社内向けのWebアプリケーションサーバーだった。ある日、ユーザーから「時々ページの表示が遅くなる」という報告が来た。確認してみると、その時点では正常に動作している。Apacheのプロセス数も正常、メモリ使用率も問題なし。ログを見ても目立ったエラーは出ていない。
「ネットワークの一時的な問題かもしれない」「ブラウザのキャッシュの問題かも」と思いながら、そのまま様子見にした。この判断が後の大きなミスに繋がることは、その時点では分からなかった。
2. ログを残さずに6週間が経過した
その後、同じ報告が週に数回届くようになった。確認するたびに「今は正常」で終わる。私が犯した最大のミスは、エラーが出ていた時間帯のログをきちんと収集・保管しなかったことだ。
報告を受けるたびに手動でチェックしていたが、症状が出ていない時点で確認しているため、何も分からない。そのうちに「たまに遅くなる問題」は現場の「既知の問題」になり、誰も本格的に調査しなくなっていった。
3. 深夜のクラッシュ
6週間後の深夜、オンコールの電話で叩き起こされた。「Webサーバーが全く応答しない」という連絡だった。接続してみると、Apacheのプロセスが大量に起動して応答不能になっていた。メモリ使用率はほぼ100%。原因を調査すると、Webアプリ側のセッション処理にメモリリークがあることが判明した。
原因が分かった時、真っ先に思い出したのは6週間前の最初の報告だった。あの「たまに遅くなる」は、メモリが少しずつ増えていたサインだったのだ。
あの6週間、sarコマンドでメモリ使用率を記録し続けていれば、緩やかな上昇傾向を早期に発見できていた。そう気づいた時、「記録しないことの代償」を痛感した。
間欠障害の本質｜なぜ「再現しない」のか
間欠障害が再現しない理由には、いくつかのパターンがある。理解しておくと、調査の方針が立てやすくなる。1. タイミング依存の問題
cronジョブやバッチ処理が特定の時間にのみ負荷を引き起こす。確認のタイミングがずれると症状が出ない。
2. リソース消費の累積
メモリリークやディスクの断続的な消費など、少しずつ積み重なって閾値を超えた時だけ症状が出る。
3. 外部依存の問題
特定のIPからのアクセス集中、外部APIの断続的な遅延、ネットワーク機器の一時的な問題など。
4. 競合条件（Race Condition）
複数のプロセスが同じリソースに同時アクセスした時だけ起きる問題。滅多に発生しないため再現が難しい。
これらに共通するのは、「エラーが出た瞬間」の状態を記録していないと、後から原因を特定できないという点だ。「再現しない問題」が難しいのは、問題そのものが複雑だからではなく、記録がないから手がかりがないのだ。
間欠障害を解決する3つの習慣
1. エラーが出た瞬間の状態を必ずログに残す
間欠障害で最も重要なのは、「症状が出た瞬間の状態を記録する」ことだ。私が現場で使っているのは、エラーログをリアルタイムで監視しながら、その瞬間のサーバー状態も自動で記録するシェルスクリプトを常時動かしておく方法だ。
# エラーログをリアルタイム監視しながら、発生時の負荷情報もセットで記録する tail -f /var/log/httpd/error_log | while read line; do { echo "$(date '+%Y-%m-%d %H:%M:%S') $line" echo "--- Memory ---" free -m echo "--- Top processes ---" ps aux --sort=-%mem | head -10 } | tee -a /var/log/debug/error_with_status.log done
tail -fの詳細な使い方は「tail -fコマンドでログをリアルタイムに監視する方法」で解説している。
2. 定点観測でパターンをつかむ
間欠障害を解決するためには、「エラーが出た時」だけでなく、「正常な時との差分」を見ることが重要だ。そのために役立つのが、定点観測のデータだ。sarコマンドを使うと、CPUやメモリの使用状況を時系列で記録し、後から振り返ることができる。
# sysstatをインストール（RHEL/AlmaLinux系） dnf install sysstat # sarで今日のメモリ使用率を時系列で確認（10分おきの記録） sar -r # 特定の日（25日）の記録を確認 sar -r -f /var/log/sa/sa25
# 今日のエラー・警告を時系列で確認 journalctl -p err -S today # 特定のサービス（httpd）のログを日付指定で確認 journalctl -u httpd -S "2026-07-01" --no-pager | less
journalctlの詳しい使い方は「journalctlコマンドでsystemdのログを確認する方法」を参照してほしい。
3. 再現条件を論理的に絞り込む
ログとサーバーの状態記録が溜まってきたら、再現条件を絞り込む作業に入る。20年以上の現場経験で気づいたのは、「条件を絞り込む」という作業自体に型があるということだ。私が現場で使っている絞り込みの観点は次の5つだ。
・時間帯：特定の時間に集中して発生していないか
・曜日・周期：週次・月次のバッチ処理と一致していないか
・リソース使用量：CPUやメモリが特定の閾値を超えた直後に発生していないか
・アクセスパターン：特定のIPアドレスやURLへのアクセスが関連していないか
・直前のイベント：dmesgや/var/log/messagesで、直前に何かエラーが出ていないか
これらを一つひとつ照合していくと、「○○の条件が重なった時だけ発生する」という再現条件が浮かび上がってくる。完全な再現条件が分かれば、テスト環境で再現させて根本原因を特定できる。
本記事のまとめ
| 習慣 | 具体的な方法 |
|---|---|
| エラー発生時の状態を記録 | tail -f ＋ while ループでログと負荷情報をセット保存 |
| 定点観測でパターンをつかむ | sar -r・journalctl -p err で時系列の推移を確認 |
| 再現条件の絞り込み | 時間帯・周期・リソース閾値・アクセスパターンを照合 |
20年以上サーバーを運用してきた経験から言うと、間欠障害の根本原因が「完全に不明のまま」終わった案件はほぼない。記録を残し、パターンを探し、条件を絞り込む。この3ステップを地道に続ければ、必ず糸口は見つかる。
「再現しない問題」という言葉で片付けることをやめた日から、障害対応の質は確実に変わる。次に間欠障害が発生した時は、まず記録することから始めてほしい。
「再現しない」を「必ず解決できる」に変える実力を、体系的に身につけませんか？
間欠障害への対応力は、Linuxサーバー運用の基礎知識が土台にあってこそ磨かれます。個別のトラブル対応を断片的に覚えるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
・Linuxの「動いている」を信じすぎると痛い目に遭う理由｜現役講師が語る監視と確認の習慣
・障害発生時の第一報を上手く書ける人が現場で信頼される理由｜現役講師が教えるインシデント連絡の型
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：LinuxのApache設定ミスで本番サーバーが止まった日の話｜httpd -tを「毎回打つ習慣」が生まれた経験
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます