🐥
障害時のデータ復旧手順が考慮されているか？
障害時のデータ復旧手順が考慮されているか？
背景・概要
障害発生時に失われたデータをどのように復元するかを明示しておくことは、サービス品質の担保に直結する
保存・ログ出力・再取得APIの有無など、復旧方針によって設計が大きく異なるため、早期に合意しておく必要がある
例
- 通知送信ログをBigQuery・Redshift・Azure Data Explorerなどの分析基盤や、RDBMS（PostgreSQL/MySQL等）にアーカイブし、失敗通知は再送可能に
- 重要イベントのOutboxパターンにより、DB更新ログから再送処理が可能
- バックアップからのDBスナップショットリストア手順を手順書に記載済み
よくある失敗例
- 障害時にデータが失われ、復元できないことが後から発覚
- 復旧方法がバックアップのみで、数時間分のデータ損失が確定
- 誰も復旧方法を知らず、試行錯誤している間にSLAを超過
FAQ
Q. 自動バックアップだけで十分？
A. リカバリポイントまでの復元（RPO）と復旧までの時間（RTO）を意識しないと、意外と間に合わないものです
Q. データ復旧対象はどこまで考える？
A. 「ユーザーが修正できないデータ」はすべて復旧対象とすべきかな。マスターデータや機密データは特に注意が必要
関連観点
- バックアップ戦略が整理されているか？
- 非同期処理のフォールバック戦略が設計されているか？（失敗時の再実行順序やデータの重複生成防止などの考慮）
- 障害発生時のリカバリ手順が整理されているか？
- 監視対象が適切に設計され、異常時の通知が設定されているか？
- 重要な処理において、フェイルオーバー設計が組み込まれているか？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🔰 災害対策・可用性
レベル：DeepDive（実装・運用レベル）
推奨読者：設計リーダー / SRE / インフラ設計者 / レビュー担当者
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion