Event Management モジュールの運用設計書

Event Management は、監視ツールの警報をまとめてインシデントにするところまでを自動で行います。自動化の外側に残るのは、誰が5分以内にアラートを確認し、誰が優先度を決め、ルールの変更を誰が承認するかという判断です。この設計書は、架空のモデル案件について、その判断を運用ルール10件で定めます。

この設計書で決めること

• 受付・Acknowledge・引継ぎ・クローズの流れと、各段階の担当と期限

• 自動起票されたインシデントの優先度を、誰がいつ確かめるか

• ルールの追加・変更を、検証環境での試験と承認を経て本番へ移す手順

• Event Management 自身の処理異常を、何を見て、誰へ知らせるか

• 月次の指標と、値を自社用に置き換えるときの記入例・記入様式・判断基準

組織・人数・時間・期限は、すべて架空のモデル案件の要件から決めた値です。Brazil PDI で確かめたのは、標準機能でこの設計を実現できるかどうかまでです。PDI の件数や処理時間から、運用の期限や体制は決めていません。

1. はじめに

この章で決めること：何を、どの体制と分担で運用するか。

1.1 目的と対象範囲

この設計書の目的は、Event Management が受け取った警報を、人が判断すべき箇所で確実に判断できる状態に保つことです。第2章の7つの業務要件を、運用の側から満たすことを到達条件にします。

• 対象環境：本番インスタンスの Event Management と、ルールを本番へ移す前の検証環境

• 対象の機能：イベントの受信、アラート、相関ルール、アラート管理ルール、Express List（優先度順のアラート一覧）、インシデントへの自動起票

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

操作の手順は「Event Management モジュールの運用手順書」にあります。この設計書は、組織が何を決めるかだけを書きます。

1.2 読み方・用語・文体

用語

• イベント：監視ツールから届く1件の通知

• アラート：イベントから作られる、対応対象の記録

• 親アラート・子アラート：相関ルールでまとめた関係。原因側が親、巻き込まれた警報が子

• 優先度グループ：アラートを4つに分けて一覧の上に出す区分。最上位が Urgent

• 運用当番：サービスデスクを兼ねる当番。アラートを最初に受ける

• 担当グループ：インシデントの割り当て先。モデル案件では Database と Web/AP

• Clear：監視ツールが送る回復通知（severity 0）

文体

決定事項は常体で言い切ります。説明の文は「です・ます」で書きます。

識別子

要件は番号付きの名前、運用ルールは OR で始まるID、未決事項は OI で始まるIDを持ちます。本文では名前で呼び、IDは見出し、分担の一覧、未決事項の一覧でだけ使います。

根拠の表示

製品の挙動を書いた行には、次のラベルを付けます。

• ［実測］PDI で操作して確かめた

• ［公式］製品同梱の説明か公式ドキュメントにある

• ［未確認］確かめていない

確かめ方には、状態を［実施済み］［未実施］で付けます。

1.3 モデル案件

架空のネットショップ「EC サイト」の想定です。業務サービス「オンライン決済サービス」（重要度は最上位）が動きます。構成はロードバランサー1台、Web 2台、AP 1台、DB 1台（MySQL）です。決済と無関係な社内ファイルサーバーも、同じ監視ツールの対象です。既存の監視製品（仮称 EC-Monitor）が、REST でイベントを Event Management に送ります。

• 運用当番：24時間365日、常時2名。平日9:00〜18:00は4名

• DB チーム（グループ Database）：平日9:00〜18:00。夜間と休日はオンコール1名が、呼び出しから30分以内に着手する

• Web/AP チーム：平日9:00〜18:00。夜間と休日はオンコール1名

• 監視設計担当：ITOM 管理者（evt_mgmt_admin）。平日のみ、1名

• サービス責任者：決済サービスのオーナー。重大度1の第一報を受け、ルール変更を承認する

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

自社の値に置き換える箇所は、付録Cにまとめています。

1.4 運用コンセプト

運用の方針は次のとおりです。

• 標準を使う：標準の相関ルール、アラート管理ルール、プロパティで組む。スクリプトは書かない。その代わり、製品の更新後に標準の挙動が変わっていないかを毎回確かめる

• 自動化は人の判断の手前までにする：まとめる、起票する、回復で閉じるは自動で行う。優先度の最終確認、ルールの変更、権限の付与は人が行う

• 月次で見直す：起票数、子アラートの比率、誤起票を月次で見て、ルールとしきい値を見直す

1.5 体制と役割の分担

モデル案件の役割は4つです。運用当番、担当グループ、監視設計担当、サービス責任者が担います。運用ルールごとの分担を、ここで4つの記号の一覧にまとめ、1.6で役割ごとの仕事を詳しく書きます。

記号の意味は次のとおりです。

• R（Responsible・実行）：実際に作業を行う

• A（Accountable・承認）：承認し、結果に責任を持つ

