incident-lifecycle

インシデントライフサイクル管理

概要

このスキルでは、ITIL のベストプラクティスに従って、ServiceNow におけるインシデントのライフサイクル全体を扱います。

1. 作成 - 必要な詳細情報を記録してインシデントを登録します
2. 分類 - 種類とサービスに基づいて分類します
3. 優先順位付け - 影響度、緊急度、優先度を設定します
4. 割り当て - 適切なチームに振り分けます
5. 調査 - 問題を診断します
6. 解決 - 問題を修正し、記録します
7. クローズ - インシデントを確認してクローズします

前提条件

• ロール: ほとんどの操作には itil、一部の上書き操作には incident_manager
• アクセス権: インシデントテーブルの読み取り／書き込み権限
• 知識: ITIL のインシデント管理の基礎

手順

フェーズ 1：インシデントの作成

必要な情報をすべて記載した、十分な記録のあるインシデントを作成します。

MCP を使用する場合：

Tool: SN-Create-Incident
Parameters:
  short_description: "Brief summary of the issue"
  description: "Detailed description including:
    - What happened
    - When it started
    - Who is affected
    - What has been tried"
  caller_id: [user_sys_id or username]
  category: software
  subcategory: application
  impact: 2
  urgency: 2
  assignment_group: Service Desk

REST API を使用する場合：

POST /api/now/table/incident
Content-Type: application/json

{
  "short_description": "Brief summary",
  "description": "Detailed description...",
  "caller_id": "user_sys_id",
  "category": "software",
  "impact": "2",
  "urgency": "2",
  "assignment_group": "group_sys_id"
}

作成時のベストプラクティス：

• 短い説明は 10～50 文字にします
• 説明には、誰が、何を、いつ、どこで、の情報を含めます
• 必ず発信者（影響を受けているユーザー）を設定します
• 適切に振り分けられるよう、カテゴリ／サブカテゴリを設定します

フェーズ 2：分類と優先順位付け

インシデントが適切に分類されていることを確認します。

カテゴリ階層：

Hardware
├── Computer
├── Monitor
├── Printer
└── Mobile Device

Software
├── Operating System
├── Application
├── Email
└── Database

Network
├── Connectivity
├── VPN
└── WiFi

Request
├── Access
├── Installation
└── Information

優先度マトリックス：

影響度 ↓ / 緊急度 →	1-高	2-中	3-低
1-高	P1	P2	P3
2-中	P2	P3	P4
3-低	P3	P4	P5

フェーズ 3：割り当て

適切な解決チームに振り分けます。

MCP を使用する場合：

Tool: SN-Assign-Incident
Parameters:
  sys_id: [incident_sys_id]
  assignment_group: Desktop Support
  assigned_to: john.smith  # Optional: specific person
  work_notes: "Assigned based on hardware category"

フェーズ 4：調査と診断

調査の手順をすべて記録します。

作業メモの追加（内部向け）：

Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [incident_sys_id]
  work_notes: |
    Investigation Steps:
    1. Verified user credentials - OK
    2. Checked network connectivity - OK
    3. Reviewed application logs - Found error
    4. Identified root cause: Corrupted cache

    Next: Clear application cache and test

コメントの追加（顧客に表示）：

Tool: SN-Add-Comment
Parameters:
  sys_id: [incident_sys_id]
  comment: "We are investigating your issue and have identified a potential cause. We will update you shortly with a solution."

作業中の状態遷移：

New (1) → In Progress (2) → On Hold (3) → In Progress (2) → Resolved (6)

状態の更新：

Tool: SN-Update-Record
Parameters:
  table_name: incident
  sys_id: [incident_sys_id]
  data:
    state: 2  # In Progress
    work_notes: "Starting investigation"

フェーズ 5：解決

修正内容を記録し、インシデントを解決します。

MCP を使用する場合：

Tool: SN-Resolve-Incident
Parameters:
  sys_id: [incident_sys_id]
  resolution_code: Solved (Permanently)
  resolution_notes: |
    Root Cause: Application cache was corrupted after update

    Resolution:
    1. Cleared application cache folder
    2. Restarted application service
    3. Verified user can now access the application

    Prevention: Scheduled cache cleanup added to maintenance window

解決コード：

• Solved (Permanently) - 問題を完全に解決しました
• Solved (Workaround) - 一時的な修正を適用しました
• Not Solved (Not Reproducible) - 問題を再現できませんでした
• Not Solved (Too Costly) - 修正の費用対効果が見合いません
• Closed/Resolved by Caller - ユーザー自身が解決しました

フェーズ 6：クローズ

ユーザーに確認し、インシデントをクローズします。

確認用の顧客コメントを追加：

Tool: SN-Add-Comment
Parameters:
  sys_id: [incident_sys_id]
  comment: "Your incident has been resolved. Please confirm the issue is fixed. If you don't respond within 3 business days, this incident will be automatically closed."

インシデントをクローズ：

Tool: SN-Close-Incident
Parameters:
  sys_id: [incident_sys_id]
  close_code: Solved (Permanently)
  close_notes: "User confirmed resolution. Closing incident."

状態フロー図

┌─────────┐    ┌────────────┐    ┌─────────┐
│   New   │───►│ In Progress│───►│ On Hold │
│   (1)   │    │    (2)     │◄───│   (3)   │
└────┬────┘    └─────┬──────┘    └─────────┘
     │               │
     │               ▼
     │         ┌──────────┐    ┌─────────┐
     └────────►│ Resolved │───►│ Closed  │
               │   (6)    │    │   (7)   │
               └──────────┘    └─────────┘

ツールの使用概要

フェーズ	MCP ツール	REST エンドポイント
作成	SN-Create-Incident	POST /incident
更新	SN-Update-Record	PATCH /incident/{id}
割り当て	SN-Assign-Incident	PATCH /incident/{id}
メモ	SN-Add-Work-Notes, SN-Add-Comment	POST /sys_journal_field
解決	SN-Resolve-Incident	PATCH /incident/{id}
クローズ	SN-Close-Incident	PATCH /incident/{id}

ベストプラクティス

• 定期的に更新する: 作業中は 30～60 分ごとに作業メモを追加します
• 顧客とのコミュニケーション: 主要な節目ごとにコメントを追加します
• 詳細な記録を残す: 今後発生するインシデントの対応に役立つよう、詳しいメモを残します
• 適切にクローズする: 可能な場合は、必ずユーザーの確認を得ます
• 関連レコードをリンクする: 問題、変更、ナレッジ記事に関連付けます

トラブルシューティング

状態を変更できない

原因: 状態遷移が許可されていないか、必須フィールドが未入力です
解決策: 状態遷移のルールを確認します。解決する前に、解決フィールドが設定されていることを確認します

作業メモが表示されない

原因: ジャーナルフィールドの権限に問題があるか、フィールド名が正しくありません
解決策: ロールの権限を確認します。内部メモには comments ではなく work_notes を使用します

インシデントが自動的に再オープンされる

原因: ユーザーが通知メールに返信しました
解決策: 受信メールアクションを確認し、返信を確認したことを作業メモに記録します

関連スキル

• itsm/incident-triage - 初期トリアージのプロセス
• itsm/major-incident - P1 インシデントの対応
• itsm/problem-analysis - 根本原因分析
• reporting/sla-analysis - SLA の追跡

References

• ServiceNow Incident Management
• ITIL 4 Incident Management Practice