企业IT生产变更管理是运维流程的重要流程，有效防控变更风险将直接影响业务连续性管理的有效性， 变更管理的目标是通过规范生产系统变更实施，减少变更带来的问题，并高效和迅速地处理变更发布、交付需求 。 变更管理通常包括几个主要步骤：变更流程、变更评审、变更实施、变更效果评估。变更流程主要指建立变更发布计划，并通过线上化流程方式进行变更申请的审批；变更评审主要指围绕降低变更风险，并让变更正常交付涉及的准备工作；变更实施主要指变更计划的现场实施管理，以及变更发布执行涉及的操作；变更效果评估主要指围绕变更管理的执行情况进行数据运营，以持续提升变更管理水平。

1. 变更管理概述

数字化转型要求业务能够敏捷响应外部环境是不断变化，能够随着外部环境的变化做出调整，而IT需要快速交付业务的IT需求，支持业务运作的基础设施、应用系统、生产数据等进行变更。变更推动着企业业务发展的同时，也带来实施变更的风险，事实上，企业大部分业务连续性故障都是变更引发。为了解决变更引发的问题，运维需要建立完善的变更管理。 变更管理是 IT服务管理的一个重要流程，是IT交付核心价值链最后十公里，涉及组织架构、变更前中后流程与协同机制、变更管理流程与发布等涉及的工具平台。 变更管理的目标是通过规范生产系统变更实施，减少变更带来的问题，并高效和迅速地处理变更发布、交付需求 。遗憾的是，很多IT组织认为变更管理是对交付的控制、限制，所以运维组织在推进变更管理时需要从变更风险、标准、效率等多个维度进行宣传与运营。

在变更内容上，生产变更通常针对应用系统与平台支撑类变更。应用系统变更通常是由需求或故障驱动的变更，比如：新的信息系统上线，对现有系统的程序投产、配置变更、业务参数调整、数据维护、补丁升级、账户迁移、系统切换、版本回滚等。平台支撑类变更重点指支持应用系统相关的机房、网络、IAAS平台、PAAS平台，以及操作系统、数据库、中间件等平台软件类变更，比如机房迁移、设备更换、新模块安装、基础平台软硬件升级加固、预防性的维护、增加容量、提高系统性能、安全防范措等。

在变更分类上，需要针对不同信息系统重要级别、连续性要求、系统生命周期阶段等方向，制定不同的变更内容。有些运维组织分为一般变更、重大变更、紧急变更、标准变更四类，不同的变更对就的变更管控方式有所区别。其中，一般变更和重大变更通常称为常规性的变更，这类变更计划性较好，有一些标准化的变更管理机制，一般变更、重大变更通常根据变更内容涉及的信息系统级别、变更涉及改造的风险、变更涉及影响的对象范围等维度进行划分。紧急变更重点针对无法按计划进行管理的变更，比如生产故障的修复、监管紧急要求、紧急业务需求等，紧急变更对交付速度要求比较高，必要时可以先执行后补单。变更管理必然涉及一些管理流程，为了提升一些规律性强、规范性、自动化水平高的变更交付效率，又可以设计出标准变更这种分类，比如敏态下的互联网灰度发布、数据维护、参数调整、补丁升级等。通常针对标准变更的管控， 可跳过风险评估阶段，按照预授权定义，实现快速审批，并 可以通过自动化水平来提高变更风险的提升，运维组织要建立标准变更的目录清单，做好标准变更的入库审核。

原则上，非紧急变更发布必须先填写记录，不可事后补单；紧急变更发布可通过口头形式审批，但事后必须补单；标准变更发布需经协商确定，每个标准变更需描述变更发布分类、变更发布风险等，以确保在变更发布风险可控的前提下合理调配变更发布管理资源，同时由变更发布流程经理组织定期回顾评审。

2. 变更流程

针对一般变更、重要变更、紧急变更、标准变更会有不同的变更流程，比如流程审批的环节、流程交付的信息等。但总的来说变更管理涉及一个主线：变更申请、评审、审批、发布、验证，不同的组织也会在这个主线流程中增加审批后的变更通知，变更中增加准生产环境测试，变更后增加变更跟踪、变更总结等。以下对主线流程进行整理：

（1） 变更申请
变更申请指变更需求方或项目经理对变更进行申请，通常变更申请人在ITSM发起申请，或在研发过程管理系统中发起申请后自动调用ITSM变更流程工单。一个完整的变更申请，通常还应该包括变更背景、变更内容、变更发布手册、回退方案、测试报告、程序或数据变更清单、验证方案等。大型或重要变更申请，可能还需要进行专项的变更风险、合规、安全等方面的管控流程。

