システム停止が必要な場合、最小限に抑えられるように計画されているか？¶
Type: DeepDive
Category: リリース・ロールバック
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
システムの完全停止はユーザー影響が大きいため、無停止 or 最小停止のリリースを原則とすべき
ゼロダウンタイムを前提にした設計が難しい場合でも、停止時間の短縮・影響範囲の明示・代替手段の提示は設計時点での必須検討事項になる
例¶
- DBマイグレーションをオンラインで段階適用（カラム追加→バックフィル(Insert/Update)→切替）
- 機能切替は新旧両APIを一時的に動作させ、停止を回避
- フロント側に「一時利用停止」画面を表示し、ユーザーに影響を伝達
よくある失敗例¶
- DBスキーマ変更時に長時間ロックが発生し、関連機能がすべて停止
- 機能切替にあたりダウンタイムが必要だったが、告知が不十分で苦情が発生
- 旧データ形式と新形式の互換性が考慮されておらず、移行時に一括停止が必要になった
FAQ¶
Q. なぜゼロダウンタイムが難しい？
A. データ整合性・バージョン非互換・スキーマ移行などが複雑になるため。ただし完全停止を避ける工夫は可能
Q. 一部機能のみ停止は許される？
A. ユーザー影響が小さければ許容されることが多いが、影響範囲を明示し、リカバリ策も用意することが前提です