運用できる設計へ仕上げる
本番稼働は、build成功の先にあります。異常を見つけ、影響を判断し、安全に止め、復旧し、会計を照合できる状態までを設計します。
境界、transaction、並行制御、脅威、テスト、障害対応をFailure Firstで学ぶ。
先に学ぶ内容 — Prerequisite: 基礎 / 銀行システム学ぶこと — LEARNING GOALS
このページで学ぶこと
- SLI・SLO・Alertの組み立て
- Runbookと手作業統制
- 安全なreleaseとrollback
体験26 · OPERATIONAL READINESS（運用の目で見る）
APIが200を返し続けることと、運用上「安定している」ことは同じか確かめよう
まずは予想をひと言。本文を読んだ後、実際の管理画面で運用記録を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
振込APIがHTTP 200を返し続けていれば、その銀行システムは運用上「安定している」と言えるでしょうか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
HTTP 200は「通信が成功した」という意味です。「業務として正しく完了した」という意味とは限りません。
ヒント2を見る
画面が動くことと、異常を検知して対応できることは同じでしょうか？
もっと詳しく：この問いで使う専門用語
- SLI（Service Level Indicator）は、利用者が必要とする能力を測る具体的な数値です。
- Runbookは、異常が起きた時に何を確認しどう対応するかを事前に定めた手順です。
- financial_operationsは、入金・出金・手数料・組戻しという業務操作の記録です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
本番準備はtest合格だけでなく、異常を測り、担当者が判断し、安全に復旧できる状態です。
server uptimeではなく、振込成功・残高整合・audit完全性など利用者が信頼する能力を測ります。
復旧は画面が開いた時ではなく、欠落・重複・不整合がないと照合できた時に完了します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
SLI / SLO
利用者が必要とする能力の測定値と目標です。
何をもって安定とするか共通判断できます。
振込成功率やLedger-cache不一致件数を候補にできます。
Runbook
異常時の確認・停止・復旧手順です。
緊急時の記憶や個人判断だけに依存しないためです。
integrity issue発生時の影響確認と再照合手順が対象です。
Release gate
本番へ進めるための客観的な条件です。
期限だけで危険な変更を押し込まないようにします。
型・回帰・E2E・権限test・監視準備を条件にします。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
利用者の信用を測るSLI
| 能力 | SLI例 | 単なるserver監視では不足する理由 |
|---|---|---|
| 振込できる | 正当な振込の成功率・p95完了時間 | HTTP 200でも二重記帳なら失敗 |
| 残高を信頼できる | Ledgerとcacheの不一致件数 | 画面表示だけでは正しさが分からない |
| 管理操作を追える | audit欠落率・actor不明件数 | API uptimeでは証拠欠落を検知できない |
| 異常から戻れる | 検知時間・復旧時間・未照合件数 | 再起動だけでは業務復旧にならない |
Alertは『誰が何をするか』まで設計する
- 01利用者影響を表すsignalを選ぶ
- 02正常な変動と異常を区別するthresholdを決める
- 03severityとownerを決める
- 04最初の5分のrunbookを用意
- 05自動停止・縮退・手動判断の境界を決める
- 06復旧後のreconciliationを完了条件にする
Release readiness checklist
- 変更対象の不変条件とriskを明文化
- migrationのforward pathと互換期間を確認
- type・lint・unit・regression・E2E・security testを実施
- metric・log・audit・dashboardを先に用意
- 段階releaseと中止条件を決定
- rollback後にdataをどう扱うか確認
- 問い合わせ・障害時のownerと連絡経路を確認
手作業は、隠さず統制する
| 危険な手作業 | 必要な統制 |
|---|---|
| DBを直接UPDATE | 原則禁止。承認済みRPC・reversal・auditへ置換 |
| 障害時の管理者操作 | 二者確認、理由、対象、前後値、期限付き権限 |
| 照合差異の解消 | 根拠record、承認、再実行可能な手順、再照合 |
| 緊急release | 影響限定、追加監視、事後review、通常processへの復帰 |
実際のMinibankでは
health endpoint、admin operations、audit、integrity、reconciliationなど、運用を見る入口があります。ただし本番用のon-call、SLO、alert routing、backup復元訓練、multi-region復旧が完成していることを意味しません。
学習では『画面が動いた』を完了にせず、異常検知と照合まで含むacceptance criteriaを書いてください。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
SLI/SLOとRunbookの考え方を読んだところで、実際の運用画面を確認し、自分の言葉で説明してみます。
- 02実際に観察する — OBSERVE
同じ仕組みを、動く画面から観察する
この仕組みは管理者向けの画面で確認できます。管理者ログインがない場合は、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
管理者ログインがない場合：教材の参照元で確認する ↓ - 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず運用画面が読み出すservice層を見て、次にhealth endpointの中身を見ます。「動いている」が何を指しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓業務操作・整合性チェックの検索と集計を行うservice層。
src/services/AdminOperationalService.tshealth endpoint。プロセスの生死確認と業務の健全性確認の違いを探します。
src/app/api/v1/health/route.ts - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜAPIの200応答だけでなく、業務操作や整合性チェックの記録を別途観察する必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「利用者影響」と「検知」という2つの言葉を使って書いてみましょう。
ヒント2を見る
サーバーが動いているのに困る状況を1つ想像してみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
SLI/SLO、Runbook、Release gateの3つを使って、運用できる設計とビルド成功の違いを説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- HTTP応答だけでは業務の健全性を確認できないと説明できる
- 検知の記録が残る設計になっていると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1HTTP 200率だけで振込のSLIになりますか？
不十分です。会計記帳・二重処理・完了時間など業務結果も含めます。
Q2rollbackできればreleaseは安全ですか？
DB dataや外部副作用は単純に戻せない場合があり、互換期間と復旧後照合も必要です。
Q3復旧完了をどう判定しますか？
重要機能の回復に加え、停止中requestの欠落・重複とLedger・業務recordの一致を確認します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/app/api/v1/health/route.tshealth endpoint - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/operations/運用画面 - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/integrity/整合性検査画面 - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/accounting/reconciliation/会計照合画面