重要な点は、SLA ステータスが SLA 内の保証条項に基づいて正確であることです。ほとんどのケースでは、すべてのサービス停止が SLA に影響を与えるとは限りません。SLA モデルを使用する際に遭遇する可能性がある最も一般的な問題の 1 つは、SLA の保証対象外の問題に対する記録停止時間の保証です。その理由は、正確なリアルタイム監視用に設計されたサービスは通常、SLA に対する考慮が十分になされていないことです。

あらゆる障害シナリオを包含するサービスを設計する場合、膨大なリソース監視機能セットを構築することになります。一方、SLA は、特定のタイプのサービス停止に焦点を合わる傾向があります。たとえば、クリティカルなアプリケーション サービスなどです。リアルタイム監視の場合、物理サーバの可用性、クリティカルなプロセス、システム リソース、ネットワーク接続、アプリケーションおよびネットワーク レスポンス時間を理解する必要が発生することがあります。正確なリアルタイム管理については、サービスで広範囲にわたる潜在的なリソース障害を考慮する必要があります。

アプリケーション サービスのサポートでは、サーバ チームに、物理サーバが標準営業時間中の 99.9 パーセント使用できると規定する SLA があります。サーバ チームは物理サーバに対して責任を負いますが、物理サーバ上で実行されるアプリケーションや、物理サーバへのアクセスを提供するネットワークに対しては責任を負いません。このため、サーバ チームに対する可用性の保証の場合、SLA はサーバ自体に障害がある場合のみ時間を記録しますが、アプリケーションの障害やサーバへアクセスできなくなるネットワーク障害については、時間を記録しません。

したがって、リアルタイム監視用のサービス設計は、SLA 用の固有リソースの障害を分離するように設計されたサービスとは異なる可能性が高くなります。前のシナリオのいくつかの側面を確認し、サービス設計がどのように異なるか検討しましょう。

まず、CA Spectrum で、物理サーバの可用性を監視する方法を検討してください。サーバとの接続が失われた場合、サーバは使用不可とみなすことができます。ただし SLA の観点から見た場合、接続が失われたというだけでは十分ではありません。SLA では、サーバ停止と、サーバへのアクセスが不能になるネットワーク停止を区別する必要があります。CA Spectrum では、可用性の保証により、サーバが赤の場合のみ、停止時間を記録する必要があり、サーバがグレーの場合、停止時間を記録する必要はありません。アプリケーション サービスがリアルタイム監視用に設計されている場合、この 2 種類の停止を区別するため、設計者がリソース監視コンポーネントを搭載した可能性は低くなります。

次に、サーバ障害とアプリケーションやプロセスの障害をどのように区別する必要があるかを検討します。サーバ チームは、サーバ自体の上で実行されている処理に責任を負いません。まず、監視対象のプロセス停止を、サーバに対してではなく、プロセス モデルに対して分離しなければならないでしょう。その他のシステム リソース関連の障害は、サーバ チームが責任を負うこともあれば、負わないこともあります。たとえば、CPU の高負荷はサーバ上のアプリケーションが原因である可能性が高く、ローカル ファイル システムの障害はサーバ チームの責任である可能性が高くなります。つまり、リアルタイム監視用のサービスの最初の設計者が、サービスを設計した際に、これらの区別を考慮したとは可能性は低いと言えます。

2 つのテクニックを使って、SLA が保証対象のサービスを正確に監視していることを確認できます。

最初のオプションは、SLA によって保証されるコンポーネントを明確に監視するサービスの並列セットをシンプルに作成することです。これらのサービスは、リアルタイム監視用に設計されたサービスに加えて作成されます。このようなサービスでは、小規模のリソース セットの監視が可能で、異なるサービス ポリシーを使用する可能性が高いため、アラームは生成されません。SLA 固有のサービスは保守期間も定義できますが、SLA で指定された営業時間外は非アクティブになります。これは、おそらく最も簡単なテクニックですが、スケーリングが必ずしも適切とは限りません。サーバ チームの SLA の例を検討します。アプリケーション チームとネットワークに SLA があると想定します。1 つの論理アプリケーション サービスの場合、サポートする 4 つのサービス階層を簡単に作成できます。1 つのはリアルタイム監視用、1 つはサーバ用、1 つはアプリケーション用、1 つはネットワーク用です。これらのサービスの実装と保守には非常に手間がかかります。

2 番目のオプション（代替テクニック）は、すべてのサービスがモジュール設計で構築されることを確認することです。リソース モニタを使用することで、サービスの監視機能の拡張が簡単にできます。これは、新しいリソースを追加する場合だけでなく SLA のサポートを追加する場合にも当てはまります。特定のリソース モニタに対して保証を関係付けることができるように、リソース モニタを使って、特定の障害を分離することができます。適切に設計された場合、複数の SLA に対して同じサービスを使用し、さらにリアルタイム監視に使用することができます。