trend-analysis

趋势分析

概述

此技能可对 ServiceNow ITSM 数据进行全面的趋势分析，帮助你：

• 分析事件量随时间的变化趋势（日、周、月、季度）
• 识别类别和优先级分布的变化
• 检测季节性和周期性模式
• 识别用于容量规划的预测性指标
• 生成可操作的资源分配建议

适用场景： 进行容量规划、资源预测、识别系统性问题、准备趋势报告，或检测需要调查的异常情况。

前提条件

• 角色： report_admin、itil 或 analytics_admin
• 访问权限： 具有 incident、problem 及相关表的读取权限
• 知识： 具备基础统计知识，并了解组织模式
• 数据： 建议至少准备 90 天的历史数据；进行季节性分析时，最好准备 12 个月的数据

流程

步骤 1：建立基线指标

查询历史数据，建立用于比较的基线。

使用 MCP（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 90 days@javascript:gs.daysAgoStart(90)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,number,sys_created_on,priority,category,state,assignment_group
  limit: 5000

使用 REST API：

GET /api/now/table/incident?sysparm_query=sys_created_onONLast 90 days@javascript:gs.daysAgoStart(90)@javascript:gs.daysAgoEnd(0)&sysparm_fields=sys_id,number,sys_created_on,priority,category,state,assignment_group&sysparm_limit=5000

步骤 2：每日事件量趋势分析

按天跟踪事件创建模式。

查询每日明细（使用 GlideAggregate）：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var ga = new GlideAggregate('incident');
    ga.addQuery('sys_created_on', '>=', gs.daysAgo(30));
    ga.addAggregate('COUNT');
    ga.groupBy('sys_created_on');
    ga.orderBy('sys_created_on');
    ga.query();

    var dailyCounts = [];
    while (ga.next()) {
      var dateStr = ga.getValue('sys_created_on').substring(0, 10);
      dailyCounts.push({
        date: dateStr,
        count: parseInt(ga.getAggregate('COUNT'))
      });
    }
    gs.info('Daily Volume: ' + JSON.stringify(dailyCounts));
  description: Aggregate daily incident counts

手动计算（不使用 GlideAggregate）： 查询特定日期范围内的事件：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onON2024-01-15@javascript:gs.dateGenerate('2024-01-15','00:00:00')@javascript:gs.dateGenerate('2024-01-15','23:59:59')
  fields: sys_id
  limit: 500

步骤 3：每周事件量对比

按周进行对比，识别趋势。

本周：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 7 days@javascript:gs.daysAgoStart(7)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,priority,category
  limit: 1000

上周：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 7 days@javascript:gs.daysAgoStart(14)@javascript:gs.daysAgoEnd(7)
  fields: sys_id,priority,category
  limit: 1000

周环比分析：

周	数量	变化	变化百分比
当前周	145	+12	+9.0%
上周	133	-5	-3.6%
两周前	138	+8	+6.2%
三周前	130	-	基线

步骤 4：类别分布分析

跟踪事件类别随时间的变化。

查询类别分布：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,category
  limit: 2000

处理结果以生成分布数据：

Category Distribution (Last 30 Days):
| Category | Count | % of Total | Prev Month % | Change |
|----------|-------|------------|--------------|--------|
| Software | 245 | 32% | 28% | +4% |
| Network | 189 | 25% | 30% | -5% |
| Hardware | 152 | 20% | 18% | +2% |
| Email | 98 | 13% | 12% | +1% |
| Security | 76 | 10% | 12% | -2% |

步骤 5：优先级趋势分析

监控优先级分布的变化。

查询随时间变化的优先级分布：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,priority,sys_created_on
  limit: 2000

优先级变化指标：

指标	含义	操作
P1/P2 增加	严重问题增多	调查根本原因
P3/P4 增加	正常增长或分诊问题	检查分诊流程
P1 稳定，P2 增加	升级阈值发生变化	检查紧急程度标准

步骤 6：星期模式

识别事件量最高的星期几。

