環境内のすべてのITリソースは、組織の内部および外部ユーザーにサービスを提供するITサービスに参加しています。 ITサービスは、アプリケーション(注文管理アプリケーションなど)またはインフラストラクチャサービス(オフィスビルのWi-Fiなど)の場合があります。

データセンターで実行されているアプリケーションについて考えてみます。発生する可能性のあるシナリオは次のとおりです。

  • そのアプリケーションのユーザーは、アプリケーションが機能を停止すると中断を経験します。
  • アプリケーションが実行されているサーバーがシャットダウンすると、アプリケーションはダウンします。
  • サーバーを接続するネットワークスイッチが期待どおりに機能しない場合、サーバーは事実上利用できなくなります。

ITサービスのユーザーエクスペリエンスはさまざまなITリソースに依存し、それぞれが特定のインフラストラクチャまたはサービスレイヤーに影響を与える可能性があります。日常業務では、ITリソースとユーザーへの影響を明確に把握することが重要です。

Y次の質問に答えられる必要がありますto運用タスクに効果的に優先順位を付けて計画します。 

  • ITサービスをサポートするすべてのワークロードが稼働していますか?
  • メンテナンスのためにこれらのサーバーを再起動すると、どのユーザーが影響を受けますか?
  • このサービスのユーザーは先月、ダウンタイムを経験しましたか?

ITサービスの可視性 データセンターとクラウド環境全体にワークロードを分散している場合は、さらに重要になります。では、ミッションクリティカルなITサービスの可用性とパフォーマンスをどのように管理しますか?

サービスマップを入力してください

OpsRampのサービスマップは、ITリソースを階層構造に編成して、ユーザーへの影響をより迅速に分析するのに役立ちます。図1は、ITサービスのサービスマップを示しています。 ウェブアプリケーション、アプリケーションサーバー、データベースサーバー、およびロードバランサーを使用します。タイトルのノード 「私のアプリケーションのユーザー」 サービスのユーザーを表します。

アプリケーションサーバー、データベースサーバー、またはロードバランサーが使用できなくなると、ITサービスは機能しなくなります。サービスマップを使用すると、ノードとそのさまざまなコンポーネントが相互リンクする方法のルールを設定できます。サービスマップを使用して、確立したルールに基づいてサービスの影響を自動的に追跡できます。図1では、 「私のアプリケーションのユーザー」 1つ以上のアプリケーションサーバーがダウンしているため、劣化が発生しています。

Track IT Service Impact

図1-見通し内のユーザーに対するITサービスの影響の追跡

サービスマップデザインパターン

サービスマップの設計は、環境内のITサービスのタイプと、ユーザーへの影響を追跡する粒度に基づいて行います。サービスマップの3つの一般的なデザインパターンを見てみましょう。

デザインパターン#1:特定のITサービスのユーザー

