change-risk-explanation

変更リスクの説明生成

概要

このスキルでは、ServiceNow の変更リクエストについて、包括的なリスク説明を生成します。

• 変更範囲を分析し、影響の広さ（影響を受ける CI、サービス、ユーザーの数）を評価する
• 影響を受ける構成アイテムとその重要度レベルを評価する
• 類似の変更や影響を受ける CI に関する過去の変更失敗率を計算する
• タイミング、メンテナンスウィンドウ、ビジネスサイクルなど、デプロイウィンドウのリスクを評価する
• CAB のレビューおよび承認ワークフロー向けに、人が読みやすいリスク説明文を生成する
• 特定されたリスク要因に基づいて、リスク軽減策を提案する

使用する場面： CAB のレビューに向けて変更リクエストを準備するとき、自動リスク評価に人が読みやすい説明が必要なとき、変更マネージャーがリスク評価を正当化する必要があるとき、またはステークホルダーがリスク影響の要約を求めるときです。

前提条件

• ロール： change_manager、itil、または admin
• プラグイン： com.snc.change_management（Change Management）、com.snc.cmdb（CMDB）
• アクセス権： change_request、task_ci、cmdb_ci、cmdb_rel_ci テーブルへの読み取りアクセス
• データ： CI の関連付けと変更計画が入力済みの変更リクエスト
• 関連スキル： 変更ライフサイクルについては itsm/change-management、CI の影響分析については cmdb/impact-analysis

手順

ステップ 1：変更リクエストの詳細を取得する

リスクに関連するすべてのフィールドを含む変更リクエストのレコードを取得します。

MCP での方法：

Tool: SN-Get-Record
Parameters:
  table_name: change_request
  sys_id: [CHG_SYS_ID]
  fields: sys_id,number,short_description,description,type,category,risk,impact,priority,state,start_date,end_date,planned_start_date,planned_end_date,change_plan,backout_plan,test_plan,assignment_group,assigned_to,requested_by,cmdb_ci,business_service,risk_impact_analysis,conflict_status,conflict_last_run,cab_required,scope,implementation_plan

REST での方法：

GET /api/now/table/change_request/[CHG_SYS_ID]
  ?sysparm_fields=sys_id,number,short_description,description,type,category,risk,impact,priority,state,start_date,end_date,planned_start_date,planned_end_date,change_plan,backout_plan,test_plan,assignment_group,assigned_to,cmdb_ci,business_service,risk_impact_analysis,scope
  &sysparm_display_value=true

ステップ 2：影響を受ける構成アイテムを特定する

変更リクエストに関連付けられたすべての CI を取得します。

MCP での方法：

Tool: SN-Query-Table
Parameters:
  table_name: task_ci
  query: task=[CHG_SYS_ID]
  fields: sys_id,ci_item,ci_item.name,ci_item.sys_class_name,ci_item.operational_status,ci_item.busines_criticality
  limit: 50

REST での方法：

GET /api/now/table/task_ci
  ?sysparm_query=task=[CHG_SYS_ID]
  &sysparm_fields=sys_id,ci_item
  &sysparm_display_value=true

影響を受ける各 CI の詳細を取得します。

Tool: SN-Get-Record
Parameters:
  table_name: cmdb_ci
  sys_id: [CI_SYS_ID]
  fields: sys_id,name,sys_class_name,operational_status,busines_criticality,environment,support_group,location,used_for,managed_by

ステップ 3：CI の関係と影響範囲を分析する

影響を受ける CI の変更による下流への影響を特定します。

MCP での方法：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_rel_ci
  query: parent=[CI_SYS_ID]^type.name=Depends on::Used by
  fields: sys_id,parent,child,type,child.name,child.sys_class_name,child.busines_criticality
  limit: 100

REST での方法：

GET /api/now/table/cmdb_rel_ci
  ?sysparm_query=parent=[CI_SYS_ID]^type.name=Depends on::Used by
  &sysparm_fields=sys_id,parent,child,type
  &sysparm_display_value=true

影響範囲の評価を作成します。

BLAST RADIUS ANALYSIS:

Directly Affected CIs: [count]
  Tier 1 (Critical): [count]
  Tier 2 (High): [count]
  Tier 3 (Medium/Low): [count]

