いよいよ実作業--具体的な計画を立てるために覚えておきたいポイント - (page 3)

細川涼子 (Dell Technologies)

2020-01-28 07:15

 そんな時間はない、完了まで1年だ……という場合、移転先の環境や移転のタイミングはかなり狭まるでしょう。システムの停止がしにくい場合はトップダウンでの調整が必要になるかもしれません。

 システムの更改タイミングにあわせて移行するのであれば、より長い期間がかかります。しかし、そうであっても、データセンターを重複利用する期間は減らしたいですね。

 システムに対して更改時期の前倒しを依頼する、また現在のデータセンターのラックを、移転が終わった部分について順々に解約していけないか検討するのも必要です。

 また、「新データセンターへの移転はせず、クラウド移行する/システム廃止する」としていたシステムが「やっぱり、更改が間に合わないのでとりあえず移転したいんだけど……」という要望もよく見受けられます。それらのシステムを新データセンターに逃がしきるためにも、計画上の完了とデータセンターの解約の間には余裕を持たせましょう。

2.計画を家族=システムと共有しよう

 住宅の引っ越しであれば、実際の回数は1回か2回でしょう。しかし、データセンター移転は、システムを家族それぞれと考えると20~30人の大家族の引っ越しにあたります。各人それぞれの生活や事情、引っ越しのために休める日の制約があるなか、スムーズに引っ越しするにはどうしたらよいでしょうか。

 整理するのは「スケジュール」と「役割分担」です。そして、この二つをプロジェクトチームである程度仮決めして「移転計画書」として各システムに周知し、不都合があれば調整する、という進め方をするとスムーズです。

2.1スケジュール

 引越期間が長いほど、新居と旧居の平行稼働期間が長くなり、引越回数が多いほど搬送費用がかさみコスト増になります。なるべく移転するシステムを集約し、回数を減らし、早期に現在のデータセンターを明け渡せることが望ましいです。

 一方で「年末年始やお盆、ゴールデンウイークしか移転ができない」といったシステムがある場合、リハーサルや失敗時の再実施予定日を含めると計画が長期化する可能性があります。

 どのシステムをいつ移転させるか、という観点では、開発・検証環境から先に移転させ、稼働確認後に別日程で本番環境を移転させる、というのが一般的です。また、停止調整のしやすい、比較的小規模なシステムから移転をスタートさせてプロジェクト全体の移転スキルの習熟を図ることが多いです。

・なるべく搬送回数は少なく、引っ越しをまとめる
・開発系→本番系
・最初は小規模システムから

2.2役割分担

 各システムにとって、移転の準備でまず知りたいのは「いつ移転するのか(スケジュール)」とともに、「自分たちは何をすればよいのか」ということでしょう。移転プロジェクトチームとの「タスクの役割分担」と「コスト負担の役割分担」の線引きが明確になっている必要があります。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]