🌊
障害発生時のリカバリ手順が整理されているか？
障害発生時のリカバリ手順が整理されているか？
背景・概要
障害が発生した際に「誰が・何を・どの順で」対応すべきか明記されていないと、対応が後手に回り、復旧までの時間が大きく悪化する
システム設計時点でリカバリ方法・操作フロー・対応者の洗い出しまで含めておくと、運用チームや夜間対応も安心して対応できる
例
- 特定のキューが詰まった場合、手動再実行用の管理画面リンクを記載する
- メッセージ送信失敗時のSQSリトライと、最終的にデッドレターキューに送られたメッセージの再取り込み方法をドキュメント化する
- 再処理時に冪等性が担保されるよう実装済みであることを明示する
よくある失敗例
- 再実行手順が属人化していて、特定メンバーがいないと復旧できない
- 原因は特定できたが、再処理の順番や対象が不明で、誤処理を起こす
- チケット起票や管理画面操作に一貫性がなく、操作ミスが発生
FAQ
Q. リカバリ手順は運用チームに任せてよくない？
A. システムの動きが分かるのは開発チームなので、設計段階でのドキュメント化が望ましい
Q. 実装していない機能でも書くべき？
A. 未実装でも「こういう復旧方針を前提とする」と明記しておけば、後続チームの作業に役立つ
関連観点
- バックアップ戦略が整理されているか？
- 非同期処理のフォールバック戦略が設計されているか？（失敗時の再実行順序やデータの重複生成防止などの考慮）
- 監視対象が適切に設計され、異常時の通知が設定されているか？
- 障害時のデータ復旧手順が考慮されているか？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🔰 災害対策・可用性
レベル：DeepDive（実装・運用レベル）
推奨読者：設計リーダー / SRE / インフラ設計者 / レビュー担当者
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion