サーバーと移行先が列挙されていれば、移行案は完成して見えるかもしれません。より難しい問いは、そのサーバーが支える仕事にあります。スタッフは注文処理を続けられるか。定期エクスポートはいつ動くか。転送後の記録は誰が確認するか。クラウド移行計画では、インフラの判断をこれらの日常業務と結び付ける必要があります。以下の順序で、大きな移行をレビュー可能な作業へ落とし込みましょう。
このページの内容
運用上の改善を定義する
「クラウドへ移行する」を、評価できる理由に置き換えます。例えば、リリースが手動設定のサーバー一台に依存している、繁忙期に現在の構成では足りない容量が必要になる、といった理由です。将来の環境を定める前に、現在の動作を記録します。その基準がなければ、移行が元の問題を解決したのか、発生場所を変えただけなのか判断しにくくなります。
- 対象となる業務フローと責任者を明確にします。
- 再現可能なデプロイ手順など、観測できる改善を説明します。
- 移行時に守るべき制約を列挙します。
各ワークロードの周囲のつながりを整理する
アプリケーションごとに、データベース、ファイルストレージ、定期ジョブ、外部サービス、アクセス要件を列挙します。運用担当者に関係図を確認してもらいましょう。夜間レポートや取引先との接続は、サーバー一覧だけでは見落とされがちです。一緒に移行する必要がある依存関係と、段階的な移行中も現状を維持できる接続を区別します。
アプリケーションごとに移行方法を選ぶ
判断の例として、顧客ポータルがサポート対象の実行環境を使いながら、古い会計アプリケーションとデータベースを共有している状況を考えます。ポータルを先に移すことが妥当なのは、残るデータベース接続が合意したアクセス・性能要件を満たす場合に限られるかもしれません。そうでなければ、関連するワークロードを一緒に移すか、先に依存関係を解消します。そのアプリケーションのニーズに照らして、単純移行、限定的な変更、再開発を比較しましょう。すべてのシステムで同じ方法を使う必要はありません。
新しい環境の運用方法を設計する
アクセス、デプロイ、アラート、バックアップ、費用確認の責任者を決めます。閑散期とピークを含む利用状況から、需要を見積もります。保存量が増える場合やサービス間でデータを移動する場合に、見積もりがどう変わるかを確認しましょう。有用な費用の議論では、最初の試算を固定的な運用請求額とみなすのではなく、前提と公開後に監視する項目を説明します。
- 本番環境の設定は誰が変更できますか？
- ジョブが失敗した場合、誰が対応しますか？
- バックアップからの復元をどう検証しますか？
切り替え前にロールバックの判断を定める
例のポータルでは、新環境を公開する前に、ログイン、注文送信、レコード件数をどう検証するか合意します。どの失敗で移行を止めるのか、誰が判断するのかを定めます。切り替え後にユーザーが新規レコードを作成できるなら、通信を旧サーバーへ戻すだけでは不十分です。そのレコードを扱う計画も必要になります。ロールバックに追加のデータ作業が必要になる境界点も含め、手順を予行演習します。
運用確認をもって移行を完了する
移行後は、業務フロー、定期タスク、アラート、利用傾向を合意した基準と比較します。未解決の問題には責任者を割り当てます。旧環境を停止するのは、チームが移行確認を完了し、保持すべきデータや設定を決めてからです。今後サービスを保守する担当者が、アプリケーション関係図と復旧手順を参照できるようにしておきます。