alert-investigation

アラート調査

概要

このスキルでは、LEAP フレームワークを使用して、ServiceNow ITOM アラートを体系的に詳しく調査する方法を説明します。

• Locate（特定） -- アラート、その発生元、影響を受ける CI を特定します
• Examine（調査） -- CI の関係をたどり、最近の変更を確認し、過去のパターンを調べます
• Analyze（分析） -- 関連アラート、メトリクスデータ、ビジネスへの影響と相関させます
• Propose（提案） -- ナレッジベースの記事と過去の解決事例に基づいて、修復アクションを提案します

基本的なトリアージを超える根本原因の調査が必要な単一のアラートまたはアラートのクラスターに、このスキルを使用します。個々のアラートのフォレンジックに重点を置き、alert-analysis よりも詳細に調査します。

使用する場面： 運用エンジニアが重大または大規模なアラートを受け取り、影響範囲全体、最近の変更が原因かどうか、実施すべき修復手順を把握する必要がある場合です。

必須プラグイン： com.snc.event_management

前提条件

• ロール： evt_mgmt_admin、evt_mgmt_user、または itil
• アクセス権： em_alert、em_event、em_impact、cmdb_ci、cmdb_ci_service、change_request、kb_knowledge への読み取りアクセス権
• 知識： ITOM Event Management のアラートライフサイクル、CMDB CI クラス、変更管理プロセスに関する理解
• プラグイン： com.snc.event_management、com.snc.cmdb が有効化されている必要があります

手順

ステップ 1：アラートを特定し、初期コンテキストを収集する（LEAP - Locate）

関連するすべてのフィールドを含む、アラートレコード全体を取得します。

MCP を使用する場合：

Tool: SN-Get-Record
Parameters:
  table_name: em_alert
  sys_id: [alert_sys_id]

アラート番号しか分からない場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: number=[alert_number]
  fields: sys_id,number,description,severity,state,source,node,ci,group_source,acknowledged,additional_info,metric_name,sys_created_on,sys_updated_on

REST API を使用する場合：

GET /api/now/table/em_alert?sysparm_query=number=[alert_number]&sysparm_fields=sys_id,number,description,severity,state,source,node,ci,group_source,acknowledged,additional_info,metric_name,sys_created_on,sys_updated_on

ステップ 2：影響を受ける CI とその関係をたどる（LEAP - Examine）

CI の詳細と、上流／下流の依存関係を取得します。

MCP を使用する場合：

Tool: SN-Get-Record
Parameters:
  table_name: cmdb_ci
  sys_id: [ci_sys_id_from_alert]

次に、この CI がサポートするサービスを確認します。

Tool: SN-Query-Table
Parameters:
  table_name: svc_ci_assoc
  query: ci_id=[ci_sys_id]
  fields: sys_id,ci_id,service_id,type

REST API を使用する場合：

GET /api/now/table/cmdb_ci/[ci_sys_id]?sysparm_fields=sys_id,name,sys_class_name,business_criticality,support_group,operational_status,environment,location
GET /api/now/table/svc_ci_assoc?sysparm_query=ci_id=[ci_sys_id]&sysparm_fields=sys_id,ci_id,service_id,type

ステップ 3：影響を受ける CI の最近の変更を確認する

最近の変更要求がアラートの原因となった可能性があるかを特定します。

MCP を使用する場合：

Tool: SN-Execute-Background-Script
Parameters:
  description: Find recent changes associated with the alerting CI
  script: |
    var ciSysId = '[ci_sys_id]';
    var gr = new GlideRecord('task_ci');
    gr.addQuery('ci_item', ciSysId);
    gr.addQuery('task.sys_class_name', 'change_request');
    gr.addQuery('task.sys_created_on', '>=', gs.daysAgo(7));
    gr.orderByDesc('task.sys_created_on');
    gr.setLimit(10);
    gr.query();

    gs.info('=== RECENT CHANGES ON CI (Last 7 Days) ===');
    while (gr.next()) {
      var chg = new GlideRecord('change_request');
      if (chg.get(gr.task)) {
        gs.info('Change: ' + chg.number +
          ' | Type: ' + chg.type.getDisplayValue() +
          ' | State: ' + chg.state.getDisplayValue() +
          ' | Short Desc: ' + chg.short_description +
          ' | Planned End: ' + chg.end_date);
      }
    }

REST API を使用する場合：

GET /api/now/table/task_ci?sysparm_query=ci_item=[ci_sys_id]^task.sys_class_name=change_request^task.sys_created_on>=javascript:gs.daysAgo(7)&sysparm_fields=task,ci_item&sysparm_limit=10

ステップ 4：関連アラートと相関させる（LEAP - Analyze）

同じ CI、同じノード、または同じ時間帯に発生したほかのアラートを探します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: ci=[ci_sys_id]^state!=Closed^sys_idNOT IN[current_alert_sys_id]^ORDERBYDESCsys_created_on
  fields: sys_id,number,description,severity,source,state,sys_created_on
  limit: 20