• C（Consulted・相談）：実施の前に相談を受ける

• I（Informed・報告先）：実施の後に結果の報告を受ける

• OR-01 アラートの受付と Acknowledge：R＝運用当番の主担当／A＝なし（理由：Acknowledge は設定を変えない）／C＝なし／I＝副担当

• OR-02 自動起票されたインシデントの引継ぎ：R＝運用当番の主担当（Resolved 後の確認は担当グループ）／A＝なし（理由：担当グループが着手の可否を決める）／C＝担当グループ／I＝サービス責任者（重大度1のとき）

• OR-03 無関係・低優先度アラートの日次確認とクローズ：R＝運用当番の主担当／A＝なし／C＝監視設計担当／I＝なし

• OR-04 メンテナンス時間帯の扱い：R＝監視設計担当／A＝サービス責任者／C＝DB チーム・Web/AP チーム／I＝運用当番

• OR-05 処理異常の検知と初動：R＝運用当番／A＝なし／C＝監視設計担当／I＝サービス責任者

• OR-06 重大障害時のエスカレーション：R＝運用当番／A＝サービス責任者／C＝担当グループ／I＝監視設計担当

• OR-07 ルールの追加・変更の承認と移送：R＝監視設計担当／A＝サービス責任者／C＝担当グループ／I＝運用当番

• OR-08 ノイズの見直し：R＝監視設計担当／A＝サービス責任者／C＝運用当番／I＝担当グループ

• OR-09 メジャーアップグレード時の確認：R＝監視設計担当／A＝サービス責任者／C＝運用当番／I＝担当グループ

• OR-10 ロールの付与と棚卸し：R＝監視設計担当（棚卸しの照合は、運用当番の保有は監視設計担当、監視設計担当の保有はサービス責任者）／A＝サービス責任者／C＝なし／I＝対象者の上長

同じ案件で兼ねてはいけない組み合わせ

1. 実行と承認（監視設計担当が自分の変更を承認しない）

2. ロールの付与で、対象者本人による実行

3. 棚卸しで、ロールの保有者本人による照合

1.6 役割ごとの仕事

1.5の分担を、役割ごとの仕事として書き直します。使う画面は4つです。Express List（優先度順のアラート一覧）、アラートのフォーム、インシデントのフォーム、ルールのフォームを使います。ServiceNow のロールは、この設計書で付与を決めるものだけを書きます。

図の内容を文字でも書き出します。

• 受付：自動＝アラートを作り、親子にまとめる／運用当番＝Express List で Urgent を受ける

• Acknowledge：運用当番＝5分以内に Acknowledge する

• 起票：自動＝Critical の親だけ、1分以内に起票する／運用当番＝重大度と優先度を5分以内に確認する／サービス責任者＝重大度1は15分以内に第一報を受ける

• 引継ぎ：運用当番＝担当グループへ連絡し、夜間と休日はオンコールを呼び出す／担当グループ＝30分以内に着手する

• 回復：自動＝Clear で Resolved とし、アラートを閉じる／担当グループ＝復旧を確認する／サービス責任者＝重大度1の終了を宣言する

• クローズ：担当グループ＝翌営業日10:00までに、紐づくアラートが0件であることを確認する

• 月次見直し：監視設計担当＝第3営業日までに集計して報告する／サービス責任者＝報告を受けて承認する

• ルール変更：担当グループ＝依頼・相談／監視設計担当＝検証環境で試験して移送する／サービス責任者＝承認する。ルール変更の承認者は、サービス責任者1名とする

運用当番

• ServiceNow のロール：evt_mgmt_operator を持つ［公式：アラートを管理する（閉じる、確認するなど）］。インシデントの作成と更新には itil を使う（付与の実態は［未確認］）。ルールとプロパティを変えるロールは持たない

• 体制：24時間365日、常時2名で、主担当と副担当に分かれる。平日9:00〜18:00は4名

• 受付・確認：Express List で優先度グループ Urgent のアラートを受け、アラートのフォームで5分以内に Acknowledge する。決済サービスの CI のアラートは、優先度グループにかかわらず30分以内に確かめる

• 起票後の対応：インシデントのフォームで、重大度と優先度を5分以内に確かめる。Major の親アラートは、Quick Incident で15分以内に手動のインシデントにする（運用手順書の手順(13)）。担当グループへ連絡し、夜間と休日はオンコール1名を呼び出す

• 日次の仕事：毎営業日10:00までに Warning と Minor の単独アラートを確かめ、毎日9:00と30分ごとに処理の異常を確かめる

• 行わないこと：ルールとプロパティの変更、ロールの付与、決済と無関係な警告のインシデント化、重大度1の終了の宣言

担当グループ（DB チーム・Web/AP チーム）

• ServiceNow のロール：インシデントの対応に itil を使う（付与の実態は［未確認］）。Event Management のロールは付与しない

