ルール・セットの開発

インシデントのルールおよびルール・セットを作成する前の最初のステップは、組織のビジネス要求に応じていつインシデントが作成される必要があるかを戦略的に決定することです。考慮すべき重要な質問は次のとおりです。

1. 何のイベントでインシデントを作成する必要があるか。どのサービス中断がIT管理者により追跡され解決される必要があるか。
2. どの管理者が着信イベントまたはインシデントに対し通知される必要があるか。
3. イベントまたはインシデントが外部システム(ヘルプデスク・チケット・システムなど)へ転送されるか。

例5-1 ルール・セットの例

• ルール・セットは、ターゲット: グループ・ターゲットGに適用されます。

• ルール・セットのルール:

  1. 指定されたイベントでインシデントを作成するためのルール

  2. インシデント発生時に通知を送信するルール

  3. いくつかの条件に基づいてインシデントをエスカレーションするルール。たとえば、インシデントがオープンな時間の長さです。

例5-2 より詳細なルール・セットの例

• 製品グループGのルール・セット

  • ターゲット: 製品グループG

  • ルール1: すべてのターゲット停止イベントのインシデントを作成します。

  • ルール2: 重大度がクリティカルまたは警告の特定のデータベース、ホストおよびWebLogic Serverのメトリック・アラート・イベントのインシデントを作成します。

  • ルール3: すべての問題ジョブ・イベントのインシデントを作成します。

  • ルール4: すべてのクリティカル・インシデントについてページを送信します。すべての警告インシデントについて電子メールを送信します。

  • ルール5: 致命的インシデントが12時間を超えてオープンされている場合は、エスカレーション・レベルを1に設定し、マネージャに電子メールを送信します。

正確にビジネス要件が理解されたら、それをエンタープライズ・ルール・セットに変換します。次のガイドラインに従うと、システム・リソースを効率的に使用し、効率よく運用できます。

• ターゲット(ホストやデータベースなど)を操作するルール・セットの場合は、グループを使用してターゲットをルール・セットのより少ない数のモニタリング・エンティティに統合します。グループは、インシデント管理および応答を含む、同様のモニタリング要件を持つターゲットで構成される必要があります。

• 同じターゲットのグループに適用されるすべてのルールは、1つのルール・セットに統合される必要があります。同じターゲットのグループに適用されるすべてのルールは、1つのルール・セットに統合される必要があります。1つのイベント・クラスに特有のイベントに対するルール、特定のイベント・クラスおよびターゲット・タイプのイベントに適用されるルール、またはそれらのターゲットのインシデントに適用されるルールを作成できます。

• ルール・セット内のルールの実行順序を活用します。ルール・セットとルール・セット内のルールは順次実行されます。そのため、ルールおよびルール・セットはその点に留意して順番を決めてください。

新規ルールを作成するとき、イベント、インシデントおよび問題のうち、どのオブジェクトにそのルールを適用するかを選択できます。次のルール使用のガイドラインは、どれを選択するかのガイドとして使用できます。

表5-7 ルール使用のガイドライン

ルール使用	適用
イベントに関するルール	Enterprise Managerで管理されているイベントのインシデントの作成。 イベントに関する通知の送信。 ヘルプデスクのアナリストによって管理されるインシデントのチケットを作成するには、イベントのインシデントを作成し、そのインシデントにチケットを作成します。 イベントをサード・パーティ管理システムに送信。
インシデントに関するルール	インシデント・ワークフロー操作の管理(所有者の割当て、優先度の設定、エスカレーション・レベル)を自動化し、通知を送信 インシデント条件に基づくチケットの作成。たとえば、インシデントがレベル2にエスカレートされた場合にチケットを作成します。
問題に関するルール	問題ワークフロー操作の管理(所有者の割当て、優先度の設定、エスカレーション・レベル)を自動化し、通知を送信

ルール・セットの例

次の例は、説明した実装ガイドラインの多くを示しています。すべてのターゲットは単一のグループに統合され、グループ・メンバーに適用されるすべてのルールは同じルール・セットに属し、ルールの実行順序が設定されています。この例では、次のようなターゲットから構成されるグループ(製品グループG)にルール・セットを適用します。

• DB1 (データベース)

• Host1 (ホスト)

• WLS1 (WebLogic Server)

ルール・セット内のすべてのルールは、インシデント作成、通知およびエスカレーションの3種類のアクションを実行します。

ルール・セットのより詳細なビューでは、ガイドラインにどのように従ったかを確認できます。

この詳細ビューでは、すべてのグループ・メンバーに適用される5つのルールがあります。ルールの実行順序(ルール1からルール5)は、ルール・セット内の3種類のルール・アクション(ルール1から3)に対応します。

• ルール1-3: インシデントの作成

• ルール4: 通知

• ルール5: エスカレーション

ルールの実行順序をルール・アクション・カテゴリの進行状況と同期することで、実行効率が達成されます。この例に示すように、同じイベントのセットに対し重大度に基づき異なるアクションをとる条件付きアクションを使用することで、今後、複数のルールを変更する必要なく、イベント選択条件を変更することが容易になります。ノート: これは、すべてのインシデント(ルール1から3)のアクション要件が同じであることを前提としています。

次の表は、この例における明示的なルール・セット操作を示しています。すべてのターゲットは製品グループGにあります。

表5-8 製品グループGのためのルール・セットの例

ルール名	実行順序	基準	トリガー条件	アクション
ルール1	1番目	DB1の停止 Host1の停止 WLS1の停止	該当なし	インシデントを作成します。
ルール2	2番目	DB1 表領域フル(%) ノート: 警告およびクリティカルのしきい値は、ルールUIではなく、メトリックおよびポリシー設定で定義されます。 Host1 CPU使用率(%) WLS1 ヒープ使用量(%)	重大度=警告の場合 重大度=クリティカルの場合	インシデントを作成します。
ルール3	3番目	DB1、Host1およびWLS1での、問題ジョブのステータス変更イベントの生成	該当なし	インシデントを作成します。
ルール4	4番目	製品グループGのすべてのインシデント	重大度=警告 重大度=クリティカル	電子メールを送信します。 ページを送信します。
ルール5	5番目	12日を超えてインシデントがオープンのまま残存	ステータス=致命的	エスカレーション・レベルを「1」にアップします。