アラートのメトリクス相関を確認します。

Tool: SN-Query-Table
Parameters:
  table_name: em_alert_metric_correlation
  query: alert=[alert_sys_id]
  fields: sys_id,alert,metric_name,ci,correlation_strength,sys_created_on

ビジネスへの影響を確認します。

Tool: SN-Query-Table
Parameters:
  table_name: em_impact
  query: alert=[alert_sys_id]
  fields: sys_id,alert,business_service,impact_level,ci

REST API を使用する場合：

GET /api/now/table/em_alert?sysparm_query=ci=[ci_sys_id]^state!=Closed^sys_idNOT IN[current_alert_sys_id]^ORDERBYDESCsys_created_on&sysparm_limit=20
GET /api/now/table/em_alert_metric_correlation?sysparm_query=alert=[alert_sys_id]
GET /api/now/table/em_impact?sysparm_query=alert=[alert_sys_id]

ステップ 5：修復方法をナレッジベースで検索する（LEAP - Propose）

アラートの説明または CI クラスに一致する既存の KB 記事を探します。

MCP を使用する場合：

Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: workflow_state=published^123TEXTQUERY321=[alert_description] remediation [ci_class_name]

または、KB を直接照会します。

Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: textLIKE[key_alert_terms]^workflow_state=published
  fields: sys_id,number,short_description,text,kb_knowledge_base,sys_updated_on
  limit: 10

REST API を使用する場合：

GET /api/now/table/kb_knowledge?sysparm_query=textLIKE[key_alert_terms]^workflow_state=published&sysparm_fields=sys_id,number,short_description,text&sysparm_limit=10

ステップ 6：調査結果を記録し、修復方法を提案する

調査メモと推奨アクションをアラートに追加します。

MCP を使用する場合：

Tool: SN-Update-Record
Parameters:
  table_name: em_alert
  sys_id: [alert_sys_id]
  data:
    work_notes: |
      LEAP Investigation Summary:
      - LOCATE: Alert [number] from [source] on node [node], CI [ci_name]
      - EXAMINE: CI criticality [criticality], [N] related changes found, closest change [CHG_number]
      - ANALYZE: [N] correlated alerts found, impact on [N] business services
      - PROPOSE: KB article [KB_number] provides remediation steps. Recommended action: [action]
    acknowledged: true

REST API を使用する場合：

PATCH /api/now/table/em_alert/[alert_sys_id]
Content-Type: application/json

{
  "work_notes": "LEAP Investigation completed. See work notes for full analysis.",
  "acknowledged": "true"
}

ツールの使用方法

MCP ツールのリファレンス

ツール	使用する場面
SN-Get-Record	sys_id を指定してアラートまたは CI のレコード全体を取得する
SN-Query-Table	アラート、変更、KB 記事、CI の関連付けを検索する
SN-Update-Record	調査結果をアラートに記録する
SN-Natural-Language-Search	修復方法に関する KB 記事を自然言語で検索する
SN-Execute-Background-Script	複雑なテーブル間結合や変更の検索を行う

REST API のリファレンス

エンドポイント	メソッド	目的
/api/now/table/em_alert	GET/PATCH	アラートを照会および更新する
/api/now/table/em_event	GET	元の未加工イベントをたどる
/api/now/table/em_alert_metric_correlation	GET	メトリクス相関を確認する
/api/now/table/em_impact	GET	ビジネスサービスへの影響を評価する
/api/now/table/cmdb_ci	GET	CI の詳細と重要度を取得する
/api/now/table/change_request	GET	最近の変更を確認する
/api/now/table/kb_knowledge	GET	修復方法をナレッジベースで検索する
/api/now/table/task_ci	GET	CI にリンクされた変更を探す

ベストプラクティス

• LEAP の順序に従う： Locate フェーズと Examine フェーズを完了する前に、Remediation に進むのは避けてください。コンテキストが不完全だと、誤った修正につながります
• まず変更を確認する： 本番環境では、インシデントの 60～80％は最近の変更が原因です。他の原因を調査する前に、必ず変更履歴を確認してください
• 切り分ける前に相関を確認する： CI に対する単一のアラートは、上流の障害の兆候である可能性があります。必ず親サービスとインフラストラクチャ CI の関連アラートを確認してください
• 時間枠を設定する： 相関を確認する際は、誤った相関を避けるため、狭い時間枠（アラート発生の 1～2 時間前）を使用してください
• すべて記録する： 他のエンジニアが調査を引き継げるよう、LEAP の各フェーズで work_notes を更新してください
• アラートの状態を維持する： 根本原因が確認され、修正が検証されるまで、アラートをクローズしないでください

トラブルシューティング

アラートに CI がマッピングされていない

