Event Management モジュールの開発設計書

検証環境：Brazil PDI / OOTB＋Event Management プラグイン＋AIOps Experience / 2026-10-14〜15 確認

本書は、監視ツールのイベントをアラートにまとめ、重大なものだけを担当グループ付きのインシデントにするまでの開発設計書です。架空のモデル案件を1つ置き、標準機能の設定（ルール・テンプレート・プロパティ・ロール）だけで要件を満たす設計を11件決めます。スクリプトは書きません。次の3点の扱いも決めます。

• 標準の自動起票ルールが無効のまま入っていること

• ルールの条件に Type を表示名で書くと一致0件になること

• 起票されるインシデントの影響度が、実行ごとに変わること

変更要求を受けたときは、第2章の対応表と付録Cから、変更対象・影響する権限・確かめる動作を引けます。

各設計は同じ10項目で書き、標準仕様の各行には根拠の種類を付けました。

関連する巻は次のとおりです。現在の設定値の一覧は「Event Management モジュールの設定」にあります。操作は「Event Management モジュールの運用手順書」に、運用の判断基準は「Event Management モジュールの運用設計書」にあります。

1. 目的・範囲・前提

この章で決めること：何の案件を想定した設計書で、どこまでが範囲で、設計書の記述をどう読むか。

想定する案件

この設計書のモデル案件は架空の設計例です。ネットショップ「EC サイト」の業務サービス「オンライン決済サービス」（重要度は最上位）を、既存の監視ツール（仮称 EC-Monitor）の警報から守ります。

• 構成は、ロードバランサー1（ec-lb-01）、Web 2（ec-web-01・ec-web-02）、AP 1（ec-app-01）、DB 1（ec-db-01）、MySQL インスタンス（ecpay-mysql）

• 決済と無関係な社内ファイルサーバー（hr-file-01）も同じ監視ツールの対象

• 監視ツールは REST（/api/global/em/jsonv2）でイベントを送る

• 運用当番（サービスデスク兼務）は24時間365日で常時2名、平日9〜18時は4名

• DB チーム（グループ Database）と Web/AP チームは平日9〜18時。夜間休日はオンコール1名（呼び出しから30分以内に着手）

• 監視設計担当（evt_mgmt_admin）は平日のみ1名

• サービス責任者は、P1 の第一報を受ける

• ライセンスは ITOM AIOps 相当を契約済みの想定。機械学習によるクラスタリング・Health Log Analytics・Now Assist は対象外

• メンテナンス時間帯は毎週日曜 2:00〜4:00

• 対象外は、Discovery と Service Mapping による CMDB の自動作成、監視ツール側の設定、ネットワーク機器の監視、ログ分析、インシデントの調査・解決の運用

次の値は架空です。自社の案件では、読み替えてください。

• 相関の時間窓（15分）

• 起票までの時間（受信から1分以内）と、Acknowledge までの時間（5分以内）

• 当番の人数・オンコールの着手時間（30分）・メンテナンス時間帯

• 業務サービス名・CI 名・担当グループ名・監視ツールの名称

PDI で確かめたのは、標準機能の設定でこの設計が実現できるかどうかまでです。当番の運用・承認の流れは PDI では実演していません。デモ環境の件数や実績から運用の基準は決めていません。

用語

本書では、次の語を1つの意味で使います。

• イベント：監視ツールから届く1回の通知（em_event）

• アラート：イベントから作られ、同じ障害の通知をまとめる単位（em_alert）

• 親アラート・子アラート：相関ルールでまとめたときの代表と、ぶら下がる側

• 相関ルール：アラートを親子にまとめるルール（em_alert_correlation_rule）

• アラート管理ルール：アラートに対してインシデント作成などを自動で行うルール（em_alert_management_rule）

• メッセージキー：同じ事象の通知を同じアラートに束ねる識別子（message_key）

• 当番：運用当番のサービスデスク担当者

• 監視設計担当：ルールとプロパティを設定する担当。evt_mgmt_admin を持つ1名

• 起票：アラートからインシデントを作成すること

• 開発環境／本番環境：モデル案件で使う2つの環境。PDI は、標準仕様を確かめた Brazil の Personal Developer Instance

• 自作ルール：筆者が検証のために作ったルール。名前が「デモ:」「PDI検証:」で始まる。標準の件数には含めない

設計項目の形式と表記

各設計は、次の10項目をこの順に書きます。該当する内容がない項目は「なし（理由：〜）」と書き、空欄にしません。

• 対象：設計が扱うテーブル・項目・レコード

• 目的：この設計で決めること

• 前提：設計を適用する前にそろっている条件

• 標準仕様：製品の標準の構成と挙動

• 設計内容：この案件で採用する決定

• 設計理由：その決定を採る理由

• 例外：決定が当てはまらない場合、制約、未決事項

• 完了条件：設計どおりに適用できたと判断する状態

• 確かめ方：試験の条件・合格基準・実施状態と、見直しの契機

• 記入例：モデル案件で設計を適用した後の期待値。付録Dにまとめます

標準仕様の各行の末尾には、根拠の種類を付けます。

• ［実測］：PDI で確かめた事実

• ［公式］：製品同梱の説明、または公式ドキュメントの記述

• ［未確認］：確かめていないこと

試験の状態は、PDI で条件どおりに実行して合格基準を満たしたものを［実施済み］、まだ実行していないものを［未実施］とします。

文体は次のとおりにそろえます。設計内容の文末は「する」「とする」、完了条件と合格基準の文末は「こと」、図表を書き起こした箇条書きは体言止め、それ以外の説明は「です・ます」です。

担当（監視設計担当）と関連資料（設定・運用手順書・運用設計書）は文書全体で共通とし、各設計に繰り返しません。試験の合否は監視設計担当が判定し、結果を作業記録に記入します。記入するのは、条件・日時・実施者・画像の保存先です。図と表の画像は、同じ内容を直後に箇条書きでも書き出しています。

要件・設計・試験・未決事項・設計判断には、名前とIDを付け、本文では名前で呼びます。

IDを使う場所は、見出し・項目名・第2章の対応表・第11章の一覧・変更票・付録Cだけです。接頭辞は次のとおりです。

• 要件：RQ

• 設計：DS

• 試験：TS

• 未決事項：OI

• 設計判断：DC

2. 要件と設計の対応

この章で決めること：どの要件を、どの設計で満たすか。要件と設計の対応は、この章の表だけに書きます。

要件

• RQ-01 親子へのまとめ：同じ障害から届く警報は、原因の CI のアラート1件に子としてまとめる。相関の時間窓は15分とする

• RQ-02 重大な親の1分以内の起票：業務サービスに影響する重大（Critical）な親アラートだけを、受信から1分以内に担当グループ付きのインシデントにする

• RQ-03 警告の日次確認：決済と無関係な警告（Warning・Minor の単独）はインシデントにせず、当番が Express List で日次に確認する

• RQ-04 回復通知での自動解決：監視ツールの回復通知（Clear）で、アラートと紐づくインシデントを自動で Resolved にする。人の操作を要さない

• RQ-05 5分以内の Acknowledge：当番は、優先度グループ Urgent のアラートに5分以内に Acknowledge する

• RQ-06 本番前の検証と承認：ルール（相関・アラート管理）の追加・変更は、開発環境で試験してから本番へ移送し、変更は承認を経る

• RQ-07 追跡：インシデントから元のアラート、アラートから影響サービスへ、画面上でたどれる

設計と要件の対応表

要件と設計の対応です。設計ごとに、その設計で満たす要件を並べます。

• CIと業務サービスの登録規則（DS-01）：RQ-02 重大な親の1分以内の起票／RQ-07 追跡

• 当番の画面（DS-02）：RQ-03 警告の日次確認／RQ-05 5分以内の Acknowledge

• イベントの受信とCIの特定（DS-03）：RQ-01 親子へのまとめ／RQ-04 回復通知での自動解決

• 相関ルール（DS-04）：RQ-01 親子へのまとめ

• インシデントの起票条件（DS-05）：RQ-02 重大な親の1分以内の起票／RQ-03 警告の日次確認

• インシデントの項目（DS-06）：RQ-02 重大な親の1分以内の起票／RQ-07 追跡

• 自動クローズ（DS-07）：RQ-04 回復通知での自動解決

• ロール（DS-08）：RQ-05 5分以内の Acknowledge／RQ-06 本番前の検証と承認

• 監視ツールからの受信（DS-09）：RQ-02 重大な親の1分以内の起票

• 処理時間（DS-10）：RQ-02 重大な親の1分以内の起票／RQ-04 回復通知での自動解決

• 更新セットでの移送（DS-11）：RQ-06 本番前の検証と承認

3. 設計方針

この章で決めること：標準のまま使うもの、設定で調整するもの、追加開発するもの。

方針は、標準で足りるものを標準のまま使い、足りない部分だけ設定で調整する順に決めます。追加開発（スクリプト）は、この案件の要件には1件もありません。次の図は、イベントがインシデントになり閉じるまでの流れを、各段を受け持つ設計の名前で示したものです。

• イベントの受信（設定で調整）：/api/global/em/jsonv2 に送り、ノード名で CI を特定する

• 相関（設定で調整）：相関ルール1つで、DB のアラートを親に、AP・Web・LB のアラートを子にする

• 起票（設定で調整）：標準のルールは有効化せず、条件を持つアラート管理ルールを1つ作る

• 当番の確認（標準のまま）：Express List の優先度グループを使う

• クローズ（標準のまま）：クローズに関するプロパティ4つを既定のまま使う

• 機械学習のクラスタリング（採用しない）：案件の対象外

採用の理由

• 起票を自作のアラート管理ルールで組むのは、重大度・ノードの範囲・子でないこと・メンテナンス時間帯を、条件として自分で書けるためです。標準の自動起票3ルールの条件は照合しておらず、この判断は暫定です。標準ルールの条件を確かめる作業は、未決事項に置きました

• クローズを標準のままにするのは、回復通知で Resolved になる動作を PDI で3回確かめたためです

• スクリプトを書かないのは、受信・相関・起票・クローズがすべて標準の設定の範囲で動いたためです

却下した案

• 標準の Create Incident 系ルールをそのまま有効化する案：暫定で却下。PDI では、有効化しても AIOps Experience を導入するまで実行記録が0件のままで、導入後の動作と条件の中身は確かめていません。条件を確かめる作業は、未決事項「標準の起票ルールの条件の照合」に置きます。案件の条件を満たすと分かれば、有効化に切り替えます

• 機械学習によるクラスタリングで相関する案：却下。案件の対象外で、PDI では必要な機械学習の定義が有効でないという記録が毎分ログに残っています

• インシデントのスクリプトで impact を設定する案：却下。スクリプトを書かない方針のためです。impact の扱いは「インシデントの項目」で決めます

4. データ設計

この章で決めること：CI と業務サービスをどう登録し、アラートとつなぐか。新しいテーブルは追加しません。

DS-01 CIと業務サービスの登録規則

対象：cmdb_ci の派生クラス（cmdb_ci_lb・cmdb_ci_linux_server・cmdb_ci_db_mysql_instance）と、業務サービス（Mapped Application Service）

目的：監視ツールのノード名と CI を一致させ、CI の担当グループと業務サービスへの所属を決めます。

前提：監視ツール側のノード名が決まっています。CMDB への自動登録（Discovery）は使わず、手で登録します。

標準仕様

• イベントのノード名は、CI の名前で探されます。PDI では processing_notes に「Node will be resolved to CI id … found by node name」と記録されました［実測］

• ノード名に一致する CI がないイベントの扱い［未確認］

• Calculated Application Service は、構成の関連（svc_ci_assoc）が、作成後も空のままだったため削除しました［実測］。作成そのものはできました

• Mapped Application Service は、POST /api/now/cmdb/app_service/create で作成し、「6 CIs added to business service」が返りました［実測］

• インシデントの説明には「Total impacted services by the CI: [ec-db-01] is 1」と入ります。一方、Impact Summary の Service 欄は空でした［実測］

• 影響の計算の対象は Service Instance とその派生クラスだけで、Business Service は対象外です［公式］

• syslog に「Service … is not in the model」という記録が出ました［実測］

設計内容

• 監視ツールのノード名は、CI の名前と完全に一致させる。大文字小文字・ドメイン部分を含める

• CI は6件（ec-lb-01・ec-web-01・ec-web-02・ec-app-01・ec-db-01・ecpay-mysql）と、hr-file-01 を登録する。hr-file-01 は業務サービスに含めない

• CI の担当グループ（support_group）は、DB の2件を Database、Web/AP の3件を Web/AP とする

• 業務サービス「オンライン決済サービス」は Mapped Application Service として、6件の CI を結んで作る。Calculated は使わない

• 登録は監視設計担当が行い、CI の追加・改名のたびに監視ツール側のノード名と突き合わせる

設計理由

• ノード名と CI 名を一致させると、受信の時点で CI が特定され、相関ルールとアラート管理ルールの条件にノード名を使えます

• Calculated を使わないのは、作成後も関連が自動では埋まらないためです。関連を手で用意する案件では、Mapped のほうが登録の結果をすぐ確認できます

• hr-file-01 をサービスに含めないと、決済と無関係な警告が決済サービスの影響として扱われません

例外

• 未決事項：アラートからサービスへの追跡。PDI では、Impact Summary の Service 欄が空で、サービスまで画面でたどれることを確かめていません。決める人は監視設計担当で、期限は本番移行の2週間前です。決まるまで進められない作業は、追跡の運用基準の確定です

• 未登録のノード名のイベントは、アラートに CI が結ばれない可能性があります。受信前に CI を登録します

完了条件

• 監視ツールの全ノード名が、CI の名前と一致していること

• 業務サービスに6件の CI が結ばれていること

確かめ方

• TS-01 ノード名とCI名の一致［実施済み］：ec-db-01 などのノード名でイベントを送ります。合格基準は、アラートの CI が同名の CI に結ばれること

• TS-02 サービスへの影響表示［未実施］：親アラートからインシデントを開き、Impact Summary の Service 欄を確認します。合格基準は、Service 欄に「オンライン決済サービス」が表示されること

• 見直しの契機：CI の追加・改名、または影響計算の対象クラスが変わったとき

記入例：付録D「CIと業務サービスの登録規則」に載せます。

5. 画面設計

この章で決めること：当番が日々見る画面と、そこで使う優先度の分け方。

DS-02 当番の画面

対象：Service Operations Workspace の Express List、優先度グループ（em_alert_priority_group）

目的：当番が最初に開く画面と、警告の日次確認、Acknowledge の操作の場所を決めます。

前提：AIOps Experience が導入済みで、Express List が使えます。

標準仕様

• 優先度グループは、アラートの優先度を4つのカテゴリに分けて一覧の上に表示します。閾値 evt_mgmt.top_priority_group_threshold（既定 1M）を超えると Urgent です［公式］

• 優先度の計算ジョブは30分間隔（Calculate Alert Priority Grouping）、優先度のキューは19秒間隔です［実測］

• Express List は、AIOps Experience を導入する前の PDI には、ルート（sys_ux_app_route）がありませんでした［実測］

• デモでは、親アラートと子アラート4件が Urgent に並び、無関係の警告（hr-file-01）は Low のままに並びます。LB の子アラートは Minor でも Urgent に入ります［実測］

• Acknowledge は、アラートの画面から操作します［実測］

• 1日に何件の警告が出るかは、監視ツールの設定で決まります［未確認］

設計内容

• 当番は、Service Operations Workspace の Express List を最初に開く画面とする

• Urgent のアラートは、見つけた当番がその場で Acknowledge する

• 警告の日次確認は、Express List で Low のグループを開いて行う。確認の時刻は、運用設計書で決める

• 優先度の閾値と重みは、変更しない。変更するときは、変更票を起こして開発環境で試験する

設計理由

• 優先度の計算は標準のままでも、重大なアラートと警告を別のグループに分けられたためです

• Low のグループに警告を集めると、インシデントにしない警告も日次の確認で拾えます

例外

• 親アラートが閉じると、子アラートの扱いは evt_mgmt.rule_based_manual_closure で変わります。既定（false）のまま使います

• Urgent の表示を決めるジョブは確かめていません。優先度グループの計算は30分間隔のため、表示の遅れが5分以内の Acknowledge に影響するかは、試験の条件に含めて測ります［未確認］

• 未決事項：5分以内の Acknowledge の測定方法。決める人は運用設計書の担当で、期限は本番移行の2週間前です

完了条件

