Event Management モジュールの運用手順書

監視ツールの警報が1通ずつインシデントになる運用では、DB が止まった夜にアプリ・Web・ロードバランサーの警報まで別々に起票されます。当番が2名しかいなければ、手順が頭の中にあるだけで、休暇や異動のたびに止まります。この記事は、Event Management の構築・定常・障害時の作業を13の手順に分け、操作・期待結果・分岐・中止条件まで書いた手順書です。

前提は、検証用のインスタンスで作って確かめてから、本番へ移送する流れです。実際の検証は PDI 1つで行いました。手順(4)から手順(6)は決済障害のイベントを3回流して確かめ、手順(10)と手順(11)は症状を実際に起こして確かめました。手順(12)で起こしたのは、「インシデントを閉じてもアラートが閉じない」症状だけです。手順(1)から手順(3)は、REST とスクリプトで作成した結果を確かめた手順で、画面の入力操作は確かめていません。手順(7)、手順(8)、手順(9)は PDI では実行していません。手順(4)の片付けも未実行です。各手順の冒頭に、実行した範囲を書きました。

この手順書でできること

• 症状や依頼から、実行する手順を番号で引ける（第1章）

• 業務サービスの登録、相関ルール、アラート管理ルールを作り、試験イベントで起票と自動解決まで確かめられる（手順(1)から手順(4)。無料部）

• 当番が Express List で Urgent を確認し、自動作成されたインシデントを点検できる（手順(5)から手順(7)。無料部）

• 月次の棚卸し（手順(8)。無料部）と、メジャーアップグレード後の確認（手順(9)。有料部）を、同じ書式で行える

• 「インシデントが作られない」「閉じない」症状を、見る場所の順に切り分けて復旧できる（手順(10)から手順(12)。有料部）

この記事のモデル案件は架空の設計例です。ネットショップ「EC サイト」の業務サービス「オンライン決済サービス」を、既存の監視製品（仮称 EC-Monitor）から REST でイベントを送って監視する想定です。次の値は架空なので、自社の値に置き換えてください（置き換える箇所には★を付けます）。

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

• DB チーム（グループ Database）は夜間休日オンコール1名、呼び出しから30分以内に着手 ★

• 相関の時間窓は15分、メンテナンス時間帯は毎週日曜2時から4時 ★

• 決済側の構成は、ロードバランサー ec-lb-01、Web の ec-web-01 と ec-web-02、AP の ec-app-01、DB の ec-db-01（いずれも Linux サーバー）と、MySQL インスタンス ecpay-mysql の計6つ。決済と無関係な Linux サーバー hr-file-01 も同じ監視対象

対象外は、Discovery と Service Mapping による CMDB の自動作成、監視ツール側の設定、機械学習によるアラートのクラスタリングです。標準で何がどう設定されているかは第2巻の「Event Management モジュールの設定」、設計の決定は第4巻、体制と判断基準は第5巻に書きます。この巻は操作に集中します。

1. 全手順に共通する事項

この章で決めること：誰が、どの環境で、どの手順を使い、何を作業記録に残すか。

対象者と前提スキル

• 対象者：運用当番（インシデントとアラートを操作する人）と、ITOM 管理者（ルールとプロパティを作る人）

• 前提スキル：クラシック画面で一覧とフォームを開けること。Service Operations Workspace（以降 SOW）の Express List を開けること

• 前提ロール：ルールの作成は evt_mgmt_admin、アラートの操作は evt_mgmt_operator、イベントの送信は evt_mgmt_integration。この記事の検証は admin で行いました

対象環境

• Brazil の PDI。Event Management プラグインに加えて、Store アプリ AIOps Experience（sn_sow_aiops、無料）が入っていること。この PDI では、導入するまでアラート管理ルールが評価されず、インシデントが作られませんでした（手順(11)）。自社の環境では、必要なアプリと評価ジョブを手順(11)で確かめます

• 作業先が検証用であることを、着手前に毎回確かめます。ルールの追加と変更は、検証環境で試験してから本番へ移送します

• この記事の検証は PDI 1つです。更新セットでの移送そのものは確かめていません

手順の一覧

手順は構築・定常・障害時の3つに分けています。所要時間は人が実行した時間を測っていないため、すべて未計測です。

• 手順(1) 業務サービスと構成アイテムを登録する（構築）：新しい監視対象をサービスに加えるとき。必要なロールは CMDB を更新できるロール。PDI では REST で作成して確認（画面操作は未確認）

• 手順(2) 相関ルールを作る（構築）：同じ障害の警報を、親子の関係にするとき。必要なロールは evt_mgmt_admin。PDI では REST で作成して動作確認（画面操作は未確認）

