AI駆動開発の実運用ノート No.124「複製が健全」と「復旧できる」は別物だった

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

実録災害復旧リハーサルの1日

「レプリケーションが健全」と「復旧できる」は別物だった

時刻	出来事	教材ポイント
朝	AI「着手＝即実行ではない。本番 DB 切替には人間の承認が必要」と2案提示 → オーナーが本番フルリハを決断	不可逆点に go/no-go を置く
直後	読み取り専用の事前点検が本物の欠陥を発見——複製は健全だが、アプリが新 DB に到達できない経路遮断。「今 DB が全損したら復旧できない」状態だった	プリフライトの価値
昼	前提を同日中に是正 → 本番リハ実施 → 手順書のバグを2件実機発見 → 完全復元まで1周	未テストの手順書は本番で必ずバグる

その総仕上げがこれになります。

まる1日かけて、災害からの復旧をリハーサルしました。結果、分かったのは——「データの複製が健全」と「実際に復旧できる」は別物だったということです。

複製はできていました。でも、いざ切り替える手順で詰まりました。

リハーサルをやらなければ、これは本番の障害当日まで分からなかったはずです。

「できるはず」を「できた」に変える。この一手間だけが、運用を本当に無人化できる状態にします。

この回の出典

つづく