- システムのリリース・設定変更・パッチ適用後に問題が発生した際に、変更を取り消して変更前の正常な状態に戻す（元に戻す）作業・手順のこと
- 「ロールバック」とほぼ同義で使われるが、IT運用・プロジェクト管理の文脈では「バックアウト計画（Backout Plan）」として事前に準備・承認された緊急時の撤退手順として位置付けられる
- 変更管理（ITIL Change Management）のプロセスでは、本番環境への変更を実施する前にバックアウト計画を必ず準備することが求められ、「変更してダメだったら元に戻せる状態」を保証することが原則だ
【深掘り】これだけ知ってればOK！
バックアウト計画に含めるべき要素を整理しよう。バックアウトの判断基準：どのような状況になったらバックアウトを決定するか（例：エラー率5%超・5分以内に復旧見込みなし）。バックアウトの具体的な手順：誰が・何を・どの順番で実行するか。バックアウト後の確認方法：正常に戻ったことをどう確認するか。タイムリミット：変更後何分以内にバックアウト判断を行うか。
バックアウトとロールバックの使い分けを整理しよう。両者は実質的に同じ意味（変更を戻す）で使われることが多いが、文脈が異なる場合がある。バックアウトはITIL・プロジェクト管理の文脈で「変更リクエスト（Change Request）の撤回」として使われる。ロールバックはデータベース・Gitのバージョン管理・デプロイツールの文脈で技術的な操作として使われることが多い。
ITIL（IT Infrastructure Library）のChange Managementプロセスでは、変更の実施前にCAB（Change Advisory Board：変更諮問委員会）がバックアウト計画を含む変更リクエストを審査することが求められる。「バックアウトできない変更」は最も高リスクに分類され、十分な事前テストと承認プロセスが必要だ。
よくある誤解
バックアウトはシステム担当者の独断で素早くやればいいと思っている
特に本番環境のバックアウトは事前に承認されたバックアウト計画に従って実施することが重要だ。誰がいつバックアウトを判断するかの権限・手順・確認方法をチームで合意しておかないと、対応が混乱して被害が拡大するリスクがある。
バックアウトすればデータも含めて完全に元に戻ると思っている
アプリケーションコードやシステム設定はバックアウトで元に戻せるが、その間にDBに書き込まれたデータ・ユーザーの操作ログ・外部APIへのリクエストは必ずしも元に戻せない。バックアウト計画ではデータの取り扱いについても事前に検討しておく必要がある。
会話での使われ方
今回のリリース計画、バックアウト手順を書いておいてください。変更後10分以内に問題が発生したらバックアウトを実行します。
リリースマネージャーがリリース計画書の準備でバックアウト手順の記載を担当者に指示している場面。
バックアウトに30分かかるとなると、その間ずっとサービスが止まります。もっと素早く戻せるようにDockerイメージをバージョン管理して即座に切り替えられる仕組みを作りましょう。
インフラエンジニアがバックアウトの所要時間短縮のための技術的な改善を提案している場面。
CABのレビューでバックアウト計画が不明確だと指摘されました。「問題が発生したら戻す」だけでなく、誰が判断して誰が実行してどう確認するかを明記してください。
IT変更管理担当者がITILのChange Managementプロセスに従ったバックアウト計画の不備を指摘している場面。
【まとめ】3つのポイント
- 変更後に問題が発生したときに元の状態に安全に戻すための計画と手順：バックアウトが素早く実行できる状態を保証しておくことでリリースの失敗時の被害を最小化し、変更に踏み切れる安心感が変化のスピードを上げる
- 判断基準・実行手順・確認方法・タイムリミットを事前に定義する：本番障害の混乱の中でバックアウトを適切に実行するために、「誰が・いつ・何を・どの順番で・どう確認するか」を事前に合意・文書化しておくことが不可欠だ
- Gitタグ・Dockerバージョン・スナップショットでバックアウトを高速化：バックアウトに必要な技術的準備（デプロイ成果物のバージョン管理・DBバックアップ・インフラのスナップショット）を整えて所要時間を事前計測しておくことが素早い撤退判断を支える
よくある質問
-
Qバックアウトとロールバックの違いは何ですか？
-
A
実質的には同義語として使われることが多いです。使われる文脈が異なる場合として、バックアウトはITILの変更管理プロセスや計画文書の文脈で「変更を撤回する計画」として使われます。ロールバックはデータベース・Git・デプロイパイプラインの技術的な操作として使われることが多いです。
-
Qバックアウト計画に最低限含めるべき内容は何ですか？
-
A
バックアウトの判断基準（何が起きたらバックアウトするか）・バックアウトの具体的な実行手順（誰が何をどの順番で）・バックアウト後の動作確認方法・タイムリミット（変更後何分以内に判断するか）・バックアウトの所要時間（実際に何分かかるか）の5項目を含めることをお勧めします。
-
Qバックアウトできない変更はどう扱えばいいですか？
-
A
データベースの破壊的なスキーマ変更・外部への通知メール送信など、バックアウトできない変更は最高リスクカテゴリとして扱います。十分な事前テスト・ステージング環境での検証・小さな変更への分割・承認プロセスの強化が必要です。どうしても不可逆な変更が必要な場合は、可能な限りユーザー影響が少ない時間帯に実施します。
-
Qバックアウトとフォワードフィックスはどちらを選ぶべきですか？
-
A
障害の原因と影響範囲によって判断します。素早くバックアウトできる・バックアウトしても機能損失が許容できる場合はバックアウト優先です。バックアウトに時間がかかる・修正が明確で素早く適用できる・バックアウト自体に追加リスクがある場合はフォワードフィックス（そのまま進んで修正する）を選びます。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| ロールバック | ロールバックを押さえると本記事の理解がさらに深まります。ロールバックというのは、システムやデータを、問題が起きる前の正常だった状態に巻き戻す操作のことなんだ。 |
| データ | 本記事のテーマと実務上セットで使われることが多い用語です。コンピュータが処理する数値や文字、画像といった事実や資料そのもの、それがデータだ |
| ITIL | 本記事のテーマと実務上セットで使われることが多い用語です。ITILの主要な特徴と用途を理解することで、関連する技術・制度・概念を正確に把握できるようになる |
| データベース | データベースは関連分野でよく登場する重要キーワードです。データを効率よく蓄積・検索・更新・削除できるよう構造化して管理する仕組みの総称。専用エンジンを持ち大量データを高速操作できる |
| 変更管理 | 変更管理を押さえると本記事の理解がさらに深まります。変更管理の主要な特徴と用途を理解することで、関連する技術・制度・概念を正確に把握できるようになる |
【出典】参考URL
https://www.axelos.com/certifications/itil-service-management ：ITIL Change Managementの変更管理プロセス
https://e-words.jp/w/%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%82%A6%E3%83%88.html ：IT用語辞典「バックアウト」
https://docs.gitlab.com/ee/ci/environments/deployment_safety.html ：GitLabによるデプロイのロールバック・バックアウトのベストプラクティス
コメント