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

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

AI駆動開発の実運用ノート No.120アラートは本当に鳴るのか、わざと壊して確かめる

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

事故 → アラートのコード化 → 導通実証

アラートは事前設計ではなく事故駆動で1つずつ増えた

完成形の実例: 本番バッチ停止の原因がホスト側の CPU 奪取と判明した日、同日中にアラートをコードで実装し、検証環境で導通を実証し、ベンダ申告の証跡収集まで1セットで済ませた。

  • アラートは設定画面でなくコード(プロビジョニングファイル)で持つ——再構築で消えない
  • 通知経路は「実到達テスト」までやる——本番に通知先が無く「失敗してもログのみ」だった期間が実在した
  • ログはデプロイでコンテナが入れ替わっても残る場所に集約する

まず監視から。

ここでも原則は同じで、アラートは事前に設計したのではなく、事故駆動で1つずつ増えました。 だからアラートの一覧は「何を監視すべきか」の理想像ではなく、これまでに起きた事故の一覧でもあります。

そして大事なのは最後の「導通実証」です。

アラートを仕込んだら——わざと異常を起こして、本当に鳴るかを確かめます。

「アラートを設定した」と「アラートが鳴る」は別物だからです。 第3部で出てきた「機構はあるが配線されていない」の、監視版にあたります。

つづく