关于 change-risk-explanation
此技能为 ServiceNow 变更请求生成风险说明,供变更经理和 CAB 审核使用。它结合 CI 影响范围、历史失败记录、部署时段和计划完整度,形成风险叙述及缓解建议。
主要功能
- 01评估 CI 关键性与影响范围
- 02分析历史变更失败率
- 03检查部署时段与并发冲突
- 04评估变更计划完整度
- 05生成风险说明与缓解建议
适用场景
- 01准备 CAB 审核的变更请求
- 02解释自动风险评估结果
- 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 | 根据描述查找类似的历史变更 | 为故障分析匹配模式 |
最佳实践
- 基于数据评估风险,而非凭空假设——使用历史故障率和 CI 的实际关键程度
- 分析影响范围——对一个 CI 的变更可能沿依赖关系逐级扩散
- 考虑业务背景——同一项变更在季度末和季度中期的风险不同
- 提出缓解措施,而不只是指出风险——每项已识别的风险都应有相应的缓解措施
- 评估计划质量——回退计划不完整会显著增加风险
- 检查变更冲突——对相关 CI 的并发变更会叠加风险
- 考虑团队经验——首次在不熟悉的系统上实施变更,风险更高
- 记录假设——说明使用了哪些数据,以及分析中的任何缺口
- 随着变更推进更新风险评估——范围、时间或 CI 发生变化时重新评估
- 使用一致的评分标准——对所有变更应用同一风险模型,以便进行比较
故障排除
| 问题 | 原因 | 解决方法 |
|---|---|---|
| 未找到 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