第5部 ループ · 第13回 / 全20回 · 15分くらい
気づかないうちに壊れる仕組みを、気づける仕組みにする
ループでいちばん怖いのは、止まることではなく、止まったことに気づかないことです。この回では、止め方とセットで「気づき方」を最初から作ります。Google の運用の考え方を手がかりに、自分の環境で実際に見つけた失敗を材料にします。
履修 0 / 20 回
この回を読み終えると、できるようになること
- 「最後にうまくいったのはいつか」を見張る理由を、エラーを待つやり方と比べて説明できる
- 成功の記録の「中身」を確かめる方法を3つ挙げられる
- 止める仕組み（上限・止めるスイッチ・連続失敗で休む）と、知らせすぎない工夫を設計できる
専門用語は、初めて出たところで括弧に短い説明を付けています。説明が長くなるものには ※番号を付け、ページの終わりの用語メモにまとめました。
1エラーを待っていても、来ない
止まった仕組みは、エラーを出しません。動いていないので、出す者がいないからです。だから「失敗したら知らせる」だけでは足りません。
別の係が「最後にうまくいったのはいつか」を見張り、決めた時間を過ぎたら知らせます。この見張り方は、デッドマンスイッチ※1と呼ばれる考え方に近いものです。「便りがないのは無事の知らせ」ではなく、「便りがないのは異常の知らせ」として扱います。
2症状を見張り、原因はあとで調べる
Google の SRE本の監視の章では、見張るべきは「何が壊れているか（症状）」で、「なぜか（原因）」はそのあとで調べる、と書かれています。たとえば「ページが表示されない」が症状で、「データベースが応答しない」が原因です。
自分の仕組みに当てはめると、症状は「成果物が届いていない」、原因は「ジョブが落ちた」「入力が読めない」「送り先が無い」などです。原因の数だけ見張りを作ると、見張りのほうが増えすぎます。成果物が届いているかを見張れば、どの原因でも気づけます。
3「成功」の中身を確かめる
終了コードが0でも、中身が空だったり、違う期間を集計していたりします。成功の記録に、次のような数えられる中身を残し、いつもと大きく違えば知らせます。
- 件数：処理した件数が0の日が続いていないか
- 対象の期間：作ったものが、作るべき期間の分か
- 大きさ：出力の大きさが、いつもの何分の1になっていないか
そして第12回で見たとおり、「何もしなかった」回は成功と分けて記録します。自分の環境のバックアップは、送り先が設定されていないので毎日「スキップ」していたのに、それが成功と記録されていて、5か月間、一度もバックアップしていませんでした。何もしなかった回が一定の日数続いたら知らせる、という見張りを足して、ようやく気づける形になりました。
4止める仕組みを3つ用意する
- 上限：1回あたりの回数・時間・費用に上限を置く。AIが同じ作業をくり返して止まらない、という事故を防ぐ
- 止めるスイッチ：「このファイルがあったら、何もせずに終わる」のように、誰でもすぐ止められる手段を用意する。止め方を知らない仕組みは作らない
- 続けて失敗したら休む：同じ失敗が3回続いたら、自動で止まって人に知らせる。この作りはサーキットブレーカー※2と呼ばれる。壊れたまま毎回失敗し続けて、まわりを巻き込むのを防ぐ
5たくさん消す処理は、自動では消さない
たくさんのデータを消す・移す処理は、件数が多いほど人の確認なしでは動かない作りにします。自分の目安は、1,000件以上か、全体の半分以上なら、いったん止まって確認を待つ、です。
間違いの大きさは、件数に比例します。1件の誤りは手で直せますが、1万件の誤りは直せません。消す処理には、消す前に一覧と件数を出す、消すのではなくまず別の場所に移す、移した記録を残して戻せるようにする、のどれかを入れておきます。
6知らせすぎない
通知が多すぎると、誰も読まなくなります。SRE本は、知らせ方を「すぐ人を呼ぶもの」「あとで対応すればよいもの」に分け、すぐ呼ぶのは人が今すぐ動く必要があるときだけにする、という考え方を示しています。
自分の仕組みでは、次のように分けています。
- すぐ知らせる：失敗した、データが消えそう
- 朝のまとめに載せる：何もしない日が7日続いている、予定より遅れている
- 記録に残すだけ：それ以外
もう1つ大事なのは、誤報を放っておかないことです。自分の環境では、引退させたジョブの「失敗」が毎朝出続けていました。誤報が毎朝出ると、本物の失敗も読み流すようになります。誤報を見つけたら、知らせる側を先に直します。
誤解よくある思い違い
失敗したら知らせる仕組みがあれば、十分
止まった仕組みは失敗を知らせません。「最後にうまくいったのはいつか」を別の係が見張ります。
知らせは多いほど安心
多すぎる知らせは読まれなくなり、本物を見落とします。すぐ動く必要があるものだけをすぐ知らせ、誤報は先に消します。
演習手を動かして確かめる
演習1
毎晩、スマホのメモを取り込むジョブがあります。ここ2週間、毎回「0件を取り込みました。成功」と記録されています。本当にメモが無いのか、読めていないのかを、どう見分けますか。
答えを見る
例：①自分でテスト用のメモを1件送って、翌朝に取り込まれているかを確かめる（いちばん確実）。②取り込み元のフォルダを、定時実行と同じ呼ばれ方で一覧できるかを確かめる（権限の問題を見つける）。③「0件」の回を「何もしなかった」として記録し、7日続いたら知らせる見張りを足す。①で取り込まれなければ、読めていないほうです。
演習2
自分の定時実行の仕組みを1つ思い浮かべて、「止まっても誰も気づかない場面」「成功と記録されるのに中身が違う場面」「止めたいのに止められない場面」を1つずつ書き出してください。
答えを見る
答えは仕組みによって違います。書き出したら、それぞれに「何を記録し、何と比べ、いつ知らせるか」を1行ずつ足してみてください。たとえば「バックアップの送り先が外れていても誰も気づかない → 最後にうまくいった日を記録し、7日過ぎたら朝のまとめに載せる」のようにします。
頼み方そのまま使える頼み方の例
次の定時実行の仕組みについて、気づかないうちに壊れる可能性を洗い出してください。
1. 止まっても誰も気づかない場面
2. 「成功」と記録されるのに、中身が違う場面
3. 止めたいときに止められない場面
それぞれに、見張り方（何を記録し、何と比べ、いつ知らせるか）を提案してください。変更はせずに止まってください。
仕組み：（何を、いつ、どこで動かしているかを書く）用語メモ本文の ※番号の説明
出典確かめた資料（2026年10月時点）
- Google「Site Reliability Engineering」6章 Monitoring Distributed Systems 症状と原因を分ける、知らせ方の分け方。