• 体制：どちらも平日9:00〜18:00。夜間と休日はオンコール1名で、呼び出しから30分以内に着手する

• 起票後の対応：引継ぎを受けたら、インシデントのフォームを開き、調査と復旧を始める。元のアラートは、インシデントから1クリックでたどる。調査と解決の運用は、インシデント管理の運用で決める

• 回復・クローズ：Resolved になったら、翌営業日10:00までに、紐づくアラートがすべて閉じていることを確認し、作業記録に書く

• ルール変更：ノイズ調査とルールの変更を、監視設計担当へ依頼する。変更の前に相談を受ける

• 行わないこと：アラートの Acknowledge とクローズ、ルールの変更

監視設計担当（ITOM 管理者）

• ServiceNow のロール：evt_mgmt_admin を持つ［公式：プロパティとルールを設定・構成できる］。コネクタ関連の4つのロール（読み取り・作成・更新・削除）も持つ。evt_mgmt_integration は、人ではなく監視ツールの連携用アカウントに付く

• 体制：平日のみ、1名

• ルール変更：相関ルールとアラート管理ルールのフォームで、検証環境で試験し、承認の後に火曜から木曜の10:00〜16:00に本番へ移送する。メンテナンス計画は、金曜17:00までに運用当番へ渡す

• 月次の見直し：第3営業日までに、起票数、子アラートの比率、誤起票を集計して、サービス責任者へ報告する

• そのほかの仕事：メジャーアップグレード時の確認、ロールの付与と剥奪、平日の ServiceNow への問い合わせ

• 行わないこと：自分の変更の承認、承認の前の本番でのルール変更、自分が持つロールの照合、夜間と休日の対応

サービス責任者

• ServiceNow のロール：Event Management のロールは持たない運用とする。承認は、依頼票と報告への返答で記録する。インシデントを画面で見るために itil が要るかは［未確認］

• 体制：決済サービスのオーナー1名。不在時は、事前に指名した代行者が承認する

• 起票後の対応：重大度1の第一報を、インシデントの作成から15分以内に電話で受ける。以後、30分ごとの報告を受け、サービスの復旧を確認したら終了を宣言する

• ルール変更・月次の見直し：ルール変更を受付から3営業日以内に承認する。月次報告を受けて、改善する項目の担当と期限を決める。ロールの付与とメンテナンス計画も承認する

• 行わないこと：アラートとルールの操作、自分が実行した作業の承認

1.7 窓口と代行

• 窓口：運用当番（サービスデスク）。電話とチャットで24時間365日受け付ける

• 連絡先の正本：情報システム部の連絡先台帳。電話番号は台帳を参照する

• 代行：サービス責任者の不在時は、責任者が事前に指名した代行者が承認を担う。代行者は同じ案件で実行を兼ねない。監視設計担当の不在時は、平日でもルール変更を延期し、受付と引継ぎだけを続ける

1.8 インスタンス運用方針

• 本番：監視ツールのイベントを受け、インシデントを作るインスタンス。アラートにはホスト名やサービス名が含まれる。ここでの作業は、承認を受けたルールの移送と、取り下げに限る

• 検証環境：ルールの試験に使う。試験は模擬イベント（送信元名は EC-Monitor と区別する）だけで行う

• 特権：evt_mgmt_admin は、ルールとプロパティを変更できる特権として扱う。付与と棚卸しは「ロールの付与と棚卸し」で決める

1.9 検証範囲

• 検証は Brazil PDI 1インスタンスで行った。運用当番の5分以内の Acknowledge、ルール変更の承認と移送、メンテナンス時間帯の除外、メジャーアップグレード後の確認は、PDI では実演していない

• 運用ルールの期限と体制は、モデル案件の要件から決めた架空の値。PDI の処理時間や件数から決めていない

• 公式ドキュメントは Australia 版を参照した。Brazil 版との差は確かめていない

• 検証中に、evt_mgmt.alert_management_scoped_active などを一時的に変更し、すべて元の値に戻した

• メジャーアップグレード後に、プロパティやルールの値が保たれるかは確かめていない

2. 要件と運用ルールの対応

この章で決めること：どの要件を、どの運用ルールで満たすか。運用ルールをどの書式で書くか。

2.1 業務要件

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

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

• 要件(3) 無関係な警告は日次で確認する：決済と無関係な警告（Warning／Minor 単独）はインシデントにせず、運用当番が Express List で日次に確認する

• 要件(4) 回復で自動クローズする：Clear でアラートと紐づくインシデントを自動で Resolved にする。人の操作を要さない

• 要件(5) 5分以内の Acknowledge：運用当番は優先度グループ Urgent のアラートに5分以内に Acknowledge する

• 要件(6) ルール変更は承認を経る：相関とアラート管理のルールの追加・変更は、検証環境で試験してから本番へ移送し、承認を経る

• 要件(7) 1クリックでたどれる：インシデントから元のアラート、アラートから影響サービスへ、画面上で1クリックでたどれる