原因： イベントソースに CI 識別フィールドが含まれていないか、CI ルックアップルールが一致しませんでした。
解決策： em_event テーブルの未加工イベントで ci_identifier フィールドを確認してください。Event Management の CI ルックアップルールを確認してください。ノードまたはソースから CI を特定できる場合は、手動で関連付けてください。

最近の変更が見つからないのにアラートが続く

原因： 問題は変更ではなく、環境（容量、ネットワーク、外部依存関係）に起因する可能性があります。
解決策： 調査範囲を広げて、メトリクスの相関（em_alert_metric_correlation）を確認し、インフラストラクチャ CI の正常性（CPU、メモリ、ディスクのメトリクス）を確認して、上流サービスの依存関係を調べてください。

KB 検索で関連する記事が見つからない

原因： ナレッジベースに、この種のアラートに関する記事がない可能性があります。
解決策： 解決後、根本原因と修正手順を記載した KB 記事を作成してください。今後の参照に備えて、CI クラスとアラートソースにリンクしてください。

相関したアラートの根本原因が異なる

原因： 複数の無関係な問題が同時に発生した場合、時間ベースの相関によって誤検知が生じることがあります。
解決策： 相関したアラートが時間的に近いだけでなく、CI 間の関係（同じサービスマップ）を共有しているか確認し、相関を検証してください。

例

例 1：重大なデータベースアラートを調査する

# LEAP Step 1 - LOCATE: Retrieve the alert
Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: number=AL0045123
  fields: sys_id,number,description,severity,source,node,ci,state,additional_info,sys_created_on

# LEAP Step 2 - EXAMINE: Get CI details
Tool: SN-Get-Record
Parameters:
  table_name: cmdb_ci
  sys_id: [ci_sys_id_from_alert]

# LEAP Step 2 - EXAMINE: Find recent changes
Tool: SN-Query-Table
Parameters:
  table_name: task_ci
  query: ci_item=[ci_sys_id]^task.sys_class_name=change_request^task.sys_created_on>=javascript:gs.daysAgo(3)
  fields: task,ci_item

# LEAP Step 3 - ANALYZE: Find related alerts
Tool: SN-Query-Table
Parameters:
  table_name: em_alert
  query: ci=[ci_sys_id]^state!=Closed^ORDERBYDESCsys_created_on
  fields: sys_id,number,description,severity,source
  limit: 15

# LEAP Step 4 - PROPOSE: Search KB
Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: workflow_state=published^123TEXTQUERY321=database connection pool exhausted remediation Oracle

例 2：変更に起因するアラートの調査

# 1. Get the alert details
Tool: SN-Get-Record
Parameters:
  table_name: em_alert
  sys_id: [alert_sys_id]

# 2. Find changes that completed within 2 hours before the alert
Tool: SN-Execute-Background-Script
Parameters:
  description: Find changes completed shortly before alert firing
  script: |
    var alert = new GlideRecord('em_alert');
    alert.get('[alert_sys_id]');
    var alertTime = alert.sys_created_on.toString();
    var ciId = alert.ci.toString();

    var twoHoursBefore = new GlideDateTime(alertTime);
    twoHoursBefore.addSeconds(-7200);

    var taskCi = new GlideRecord('task_ci');
    taskCi.addQuery('ci_item', ciId);
    taskCi.query();

    gs.info('=== CHANGES NEAR ALERT TIME ===');
    while (taskCi.next()) {
      var chg = new GlideRecord('change_request');
      if (chg.get(taskCi.task)) {
        var closeTime = chg.closed_at.toString();
        if (closeTime >= twoHoursBefore.toString() && closeTime <= alertTime) {
          gs.info('SUSPECT CHANGE: ' + chg.number +
            ' | Closed: ' + closeTime +
            ' | Type: ' + chg.type.getDisplayValue() +
            ' | Desc: ' + chg.short_description);
        }
      }
    }

例 3：複数サービスへの影響評価

# 1. Check business impact records
Tool: SN-Query-Table
Parameters:
  table_name: em_impact
  query: alert=[alert_sys_id]
  fields: sys_id,business_service,impact_level,ci

# 2. For each impacted service, check service criticality
Tool: SN-Query-Table
Parameters:
  table_name: cmdb_ci_service
  query: sys_idIN[service_sys_ids_from_impact]
  fields: sys_id,name,business_criticality,owned_by,operational_status

関連スキル

• itom/alert-analysis -- アラートの一括トリアージ、ノイズ削減、抑制ルール
• itom/service-mapping -- アラートを発生させる CI の背後にあるサービス依存関係の把握
• itom/health-log-analytics -- 異常検出とログベースの根本原因分析
• itom/observability-integration -- 外部監視ツールからのアラートの取り込みと正規化
• cmdb/impact-analysis -- より広範な CI の影響と依存関係の分析
• itsm/change-management -- 変更リクエストのライフサイクルとリスク評価