このデザインパターンでは、特定のITサービスに対するユーザーの影響を追跡する必要があります。 ITサービスは、図2に示すように、3つのコンポーネントを備えたWebアプリケーションです。

  • サービスへのエントリポイントとして機能するロードバランサー(https://myapp.弊社.com)
  • アプリケーションサーバー
  • データベースサーバー

このITサービスに関心のあるいくつかの質問は次のとおりです。

  • ユーザーはこのサービスを利用できますか?
  • サービスがダウンした場合、どのコンポーネントが問題を引き起こしていますか?
  • 先月、ユーザーがサービスを利用できた時間の割合はどれくらいですか?
  • サービスのダウンタイムのどのくらいが、その各コンポーネントに依存しますか?
A Simple IT Service That Serves A Specific Set of Users
図2-特定のユーザーセットにサービスを提供するシンプルなITサービス

これらの質問に答えるには、次のようにサービスマップを作成します。 Figure 1。ラベルの付いたノード 「私のアプリケーションのユーザー」 はサービスのすべてのユーザーを表し、残りのノードはそれぞれ異なるアプリケーションコンポーネントを表します。「私のアプリケーションのユーザー」 3つのコンポーネントのいずれかが使用できなくなると、劣化が発生します。

デザインパターン#2:2つの関連するITサービスのユーザー

このデザインパターンでは、次のように、同じユーザーセットが同時に使用する2つのITサービスを検討します。Figure 3。各サービスは、最初のデザインパターンのアプリケーションと同じように、Webアプリケーションです。 

相互に関連するITサービスに関するいくつかの質問を次に示します。

  • ユーザーは両方のサービスを利用できますか?
  • 先月、ユーザーが両方のサービスを利用できた時間の割合はどれくらいですか?
  • 先月、ユーザーに最も影響を与えたサービスはどれですか?

これらの質問に答えるには、ユーザーを次の階層に編成します。

  • すべてのユーザー(アプリケーションAまたはB、あるいはその両方のユーザー)
  • アプリケーションAのユーザー
  • アプリケーションBのユーザー
Two Different IT Services With The Same Set of Users
図3-同じユーザーセットをサポートする2つの異なるITサービス

サービスマップは、次のようにユーザーのこの階層グループを反映しています。 図4。定義 。定義 誰が影響を見るか 誰が影響を見るか また 「アプリケーションBのユーザー」 影響を受ける。このデザインパターンを使用すると、必要な場合にのみ、いずれかのサービスに対するユーザーの影響に関する情報を自動的に表示し、特定のサービスに関する追加の詳細を検討できます。このような影響情報の自動視覚化は、相互に関連する多数のサービスを管理する場合に特に役立ちます。 

Visualize User Impact For Interrelated IT Services

図4-相互に関連するITサービスのユーザーへの影響とパフォーマンスを視覚化する 

 

デザインパターン#3:特定の場所にまたがるITサービスのユーザー

オフィスビルにWi-Fi接続を提供するITサービスを考えてみましょう。 Wi-Fi接続サービスには、次のように、建物の3つのフロアにWi-Fiアクセスポイントがあります。図5.

このITサービスに関心のあるいくつかの質問は次のとおりです。

  • 各フロアのユーザーはWi-Fiサービスを利用できますか?
  • 先月、各フロアのユーザーがWi-Fiサービスを利用できる時間は何パーセントでしたか?
Supports Users Across Several Locations
図5-複数の場所にまたがるユーザーをサポートするITサービス

これらの質問に答えるには、各フロアのWi-Fiユーザーを表すノードを定義します。単一のノードは、次のように、建物の3つのフロアにまたがるすべてのWi-Fiユーザーを表します。 Figure 6。これらの各サービスは、そのフロアのアクセスポイントに依存しています。 Wi-Fiサービスが利用可能な場合、フロアに十分なカバレッジがあれば、最小限の数のアクセスポイントが稼働しています。

Visualize User Impact Across LocationsFigure 6 - Visualize User Impact Across Locations For A Single Service

Dimensions of Impact

サービスの可用性のコンテキストでユーザーへの影響について説明しましたが、その影響は、次のようなITサービスの健全性のさまざまな指標にも当てはまります。

  • サービスパフォーマンス:サービスのユーザーは良好な応答時間を受け取っていますか?
  • サービス容量:サービスの予測される需要をサポートするのに十分な容量がありますか?
  • サービスコンプライアンス:サービスに参加しているリソースは、組織の慣行に準拠していますか?

サービスマップのコンテキストでは、ITリソースがユーザーに与える影響について説明しました。影響にはもう1つの重要な側面があります。それは、ITリソースが相互に与える影響です。マイクロサービスをサポートするコンテナーを実行しているサーバーに障害が発生すると、そのサーバーで実行されているすべてのコンテナーが機能しなくなる可能性があります。サービスマップは、これらの影響の側面をモデル化するのに役立ちます。これについては、今後のブログで詳しく説明します。

次のステップ:

Unified Service Discovery


Recommended posts