按星期查询事件：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 90 days@javascript:gs.daysAgoStart(90)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,sys_created_on
  limit: 5000

处理数据以提取星期几：

Day of Week Analysis (90-Day Average):
| Day | Avg Volume | vs Overall Avg | Staffing Recommendation |
|-----|------------|----------------|------------------------|
| Monday | 32 | +23% | Full staff + OT |
| Tuesday | 28 | +8% | Full staff |
| Wednesday | 26 | 0% | Normal |
| Thursday | 25 | -4% | Normal |
| Friday | 24 | -8% | Normal, early close OK |
| Saturday | 8 | -69% | Weekend skeleton |
| Sunday | 7 | -73% | Weekend skeleton |

步骤 7：小时模式

识别高峰时段，以优化人员配置。

按时间明细查询：

Tool: SN-Execute-Background-Script
Parameters:
  script: |
    var ga = new GlideAggregate('incident');
    ga.addQuery('sys_created_on', '>=', gs.daysAgo(30));
    ga.addAggregate('COUNT');
    ga.query();

    // Note: For hourly analysis, use sys_created_on timestamp
    // and extract hour component in processing
    var total = ga.getAggregate('COUNT');
    gs.info('Total incidents: ' + total);
  description: Count incidents for hourly analysis

典型的小时分布：

Hourly Volume Pattern (30-Day Analysis):
Peak Hours: 8am-11am (35% of daily volume)
Secondary Peak: 1pm-3pm (25% of daily volume)
Low Period: 6pm-6am (15% of daily volume)

Staffing Recommendation:
- Core Hours (8am-5pm): 80% of staff
- Extended Hours (5pm-8pm): 15% of staff
- Night/Weekend: 5% of staff

步骤 8：季节性和周期性模式

根据日历事件识别重复出现的模式。

查询月度数量（同比）： 针对每个月进行查询：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onON2024-01-01@javascript:gs.dateGenerate('2024-01-01','00:00:00')@javascript:gs.dateGenerate('2024-01-31','23:59:59')
  fields: sys_id
  limit: 2000

常见的季节性模式：

时段	模式	可能原因
1 月	+15-20%	假期积压、新年问题
3 月/4 月	+10%	财年末、系统变更
6 月至 8 月	-10-15%	假期期间、活动减少
9 月	+20%	开学/返工、新员工入职
11 月	+5%	节前变更
12 月	-20%	节假日停工

步骤 9：预测性指标

识别未来事件量的领先指标。

变更量相关性： 变更量较大时，事件量通常会随后激增。

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: sys_created_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,type,cmdb_ci
  limit: 500

问题创建作为领先指标：

Tool: SN-Query-Table
Parameters:
  table_name: problem
  query: sys_created_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,category,first_reported_by_task
  limit: 100

需要监控的领先指标：

指标	相关性	滞后时间
变更量	+0.65	1-3 天
新员工人数	+0.45	1-2 周
软件部署	+0.72	1-7 天
基础设施警报	+0.80	0-24 小时
创建的问题记录	+0.55	1-4 周

步骤 10：异常检测

识别需要调查的异常模式。

计算统计边界：

Rolling 30-Day Average: 26 incidents/day
Standard Deviation: 6 incidents
Upper Threshold (2σ): 38 incidents/day
Lower Threshold (2σ): 14 incidents/day

Any day outside 14-38 range = Anomaly requiring investigation

查询近期异常： 如果每日数量超过阈值，请进行调查：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()^ORDERBYcategory
  fields: sys_id,category,short_description,cmdb_ci
  limit: 100

工具用法

MCP 工具参考

工具	使用时机
SN-Query-Table	查询历史数据的主要工具
SN-Natural-Language-Search	使用自然语言查询进行快速探索
SN-Execute-Background-Script	使用 GlideAggregate 执行复杂聚合

REST API 参考

端点	方法	用途
/api/now/table/incident	GET	查询事件历史记录
/api/now/stats/incident	GET	统计聚合
/api/now/table/change_request	GET	变更关联数据

