incident-activity-summarization

事件活动摘要

概述

此技能可为 ServiceNow ITSM 生成简洁的事件活动流叙述摘要：

• 将工作备注、附加评论和日志条目整合为连贯的时间线
• 跟踪状态变更及其时间戳、持续时间和负责人
• 映射跨团队和个人的指派变更
• 突出关键决策点、升级触发条件和解决尝试
• 生成便于交接的摘要，支持换班和团队交接
• 为重大事件创建便于管理层阅读的执行摘要
• 生成考虑 SLA 的摘要，标记违约和存在风险的时间线

适用场景： Agent 需要在交接时快速了解事件历史、管理人员需要获取活动事件的状态更新、编写事后事件文档，或构建可自动汇总活动的零接触服务台自动化时。

前提条件

• 角色： itil、incident_manager 或 admin
• 插件： com.glideapp.itil（ITSM）
• 访问权限： 对 incident、sys_journal_field、sys_audit、task_sla 的读取权限
• 知识： 事件生命周期状态、SLA 概念、指派组结构
• 相关技能： 用于状态管理的 itsm/incident-lifecycle，用于 P1 流程的 itsm/major-incident

操作步骤

第 1 步：检索事件记录

获取事件的核心详情以作为上下文。

MCP 方式：

Tool: SN-Get-Record
Parameters:
  table_name: incident
  sys_id: <incident_sys_id>
  fields: sys_id,number,short_description,description,state,priority,impact,urgency,category,subcategory,assigned_to,assignment_group,opened_at,opened_by,resolved_at,resolved_by,closed_at,closed_by,caller_id,cmdb_ci,contact_type,reopen_count,reassignment_count,escalation,sys_updated_on

REST 方式：

GET /api/now/table/incident/<incident_sys_id>
  ?sysparm_fields=sys_id,number,short_description,description,state,priority,impact,urgency,category,subcategory,assigned_to,assignment_group,opened_at,resolved_at,closed_at,caller_id,cmdb_ci,reopen_count,reassignment_count,escalation
  &sysparm_display_value=true

第 2 步：检索工作备注和评论

获取该事件的所有日志条目（工作备注和附加评论）。

MCP 方式：

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=<incident_sys_id>^elementIN(work_notes,comments)^ORDERBYsys_created_on
  fields: sys_id,element,value,sys_created_on,sys_created_by
  limit: 200

REST 方式：

GET /api/now/table/sys_journal_field
  ?sysparm_query=element_id=<incident_sys_id>^elementIN(work_notes,comments)^ORDERBYsys_created_on
  &sysparm_fields=sys_id,element,value,sys_created_on,sys_created_by
  &sysparm_limit=200

第 3 步：检索状态变更历史

使用审计日志跟踪所有状态变更及其时间戳。

MCP 方式：

Tool: SN-Query-Table
Parameters:
  table_name: sys_audit
  query: documentkey=<incident_sys_id>^fieldname=state^ORDERBYsys_created_on
  fields: sys_id,oldvalue,newvalue,sys_created_on,user
  limit: 50

REST 方式：

GET /api/now/table/sys_audit
  ?sysparm_query=documentkey=<incident_sys_id>^fieldname=state^ORDERBYsys_created_on
  &sysparm_fields=sys_id,oldvalue,newvalue,sys_created_on,user
  &sysparm_display_value=true
  &sysparm_limit=50

第 4 步：检索指派历史

跟踪由哪些人处理过此事件以及各自的处理时长。

MCP 方式：

Tool: SN-Query-Table
Parameters:
  table_name: sys_audit
  query: documentkey=<incident_sys_id>^fieldnameINassigned_to,assignment_group^ORDERBYsys_created_on
  fields: sys_id,fieldname,oldvalue,newvalue,sys_created_on,user
  limit: 50

第 5 步：检索 SLA 状态

检查与该事件关联的所有 SLA 记录。

MCP 方式：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: task=<incident_sys_id>
  fields: sys_id,sla,stage,has_breached,planned_end_time,percentage,business_percentage,start_time,end_time,pause_duration,pause_time
  limit: 10

REST 方式：

GET /api/now/table/task_sla
  ?sysparm_query=task=<incident_sys_id>
  &sysparm_fields=sys_id,sla,stage,has_breached,planned_end_time,percentage,business_percentage,start_time,end_time
  &sysparm_display_value=true
  &sysparm_limit=10

第 6 步：构建活动时间线

