变更管理过程工作流

变更管理是在整个请求生命周期内管理变更请求的过程。 变更管理确保使用标准化方法和步骤来处理变更。

由于技术的快速更新，IT 服务产品的革新需求也同样紧迫。 未合理规划的变更会带来很多问题。 因此，需要严格管理和控制 IT 系统和服务的变更方法。 

变更管理旨在最大限度地减少由于实施变更而对现有 IT 服务造成的任何不良干扰。 变更管理包括设置用于处理变更的流程并确保：

• 使用适当的变更类型对变更分类，并在该变更类型的工作流中处理变更。
• 根据特定的变更类型，通过适当的变更审批流程提交变更。
• 根据定义的流程实施变更，变更包含验证已实施变更的所有方面的任务。
• 审核变更实施以确保将总体业务风险降至最低。 变更实施还可以确保变更在关闭之前已记录在所有关联的系统中。  

ServiceAide Cloud Service Management 提供六种预定义的变更管理过程工作流：   

默认变更管理过程工作流的状态为：

• 默认常规变更管理过程流程的状态为“已发布”。
• 默认标准变更管理过程流程的状态为“已发布”。
• 默认紧急变更管理过程流程的状态为“已发布”。
• 默认故障修复变更管理过程流程的状态为“已发布”。
• 重大变更管理过程流程的状态为“草案”。
• DevOps 变更管理过程流程的状态为“草案”。

默认常规变更管理过程流程

默认常规变更管理过程流程将定义与常规变更相关的请求的基本过程工作流。 请求与处于活动状态的其他变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示默认常规变更管理的过程：

下列步骤说明了默认常规变更管理过程流程的工作方式：

1. 提出故障单时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 变更协调者会评测和评估请求，并提交该请求以供经理审批。
3. 经理将对请求执行以下某一操作：
   • 审批 - 请求将分配给变更顾问委员会 (CAB) 以供进一步评估。 
   • 拒绝 - 请求将重新分配给变更协调员以供重新评估或是关闭该请求。
4. CAB 将通过以下某一操作来评估请求：
   
   • 由所有批准人审批 - 请求将由所有 CAB 成员进行审批。
   • 一个审批人批准或拒绝 - 请求由某一 CAB 成员进行审批。
   • 所有审批人紧急审批 - 提交请求以供 CAB 紧急审批。
     注意：经理可撤销 CAB 对请求的审批，并可在审批阶段关闭该请求。
5. 如果 CAB 批准，便会实施变更。 如果未获批准，CAB 则会对变更请求提出带修改的审批。 

默认标准变更管理过程流程

默认标准变更管理过程流程将定义与常规变更相关的请求的基本过程工作流。 例如，应用 service pack、常规包以及向测试环境添加服务器等请求。 请求与处于活动状态的其他变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示默认标准变更管理的过程：

下列步骤说明了默认标准变更管理过程流程的工作方式：

1. 提出变更请求时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 变更协调员将评估请求，并将该请求发送给变更经理以供审批。
   注意：变更协调员可撤销经理对请求的审批以便修改该请求。 修改后，变更协调员将重新提交请求以供经理审批。  
3. 变更经理将执行以下某一操作：
   • 批准 - 实施请求并关闭已成功的请求。
   • 拒绝 - 请求失败，并在有例外的情况下关闭。 

默认紧急变更管理过程流程

默认紧急变更管理过程流程将定义与紧急变更相关的请求的基本过程工作流。 例如，用于解决生产停机时间和网络停机时间的请求。 请求与处于活动状态的其他变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示默认紧急变更管理的过程：

下列步骤说明了默认紧急变更管理过程流程的工作方式：

1. 提出变更请求时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 变更协调员将执行以下某一操作：
   • 批准实施：变更协调员批准请求进行实施。
   • 提交给 ECAB 审批（所有审批人）：由所有 ECAB 成员审批请求。 
   • 提交给 ECAB 审批（任何一人批准或拒绝）：由某一 ECAB 成员审批请求。
3. 变更经理或紧急变更顾问委员会 (ECAB) 将执行以下某一操作：
   • 批准 - 实施请求并关闭已成功的请求。
   • 拒绝 - 请求失败，并在有例外的情况下关闭。 

默认故障修复变更管理过程流程

当某一请求需修正轻微变更时将采用默认故障修复变更管理过程流程。 请求与处于活动状态的其他故障修复变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示默认故障修复变更管理的过程：

下列步骤说明了默认故障修复变更管理过程流程的工作方式：

1. 提出变更请求时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 变更协调员将提交请求以便进行变更管理审核。
3. 将审核注释更新到请求后，变更协调员将验证注释并执行以下某一操作：
   • 关闭变更请求。 
   • 如果对审核注释不满意，则重新开出变更请求。 

重大变更管理过程流程

重大变更管理过程流程将定义与重大变更相关的请求的基本过程工作流。 例如，用于部署应用程序的请求。 请求与处于活动状态的其他变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示重大变更管理的过程：

下列步骤说明了重大变更管理过程流程的工作方式：

1. 提出变更请求时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 变更经理将评测和评估请求，并提交 IT 支持团队进行审核。
3. IT 支持团队将评估请求并将其提交变更顾问委员会 (CAB) 进行审批。 CAB 将执行以下某一操作：
   • 批准 - CAB 将审核实施计划并提交给部署团队进行部署。 
   • 拒绝 - 请求将重新分配给变更协调员重新评估或是关闭该变更请求。
     注意：IT 支持团队可撤销 CAB 对请求的审批，并可将其重新分配给变更经理。 
4. 部署团队将对请求执行以下某一操作：
   
   • 批准 - 实施变更并关闭该请求。 （可选）如果实施过程中涉及多个团队，则会创建一个项目。 如果实施失败，则会重新开出请求并在变更实施之前重复执行从步骤 2 开始的步骤。 
   • 拒绝 - 重新开出请求，并在实施变更之前从步骤 2 开始重复执行该过程。

DevOps 变更管理过程流程

DevOps 变更管理过程流程定义与 DevOps 变更相关的请求的基本过程工作流。 例如，用于在应用程序中实施某一变更以便进行发布的请求。 请求与处于活动状态的其他变更过程工作流的入口条件不匹配时，会应用默认过程。

下图显示 DevOps 变更管理的过程：

下列步骤说明了 DevOps 变更管理过程流程的工作原理：

1. 提出变更请求时，会基于匹配条件对入口条件进行验证以分配请求。 不匹配任何条件时，默认情况下该请求将分配给“变更管理”组。
2. 发布协调组将评测和评估该请求。 创建一个请求实施计划，并将该计划分配给变更顾问委员会 (CAB) 进行审批。
3. CAB 批准后，将执行以下步骤：
   1. 启动构建活动 - SSH 连接器：启动构建脚本以便为发布创建软件包。
   2. 检查构建状态 - SSH 连接器脚本：验证构建脚本是否成功运行。 如果构建失败，则记录该构建操作，并在有例外的情况下关闭该请求。 
   3. 启动测试活动 - SSH 连接器：调用测试脚本以验证软件包是否按设计方式运行。 
   4. 检查测试执行状态 - SSH 连接器：验证测试是否成功。 如果测试失败，则运行备用计划或更新为测试失败，并在有例外的情况下关闭该请求。 
   5. 启动实施 - ServiceAide Release Automation：调用部署脚本以实施该软件包。
   6. 检索来自 ServiceAide Release Automation 的发布状态：收集来自发布自动化应用程序的发布信息。 
      注意：如果实施失败，请执行撤消计划，并在存在例外的情况下关闭该请求。
4. 随即实施请求并验证其完整性。 变更请求即已关闭。