2.2 対応表

要件と運用ルールの対応は、ここだけに書きます。各運用ルールの本文には書きません。

• OR-01 アラートの受付と Acknowledge：要件(5)

• OR-02 自動起票されたインシデントの引継ぎ：要件(2)、要件(7)

• OR-03 無関係・低優先度アラートの日次確認とクローズ：要件(3)

• OR-04 メンテナンス時間帯の扱い：要件(2)、要件(3)

• OR-05 処理異常の検知と初動：要件(1)、要件(2)、要件(4)

• OR-06 重大障害時のエスカレーション：要件(2)

• OR-07 ルールの追加・変更の承認と移送：要件(6)、要件(1)

• OR-08 ノイズの見直し：要件(1)、要件(3)

• OR-09 メジャーアップグレード時の確認：要件(2)、要件(4)、要件(7)

• OR-10 ロールの付与と棚卸し：要件(6)

2.3 運用ルールの書式

運用ルールは、1つの判断を1つの節で完結させます。冒頭に対象を1〜2文で書き、次の項目をこの順で書きます。該当がない項目は「なし（理由：〜）」と書き、空欄にしません。

1. 条件：開始する条件と、そろっていなければならない情報

2. 判断基準・実施内容：どの場合にどうするか。実行しない場合の条件

3. 責任者：実行・承認（1.5の分担と同じ）

4. 期限

5. 証跡：残すものと記録先

6. 例外：実行しない・保留する場合と、その引継ぎ先

7. 見直しの契機

8. 確かめ方：条件、合格基準、状態

製品の挙動に依存するルールは、項目の前に「前提となる製品の挙動」を根拠ラベル付きで置きます。

3. 運用サービス設計

この章で決めること：運用チームが何を提供し、いつ受け付け、どの水準で返すか。

3.1 サービスメニュー

運用チーム（運用当番、監視設計担当）が提供するサービスは次のとおりです。

• 警報の受付：24時間365日。Urgent は5分以内に Acknowledge する

• ルールの追加・変更の依頼：平日のみ。依頼できるのは担当グループとサービス責任者。受付から3営業日以内に可否と反映日を返す

• ノイズ調査の依頼：担当グループが、同じ警報が多すぎると感じたときに出す。受付から2営業日以内に調査結果を返す

• ロール付与の依頼：受付から2営業日以内に可否を返す

3.2 対応時間

警報の受付は24時間365日です。ルール変更と調査は平日9:00〜18:00とします。期限は営業時間の経過で数え、18:00を過ぎた分は翌営業日の9:00から数え直します。

3.3 運用項目の一覧

• 定常（毎日）：日次確認（無関係・低優先度アラートの日次確認とクローズ）、処理異常の確認（処理異常の検知と初動）

• 定常（毎月）：ノイズの見直し、月次報告

• 定常（四半期）：ロールの棚卸し

• 障害対応：アラートの受付と引継ぎ、重大障害時のエスカレーション

• 保守：ルールの追加・変更、メジャーアップグレード時の確認、メンテナンス時間帯の登録

3.4 計画停止の事前通知

Store アプリの更新や、ルールの移送でイベント処理が一時的に遅れる計画作業は、作業の2営業日前までに、監視設計担当が担当グループへ通知します。ServiceNow 側の計画メンテナンスは、通知を受けた運用当番が同日中に監視設計担当へ回し、監視設計担当が担当グループへ伝えます。

4. 業務運用

この章で決めること：受付から引継ぎ、日次の確認までの、担当・条件・期限。

4.1 受付からクローズまでの流れ

1. 運用当番が Express List で、優先度グループ Urgent のアラートを受ける

2. 運用当番が5分以内に Acknowledge する

3. アラート管理ルールが、重大な親アラートだけを自動でインシデントにする

4. 運用当番が優先度を確かめ、担当グループへ引き継ぐ。夜間と休日はオンコールを呼び出す

5. 監視ツールの回復通知で、アラートとインシデントが自動で閉じる

6. 担当グループが Resolved を確認する。月次でノイズを見直す

OR-01 アラートの受付と Acknowledge

優先度グループ Urgent のアラートを、運用当番が5分以内に Acknowledge するルールです。Acknowledge は、人が見たことを記録する印です。

前提となる製品の挙動

• ［実測］Express List は、優先度グループ Urgent の親アラートと子アラートを上にまとめて表示する

• ［実測］アラートのフォームに Acknowledge のボタンと Acknowledged のチェック、起票されたインシデントの Task 項目がある

• ［実測］クラシック画面の Acknowledge ボタンで親アラートを確認済みにすると、Acknowledged がオンになった。このデモでは5分以内の運用としては実演していない

• ［公式］優先度グループは、計算された優先度を4つのカテゴリに分けてリストの上に表示する

• ①の枠：親アラートと、その下にまとまった子アラート。決済サービスの CI に紐づくアラートが並ぶ

• ②の枠：Priority の列。Urgent は最上位のグループ

• ①の Acknowledge：ボタンを押すと、運用当番が確認済みにできる

• ②の Acknowledged：確認済みのときにチェックが入る。画面は Acknowledge を押す前の状態

• ③の Task：自動起票されたインシデントの番号が入る。Acknowledge の時刻が更新履歴に残るかは確かめていない［未確認］

項目

• 条件：Express List に優先度グループ Urgent のアラートが現れたとき。送信元が EC-Monitor のアラートを対象にする

• 判断基準：運用当番の主担当が内容を読み、親アラートを先に Acknowledge する。子アラートは、親の Acknowledge の後に確認すれば足りる

• 責任者：実行＝運用当番の主担当。承認＝なし（理由：Acknowledge は設定を変えず、起票の可否を決めないため）

• 期限：Urgent のアラートが現れてから5分以内。5分を過ぎても Acknowledge がない場合、副担当が代わりに行い、10分を過ぎたら、平日9:00〜18:00は監視設計担当へ、それ以外はサービス責任者（不在時は代行者）へ連絡する

• 証跡：アラートの Acknowledged のチェック。受付日時と担当者名を引継ぎ記録（付録B）に書く

• 例外：メンテナンス時間帯のアラートは「メンテナンス時間帯の扱い」に従う。同じアラートが連続して届く場合は、最初の1件だけ Acknowledge する

• 見直しの契機：月次報告で5分以内の遵守率が90%を下回る月が2か月続いたとき。運用当番の人数が変わったとき

• 操作の手順：運用手順書の手順(5)

• 確かめ方：条件＝検証環境で模擬イベントを送り、Urgent のアラートを作る。合格基準＝運用当番が Express List から開き、5分以内に Acknowledged が入る。［未実施］

記入例は付録Aにあります。

OR-02 自動起票されたインシデントの引継ぎ

アラート管理ルールが作ったインシデントを、運用当番が担当グループへ引き継ぐルールです。インシデント後半の調査と解決は、インシデント管理の運用で扱います。

前提となる製品の挙動

• ［実測］条件に合う親アラートから、受信後に数秒でインシデントが作られ、担当グループが入った。デモでは、DB 障害のイベントを受けてから16秒でインシデントができた（同じシナリオを3回流して16〜20秒）

• ［実測］インシデントの作成処理は impact を設定しない。デモの1回目は impact 1・優先度 P1、2回目と3回目は impact 3・優先度 P3 で、実行ごとに優先度が変わった。原因は未確認

• ［実測］ルールのテンプレートが反映するのは担当グループなどの項目で、状態は New のままだった

• ［実測］アラートのフォームの Quick Incident で、インシデントを手動でも作れた。CI と緊急度が入り、impact は3だった

項目

• 条件：自動起票でインシデントが作られたとき、または Major の親アラートを運用当番が見つけたとき。自動起票の時刻は、アラートの受信から1分以内になる設計とする

• 判断基準：運用当番の主担当は、インシデントの優先度を必ず確かめ、重大度を判定する（6.1）。重大度1は impact を1に揃えて優先度を P1 とする。重大度2は、自動起票されないため Quick Incident で手動のインシデントを作り（運用手順書の手順(13)）、impact を2に揃える。優先度が揃ったら、担当グループへ引き継ぐ。平日9:00〜18:00は担当グループの当番へ連絡し、夜間と休日はオンコール1名を呼び出す。着手は呼び出しから30分以内とする。インシデントが Resolved になったら、担当グループが翌営業日10:00までに、紐づくアラートがすべて閉じていることを確認し、作業記録に書く。Resolved への移行は自動で、人が行うのは確認だけとする

• 責任者：実行＝運用当番の主担当（Resolved 後の確認は担当グループ）。承認＝なし（理由：優先度の判断は実行者に任せ、担当グループが着手を判断するため）。相談＝担当グループ。報告先＝サービス責任者（重大度1のとき）

• 期限：インシデントの作成（Major は手動で作成した時点）から5分以内に優先度を確かめて引き継ぐ。オンコールの着手は呼び出しから30分以内。Resolved 後の確認は翌営業日10:00まで

• 証跡：インシデントの優先度の確認結果、引継ぎ日時、引継ぎ先。記録先は引継ぎ記録

• 例外：オンコールが30分以内に着手しない場合は、運用当番が DB チームのリーダー、または Web/AP チームのリーダーへ連絡する。それでも着手しない場合は、「重大障害時のエスカレーション」の着手遅延の判断に進む

• 見直しの契機：自動起票の優先度のばらつきの原因が分かったとき。担当グループが増減したとき

• 操作の手順：運用手順書の手順(6)。重大度2は手順(13)

• 確かめ方：条件＝検証環境で模擬の障害イベントを送り、インシデントを作る。合格基準＝インシデントに担当グループが入り、運用当番が優先度を確かめた記録が残る。インシデントの作成と担当グループの設定は［実施済み］（運用手順書の手順(4)と手順(6)、PDI で3回）、優先度を確かめた記録は［未実施］

優先度を自動で揃える方法は、現時点では確かめていません。未決事項の一覧に載せ、決まるまでは運用当番が毎回確かめます。

OR-03 無関係・低優先度アラートの日次確認とクローズ

Warning または Minor の単独アラートを、運用当番が日次で確かめるルールです。決済サービスと無関係な警告は、インシデントにしません。

前提となる製品の挙動

• ［実測］社内ファイルサーバーの容量警告は、優先度が Low のままで、インシデントは作られなかった

• ［実測］自動クローズの間隔（evt_mgmt.alert_auto_close_interval）は 0 で、開いたアラートは自動では閉じられない

• ［公式］アラート管理ルールは、条件に合うアラートだけに処理を行う

項目

• 条件：毎営業日10:00までに、前日0:00以降に作られた Warning と Minor の単独アラートを Express List で確かめる。決済サービスの CI のアラートは、優先度グループにかかわらず、気づいてから30分以内に確かめる

• 判断基準：決済サービスの CI（ec-lb-01、ec-web-01/02、ec-app-01、ec-db-01）に紐づく場合は、運用手順書の手順(13)で手動のインシデントを作る。決済と無関係な場合は、クローズする。同じアラートが3営業日続く場合は、監視設計担当へしきい値の見直しを依頼する

• 責任者：実行＝運用当番の主担当。承認＝なし（理由：インシデント化の基準は要件で決まっており、実行者の判断に任せるため）。相談＝監視設計担当

• 期限：毎営業日10:00まで

• 証跡：クローズしたアラートの番号と件数、手動でインシデントにした番号。記録先は日次確認の記録

• 例外：休日は翌営業日にまとめて確認する。休日に決済サービスの CI のアラートが出た場合も、30分以内の確認を同じように行う

• 見直しの契機：同じ警告が週に5回以上出たとき。月次のノイズ見直しの結果

• 確かめ方：条件＝検証環境で、決済と無関係な警告と、決済サービスの CI の警告を1件ずつ送る。合格基準＝前者がクローズでき、後者が手動のインシデントになる。［未実施］

OR-04 メンテナンス時間帯の扱い

毎週日曜 2:00〜4:00 のメンテナンスで出るアラートを、インシデントにしないルールです。

前提となる製品の挙動

• ［実測］アラート管理ルールの条件に maintenance=false を含めた。Alert の画面には Maintenance のチェックがある

• ［実測］アラートのフォームに Maintenance のボタンがある

• ［未確認］対象 CI のメンテナンス登録でアラートに maintenance が付くこと、maintenance=true のアラートが実際にインシデントにならないこと

項目

• 条件：メンテナンス時間帯の前営業日（金曜）17:00までに、監視設計担当が翌週の計画を確認したとき

• 判断基準：監視設計担当が、メンテナンスの対象 CI と時間帯を、金曜17:00までに運用当番の引継ぎ記録に書き、対象 CI にメンテナンスの時間帯を登録する。運用当番は、時間帯の途中で Maintenance が付いていないアラートを見つけたら、アラートのフォームの Maintenance ボタンで付ける。時間帯が終わった4:00に、Maintenance が付いたまま Open のアラートを確かめる。4:30までに Open のまま残るものは、通常のアラートとして扱う。メンテナンス中に起票されたインシデントは、運用当番が確認し、不要なら Resolved にして作業記録に書く

• 責任者：実行＝監視設計担当。承認＝サービス責任者。相談＝DB チーム・Web/AP チーム

• 期限：金曜17:00までに計画を書く。確認は日曜4:30まで

• 証跡：メンテナンスの計画、対象 CI、時間帯。記録先は引継ぎ記録

• 例外：計画外のメンテナンスは、実施の前に運用当番へ連絡し、運用当番が引継ぎ記録へ追記する

• 見直しの契機：メンテナンスの曜日や時間帯が変わったとき

• 確かめ方：条件＝検証環境で、maintenance=true のアラートを作る。合格基準＝インシデントが作られない。［未実施］

5. 監視と異常検知

この章で決めること：Event Management 自身が止まっていないことを、何を見て、誰へ知らせるか。

OR-05 処理異常の検知と初動

イベントが処理されていない状態を、運用当番が毎日確かめるルールです。

前提となる製品の挙動

• ［実測］severity を持たないイベントは、em_event の状態が Error になり、アラートが作られなかった

• ［実測］ルールを作る順序によっては、ルールが active=false、エラーメッセージが "No active actions" になった。作り直して active=true にすると解消した

• ［実測］条件の Type（em_event_type を参照）を表示名で書くと、一致が0件でもエラーが出なかった。Type は参照の値で書く