• 手順(3) アラート管理ルールを作る（構築）：重大な親アラートからインシデントを自動作成するとき。必要なロールは evt_mgmt_admin。PDI では REST で作成して動作確認（画面操作は未確認）

• 手順(4) 試験イベントで起票と自動解決を確かめる（構築）：手順(2)と手順(3)の後。必要なロールは evt_mgmt_integration と evt_mgmt_admin。PDI で実行（操作7の片付けは未実行）

• 手順(5) 当番が Express List で Urgent を確認し、Acknowledge する（定常）：当番の開始時と警報の通知を受けたとき。必要なロールは evt_mgmt_operator。PDI で実行

• 手順(6) 自動作成されたインシデントを点検する（定常）：インシデントが自動で作られたとき。必要なロールは ITIL 相当。PDI で確認（impact の手動設定は未実行）

• 手順(7) 日次：警告アラートの確認とクローズ（定常）：1日1回。必要なロールは evt_mgmt_operator。PDI では未実行

• 手順(8) 月次：ルールの棚卸し（定常。無料部）：月1回。必要なロールは evt_mgmt_admin。PDI では未実行

• 手順(9) メジャーアップグレード後の確認（定常）：アップグレードの後。必要なロールは evt_mgmt_admin。PDI では未実行

• 手順(10) イベントが Error になる（障害時）：送ったイベントがアラートにならないとき。PDI で再現

• 手順(11) アラートはあるのにインシデントが作られない（障害時）：PDI で再現して復旧

• 手順(12) アラートとインシデントの終了連動不良（障害時）：回復通知でインシデントが閉じない、またはインシデントを閉じてもアラートが閉じないとき：PDI で再現

• 手順(13) Quick Incident で手動のインシデントを作る（定常）：Major の親アラート、または決済 CI の警告を、手動でインシデントにするとき。必要なロールは evt_mgmt_operator とインシデントを作れるロール。PDI でインシデントの作成まで実行（影響度の手動設定は未実行）

症状から手順を引く

• 新しい監視対象を加えたい：手順(1)

• 同じ障害の警報が別々のアラートになる：手順(2)

• 重大なのにインシデントができない：手順(3)、それでも出なければ手順(11)

• 送ったイベントがアラートに現れない：手順(10)

• 回復通知を送ったのにインシデントが残る：手順(12)

• 朝の当番で何を見るか：手順(5)から手順(7)

• Major の親アラートや決済 CI の警告を手動でインシデントにする：手順(13)

モデル案件の要件との対応は次のとおりです。第4巻の設計は要件と同じ番号で、第5巻の運用ルールは別の番号（OR-01 から）で、対応表により要件と結び付けられます。

• 要件(1)（警報を原因の CI のアラートに子としてまとめる。時間窓15分）：手順(2)、手順(4)

• 要件(2)（重大な親アラートだけを、受信から1分以内にインシデント化）：手順(3)、手順(4)、手順(11)

• 要件(3)（警告単独はインシデントにせず、当番が日次に確認）：手順(7)、手順(13)

• 要件(4)（回復通知で、アラートを Closed、関連インシデントを Resolved にする）：手順(4)、手順(12)

• 要件(5)（Urgent に5分以内に Acknowledge）：手順(5)

• 要件(6)（ルールの変更は検証環境で試験し、承認を経て移送）：手順(8)、手順(9)

• 要件(7)（インシデントから元のアラートへ、1クリックでたどる）：手順(6)

画面を開く URL

次の URL を、自分のインスタンスの先頭に付けて開くと、この記事で触れる画面にそのまま入れます。

• イベント：/em_event_list.do（時刻と message_key で絞る）

• アラート：/em_alert_list.do（parent と incident の列を出しておく）

• 相関ルール：/em_alert_correlation_rule_list.do

• アラート管理ルール：/em_alert_management_rule_list.do

• アラート管理ルールの実行履歴：/em_alert_management_execution_list.do

• Event Management のプロパティ：/sys_properties_list.do?sysparm_query=nameSTARTSWITHevt_mgmt

• スケジュールジョブ：/sysauto_script_list.do?sysparm_query=nameLIKEEvent Management

作業記録の残し方

1. 依頼票またはチケットの番号を、作業記録の先頭に書く（形式は自社で決める。例：CHG-2026-0042）★

2. 変更する画面で、変更前の値（有効状態、条件、プロパティの値）を作業記録へ写す。新規作成は「なし（新規）」と書く

3. 手順を実行し、変更後の値、確認者、画面の保存先を作業の終了時に追記する

依頼票の番号がない、実行資格がない、変更前の値を控えられない、のいずれかなら着手しません。判断できない依頼は変更せず、次の「連絡と引継ぎ」に従います。記入の書式は、有料部の「作業記録の書式」にあります。

連絡と引継ぎ

ルールや構成を直す担当（ITOM 管理者、運用設計書でいう監視設計担当）は平日の9時から18時だけです。夜間と休日に判断が止まらないよう、第5巻の運用設計書に合わせて、次のとおり定めます。値は架空の設計例で、自社の値に置き換えます。

• 一次受付：運用当番が、インシデントとアラートの受付を保持する。連絡がつかない相手がいても、受付は手放さない

• ルールと構成の変更：夜間と休日は行わない。受付と引継ぎだけを続ける。平日でも監視設計担当が不在のときは、変更を延期する

• インシデントの引継ぎ先：担当グループ。夜間と休日は Database と Web/AP のオンコール各1名を呼び出す。着手は呼び出しから30分以内 ★

• Event Management 自体の異常（イベントが処理されない、ルールが動かない）の連絡先：平日の9時から18時は監視設計担当。それ以外はサービス責任者（不在時は代行者）。Acknowledge が10分を過ぎても入らないときも同じ

• 連絡先の台帳：自社の連絡先台帳（所在と版は第5巻の運用ルールで決める）★

• 台帳と連絡先が決まっていない場合は、本番での運用を開始しません

以降の手順の「連絡先」は、この定めを指します。

2. 構築の手順

この章で決めること：サービスの登録、相関ルール、アラート管理ルールを作り、試験イベントで動作を確かめること。

実行する順番は、手順(1)、手順(2)と手順(3)、手順(4)です。手順(1)で構成アイテムを作っておくと、イベントの node が構成アイテムに紐づき、アラートからサービスへたどれます。手順(2)と手順(3)は互いに独立しているため、どちらを先に作っても構いません。手順(4)は2つが終わってから流します。

途中の手順で期待結果が得られなければ、次の手順へ進まず、その手順の「中止条件と連絡先」に従います。手順(4)で起票されなければ、手順(11)で原因を切り分けます。

手順(1) 業務サービスと構成アイテムを登録する

PDI では、REST で構成アイテムと Mapped Application Service を作成して結果を確かめました。画面で入力する操作は確かめていません。以下の画面操作は、標準のフォームの項目名で書いた手順で、未確認です。

1. 目的と契機：監視対象を CMDB に登録し、アラートが構成アイテムとサービスにたどれる状態にします。新しい監視対象が加わったときに実施します。

2. 前提・ロール・承認：CMDB を更新できるロール。承認済みの依頼票。サービス名と重要度（モデル案件では「オンライン決済サービス」、重要度は最上位 ★）。

3. 事前確認

• 同名の構成アイテムが既にないことを、cmdb_ci_list.do の検索で確かめる

• 監視ツールが送ってくるノード名（node）と、構成アイテムの名前が同じ綴りであること

4. 手順（操作 → 期待結果 → 分岐）

1. サーバーの構成アイテムを作る（画面は未確認）。クラスは Linux Server（cmdb_ci_linux_server）、名前は監視ツールのノード名と同じにする。対象は ec-web-01、ec-web-02、ec-app-01、ec-db-01、hr-file-01 の5台。Support group に担当グループ（DB なら Database）を入れる。期待結果：保存でき、一覧に出る。分岐：名前が既存と重複したら、保存を中止して依頼票へ戻す

2. ロードバランサー ec-lb-01 を cmdb_ci_lb、MySQL インスタンス ecpay-mysql を cmdb_ci_db_mysql_instance で作る（ecpay-mysql は ec-db-01 の上で動く関係にする）。期待結果：2件が登録される

3. 業務サービスを、POST /api/now/cmdb/app_service/create で作る。サービス名と、関連づける構成アイテムを本文で渡す。本文の正確な形は PDI の実行ログに残っていないため、API の公式の説明で確かめて記入する ★。決済と無関係な hr-file-01 は、関連づけない。PDI では、Mapped Application Service が作られ、「6 CIs added to business service」が返った。期待結果：サービスに決済側の構成アイテムが関連づく。分岐：Calculated Application Service を作ると、関連づけが空のまま（svc_ci_assoc が空）だった。その場合は削除して、Mapped で作り直す

5. 結果確認と証跡：サービスの関連構成アイテムの一覧を開き、決済側の構成アイテムの名前を1つずつ作業記録に写します。PDI で関連づいた6件の内訳は、実行ログに名前が残っていません。自社の環境で一覧を確かめてください。

6. 中止条件と連絡先：ノード名の綴りが監視ツールと一致しない場合は登録を中止し、監視設計担当へ連絡します。夜間と休日は、第1章の連絡先に従います。

7. 切り戻しと後片付け：作ったレコードの sys_id を作業記録に残し、取り消すときは作成順の逆に削除します。

手順(2) 相関ルールを作る

PDI では、相関ルールを REST で作成しました。親は ec-db-01、子は AP・Web・LB、時間窓は15分です。動作は手順(4)で確かめています。画面での入力操作は未確認です。

1. 目的と契機：同じ障害から届く警報を、原因の CI のアラートの子としてまとめるルールです。要件(1)に対応します。新しい障害の型が加わったときに実施します。

2. 前提・ロール・承認：evt_mgmt_admin。承認済みの依頼票。親にする CI と、子にする CI の一覧、時間窓（15分 ★）。

3. 事前確認：Alert Correlation Rules（em_alert_correlation_rule）の一覧で、同じ対象の既存ルールがないことを確かめます。標準で入っているルールは、各社のコネクタ用のものが中心です。自作のルールを名前で区別できるよう、名前の先頭を「自作:」のような識別子で始めます。

4. 手順（操作 → 期待結果 → 分岐。画面の項目名は標準のフォームに基づく未確認の記述）

1. Alert Correlation Rules の一覧で New を押す。名前を入れ、Order（実行順）を決める。期待結果：フォームが開く

2. 親になるアラートの条件を node=ec-db-01 で入れる。子の条件は、ec-app-01、ec-web-01、ec-web-02、ec-lb-01 のノードを、OR で並べて入れる。時間窓は15分にする。期待結果：親と子の条件が保存される。分岐：親の条件が広すぎる（node を絞っていない）と、無関係なアラートまで子になる。絞って保存し直す

3. 保存して、Active が true であることを確かめる。期待結果：一覧に新しいルールが true で出る。分岐：false のままなら、フォームで Active にチェックを入れ直す

4. 作業記録に、ルール名・親の条件・子の条件・時間窓を写す

記入例（モデル案件の相関ルール。値は架空）

ルール名: 自作: 決済DBの障害を親にまとめる ★
Active: true ／ Order: 40
親の条件: node=ec-db-01
子の条件: node=ec-app-01, ec-web-01, ec-web-02, ec-lb-01
時間窓: 15分 ★

5. 結果確認と証跡：上の画像のように、①の行が true で出ること。②の Order で、他のルールとの実行順を確かめます。

6. 中止条件と連絡先：親の条件を絞れない場合は保存を中止し、監視設計担当へ連絡します。夜間と休日は、第1章の連絡先に従います。

7. 切り戻しと後片付け：作成を取り消すときは、Active を false にします。手順(4)の試験へ進む場合は、true のまま残します。

手順(3) アラート管理ルールを作る

PDI では、条件 source=EC-Monitor^severity=1^parentISEMPTY^incidentISEMPTY^maintenance=false のルールを REST で作成しました。DB のアラートからインシデントが作られる結果は、手順(4)で確かめています。標準の Create Incident 系のルール3つは、既定で無効のまま入っています。画面での入力操作は確かめていません。

1. 目的と契機：重大（Critical）な親アラートから、担当グループ付きのインシデントを自動作成します。要件(2)に対応します。

2. 前提・ロール・承認：evt_mgmt_admin。この PDI では Store アプリ AIOps Experience の導入が必要でした（手順(11)）。担当グループ（Database）と、インシデントのテンプレートの値。

3. 事前確認：Alert Management Rules の一覧で、同じ目的のルールがないことを確かめます。標準の Create Incident 系3つは active が false です。対象は Create Incident、Create Incident for Primary Alert、Create Incident on Primary Critical Alert。有効なのは、手動で起票する Create Incident Manually です。

4. 手順（操作 → 期待結果 → 分岐。画面の項目名は標準のフォームに基づく未確認の記述）

1. Alert Management Rules（em_alert_management_rule）の一覧で New を押す。名前を入れる

2. 条件を、source=EC-Monitor、severity=1（Critical）、parent が空、incident が空、maintenance=false で組む。期待結果：まだインシデントがなく、メンテナンス中でない、親または単独の Critical アラートが対象になる。分岐：Type（アラートの種別）を条件に使うときは、表示名で書くと一致が0件になります。エラーも出ません。参照の値（sys_id）で指定します

3. アクションに、インシデントの作成を追加し、テンプレートに assignment_group=Database、category=database、state=2 を入れる。期待結果：アクションが1件付く

4. 保存して、Active が true で、エラーメッセージが空であることを確かめる。分岐：ルールを先に保存し、アクションを後から付けると、Active が false になりました。エラーには「No active actions」が出ます。アクションが付いた後で、Active にチェックを入れ直します

記入例（モデル案件のルール。値は架空）

ルール名: 自作: 決済サービスの重大なアラートを自動でインシデント化 ★
条件: source=EC-Monitor ^ severity=1 ^ parent 空 ^ incident 空 ^ maintenance=false
アクション: インシデント作成
テンプレート: assignment_group=Database ^ category=database ^ state=2
Active: true ／ エラーメッセージ: 空

