「たまにエラーになる」という報告を受けて画面を開いたものの、そのときには正常に戻っていて手がかりが残っていない状況に向き合う一人運用の保守担当者
障害対応・運用監視約15分

断続的に落ちる障害（フラッピング）の追い方｜記録から正体をつかむ

「さっきエラーが出たんですけど、今もう一回見たら普通に開けました」 「監視から落ちたと通知が来たのに、ログインしたら復旧していた」 「週に何回か、なんとなく重い時間があるらしい」

——こういう報告、いちばん追いにくいですよね。落ちっぱなしなら、いま見えているものを調べればいい。でも断続的に落ちて、自分で直ってしまう障害（フラッピング）は、こちらが見に行った時点で証拠が消えています。

そして厄介なのは、直ってしまうがゆえに優先度が上がりにくいことです。「まあ動いてるし」で先送りになり、そのあいだも報告だけは静かに積み上がっていく。心のどこかで気にし続けている状態が、いちばん消耗します。

この記事では、この断続的な障害を「運よく現場を押さえる」ではなく、記録を並べて正体を絞るやり方で追う手順を一緒に整理します。環境や構成で細部は変わりますが、順番はそのまま使えます。

結論：断続障害は、発生の瞬間を捕まえに行く前に、過去の発生時刻を並べるほうが早く進みます。手順は、①いつ起きたかの「点」をかき集める → ②その点が規則的か不規則かを見る → ③同じ時刻に動いていたもの（cron・バックアップ・アクセス増・外部の処理）と重ねる → ④次に落ちたとき証拠が残る仕掛けを先に入れる → ⑤仮説を1つに絞って、次の発生で答え合わせをする。再起動やサービス再開で「とりあえず直った」を繰り返すと、点が消えて追跡がふりだしに戻ります。直す前に、時刻とログだけは先に確保します。

なお、断続的に見える事象のなかには、利用者側の回線や端末が原因のものも混ざります。全部をサーバー側の問題と決めつけず、点を並べる段階で「特定の人だけか、全員か」も一緒に見ていきます。

何が起きているか：フラッピングは「証拠が自分で片づく」障害

フラッピング（flapping）は、もともと監視の世界で「異常と正常を短い間隔で行き来する状態」を指す言葉です。落ちて、戻って、また落ちる。監視の通知が「ダウン」「復旧」を繰り返すあの状態です。

追いにくい理由は、能力の問題ではありません。構造として、調べに行くころには証拠が残っていないからです。

つまり、断続障害の調査は「証拠を見つける」ではなく「証拠を残す側に回る」仕事です。そう考え直すと、やることがはっきりします。まずは、いま手元に残っている点をかき集めるところからです。

追う順番：点を集めて、重ねて、仕掛けを入れる

障害の発生時刻を時間軸に並べたとき、等間隔に並ぶ場合と間隔がバラバラな場合とで、疑う相手が変わることを示した比較図
発生時刻を並べると、規則的か不規則かが見える。ここで疑う相手が変わる

順番はシンプルです。集める → 重ねる → 仕掛ける。焦って一気に原因を当てにいかず、この3段だけを進めます。

① 発生時刻の「点」をかき集める

最初にやるのは、原因探しではなく日時の一覧づくりです。紙でもスプレッドシートでも構いません。1件1行で、次を書きます。

点は、あちこちに散らばっています。集めやすいところから順に。

# 直近1週間のうち、5xxが出た時刻を「日 時」単位で数える（nginxの既定ログ形式の例）
awk '$9 ~ /^5/ {print $4}' /var/log/nginx/access.log | cut -c2-15 | sort | uniq -c
# systemd 管理のサービスが再起動した記録を、時刻付きで拾う
journalctl -u <サービス名> --since "1 week ago" | grep -iE "start|stop|fail"

10件も並べば十分です。3件でも、並べる価値はあります。ここが後の全部の土台になります。

② 規則的か、不規則かを見る

点が並んだら、次は間隔を眺めるだけです。ここで疑う相手が大きく変わります。

ここで一呼吸。時刻を並べて眺めるだけの作業は、何も直していないように感じるかもしれません。でも、断続障害でいちばん効くのがこの工程です。すでに「運まかせ」から「調査」に変わっています。

③ 同じ時刻に動いていたものと重ねる

間隔の見当がついたら、その時刻に何が動いていたかを突き合わせます。ここが正体に届く一番の近道です。

# 定時実行の一覧を出して、発生時刻と見比べる
crontab -l                      # 自分のユーザー
sudo crontab -l -u <ユーザー名>  # 他ユーザー
ls -l /etc/cron.d/ /etc/cron.daily/

