CI に対してアクティブな変更要求がスケジュールされている場合、または CI の [インストールステータス] が [メンテナンス中] の場合、影響を受ける CI のすべてのアラートがインパクトカリキュレーションから除外されます。また、[アラート] タブでは、対応するすべてのアラートが一時的に非表示になります。影響度ツリーには、(メンテナンス中) というメモとともに CI が緑色で表示されます。影響度ツリーとサービスマップには、一時的に CI が緑色で表示されます。

サービスの場合、サービスの CI ではすべてのアラートも [アラート] タブで非表示になります。サービス全体は影響度ツリーに緑色で表示されます。アクティブな変更要求があるホストの場合、ホストアプリケーションは 1 つのユニットと見なされます。すべての子アプリケーションは、変更要求がアクティブでなくなるまでホストと同じ方法で処理されます。 詳細については、「メンテナンス中の CI でのアラートの動作」を参照してください。

CI のアラートが生成されると、関連 CI に対して追加のインパクトカリキュレーションが実行されます。たとえば、実際にアプリケーションサービスに含まれていない CI に対するアプリケーションサービスの依存関係について、追加のインパクトカリキュレーションが実行されます。こうした関連 CI は、サービスの一部としては検出されません。代わりに、関連 CI はインフラストラクチャ関係定義によって指定されます。

クラスターごとに異なる影響度ルールを構成できるため、子 CI から親 (同じ子 CI に対する) への影響度伝達が異なります。したがって、CI のグループを手動で作成し (別名：手動クラスター)、クラスターの子に向かう下流に対するクラスターレベルで影響度ルールを構成できます。

上記の例では、エントリーポイントが 2 つあります。右側の Osaka クラスターには 3 つの CI があります。左側の Tokyo クラスターには 2 つの CI があります。Tokyo and Osaka バックアップサーバーは共有の親があります。Tokyo クラスターと Osaka クラスターです。右側のパネルには影響ツリーが表示され、Tokyo クラスターの 2 つのアプリケーションクラスターメンバーはそれぞれ影響度が 50% で、Osaka クラスターの 3 つのメンバーはそれぞれ 34% の影響度を持っています。

手動クラスター構成の場合、[アプリケーション影響] と [アプリケーションクラスタメンバー] の 2 つの行があります。[影響度 (Impact On)] フィールドで [アプリケーションサービス] ではなく [親] が選択されているため、子が表示されます。[アプリケーションクラスタメンバー] 行で [影響] フィールドが 2 に構成されています。これは、失敗する (および失敗を親に伝達する) 子の最小数が 2 つであることを意味します。Osaka クラスターでは 3 に構成されています。それぞれのクラスターでの Tokyo and Osaka バックアップサーバーの影響割合は異なります (50% と 34%)。ご覧のとおり、Tokyo and Osaka バックアップサーバーの障害は赤で重大ですが、親への影響は異なります。Tokyo クラスターの障害はオレンジ色で大になりますが、Osaka クラスターは緑色のままです。

サービスまたは CI をクリックすると、それに関連付けられているアラートが表示されます。たとえば、高レベルのアプリケーションサービスをクリックした場合、[アラート] を選択するとそれに関連付けられているアラートがマップビューの下にあるアラートエリアに表示されます。一覧表示されるのは、選択したサービスのアラートです。そうしたサービスを選択すると、子サービスのアラートが一覧表示されます。

[影響度] を選択すると、次の影響度フィールドが表示されます。