移行を予約する前にプロジェクトを棚卸しする
client.example.comの例示的な問い合わせウェブサイトを使用します。編集者はプロジェクトページを公開し、訪問者はブリーフをアップロードし、スケジュールタスクが問い合わせをクライアントシステムにエクスポートします。その公開ページを移行するだけでは作業の一部しかカバーしません。日付を確定する前に、ソースと移行先への承認されたアクセス、ドメインコントロール、復旧コピーを確認します。
すべてのコンポーネントについて、所有者、バージョン、場所、依存関係、受け入れチェックを記録します。資格情報の場所は棚卸しに保持し、パスワードと秘密鍵は承認されたシークレットストアに保持します。
テーブルのすべての列を表示するには横にスクロールしてください。
| コンポーネント | 移行前に記録する | 誰が確認するか |
|---|---|---|
| ドメインとDNS | レジストラ、DNSオペレーター、現在のレコードとTTL | クライアントアカウント所有者 |
| アプリケーション | リリース、ランタイム、拡張機能、デプロイ方法 | 代理店メンテナー |
| データとアップロード | データベース、アップロードパス、バックアップ方法、最後に使用可能なコピー | データオペレーター |
| フォームと統合 | 受信者、Webhookエンドポイント、許可されたテスト送信先 | クライアントワークフロー所有者 |
| スケジュールされた作業 | Cronまたはスケジューラ、タイムゾーン、キュー、最後に成功した実行 | 代理店メンテナー |
本番環境に触れる前に復旧コピーを証明する
別のテスト送信先に復元し、ライブデータベース上には決して行わないでください。PostgreSQLでは、SQLダンプは一貫したデータベーススナップショットを表しますが、単一データベースのダンプにはクラスタ全体のロールやテーブルスペースは含まれません。アプリケーションが必要とするサポートオブジェクトを記録します。そのデータベーススナップショットも、別途コピーされたアップロードを自動的に一貫させるものではありません。 PostgreSQL SQLダンプのドキュメント.
WordPressプロジェクトの場合は、そのファイルとデータベースを含めます。URLが変更される場合は、その移行固有のガイダンスに従ってください。無差別なデータベースの検索と置換は、シリアル化された値を破損する可能性があります。選択した方法をコピー上でリハーサルします。 WordPress移行ハンドブック.
既知の問い合わせとその添付ファイルを記録し、それらを復元し、アプリケーションを通じて両方を検証します。元のバックアップを移行対象のサーバー外で保護された状態に保ちます。完了したファイル転送は復元の受け入れではありません。
クライアントが気づくワークフローをリハーサルする
アクセス制御された一時ホスト名またはオペレーター専用の名前マッピングを使用してテストします。HTTPSや関連するコールバックURLを含め、そのテスト経路用にアプリケーションを設定します。コピーが本番メッセージを送信したり、実際の支払いを処理したり、本番スケジュールを実行したりするのを防ぎます。不要な個人データではなく、承認された合成レコードを使用します。
各チェックの前に期待される結果を書きます。合格または不合格、証拠の場所、レビューした人を記録します。ホームページのスクリーンショットはグリッド全体の代わりにはなりません。
テーブルのすべての列を表示するには横にスクロールしてください。
| ワークフロー | 期待結果 | 保持する証拠 |
|---|---|---|
| フォームと添付ファイル | 保存された問い合わせ1件と読み取り可能なファイル1件。テスト受信者のみ | 合成レコード識別子と配信の観察 |
| Webhook | 承認されたテストイベントが意図したテストコンシューマーに到達する | イベント識別子とコンシューマー結果 |
| スケジュールされたエクスポート | 制御された1回の実行、正しいタイムゾーン、旧サーバーの重複なし | 実行識別子とエクスポートされたレコードの比較 |
| 編集者と訪問者の経路 | 期待される権限、リダイレクト、アセット、HTTPSの動作 | チェックされたURLと障害の詳細 |
旧システムの最後の書き込みを定義する
この例では、代理店が短いメンテナンスウィンドウを提案します。問い合わせ送信と編集を一時停止し、古いエクスポートスケジュールを停止し、キューに入った作業を完了または処理し、最終的なデータベースとアップロードのコピーを作成します。クライアントは、送信が一時的に利用できないことを訪問者にどのように伝えるかを承認する必要があります。
最後に受け入れられた問い合わせ識別子と書き込みが停止した時刻を記録します。新しい送信を許可する前に、移行先にそのレコードとその添付ファイルが含まれることを検証します。DNS応答が異なる可能性がある間、ソースが独立した書き込みを受け入れられないように保ちます。書き込みを一時停止できないプロジェクトには、アプリケーション固有の同期設計が必要です。カットオーバー中に即興で行わないでください。
DNS決定ログを保持する
TTLはDNS応答がキャッシュされる期間を制御します。カットオーバー時にTTLを下げても、以前の値で既にキャッシュされた応答は無効になりません。そのため、TTL変更は事前に準備し、関連するネットワークから移行を観察します。Cloudflareは、ローカルキャッシュが可視的な変更を遅らせる可能性があることも指摘しています。 Cloudflare DNS TTLドキュメント.
レコード名とタイプ、古い値、意図した値、以前のTTL、承認、変更時刻、観察された結果をログに記録します。IPv4レコードとIPv6レコードの両方が存在する場合は、両方を確認します。無関係なメールレコードを保持します。変更後、公開ホスト名が意図したIPアドレスだけでなく、意図したアプリケーションとその重要なワークフローに到達することを検証します。
ロールバックをデータの決定にする
具体的な停止条件に合意します。最終的な問い合わせが欠落している、添付ファイルが開けない、サインインが失敗する、Webhookが誤った受信者に到達するなどです。新しい書き込みが始まる前は、保持されたソースへのリハーサル済みの復帰が可能かもしれません。移行先が新しい問い合わせを受け入れた後は、古いバックアップの復元やDNSの逆戻りだけではそれらのレコードを失う可能性があります。
再開後に停止条件が現れた場合は、書き込みを一時停止し、両方のコピーを保存し、権威あるシステムを選択する前に指名されたオペレーターに変更を調整させます。クライアント承認者が復旧を続けるか、合意された代替手段を使用するかを決定します。DNSを繰り返し切り替えるのではなく、短いインシデントログを保持します。
証拠と所有権で移行を閉じる
クライアントに受け入れグリッドをレビューしてもらいます。1つのアクティブなスケジューラ、新しいバックアップパス、アラートの所有権、次の観察チェックポイントを確認します。合意された期間ソースを保持し、その後明示的にその廃止を承認します。プロジェクト契約に従って一時的なアクセスとテストデータを削除します。
結果を使用して 運用責任シート と プロジェクト予算を更新します。この手順はチームの作業を整理するものであり、移行支援や中断のないサービスが含まれることを意味するものではありません。
出典とレビュー
技術参照は12年2026月に確認しました。例は計画上の演習であり、参照されたソフトウェア文書はPrivateHostLabのサービス機能を立証するものではありません。