「再起動したら直った」で終わっていい？原因に近づく、小さな障害テスト
動き出してほっとしたのに、翌日また止まった。そんなとき欲しいのは、次にも使える手掛かりです。大規模な障害研究から、一つだけ条件を変える調べ方を持ち帰ります。
この記事の目次
直った後に、次へ残す一行がある
画面が止まった。再起動したら動いた。ほっとして、そのまま作業へ戻る。翌日また止まって、今度も同じことを試す。こんな往復をすると、使える時間も自信も少しずつ減ってしまいますよね。
再起動で復旧できたことは大事です。その上で、次に欲しいのは「何が変わって動いたか」を調べる手掛かり。止まった時刻、直前の操作、出ていた表示を一行ずつ残すだけでも、次は同じ地点から始められます。
この記事で考えるのは、障害を派手に起こす方法より、調べられる大きさへ小さくする方法です。大規模システムの研究にも、この小ささが出てきます。
大きな障害の入口が、小さなエラー処理だった
Yuan氏らは2014年、五つの分散データシステムで報告された198件の障害を分析しました。深刻な結果へつながった不具合の中に、エラーを受けた後の基本的な処理の問題が含まれていた、と報告しています。成功する経路だけを試すと、その分岐へ入れないんですね。[1]
さらに面白いのは、調べた障害のほぼすべてが、三台以下の構成で再現できたという報告です。何千台もある本番環境を丸ごと作り直さなければ調べられない、とは限らない。ただし、入力を何個か組み合わせ、起こす順番も合わせる必要がありました。小さくするのは規模であって、失敗に必要な条件まで省いてよいわけではないんです。[1]
たとえば、ファイルが読めたら次へ進む処理で、読めなかったときに何も表示せず、同じ操作を永遠に繰り返す。利用者には「待っている画面」に見えても、内側は一歩も進んでいないかもしれません。正常時に動くことと、失敗した後に戻れることは別の問いです。
同じ操作で、失敗の条件を一つだけ変える
小さなテストにするなら、「読める」「返事が来ない」「返事は来たが内容が違う」の三つに分けます。全部を同時に壊すと、何の確認で止まったか分かりにくい。入力と処理をそろえ、変えるのは失敗の条件だけにします。
下の図は、外部へ問い合わせる架空の処理です。タイムアウトを選んだとき、利用者へ戻るのか、待ち続けるのか。返事の中身が違うとき、それを成功として次へ渡していないか。この二つを、正常時と横に並べて追ってください。
観察する人によって健康に見えたり異常に見えたりする問題は、Huang氏らのGray Failureの論考でも扱われています。監視の「応答あり」だけでは、欲しい仕事が終わったかは分からない。テストでも「プロセスが生きている」と「結果を返せる」を分けておくと、見逃しを減らす問いになります。[3]
期待する表示を「問題が発生しました」だけにすると、次も利用者は何をすればよいか迷います。「一定時間返事がなかったので、この操作は完了を確認できませんでした」とするのか、「変更前の状態へ戻しました」とするのか。実際に保証できる状態を言葉にしておくと、テストでも確かめるべき内容が決まります。
ここで、返事が来なかったことと、相手が何もしなかったことも区別したいところです。相手は処理を終えたのに、返事だけが失われる場合がある。読み直せば済む問い合わせと、もう一度実行すると二重になる注文では、次の一手が変わる。タイムアウトの練習を、単なる待ち秒数の設定で終わらせない理由です。
つまり、テストで欲しいのは赤いエラーを出す演出より、「この失敗なら、ここで止めて、こう知らせる」という約束です。待ち時間の上限、再試行の回数、利用者へ返す表示、調査用に残す記録。それぞれに確かめる場所があります。
再試行にも境界が要ります。読むだけの処理と、代金を請求する処理では、同じ操作をやり直す意味が違う。何度も実行してよいかが分からない処理は、回数を増やす前に、その操作が二重にならない設計を確認します。
成功したかより、失敗の後に戻れるか
- 1正常な返事
同じ問い合わせで、この条件だけを変える
- 2期待する終わり方
結果を確かめ、成功を返す
- 3残す手掛かり
成功の記録
成功の経路だけでは、残り二つの分岐を試せません。
手元で試すなら、外へつながらない練習から
まずは下の短いPythonの例で十分です。外部のサーバーには接続せず、一回目と二回目は自分でタイムアウトを起こし、三回目に結果を返します。出力が「失敗、失敗、成功」になり、成功の後で繰り返さないことを確認してください。
次に成功する条件を五回目へ変えてみます。試す回数の上限は三回なので、「上限で終了」へ進むはずです。失敗し続けるときに終われることも、期待する結果として書いておく。現実の復旧では、この終わり方が次の担当者へ手掛かりを渡します。
本番環境の通信を切ったり、共有サーバーを止めたりする必要はありません。まず制御できる練習で、条件、予想、実際の出力を並べる。原因を言い当てるより、この順番で候補を減らせることが、次にも使える力になります。
for attempt in range(1, 4):
try:
if attempt < 3: # 5 に変えると、上限まで失敗する
raise TimeoutError("練習用のタイムアウト")
print(attempt, "成功")
break
except TimeoutError:
print(attempt, "失敗")
else:
print("上限で終了")研究の補足と、よくある疑問
再起動前に必ず調査を終えるべき？
復旧を急ぐ場面もあります。作業権限と運用手順に従い、残せる範囲で時刻・症状・変更を記録します。原因を特定するまで停止させ続ける提案ではありません。[3]
出典と確認した範囲（4資料）
出典と、読み取れる範囲
原著の公開要旨・取得できた本文部分・研究レビューと、仕様を確認する公式資料を照合しています。対象と比較条件が違う結果を一つの効果へ合算せず、手元の操作例は編集上の説明例として区別します。確認範囲は資料ごとに示しています。
対象・方法：Cassandra・HBase・HDFS・MapReduce・Redisの利用者報告から無作為に選んだ198障害。
主な結果：小規模な構成で再現できる障害や、エラー処理の問題を分析。
限界：過去の5システムの選定事例。現在の障害全般の予防率を示さない。
確認した範囲
学会主催者の研究紹介・要旨・書誌を確認。本文全体の精読・追試は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：6種類のクラウドシステムの障害・不具合報告を調査。
主な結果：問題の種類と、試験・運用の難しさを整理。
限界：公開報告を使う研究。報告されない障害や現在の全製品へ一般化しない。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：クラウドにおける灰色障害、すなわち観測者によって正常・異常の見え方が異なる問題を整理。
主な結果：単一の監視視点では正常でも、利用側では失敗する状況を扱う。
限界：概念と事例の整理。特定監視製品の失敗率ではない。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：25分散システムのネットワーク分断に関わる136障害を調査。
主な結果：故障の順序・タイミングなどを整理し、テスト環境NEATでも問題を発見。
限界：対象事例の分析と試験。どの障害も単一の小さな試験だけで直せるとはしない。
確認した範囲
学会主催者の研究紹介・要旨・書誌を確認。本文全体の精読・追試は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
この記事は複数文献を照合した編集記事です。既存研究を照合し、結果と条件を紹介しています。研究が同じ参加者を含む可能性があるため、文献間の人数を足していません。本文の行動提案・未来のシナリオは編集上の整理です。
この記事から、次に気になる話へ。
平均は速いのに、ときどき遅い。サイトの「たまに待たされる」は、なぜ消えない？
平均20ミリ秒と聞くと快適そう。でも、その平均を作った10回の中身は？ サーバーを増やすほど遅い一台の影響が広がる仕掛けを、小さな数字で追います。
エラーログがないのに、動かない。調べる人は、どこから読む？
ERRORで検索しても、困っている処理が出てこない。別の利用者のエラーを追っていないでしょうか。ログの量を増やす前に、一つの依頼を最後までたどってみます。
AIとクラウドの時代、インフラエンジニアを目指す価値はある？
「サーバーを触る仕事」は、この先も選べるのか。需要の数字と障害研究から、操作を覚える先にある仕事と、最初に学ぶ順番を見ていきます。