• 当番が、Express List から Urgent と Low のグループを開けること

• 警告のアラートが、Low のグループに表示されること

確かめ方

• TS-03 優先度グループの表示［実施済み］：親アラート・子アラート・警告のアラートがある状態で Express List を開きます。合格基準は、Urgent に親と子、Low に警告が並ぶこと

• TS-04 5分以内の Acknowledge［未実施］：Urgent のアラートの発生時刻、Urgent の表示時刻、Acknowledge の時刻を記録します。合格基準は、発生から Acknowledge までが5分以内で、Urgent の表示が30分間隔の計算ジョブを待たないこと

• TS-05 日次確認の絞り込み［未実施］：Low のグループを前日分で絞り込みます。合格基準は、前日の警告がすべて表示されること

• 見直しの契機：当番の人数・勤務時間が変わったとき

記入例：なし（理由：優先度グループは標準の設定のままで、記入する値がないためです）

6. ロジック設計

この章で決めること：受信から相関・起票・クローズまでの、各段の条件と処理。

DS-03 イベントの受信とCIの特定

対象：em_event、em_alert

目的：監視ツールのイベントを、どのキーでアラートにまとめ、どのイベントを受け付けるかを決めます。

前提：CI が登録済みです（CIと業務サービスの登録規則）。

標準仕様

• イベントはイベントルール、CI のバインディング、項目のマッピングで処理され、アラートが作られます［公式］

• em_event を挿入すると、アラートが作られ、processing_notes に CI のバインドの経過が残ります［実測］

• 同じメッセージキーのイベントを再送すると、アラートは増えず、重大度が更新され、イベント数が増えます。PDI では重大度が2から1に変わり、Overall Event Count は2になりました［実測］

• イベントの処理は、受信から evt_mgmt.events_processing_delay_sec（5秒）［実測］。この値が待ち時間として働くことは、プロパティの説明による［公式］

• 重大度（severity）を付けずに送ったイベントは、state が Error になり、アラートは作られません［実測］

• evt_mgmt.active_interval の値は14400秒（4時間）です［実測］。この期間内に新しいイベントが来ると、閉じたアラートを開き直すという設定の説明があります［公式］。実際の再オープンの挙動［未確認］

• 4時間を超えて届いたイベントの扱い［未確認］

設計内容

• 監視ツールは、イベントに source・node・severity・message_key・description を必ず付ける。resource と type も付けられる限り付け、合わせて7項目で送る

• メッセージキーは「ノード名＋リソース名＋事象」とし、同じ事象の再送は同じキーにする

• 回復通知は、severity を 0（Clear）にし、同じメッセージキーで送る

• 重大度は 1（Critical）から 5（OK）までと 0（Clear）だけを送る

• 受信側のプロパティは、既定のまま使う

設計理由

• 同じメッセージキーで再送すると、アラートが1件のまま重大度だけが更新され、件数が膨らみません

• 重大度が空のイベントは Error になって処理されないため、送信側で必須にします

例外

• 重大度が空で届いたイベントは、アラートにならず Error のまま残ります。監視ツール側の送信内容を直します

完了条件

• 監視ツールが送る全イベントに、必須の5項目（source・node・severity・message_key・description）が付いていること

• 同じメッセージキーの再送で、アラートが増えないこと

確かめ方

• TS-06 同キーの再送［実施済み］：同じメッセージキーで重大度を変えて2回送ります。合格基準は、アラートが1件のままで、重大度が更新され、イベント数が2になること

• TS-07 重大度の欠落［実施済み］：重大度を空にして送ります。合格基準は、イベントが Error になり、アラートが作られないこと

• TS-08 未登録のノード［未実施］：CI にないノード名で送ります。合格基準は、アラートの作成可否と CI の結びが記録されること

• 見直しの契機：監視ツールの項目が変わったとき

記入例：付録D「イベントの受信とCIの特定」に載せます。

DS-04 相関ルール

対象：em_alert_correlation_rule

目的：同じ障害から届く警報を、DB のアラートを親にして子としてまとめる条件と時間窓を決めます。

前提：CI が登録済みで、ノード名が一致しています（CIと業務サービスの登録規則、イベントの受信とCIの特定）。

標準仕様

• 相関ルールは、アラートを主と従に分けて関係を作ります。階層は2段階までで、複数の親は持てません［公式］

• PDI では、親の group_source が 2（Rules-based）、子が 5（Secondary）になりました［実測］

• 相関ルールの relationship_type の 1 は No Relationship です［実測］

• 標準の相関ルールは18件で、有効は2件だけです。自作ルールを除いた全件の件数で、画像は一覧のうち、自作2件と標準の有効2件・無効1件を含む5行を切り出したものです［実測］

• 機械学習のクラスタリングは、PDI では必要な定義が有効でなく、毎分ログに記録が出ます［実測］

• 時間窓を超えて届いたアラートがどうなるか［未確認］

自作の相関ルールのフォームでは、親と子の条件を別々に書きます。

設計内容

• 相関ルールは1つ作り、親を ec-db-01（DB）のアラート、子を ec-app-01・ec-web-01・ec-web-02・ec-lb-01 のアラートとする

• 時間窓は15分とする

• relationship_type は No Relationship のままにする

• 標準の相関ルールには手を付けない

• ルールの名前は「<サービス名>: <障害>を親に子をまとめる」とする

設計理由

• DB が止まると上位の AP・Web・LB の警報が連鎖するため、DB を親にすると、当番が見る親が1件に絞られます

• 時間窓15分は、モデル案件で決めた値です。自社の値は、付録Aの決め方で監視ツールのログから決めます

例外

