DR戦略とRTO/RPO

1）基本原則

1.手段の前に目標。まず、RTO/RPOと重要なシナリオを策定し、技術を選択します。
2.重要度によるセグメンテーション。すべてのサービスが「金」を必要とするわけではありません。ビジネスの重要性によって分けて下さい。
3.データはDRRの中核である一貫性、レプリケーション、破損検出、およびリカバリポイントは、ハードウェアよりも重要です。
4.自動化と検証可能性。DRはIaC、回復回帰テスト、およびテレメトリーなしで無意味です。
5.教えと証拠。通常の「ゲームの日」のないプランは、準備の錯覚です。
6.安全性とコンプライアンス。暗号化、分離、WORM/不変バックアップ、DPA/管轄。

2）利用規約と対応

RTO-イベントの瞬間からサービスが「通常」に復元されるまでの時間。
RPOは、回復時の最後の健全なデータポイントの「時代」です。
RLO （Recovery Level Objective）-復元する必要がある機能のレベル（最小実行可能なサービス）。
MTD （Maximum Tolerable Downtime）-ビジネスが容認できない損傷を受けるしきい値。
RTA/RPA（実績）-実践からの実際の時間/回復ポイント。

コミュニケーション：RTO ≤ MTD；RPA ≤ RPO。目標と事実の間のギャップは、死後と改善の主題です。

3） DR戦略クラス（準備レベル）

4）私たちが守るシナリオ

地域/クラウド/データセンター（電気、ネットワーク、プロバイダ）の損失。
データの破損/オペレータエラー（削除、壊れたレプリカ、論理的な破損）。
マルウェア/ランサムウェア。
リリース/構成の欠陥（大量停止）。
中毒の崩壊（KMS、 DNS、秘密、支払いプロバイダー）。
法的イベント（ブロック、管轄からのデータのエクスポートの禁止）。

各シナリオについて、RTO/RPO、 DRレベル、プレイブック、責任者を指定します。

5）データ戦略（RPOの鍵）

5.1バックアップ

完全+増分+トランザクションログ（DB用）。
不変/WORMストレージとオフラインコピー（「air-gapped」）。
メタデータと暗号署名を持つバックアップのカタログ。スケジュールされたテストのリストア。

5.2レプリケーション

Synchronous （低RPO、 latentnost、腐敗伝播のリスク）。
非同期（perf、 RPO> 0への影響が少ない；腐敗した子供と組み合わせる）。
CDC （Change Data Capture）によるストリーミングレプリケーションとステートの再構築。

5.3論理的な腐敗からの保護

ウィンドウ≥ N日でのバージョン管理/」points in time」 （PITR）。
不変署名（balances、 sum、 chexums）は「、壊れた」データの早期検出です。
「遅い」レプリケーションチャネル（遅延15〜60分）をバッファとして瞬時に破損します。

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6）適用、状態、キャッシュ

ステートレス層-任意の領域（Gitのイメージ/チャート/マニフェスト）でスケールと再起動します。
ステータス（DB/キャッシュ/kew）：真実のソースはDBの1つです。キャッシュとインデックスは過剰生成可能です。
Idempotenceと再ドライブ-イベントの再配送は許可されています。outbox/inbox、 dedup、およびバージョンを使用します。

7）ネットワークとエントリーポイント

GSLB/DNS-feilover：レイテンシ/ヘルスベース、短いTTLからクラッシュウィンドウ。
Anycast/L7プロキシ：単一のIP、地域の健康ルーティング。
地域ドメインと管轄政策（PIIのためのジオピンニング）。
証明書ファイル/KMS：スペアチェーン、デュアルキー。

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8）操作モデルおよびオートメーション

IaC/GitOps： 2番目のリージョンインフラストラクチャ=コード、「シングルボタン」展開。
コードとしてのポリシー：gate 「no DR manifests/backups/alerts-no release」。
Runbooks：ステップバイステップの手順と、両方のリージョンと同じ「赤いボタン」。
秘密：短命のクレジット、OIDC連盟、妥協/リコール計画。

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9）練習とテスト（ゲームの日）