将所有数据源合并为统一的时间顺序时间线：

=== INCIDENT ACTIVITY TIMELINE ===
Incident: INC0067890 - Production database connection pool exhaustion
Priority: P1 - Critical | State: Resolved
Duration: 4 hours 23 minutes (Opened to Resolved)

[2025-12-10 02:15] OPENED by Monitoring System (auto-created)
  - Source: Event Management alert
  - Description: Connection pool on prod-db-01 exceeded 95% threshold
  - Auto-assigned to: Database Administration (DBA Team)

[2025-12-10 02:17] WORK NOTE by System
  - "Related alert: CPU utilization on prod-db-01 at 92%"
  - "3 dependent services affected: Order Processing, User Auth, Reporting"

[2025-12-10 02:25] STATE: New -> In Progress
  - Assigned to: Mike Chen (DBA Team)
  - Work note: "Investigating connection pool metrics. Current active
    connections: 485/500. Identifying top consumers."

[2025-12-10 02:42] WORK NOTE by Mike Chen
  - "Root cause identified: Reporting batch job spawning excessive connections.
    Job ID: RPT-NIGHTLY-2025121001. Normally runs 50 connections, currently
    holding 280 connections due to long-running query."

[2025-12-10 02:55] ESCALATION triggered (P1 > 30 min without resolution)
  - Notification sent to: DBA Manager (Sarah Kim)

[2025-12-10 03:10] WORK NOTE by Mike Chen
  - "Killed the runaway reporting query (PID 45678). Connection pool
    dropping. Currently at 310/500. Waiting for connections to release."

[2025-12-10 03:15] COMMENT by Sarah Kim (Manager)
  - "Monitoring the situation. Is there a risk of recurrence tonight?"

[2025-12-10 03:20] WORK NOTE by Mike Chen
  - "Disabled the nightly reporting job to prevent recurrence. Will
    coordinate with Reporting team to fix the query before re-enabling.
    Connection pool now at 180/500 - within normal range."

[2025-12-10 03:45] WORK NOTE by Mike Chen
  - "All dependent services confirmed operational. Order Processing,
    User Auth, and Reporting dashboard all responding normally."

[2025-12-10 04:00] ASSIGNMENT changed: Mike Chen -> Lisa Park (for monitoring)
  - Shift handoff: Mike Chen end of on-call rotation

[2025-12-10 06:38] STATE: In Progress -> Resolved
  - Resolved by: Lisa Park
  - Resolution: "Runaway reporting query killed, connection pool restored.
    Nightly job disabled pending query optimization. Change CHG0012345
    created for permanent fix."

第 7 步：生成叙述摘要

将时间线转换为易读的叙述：

=== NARRATIVE SUMMARY ===
Incident INC0067890 was a P1 critical issue involving production database
connection pool exhaustion on prod-db-01. The incident was auto-created
by Event Management at 02:15 on December 10, 2025, when the connection
pool exceeded the 95% threshold.

DBA team member Mike Chen began investigation at 02:25 and identified
the root cause within 17 minutes: a nightly reporting batch job had
spawned 280 connections (normally 50) due to a long-running query. Three
dependent services were impacted: Order Processing, User Auth, and
Reporting.

The runaway query was terminated at 03:10, and the connection pool
returned to normal levels (180/500) by 03:20. The nightly reporting job
was disabled as a preventive measure. All dependent services were
confirmed operational by 03:45.

The incident was handed off to Lisa Park at 04:00 during shift rotation
and formally resolved at 06:38. Total resolution time was 4 hours 23
minutes. A change request (CHG0012345) was created for the permanent
fix (query optimization).

KEY METRICS:
- Time to Acknowledge: 10 minutes
- Time to Root Cause: 27 minutes
- Time to Mitigate: 55 minutes
- Time to Resolve: 4 hours 23 minutes
- Reassignment Count: 1 (shift handoff)
- SLA Status: Response SLA met, Resolution SLA met

第 8 步：生成交接摘要

创建便于换班交接的精简摘要：

=== SHIFT HANDOFF SUMMARY ===
Incident: INC0067890 - DB Connection Pool Exhaustion (P1)

CURRENT STATE: Resolved (monitoring)
WHAT HAPPENED: Reporting batch job consumed 280 DB connections (limit 500),
  causing service degradation for 3 dependent apps.
WHAT WAS DONE: Killed runaway query, disabled nightly job, pool recovered.
WHAT REMAINS: Monitor for recurrence. Reporting job stays disabled until
  CHG0012345 (query optimization) is implemented.