• rule_based_manual_closure は false のままとします。親だけに Clear を送った検証で、子アラートも Closed になりました

• 親の ec-db-01 以外が原因の連鎖には、このルールは当てはまりません。別のルールを追加します

• 未決事項：時間窓15分の妥当性。決める人は監視設計担当で、期限は本番稼働の1か月後です。決まるまで進められない作業は、時間窓の変更です

完了条件

• 親1件に子4件が、15分以内の連鎖でまとまること

• 無関係な警告（hr-file-01）が、親にまとまらないこと

確かめ方

• TS-09 相関の親子化［実施済み］：DB の重大なアラートの後に、AP・Web の Major と LB の Minor のアラートを送ります。合格基準は、子4件の親が DB のアラートになること

• TS-10 時間窓の境界［未実施］：親の受信の16分後に、子のイベントを送ります。合格基準は、親にまとまらないこと

• 見直しの契機：サービスの構成が変わったとき、または相関の時間窓の見直し要望が出たとき

記入例：付録D「相関ルール」に載せます。

DS-05 インシデントの起票条件

対象：em_alert_management_rule、実行記録（em_alert_management_execution）

目的：どのアラートを、どの条件で、どのテンプレートでインシデントにするかを決めます。

前提：AIOps Experience（Alert Rules Management を含む）が導入済みで、evt_mgmt.alert_management_scoped_active が true です。

標準仕様

• アラート管理ルールは、条件に合うアラートに、インシデントの作成・ナレッジの作成・修復アクションの起動などを行います［公式］

• 標準の自動起票ルール（Create Incident・Create Incident for Primary Alert・Create Incident on Primary Critical Alert）は無効で、有効なのは手動起票の Create Incident Manually です［実測］

• 標準ルールを一時的に有効にしても、AIOps Experience を導入するまで実行記録は0件のままでした［実測］。自作ルールは、Type の不一致を直し、導入した後に自動で起票されました［実測］

• デモでは、DB のアラートの起票（受信の16〜20秒後）が、連鎖したアラートの到着より前に起きました［実測］

• ワークスペースの Alert automation は、自動化を Ignore・Enrich・Group・Respond の4種類に分けて設定します［実測］

• 条件の Type は、イベントタイプ（em_event_type）の参照です。表示名（Disk Full）で書くと一致0件で、エラーは出ません。sys_id で書くと一致しました［実測］

• アラートの条件にドットウォークがあるとエラーを記録するビジネスルール（Inform filter with dot-walk、error_msg は「Dot-walk in alert filter」）が、定義として存在します［実測：定義の読み取り］。条件を作って発火させた確認［未確認］

• ルールを作ってから、あとでアクション（M2M）を結ぶと、ルールが active=false になり「No active actions」が記録されます。再度 active を true にすると解消しました［実測］

• 標準の3ルールの条件の中身［未確認］

• maintenance 項目が、メンテナンス時間帯に自動で true になる仕組み［未確認］

標準の自動起票ルールのフォームには、有効でないというメッセージが出ます。

このため、本書では自作ルールを1つ作ります。デモのルールは Active が有効で、説明に対象と担当グループを書いています。

実行記録（em_alert_management_execution）には、ルールの実行ごとにアラートと、作られたインシデントが記録されます。

①の4種類のうち Ignore を開くと、②の Active が True の自動化が3件あり、③の Source は OMi・Hyperic・OBM です。

設計内容

• アラート管理ルールを1つ作る。条件は次の6つをすべて満たすこととする。

• source が EC-Monitor

• severity が Critical

• node が決済サービスのノード名（ec-lb-01・ec-web-01・ec-web-02・ec-app-01・ec-db-01）のどれか

• 子でない（parent が空）

• インシデント未作成（incident が空）

• maintenance が false

• node の複数指定は、相関ルールのフォームで Node の is one of により指定できた（画像）。アラート管理ルールの条件では範囲指定を［未確認］とし、TS-29 で確かめる

• 条件の Type は使わない。使うときは、イベントタイプの sys_id で指定する

• 条件にドットウォークを含めない

• アクションは、インシデント作成を1つ結ぶ。テンプレートは「担当グループ Database」とする

• ルールは「アクションを先に用意してから、ルールを有効にして保存する」順で作る。作成後は、active が true であることと、エラーメッセージが空であることを確かめる

• 標準の3つの自動起票ルールは、有効にしない

• Warning と Minor の単独のアラートは、条件に合わないため、自動では起票しない

• 決済サービス外のノード（hr-file-01 など）の Critical も、自動では起票しない。必要なときは、当番が有効な手動起票ルール（Create Incident Manually）で起票する

設計理由

• 重大度・ノードの範囲・子でないことを条件にすると、業務サービスに影響する重大なアラートの1分以内の起票を、1つのルールで満たせます。ノードの範囲を入れないと、決済と無関係な Critical も同じ担当グループのインシデントになります

• parent が空であることは「子ではない」という意味です。起票は連鎖の到着より前に起きるため、起票の時点では DB のアラートもまだ親になっていません

• Type を表示名で書くと一致0件のまま気づけないため、設計の段階で禁止します

• ルールを先に作ると active=false になるため、作成の順を固定します

例外

• 子になる前に届いた別ノードの Critical は、親にまとまる前に起票されます。この扱いは、標準の起票ルールの条件の照合と合わせて決めます

• メンテナンス時間帯の除外は、maintenance 項目の値に依存します。この項目が自動で true になるかを確かめるまで、時間帯の除外は未決事項です

• 未決事項：メンテナンス時間帯のアラートの除外方法。決める人は監視設計担当で、期限は本番移行の2週間前です。決まるまで進められない作業は、日曜 2:00〜4:00 の運用基準の確定です