結果の注意：PDI で作成されたインシデントには、テンプレートのうち assignment_group（Database）だけが反映されました。category は inquiry、state は New のままです。category と state が要件であれば、解消して再び確かめるまで、構築を完了にしません。

適用範囲の注意：この条件は、送信元と重大度で絞っています。同じ送信元の決済と無関係な Critical も、一致する可能性があります。対象を決済のサービスに限る場合は、node や構成アイテムの条件を足します ★。無関係な Critical が起票されないことの試験は、PDI では実行していません。手順(4)で、自社の環境で試験を追加します。

5. 結果確認と証跡：作成したルール自身の行で、Active が true、エラーメッセージが空であることを、作業記録に写します。上の画像の①②③は、一覧の見方の例です。ルールの動作は、手順(4)の試験イベントで確かめます。

6. 中止条件と連絡先：条件をテスト用のレコードで確かめられない場合は、本番へ移送せず、ITOM 管理者へ相談します。夜間と休日は、第1章の連絡先に従います。

7. 切り戻しと後片付け：作成を取り消すときは、Active を false にする。手順(4)の試験へ進む場合は、true のまま残す。標準のルールを有効にした場合は、作業前の Active（false）へ戻す。

手順(4) 試験イベントで起票と自動解決を確かめる

PDI で、決済障害のイベントを同じシナリオで3回流し（画面は3回目）、操作1から操作6を実行しました。操作7の片付けは、PDI では実行していません。

1. 目的と契機：手順(2)と手順(3)のルールが、期待どおりに動くことを確かめる手順です。要件(1)(2)(4)に対応します。ルールを作った後、または変えた後に実施します。

2. 前提・ロール・承認：evt_mgmt_integration（イベントの送信）と、結果を見るためのロール。試験用の source 名（EC-Monitor と同じ名前にするか、別名にして条件を合わせる）。送信先は検証環境です。本番へ試験イベントを送りません。

3. 事前確認：Express List で、試験に使うノードのアラートが開いていないこと。試験の開始時刻（JST）を作業記録に書きます。

4. 手順（操作 → 期待結果 → 分岐）

送信は POST /api/global/em/jsonv2 で行います。認証は自社の方式で、認証情報は手順書に書きません ★。

本文は、次の形でイベントを並べます。項目は、PDI で送ったものと同じです。本文の正確な書式は PDI の実行ログに残っていないため、公式の説明で確かめます。

{"records": [
  {"source": "EC-Monitor", "node": "ec-db-01", "type": "DB Connection",
   "resource": "threads_connected", "message_key": "ecpay_db_conn",
   "severity": "1", "description": "MySQL 接続数が上限に到達"}
]}

障害・再送・回復のキーの対応は、次のとおりです。

• 障害：ec-db-01、message_key ecpay_db_conn、severity 1

• 再送：障害と同じ message_key で、同じ内容を送る

• 回復（Clear）：障害と同じ node・type・resource・message_key で、severity を0にして送る

1. 無関係な警告を1件送る。ノードは hr-file-01、severity は4（Warning）。期待結果：アラートが Low のまま1件できる。インシデントはできない

2. DB の障害のイベントを1件送る。期待結果：応答は200で、「1 events were inserted」が返る

3. 待機の上限（5分 ★）まで、Alerts の一覧を見る。期待結果：DB のアラートが Open で、incident の欄に番号が入る。PDI の実測は、イベントの受信からインシデントの作成まで、3回で16〜20秒でした（3回目は16秒）。分岐：上限までにインシデントが空なら、手順(11)へ進み、本番への切り替えを保留する

4. 子になる警報を送る。AP・Web2台・LB の4件で、severity は2または3。期待結果：4件とも DB のアラートの子（parent が親の番号）になる。インシデントは、DB の1件だけで、増えない。分岐：子が親にならない、またはインシデントが2件以上できたら、手順(2)の条件を見直し、本番への切り替えを保留する

5. 障害と同じ message_key のイベントを再送する。期待結果：アラートは増えず、Overall Event Count が増える

6. 回復（Clear）を、DB・AP・Web・LB の分だけ送る。期待結果：アラートが Closed になり、関連インシデントが Resolved（state 6）になる。PDI の実測は、回復の送信から Resolved まで、3回で6〜8秒でした（3回目は7秒）。解決メモ（close_notes）に「Closed the task associated with alert」が残ります。分岐：待機上限を過ぎても Resolved にならなければ、手順(12)へ進む

7. 試験データを片付ける。試験用のアラート、イベント、インシデントの番号を作業記録に写し、検証環境の掃除手順（自社で定める ★）に従って閉じるか削除する。この手順は PDI では未実行で、警告のアラート Alert0010034 は Open のまま残っています