シナリオテーブル：データベースの損失、「壊れた」データ、KMSの障害、リージョンドロップ、突然の排出制限。
頻度：ミッションクリティカルの四半期；半年に一度-残りのために。
練習のメトリクス：RTA/RPAと目標、自動ステップの割合、手動介入の数、プレイブックのエラー。
リリースのカオススモーク：依存性分解はDRパスを「壊す」べきではありません。

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10）プレイブック（正規テンプレート）

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11） DRの観測可能性の指標

レプリカラグ（秒）、RPOドリフト（ターゲットと実際のRPOの違い）。
SLIの復元：環境による冷たい/暖かい回復時間。
適用範囲：プレイブック/バックアップ/PITR ≥ N日のサービスの％。
ドリルスコア：自動ステップの割合、RTA分布、エラー率。
不変性：WORM/air-gappedのバックアップの％。
イベントメトリクス：フェイク後のキュー長/再ドライブ速度。

12）コストとトレードオフ

CapEx/OpEx：暖かいスタンドはActive/Activeよりも安価ですが、パイロットライトよりも高価です。
出口：地域間/クラウド間のレプリケーションにはコストがかかります。キャッシュ/圧縮/ローカル集計。
RTO/RPO vs$：可用性の各「9」とRPOの1秒は数倍の高価です-ビジネスと調整します。
緑のウィンドウ：バッチ・レプリケーション-安い/」緑「時間で。

13）安全性とコンプライアンス

暗号化「at rest」と「in transit」は、地域ごとにKMSドメインを分離します。
不変バックアップ、ランサムウェア保護：「3-2-1」（3コピー、2メディア、1オフライン）、MFA-delete。
管轄区域：PIIの地理ピン留め、バックアップのローカライズ、TTLの上の法的保持。
タイムアクセス：DRオペレーションの一時的な役割、監査ログ。

14）アンチパターン

「後で計画を書きましょう」-DRは演習なし。
論理的な破損から保護されないレプリケーション-エラーを即座に乗算します。
1つのKMS/秘密領域-feiloverは不可能です。
定期的な復元なしのバックアップ-「シュレッディンガー」DRR。
リージョン間の密接に関連する同期トランザクションは、カスケードのレイテンシー/フォールです。
優先順位付けなし：すべてのための同じDRレベル（高価で無駄）。

15）建築家のチェックリスト

1.サービスとシナリオでRTO/RPO/RLOを定義？
2.分類されたデータ：真実のソース、PITR/ウィンドウ、 WORM/不変？
3.DR（バックアップ/リストア、パイロット、ウォーム、A/P、 A/A）はサービスごとに選択されていますか？
4.ネットワーク：GSLB/Anycast、マージン付き証明書/キー、読み取り専用フラグ？
5.App： idempotence、 outbox/inbox、 offsetting transactions？
6.IaC/GitOps/Policy as Code：ワンクリックで2つ目のリージョンを展開しますか？
7.ドリル：スケジュール、KPI RTA/RPA、トレーニング後の活動？
8.監視：遅延、RPOドリフト、リストアSLI、ドリルスコア、不変バックアップ？
9.セキュリティ/コンプライアンス：KMSドメイン、管轄区域、法的保持？
10.コスト：出口予算、緑の窓、経済的に健全なレベル？

16）ミニレシピとスケッチ

16.Postgresのための1 PITR（アイデア）：

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16.2論理的な破損に対する保護（遅延レプリカ）：

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16.3トラフィックスイッチング（GSLB擬似API）：

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16.4 feilover（擬似コード）後の不変量のチェック：

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

結論

DRは、ダメージが増大するよりも迅速に技術的および組織的な意思決定を行う能力です。現実的なRTO/RPOを特定し、十分な可用性を選択し、インフラストラクチャとチェックを自動化し、定期的に運動し、実際のRTA/RPAを測定します。その後、事故は災害に変わるのではなく、予測可能な結果を伴う制御された事件に変わるでしょう。