完了条件

• 条件に合う重大なアラートから、インシデントが自動で作られること

• 実行記録（Alert execution）に「Automatic execution #1 out of 1.」が残ること

• ルールの active が true で、error_msg が空であること

• node 条件を含む版は TS-29 で確認する（TS-11 の実施済みは node 条件なしの版に限る）

確かめ方

• TS-11 重大な親だけの起票［実施済み（node 条件なしの版）］：親アラートと警告のアラートがある状態で、親を重大度1で受信します（PDI の自作ルールは、ノードの範囲を条件に含めていません）。合格基準は、親だけがインシデントになり、警告のアラートは起票されないこと

• TS-29 決済サービス外の Critical［未実施］：ノードの範囲を条件に加えたルールで、hr-file-01 の Critical を送ります。合格基準は、インシデントが作られず、決済サービスのノードの Critical は起票されること

• TS-12 Type の参照値［実施済み］：Type を表示名で指定した条件と、sys_id で指定した条件を、同じアラートに当てます。合格基準は、表示名で0件、sys_id で一致すること

• TS-13 作成の順序［実施済み］：ルールを先に作ってからアクションを結びます。合格基準は、active=false と「No active actions」が出て、有効化で解消すること

• TS-14 メンテナンス時間帯［未実施］：日曜 2:00〜4:00 に重大なアラートを送ります。合格基準は、インシデントが作られないこと

• TS-15 標準3ルールの有効化［未実施］：開発環境で標準の Create Incident on Primary Critical Alert を有効にし、同じアラートを送ります。合格基準は、条件と起票結果が作業記録に残ること。未決事項「標準の起票ルールの条件の照合」の判断に使います

• 見直しの契機：メジャーアップグレード、または標準のアラート管理ルールの仕様が変わったとき

記入例：付録D「インシデントの起票条件」に載せます。

DS-06 インシデントの項目

対象：incident（アラート管理ルールのテンプレート）

目的：自動で作るインシデントに、どの項目を、どの値で入れるかを決めます。

前提：起票の条件が決まっています（インシデントの起票条件）。

標準仕様

• インシデントは、アラート管理ルールのテンプレートで作られ、呼び出し元は Event Management、CI はアラートの CI です［実測］

• テンプレートに指定した項目のうち、担当グループ（assignment_group）だけが反映されました。category は inquiry、state は New のままでした［実測］

• 作成処理（EvtMgmtIncidentHandler）は、urgency を、アラートの severity が 1 か 2 のときはそのまま、それ以外は 3 にします。impact は設定しません［実測］

• 作成されたインシデントには impact の値が入り、デモ3回のうち、1回目は 1（priority 1）、2回目と3回目は 3（priority 3）になりました。作成処理以外の経路で入った値で、原因は確かめていません［実測］

• インシデントの説明には、アラートの番号・CI・メトリクス名・影響サービスの件数が入ります［実測］

• Origin のカードに、元のアラートの番号・優先度グループ・重大度・CI・説明が表示されます［実測］

• impact を自動で設定する方法［未確認］

設計内容

• 担当グループは、テンプレートで Database とする。他の項目（category・state）は、テンプレートでは設定しない

• urgency は標準の処理に任せ、Critical の親は 1 とする

• impact は、起票後に当番が確認して設定する。期限は運用設計書で決める

• 優先度は、impact を設定した後の値を正とする。起票直後の優先度は、仮の値として扱う

• インシデントから元のアラートへは、Origin のカードのアラートの番号から開く

設計理由

• テンプレートで反映されるのは担当グループだけのため、他の項目の値は、設計では当てにしません

• impact は、PDI の3回のうち1回で値が変わり、原因も不明です。人が確認する手順を入れると、優先度が誤ったまま P1 の第一報が出る事態を防げます

例外

• 未決事項：impact の自動設定。決める人は監視設計担当で、期限は本番移行の2週間前です。決まるまで進められない作業は、起票直後の優先度を使う運用の確定です

• 担当グループは、CI の support_group と一致しなくても、テンプレートの値が優先されます

完了条件

• 自動で作られたインシデントの担当グループが Database であること

• インシデントの Origin に、元のアラートの番号が表示されること

確かめ方

• TS-16 項目の反映［実施済み］：自動で作られたインシデントを開きます。合格基準は、担当グループが Database、urgency が 1であること。impact の値と、category・state がテンプレートの値でないことを記録すること。impact は当番が設定する前の仮の値として扱う

• TS-17 impact の自動設定［未実施］：テンプレートに impact を入れた版を開発環境で試験します。合格基準は、impact が設定の値で作られること

• 見直しの契機：メジャーアップグレード、または impact の扱いが決まったとき

記入例：付録D「インシデントの項目」に載せます。

DS-07 自動クローズ

対象：システムプロパティ evt_mgmt.alert_closes_incident・evt_mgmt.incident_closes_alert・evt_mgmt.rule_based_manual_closure・evt_mgmt.alert_auto_close_interval、スケジュールジョブ

目的：回復通知でアラートとインシデントを自動で閉じる方式と、人の操作を要する範囲を決めます。

前提：インシデントが自動で作られます（インシデントの起票条件、インシデントの項目）。

標準仕様

• evt_mgmt.alert_closes_incident は resolve、evt_mgmt.incident_closes_alert は true、evt_mgmt.rule_based_manual_closure は false、evt_mgmt.alert_auto_close_interval は 0（無効）です［実測］

