壊れたときに戻せるかは、バックアップが「ある」かではなく、「実際に戻せる」かで決まります。そして、止まったことに利用者より先に気づくには、通知が誰に届くかまで決めた監視が要ります。この記事では、その2つの確かめ方を説明します。
バックアップと監視は、別の問いに答えるもの
データが消えたり、アプリが止まったりしたとき、次の2つが問われます。
- 戻せるか（バックアップ）: 消えたデータや壊れた状態を、元に戻せるか。いつの時点まで戻せるか。
- 気づけるか（監視）: 何かおかしいことに、利用者より先に、誰かが気づけるか。
どちらかが欠けると、被害は大きくなります。バックアップがあっても、気づくのが数日後なら、戻す対象が増えてしまう。監視があっても、戻せなければ、知らせを受けて何もできません。
AI にアプリを作らせると、画面と機能は早く揃います。しかし、「壊れたときにどうするか」は、頼まなければ作られないことが多い部分です。
私たちの考え方: 戻す練習をしていないバックアップは、確かめていないのと同じ
私たちはこう考えます。確かめるのは「バックアップがあるか」ではなく、戻したことがあるかです。
バックアップには、次のような落とし穴があります。取れているつもりで取れていなかった。データベースの本体と同じ場所にあり、同時に失われる。取っているのは一部のデータで、肝心のものが入っていない。戻し方を知っている人がいない。どれも、一度戻してみなければ分かりません。
判断基準を3つにまとめます。
- 取っているか。 何を、どのくらいの頻度で取っているか。
- どこまで戻せるか。 いつの時点の状態に戻せるか。それが、利用者や業務にとって許せる範囲か。
- 実際に戻せるか。 戻す手順を、作った本人以外も含めて、誰かが実行したことがあるか。
確かめ方: バックアップ
次の順で確かめてください。
- アプリのデータ（データベース、アップロードされたファイル）が、どこに保存されているかを書き出す
- それぞれに、バックアップの設定があるかを確かめる。使っているサービスの管理画面で確認できることが多い
- バックアップが、元のデータと同じ場所だけに置かれていないかを確かめる
- 可能なら、テスト用の環境に一度戻してみる。本番を直接触らない
「どこに保存されているか」を書き出せない場合は、4点目の「作った本人以外に直せる人がいるか」にも関わります。そちらは AIで作ったアプリを本番化するには で触れています。
確かめ方: 監視
監視は、仕組みを入れるだけでは意味がありません。次の3つを決めます。
- 何を見るか。 アプリが応答しているか、エラーが増えていないか、など。
- 誰に知らせるか。 作った本人だけが受け取る設定だと、その人が不在のときに誰も気づきません。
- 知らせが来たら誰が何をするか。 戻す手順につながっているか。
目安は「利用者から連絡が来る前に、自分たちが気づけるか」です。
事例: 障害の検知から報告書まで
AI で作ったアプリの案件ではありませんが、監視の設計の参考になる例です。私たちは、AWS 上に、障害の検知から報告までを回す監視基盤を構築しました。CloudWatch のアラームと、EventBridge・Lambda による通知を組み合わせています。障害が起きると、調査報告書と対策手順書を AI で作成し、人は最終チェックを行う運用です。構成は Terraform で管理しています。
これは、監視を「気づく」ところで終わらせず、「調べて、報告して、対策を決める」ところまでつなげた例です。ここで紹介するのは監視の設計の一例で、アプリの規模や用途によって、必要な深さは変わります。
私たちの経験
私たちは、バックアップも監視もなく、壊れたら戻せない状態を見たことがあります。動いている間は問題が見えないので、作った人も気づきにくい。壊れたときに初めて、「戻せない」と分かります。
だから私たちは、本番化の中で、監視とバックアップを備えることを標準の作業として扱っています。公開して終わりではなく、使われ方を見ながら改善していくためです。
wizgeek にできること
監視とバックアップが足りているか不安なときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。本番化の作業は別途お見積りします。公開後は、監視とバックアップを備えた体制で運用を担います（保守運用：月10万円〜、税別が目安）。