（2） 变更评审
变更评审主要是为了 降低系统变更投产带来的风险，并让变更如期交付业务。 在实际的变更评审中，不同组织会在系统交付生命周期的不同阶段建立相对应的变更评审机制，比如项目立项环节的可用性评审、技术或部署架构可用性评审，设计阶段的非功能性、可运维性评审，上线环节的CAB评审等等（变更评审相关内容后面有专门章节进行介绍）。

（3） 变更审批
变更审批发生在变更申请后，设置线上化流程节点，由变更相关干系人基于变更审批流程进行处理 。通常变更审批通过ITSM进行线上化流转，审批的一般性内容包括评审是否完成、资源是否就绪、业务协同是否就绪，对于部分业务侧变更还要关注业务侧是否就绪。以往，变更审批通常只能由人工干预，随着企业运维平台化建设不断完善，变更审批流程一方面需要形成端到端的流程优化；另一方面需要简化流程，将可自动化的环节自动化，比如某个流程结束后自动触发相关自动化操作。变更审批流程节点设计中，也要考虑一些特殊情况，应用一些更加扁平的工具解决方案，支持更加高效的流程审批方式。另外，变更审批后，通常还需要将变更计划涉及的时间、实施内容、业务影响、对下游系统影响、业务检查反馈方案、联系人等信息通知相关干系人。

（4） 变更发布
变更发布管理主要是管理生产变更的版本部署、升级、操作、维护等变更实施。变更发布是变更管理最后一公里，涉及发布策略与方案的制定、发布流程、发布验收、变更后技术检查，变更异常涉及的变更回退，以及与发布相关的制品库、自动化部署等工具。变更发布管控不到位容易引发生产故障，所以发布管理除了线上发布流程外，还需要配套相关协同操作机制，比如：变更发布前的公告、用户解释、业务验证安排、技术支持、窗口安排、后勤保障准备等；发布中的现场操作、关联支持、总体协调、应急管理、后勤保障等；发布后的基本功能验证、变更内容验证、进展通告、应急管理等。

（5） 变更验证
变更验证包括技术验证与业务验证。技术验证包括技术角度进行可用性、性能、变更功能有效性、功能异常等角度的验证，采用监控、日志、数据库流水、拨测等侧面方式进行验证；业务验证主要从业务角度进行验证，通常业务验证会尽最大可能模拟业务操作进行验证，需要提前准备相关用户账号、业务数据等信息。从验证内容分类，变更验证又包括变更项验证、基本或最小核心功能验证，前者是针对变更涉及的服务内容进行验证，后者是对变更对象最基本的服务的验证，这类服务不一定发生变更。一般来说，变更验证在变更发布后即要马上进行验证，但针对变更涉及功能点无法马上发生的情况，则需要建立变更后的验证跟踪，比如首笔发生的监控。另外，变更验证的问题，通常还会触发事件或问题流程，或其他协同机制。

3. 变更管理涉及的角色

变更管理是一个涉及多方协同的工作流程，以下梳理一些常见的角色

变更发起人。负责牵头梳理变更材料、提交变更申请、跟踪和协调变更准确、审批、发布、验证等流程，理想情况下应该由类似项目经理、产品经理等比较熟悉变更内容与变更流程的人负责。

变更负责人。对整个变更交付结果负责的人，负责与申请人沟通并完善变更发布计划、实施方案、回退计划、应急预案、影响分析，组织评审等，通常变更发起人与变更负责人是同一个。

变更审批人。在变更流程中不同节点的人，针对不同级别的变更通常会有不同的审批人。 变更申请人 / 负责人和变更审批人两种角色建议不能由同一人担当。

变更实施人。负责在生产环境执行和实施变更的员工或团队，通常指一线运维人员。

变更经理。不同组织对于变更经理的角色定义不同，比如负责设计变更流程，协调、监控、跟踪流程执行，总体制定变更计划时间窗口，收集变更流程反馈信息等，个别企业的变更经理还要负责重大变更具体内容的管控。总体来说，变更经理需要统筹组织内变更流程生命周期的有序管理。

紧急咨询委员会（CAB）。通常由一组员工组成，辅助变更经理进行分析和决策，CAB 委员会由来自不同领域的员工组成，包括 IT领域的运维、测试、开发、安全等骨干或决策层，部分业务领域，以及第三方和供应商。

4. 变更窗口

