sla-analysis

SLA 分析

概述

此技能可对 ServiceNow ITSM 的 SLA（服务级别协议）进行全面的性能分析。它支持你：

• 实时检测 SLA 违约和即将违约的情况
• 按服务、优先级或时间段计算 SLA 达成率
• 分析趋势，识别系统性问题
• 生成报告，供利益相关者沟通使用
• 在 SLA 违约前识别有风险的 SLA

使用场景： 用于 SLA 合规性报告、识别性能问题、准备高管摘要或调查违约模式。

前提条件

• 角色： sla_admin、itil 或 report_admin
• 访问权限： 对 task_sla、contract_sla、incident 及相关表具有读取权限
• 知识： 了解 SLA 定义及其业务影响
• 数据： 必须已在 ServiceNow 中配置有效的 SLA 定义

操作步骤

步骤 1：查询 SLA 状态概览

获取所有活动任务当前 SLA 状态的快照。

使用 MCP（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=true
  fields: sys_id,task,sla,stage,percentage,has_breached,business_time_left,planned_end_time
  limit: 100

使用 REST API：

GET /api/now/table/task_sla?sysparm_query=active=true&sysparm_fields=sys_id,task,sla,stage,percentage,has_breached,business_time_left,planned_end_time&sysparm_limit=100

步骤 2：检测已违约的 SLA

识别所有已经违约的 SLA。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: has_breached=true^active=true
  fields: sys_id,task,sla,stage,percentage,original_breach_time,business_time_left
  limit: 50

SLA 阶段值参考：

阶段	描述	所需操作
进行中	SLA 计时器正在运行	监控
已暂停	计时器已暂停（等待用户）	查看暂停原因
已违约	SLA 已违约	立即处理
已达成	SLA 已成功达成	无需操作
已取消	SLA 不再适用	查看取消原因

步骤 3：识别有风险的 SLA

查找即将违约的 SLA（已耗时 >75%）。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=true^has_breached=false^percentage>=75
  fields: sys_id,task,sla,percentage,business_time_left,planned_end_time,stage
  limit: 50
  order_by: percentage
  order_direction: desc

使用 REST API：

GET /api/now/table/task_sla?sysparm_query=active=true^has_breached=false^percentage>=75&sysparm_fields=sys_id,task,sla,percentage,business_time_left,planned_end_time,stage&sysparm_limit=50&sysparm_orderby=percentage&sysparm_orderbydesc=percentage

步骤 4：计算达成指标

查询已完成的 SLA，以计算达成率。

获取已达成的 SLA（过去 30 天）：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=false^has_breached=false^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,task,sla,end_time
  limit: 1000

获取已违约的 SLA（过去 30 天）：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=false^has_breached=true^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,task,sla,end_time
  limit: 1000

计算达成率：

Achievement Rate = (Achieved SLAs / Total Completed SLAs) * 100

步骤 5：按 SLA 定义分析趋势

按 SLA 定义对指标分组，以识别有问题的 SLA。

查询 SLA 定义：

Tool: SN-Query-Table
Parameters:
  table_name: contract_sla
  query: active=true
  fields: sys_id,name,collection,duration,schedule,relative_duration_works_on
  limit: 100

按 SLA 定义查询违约情况：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: has_breached=true^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sla,task,end_time
  limit: 500

步骤 6：生成基于时间的趋势分析

分析各时间段内的 SLA 性能。

每周违约数（过去 4 周）：

查询每周数据：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: has_breached=true^end_timeONLast 7 days@javascript:gs.daysAgoStart(7)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,sla,task
  limit: 500

对前几周重复查询，并使用 daysAgoStart(14)@javascript:gs.daysAgoEnd(7)。

步骤 7：按优先级分析 SLA 性能

按事件优先级细分分析 SLA 达成率。

将 task_sla 与事件数据联接：

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: task.sys_class_name=incident^active=false^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,task,task.priority,sla,has_breached
  limit: 500

预期输出分析：

优先级	SLA 总数	已达成	已违约	达成率 %
P1 - 严重	25	20	5	80%
P2 - 高	150	135	15	90%
P3 - 中	400	380	20	95%
P4 - 低	200	198	2	99%

工具用法

MCP 工具参考

工具	使用场景
SN-Query-Table	查询 task_sla 和 contract_sla 表的主要工具
SN-Natural-Language-Search	使用自然语言查询，例如“显示本周已违约的 SLA”
SN-Get-Record	获取特定 SLA 记录的详细信息

REST API 参考

端点	方法	用途
/api/now/table/task_sla	GET	查询活动/已完成的 SLA
/api/now/table/contract_sla	GET	查询 SLA 定义
/api/now/stats/task_sla	GET	汇总统计数据

关键表

表	描述
task_sla	附加到任务的单个 SLA 记录
contract_sla	SLA 定义（条款、时长、计划）
cmn_schedule	用于 SLA 计算的业务计划
sla_condition_class	SLA 启动/停止/暂停条件

最佳实践

