障害時の戻し方は一つではありません。
| 方法 | 内容 | 向く状況 |
|---|---|---|
| ロールバック | 前の版へ戻す | 変更が独立し、旧版が動く |
| ロールフォワード | 追加修正を出す | データを戻せない、小修正で直る |
ロールバックできない例
新しいDB列へデータを書き、古い列を削除した後では、旧アプリへ戻しても動かない可能性があります。コードだけでなくデータ互換性を確認します。
判断材料
- 利用者への影響と緊急度
- 問題箇所を特定できているか
- 旧版と現在データの互換性
- 修正の大きさと検証時間
- 戻した時に失われる変更
事前に決める
障害中に初めて考えず、リリース前に戻すコマンド、判断者、確認指標を用意します。
戻せるかどうかはデプロイ機能ではなく、コード・設定・データを含む設計で決まります。
ケーススタディ：注文番号の形式変更
新しい版が注文番号を数値から文字列へ変更し、公開直後から注文詳細の500エラーが増えたとします。まず変更版だけが失敗しているか、失敗率、影響する注文、直近のデータ書き込みを確認します。新旧アプリが同じ文字列形式を読めて、旧版へ戻す操作が数分で終わるならロールバックが有力です。一方、新版が旧版では解釈できない注文番号をすでに大量に保存していたら、コードだけ戻すと障害を広げます。この場合は読取処理を両形式へ対応させる小さなロールフォワードが安全です。
判断は「原因が分かったか」だけでは足りません。復旧までの見込み時間、操作の可逆性、データ損失の可能性、旧版の既知障害、修正版を検証できる範囲を並べます。緊急だから常に戻す、修正が一行だから常に前へ進む、という固定ルールは使えません。一行の修正でも認証や金額計算なら検証が重く、ロールバックでもDB変更を伴えば危険です。
実行中の観測と中止条件
作業前に基準時点のエラー率、成功件数、待ち行列、主要画面の応答時間を記録します。実行後は同じ指標を一定間隔で見て、新しい異常がないか確認します。良い対応は、判断者、実行者、利用者への連絡担当を分け、いつ何を根拠に選んだかを時系列で残します。悪い対応は、複数人が別々の修正を同時に出し、どの変更で回復したか分からなくすることです。
予定時間を超えても指標が戻らない、データ不整合が増える、監視できない状態になった場合は、当初の方法を続けない中止条件にします。ロールバック後も、キャッシュや非同期処理に新版の影響が残ることがあります。アプリの版だけで成功とせず、既存注文の表示、新規注文、取消処理、遅延ジョブまで確認します。
平常時に作る戻しやすさ
DB変更は、列を追加して新旧版が共存できる期間を設け、読み書きを切り替え、最後に古い列を削除する順序に分けます。設定変更にも版と履歴を持たせ、リリース単位を小さくします。定期的に検証環境で戻す手順を実行し、所要時間と権限不足を観測します。手順書があっても実行できなければ戻せる設計とは言えません。
よくある誤解：前の版は必ず安全ではない
旧バイナリが既知でも、データと外部サービスは公開前の状態とは限りません。新版が新形式を書き込んだ後に旧版へ戻すと、読めないレコードを増やすことがあります。また、決済やメール送信はコードを戻しても取り消されません。ロールバック可能性はコードの履歴ではなく、現在のデータを旧版が扱えるかで決まります。
ロールフォワードも「正しい修正が完成するまで待つ」ことではありません。障害経路を止める機能フラグ、旧形式も読める互換処理、問題入力だけを隔離する変更など、影響を縮める最短の新しい版を選びます。
| 判断材料 | ロールバック寄り | ロールフォワード寄り |
|---|---|---|
| データ形式 | 旧版と互換 | 新形式を保存済み |
| 復旧時間 | 数分で切替可能 | 修正の方が早い |
| 外部副作用 | まだ発生していない | 決済・通知が発生済み |
| 原因範囲 | 新版に限定 | 設定やデータも関与 |
| セキュリティ | 旧版も安全 | 旧版に既知の脆弱性 |
動作確認：復旧操作を訓練する
検証環境で新旧版を同時に起動し、移行前、移行中、移行後のデータを双方が読めるか確認します。切替時間、キャッシュ更新、ジョブの重複、監視アラートの復帰を記録します。手順の途中で権限申請や担当者判断が必要なら、目標復旧時間へ含めます。
本番判断では、エラー率だけでなく不正な書き込み件数、未処理キュー、利用者影響、復旧後に必要な補償を追います。中止条件を先に数値で決め、改善しなければ次の手段へ移ります。戻したという操作ではなく、利用者影響が止まりデータ整合性が確認できた時に復旧完了です。
まとめ
ロールバックとロールフォワードの使い分けで大切なのは、用語を単独で暗記することではありません。期待、観測、差分、仮説、操作、結果を順に残し、テーマに合う証拠で判断します。小さく確認し、再現できる説明を残すことが、修正と学習の両方を次へつなげます。
参考リソース
復旧方針は平常時に演習し、実測した切替時間と互換性を手順へ反映します。判断者が不在でも実行可能かを確認し、例外時の連絡経路も更新します。
複数地域へ配信している場合、版の切替は同時ではありません。新旧版が混在する時間に、同じキューやDBを安全に扱える契約が必要です。クライアントアプリを即時に戻せない場合も、サーバは古いクライアントの要求を一定期間受けられるようにします。APIの必須項目削除や意味変更を一回で行わない理由です。
ロールバック手順には、対象版、実行コマンド、必要権限、承認者、予想時間、確認指標、失敗時の次手を含めます。スクリーンショットだけの手順は環境変更で陳腐化するため、定期演習で更新します。バックアップも存在確認だけでなく、隔離環境へ復元してアプリが読めることを試します。
障害中は復旧を最優先し、原因分析と恒久修正を混同しません。安全な旧版へ戻せるなら、完全な原因説明を待たず影響を止めます。ただし戻すことで証拠が消える場合は、必要なログや追跡IDを先に保全します。復旧後の分析では個人の操作ミスで終わらせず、その操作が本番へ到達できた権限や検証不足を見直します。
状況別の復旧設計
表示文言の誤りでデータ更新がないなら、直前版へ戻す判断は比較的単純です。対してDB列の意味変更、決済、メール、キュー投入を伴う変更は、副作用を一覧にしてから選びます。コードを戻す間にも新形式の書き込みが続くなら、先に書き込み経路を止めるか、両形式を読める版を出します。
段階的移行では、旧列を残して新列を追加し、両方へ書き、読み取りを切り替え、十分な監視期間後に旧列を削除します。各段階を独立したリリースにすれば、戻せる境界が増えます。破壊的DDLと新コードを同時に公開すると、旧版へ戻す選択肢を自分で失います。
機能フラグも万能な戻し方ではありません。フラグを切っても既に作成したデータや送信済み通知は残ります。依存するジョブ、キャッシュ、モバイルアプリの旧版がどの状態を読むかも含めます。フラグ自体の権限、監査記録、期限切れフラグの削除責任も決めます。
復旧後は原因修正だけで終えず、影響した利用者とデータを特定し、再処理、返金、通知が必要か判断します。時系列には検知、判断、操作、指標回復、データ確認を分けて残します。次回は検知を早める指標、互換期間、演習頻度へ反映します。