RISK: Low - root cause addressed. If pool spikes again, kill reporting
  connections first (see work note at 02:42 for query identification steps).
CONTACTS: Mike Chen (original responder), Sarah Kim (manager, notified).

第 9 步：生成执行摘要

创建便于管理层阅读的概览：

=== EXECUTIVE SUMMARY ===
INC0067890 | P1 Critical | RESOLVED

A production database capacity issue caused temporary degradation to three
business services (Order Processing, User Authentication, Reporting) for
approximately 90 minutes on December 10. The issue was caused by a
misconfigured batch reporting job and was resolved without data loss or
customer impact. A permanent fix is scheduled via change request CHG0012345.

Impact: 3 internal services, no customer-facing impact
Duration: 90 minutes (service degradation), 4h23m (total incident lifecycle)
Root Cause: Software defect in reporting batch job
Prevention: Change request filed for query optimization

第 10 步：将摘要附加到事件

将生成的摘要保存为工作备注。

MCP 方式：

Tool: SN-Add-Work-Notes
Parameters:
  table_name: incident
  sys_id: <incident_sys_id>
  work_notes: "[AI-Generated Activity Summary]\n\n<narrative summary>"

工具用法

工具	用途	适用场景
SN-Get-Record	检索事件记录详情	初步收集上下文
SN-Query-Table	获取日志条目、审计记录、SLA 记录	检索活动数据
SN-Natural-Language-Search	按描述查找相关事件	跨事件模式分析
SN-Add-Work-Notes	将生成的摘要附加到事件	文档记录和交接

最佳实践

1. 按时间顺序合并所有数据源 —— 将工作备注、状态变更和任务分配整合到同一时间线中
2. 区分工作备注和评论 —— 工作备注仅供内部查看，评论对客户可见
3. 计算状态持续时间 —— 显示事件在每种状态下持续了多久
4. 清晰突出根本原因 —— 最重要的发现应醒目呈现
5. 列出仍待完成的事项 —— 交接摘要必须涵盖未完成的操作
6. 醒目标记 SLA 违规 —— 任何摘要都应在顶部显示 SLA 违规情况
7. 使用业务友好型语言 —— 面向管理层的摘要应避免使用技术术语
8. 注明重新分配情况 —— 过多的重新分配表明路由存在问题
9. 包含相关记录 —— 链接到变更请求、问题记录或相关事件
10. 为所有条目添加时间戳 —— 每项活动都必须有明确的时间戳，以便审计

故障排除

问题	原因	解决方法
缺少日志条目	保留策略清除了旧条目	检查 sys_journal_field 的保留设置；数据可能已存档
审计记录不完整	并非所有字段都启用了审计	在 sys_dictionary 中验证审计配置
未跟踪状态变更	状态字段未启用审计	在字典中为 state 字段启用审计
缺少 SLA 记录	此优先级或类别没有 SLA 定义	检查 contract_sla 中的 SLA 定义
任务分配历史存在缺口	任务分配变更未启用审计	为 assigned_to 和 assignment_group 启用审计
时间线顺序混乱	查询中的时区不匹配	统一使用 UTC，并在显示时进行转换

示例

示例 1：轮班交接摘要

输入：“总结 INC0067890 上的所有活动，供接班人员查看”

**步骤：**检索事件，获取所有日志条目和状态变更，识别过去 4 小时内的活动，并生成精简的交接摘要，其中包含当前状态、待处理操作和风险评估。

示例 2：重大事件管理层报告

输入：“为 CTO 生成 P1 事件 INC0067890 的管理层摘要”

**步骤：**检索事件及所有活动，计算关键指标（检测、响应和解决所需时间），评估业务影响，生成不含技术细节的管理层叙述，并纳入预防措施。

示例 3：每日站会批量活动摘要

输入：“总结过去 24 小时内的所有 P1 和 P2 事件”

**步骤：**查询过去 24 小时内新建或更新且优先级为 1 或 2 的事件，为每个事件生成简短摘要（3-5 行），包含当前状态和负责人，并汇总指标（事件总数、已解决数量、仍未解决数量）。

相关技能

• itsm/incident-lifecycle - 事件状态管理和生命周期
• itsm/major-incident - 重大事件管理流程
• itsm/incident-triage - 事件分类和路由
• reporting/sla-analysis - SLA 性能分析
• itsm/quick-reference - ITSM 字段和状态参考