システム移行がうまくいったとしても，それだけで仮想化導入のプロジェクトが終わるわけではない。この期に及んで持ち上がるトラブルとして多いのは，「仮想環境に移行した古いアプリケーションのテストを，誰が受け持つか？」という点が曖昧になっていることだ。
落とし穴８
移行後のテストを誰もできない
ユーザー企業としては，「システムを新しい環境に移行するだけだから，テストはベンダーがやってくれるはず」と思う。一方のシステム・インテグレータは，「業務のことは分からないから，当然ユーザー側で実施するはず」と考える（図1）。通常のシステム開発でも耳にする話ではあるが，特に仮想化の導入事例では，テストに関する認識のズレが起こりやすい。これを曖昧にしたままテスト・フェーズを迎えると，トラブルに発展しかねない。
 |
| 図1●計画段階からテストに対する認識がズレやすい [画像のクリックで拡大表示] |
一番やっかいなケースは，誰も移行後のシステムをテストできない場合だ。古いアプリケーションの移行に成功したとしても，それがブラックボックス化したものだと，ユーザー自身ですらテストを実施できない。これでは，仮想化したシステムが正しく動作しているか確認できず，本当に成功したかどうか分からない。
仮想化技術の成熟に伴い，たとえ古いシステムでも，仮想環境に移行させるだけなら成功率が高くなった。ただ，落とし穴２でも述べた通り，そもそも「移行すること自体に無理があるほど古いシステム」を延命すべきかどうか，テストの観点からも是非を検討しておく必要がある。この点を事前に明確にすることは，仮想化の導入計画が妥当なのかを再認識する上で重要なポイントになる。
落とし穴９
既存システムのバックアップができない
運用段階まで来たら，もう難題はないだろうと考えるのは早計である。運用管理やバックアップの面で問題が発生しやすい。
既存システムを仮想環境に移行する案件で，とりわけ忘れてはならないのが，システムのバックアップ方法だ。既存システムは運用まで含めて安定しているため，日々のバックアップ作業を改めて検討することなく，仮想環境に移行してしまうケースがよくある。
問題は，主な仮想化ソフトでは，既存システムで使ってきたデバイスを利用できないことが多いこと。例えば，テープ装置などが挙げられる。
このため，既存システムでは毎日のように自動実行していたオンライン・バックアップも，仮想環境では実行できなくなる。対処策としては，システムを停止してバックアップする方針に切り替えるか，全く別の方法を考える必要がある。
当然のことながら，こういったことを仮想環境への移行が済んでから考えるようでは遅すぎる。仮想化の計画段階でしっかり検討しておくべきだ。
落とし穴１０
要員がスキルアップしないと運用管理は楽にならない
仮想化の代表的なメリットとして，よく「システムの運用管理が楽になる」と言われるが，誤解を受けやすいところでもある。
確かに「分散，混在していたシステムを集約し，統一された仮想環境管理ツールを使って運用管理する」という意味では仮想化のメリットが得られる。だが，一方で忘れてはいけないのは，「移行前の環境とは，確実に違う管理手法やスキルが必要になる」という変化が訪れることだ。
システムを統合した仮想環境を想像してみよう。ハードウエアや仮想化ソフトに何らかのトラブルが発生したら，最悪の場合，システムが全面ダウンすることもあり得る。また，仮想化ソフトのレイヤーがある分だけ，トラブルの原因を特定するのに時間がかかることもあるだろう。
これもまた，当たり前のことだと思われるかもしれない。しかし実際，多くのケースでは前述してきたように「仮想化を導入しさえすれば万事OK」と思われがちなのが実情だ。
仮にシステムを延命させるための仮想化が目的なのだとしても，あくまでも仮想環境は「全く新しい環境」なのだと，今一度，改めて認識してほしい。運用担当者のトレーニングをはじめ，さまざまな準備を計画段階から進めておくことが肝心である。ここまで含めた戦略的なプランニングこそが，仮想化導入を成功に導き，そのメリットを最大にしてくれる。
|
