ロールバック

サイトの更新やリニューアル後に致命的な問題が発覚した際、安全だった「以前の状態に巻き戻す(復元する)」作業のこと。手法としては、事前のバックアップからの復元、Git(ギット:プログラムのバージョン管理システム)による変更履歴(リビジョン)の差し戻し、サーバの旧環境への切り替えなどがある。プラグイン更新やサーバ設定変更で画面が真っ白になった時など、「やっぱり前の方がちゃんと動いていた」と気づいた時の“最後の砦”となる。

最大の特徴：「戻せません」は許されない。公開前の絶対条件

現場の鉄則は、「公開して終わり」ではなく「いつでも元に戻せる準備が整って初めて公開してよい」ということ。制作業者が公開(リリース)作業を行う場合、事前の契約段階で「ロールバック手順書」の提出を要求しておくのが発注者としての身を守る術。これを用意せずに本番作業を強行すると、トラブル発生時に業者から「バックアップがないので戻せません」と宣告され、会社が大損害を被る事故に直結する。

運用の要点：プロが行う周到な準備と「DB(データベース)」の罠

実務では、本番反映の直前に以下の準備を行う。

• スナップショット(ある瞬間のデータを丸ごと保存した状態)の取得や、バージョン管理へのタグ付けを行う。
• 「誰が・どうやって・何分で戻せるか」を 1 枚の手順書にする。
• ロールバック後の検証チェックリスト(計測タグ、フォーム、SSL 証明書(SSL / TLS)、SEO の基礎設定が古い状態に戻っていないか等)を用意する。
• 【最重要】デザインなどの「ファイル」と、記事や顧客データが入る「DB(データベース)」のバックアップを分けて考える。

現場でよくある「落とし穴」

• 「DB ごと巻き戻し」によるデータの完全消失：システムエラーに慌てて、サイト全体(DB 含む)を昨日の状態にロールバックしてしまう。悲惨な末路として、エラーは直ったものの、「昨日のバックアップ時点から今日までの間に投稿された新しい記事」や「お客様からの問い合わせデータ」「EC の注文データ」まで全て消滅し、顧客に多大な迷惑をかける(※システムだけを戻し、DB データは最新を保持する切り分け設計が必須)。
• 業者への過度な依存による「詰み」：ロールバックの手順が業者の頭の中にしかなく、金曜の夜間にトラブルが起きた際、業者が土日休みで連絡がつかず、週明けまでサイトが死んだままになる(緊急時は自社でも動ける体制や手順の共有が必要)。
• その他のリスク：バックアップを取らずに本番反映する、サーバ移転(移管)において旧サーバをすぐに解約してしまい「いざという時の戻り先」を自ら断ってしまう、など。