浅谈IT 运维-变更管理

定义:

在企业的运维管理过程中,很多时候会有变更产生。这些变更通常来源于基础设施的升级,容量管理、可用性管理、软件更新、新服务的推出,服务级别目标的变化等等。

风险与问题举例:

变更在执行中常 常会引发以下一系列的负面影响

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

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

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

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

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

核心问题1:为什么要有合理的变更分类

场景描述:

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

解决方法:

将变更分成标准变更、紧急变更、正常变更

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

标准变更

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

紧急变更

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

正常变更

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

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

核心问题2:变更导致故障

场景描述:

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

解决办法:

技术角度:

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

管理角度:

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

核心问题3:把紧急变更比例控制在合理的区间

场景描述:

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

解决办法:

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

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

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

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

你可能感兴趣的:(自动化运维,运维)