合否は、次の3つがすべてそろったときに「合格」とします。

• 親子の関係：子4件の parent が、DB のアラートの番号になっている

• 起票の件数：インシデントが DB の1件だけで、担当グループが Database

• 最終状態：アラートが Closed、インシデントが Resolved

自社の環境で足す試験：決済と無関係な Critical（例：hr-file-01、severity 1）を送り、インシデントが作られないことを確かめます。条件に決済側の限定を足した場合の確認です。PDI では実行していません ★。

5. 結果確認と証跡：上の画像で、①のアクティビティと、②の State を確かめます。時刻は JST で作業記録に写します。

6. 中止条件と連絡先：試験イベントの source が本番の監視ツールの名前と重なっている場合は、本番のアラートと混ざるため、送信を中止します。連絡先は第1章に従います。

7. 切り戻しと後片付け：試験用のルールは、本番へ移送しないものなら Active を false にします。プロパティを一時的に変えた場合は、元の値へ戻したことを作業記録に書きます。

3. 日次と月次の定常手順

この章で決めること：当番が1日のうちに見る画面と押すボタン、ITOM 管理者が月に1回行う棚卸し。

当番の1日は、次の順で進みます。手順の番号は、実行する節を指します。

• 当番の開始時：Express List を開き、Urgent のアラートを確かめる（手順(5)）

• 警報の通知を受けたとき：該当のアラートを開き、Acknowledge する（手順(5)）。インシデントができていれば点検する（手順(6)）

• 日次：優先度グループが Low のアラートを確認して閉じる（手順(7)）

• 引継ぎ：未回復のアラートと、手で設定した項目を、作業記録に書いて次の当番へ渡す

手順(5) 当番が Express List で Urgent を確認し、Acknowledge する

PDI で、Express List を開き、DB のアラートを Acknowledge して、結果を確かめました。

1. 目的と契機：発生中のアラートのうち、優先度グループ Urgent を見つけ、着手したことを記録する手順です。要件(5)に対応します。当番の開始時と、警報の通知を受けたときに行います。

2. 前提・ロール・承認：evt_mgmt_operator。Service Operations Workspace の左メニューから Express List が開けること。

3. 事前確認：Express List の上部が Active alerts で、フィルタに State の Open が入っていること。

4. 手順（操作 → 期待結果 → 分岐）

1. SOW の左メニューから Express List を開く。期待結果：発生中のアラートが、優先度グループの順に並ぶ

2. 優先度グループ Urgent のアラートを探す。分岐：Urgent が0件なら、正常です。手順(5)はここで終了し、作業記録に「Urgent 0件」と時刻を書く。件数があるのに優先度の列が空の場合は、フィルタの条件、対象のアラート、優先度の計算（evt_mgmt.top_priority_group_threshold）の順に確かめる

3. Urgent のアラートの番号の横に ▼ があれば押して、子を展開する。期待結果：親アラートの下に、まとめられた子が並ぶ。PDI のデモでは、決済 DB の親の下に子4件が出た。件数は障害ごとに異なる

4. 親アラートの番号を開く。期待結果：重大度、優先度グループ、インシデントの番号が上段に並ぶ

5. Acknowledge を押す。PDI では、クラシック画面のフォーム上部の Acknowledge ボタンから押した（実行済み）。期待結果：Acknowledged がオンになる（PDI で確認済み）。分岐：ボタンの位置は、クラシック画面と SOW で異なる。見つからなければ、アラートのフォーム上部のボタンを確かめる

6. 作業記録に、警報の通知を受けた時刻（または Express List で Urgent を見つけた時刻）と、Acknowledge した時刻を JST で写す。差が5分以内なら、要件(5)を満たす

5. 結果確認と証跡：親のアラートで、①の Acknowledged がオンになることを確かめます。②の Task にはインシデントの番号が入る。1枚目の画像の②では、優先度グループの列が Urgent で並ぶ点も見ます。

6. 中止条件と連絡先：優先度の列が空のまま、確かめても直らない場合は、ITOM 管理者へ連絡する。重大なアラートがあるのにインシデントが作られない場合は、手順(11)へ進む。夜間と休日は、第1章の連絡先に従う。

7. 切り戻しと後片付け：誤って Acknowledge したときは、フォームで Acknowledged をオフに戻し、作業メモに理由を書きます。この取り消し操作は、PDI では実行していません。

手順(6) 自動作成されたインシデントを点検する

PDI で、自動作成されたインシデント2件の項目を確かめました。impact の手動設定は、実行していません。

1. 目的と契機：自動作成のインシデントに、元のアラート、担当、優先度が入っていることの確認です。要件(2)と要件(7)に対応します。インシデントが自動で作られたときに行います。

