信頼性設計と障害対応
障害をゼロにするのではなく、重要業務への影響を限定し、正しい状態へ復旧し、学びを次の防御へ戻す一連の能力を設計します。
境界、transaction、並行制御、脅威、テスト、障害対応をFailure Firstで学ぶ。
先に学ぶ内容 — Prerequisite: 基礎 / 銀行システム学ぶこと — LEARNING GOALS
このページで学ぶこと
- Failure modeとblast radius
- Incident commandと業務復旧
- Postmortemから防御へ戻す方法
体験33 · RELIABILITY / INCIDENT（止血を優先する）
障害の原因が分かるまで、復旧作業を始めるべきではないか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の回帰testとaudit実装を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
障害の原因がはっきり分かるまで、復旧作業を始めるべきではないと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
原因究明と、影響を止める作業は同時にできないでしょうか？
ヒント2を見る
証拠を残さずに復旧作業を進めると、後で何が困るでしょうか？
もっと詳しく：この問いで使う専門用語
- Incident Commandは、緊急時の判断・記録・連絡の役割を明確にする運営方法です。
- Business recoveryは、system起動だけでなく重要業務とdata整合が戻った状態です。
- Blameless postmortemは、個人非難でなく仕組みと条件を分析する振り返りです。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
信頼性は、止まらないことだけでなく、影響を限定し正しい状態へ戻れる能力です。
incident初期は原因推測より、影響測定・証拠保存・止血・安全な復旧を優先します。
復旧後は個人の注意ではなく、constraint・test・alert・runbookへ学びを戻します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Incident Command
緊急時の判断・記録・連絡の役割を明確にする運営方法です。
複数人が別々の仮説で変更を重ねる混乱を防ぎます。
停止判断、証拠保存、照合、再開のownerを分けて考えます。
Business recovery
system起動だけでなく重要業務とdata整合が戻った状態です。
欠落・重複が残れば利用者は残高を信頼できません。
Ledger・transfer・cache・auditを照合して完了を判断します。
Blameless postmortem
個人非難でなく、事故を許した仕組みと条件を分析する振り返りです。
同じ種類の事故を組織的な防御へ変えます。
失敗例をmigration・regression test・教材へ残します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
障害を部品停止だけで考えない
| Failure mode | 金融systemでの危険 | 設計する対策 |
|---|---|---|
| Timeout | 成功済みか不明で再送される | idempotency・照会・状態確定 |
| Partial dependency failure | 通知だけ失敗、外部決済だけ遅延 | outbox・queue・再送・状態分離 |
| Slowdown | lock待ちとconnection枯渇が連鎖 | timeout・backpressure・優先度 |
| Bad deployment | 正しいdataを誤ruleで大量処理 | canary・kill switch・rule version |
| Data corruption | 画面復旧後も残高を信頼できない | immutable backup・reconciliation・再構築 |
| Operator error | 強権限で影響が拡大 | 職務分離・二者承認・audit・限定tool |
Incidentの最初の30分
- 01Incident Commanderと記録係を決める
- 02顧客・金額・機能・開始時刻を測る
- 03証拠を保存しながら拡大を止める
- 04write停止・縮退・rollbackを判断
- 05既知の安全な状態へ復旧
- 06Ledger・業務record・外部結果を照合
- 07顧客・社内へ事実と次回更新時刻を共有
復旧完了の定義
- 重要APIがSLO範囲で応答する
- 停止中のrequestが欠落・二重処理されていない
- Ledgerと業務recordとcacheが照合済み
- 外部連携の未処理・再送対象を特定済み
- 顧客影響と補償判断に必要な証拠がある
- 追加監視と再発時の即時停止条件が有効
Blameless Postmortemを防御へ変える
| 問い | 弱い結論 | 強い改善 |
|---|---|---|
| なぜ起きた | 担当者が間違えた | 誤操作を許した権限・UI・承認・検知を分解 |
| なぜ広がった | 想定外だった | blast radius制御と中止条件を追加 |
| なぜ遅れた | 監視を見落とした | 利用者影響SLIとactionable alertを追加 |
| どう防ぐ | 注意する | constraint・test・automation・runbookへ変換 |
実際のMinibankでは
Regression、E2E、Integrity、Reconciliation、Auditは予防と検知の一部です。正式な24時間on-call、disaster recovery、外部networkとの復旧調整までは実装範囲外です。
上級演習では、振込timeout、誤rule release、月末満期集中などのscenarioごとに、検知signal・停止判断・照合query・再開手順を書いてください。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Incident CommandとBlameless postmortemの考え方を読んだところで、教材内の参照元で実際の回帰testとaudit実装を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず既知障害の再発を防ぐ回帰testを見て、次に復旧作業自体を記録するaudit画面の実装を見ます。学びがどう防御へ戻るかを確かめましょう。
教材の参照元を確認する — Source Trail ↓既知障害の再発防止test。
scripts/regression/復旧作業を含む操作の証拠が残る画面の実装。
src/app/admin/(protected)/audit/page.tsx - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜincident対応では、原因究明より先に影響測定と証拠保存を優先するのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「止血」と「証拠保存」という2つの言葉を使って書いてみましょう。
ヒント2を見る
APIが復帰した時点と、業務が復旧した時点の違いを考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Incident Command、Business recovery、Blameless postmortemの3つを使って、障害対応から防御への学びの戻し方を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 原因究明より先に影響測定と止血を優先すると説明できる
- 業務復旧はAPI復帰より広い条件だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1incident発生直後にroot cause修正を始めますか？
まず影響を測り、証拠を保存し、拡大を止め、安全な状態へ復旧します。原因分析はその後です。
Q2APIが復帰すればincident closeですか？
いいえ。停止中requestの欠落・重複と業務・会計dataの照合が必要です。
Q3再発防止を『注意する』で終えてよいですか？
いけません。constraint、権限、test、alert、runbookなど検証可能な防御へ変えます。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/既知障害の再発防止 - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/operations/運用可視化 - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/integrity/異常検知とissue - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/(protected)/audit/incident時の証拠