趋势分析的关键字段

字段	用途
sys_created_on	事件创建时间戳
category	类别分类
priority	优先级
assignment_group	分配的团队
cmdb_ci	配置项
state	当前状态

最佳实践

• 统一时区： 确保所有查询使用相同时区
• 统计显著性： 使用 90 天以上的数据来识别可靠模式
• 季节性调整： 比较同比相同时间段
• 关联分析： 将事件与变更、问题和 CI 关联起来
• 可视化： 使用图表识别模式
• 自动发送警报： 为统计异常设置警报
• 记录例外： 记录会导致数据偏差的一次性事件

故障排除

“数据出现意外峰值”

原因： 重大事件、系统中断或批量创建工单 解决方案： 筛除已知的重大事件；将该事件记录为例外

“同比比较结果不一致”

原因： 业务变化、合并或组织重组 解决方案： 根据员工人数或范围变化进行标准化；注明结构性差异

“未出现季节性模式”

原因： 历史数据不足（少于 12 个月） 解决方案： 等待积累更多数据；使用行业基准作为参考

“每周各天的模式不一致”

原因： 节假日、公司活动或远程办公变化 解决方案： 排除节假日所在周；分别分析远程办公和办公室办公时段

示例

示例 1：每周趋势报告

目标： 为管理层生成每周趋势摘要

查询：

// This Week
Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 7 days@javascript:gs.daysAgoStart(7)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,priority,category,sys_created_on
  limit: 500

// Previous Week
Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 7 days@javascript:gs.daysAgoStart(14)@javascript:gs.daysAgoEnd(7)
  fields: sys_id,priority,category,sys_created_on
  limit: 500

// Same Week Last Year (if available)
Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onON2023-01-15@javascript:gs.dateGenerate('2023-01-15','00:00:00')@javascript:gs.dateGenerate('2023-01-21','23:59:59')
  fields: sys_id,priority,category
  limit: 500

输出报告：

=== WEEKLY TREND REPORT ===
Week: Jan 15-21, 2024

VOLUME COMPARISON:
| Period | Volume | Change |
|--------|--------|--------|
| This Week | 152 | - |
| Last Week | 138 | +10.1% |
| Same Week Last Year | 165 | -7.9% |
| 4-Week Average | 142 | +7.0% |

TREND ASSESSMENT: Moderate Increase (within normal range)

DAILY BREAKDOWN:
| Day | Volume | vs Avg |
|-----|--------|--------|
| Mon | 35 | +17% |
| Tue | 28 | -7% |
| Wed | 25 | -17% |
| Thu | 22 | -27% |
| Fri | 24 | -20% |
| Sat | 10 | -67% |
| Sun | 8 | -73% |

Monday spike correlates with 3 changes deployed over weekend.

CATEGORY SHIFTS:
| Category | This Week | Last Week | Change |
|----------|-----------|-----------|--------|
| Software | 52 (34%) | 42 (30%) | +4% |
| Network | 38 (25%) | 42 (30%) | -5% |
| Hardware | 30 (20%) | 28 (20%) | 0% |
| Email | 18 (12%) | 14 (10%) | +2% |
| Security | 14 (9%) | 12 (9%) | 0% |

SOFTWARE TREND: +4% increase requires investigation
- 15 incidents related to new CRM deployment
- Recommend knowledge article for common CRM issues

FORECAST (Next Week):
Based on 8-week trend and scheduled changes:
Expected Volume: 145-160 incidents
Confidence: Medium (upcoming holiday may reduce volume)

示例 2：容量规划报告

目标： 预测下个季度的人员需求

分析流程：

1. 历史数量（过去 12 个月）：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: sys_created_onONLast 365 days@javascript:gs.daysAgoStart(365)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,sys_created_on,priority
  limit: 10000

2. 计算月平均值：

Monthly Volume Summary:
Jan: 720 | Feb: 680 | Mar: 750
Apr: 710 | May: 695 | Jun: 620
Jul: 580 | Aug: 590 | Sep: 780
Oct: 740 | Nov: 700 | Dec: 550

