v1.0.0 の歴史資料当時の説明です。現在の仕様とは異なる箇所があります。現行版の対応記事 →資料一覧へ

DEEP GUIDE 08

公開後に異常を見つける

設定、健康状態、整合性チェックを運用の入口として読む。

このガイドで追う一件

公開後、利用者から「残高が違うように見える」と連絡が来たとします。アプリの稼働と帳簿の整合性を、別の問いとして調べます。

コードを読む順番

以下は MiniBank v1.0.0 の確認先です。マイグレーションは順に適用されるため、関数の最終形を調べるときは後続の変更も確認してください。

  1. 1

    配置と秘密情報を確認する

    コード、データベースのマイグレーション、環境変数が同じ前提を共有しているか調べます。例示された秘密情報の名前を、公開時の設定と混同しないようにします。

    確認するファイル.env.local.example

  2. 2

    アプリの生存確認を読む

    health API はアプリのプロセスが応答できるかを見る入口です。データベース接続を検査するものではないと、コードのコメントにも明記されています。

    確認するファイルsrc/app/api/v1/health/route.ts

  3. 3

    整合性チェックを実行する経路を見る

    管理者向け API と reconciliation.run_check をたどり、検査の実行と問題の保存先を確認します。

    確認するファイルsrc/app/api/v1/admin/integrity/runs/route.ts

  4. 4

    問題を調査する

    問題一覧から対象の口座や仕訳を絞り、原因を調べます。修正は帳簿と監査の方針に沿って扱います。

    確認するファイルsrc/app/api/v1/admin/integrity/issues/route.ts

失敗時・範囲外の確認

health が 200 を返しても、データベースが正常とは限りません。バックアップ、復旧手順、担当者への連絡などは学習用実装の外にあり、本番運用では別途設計します。

ここまでで説明できること

「アプリが応答する」と「取引の記録が整合している」を分けて確認できます。