2. 前提・ロール・承認：ITIL 相当のロール。インシデントを開ける画面（SOW またはクラシック）。

3. 事前確認：Express List で、親アラートの上段にインシデント番号が出ていること。

4. 手順（操作 → 期待結果 → 分岐）

1. インシデントを開く。期待結果：説明欄に「Critical alert [アラート番号] . Created on CI: [ec-db-01]」と、メッセージが入っている

2. Origin（右側の欄）を見る。期待結果：元のアラートの番号、優先度グループ、重大度、構成アイテムが出る。アラートの番号を押すと、元のアラートへ移る（要件(7)の1クリック）

3. 担当グループを見る。期待結果：Database が入っている（テンプレートの assignment_group）

4. 優先度、影響度、緊急度を見る。PDI の実測は、1回目が影響度1・緊急度1・優先度1、2回目と3回目が影響度3・緊急度1・優先度3でした。作成処理（EvtMgmtIncidentHandler）は、影響度を明示的に設定しません。緊急度は、重大度が1か2のときに、その値が入ります。作成時の影響度が実行ごとに異なった原因は、確かめていません。分岐：優先度が業務の基準（★）より低ければ、影響度を手で設定して保存する。設定後に優先度が再計算されることは、PDI では未実行

5. 作業記録に、インシデント番号と元のアラート番号と優先度を写す

5. 結果確認と証跡：①②の項目を確かめます。影響度は、1回目だけ異なっていました。

6. 中止条件と連絡先：担当グループが空、または Origin が空のインシデントは、本番でも当番が一次受付として保持します。当番が担当グループ（夜間と休日はオンコール）へ引き継ぎます。Event Management の設定の不備は、第1章の連絡先へ連絡してください。応答期限（30分 ★）の間は、当番が内容を確かめて対応を続けます。

7. 切り戻しと後片付け：手で設定した影響度は、作業メモに変更前と変更後の値を書きます。

手順(7) 日次：警告アラートの確認とクローズ

PDI では実行していません。モデル案件の要件(3)と、Express List の表示（手順(5)）から書いた手順です。

1. 目的と契機：決済と無関係な警告（Warning と Minor の単独）を、インシデントにせず、1日1回まとめて確認します。要件(3)に対応します。

2. 前提・ロール・承認：evt_mgmt_operator。閉じる判断は運用当番の主担当が行い、承認は要りません（第5巻の運用ルールどおり）。

3. 事前確認：毎営業日10時までに実施する。前日0時以降に作られた Warning と Minor の単独アラートが対象です。Express List の優先度グループが Low で、親とインシデントが空のものを選びます。決済サービスの CI（ec-lb-01、ec-web-01/02、ec-app-01、ec-db-01）のアラートは、優先度グループにかかわらず、気づいてから30分以内に確かめる。

4. 手順（操作 → 期待結果 → 分岐）

1. Express List で優先度グループの Low に絞る。期待結果：決済と無関係な警告が並ぶ。PDI では、hr-file-01 のディスク使用率の警告が Low のまま残りました

2. 各アラートについて、監視ツール側で回復していることを確かめる。期待結果：回復の通知を受けたアラートは、すでに Closed になっている

3. 回復していないものは、担当の運用チームへ連絡し、作業メモに連絡先と時刻を書く

4. 決済サービスの CI に紐づくアラートは、閉じずに手順(13)で手動のインシデントにする。決済と無関係で、(a) 監視ツールの画面または運用チームの連絡で回復を確認したものだけを Close する。承認は要らない。期待結果：State が Closed になる

5. 結果確認と証跡：Low の件数と、閉じたアラートの番号を作業記録に書きます。同じアラートが3営業日続いたときは、監視設計担当へしきい値の見直しを依頼します（日数は運用設計書の値 ★）。

6. 中止条件と連絡先：Low のアラートに Urgent が混ざっていたら、手順(5)へ戻ります。

7. 切り戻しと後片付け：回復を確認する前に閉じたことに気づいたら、閉じた番号と時刻を作業記録に書き、運用当番の副担当へ引き継ぎます。副担当は、そのノードの監視を続け、同じキーのアラートが再び出るかを、アラート一覧で確かめてください。プロパティの説明によると、閉じてから evt_mgmt.active_interval（PDI の値は14400秒、4時間）の間に同じキーのイベントが届けば、アラートは開き直されます。ただし、この動作は PDI で未確認です。

手順(8) 月次：ルールの棚卸し

PDI では実行していません。画面で確かめられる項目から書いた手順です。

1. 目的と契機：自動起票に関わるルールと自動化が、承認済みの状態かを、月1回確かめます。要件(6)に対応します。

