🦁
ロールバック手順が用意されているか？
ロールバック手順が用意されているか？
背景・概要
本番での問題発生時、即時に元の状態に戻せる手順（ロールバック）があるかどうかはサービス信頼性(SLA)の鍵になる
ゼロから作業するのではなく、事前に自動化・手順化されたロールバック設計をすべき
例
- コンテナ実行基盤（例：Cloud Run, AWS App Runner, Azure Container Apps）でリビジョン機能を活用し、トラフィックを旧バージョンへ即時切り替え可能にする
- DBマイグレーションは 巻き戻し可能な設計で、rollback.sql を事前用意
- ロールバック実施後の影響範囲（ログ・通知・ユーザー影響）も明記
よくある失敗例
- リリース直後に問題発覚したが、旧バージョンに戻す方法が用意されておらず対応に数時間
- DBスキーマ変更後にエラーが出たが、差分リカバリ用SQLがなく、巻き戻しできなかった
- 機能フラグだけ戻してUIが非対応のままで混乱
FAQ
Q. ロールバックは毎回必要？
A. ケースバイケースだが重要機能・スキーマ変更・外部連携がある機能は必ず用意すべき。軽微なUI修正などの場合は不要という判断もあり得る
Q. 巻き戻せないDB変更はどう扱う？
A. バックアップ取得・二重書き込み・非破壊変更などでリスクを下げる設計が必要
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🚀 リリース・ロールバック
レベル：DeepDive（実装・運用レベル）
推奨読者：設計リーダー / SRE / インフラ設計者 / レビュー担当者
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion