災害復旧シナリオ

1） DRが必要な理由と目的

災害復旧（DR）は、災害後のサービス（データセンター/リージョンの障害、データ損失、大量構成エラー）を回復するためのアーキテクチャ、プロセス、およびトレーニングのセットです。DRの目標は、顧客の信頼と規制遵守を維持しながら、管理されたコストとリスクでターゲットのRTO/RPOを満たすことです。

回復時間目標（RTO）-ダウンタイムを許容。
Recovery Point Objective （RPO）-許容データ損失（最後の一貫性のあるポイントからの時間）。
RLO （Recovery Level Objective）：最初に返すべき機能のレベル（最小実行可能なサービス）。

2）臨界性によるシステム分類

階層0（重要）：支払い、ログイン、KYC、コアトランザクション-RTO ≤ 15分、RPO ≤ 1-5分。
階層1（高）：動作パネル、レポートD-1-RTO ≤ 1 h、 RPO ≤ 15-60分。
階層2（平均）：バックオフィス、ほぼリアルタイム分析-RTO ≤ 4-8時間、RPO ≤ 4-8時間。
層3（低い）：非重要な補助-RTO ≤ 24-72 h、 RPO ≤ 24 h。

サービスカタログの各サービスに階層+ターゲットRTO/RPOを割り当てます。意思決定と予算はそれらに対してチェックする必要があります。

3）脅威モデルとシナリオ

人工：AZ/region/providerの失敗、ネットワークの劣化/DNS、データベース/ストレージの障害、大量リリースのバグ。
ヒューマンファクター：誤ったconfigs/IaC、データ削除、重要な妥協。
自然/外部：火災/洪水、停電、法的閉塞。
それぞれ-確率/影響を評価し、DRシナリオとプレイブックにリンクします。

4） DRアーキテクチャパターン

1.アクティブ-アクティブ（マルチリージョン）：両方のリージョンがトラフィックを提供します。

長所：最低のRTO/RPO、安定性が高い。
欠点：データの複雑さ/一貫性、高価格。
Where：読み取り重量、キャッシュ負荷、ステートレスサービス、マルチマスターDB（厳格な競合ルール）。

2.アクティブパッシブ（ホットスタンバイ）：ホットパッシブは完全に加熱されたコピーを保持します。

RTO：分；RPO：分。自動フェイルオーバーとレプリケーションが必要です。

3.ウォームスタンバイ：リソースの一部がウォームアップされ、事故が発生した場合にスケーリングされます。

RTO：数十分；RPO： 15-60分。より経済的ですが、より長くなります。

4.パイロットライト：最小の「スパーク」（メタデータ/画像/スクリプト）+クイックスプレッド。

RTO：時間；RPO：時間。格安、Tier 2-3に適しています。

5.バックアップと復元：オフラインバックアップ+手動ウォームアップ。

RTO/RPO：時間/日。唯一の低い批評性とアーカイブのために。

5）データと一貫性

• 同期-ほぼゼロのRPO、しかし、latentnost/stoimost。
• 非同期-パフォーマンスの向上、RPO> 0（ログの尾）。
• 一貫性：モデル（strong/eventual/causal）を選択します。支払いのために-厳密に、分析のために-最終的に。
• スナップショット：定期的に一貫したポイントを作成する+ログを保存する（WAL/やり直し）。
• クロスリージョントランザクション：2PCを避けます。idempotent操作、deli-and-repeat（重複除外による再試行）、イベントソーシングを使用します。
• キュー/バス：レプリケーション/ミラーリング、DLQ、注文、消費者の特権。

6）ネットワーク、交通およびDNS

GSLB/Anycast/DNS：フェイルオーバー/フェイルバックポリシー、低いTTL（しかしあまり多くはありません）、いくつかの地域からのヘルスチェック。
L7ルーティング：地域マップ、劣化フラグ（機能制限）。
プライベートリンク/VPN：プロバイダ（PSP/KYC/CDN）へのバックアップチャネル。
率の制限：回復の間の嵐の保護。

7）ステートフル対ステートレス

ステートレスはスクリプト/オートスケールによって実行されます。statefulには、一貫したデータ戦略（レプリケーション、スナップショット、レプリカプロモーション、クォーラム）が必要です。
キャッシュ/セッション：クロスリージョンレプリケーションまたはログによる再シードを伴う外部（Redis/Memcached）；トークン（JWT）または共有ストレージでセッションを保持します。

8） DRの制動機およびオートメーション

SLO gardrailsとquorum probes→自動リージョン・フェイルオーバー・ランブック。
事故の場合の変更フリーズ：ブロック無関係のリリース/移行。
コードとしてのインフラストラクチャ：スタンバイマニフェストの展開、ドリフトチェック。
ロールプロモーション：自動プロモートレプリカDB+ライター/シークレットドレッシング。