• 回復通知（severity 0）で、アラートが Closed になり、紐づくインシデントが Resolved（state 6）になります。親だけに Clear を送った検証では、子アラートも Closed になり、親子の紐づけが解除されました［実測］

• デモの3回は5ノードすべてに Clear を送り、全アラートが Closed、インシデントが Resolved になりました［実測］

• Resolved のインシデントの close_notes は「Closed the task associated with alert: …」です［実測］

• インシデントを閉じると、関連するアラートを閉じるジョブ（Event Management - Close alerts when incident resolved、13秒間隔）が動きます。AIOps Experience の導入前は、アラートが Open のままでした［実測］

• evt_mgmt.alert_reopens_incident の値は new です［実測］。説明欄は途中で終わっており、挙動の全文は確認していません［未確認］

• Acknowledge したアラートに回復通知を送っても、アラートは Closed、インシデントは Resolved になりました［実測］

設計内容

• 回復通知（severity 0）で、アラートを閉じ、インシデントを Resolved にする。Closed にする条件は、運用設計書で決める

• クローズに関するプロパティ4つ（alert_closes_incident・incident_closes_alert・rule_based_manual_closure・alert_auto_close_interval）は、既定のまま使う

• 回復通知がこない障害のアラートは、当番が手動で閉じる。自動のクローズ期限は設けない

• 閉じた後に同じキーのイベントが届いたときの扱いは、再オープンの試験が済むまで、運用で確認する

設計理由

• 標準の4つのプロパティで、アラートとインシデントの両方向の連動が決まり、PDI で3回の動作を確かめたためです

• 自動クローズの間隔を0のままにすると、回復通知がこないアラートが自動で閉じられず、当番が見落とした障害の確認の機会が残ります

例外

• 回復通知より先に人がインシデントを Resolved にすると、アラート側は別のジョブで閉じられます。閉じるまでの時間は、ジョブの間隔の範囲です

完了条件

• 回復通知の後、アラート・子アラートが Closed で、インシデントが Resolved であること

• インシデントの close_notes に、アラートの番号が残ること

確かめ方

• TS-18 Clear での解決［実施済み］：親子のアラートがある状態で、全ノードに Clear を送ります。合格基準は、アラートがすべて Closed で、インシデントが Resolved になり、人の操作が不要なこと

• TS-19 インシデント側のクローズ［実施済み］：インシデントを手動で Closed にします。合格基準は、アラートが Closed になること

• TS-20 再オープンの扱い［未実施］：閉じた後に同じキーのイベントを送ります。合格基準は、アラートの状態と、インシデントの扱いを記録できること

• 見直しの契機：メジャーアップグレード、または evt_mgmt.* の既定値が変わったとき

記入例：付録D「自動クローズ」に載せます。

7. 権限設計

この章で決めること：誰に、どのロールを付与し、何を操作できるようにするか。

DS-08 ロール

対象：ロール（evt_mgmt_admin・evt_mgmt_operator・evt_mgmt_user・evt_mgmt_integration・evt_mgmt_connector_instance_*）

目的：監視設計担当・当番・監視ツールの連携用ユーザーに付けるロールを決めます。

前提：ユーザーと、当番・DB チームなどのグループが登録済みです。

標準仕様

• Event Management のロールは8つです［実測］

• evt_mgmt_admin：プロパティとルールを設定・構成する

• evt_mgmt_operator：アラートを管理する（閉じる、確認するなど）

• evt_mgmt_user：アラートのライフサイクルを管理する

• evt_mgmt_integration：イベントの生成とノードの登録を行う。REST で送信する連携用

• evt_mgmt_connector_instance_read・create・write・delete：PUSH / PULL コネクタインスタンスの操作

• アラート管理ルールの作成には evt_mgmt_admin、手動実行には evt_mgmt_operator が要ります［公式］

• 8つのロールは、プラグイン導入時に作られます（レコードの作成日は2014〜2023年）［実測］

• ロールの包含関係と、ACL の中身［未確認］

• 一般の利用者のロールで、各画面と操作を確かめた結果［未確認］

設計内容

• 監視設計担当に evt_mgmt_admin を付与する。1名だけとする

• 当番に evt_mgmt_operator を付与する。evt_mgmt_admin は付与しない

• 監視ツールの連携用ユーザーに evt_mgmt_integration だけを付与する。画面にログインするユーザーとは分ける

• evt_mgmt_connector_instance_* は、このモデル案件では付与しない。REST で送るため、コネクタインスタンスは使わない

• 付与は、グループへのロールの付与とし、ユーザーへの直接付与は行わない

設計理由

• 設定する担当と、アラートを操作する担当を分けると、当番の操作でルールが変わる事態を避けられます

• 連携用ユーザーを分けると、パスワードが漏れても、アラートの操作はできません

例外

• 緊急時に当番がルールを無効化する必要が出た場合は、監視設計担当に依頼します

• 未決事項：ロールの包含と ACL の確認。決める人は監視設計担当で、期限は本番移行の2週間前です。決まるまで進められない作業は、当番へのロール付与の確定です

完了条件

• 監視設計担当・当番・連携用ユーザーのロールが、設計どおりであること

• 当番が、ルールの変更画面を開けないこと

確かめ方

• TS-21 当番ロールでの操作［未実施］：evt_mgmt_operator だけを持つユーザーで、アラートの Acknowledge とルールの編集を試します。合格基準は、Acknowledge できてルールは編集できないこと

• TS-22 連携用ユーザーでの画面操作［未実施］：evt_mgmt_integration だけを持つユーザーで、画面にログインします。合格基準は、アラートの閲覧・操作ができないこと

• 見直しの契機：当番の体制が変わったとき、またはロールの構成がメジャーアップグレードで変わったとき

