銀行エンジニアリング 32：障害に備える（書込停止・旧 writer・RTO と RPO）

Level 1 基礎：障害のときに困る3つのこと

データベースが壊れて、バックアップから戻すことを考えます。困ることは3つあります。

①バックアップのあとに確定した取引は、戻したデータには無い（どこまで失ったか＝RPO）。②壊れたと思った古い側が、実は動いていて書き続けている（二重運用）。③戻すのに時間がかかる（どれだけ止まるか＝RTO）。

• どちらも『この機械・このデータ量・この手順で測った値』です。目標値でも保証値でもありません。測るときは、データ量や機械の条件を一緒に残します。

Level 2 銀行業務：復旧の状態と、書ける状態

状態は決められた順序でしか進みません。停止 → 復元 → 照合 → レビューの提出 → 別の管理責任者が再開。復元しない予防的な停止では、復元の段階を飛ばせます。各遷移には理由が必要で、追記専用の履歴に残ります。

Level 3 システム：MiniBankでの実装

• 金融の書込みはすべて、15の表に付いた営業日のゲート（ops.require_business_day_open）を通る。v17はこのゲートに、復旧の状態の検査を営業日の判定の前に足した。新しい入口を作らないので、あとから追加した機能も自動で止まる
• fence は EOD と同じ排他の advisory lock（74821,1）を取る。すでに走っている書込みが終わるのを待ち、その後ろに並んだ書込みは RY001 で失敗する。確定した書込みと止まった書込みの境目が明確になる
• 書込世代（epoch）は再開のたびに上がる（外に控えた『それまでに発行した最大の世代』の1つ上。復元先が覚えている古い世代へは戻らない）。enforce_epoch を有効にすると、X-Writer-Epoch ヘッダー（アプリの環境変数 MINIBANK_WRITER_EPOCH）が現在の世代と一致しない書込みを RY002 で断る。古い設定のまま生き残ったアプリが書けなくなる
• 再開（confirm_reopen）は、レビューを提出した人とは別の管理責任者だけ（RY005）。提出と再開には、最新の検証で manifest との比較を除く全項目が OK であること（RY004）、復元を経ている場合は、その間にバックアップの記録（manifest）との比較まで OK になった検証があることが必要
• ゲートの表に載らない書込み（他行送金の送信、決済バッチ、営業日の開始・終了）にも、書込停止と書込世代だけを見る検査を付けた（recovery.require_writable）。決済バッチは、書込停止中に『一部失敗』として記録せず、RY001 で止まる
• 復元を始める（begin_restore）には、障害の前にデータベースの外へ控えた manifest の digest と、それまでに発行した最大の書込世代が要る（RY007）。digest は方式の版つきで、既定は現行の 3。旧方式（2＝group 等まで、1＝元帳・口座・イベントだけ）で控えた値は、その版を明示して渡す（版が違えば NG。安全側）。運用者の一覧（external_operators）も、任意で渡せる。画面は、復元されたデータベースの中の値を入力の既定値にしない（それが外に控える意味を消すため）。提出者は自分の提出を差し戻せない（RY005）
• 入力を間違えたまま詰まらないよう、復元中・照合中・レビュー中は abort_restore（復元のやり直し）で書込停止に戻せる。検証を省くものではなく、最初の宣言からやり直し、検証・提出・別の人の再開を通る
• 運用者の権限（admin.admin_operators）は、digest に入れない。書込停止中でも運用者の『無効化』だけは許す（事故対応）ので、権限を digest に入れると、正当な無効化のせいで再開が詰まる。代わりに、障害の前に運用者の一覧（user_id・role・status。画面の『運用者の一覧（外に控える用）』。1〜500 件の配列）を外に控え、復元の宣言で渡す。復元後の検証（EXTERNAL_OPERATORS）は、一覧にある人の権限が一覧より『増えて』いたら NG にする（無効のはずが有効、運用者のはずが管理責任者）。減る向き（無効化）と、一覧にない人は NG にしない（一覧にない有効な運用者の人数 unlisted_active は、情報として出すだけ）。一覧を渡さなかったときは検査が走らず、検証に『検査せず』（declared:false）と出る。一方向の検査であり、外に控えた一覧を渡さなければ何も守らない
• 遷移の履歴（recovery.transitions）は追記専用。更新や削除は PF001 で拒否される
• 書込停止の間も、読取りと管理画面の閲覧はできる。許される書込みは、復旧の制御と検証、監査の記録、観測の記録（risk／twin のスナップショットと実行）、Open Banking の利用時刻の記録、再開時のトークン失効、運用者の無効化（事故対応）など。金額が 0 円でも、融資・価格・Open Banking・リスク／Twin の設定・日次の締め・運用者の権限（無効化以外）・KYC の状態など、業務の状態を変える書込みの多くは RY001 で止まる。ただし、AML のケース、調査、通知、清算の記録など、止めていない領域もある（V20-FREEZE-HARDENING.md の一覧）

異常時：古いアプリが、復旧後も書こうとする

Level 4 アーキテクチャ：フェンシング・トークン

古い書き手を止める定番の方法が、単調に増える番号（フェンシング・トークン）です。書き込む側が自分の世代を示し、受ける側が古い世代を断ります。MiniBankの世代はアプリの自己申告で、悪意のある書き手を防ぐものではありません（それは認証と権限の役割です）。防ぐのは『自分たちの古い設定のアプリ』です。

どこを確認すればよいか

• 管理画面『復旧・DR』：状態、世代、履歴、検証、演習の記録
• 運用センター：書込停止中は Recovery が赤になり、『書込停止中』の例外が出る