ITインシデントのコンテキストを理解すると、MTTRが大幅に削減され、根本原因を特定する機能が強化されます。 IT環境では、「コンテキスト」は、インシデントまたはイベントのトラブルシューティングと診断に必要な情報のサブセットを指すために使用されます。 シナリオによっては、高可用性ファイアウォールのペアがオフラインになった後のダウンストリームの依存関係である場合もあれば、複数のVMから競合しているデータストアである場合もあります。 それでも、コンテキストは、インシデントが発生したときに関連するスコープを理解するために必要な一連の重要な情報です。
実用的なコンテキストを実現するために必要なコア機能のXNUMXつは、重要なリソースの動的トポロジマッピングです。 正確で動的なトポロジマップを使用すると、ITOpsは重大な問題を一目で診断およびトラブルシューティングできます。 問題が発生した場合、CLIで時間を費やし、TraceRouteを利用すると、トラブルシューティングプロセスが遅くなるだけであり、エンドユーザーの不満につながる可能性があります。
減算的アプローチ
トポロジマップを使用してコンテキストを確立する場合、加法混色と減法混色のXNUMXつの基本的なアプローチがあります。 サブトラクティブの原則に基づいて構築されたトポロジマップでは、ユーザーは、探しているものが見つかるまで、リソースのスタック全体をナビゲートする必要があります。 サブトラクティブモデルでは、トポロジマップで問題のあるリソースを特定することは、インシデント自体のトラブルシューティングと同じくらい面倒な場合があります。 サブトラクティブアプローチでは、ユーザーは提供される膨大な量の情報に気が遠くなり、トラブルシューティングの取り組みをどこに集中させるべきかについて混乱することがよくあります。 これは、ITインフラストラクチャが数千のリソースにまたがる可能性がある大規模なIT環境ではさらに当てはまります。 トポロジへのサブトラクティブアプローチには、ネットワークの全体的な概要などの利点がありますが、トラブルシューティングプロセスが妨げられ、ユーザーインターフェイスに過度のノイズが発生することがよくあります。
相加的アプローチ
付加的なアプローチでは、ITインシデントまたはイベントを理解してトラブルシューティングするために必要な情報の最小のサブセットがユーザーに提供されます。 イベントが発生すると、多くの場合、ITOpsは監視プラットフォームからのアラートを介して通知されます。 アラートから、当面のコンテキストを理解し、関連情報のみを表示することで、無限のデバイスとリソースを分類する手間を軽減することで、トラブルシューティングの作業を合理化できます。 付加的なアプローチは意図的に限られた情報のセットのみを提供しますが、ユーザーはより大きなコンテキストを理解するためにさらに拡張することを選択できます。 ただし、多くの場合、どのリソースがXNUMX次およびXNUMX次の隣接リソースであるかを知るだけで、インシデントを理解して効率的に修正できます。 たとえば、メールサービスを提供するホストのパフォーマンスが低下している場合、コアスイッチで深刻なネットワーク遅延が発生していることが原因であることがすぐにわかると、ITOpsは迅速に対応し、エンドユーザーの不満を減らすことができます。
LogicMonitorは、動的で付加的なトポロジマッピングの追加を発表できることを誇りに思います。 ユーザーは、追加のレンズを通してインフラストラクチャを表示し、俊敏性を高めてインシデントやイベントのトラブルシューティングを行うことができるようになりました。 プラットフォームのほぼどこからでも、ユーザーは、発生した可能性のあるイベントやインシデントのトラブルシューティングに必要なコンテキストを含むトポロジマップを作成できます。 トポロジマップは、リソースのリアルタイムビューを提供し、サービス、パブリッククラウド、およびデータセンターインフラストラクチャ全体に広がります。 LogicMonitorは、さまざまな方法を利用して、CDP、LLDP、転送テーブル、さまざまなAPIなどのインフラストラクチャの動的マップを作成します。 詳細については、無料トライアルをリクエストしてください ここ、またはアカウントマネージャーと話し合ってください。