重ねる相手の候補です。

# カーネル側の記録を時刻付きで見る（OOMやI/Oエラーの痕跡を探す）
dmesg -T | grep -iE "oom|killed process|error|reset"

一致するものが見つかったら、それが仮説の第一候補です。見つからなくても大丈夫です。「定期実行ではなさそう」と分かっただけでも、探す範囲は確実に狭まっています。

④ 次に落ちたとき、証拠が残る仕掛けを入れる

ここまでで当たりがつかないときは、次の発生を待ち伏せる準備に切り替えます。張り込むのではなく、勝手に記録が残るようにします。一人運用では、こちらのほうが現実的です。

# 例：5分おきに、メモリ・ディスク・プロセス数を1ファイルへ追記する（最小構成）
*/5 * * * * { date; free -m; df -h; ps aux --sort=-%mem | head -5; } >> /var/log/snapshot.log 2>&1

追記し続けるファイルは、それ自体がディスクを埋めてしまわないよう、ローテーションの対象に入れておくと安心です。

⑤ 仮説を1つに絞って、次の発生で答え合わせをする

最後は、仮説を1つだけ立てて、確かめる。同時にいくつも変えないのが要点です。

止まれば仮説は当たり。止まらなければ、その仮説を消して次へ。消せた仮説も成果です。断続障害の調査は、当てにいく作業ではなく、消していく作業だと思っておくと気持ちが楽になります。

そして、確かめ終わるまでは、点を消さない。安易な再起動で戻すのは応急処置と割り切り、戻す前に「時刻・画面・ログの該当部分」だけは控えておきます。

具体例：「夕方だけ、たまに重くて開けない」を追う

よくある形を、順番にたどってみます。

もし「重いです」の報告のたびに再起動して終わりにしていたら、7件の点はどこにも残らず、原因は今も分からないままだったはずです。重なった条件が見えたのは、時刻を並べたからでした。

影響：追う順番を持つと、何が変わるか

断続障害に順番を1つ持っておくと、直す力そのものより先に、消耗が減ります。

逆に、そのつど再起動で流していると、点が消え、毎回ふりだしに戻ります。順番は、未来の自分の時間を守る道具です。

明日やること：発生時刻の一覧を1枚つくる

立派な資料は要りません。明日できる、いちばん小さな一歩はこれです。

  1. メモを1枚（またはスプレッドシート1シート）用意する。列は「日時／誰が・どこで／どう見えたか／どのくらいで戻ったか／そのとき動いていたもの」の5つだけ。
  2. いま思い出せる分、監視通知やチャットから遡れる分を書き出す。3件で十分です。時刻が「たぶん夕方」でも書いておきます。
  3. 並べて眺める。等間隔か、時間帯が固まっているか、バラバラか。ここで仮説がひとつ浮かべば上出来です。
  4. crontab -l を1回叩いて、定時実行の時刻と見比べる。一致があればメモに書き添えます。
  5. 報告の受け口に「発生時刻」を必ず聞く一言を足す。「何時ごろでしたか」と聞くだけで、点は勝手に増えていきます。

きれいに整える必要はありません。次に落ちたときに書き足せる場所がある——それだけで、この障害はもう「たまたま起きるもの」ではなく、追える対象に変わります。

断続障害チェックリスト

追いかけるときに、これだけ確認できているかを見る項目です。全部を毎回そろえる必要はありません。

まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。

次の項目は、当たりがつかないとき・長引いているときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「直す前に時刻を控える」さえ習慣にできれば、次の1回から調査の材料が増えていきます。

よければ、こちらも

断続する障害は、「記録が残っているか」で難易度が変わります。監視とログの側を少しずつ整えておくと、次の1件がぐっと軽くなります。

発生時刻を並べた記録から断続的な障害の条件を突き止め、原因が見えたことに安心して穏やかな表情を見せる一人運用の保守担当者

断続的な障害がしんどいのは、調べる時間より、「また起きるかもしれない」と気にし続ける時間のほうが長いからだと思います。しかも直ってしまうので、誰にも急いでもらえない。ひとりで抱えたまま日が過ぎていく感じは、本当にこたえます。

でも、この種の障害は、粘りや運で解くものではありません。時刻を並べて、重ねて、記録が残る側に回る。それだけで、見えなかったものが少しずつ形になります。今日いきなり原因までたどり着かなくても大丈夫です。今日ひとつ時刻を書き留めておけば、次に落ちたときの自分は、ゼロから始めずに済みます。

まずは、覚えている発生時刻を1行書くところから。それがもう、この障害を追い始めた証拠です。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語