2. 前提・ロール・承認：evt_mgmt_admin。Alert Correlation Rules と Alert Management Rules を開けること。承認済みのルールの一覧（名前、Active、変更日）★。

3. 事前確認：先月の作業記録から、承認済みのルールの一覧を取り出します。

4. 手順（操作 → 期待結果 → 分岐）

1. Alert Management Rules の一覧を開き、Active の列を、承認済みの一覧と比べる。期待結果：Create Incident 系の標準3つは false、手動で起票する Create Incident Manually は true（標準）、自動起票の自作ルールは承認済みの値と同じ。分岐：一覧にないルールが true になっていたら、手順を止めて、変更履歴で作成者を調べる

2. 相関ルールの一覧を開く。期待結果：自作のルールが承認済みの状態で、Order が想定どおり

3. SOW の Alert automation 画面（左メニュー）を開き、Automation types の Ignore・Enrich・Group・Respond の一覧で、承認済みの一覧にない有効なルールがないことを確かめる

4. 自動起票のルールについて、実行の記録を見る。アラート管理ルールの実行履歴は em_alert_management_execution に残る。期待結果：その月に対象のアラートがあったなら、実行が記録されている。分岐：実行の記録がなければ、まず対象のアラートがその月にあったかを確かめる。次に、アラートが条件に一致するか、ルールが評価された記録があるか、アクションが実行されたかを、この順に確かめる。評価の記録は、条件の不一致でも残る場合がある。それでも説明できなければ、手順(11)へ

5. 差分（先月と違うもの）を作業記録に書く

5. 結果確認と証跡：①の4種類を1つずつ開き、件数と②の Active を作業記録に残します。

6. 中止条件と連絡先：先月から意図せず変わった Active があれば、棚卸しを止め、変更履歴を調べます。連絡先は第1章に従います。

7. 切り戻しと後片付け：誤って変えた Active は、作業記録の前回の値へ戻します。

手順(13) Quick Incident で手動のインシデントを作る

PDI で、アラートのフォームの Quick Incident から手動のインシデント INC0010055 を作りました。CI（lnux100）と緊急度は入り、影響度は 3 でした。影響度の手動設定と、重大度2の運用は、PDI では実行していません。

1. 目的と契機：自動起票の対象外のアラートを、運用当番が手動でインシデントにする手順です。重大度2（Major）の親アラートは、見つけてから15分以内に行います。手順(7)で、決済サービスの CI に紐づく Warning と Minor を見つけたときにも行います。

2. 前提・ロール・承認：evt_mgmt_operator とインシデントを作れる ITIL 相当のロール。承認は要りません。

3. 事前確認：対象のアラートの incident と Task の欄が空であること（すでにインシデントがあれば作らない）。

4. 手順（操作 → 期待結果 → 分岐）

1. 対象のアラートをクラシック画面で開く。期待結果：アラートのフォームが開く

2. Quick Incident を押す。期待結果：インシデントが作られ、アラートの Task にインシデント番号が入る。PDI では、CI と緊急度が引き継がれ、影響度は 3 だった。分岐：作られない場合は、ロールを確かめ、手順(11)へ進む

3. インシデントを開き、影響度と優先度を、運用設計書の判定表（重大度2は影響度2 ★）に合わせて設定して保存する。期待結果：優先度が再計算される（PDI では未実行）

4. 担当グループを入れて引き継ぐ。平日9時から18時は担当グループの当番へ、夜間と休日はオンコール1名を呼び出す

5. 作業記録に、アラート番号、インシデント番号、作成した時刻、引継ぎ先を書く

5. 結果確認と証跡：アラートの Task にインシデント番号が入ること。インシデントの説明欄から元のアラートへたどれること。

6. 中止条件と連絡先：すでにインシデントが紐づいているアラートでは作らず、そのインシデントへ引き継ぐ。ボタンが見つからない、またはロールが足りない場合は、第1章の連絡先へ連絡する。

7. 切り戻しと後片付け：誤って作ったインシデントは、作業メモに理由を書いて閉じ、作業記録に番号を残す。

有料エリアの内容

この先は次の4つで、約10,000字です。

手順(10)から手順(12)は、症状を実際に起こして、見る場所の順を確かめました。手順(9)は PDI では実行しておらず、画面と公式ドキュメントから書いています。

• 定常：手順(9)（メジャーアップグレード後の確認）

• 障害時：手順(10)（イベントが Error になる）、手順(11)（インシデントが作られない）、手順(12)（アラートとインシデントの終了連動不良）

• 作業記録の書式（記入例・記入様式（コードブロック）・値の決め方）

• 付録：画面・権限が異なる場合の確認先、公式ドキュメント、検証範囲

各手順は、目的と契機・前提・事前確認・手順・結果確認・中止条件・切り戻しの7項目で書いています。

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