• ［実測］Express List に、送信元が EC-Monitor 以外の ServiceNow 自身のアラートが出る。MID Server のエラーや、2日間更新されないアラートを示すものがある

• ［公式］evt_mgmt.self_health_active が true のとき、Event Management の自己監視が有効になる

• ①の枠：severity を付けずに送ったイベント。State が Error で、Alert の欄は空

• ①の枠：アラート、ルール、作られたインシデントの番号、Log が1行に並ぶ。日次の確認では、この一覧に当日の行があるかを見る

項目

• 条件：毎日9:00の引継ぎ時に、運用当番が日次の確認を行う。受信の確認は、30分ごとに行う

• 判断基準：日次では、次の3点を確かめる。①em_event で状態が Error のイベントが1件以上あるか。②アラート管理ルールの実行記録（em_alert_management_execution）。前日に Critical の親アラートが1件以上あったのに、実行記録が0件、またはインシデントが紐づいていないときは異常とする。③送信元が ServiceNow の自己監視アラートのうち、優先度グループ Urgent のもの。30分ごとの確認では、イベントの一覧で最新のイベントを見て、30分以上新しいイベントが届いていなければ受信の途絶とする。①は当日中に原因を調べる。②は監視設計担当へ連絡する。③は運用当番が当日中に Acknowledge し、監視設計担当へ引き継ぐ。受信の途絶は、監視ツール側の運用担当へ連絡する

• 責任者：実行＝運用当番。承認＝なし（理由：確認は設定を変えないため）。相談＝監視設計担当。報告先＝サービス責任者

• 期限：Error が1件以上なら、当日18:00までに監視設計担当へ引き継ぐ。受信の途絶は、検知から15分以内に監視ツール側へ連絡する。自己監視の Urgent アラートは、当日中に Acknowledge する

• 証跡：Error の件数、受信の最終時刻、実行記録の有無。記録先は処理異常の確認記録

• 例外：メンテナンス時間帯は、受信の途絶を異常として扱わない。ServiceNow 側の不具合が疑われる場合は、監視設計担当が ServiceNow の問い合わせ窓口へ起票する

• 見直しの契機：Error の件数が1か月で10件を超えたとき。メジャーアップグレード後

• 操作の手順：運用手順書の手順(10)〜(12)

• 確かめ方：条件＝検証環境で severity なしのイベントを送る。合格基準＝Error のイベントが1件以上現れ、運用当番が確認記録に書ける。［未実施］

6. 障害対応

この章で決めること：重大度ごとに、誰へ、いつまでに知らせ、いつ ServiceNow へ問い合わせるか。

6.1 重大度と対応期限

• 重大度1：決済サービスが利用できない。運用当番の主担当が、Critical の親アラートの影響サービスと、決済サービスのトップ画面で疎通できるかの確認結果から判定する。判定はインシデントの作成から5分以内に行う。第一報は作成から15分以内、担当グループの着手は呼び出しから30分以内

• 重大度2：決済サービスは利用できるが、性能の低下や一部機能の障害がある（Major の親アラート。自動起票の対象外）。運用当番が親アラートを見つけてから15分以内にインシデントを手動で作成し、作成から30分以内に担当グループの当番へ連絡する

• 重大度3：決済サービスに影響しない。日次確認で扱う

OR-06 重大障害時のエスカレーション

重大度1のインシデントで、第一報と ServiceNow への問い合わせの基準を決めるルールです。

前提となる製品の挙動

• ［実測］インシデントの説明に、影響サービスの件数（"[ec-db-01] is 1"）が入った

• ［実測］インシデントの Impact Summary のサービス欄は、デモでは空だった

項目

• 条件：運用当番が重大度1と判定したとき（判定の基準は6.1）

• 判断基準：運用当番がサービス責任者へ第一報を入れる。担当グループの着手後、30分ごとに状況を責任者へ報告する。イベントが2時間以上 Ready のまま処理されないなど、Event Management 自身の不具合が疑われるときは、責任者の承認後に ServiceNow の問い合わせ窓口へ起票する。起票は平日は監視設計担当、夜間と休日は運用当番が行う。担当グループが呼び出しから60分以内に着手しない場合は、サービス責任者が別のチームの要員を指名する。重大度1の終了は、Clear で Resolved になり、担当グループがサービスの復旧を確認した時点で、サービス責任者が宣言する。宣言までは30分ごとの報告を続ける

• 責任者：実行＝運用当番（平日の ServiceNow への起票は監視設計担当）。承認＝サービス責任者（終了の宣言を含む）。相談＝担当グループ。報告先＝監視設計担当

• 期限：第一報は作成から15分以内。ベンダーへの起票は、責任者の承認から2時間以内（時間外を含む）

• 証跡：第一報の日時と相手、報告の履歴、問い合わせ番号。記録先は障害記録