Downstream Dependencies: [count]
  Services Affected: [list]
  Users Potentially Impacted: [estimated count]
  Business Processes: [list]

ステップ 4：過去の変更失敗率を計算する

同じ CI またはカテゴリに対する過去の変更を照会し、失敗の可能性を評価します。

MCP での方法：

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: cmdb_ci=[CI_SYS_ID]^state=closed^sys_created_on>=javascript:gs.monthsAgo(12)
  fields: sys_id,number,close_code,state,risk,category,type
  limit: 100

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: category=[SAME_CATEGORY]^state=closed^sys_created_on>=javascript:gs.monthsAgo(12)
  fields: sys_id,number,close_code,state,risk
  limit: 200

失敗率の計算：

指標	計算式	リスクレベル
CI 失敗率	CI での失敗した変更数 / CI での変更総数	>20% = 高、10-20% = 中、<10% = 低
カテゴリ失敗率	カテゴリ内の失敗した変更数 / カテゴリ内の変更総数	>15% = 高、5-15% = 中、<5% = 低
チーム失敗率	チームによる失敗した変更数 / チームによる変更総数	>10% = 高、5-10% = 中、<5% = 低
直近の傾向	過去 3 か月の失敗件数とその前の 9 か月の比較	増加傾向 = リスク上昇

HISTORICAL CHANGE ANALYSIS:

Changes on [CI Name] (Last 12 Months):
Total: [count] | Successful: [count] | Failed: [count] | Failure Rate: [%]

Changes in [Category] (Last 12 Months):
Total: [count] | Successful: [count] | Failed: [count] | Failure Rate: [%]

