mcpField
C
change-management

change-management

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

关于 change-management

此技能为 ServiceNow 变更管理提供符合 ITIL 的全生命周期操作指导，面向变更管理人员和 CAB 成员。内容涵盖 RFC 创建、审批、实施、风险评估及实施后审查，并区分常规、标准和紧急变更。

主要功能

  1. 01创建常规、标准和紧急变更请求
  2. 02编写实施、回退和测试计划
  3. 03准备 CAB 审查与审批
  4. 04跟踪实施任务和进度
  5. 05记录实施后审查并关闭请求

适用场景

  1. 01为生产系统变更准备 RFC 和风险材料
  2. 02安排 CAB 审查并处理变更审批
  3. 03记录实施过程并完成实施后审查

MCP 相关

该技能说明如何通过 ServiceNow MCP 工具创建、查询、更新和审批变更请求及任务，也列出对应的 REST API 操作。

安装

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

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

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

详细介绍

变更管理生命周期

概述

本技能提供在 ServiceNow 中依照 ITIL 最佳实践管理变更的端到端指南，涵盖从创建变更请求（RFC）到实施后评审（PIR）的完整生命周期。

变更管理目标：

  • 最大限度降低服务中断风险
  • 确保获得适当授权并做好文档记录
  • 实现受控的变更实施
  • 通过 PIR 推动持续改进

涵盖的变更类型：

  • Normal： 标准审批工作流，由 CAB 评审
  • Standard： 预先批准的低风险、可重复变更
  • Emergency： 针对紧急修复的快速处理流程

前提条件

  • 角色： itil、change_manager 或 cab_member
  • 访问权限： 对 change_request、change_task 表具有读写权限
  • 知识： 变更管理流程、CAB 规程
  • 相关技能： itsm/problem-analysis（用于实施修复）

流程

阶段 1：创建 RFC
步骤 1.1：创建普通变更请求

使用 MCP：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[Action] [CI/Service] - [Brief purpose]"
    description: |
      CHANGE OVERVIEW:
      [Detailed description of what will be changed]

      BUSINESS JUSTIFICATION:
      [Why this change is needed]

      SCOPE:
      - In Scope: [What is included]
      - Out of Scope: [What is explicitly excluded]

      AFFECTED SERVICES/CIS:
      - [Service/CI 1]
      - [Service/CI 2]

      DEPENDENCIES:
      - [Dependency 1]
      - [Dependency 2]
    type: normal
    category: [Hardware/Software/Network/Other]
    priority: 3
    risk: moderate
    impact: 2
    assignment_group: [implementation_team_sys_id]
    cmdb_ci: [affected_ci_sys_id]
    requested_by: [requester_sys_id]
    start_date: [planned_start]
    end_date: [planned_end]

使用 REST API：

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

{
  "short_description": "Upgrade Database Server - Production CRM",
  "description": "CHANGE OVERVIEW:\nUpgrade Oracle database from 19c to 21c...",
  "type": "normal",
  "category": "Software",
  "priority": "3",
  "risk": "moderate",
  "impact": "2",
  "assignment_group": "group_sys_id",
  "cmdb_ci": "ci_sys_id",
  "start_date": "2024-02-15 22:00:00",
  "end_date": "2024-02-16 02:00:00"
}
步骤 1.2：创建标准变更请求

首先，查找已批准的标准变更模板：

Tool: SN-Query-Table
Parameters:
  table_name: std_change_catalog
  query: active=true^namLIKE[keyword]
  fields: sys_id,name,short_description,template
  limit: 10

根据模板创建：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[Standard change description]"
    description: |
      STANDARD CHANGE EXECUTION:
      Template: [Template name]

      SPECIFIC DETAILS FOR THIS INSTANCE:
      - Target System: [system]
      - Scheduled Date: [date]
      - Requestor: [name]
    type: standard
    std_change_producer_version: [template_sys_id]
    category: [from template]
    assignment_group: [implementation_team]
    cmdb_ci: [target_ci]
    start_date: [planned_start]
    end_date: [planned_end]
步骤 1.3：创建紧急变更请求