• 实时监控： 每天至少检查两次有风险的 SLA（>75%）
• 根因分析： 违约率上升时，按类别和分配组进行调查
• 营业时间： 考虑工作时间安排；非营业时间发生的违约可能表明配置有问题
• 趋势分析： 比较逐周变化，而不只是查看单个时点的数据
• 细分分析： 按优先级、类别和分配组进行分析，以获得可执行的见解
• 与 ITIL 保持一致： SLA 管理支持持续服务改进（CSI）

故障排除

“未找到 task_sla 记录”

原因： SLA 定义可能未关联到工作流，或未处于活动状态
解决方案： 确认存在有效的 contract_sla 记录；检查 SLA 条件是否与任务条件匹配

“违约时间不一致”

原因： 未正确应用工作时间安排，或存在夏令时问题
解决方案： 检查 cmn_schedule 配置；检查时区设置

“百分比超过 100%”

原因： SLA 已违约，但任务仍处于打开状态；百分比会继续累积
解决方案： 这是预期行为；使用 has_breached=true 进行筛选，以便清楚识别违约情况

“SLA 未正确启动/停止”

原因： 未满足启动/停止条件
解决方案： 检查该 SLA 定义的 sla_condition_class 条目

示例

示例 1：每日 SLA 健康检查

目标： 早间检查 SLA 状态

步骤 1：获取违约摘要

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=true^has_breached=true
  fields: task,sla,percentage,business_time_left
  limit: 20

步骤 2：获取有风险的 SLA

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=true^has_breached=false^percentage>=80
  fields: task,sla,percentage,planned_end_time
  limit: 20

输出摘要：

=== SLA HEALTH CHECK ===
Date: [Today]

CRITICAL (Breached): 3 SLAs
- INC0012345 - Resolution SLA - 120% (P1)
- INC0012400 - Response SLA - 105% (P2)
- INC0012456 - Resolution SLA - 150% (P2)

AT RISK (>80%): 7 SLAs
- INC0012500 - Resolution SLA - 85% (2 hours remaining)
- INC0012501 - Resolution SLA - 82% (3 hours remaining)
[...]

OVERALL HEALTH: Needs Attention
Action: Escalate breached P1 incident immediately

示例 2：每月 SLA 绩效报告

目标： 生成月度管理层摘要

步骤 1：处理的 SLA 总数

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: active=false^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,has_breached,sla
  limit: 2000

步骤 2：按 SLA 类型计数 处理结果以创建摘要：

=== MONTHLY SLA PERFORMANCE REPORT ===
Period: [Last 30 Days]

SUMMARY:
- Total SLAs Completed: 1,247
- Achieved: 1,185 (95.0%)
- Breached: 62 (5.0%)

BY SLA TYPE:
| SLA Definition        | Total | Achieved | Breached | Rate |
|-----------------------|-------|----------|----------|------|
| P1 Resolution (4hr)   | 45    | 38       | 7        | 84%  |
| P2 Resolution (8hr)   | 189   | 175      | 14       | 93%  |
| P3 Resolution (24hr)  | 512   | 498      | 14       | 97%  |
| P4 Resolution (72hr)  | 301   | 294      | 7        | 98%  |
| Response SLA (1hr)    | 200   | 180      | 20       | 90%  |

TREND (Week-over-Week):
Week 1: 96% achievement
Week 2: 95% achievement
Week 3: 94% achievement
Week 4: 95% achievement

RECOMMENDATIONS:
1. P1 Resolution SLA at 84% - below target; investigate root cause
2. Response SLA showing consistent underperformance - review staffing levels

示例 3：违约根因分析

目标： 调查 P1 解决 SLA 表现不佳的原因

步骤 1：获取已违约的 P1 SLA

Tool: SN-Query-Table
Parameters:
  table_name: task_sla
  query: has_breached=true^task.priority=1^sla.nameLIKEResolution^end_timeONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
  fields: task,task.number,task.assignment_group,task.category,task.short_description,original_breach_time,end_time
  limit: 50

步骤 2：分析规律

=== P1 RESOLUTION SLA BREACH ANALYSIS ===

BREACHES BY ASSIGNMENT GROUP:
- Network Operations: 4 breaches (57%)
- Application Support: 2 breaches (29%)
- Desktop Support: 1 breach (14%)

BREACHES BY CATEGORY:
- Network: 4 (57%)
- Software: 2 (29%)
- Hardware: 1 (14%)

COMMON PATTERNS:
1. 5 of 7 breaches occurred during night shift (11pm-7am)
2. Network issues taking longest to resolve (avg 6.2 hours vs 4hr target)
3. 3 breaches had multiple reassignments before resolution

ROOT CAUSE HYPOTHESIS:
- Insufficient night shift coverage for Network team
- Complex network issues exceeding 4-hour P1 target

RECOMMENDATIONS:
1. Add on-call network engineer for night shift
2. Review P1 network SLA target (consider 6-hour resolution)
3. Implement warm handoff procedures to reduce reassignment delays

相关技能

• reporting/executive-dashboard - 管理层 KPI 生成
• reporting/trend-analysis - 事件量和模式分析
• itsm/incident-lifecycle - 完整的事件管理
• itsm/major-incident - 重大事件处理

参考资料

• ServiceNow SLA 管理
• task_sla 表
• ITIL 服务级别管理