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 - 定位）

检索完整的告警记录，包括所有相关字段。

使用 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 - 检查）

检索 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 - 分析）

查找同一 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 - 提出方案）

查找与告警描述或 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： 在完成定位和检查阶段之前，不要急于修复——上下文不完整会导致错误的修复
• 先检查变更： 在生产环境中，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、内存、磁盘指标），并检查上游服务依赖项。

知识库搜索未返回相关文档

原因： 知识库中可能没有适用于此类告警的文档。 解决方案： 问题解决后，创建知识库文档，记录根本原因和修复步骤。将其关联到 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 -- 变更请求生命周期和风险评估