記入例：付録D「ロール」に載せます。

8. 連携設計

この章で決めること：監視ツールから何を、どの宛先に、どの形式で送るか。

DS-09 監視ツールからの受信

対象：/api/global/em/jsonv2（Inbound Event）、連携用ユーザー

目的：監視ツールがイベントを送る宛先・認証・項目・重複の扱いを決めます。

前提：連携用ユーザーが登録され、監視ツールから ServiceNow のインスタンスへ通信できます。

標準仕様

• POST /api/global/em/jsonv2 で、イベントを複数件まとめて受け付けます。PDI では、管理者で「1 events were inserted」（HTTP 200）が返りました［実測］

• 送る項目のうち、source は「イベントを生成する送信元（監視ツール）」、node は「監視対象の物理デバイスまたは仮想的な実体」、resource は「イベントを生成したノード上のリソース」です［公式］

• 同じメッセージキーのイベントは、同じアラートに束ねられます（イベントの受信とCIの特定）［実測］

• connector を使わずに REST で送る方式の、連携用ユーザーでの実行［未確認］

• 受信に失敗したときの、監視ツール側の再送の挙動［未確認］

設計内容

• 監視ツールは、HTTPS で /api/global/em/jsonv2 に POST する。1回に送るイベントは、同じ障害の連鎖をまとめた複数件とする

• 認証は、連携用ユーザー（evt_mgmt_integration）の資格情報とする。資格情報は監視ツール側の秘密情報の保管場所に置き、設計書には書かない

• 送る項目は、source（EC-Monitor）・node・resource・type・severity・message_key・description とする

• type は、イベントタイプの名前で送る。アラート管理ルールの条件には、type を使わない（インシデントの起票条件）

• 送信に失敗したときは、監視ツール側で同じメッセージキーのまま再送する

• 回復通知は、同じメッセージキーで severity 0 を送る

設計理由

• 同じメッセージキーで再送すれば、重複してもアラートが増えないため、再送の方針を単純にできます

• 資格情報を設計書に書かないのは、設計書が複数の担当に共有されるためです

例外

• 連携用ユーザーは、モデル案件では架空です。PDI では管理者で確かめており、連携用ユーザーの権限での受信は未確認です

完了条件

• 監視ツールから送ったイベントが、1回の POST で受け付けられること

• 受け付けたイベントが、アラートになること

確かめ方

• TS-23 jsonv2 での受信［実施済み］：管理者の資格情報で、イベントを POST します。合格基準は、HTTP 200 で「events were inserted」が返り、アラートが作られること

• TS-24 連携用ユーザーでの受信［未実施］：evt_mgmt_integration だけのユーザーで POST します。合格基準は、HTTP 200 になること

• 見直しの契機：監視ツールの種類が変わったとき

記入例：付録D「監視ツールからの受信」に載せます。

9. 非機能

この章で決めること：起票までの時間の見積もりと、ジョブの前提。

DS-10 処理時間

対象：スケジュールジョブ、evt_mgmt.events_processing_delay_sec

目的：受信から起票までを1分以内にする要件を、何の値で見積もり、何で確かめるかを決めます。

前提：起票の条件と、自動クローズが決まっています（インシデントの起票条件、自動クローズ）。

標準仕様

• 受信から起票までは、デモの3回で20秒・17秒・16秒でした［実測］

• 回復通知から Resolved までは、デモの3回で8秒・6秒・7秒でした［実測］

• アラート管理ルールを評価するジョブは約11秒間隔、インシデントを閉じた後にアラートを閉じるジョブは13秒間隔です［実測］

• 受信後の処理待ちは5秒です（evt_mgmt.events_processing_delay_sec）［実測］

• 大量のイベントが届いたときの処理時間［未確認］

設計内容

• 受信から起票までの合格基準は60秒以内とする。測定は、イベントの受信時刻とインシデントの作成時刻の差とする

• ジョブの間隔と処理待ちは、既定のまま使う

• 負荷試験は、モデル案件の想定（同じ障害で5件のイベント）の10倍の量で行う

設計理由

• 実測の3回は16〜20秒で、60秒に対して余裕があります。ただし3回の結果のため、合格基準は実測の最大値でなく、要件の値とします

例外

• 件数が多いときの処理待ちと、ジョブの実行時間は確かめていません。負荷試験の結果で見直します

完了条件

• 受信から起票までの時間が、60秒以内で記録されること

• 回復通知から Resolved までの時間が、記録されること

確かめ方

• TS-25 起票までの時間［実施済み］：重大な親アラートのイベントを送り、受信からインシデントの作成までの時間を測ります。合格基準は、60秒以内であること

• TS-26 負荷時の処理時間［未実施］：5件の10倍のイベントを、1回の POST で送ります。合格基準は、起票までが60秒以内であること

• 見直しの契機：ジョブの間隔が変わったとき、またはイベントの量が増えたとき

記入例：付録D「処理時間」に載せます。

有料エリアの内容

有料エリアには、本番へルールを移す設計と、設計を実際の案件で使い回すための成果物を置いています。

• 設計1件：更新セットでの移送（移す順序・移らないもの・移送後の確認）

• 試験の実施状態の一覧（試験29件のうち13件が実施済み）

• 設計判断6件と未決事項7件

• 付録A：設計項目の記入様式（空欄の書式）と、値の決め方

• 付録B：変更票の書式と記入例

• 付録C：変更要求から、変更する設計と確かめる試験を引く表

• 付録D：設計ごとの記入済み例（モデル案件で設計を適用した後の期待値）

💰 ここから先は有料エリア