mcpField
C
change-risk-explanation

change-risk-explanation

github.com/happy-technologies-llc云与 DevOps4141 次安装2 天前更新
代码仓库

关于 change-risk-explanation

此技能为 ServiceNow 变更请求生成风险说明,供变更经理和 CAB 审核使用。它结合 CI 影响范围、历史失败记录、部署时段和计划完整度,形成风险叙述及缓解建议。

主要功能

  1. 01评估 CI 关键性与影响范围
  2. 02分析历史变更失败率
  3. 03检查部署时段与并发冲突
  4. 04评估变更计划完整度
  5. 05生成风险说明与缓解建议

适用场景

  1. 01准备 CAB 审核的变更请求
  2. 02解释自动风险评估结果
  3. 03为利益相关方总结变更影响

MCP 相关

该技能通过 MCP 调用 ServiceNow 工具读取变更、CI 和历史记录,并可将风险说明写回变更记录或任务。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill change-risk-explanation

安装后在 Claude Code 中输入/change-risk-explanation确认已加载。

详细介绍

变更风险说明生成

概述

此技能介绍如何为 ServiceNow 变更请求生成全面的风险说明:

  • 分析变更范围,评估影响广度(受影响的 CI、服务和用户数量)
  • 评估受影响的配置项及其关键性等级
  • 计算类似变更和受影响 CI 的历史变更失败率
  • 评估部署窗口风险,包括时间安排、维护窗口和业务周期
  • 为 CAB 审核和审批工作流生成易于理解的风险说明
  • 根据已识别的风险因素提供风险缓解建议

适用场景: 准备提交 CAB 审核的变更请求、自动化风险评估需要生成易于理解的说明、变更经理需要说明风险评级的依据,或利益相关者要求提供风险影响摘要时。

前提条件

  • 角色: change_manager、itil 或 admin
  • 插件: com.snc.change_management(变更管理)、com.snc.cmdb(CMDB)
  • 访问权限: 对 change_request、task_ci、cmdb_ci、cmdb_rel_ci 表具有读取权限
  • 数据: 已填充 CI 关系和变更计划的变更请求
  • 相关技能: itsm/change-management(了解变更生命周期)、cmdb/impact-analysis(进行 CI 影响分析)

操作步骤

步骤 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. 分析影响范围——对一个 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 - 变更成功/失败趋势分析

评论

支持 Markdown