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 を特定する

違反が近づいている（経過率が 75% を超えている）SLA を見つけます。

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 と incident データを結合する：

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%）を、少なくとも1日2回確認します
• 根本原因分析： 違反率が上昇した場合は、カテゴリと割り当てグループ別に調査します
• 営業時間： スケジュールを考慮します。営業時間外の違反は、設定に問題があることを示している場合があります
• 傾向分析： その時点の状況だけでなく、前週との比較を行います
• セグメンテーション： 優先度、カテゴリ、割り当てグループ別に分析し、実行可能なインサイトを得ます
• 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 Resolution 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 サービスレベル管理