在企业的运维管理过程中，很多时候会有变更产生。这些变更通常来源于基础设施的升级，容量管理、可用性管理、软件更新、新服务的推出，服务级别目标的变化等等。这些变更在执行中常 常会引发以下一系列的负面影响。

1. 一个小小的变更引起了一个重大的故障。 

2. 一个变更进行中发现没有足够的资源可被使用来继续完成此变更。 

3. 紧急变更数量太大，导致团队成员疲于应付。 

4. 在业务窗口时间执行变更，导致业务时间段内业务中断。 

5. 一个变更未能在规定时间内完成或是虽然变更已完成，却效果不佳。此时发现此变更无法回滚。

场景一：合理的变更分类的意义

场景描述：

某个 IT 服务提供商已经实现了变更管理流程，在运营一段时间后，经常有客户抱怨说，他们提交的 变更审批得很慢，特别是一些紧急情况下的变更。更让客户难以接受的是，对于那些简单的低风险 的变更也同样也需要等待很长时间才能够被正式受理和审批。我们如何来改进这种现状呢？

解决方法：

作为变更管理最主要的目的是让企业的 IT 服务稳定性提高并控制风险，但这需要在稳定性和灵活性 之间做一个平衡。场景中的情形就是缺乏灵活性的表现。为了提高该企业的变更受理与执行的效率， 通常变更管理实施的第一步是先对变更请求进行分类，在风险和效率之间达到一种权衡，从而提高 执行变更的灵活性，最终达到提高客户满意度目的。 

对于那些风险低的，影响度低的，而且是经常会发生的变更，如：新入职员工开设系统账号、为 他们开通邮件服务等。我们可以定义为标准变更：此类变更跳过繁琐的审批与评估过程，把变更的受理与执行权预先授予某一个职能单元，如：服务台。这样提高了此类变更执行的效率，必定 会提升客户对于此类变更执行的满意度。 

对于那些非常紧急的变更，由于时间上不允许有过多的拖延，并且不可能有太多的时间用于审批 甚至是测试，我们定义为紧急变更。对于这些变更我们直接直接由专家来执行，优先级设成最高 级，马上召开 CAB/EC（紧急变更顾问委员会）进行评估和直接获得最高级授权，直接获得变更执 行的相关资源，有效减少变更挂起的时长。从时间上缩短了受理与审批的周期。 

对于兼顾风险和效率的变更我们定义为正常变更，并根据影其响度划分为不同的等级（如：Minor、 Significant、Major 等）。对于 Minor 类型的变更直接由变更经理审批，而不需要由 CAB 会议审 批，Significant 类型分配给周期性的 CAB 会议，定义为 Major 类型的通常是高风险、高影响度 的，直接由管理层来进行审批和评估。通过这样的分类能有效地进行风险控制，从而达到提高变 更成功率的目的。

总结：由于有了一系列的分类，针对不同的变更给予不同的处理过程，避免了之前的所有变更都采 用相同的处理方式。实行一段时间后，客户满意度将有显著的提高。

场景二：变更导致故障

场景描述：

某企业在周一业务繁忙时段上线了一个新的应用——客户关系管理系统，此系统安装在某一台主机 上，此主机之前一直正常运行着另一套系统——备件采购管理系统。升级完以后发现客户关系管理 系统能够正常服务，但原有的备件采购管理系统无法登录，导致当天上午采购管理系统这个应用瘫 痪。IT 技术团队经过一个上午的努力排除了故障，找出了原因，并恢复了服务。但业务部门对 IT 却提出了严重指责，从管理的角度来思考，你更关注那个方面呢？问题何在？

解决办法： 

从技术的角度上来说，是由于之前主机上安装了一套采购管理系统，使用的是 SQL Server 数据库， 并且默认都是用 sa 帐号登录。新的应用同样使用 SQLServer 数据库，新系统使用的数据库也是 SQLServer 数据库，并且后台登录用户名也是使用了和采购管理系统相同的用户名 sa，但密码不同， 在安装新应用的过程中修改了原先的 sa 密码，所以导致原有的备件采购管理系统无法正常启动。 

从管理的角度上来说，变更的执行需要在适当的时间做，也就是说我们要选择一个变更窗口，在这 个时间内这样就不会影响到业务或是对业务影响最小。变更窗口设在什么时间段呢？很容易想到就 是下班后或是双休日，绝对不会是像周一这样的业务繁忙时段。这个新应用的安装最多也就在 2 小 时内可以完成，可选的时间段非常多。所以以上企业的问题是在非变更窗口时间执行变更，导致现 有的服务受到影响而中断。所以每一个正常变更在评估变更时就要考虑到变更的影响度，预先设定 好变更窗口。这样才能保证业务的正常运作。

场景三：把紧急变更比例控制在合理的区间

场景描述：

某个制造企业紧急变更的数量占变更总数量的 80%。很多情况下由于紧急变更没有足够的时间来进 行评估与测试，数量多的话会导致 IT 的稳定性降低。所以应该严格控制紧急变更的数量和比例，从 而减少变更的不确定因素。对于此种现状，如何应对和改善？

解决办法： 

紧急变更 80%明显高得离谱。首先找到这类紧急变更的具体原因是什么，案例中发现，这些紧急变 更都来源于同一个分类，都是关于一个生产管理系统的软硬件的紧急变更。很多人认为此生产管理 系统非常重要，如果存在问题执行一系列的紧急变更也是没有办法。但谁又能保证如此多的紧急变 更能真正解决现有的故障率呢？紧急变更量大反而会使得系统更不稳定。就好比是拆东墙补西墙。  

对于每一个重大变更都做好充分的评估与测试工作，这样可以避免在重大变更发布后，再跟进很多 修补的紧急变更。 

在重大变更时设定一段试运行期，如果试运行评价报告不够好，或是不满足当初评估的预期，可以 考虑回滚，只有评估满足预期并稳定运行的变更，才会被变更。 

总结：需要对紧急变更的数量和比例做好严格的控制，从而保证变更的稳定性。