クラウド移行のメリットを定量化および認定する方法

エンタープライズビジネスの未来はクラウドにあるというのは、当然の結論です。これは、過去数年間にクラウド移行がエンタープライズスペース内で果たした大きな役割を考えると特に当てはまります。

クラウドコンピューティングへの支出は、2009年以降IT支出の4.5倍の割合で増加しており、2020年までにその6倍以上の割合で増加すると予想されています。

Forbesクラウドコンピューティングのまとめ

これは、オラクルの最新データによって裏付けられています。オラクルの2019年の第2の予測では、「ミッションクリティカル」と見なされるものを含め、すべてのエンタープライズワークロードの80％が今後12か月でクラウドに移行する予定です。

企業全体でクラウドがほぼ普及しているにもかかわらず（そしてIT専門家や一般の人々がクラウドテクノロジーに精通しているにもかかわらず）、ワークフローをクラウドに移行するのは簡単なことではありません。これは、期待を管理し、移行が完了したときに、コストやパフォーマンスに関係なく、実際に改善を提供する場合に特に当てはまります。

チームが守れない約束をしていないことを確認するには、クラウド移行のすべての段階で可視性が必要です。結局のところ、「測定できないものを管理することはできません。 」という古いマントラがあります。そのため、ITチームは、正確な期待を設定し、ベンチャー全体を狂わせる前に問題を先取りするために、移行のすべての段階で可視性を持たなければなりません。

許容可能なパフォーマンス目標の定義

まず、チームは、どのアプリケーション、ネットワークインフラストラクチャ、またはプロセスが最も頻繁に故障するかを完全に理解する必要があります。 IT部門は、組織全体で情報を入手し、賛同を得るために、部門の枠を超えて面接する必要があります。

ITが一般性の観点から考えている場合、クラウド移行の主張は簡単かもしれません。確かに、ネットワークハードウェアのメンテナンスをオフロードすることは、予算を重視する意思決定者にとって魅力的に見えますが、ビジネスがそれらの節約を実現するには、どれだけの先行投資が必要ですか？

コストだけでは、すべての意思決定者を惹きつけるのにも十分ではないかもしれません。クラウドの移行により、ビジネスクリティカルと見なされるいくつかのアプリのパフォーマンスが向上する場合、他の場所で使用されるツールが犠牲になりますか？アプリのパフォーマンスは、移行全体を通じて、またどのくらいの期間影響を受けますか？ユーザーに必要な新しいトレーニングはありますか？

チームは、移行の提案をエグゼクティブチームに提出する前に、これらすべての質問を把握する必要があります。これには、IT部門がネットワークの現在の状態を真剣に検討して、既存のパフォーマンスのベースラインを作成する必要があります。このようにして、チームは、改善が最も必要な場所に関する意思決定者の意見を確認または通知し、ソリューションをクラウドのコンテキストに置くことができます。

移行前のパフォーマンスのベースライン化

エンドユーザーエクスペリエンスは、このベースラインがすべて始まるところです。結局のところ、クラウドの移行後に従業員のエンドユーザーエクスペリエンスが改善されない場合、または実際には著しく悪化する場合、ITは成功しません。ユーザーエクスペリエンスの低下は大企業の業績にドミノ効果をもたらす可能性があるため、収益のみに焦点を当てている意思決定者でさえ同意します。したがって、ITは、アーキテクチャが根こそぎにされる前に、ネットワークの「現在の状態」に（ユーザーの満足度とともに）焦点を合わせる必要があります。

アプリケーションの場合、これには、配信パス全体にわたる明確な可視性とともに、ユーザーが作業場所で実際に体験していることをITローカルの視点で把握できる合成Webテストが必要です。この情報があれば、IT部門はおよび後に満たす必要のある「受け入れ基準」を確立できます。 ユーザーが満足し続けることを保証するためのクラウド移行。いくつかのサンプル基準は次のようになります：

• 応答時間は、移行前のレベルの5％以内である必要があります
• サービスエラー率は、移行前のレベル以下である必要があります
• アプリケーションの可用性は、移行前のレベル以下である必要があります
• インフラストラクチャのコストは、移行の過程で少なくともX％削減する必要があります

したがって、チームは、アプリが現在ユーザーに配信されている速度、サーバー間の遅延（内部と外部の両方、DNSなど）、エラー率、エラーの種類、およびブラウザー固有のパフォーマンスの問題についてパルスチェックを行う必要があります。このすべてのデータがなければ、IT部門はネットワークの移行前の状態に頭を悩ませることができます。

移行中も監視を継続する

チームがベースラインを設定したら、移行プロセス全体を通じて受け入れ基準を監視し続けることが重要です。チームは、ネットワークが基準を満たしていない場合にフラグを立てることができるダッシュボードとアラートを作成できる必要があります。理想的には、ソリューションを監視していない場合でも、ベースラインパフォーマンスを参照したものと同じメトリックを使用します。

• 稼働時間- クラウドアプリケーションの場合、IT部門は、特定の週のダウンタイムが数分に制限されることを期待する必要があります。ほとんどの公開アプリは99.9％以上を目指しています（どの営業週でも最大7分）。
• DNS -現在クラウドにあるアプリの場合、ITはIPアドレスを提供するローカルDNSサーバーまたはパブリックDNSサービスを持っている可能性があります。これは、特定の場所にいるすべてのユーザーの接続を妨げるため、積極的に監視する必要があります。
• レイテンシ、RTT -サービスがデータセンターの外またはオフィスの外にあるため、トラフィックがクライアントからサーバーに移動するのにかかる時間に意味のある違いが生じる可能性があります。ここでのスパイクは、LAN、ISP、またはアプリの問題に関連している可能性があります。
• 容量 -ISPからの帯域幅の支払いは1つのことですが、ユーザーの場所とアプリサーバー間のネットワークのエンドツーエンドの容量には、異なるボトルネックが存在する可能性があります。この測定により、IT部門は輻輳が接続速度に影響を与える時期を特定できます。

スパイクとジャンプは、移行に関連するバグの有用な指標であり、問​​題が急増する前に問題を阻止するために、新しいビジネス要求の前であっても、すぐに対処する必要があります。問題を解決することで、IT部門は問題に直接目を向け、チームは最も適切なソリューションを実装する可能性が高くなります。

モニタリングを活用して成功を認定する

新しいネットワークアーキテクチャが導入されたら、移行前にチームが実施したベースラインを比較のためにやり直す必要があります。ここで重要なのは、古いネットワークでテストされたものと同じプロセス（使用法、パターン、時間など）を使用することです。

すべてのクラウド移行で、ある程度の制御が失われます。それがベアメタル、OS、またはアクセスレベルのいずれであっても、チームが新しいクラウドサポートネットワークに同じレベルの可視性を提供できる最新の監視ソリューションを使用していることも重要です。インフラストラクチャがITによって所有されなくなった場合、古い監視ツールの可視性のレベルが損なわれます。多くの監視ソリューションでは、クラウド環境やITファイアウォールの外側でさえ可視性を提供できないため、これは非常に重要です。

ファイアウォールを超えた洞察がなければ、IT部門がISPまたはサードパーティのインフラストラクチャに起因する問題を特定して迅速に解決することは困難です。これにより、移行の進行中に移行が遅れる可能性があります。また、パフォーマンスが継続的に妨げられている場合、IT以外のユーザーはクラウド前の数日間懐かしくなります。