IDCの最近の調査 クラウド採用者の85％が複数のクラウドプラットフォームベンダーを使用しており、58％が少なくとも 4つの異なるクラウドサービスプロバイダー。マルチクラウドアーキテクチャの人気が高まるにつれ、DevOpsおよびIT Opsチームがハイブリッドの複数のクラウド間でサービスをマッピングする必要性が高まっています。
理由は簡単に理解できます。複数のクラウドプロバイダーにまたがるクラウドサービスに依存している場合、または異なるクラウドベンダーの同様のクラウドサービス（AWSS3やAzureStorageなど）を同時に利用している場合は、これらのクラウドサービスを追跡する必要があります。それらを効果的に使用および管理するため。
この記事では、マルチクラウドサービスマッピング戦略の構築がこの課題にどのように対処できるかを説明します。
この記事では、マルチクラウドサービスマッピング戦略の構築がこの課題にどのように対処できるかを説明します。
ITサービス管理チームは、インフラストラクチャ全体でインシデント、問題、および提案された変更の影響を追跡し、影響を受けるビジネスユニット内の利害関係者にこの情報を配布する必要があります。ビジネスユニットは、使用するアプリケーションの観点から話しますが、各アプリをサポートするITインフラストラクチャの詳細を知る必要はありません。
私は、詳細な技術情報をビジネスユニットに過剰に伝達している組織で働いていましたが、混乱を招きました。当たり前かもしれません ネットワーク技術者に ルーターASPHX02を交換すると、南西部のすべてのオフィスのExpressRouteの企業エンドポイントがオフラインになり、Office 365が利用できなくなりますが、平均的なクレームアナリストはこれを知る必要はありません（また、知る必要はありません）。
サービスマッピング ITインフラストラクチャリソースをアプリケーションにマッピングし、アプリケーションとITサービス間の依存関係をマッピングする機能を提供します。同じルーターを交換すると、サービスマップでダウンストリームに影響を受けるアプリがすぐに強調表示され、ビジネスユニットに影響について適切に通知できます。
クラウドが定着します。次は何ですか？
現代の企業では、ワークロードをクラウドベースのインフラストラクチャに拡張または移行する計画を立てる必要があります。 Alibaba Cloud、Microsoft Azure、プライベートVMware vCloud、またはその他のクラウドプラットフォームの組み合わせのいずれであっても、サービスを拡張してこれらのプロバイダーに移行するときは、追加されるすべての追加コンポーネントと依存関係を追跡するサービスマップが必要です。ミックス。 （この日を移動日と呼びます。）
2日目は、選択したクラウドプロバイダーに移動した後に発生します。移行が完了すると、クラウドへの移行に投資することを正当化するために、メリットとして販売されている機能を活用する必要があります。これらの利点の最大の1つは、ロードまたはスケジュールされたイベントに基づいてリソースを動的に追加および削除できることです。例としては、4月の第2週のIRSの追加容量要件（誰も早く税金を申告しないため）から、週末に最大のビジネスアプリケーションの1つのインスタンスを除くすべてをスピンする機能（誰もいないため）などがあります。オフィス）。
マルチクラウドアーキテクチャは、パブリッククラウドがもたらす複雑さを増します。これで、追跡する必要のあるより多くの施設にリソースがあり、これらのリソースタイプごとに各プラットフォームプロバイダーの固有の用語とメタデータのセットを処理する必要もあります。
マルチクラウドアーキテクチャのサービスマッピング
NS 単一の最大のアクション複数のクラウドプラットフォームに展開するときにインフラストラクチャチームが取ることができるのは、識別のために各リソースに割り当てることができる一貫したラベルのセットを作成することです。巨大な正式な分類法を設定する必要はありません。コンポーネントの名前を識別するためのラベルを追加するのと同じくらい簡単です。
多くの場合、組織は複数のラベルを標準化し、それらを展開スクリプトに含めて、常にデータが入力されるようにします。これらのラベルは、サービスマッピングアクティビティでの識別だけでなく、インシデントのトラブルシューティングにも役立ちます。私が個人的に見たラベルは一貫して使用されています 名前、によって作成された、 と作成日。よく使用される他のラベルには、 コストセンター、 プロジェクトID、 領域、 と 最終変更日。
すべてのリソースにラベルを付け、チームが自動検出機能を備えた製品を使用する場合、サービスマッピングは、（個々のITリソースを検索、タグ付け、マッピングするのではなく）ビジネスユニットにとって意味のあるサービス間の依存関係をマッピングする価値の高いアクティビティになります。 。 （特にレガシー環境で）すべてのリソースをキャプチャするための最初の作業は引き続き必要ですが、サービスマッピングの動的な部分を維持することは、使用する場合にはるかに合理的です。最新のサービスマッピングおよびディスカバリー製品.
結論
ITインフラストラクチャがクラウドプラットフォームに拡張されると、適切なサービス管理戦略がなければ、メンテナンスがロジスティックの悪夢になる可能性があります。これには、複数のクラウドにまたがってサービスをマッピングする機能が含まれ、適切なツールのセットが必要です。最終的に、ITリソースを追跡するための適切なツールがない場合の変更管理とリリース管理に関する調整には、ビジネスの前進に役立つはるかに価値のあるタスクに自由に集中できる上級技術者による信じられないほどの量のベビーシッターが必要になります。
クラウドプラットフォームの目標と夢は、ITサービス提供チームが、ビジネスニーズの変化に応じて、より迅速に、より機敏に価値を提供できるようにすることです。ハイブリッドインフラストラクチャのマルチクラウドサービスマッピングは、新しくより機敏なITパラダイムを実行可能にするための鍵です。
もっと詳しく知る：
- OpsRampの方法をご覧ください 統合サービスディスカバリ 視覚的なワークフローを使用して、サービスの相互依存関係を理解するのに役立ちます。
- 私たちを読む サービス中心のAIOpsホワイトペーパー.
- カスタムデモンストレーションをスケジュールする今日はソリューションコンサルタントと一緒に。
