【要約】11Botをサイレント停止させた2時間 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
cronエントリの消失により、11本のBotが6.5日間停止した。主な課題は以下の通り。
- ・監視対象が3本のみにハードコードされ、停止したBotを検知できなかった。
- ・管理用レジストリに新設Botが未登録で、差分チェックが機能しなかった。
- ・監視対象外の存在を無視し、「All healthy」と誤った安全宣言を出していた。
- ・エラーを吐かずに停止する「サイレント失敗」により、発見が遅れた。
// Approach
以下のステップで復旧と再発防止を図った。
1.即時復旧: crontabを手動で復旧し、バックアップを取得。
2.監視の動的化:
mapfileを用い、レジストリから監視対象を自動抽出する仕組みへ変更。3.管理の強制:
cron_registry.txtをSource of Truthとし、直接編集を禁止。4.統合管理の導入:
bot_registry.yamlを設計。cron設定、ログパス、実行間隔（expected_interval_min）、許容遅延（stale_h）を一元管理する。// Result
監視対象の自動探索化により、監視漏れを構造的に排除。
bot_registry.yamlによる統合管理により、設定と監視の乖離を解消する。稼働率（例: 18/18）を可視化し、「無音＝正常」という前提を排除した、レジリエンスの高い監視体制への移行を目指している。Senior Engineer Insight
> 「エラーが出ない停止」は、監視設計における最大の盲点だ。本件の失敗は、監視対象の「カバレッジ」を定義しなかった点にある。単なる生存確認ではなく、実行間隔とログ更新時刻の乖離を検知する設計が不可欠だ。自動化が進むほど、管理対象の増減に追従できる「メタ管理層」の構築が求められる。構成管理と監視を分離せず、一つの定義ファイルで紐付ける設計思想は、運用コストと信頼性の両面で極めて合理的である。