銀行エンジニアリング 17：インシデント管理・SLA・Runbook・Recovery
障害は必ず起きます。大切なのは、影響を把握し、原因を特定し、復旧し、同じことを繰り返さない記録を残すことです。
v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。
Prerequisite: BANKING SYSTEMLEARNING GOALS
このページで学ぶこと
- インシデントの状態と記録すべきこと
- SLA（目標時間）の考え方
- Runbookと復旧（Recovery）の原則
PLAIN LANGUAGE
まず、ここだけつかむ
インシデントは OPEN → INVESTIGATING → RESOLVED → CLOSED の順に進みます。
解決には原因と対応の記録が必要で、クローズは管理責任者が行います。
銀行の復旧は、やり直しより「相手側と照合して状態を事実に合わせる」ことが優先です。
DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
SLA
対応を終えるまでの目標時間です。
対応の優先度と遅れを見える化するためです。
SEV1=60分、SEV2=240分、SEV3=1440分。
Root Cause
問題の真の原因です。
症状への対処だけでは再発するためです。
RESOLVED に必須（OX004）。
Runbook
決まった状況で取る手順書です。
緊急時でも安全な手順を守るためです。
キュー項目ごとの RUNBOOKS。
Level 2 銀行業務：インシデントの流れ
- 01OPEN（起票：件名・重大度・影響）
- 02INVESTIGATING（調査メモ・関連対象の追加）
- 03RESOLVED（原因と対応を記録）
- 04CLOSED（管理責任者が事後レビューとして閉じる）
| 重大度 | 目標（解決まで） | 目安 |
|---|---|---|
| SEV1 | 60分 | 多くの顧客のお金の移動が止まっている |
| SEV2 | 240分 | 一部の支払や照合に影響 |
| SEV3 | 1440分 | 影響が限定的、回避策あり |
Level 3 システム：MiniBankでの実装
- RESOLVED にするには、原因（root cause）と対応（resolution）の両方が必要（OX004）
- 状態は OPEN → INVESTIGATING → RESOLVED → CLOSED の順で、飛ばせない（OX003）。RESOLVED から INVESTIGATING へ戻して再調査もできる
- CLOSED にできるのは管理責任者だけ（AD004）
- SLAは重大度から計算し、経過時間と超過の有無を表示する
- タイムライン（opscenter.incident_events）と関連対象（opscenter.incident_links）は追記のみ
異常時：Payment障害 → Incident → 調査 → Recovery
| 段階 | 内容 |
|---|---|
| 症状 | ひかり架空銀行宛の送金がすべて TIMEOUT になる |
| 調査 | Operations Centerの Exception キューから追跡し、決済システム側では受理済みであることを確認 |
| 考えられる原因 | MiniBank側のGateway障害／決済システムの遅延／受取銀行の応答なし |
| 真因 | 受取銀行（架空）が応答を返さない |
| 対応（Recovery） | 再送せず、1件ずつ照会して状態を事実に合わせる。決済バッチの未確認件数と照合差異が0になったことを確認 |
| 再発防止 | 結果不明の件数を監視し、閾値を超えたらインシデントを起票する運用にする |
Level 4 アーキテクチャ：Operational Resilience
重要業務を止めない力（Operational Resilience）は、障害を起こさない設計だけでなく、障害の検知・影響範囲の特定・安全な復旧・記録の4つで成り立ちます。MiniBankでは、検知をOperations Center、影響範囲を追跡、安全な復旧を各業務の冪等な操作（照会・再実行）、記録をインシデントが担っています。
どこを確認すればよいか
- Operations Center → インシデント一覧と詳細（SLA・タイムライン・関連対象）
CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1OPEN から直接 CLOSED にできますか？
できません（OX003）。
Q2原因を書かずに解決にできますか？
できません（OX004）。
Q3結果不明の送金の復旧で最初にしてはいけないことは？
再送です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
Implementation Status: IMPLEMENTED IN MINIBANK（この教材が扱うコードの範囲）
- RELATED LESSON/docs/reliability-incident信頼性設計と障害対応
- RELATED LESSON/docs/be-result-unknown結果不明の扱い
- CURRENT IMPLEMENTATION
supabase/migrations/20260924140000_v12_operations_center.sqlopscenter.open_incident / opscenter.set_status / opscenter.sla_minutesインシデントとSLA - CURRENT IMPLEMENTATION
scripts/banking/v12-operations.test.mjs例外・照合差異・承認キュー、追跡、インシデント、営業日外の停止のDBテスト