• 例外：サービス責任者が不在の場合は、代行者に連絡する。代行者にも連絡がつかない場合は、運用当番が情報システム部の上長へ連絡する

• 見直しの契機：重大度1の件数が月に3件を超えたとき。担当グループが変わったとき

• 確かめ方：条件＝机上で、日曜2:30に決済 DB が停止した想定を行う。合格基準＝運用当番が誰へ、いつまでに連絡するかを、この節だけで決められる。［未実施］

7. 変更・リリース・アップグレード

この章で決めること：ルールとプロパティの変更を、どう試験し、承認し、移送するか。アップグレード後に何を確かめるか。

OR-07 ルールの追加・変更の承認と移送

相関ルール、アラート管理ルール、プロパティの変更を、検証環境で試験してから本番へ移すルールです。

前提となる製品の挙動

• ［実測］相関ルールとアラート管理ルールは、更新セットで移送される設定データ（継承元が Application File）

• ［実測］ルールを作る順序によっては、ルールが active=false で作られた。移送後に有効状態を確かめる

• ［実測］アラート管理ルールの評価には、Store アプリ AIOps Experience の導入が必要だった。未導入の環境では、ルールを有効にしても実行記録が0件だった

• ［未確認］プロパティの値が、更新セットで移るかどうか

• ①の枠：evt_mgmt.alert_closes_incident（値は resolve）。アラートを閉じたときのインシデントの扱いを決める

• ②の枠：evt_mgmt.incident_closes_alert（値は true）。インシデントを解決すると、関連アラートを閉じる

項目

• 条件：担当グループかサービス責任者が、ルールの追加・変更を依頼したとき。依頼票に、目的、変更するルール、条件、期待する結果を書く

• 判断基準：監視設計担当が、検証環境で模擬イベントを送って試験する。合格は、期待どおりに起票されることと、アラート管理ルールの実行記録が1件以上作られること。条件に Type を使う場合は、参照の値で書く。試験の結果をサービス責任者が確かめ、承認したルールだけを本番へ移す。プロパティの変更は、本番で手で設定し、変更前後の値を記録する

• 責任者：実行＝監視設計担当。承認＝サービス責任者。相談＝担当グループ。報告先＝運用当番

• 期限：受付から3営業日以内に可否を返す。移送は火曜から木曜の10:00〜16:00に限る

• 証跡：依頼票、試験の結果、承認の日時、移送した更新セットの名前、変更前後のプロパティの値

• 例外：検証環境と本番で Store アプリの版が異なる場合は、移送せず延期する。重大度1の最中は、移送を行わない

• 見直しの契機：移送の後に起票の誤りが見つかったとき。Store アプリを更新したとき

• 操作の手順：運用手順書の手順(2)〜(4)

• 確かめ方：条件＝検証環境でルールを変更し、模擬イベントを送り、更新セットを作る。合格基準＝実行記録が作られ、更新セットに変更が入る。ルールの作成と、模擬イベントでの実行記録は［実施済み］（運用手順書の手順(3)と手順(4)）、更新セットへの記録は［未実施］

OR-08 ノイズの見直し

月次で、起票の数と誤起票を見て、ルールを見直すルールです。

前提となる製品の挙動

• ［実測］相関ルールで、DB 障害の後に届いた Web・AP・LB の警報が、親アラートの子としてまとまった

• ［実測］標準の相関ルール18件のうち、有効なのは2件（Dynatrace 用と Azure Monitor 用）。自動起票の標準ルールも既定では無効

• ［未確認］AIOps 360 overview の Workload saving のグラフ（イベントからアラート・インシデントへ絞られる流れ）が、実データでどう表示されるか。デモでは Value overview の一部が No data だった

項目

• 条件：毎月第3営業日までに、前月の起票を集計したとき

• 判断基準：監視設計担当が、前月の起票数、子アラートの比率、誤起票（決済に影響せずクローズされたインシデント）を確かめる。誤起票が起票数の10%を超えたら、アラート管理ルールの条件の見直しを「ルールの追加・変更の承認と移送」で依頼する。子アラートの比率が前月より10ポイント以上下がったときは、相関ルールの時間窓（15分）を見直す

• 責任者：実行＝監視設計担当。承認＝サービス責任者。相談＝運用当番。報告先＝担当グループ

• 期限：毎月第3営業日まで

• 証跡：月次の指標（第10章）と、見直した内容。記録先は月次報告

• 例外：ルールの変更が必要な場合は、「ルールの追加・変更の承認と移送」に従い、このルールでは変更しない

• 見直しの契機：誤起票の割合が2か月続けて10%を超えたとき。監視ツールの設定が変わったとき

• 操作の手順：運用手順書の手順(8)

• 確かめ方：条件＝検証環境の履歴で、1か月分の起票を集計する。合格基準＝起票数、子アラートの比率、誤起票を、第10章の集計条件どおりに出せる。［未実施］

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