自動化は壊れる前に黙る

🟢「全て成功」のログは、動いている証明にならない

成功の記録が並んでいることと、いま動いていることは、別の話でした。

その自動チェックは、走るたびに結果をファイルに残す作りにしていました。2026年7月26日に自分で数え直したところ、残っていた記録は115本。そのうち114本が「全て成功」で、失敗の記録はほぼありませんでした。

一見すると健康そのものです。ところが同じファイル群を日付ごとに数え直すと、まるまる6日ぶんが0件でした。失敗が記録されていなかったのではなく、そもそも実行されていないので何も記録されなかった、というだけの話です。

成功ログは「走ったときの結果」しか教えてくれません。走らなかった日は、行が増えないだけで、何も主張してこない。私はその沈黙を「異常なし」と読んでいました。

🔢「0件」と「0件しか見ていない」は、出力の上では見分けがつかない

件数だけを出す処理は、そもそも走査していない状態を正常に見せてしまいます。

これは同じ穴の別の顔でもあります。「該当0件」とだけ表示する処理は、100件調べて0件だった場合と、そもそも1件も調べていない場合を区別できません。取得に失敗して空が返ってきたときも、見た目は同じ「0件」です。

いまは、件数を出す処理には必ず分母も一緒に出すようにしています。「100件中0件」と書いてあれば、100が0になった瞬間に異変だと分かる。そして走査対象が0件だったときは、正常ではなく異常として印を付けるようにしました。

👁️自分の停止は、自分では観測できない

死活の見張りは、止まる可能性のある仕組みの外側に置く必要がありました。

いちばん効いた反省はここです。止まった仕組みは、止まったことを報告できません。同じ仕組みの中に「異常なら知らせる」機能を足しても、丸ごと動いていない日には何も知らせてくれない。

なので判断材料を「エラーが出たか」から「成果物が最後に更新されたのはいつか」に変えました。決まった時間ごとに何かを生むはずの処理なら、その生成物の更新時刻を外側から見れば、動いていない事実がそのまま観測できます。エラーを待つのではなく、更新が途切れたことを異常として拾う形です。

この考え方自体は運用の世界では以前から言われていることで、私たちが発明したものではありません。分かっていたつもりで、自分のところに適用できていなかった、というのが正直なところです。

🧭まとめ: 沈黙を正常と読まない

整理します。①成功ログが並んでいても、走っていない日は何も残らないので健康の証明にはならない②件数を出すときは必ず分母も出し、走査0件は正常でなく異常として扱う③死活の見張りは、止まりうる仕組みの外側に置いて「最後に更新された時刻」で見る。

自動化を増やすほど、壊れる音より黙る回数のほうが増えていきます。うるさく失敗してくれる処理より、静かに何もしなくなる処理のほうが、見つけるのに時間がかかりました。

📚参考・出典

• Google SRE Book: Monitoring Distributed Systems（監視で何を見るべきかを Google が整理している章）
• Google SRE Book: Practical Alerting from Time-Series Data（時系列データからアラートを組み立てる考え方の解説）