第7章：復旧とロールバック判断（暫定/恒久、リスク管理）
この章で学ぶこと
- 暫定と恒久を分けて考える
- ロールバック判断の基準を持つ
- 復旧によるリスク（副作用）を評価する
成果物（または判断基準）
- 復旧方針（暫定/恒久）と判断根拠
- ロールバック手順と検証項目
本文
復旧判断は“正しさ”ではなく“リスク最小化”で行う。まず暫定対応で影響拡大を抑止し、恒久対応は状況安定後に実施する。
判断の観点
- 影響（継続時間と範囲）
- ロールバック可否
- 副作用（データ整合性、再発）
- 恒久対応の見通し
ロールバック判断マトリクス（例）
| 観点 | 確認する問い | ロールバック寄り（例） | 慎重/回避寄り（例） |
|---|---|---|---|
| 影響 | 顧客影響は大きいか、継続しているか | 売上/主要機能に影響、悪化傾向 | 影響が限定/回避可能 |
| 可逆性 | 変更は戻せるか | アプリのみ変更、手順が確立 | DB変更/外部副作用が大きい |
| データ整合性 | 戻すことで壊れるデータはあるか | 影響なし/検証観点が揃っている | 片側だけ戻すと不整合が出る |
| 見通し | 恒久修正の見込みは立っているか | 修正に時間がかかる/不明 | すぐ直せる、影響小 |
| 検証 | 戻した後に「良くなった」を判定できるか | SLI/エラー率等で判定可能 | 判定指標がない/観測できない |
典型の難所（例）
- DB マイグレーション等の“戻せない変更”: ロールバックではなく forward fix（前進修正）や復旧手順（復元/再適用）が必要になることがある
- 機能フラグ/段階リリース: 影響を抑止（フラグ OFF）→原因特定→恒久修正の順にしやすい
- 部分ロールバック: 片側だけ戻すと互換性（API/スキーマ/データ形式）で副作用が出やすい。境界を明確にして実施する
具体例（場当たり→再現性）
悪い例（場当たり）
原因が分かるまで何もしない
ロールバック手順が無い
良い例（再現性）
暫定: 機能フラグ OFF で影響を抑止する
恒久: 原因特定後に修正 PR
ロールバック: 手順/検証を Runbook（運用手順書）へ記録
判断根拠: 影響と副作用を比較
チェックリスト
- 暫定/恒久が分離されている
- ロールバック可否が評価されている
- 検証項目がある
まとめ
- 暫定と恒久を分離し、復旧判断は影響とリスク（副作用）を軸に行う
- ロールバック可否と検証項目を整理し、判断の再現性を確保する
- 手順は Runbook（運用手順書）として整備し、実施後の検証までを含めて運用する
次章への接続
- 次章: 第8章