＃3：移行に際し、SLAを締結しておく
SLA（サービス品質保証契約）はクラウドプロバイダーとの良好な関係を維持するという観点から綿密に交渉されることが多いものの、クラウドへの展開における重要なフェーズ、すなわち移行時のサービス品質が見過ごされることもしばしばある。たいていの場合、迅速なレスポンスが求められ、重要あるいは複雑なインフラをクラウドに移行する際にはレスポンスの質もそれなりのものが求められるはずだ。このため、移行時におけるサービス品質の強化を求め、契約に組み込んでおくべきだろう。窓口担当者や、合意に達したレスポンスタイムを把握しておくことで、スケジュールと予算を守ったうえで本番を迎えられるようになるはずだ。
＃4：夜間に障害が発生した場合の対応策を決定しておく
どれだけ優秀なサービスプロバイダーであっても、不慮のサービス停止という状況を避けることはできない。しかしこういったサービス停止は、クラウドを採用している場合に特に大きな問題となる可能性がある。社内のインフラに障害が発生した場合、問題を解決するために走り回っているIT部門の担当者の姿を目にすることができるものの、クラウドプロバイダー側で障害が発生した場合、IT部門の担当者はプロバイダー側での問題解決を待つしか手がないため、マネジメントは無力感を覚えることになるかもしれない。障害というものはいつか必ず発生するため、ただ待つのではなく、サービスごとに停止時間に応じた対応計画を立案しておくべきだろう。例えば、使用頻度の高いアプリケーションが一時停止するという事態に備えるのであれば、何らかの通知システムをテストのうえで導入し、ユーザーに対して状況を伝達する手段を用意しておくべきだろう。
また、最悪のケースに備えるのであれば、社内システムを暫定的に再稼働させる計画や、データを記録しておき、クラウドプロバイダーに後日送信して処理させる計画を立案しておこう。極めて重要度の高いサービスに対しては、プロバイダーと協力してこういった計画を検証しておくことで、適切な順序で対処できるのか、連絡経路が決定されているか、あるいはコミュニケーションシステムが正しく配備できているのかといったことを確認しておくのがよいだろう。移行完了後にプロバイダー側で障害が起こった場合、プロバイダーのデータセンター内に設置されているサーバには手出しすることができないかもしれないが、しっかり策定されたテスト済みの計画があれば、ただ肩をすくめて「電話の前で復旧を祈る」しかない状態よりも落ち着いていられるはずだ。