9）コミュニケーションとコンプライアンス

戦争部屋：IC/TL/Comms/Scribe；SEVの更新間隔。
ステータスページ：影響の地理、ETA、回避策。
規制：通知の締め切り、データセキュリティ、変更できないエビデンスストレージ。
パートナー/プロバイダー：確認された連絡先、専用チャンネル。

10） DRテストと演習

テーブルトップ：シナリオとソリューションの議論。
ゲームデー（ステージ/プロッドライト）：AZ/リージョン障害のシミュレーション、プロバイダのシャットダウン、DNSリセット。
リストアテスト：定期的に隔離されたバックアップをリストアし、整合性を検証します。
Chaos/Failure Injection：制御ネットワーク/ノード/依存障害。
練習KPI：達成されたRTO/RPO、 playbookの欠陥、CAPA。

11）ファイナンスと戦略の選択（FinOps）

減らされたRPO/RTOのためのカウント$：より低いターゲット、より高いチャネル、ライセンス、準備金。
ハイブリッド：階層0-アクティブアクティブ/ホット；層1-暖かい；階層2-3-パイロット/バックアップ。
高価なデータ：コールドレイヤー（アーカイブ/S3/GLACIER）、増分スナップショット、重複排除を使用します。
DR-infraコストと証明書/ライセンスの定期的なレビュー。

12） DR成熟度の指標

各階層のRTO（実際）とRPO（実際）。
DRカバレッジ：設計されたスクリプト/プレイブック/テストを持つサービスの％。
バックアップの成功と復元の成功：バックアップと実績のあるリストアの毎日の成功。
災害を宣言する時間：フェイルオーバー決定のスピード。
Failback Timeは通常のトポロジに戻ります。
欠陥レートエクササイズ：発見されたギャップ/教え。
コンプライアンス証拠の完全性。

13）チェックリスト

DR導入前

• サービスディレクトリには、階層、RTO/RPO、依存関係および所有者が含まれます。
• 階層と予算によって選択されたパターン（AA/AP/WS/PL/BR）。
• 一貫性とレプリケーション契約が文書化されています。
• GSLB/DNS/ルーティングおよびヘルスチェックを構成およびテスト。
• バックアップ、スナップショット、変更ログ-有効、リストアのチェック。
• DRプレイブックとプロバイダの連絡先は最新です。

事故時（簡易）

• SEVを宣言し、戦争部屋を組み立てる。フリーズ・リリース。
• プローブのクォーラムをチェックする。インパクト/地理を記録します。
• フェイルオーバーランブックの実行：トラフィック、プロモーションDB、キュー、キャッシュ。
• degrade-UX/limitsを有効にします。SLAの更新を公開します。
• 証拠（タイムライン、グラフ、ログ、コマンド）を収集します。

事故後

• N間隔のSLOを観察する。フェイルバックを計画通りに実行します。
• AAR/RCAを実施する。CAPAを発行します。
• プレイブック、アラート触媒、DRテストケースを更新します。
• ステークホルダー/規制当局への報告（必要に応じて）。

14）テンプレート

14.1 DRスクリプトカード（例）

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14.2 Runbook「レプリカデータベースを促進する」（フラグメント）

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14.3 DRエクササイズプラン（概要）

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15）アンチパターン

定期的な復元テストなしで「バックアップがあります」。
シークレット/エンドポイントは自動的に切り替えられません。
再配達時に特権→重複/失われたトランザクションはありません。
分解フィーチャーフラグのないリージョンでも同じ設定が可能です。
「誤報」を恐れて宣言する長い時間。
Monoregionalプロバイダ（PSP/KYC）代替なし。
フェイルバックプランはありません-私たちは「永遠に」緊急トポロジーに住んでいます。

16）実装ロードマップ（6-10週間）

1.ネッド。1-2： Tierによるサービスの分類、ターゲットRTO/RPOの設定、DRパターンの選択。
2.ネッド。3-4：レプリケーション/バックアップ、GSLB/DNS、プロモーション手順の設定;プレイブックとランブックと。
3.ネッド。5-6：最初のDR演習（卓上→ステージ）、指標とCAPAの修正。
4.ネッド。7-8：交通制限された練習Prodライト；フェイルオーバーオートメーション。
5.ネッド。9-10：コスト最適化（FinOps）、 Tier 0のホット/AAへの移行、四半期ごとのエクササイズおよびレポートの規制。

17）ボトムライン

効果的なDRはバックアップだけではありません。これらは一貫したアーキテクチャ、フェイルオーバー/フェイルバックの自動化、データ分野（idempotency/replication）、トレーニング、透過的なコミュニケーションです。RTO/RPOが本物の場合、プレイブックが作動し、演習が定期的に行われると、災害は制御されたイベントに変わり、その後、サービスは迅速かつ予測可能に正常に戻ります。