Recent Failures on Same CI:
- [CHG#] ([date]): [short description] - [failure reason]
- [CHG#] ([date]): [short description] - [failure reason]

ステップ 5：デプロイウィンドウのリスクを評価する

予定されている変更のタイミングとウィンドウを評価します。

MCP での方法：

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: planned_start_date>=javascript:gs.daysAgo(-7)^planned_start_dateONNext 7 days@javascript:gs.beginningOfToday()@javascript:gs.endOfNext(new GlideDateTime(), 7)^state!=closed^state!=canceled
  fields: sys_id,number,short_description,planned_start_date,planned_end_date,cmdb_ci,conflict_status
  limit: 50

ウィンドウのリスク要因：

要因	低リスク	中リスク	高リスク
時刻	メンテナンスウィンドウ（午前 2～6 時）	ピーク時間外	営業時間中
曜日	土曜日／日曜日	火曜日～木曜日	月曜日／金曜日
ビジネスカレンダー	通常期間	月末前後	月末／四半期末／年末
変更凍結	凍結なし	凍結が近い	凍結期間中
同時進行の変更	予定なし	低リスクの変更が 1～2 件	複数または競合する変更
ロールバックウィンドウ	4 時間超を確保	2～4 時間	2 時間未満

ステップ 6：変更計画の完全性を評価する

変更計画、テスト計画、バックアウト計画が適切かどうかを評価します。

PLAN COMPLETENESS ASSESSMENT:

Change Plan:
- [ ] Step-by-step implementation instructions: [Present/Missing]
- [ ] Estimated duration per step: [Present/Missing]
- [ ] Responsible parties identified: [Present/Missing]
- [ ] Pre-implementation checklist: [Present/Missing]
- [ ] Communication plan: [Present/Missing]

Test Plan:
- [ ] Test scenarios defined: [Present/Missing]
- [ ] Expected results documented: [Present/Missing]
- [ ] Test environment specified: [Present/Missing]
- [ ] Validation steps after implementation: [Present/Missing]

Backout Plan:
- [ ] Rollback procedure documented: [Present/Missing]
- [ ] Rollback time estimate: [Present/Missing]
- [ ] Data backup strategy: [Present/Missing]
- [ ] Go/No-Go decision criteria: [Present/Missing]
- [ ] Escalation contacts: [Present/Missing]

COMPLETENESS SCORE: [X/14] items present

ステップ 7：リスクスコアを生成する

すべての要因に基づいて、総合的なリスクスコアを計算します。

RISK SCORING MODEL:

| Factor | Weight | Score (1-5) | Weighted |
|--------|--------|-------------|----------|
| CI Criticality | 25% | [score] | [weighted] |
| Blast Radius | 20% | [score] | [weighted] |
| Historical Failure Rate | 20% | [score] | [weighted] |
| Deployment Window | 15% | [score] | [weighted] |
| Plan Completeness | 10% | [score] | [weighted] |
| Change Complexity | 10% | [score] | [weighted] |
|                  |      | TOTAL: | [sum] |

RISK LEVEL:
1.0-2.0: Low Risk (Standard change candidate)
2.1-3.0: Moderate Risk (Normal change approval)
3.1-4.0: High Risk (CAB review required)
4.1-5.0: Critical Risk (Executive approval required)

CALCULATED RISK: [score] - [LEVEL]

ステップ 8：リスク説明文を生成する

すべての情報をまとめ、人が読みやすいリスク説明文を作成します。

MCP での方法：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [CHG_SYS_ID]
  data:
    risk_impact_analysis: |
      CHANGE RISK ASSESSMENT: [CHG Number]
      Overall Risk: [HIGH/MODERATE/LOW] (Score: [X]/5.0)
      Generated: [date]

      EXECUTIVE SUMMARY:
      This change request involves [brief scope description] affecting [count]
      configuration items including [critical CI names]. The primary risk factors
      are [top 2-3 risk factors]. Historical data shows a [X]% failure rate for
      similar changes on these systems. The proposed deployment window
      [supports/raises concerns about] successful implementation.

      SCOPE ANALYSIS:
      The change directly affects [count] CIs across [count] services.
      [Count] of these are classified as Tier 1 (business critical).
      Downstream dependency analysis identifies [count] additional CIs
      that could be impacted if the change causes unexpected behavior.
      Estimated user impact: [count] users across [departments/locations].

      HISTORICAL RISK:
      Over the past 12 months, [count] similar changes have been executed
      on the affected systems with a [X]% success rate. Notable failures:
      - [CHG#] ([date]): [brief failure description and root cause]
      [If failure rate is high]: This elevated failure rate warrants
      additional testing and a robust backout plan.

      DEPLOYMENT WINDOW ASSESSMENT:
      The planned window ([date/time range]) [is within/falls outside]
      the standard maintenance window. [Count] concurrent changes are
      scheduled. The available rollback window is [duration].
      [Specific timing risks if any].

      PLAN ASSESSMENT:
      [Assessment of change plan, test plan, and backout plan completeness]
      [Specific gaps or concerns identified]

      RISK MITIGATION RECOMMENDATIONS:
      1. [Recommendation based on highest risk factor]
      2. [Recommendation for deployment approach]
      3. [Recommendation for monitoring/validation]
      4. [Recommendation for communication]

      APPROVAL RECOMMENDATION:
      [Recommend approval / Recommend approval with conditions / Recommend deferral]
      [Conditions if applicable]

ステップ 9：変更タスクにリスクの詳細を追加する

個々の変更タスクに対する具体的なリスクを記録します。

MCP での方法：

Tool: SN-Query-Table
Parameters:
  table_name: change_task
  query: change_request=[CHG_SYS_ID]^ORDERBYplanned_start_date
  fields: sys_id,number,short_description,state,planned_start_date,planned_end_date,assigned_to
  limit: 20

リスクの高いタスクには、リスクに関するメモを追加します。

Tool: SN-Update-Record
Parameters:
  table_name: change_task
  sys_id: [TASK_SYS_ID]
  data:
    work_notes: |
      RISK NOTE: This task involves [specific risk].
      Mitigation: [specific mitigation step].
      Rollback trigger: If [condition], execute backout plan step [X].

ステップ 10：必要に応じてリスクレコードを作成する

リスクの高い変更について、正式なリスクレコードを作成します。

MCP での方法：

Tool: SN-Create-Record
Parameters:
  table_name: risk
  data:
    task: [CHG_SYS_ID]
    short_description: "Change failure risk for [CHG Number] affecting [Critical CI]"
    category: "Operational"
    probability: [1-5]
    impact: [1-5]
    response: "mitigate"
    mitigation_plan: "[Specific mitigation actions]"
    assigned_to: [CHANGE_MANAGER_SYS_ID]
    state: "open"

ツールの使用方法

ツール	目的	使用するタイミング
SN-Query-Table	CI、過去の変更、関連性を取得する	データ収集と分析
SN-Get-Record	変更リクエストとCIの詳細を取得する	レコードの詳細な調査
SN-Update-Record	変更レコードにリスクの説明を書き込む	リスク評価の記録
SN-Natural-Language-Search	説明から過去の類似変更を検索する	障害分析のためのパターン照合

ベストプラクティス

1. 推測ではなくデータに基づいてリスクを判断します -- 過去の障害率と実際のCIの重要度を使用します
2. 影響範囲の分析を含めます -- 1つのCIへの変更が依存関係を通じて波及する可能性があります
3. ビジネス上の背景を考慮します -- 同じ変更でも、四半期末と四半期中盤ではリスクが異なります
4. リスクだけでなく緩和策も提案します -- 特定したリスクごとに、緩和策を提案します
5. 計画の品質を評価します -- 不完全なロールバック計画はリスクを大幅に高めます
6. 変更の衝突を確認します -- 関連するCIに対する同時変更はリスクを複合的に高めます
7. チームの経験を考慮します -- 不慣れなシステムに対する初めての変更は、より高いリスクを伴います
8. 前提条件を記録します -- 使用したデータと分析上の不足点を明記します
9. 変更の進行に合わせてリスクを更新します -- 範囲、タイミング、またはCIが変更されたら再評価します
10. 一貫したスコアリングを使用します -- 比較できるよう、すべての変更に同じリスクモデルを適用します

トラブルシューティング

問題	原因	解決方法
CIの関連性が見つからない	CIが変更リクエストに関連付けられていない	task_ci テーブルを確認します。CIを手動でリンクする必要がある場合があります
過去のデータが不十分	CIが新しい、または変更頻度が低い	代わりにカテゴリー単位の障害率を使用し、評価にデータ上の制約を記載します
競合検出が実行されていない	競合分析が開始されていない	競合検出を手動で実行するか、conflict_last_run のタイムスタンプを確認します
リスクスコアが低すぎるように見える	重要な要素が適切に重み付けされていない	スコアリングの重みを見直し、CIの重要度データが正確であることを確認します
影響範囲が広すぎる	CIにCMDB上の関連性が過剰にある	直接の依存関係のみに絞り、監視およびディスカバリーの関連性を除外します
変更計画のフィールドが空	変更計画がレコードのフィールドではなく添付ファイルにある	添付ファイルを確認し、評価用に計画の内容を抽出します

例

例1：データベースアップグレードのリスク説明

変更： 本番ERPサーバーのOracleデータベースを19cから21cにアップグレードします。

RISK ASSESSMENT: CHG0045678
Overall Risk: HIGH (Score: 3.8/5.0)

KEY FACTORS:
- Tier 1 CI (ERP Database) serving 2,500 users
- 3 downstream application dependencies
- 2 prior database upgrades on this CI: 1 successful, 1 rolled back (50% failure rate)
- 4-hour deployment window with 2-hour rollback window
- Change scheduled during month-end processing period

RECOMMENDATION: Defer to post-month-end window. If timeline is fixed,
add DBA on standby and extend maintenance window to 6 hours.

例2：ネットワークスイッチのファームウェア更新

変更： ビルディングCのアクセスレイヤースイッチのファームウェアを更新します。

RISK ASSESSMENT: CHG0045702
Overall Risk: LOW (Score: 1.6/5.0)

KEY FACTORS:
- Tier 3 CIs (access switches), 150 users affected
- Same firmware update applied to 12 switches last month with 100% success
- Scheduled during maintenance window (Sunday 2-6 AM)
- Automated rollback available via TFTP backup config
- No concurrent changes in network domain

RECOMMENDATION: Approve as standard change. No additional mitigations needed.

関連スキル

• itsm/change-management - 変更管理のライフサイクル全体
• cmdb/impact-analysis - CIの影響および依存関係の分析
• cmdb/relationship-mapping - CMDBの関連性の検出
• itsm/major-incident - 重大インシデント管理（変更が失敗した場合）
• reporting/trend-analysis - 変更の成功／失敗の傾向分析