紧急变更可绕过常规 CAB 流程，但仍须记录文档：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[EMERGENCY] [Brief description of urgent fix]"
    description: |
      === EMERGENCY CHANGE REQUEST ===

      EMERGENCY JUSTIFICATION:
      [Why this cannot wait for normal change process]

      INCIDENT REFERENCE:
      [Related incident number if applicable]

      IMMEDIATE RISK IF NOT IMPLEMENTED:
      - [Risk 1]
      - [Risk 2]

      PROPOSED CHANGE:
      [What will be done]

      MINIMAL TESTING PERFORMED:
      [Testing done given time constraints]

      VERBAL APPROVAL:
      - Approved by: [name]
      - Time: [timestamp]
      - Method: [phone/in-person]
    type: emergency
    category: [category]
    priority: 1
    risk: high
    impact: 1
    assignment_group: [implementation_team]
    cmdb_ci: [affected_ci]
    reason: |
      EMERGENCY REASON:
      [Detailed reason for emergency classification]
    start_date: [immediate]
    end_date: [expected_completion]
阶段 2：变更文档记录
步骤 2.1：实施计划

添加详细的实施计划：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    implementation_plan: |
      === IMPLEMENTATION PLAN ===

      PRE-IMPLEMENTATION:
      Time: [start] - [time]

      1. [ ] Notify stakeholders of maintenance window
         Responsible: [name]

      2. [ ] Verify backup completion
         Responsible: [name]

      3. [ ] Confirm rollback resources available
         Responsible: [name]

      4. [ ] Place system in maintenance mode
         Responsible: [name]

      IMPLEMENTATION:
      Time: [time] - [time]

      5. [ ] [Step 5 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      6. [ ] [Step 6 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      7. [ ] [Step 7 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      VERIFICATION:
      Time: [time] - [time]

      8. [ ] Run verification tests
         Test Script: [location]
         Expected Results: [description]

      9. [ ] Confirm user access
         Test Users: [list]

      10. [ ] Monitor system for 30 minutes
          Metrics to watch: [list]

      POST-IMPLEMENTATION:
      Time: [time] - [end]

      11. [ ] Remove maintenance mode

      12. [ ] Send completion notification

      13. [ ] Update documentation
步骤 2.2：回退/回滚计划
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    backout_plan: |
      === BACKOUT/ROLLBACK PLAN ===

      ROLLBACK DECISION CRITERIA:
      Initiate rollback if ANY of the following occur:
      - [ ] Implementation step fails and cannot be resolved in [X] minutes
      - [ ] Verification tests fail
      - [ ] Service degradation exceeds [threshold]
      - [ ] Unexpected errors in logs
      - [ ] [Other criteria]

      ROLLBACK POINT OF NO RETURN:
      After step [X], rollback becomes significantly more complex.
      Decision to proceed or rollback must be made by: [time]

      ROLLBACK PROCEDURE:
      Estimated Duration: [X minutes]

      1. [ ] Stop current implementation
         Action: [specific action]

      2. [ ] Restore from backup
         Backup Location: [location]
         Restore Command: [command]
         Expected Duration: [X minutes]

      3. [ ] Verify service restoration
         Test: [test procedure]

      4. [ ] Remove maintenance mode

      5. [ ] Notify stakeholders of rollback
         Communication: [template/channel]

      ROLLBACK VERIFICATION:
      - [ ] Service accessible
      - [ ] User authentication working
      - [ ] Core functions verified
      - [ ] No data loss confirmed

      POST-ROLLBACK:
      - Document reason for rollback
      - Create problem ticket if root cause unknown
      - Schedule re-attempt after analysis
步骤 2.3：测试计划
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    test_plan: |
      === TEST PLAN ===

      PRE-CHANGE BASELINE:
      Capture current state for comparison
      - [ ] System performance metrics: [specific metrics]
      - [ ] Current version info: [how to capture]
      - [ ] User count/active sessions: [query/tool]

      SMOKE TESTS:
      Quick tests to verify basic functionality

      | Test | Action | Expected Result | Pass/Fail |
      |------|--------|-----------------|-----------|
      | Login | Admin login | Dashboard loads | |
      | Core Function | [action] | [expected] | |
      | API | [endpoint] | 200 OK | |
      | Database | [query] | [expected] | |

      FUNCTIONAL TESTS:
      Detailed functionality verification

      | Test ID | Test Case | Steps | Expected | Actual | Pass/Fail |
      |---------|-----------|-------|----------|--------|-----------|
      | FT-001 | [name] | [steps] | [expected] | | |
      | FT-002 | [name] | [steps] | [expected] | | |
      | FT-003 | [name] | [steps] | [expected] | | |

      PERFORMANCE TESTS:
      Compare against baseline

      | Metric | Baseline | Post-Change | Threshold | Pass/Fail |
      |--------|----------|-------------|-----------|-----------|
      | Response Time | [X]ms | | <[Y]ms | |
      | CPU Usage | [X]% | | <[Y]% | |
      | Memory | [X]GB | | <[Y]GB | |

      USER ACCEPTANCE:
      - Test User: [name]
      - Test Scenario: [description]
      - Sign-off Required: Yes/No
阶段 3：CAB 准备与排期
步骤 3.1：安排 CAB 评审

更新变更以供 CAB 评审：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -4  # Assess
    cab_required: true
    cab_date: [cab_meeting_date]
    work_notes: |
      === CAB SUBMISSION ===

      Submitted for CAB Review: [date]
      Target CAB Meeting: [date/time]

      CAB Preparation Checklist:
      - [x] Implementation plan complete
      - [x] Backout plan complete
      - [x] Test plan complete
      - [x] Risk assessment complete
      - [x] Stakeholders identified
      - [x] Communication plan ready

      Additional Materials:
      - [Link to supporting documentation]
      - [Architecture diagram reference]
步骤 3.2：创建 CAB 演示摘要
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === CAB PRESENTATION SUMMARY ===

    CHANGE: [CHG#]
    TITLE: [Short description]
    REQUESTOR: [Name/Team]

    WHAT:
    [One paragraph summary of the change]

    WHY:
    [Business justification in 2-3 sentences]

    WHEN:
    - Proposed Start: [date/time]
    - Proposed End: [date/time]
    - Duration: [X hours]
    - Maintenance Window: [Yes/No - description]

    WHO IS AFFECTED:
    - Users: [groups/count]
    - Services: [list]
    - Regions: [if applicable]

    RISK ASSESSMENT:
    - Risk Level: [Low/Moderate/High]
    - Impact if Fails: [description]
    - Likelihood of Failure: [Low/Medium/High]

    MITIGATION:
    - [Key mitigation 1]
    - [Key mitigation 2]

    ROLLBACK:
    - Rollback possible: [Yes/No]
    - Rollback time: [X minutes/hours]
    - Point of no return: [time/step]

    DEPENDENCIES:
    - [Other changes/freezes/events]

    APPROVAL REQUESTED:
    [Standard/Expedited approval request]
步骤 3.3：查询已排期的 CAB 变更

查找所有已安排 CAB 评审的变更：

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: cab_required=true^cab_date>=javascript:gs.beginningOfToday()^cab_dateONThis week@javascript:gs.beginningOfThisWeek()@javascript:gs.endOfThisWeek()^state=-4
  fields: number,short_description,cab_date,requested_by,assignment_group,risk,priority
  order_by: cab_date
阶段 4：变更审批
步骤 4.1：检查审批状态
Tool: SN-Query-Table
Parameters:
  table_name: sysapproval_approver
  query: document_id=[change_sys_id]
  fields: sys_id,approver,state,comments,sys_updated_on
步骤 4.2：批准变更（审批人操作）

使用 MCP：

Tool: SN-Approve-Change
Parameters:
  sys_id: [change_sys_id]
  approval_state: approved
  comments: |
    Approved based on:
    - Risk assessment reviewed and acceptable
    - Implementation plan verified complete
    - Rollback plan adequate
    - Testing plan comprehensive
    - Change window appropriate

    Conditions:
    - [Any conditions for approval]

使用 REST API：

PATCH /api/now/table/sysapproval_approver/{approver_sys_id}
Content-Type: application/json

{
  "state": "approved",
  "comments": "Approved based on:\n- Risk assessment reviewed..."
}

拒绝变更：

Tool: SN-Approve-Change
Parameters:
  sys_id: [change_sys_id]
  approval_state: rejected
  comments: |
    Change rejected for the following reasons:

    1. [Reason 1]
    2. [Reason 2]

    Required remediation before resubmission:
    - [Action 1]
    - [Action 2]

    Please address these concerns and resubmit.
步骤 4.3：将状态改为已排期

批准后：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -1  # Scheduled
    work_notes: |
      === CHANGE APPROVED AND SCHEDULED ===

      Approval Received: [date]
      Approved By: [names]

      Implementation Window:
      Start: [date/time]
      End: [date/time]

      Pre-Implementation Meeting: [date/time if scheduled]

      Go/No-Go Decision Time: [time before start]
阶段 5：实施
步骤 5.1：创建实施任务

使用 MCP：

Tool: SN-Create-Record
Parameters:
  table_name: change_task
  data:
    parent: [change_sys_id]
    change_task_type: planning
    short_description: "Pre-Implementation: [Task description]"
    description: |
      PRE-IMPLEMENTATION TASK

      Objective: [What needs to be done]

      Steps:
      1. [Step 1]
      2. [Step 2]

      Deliverables:
      - [Deliverable 1]

      Completion Criteria:
      - [How to know it's done]
    assignment_group: [team]
    assigned_to: [person]
    planned_start_date: [start]
    planned_end_date: [end]

标准任务类型：

  • planning - 实施前准备
  • implementation - 实际执行变更
  • testing - 验证与测试
  • review - 实施后评审
步骤 5.2：开始实施

将变更状态更新为“实施中”：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -2  # Implement
    work_notes: |
      === IMPLEMENTATION STARTED ===

      Time: [timestamp]
      Implementation Lead: [name]

      Go Decision Made By: [name]
      Go Criteria Met:
      - [x] Backup verified
      - [x] Rollback team on standby
      - [x] Stakeholders notified
      - [x] Maintenance mode active

      Starting implementation step 1...
步骤 5.3：记录实施进度
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === IMPLEMENTATION LOG ===

    [HH:MM] - Step [X]: [Description]
    Status: COMPLETE
    Notes: [Any observations]

    [HH:MM] - Step [X+1]: [Description]
    Status: IN PROGRESS

    Current Overall Status: ON TRACK / DELAYED / AT RISK

    Issues Encountered:
    - [Issue if any, or "None"]

    Next Milestone: [Description] at [time]
步骤 5.4：完成实施
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: 0  # Review
    work_notes: |
      === IMPLEMENTATION COMPLETE ===

      Completion Time: [timestamp]

      IMPLEMENTATION SUMMARY:
      - All steps executed successfully: [Yes/No]
      - Deviations from plan: [None/Description]
      - Issues encountered: [None/Description]

      VERIFICATION RESULTS:
      - Smoke tests: PASS/FAIL
      - Functional tests: PASS/FAIL
      - Performance tests: PASS/FAIL

      POST-IMPLEMENTATION STATUS:
      - Service operational: Yes
      - Users notified: Yes
      - Monitoring active: Yes

      Ready for PIR: Yes
阶段 6：实施后评审（PIR）
步骤 6.1：安排 PIR
Tool: SN-Create-Record
Parameters:
  table_name: change_task
  data:
    parent: [change_sys_id]
    change_task_type: review
    short_description: "Post-Implementation Review - [CHG#]"
    description: |
      POST-IMPLEMENTATION REVIEW

      Meeting Details:
      Date: [date]
      Time: [time]
      Location/Call: [details]

      Required Attendees:
      - Change Owner
      - Implementation Team
      - Technical Approvers
      - Service Owner (optional)

      Agenda:
      1. Change summary (5 min)
      2. Implementation review (10 min)
      3. What went well (10 min)
      4. What could improve (10 min)
      5. Action items (10 min)
      6. Lessons learned (5 min)
    assigned_to: [change_owner]
    planned_start_date: [pir_date]
步骤 6.2：记录 PIR 结果
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === POST-IMPLEMENTATION REVIEW ===

    PIR Date: [date]
    Attendees: [list]

    CHANGE OUTCOME: [Successful/Successful with Issues/Partial/Failed/Rolled Back]

    METRICS:
    - Planned Duration: [X hours]
    - Actual Duration: [Y hours]
    - Variance: [+/- Z hours]
    - User Impact: [None/Minimal/Moderate/Significant]

    WHAT WENT WELL:
    1. [Positive outcome 1]
    2. [Positive outcome 2]
    3. [Positive outcome 3]

    WHAT COULD BE IMPROVED:
    1. [Improvement area 1]
    2. [Improvement area 2]
    3. [Improvement area 3]

    DEVIATIONS FROM PLAN:
    - [Deviation 1 and why]
    - [Deviation 2 and why]

    ACTION ITEMS:
    1. [Action] - Owner: [name] - Due: [date]
    2. [Action] - Owner: [name] - Due: [date]

    LESSONS LEARNED:
    - [Lesson that should be shared]
    - [Process improvement suggestion]

    PIR STATUS: Complete
步骤 6.3：关闭变更请求
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: 3  # Closed
    close_code: successful
    close_notes: |
      CHANGE CLOSURE SUMMARY

      Change: [CHG#]
      Title: [Short description]

      Result: SUCCESSFUL

      Implementation Date: [date]
      Implementation Duration: [X hours]

      Benefits Realized:
      - [Benefit 1]
      - [Benefit 2]

      Documentation Updated:
      - [ ] CMDB updated
      - [ ] Knowledge base updated
      - [ ] Runbooks updated

      PIR Complete: Yes
      PIR Date: [date]

      No outstanding issues.

关闭代码选项：

  • successful - 按计划实施变更
  • successful_issues - 已实施，但存在轻微问题
  • unsuccessful - 变更失败或已回滚

变更状态流转

┌────────────┐    ┌──────────┐    ┌───────────┐    ┌───────────┐
│    New     │───►│  Assess  │───►│ Authorize │───►│ Scheduled │
│   (-5)     │    │   (-4)   │    │   (-3)    │    │   (-1)    │
└────────────┘    └──────────┘    └───────────┘    └─────┬─────┘
                                                         │
┌────────────┐    ┌──────────┐    ┌───────────┐         │
│   Closed   │◄───│  Review  │◄───│ Implement │◄────────┘
│    (3)     │    │   (0)    │    │   (-2)    │
└────────────┘    └──────────┘    └───────────┘
                        │
                        └───────► Canceled (4)

风险评估矩阵

风险级别影响可能性审批测试
低轻微不太可能自动/经理最少
中等显著可能CAB标准
高重大很可能CAB + 高管全面
严重极严重几乎确定董事会级别完整回归测试

工具使用摘要

MCP 工具
工具用途阶段
SN-List-ChangeRequests按条件列出变更所有
SN-Create-Record创建变更和任务1、5、6
SN-Update-Record更新变更状态和计划2-6
SN-Add-Work-Notes记录所有活动所有
SN-Add-Change-Comment与利益相关者沟通3、5
SN-Assign-Change分配给团队/个人1、5
SN-Approve-Change批准/拒绝变更4
SN-Query-Table查询审批和任务所有
REST API 端点
端点方法用途
/api/now/table/change_requestGET列出变更
/api/now/table/change_requestPOST创建变更
/api/now/table/change_request/{sys_id}PATCH更新变更
/api/now/table/change_taskPOST创建任务
/api/now/table/sysapproval_approverGET检查审批状态
/api/now/table/sysapproval_approver/{sys_id}PATCH批准／拒绝
/api/now/table/std_change_catalogGET列出标准变更

最佳实践

  • 充分规划： 在 CAB 之前完成实施计划和回滚计划
  • 合理控制变更规模： 不要合并无关的变更
  • 在低级环境中测试： 投入生产环境之前务必测试
  • 沟通至关重要： 与利益相关者充分沟通
  • 记录一切： 未来的你会感谢现在的你
  • 从 PIR 中吸取经验： 切实落实 PIR 行动项
  • 使用标准变更： 预先批准可重复执行的低风险变更
  • 紧急变更 ≠ 无需记录： 紧急变更仍需记录
  • 符合 ITIL 要求： 遵循变更赋能实践

故障排查

“变更卡在评估阶段”

原因： 缺少必填字段或文档
解决方案： 确认所有必填字段均已填写；检查验证规则

“审批耗时过长”

原因： 审批人无法处理，或未收到通知
解决方案： 直接联系审批人；检查通知日志；使用委托

“CAB 拒绝了变更”

原因： 文档不足、存在风险顾虑或时间安排冲突
解决方案： 处理 CAB 的反馈；改进后重新提交

“实施失败”

原因： 多种原因——测试不足、出现意外情况
解决方案： 执行回滚计划；记录失败情况；创建问题工单；重新安排时间

“无法关闭变更”

原因： 存在未完成的任务、缺少 PIR 或缺少关闭字段
解决方案： 完成所有任务；记录 PIR；填写必填的关闭字段

变更模板

普通变更快速参考
Type: Normal
CAB Required: Yes (typically)
Lead Time: 5-10 business days
Approval: CAB + Manager
Testing: Full cycle
标准变更快速参考
Type: Standard
CAB Required: No (pre-approved)
Lead Time: 1-3 business days
Approval: Automatic
Testing: As per template
紧急变更快速参考
Type: Emergency
CAB Required: Yes (post-implementation ECAB)
Lead Time: Immediate
Approval: Emergency approver (verbal OK, documented later)
Testing: Minimal (risk accepted)

相关技能

  • itsm/incident-lifecycle - 处理相关事件
  • itsm/major-incident - 重大事件期间的紧急变更
  • itsm/problem-analysis - 用于永久修复的变更
  • admin/deployment-workflow - 发布协调
  • admin/update-set-management - CMDB 更新

参考资料

评论

支持 Markdown