DEEP GUIDE 08
公開後に異常を見つける
設定、健康状態、整合性チェックを運用の入口として読む。
このガイドで追う一件
公開後、利用者から「残高が違うように見える」と連絡が来たとします。アプリの稼働と帳簿の整合性を、別の問いとして調べます。
コードを読む順番
以下は MiniBank v1.0.0 の確認先です。マイグレーションは順に適用されるため、関数の最終形を調べるときは後続の変更も確認してください。
- 1
配置と秘密情報を確認する
コード、データベースのマイグレーション、環境変数が同じ前提を共有しているか調べます。例示された秘密情報の名前を、公開時の設定と混同しないようにします。
確認するファイル
.env.local.example - 2
アプリの生存確認を読む
health API はアプリのプロセスが応答できるかを見る入口です。データベース接続を検査するものではないと、コードのコメントにも明記されています。
確認するファイル
src/app/api/v1/health/route.ts - 3
整合性チェックを実行する経路を見る
管理者向け API と reconciliation.run_check をたどり、検査の実行と問題の保存先を確認します。
確認するファイル
src/app/api/v1/admin/integrity/runs/route.ts - 4
問題を調査する
問題一覧から対象の口座や仕訳を絞り、原因を調べます。修正は帳簿と監査の方針に沿って扱います。
確認するファイル
src/app/api/v1/admin/integrity/issues/route.ts
失敗時・範囲外の確認
health が 200 を返しても、データベースが正常とは限りません。バックアップ、復旧手順、担当者への連絡などは学習用実装の外にあり、本番運用では別途設計します。
ここまでで説明できること
「アプリが応答する」と「取引の記録が整合している」を分けて確認できます。