インシデント・ルール・セットにおけるRCA結果の活用

前述のように、RCAは持続プロセスであり、新しいターゲットの停止イベントが受信されて処理される間に、ターゲットの停止イベントを原因、兆候またはいずれでもないとしてマークします。そのため、ターゲットの停止イベントは、受信されたときまたはその後RCAが追加のイベント情報を分析したときに、原因または兆候としてマークされる場合があります。

ターゲットの停止イベントはただちに解決する必要がある重要なイベントであるため、ほとんどのデータセンターでは、ターゲットの停止イベントのインシデントを自動的に作成します。これはお薦めのベスト・プラクティスであり、即時使用可能ルール・セットによって実装もされています。しかし、レスポンス・チームへの通知またはトラブル・チケットの作成に関しては、兆候インシデントの場合にそのようにすることは望ましくありません。一部のデータセンターでは、兆候イベントについてインシデントを作成しないことを選択する場合もあります。

そのため、RCAの結果は次のように活用できます。

1. 兆候以外のイベントについて通知またはチケットを作成します。

   これは2つの方法で実施できます。

   • 2つの別々のイベント・ルールを作成し、1つのイベント・ルールではすべての関連イベントのインシデントを作成するが、それ以上のアクションをとらない(通知やチケット作成は行わない)ようにし、もう1つのルールでは兆候以外のイベントのみについてインシデントを作成し、通知の送信およびチケットの作成を行うようにします。手順については、「兆候以外のイベントのインシデントの作成」を参照してください。

   • ターゲットの停止イベントのすべてについてインシデントを作成するイベント・ルールを作成します。インシデント優先度を更新する別のルールを作成し、兆候以外のイベントから発生したインシデントについてのみ通知の送信およびチケットの作成を行うようにします。インシデント優先度が「緊急」に設定されると、顧客は、緊急優先度のインシデントに対する追加アクションを実行する追加のインシデント・ルールを作成することもできます。「兆候以外のイベントのインシデント優先度を更新するルールの作成」を参照してください。

2. 最初に原因と兆候のどちらでもないとマークされなかったイベントを待機した後にのみ、インシデントを作成します。

   前述のように、RCAは、受信するターゲットの停止イベントが継続的に評価され、既存イベントの原因分析の状態が更新される反復プロセスです。最初に根本原因としてマークされたターゲットの停止イベントは、受信する他のターゲットの停止イベントに応じて、一定の時間(分)、根本原因のままである場合も根本原因ではなくなる場合もあります。元のターゲットの停止イベントが、後で兆候として分類されることがあります。

   後で兆候イベントという結果になる可能性のあるイベントに対して、時期尚早にインシデントを作成しチケットをオープンすることがないように、次のようにルールを設定できます。

   • 前述のステップですでに定義したルールに加えて、追加のイベント・ルールを作成し、イベントに対するRCAが更新され、イベントが兆候としてマークされてインシデントの優先度が「低」に下げられることがRCAの更新によって示されるときに機能するようにします。これによって、チケットに対する更新も自動的に送信されます。これがお薦めの方法です。手順については、「遅延時間の概要」を参照してください。

     または

   • ターゲットの停止イベントが報告、分析され、それについてのアクション(インシデントの作成やインシデントの更新など)が実行される時間を見越すために、ルール・アクションに遅延を追加できます。これは、顧客が最小遅延(通常は5分)の後にアクションを実行する許容差を持つ場合に便利です。

3. 兆候以外のイベントに対してのみインシデントを作成します。

   一部のデータセンターでは、兆候イベントについてインシデントを作成しないことを選択する場合があります。これは、原因としてマークされた、または原因と兆候のどちらでもないとマークされたイベントについてのみインシデントを作成するルールを変更することによって実施できます。手順については、「兆候以外のイベントのインシデントの作成」を参照してください。

   この方法でも、最初に原因としてまたは原因と兆候のどちらでもないとマークされていたイベントが、追加情報を受け取ったときに兆候としてマークされる場合もあることに注意してください。顧客は、ステップ2の2番目のオプションと類似した方法を使用して、インシデントの作成に遅延を作成することができます。この場合でも、事前設定の遅延後に新しい情報が現れ、イベントが結局兆候としてマークされることもありえます。そのため、インシデント優先度を使用し、ワークフローを管理する1つの方法としてそれを使用する方法の使用をお薦めします。