AI駆動開発の実運用ノート

本編の目次 › 第5部 デプロイ・運用・移植 › 監視と自己修復

AI駆動開発の実運用ノート No.122バックアップが19日間サイレント失敗していた

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第5部「デプロイ・運用・移植」から、「監視と自己修復」のお話です。

失敗事例バックアップが19日間サイレント失敗していた

「バックアップを書いた」と「バックアップされている」は別物
事故

本番バックアップが約19日間、誰にも気づかれず失敗。復元不能まで秒読みだった

根本原因

実行権限漏れ→cron の環境変数未伝播→検知スクリプト自体が本番未配備の三重奏

ルール

鮮度監視(最新バックアップの新しさを毎日確認)+ 通知の実到達テスト

強制する仕組み

監視スクリプトの配備自体を自動同期。サイレント失敗の余地を層ごとに潰す

その思想がなぜ要るのか。この事故が答えになります。

データのバックアップが19日間、静かに失敗し続けていました。

エラーは出ていません。「バックアップを取る仕組みを書いた」。でも実際には「バックアップされていなかった」のです。

第4部でも出た、この構図です。「書いた」と「動いている」は別物です。

一番怖いのはやはりサイレント失敗になります。 だからバックアップにも「新しさを監視する」仕組みを足しました。

バックアップすら、監視しないと信じられません。それが実運用です。

つづく