稼働中サイトのサーバー移行と改修を、同時事故にしないために

移行と改修を、別の成功条件にする

最初に「現在のサイトが新環境で同じように動くこと」と「新しい機能やページが動くこと」を分けます。移行だけの確認地点を作ると、問題が起きたときに変更原因を限定できます。

1. 現行環境の仕様と依存先を確認する
2. 新環境へ現行サイトを再現する
3. URL、表示、フォーム、計測、ファイルを確認する
4. CMSや新機能を別の変更として追加する
5. 切替条件を満たしてからDNSや接続先を変える

状況によって同時公開が必要でも、確認の単位は分けられます。一つの大きな作業にせず、どこまで成功したかを判定できる地点を作ります。

ファイル以外の依存先を棚卸しする

画面が表示されても、サイト全体が移行できたとは限りません。着手前に、サイトの外へつながるものを洗い出します。

• ドメイン、DNS、SSLの管理者と更新権限
• PHP、データベース、CMS、定期処理の条件
• 問い合わせフォームの送信元と送信先
• 解析タグ、広告タグ、外部API、埋め込み
• 画像、PDF、動画、ダウンロードファイル
• リダイレクト、検索除外、サイトマップ
• バックアップ、ログ、監視、障害時の連絡先

誰かが管理しているはず、という項目ほど切替時の停止原因になります。値そのものを共有資料へ広げる必要はありませんが、管理者と確認方法は明確にします。

切替前に、新環境だけで確認できる状態を作る

DNSを切り替えてから初めて新環境を見るのでは遅すぎます。一般公開前に、新環境へ接続して主要画面と処理を確認します。

• トップ、一覧、詳細、検索、404など代表URL
• フォーム送信とメール到達
• 管理画面へのログインと更新
• 画像、PDF、CSS、JavaScriptの参照
• リダイレクトと正規URL
• 定期処理、キャッシュ、外部連携

本番ドメインでしか確認できない項目は別に残し、切替直後の確認へ回します。事前に確認できることと、切替後でなければ分からないことを混ぜません。

切替手順と、戻す手順を同時に作る

公開手順だけでは、問題が起きたときに止まります。切替を判断する人、作業する人、確認する人、戻す判断をする人を決めます。

• 切替前の最終バックアップと更新停止範囲
• 切替時刻と、関係者の待機時間
• 変更する設定と作業順
• 確認するURL、フォーム、管理画面
• 許容できる不具合と、切り戻す条件
• 旧環境を保持する期間

「問題があれば戻す」だけでは判断できません。何分以内に、どの状態なら、誰が戻すかまで具体化します。

切替後は、表示以外の変化を見る

公開直後に見える画面が正常でも、メール、定期処理、検索エンジン、外部サービスの問題は遅れて現れます。切替直後、翌営業日、一定期間後に確認する項目を分けます。

フォームの受信、エラーログ、主要URLの応答、計測データ、検索エンジンのクロール、CMS更新を確認します。旧環境を閉じるのは、新環境の運用を確認してからです。

移行日を決める前に止まるべき条件

• ドメインやDNSの管理者が分からない
• 現行サイトの実行条件とバックアップを確認できない
• フォームや外部連携の送信先が分からない
• 更新を止める時間と差分反映方法が決まっていない
• 新環境の事前確認方法がない
• 切替後の確認者と連絡経路がない
• 旧環境へ戻す条件が決まっていない

日付を決めること自体が進捗になる場合もあります。しかし前提が揃わないまま固定すると、調査に必要な時間まで失います。確認できない条件は、予定表の外へ隠さず、移行可否の判断項目として扱います。

切替前のチェックリスト

• 環境移行と機能追加の成功条件を分けたか
• ドメイン、DNS、SSL、メール、外部連携の管理者を確認したか
• 新環境で現行サイトの主要機能を事前確認したか
• 本番ドメインでのみ確認できる項目を分けたか
• 更新停止と最終差分の反映方法を決めたか
• 切替手順、確認手順、切り戻し手順があるか
• 公開直後・翌営業日・一定期間後の確認を決めたか
• 旧環境を閉じる条件と保持期間を決めたか