Average: 676/month
Peak: September (780) - Back to school/work
Low: December (550) - Holiday period

3. 预测下个季度：

=== Q2 2024 CAPACITY FORECAST ===

VOLUME PROJECTION:
| Month | Projected | Confidence | Factors |
|-------|-----------|------------|---------|
| April | 720-750 | High | Fiscal year end |
| May | 700-730 | High | Normal |
| June | 630-660 | Medium | Summer start |

STAFFING REQUIREMENTS:
Current Capacity: 750 incidents/month (5 FTEs)
Incidents per FTE: 150/month

| Month | Volume | FTEs Needed | Current | Gap |
|-------|--------|-------------|---------|-----|
| April | 735 | 5.0 | 5 | 0 |
| May | 715 | 4.8 | 5 | +0.2 |
| June | 645 | 4.3 | 5 | +0.7 |

RECOMMENDATIONS:
1. April: Full staffing required, no vacations
2. May: Normal operations, 1 vacation slot OK
3. June: Good time for training, 2 vacation slots OK

RISK FACTORS:
- ERP upgrade scheduled for April 15: +20% volume risk
- New office opening in May: +50 incidents/month expected

ADJUSTED FORECAST WITH RISKS:
| Month | Base | Risk Adjusted | FTEs Needed |
|-------|------|---------------|-------------|
| April | 735 | 880 | 6.0 |
| May | 715 | 815 | 5.5 |
| June | 645 | 695 | 4.7 |

Recommendation: Hire 1 contractor for April-May to cover ERP risk

示例 3：根本原因趋势调查

目标： 调查本月软件事件增加 15% 的原因

步骤 1：找出增幅

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: category=Software^sys_created_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,short_description,cmdb_ci,subcategory,assignment_group,sys_created_on
  limit: 500

步骤 2：按子类别深入分析

Software Incident Breakdown:
| Subcategory | This Month | Last Month | Change |
|-------------|------------|------------|--------|
| CRM | 85 | 45 | +89% |
| Email | 42 | 48 | -12% |
| ERP | 38 | 35 | +9% |
| Office Suite | 35 | 40 | -12% |
| Other | 45 | 42 | +7% |

CRM subcategory driving entire increase!

步骤 3：分析 CRM 事件

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: category=software^cmdb_ci.nameLIKECRM^sys_created_on>=javascript:gs.beginningOfThisMonth()
  fields: sys_id,short_description,sys_created_on
  limit: 100

步骤 4：识别模式

=== CRM INCIDENT TREND ANALYSIS ===

TIMELINE:
- Month start (Day 1-10): 15 incidents (normal)
- Mid-month (Day 11-20): 45 incidents (+200%)
- Month end (Day 21-30): 25 incidents (+67%)

CORRELATION:
- CRM v4.2 deployed on Day 10
- 70% of incidents reference "login" or "sync" issues
- All incidents assigned to Application Support

TOP ISSUES:
1. "Unable to sync contacts" - 32 incidents
2. "Login timeout errors" - 28 incidents
3. "Report generation failing" - 15 incidents
4. Other - 10 incidents

ROOT CAUSE:
CRM v4.2 deployment introduced authentication bug
affecting mobile sync and session timeout.

RECOMMENDATIONS:
1. IMMEDIATE: Deploy hotfix for authentication issue
2. SHORT-TERM: Create knowledge article for workaround
3. LONG-TERM: Improve deployment testing for auth changes

PREDICTED IMPACT:
After hotfix deployment, expect:
- Week 1: 50% reduction in CRM incidents
- Week 2: Return to baseline (45/month)

相关技能

• reporting/sla-analysis - SLA 性能跟踪
• reporting/executive-dashboard - 高管 KPI 生成
• itsm/incident-lifecycle - 完整的事件管理
• itsm/problem-analysis - 根本原因调查

参考资料

• ServiceNow Performance Analytics
• ServiceNow Reporting
• ITIL 持续服务改进
• 统计过程控制