变更窗口是指企业约定的、周期性的变更时间段，在此期间实施变更或发布对服务的影响可以更好资源配置与风险管控，目的是控制变更风险，提高变更成功率，减少变更沟通成本。变更窗口并不限制变更的内容，而是提前在运维、研发、测试、业务之间约定好一些供变更的时间段，IT在进行变更交付时尽量在约定的窗口中发布。以下梳理了一些与变更窗口相关的内容，供参考。

变更窗口制度化 。变更窗口引入对于变更申请人可能带来约束的表现，要在企业范围内获得业务、研发、测试、运维等各个团队的支持，首先需要将变更窗口制度化。制度化窗口后，有助于规范变更窗口管理，明确各岗位角色的权利与义务，并将窗口融入变更管理生命周期。

适应敏态的IT交付 。变更窗口有助于提升变更计划性，推动研发更好的做好计划安排，合并版本等工作，对于传统稳态变更的好处显而易见。但互联网持续交付、生产故障修复、标准化的基础设施变更及资源交付，传统变更窗口一个月一次或两次的方式显然无法满足。所以，敏态的变更窗口最好还能设计每周非高度紧急的故障或紧急业务需求的临时窗口，或针对灰度发布等变更制定相适应的弹性窗口区间。

提前发布变更窗口 。制度化变更窗口后，还要在每年或每季中将变更窗口发布出去，以便变更申请人可以提供做好准备。窗口的制定，还要考虑国家规定的法定长假、国家与行业重大事件或与企业相关的重大事项封网期等特殊时段。

配套变更窗口管理机制 。变更窗口的有效落实，还需要将窗口融入到变更管理机制，比如变更窗口前的评审，每个月的变更窗口总结，加强变更窗口实施管控，系统提供服务的时间范围等。另外， 应依照变更发布管理报告周期，定期回顾变更发布的执行结果，结果应记录到变更发布管理服务报告中，改进措施应纳入服务改进管理。

5. 变更评审

变更评审有两个关键作用，一是为了 降低系统变更投产带来的风险；二是让变更如期交付给业务。 这两点看起来存在冲突的，前者关注提供可靠、稳定的服务，后者关注支持个性化需求并快速变更的灵活服务。对于变更风险，生产变更风险具有专业性强、复杂度高、隐蔽性强等特点，变更风险的识别最好能有多个领域专家，从多个维度进行风险评估；另外，变更风险的危害性极强，需要建立主动发现风险的工作机制，以及针对风险的应对措施。在控制风险基础上推进如期交付业务，主要强调变更评审不能以控制为目的，而是应该识别风险与解决风险，促进变更平稳的完成。所以，控制风险与如期交付并不冲突，是相互关联的目标。

在实际的变更评审中，不同组织会在系统交付生命周期的不同阶段建立相对应的变更评审机制，比如项目立项环节的可用性评审、技术或部署架构可用性评审，设计阶段的非功能性、可运维性评审，上线环节的CAB评审等等。在评审过程中，评审组织通常会设计评审涉及的相关checklist，将已知的故障、风险、合规、发布操作等内容作为确认信息纳入评审，将变更评审进行总结，可以包括以下几个重点：

• 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
• 风险分析：架构、性能、业务、合规等方面的风险评估， 变更内容是否属于需求范围，变更是否可控。
• 重要程度：变更属于一般、重要、紧急、标准哪一种。
• 变更审查： 内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
• 应急管理：变更步骤、应急方案、回切方案、应急预案是否完备。
• 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。

• 变更验证：变更涉及的业务、技术验证方法与时间安排。

  ITIL中提出要对变更生命周期进行控制，即允许在业务连续性基础上对变更交付进行积极的改进，变更咨询委员会(CAB)就是负责 变更生命周期控制 。理想情况下，所有生产变更都应提交 CAB接受评审，CAB在评审过程中职责主要包括：

• 检查评估执行变更的合规性、风险性、控制性。
• 对于发现的问题进行问题督导，与变更干系人进行沟通，按需调整变更。
• 审核变更涉及的资源，变更的关联信息分。
• 为变更经理或变更决策者提供信息支持。
• 为即将发布的变更进行宣传或公告通知。
• 参与变更流程的持续改进活动。

• 根据需要对个别变更进行深入审查。

  对上一阶段的变更进行复盘，尤其是失败的变更，以及变更影发的生产事件。

  CAB委员会由IT团队中相对权威的人士组成，角色可以包括：CAB运营经理、变更经理、应用运维经理与运维工程师、业务关系经理、服务台分析师等。有时候变更经理就是CAB运营经理，要负责主持CAB会议，CAB会议可以是月会，周会或日会，或紧急CAB会议。