[p=30,2,center]学习资料:IT运维管理社区专家讲堂直播300期视频回放[p=30,2,center]
[p=30,2,center]
一、变更管理概述
1.变更管理简介
中国人民大学网络与教育技术中心IT服务管理体系,是IS020000标准的落地体系。IS020000的五大流程组之服务控制流程组包括配置管理与变更管理。本文将根据我们的实际经验介绍对变更管理流程的设计实践及运行推动。
变更指对已批准构建或实施的、正在维护的或作为基线的配置项所作的增删改,这些配置项主要包括硬件、软件、涉及的SLA服务、IT环境及相关文档的更改。
变更管理,是在事件、问题处理中,或用户对硬件、软件系统、服务等的需求发生变化时,对系统、设备的软硬配置或程序等进行改变。其目的是确定所需要的变更,并使这些变更在最小的范围内得到实施。变更的结果通常需要修改配置管理数据库中的配置项信息。变更请求报告可以来自突发事件管理、问题管理、服务等级管理、可用性管理、能力管理及用户等。
2.变更管理目标
变更管理流程的目的是确保以受控的方式去评估、批准、实施和评审所有变更,使得每一条变更都有理可依、有据可查,同时将服务中断降到最少,将变更相关的事件对服务质量的影响降到最低,并持续改善支持业务的运营和基础架构。
变更管理通常与配置管理结合使用,两者合为ISO的控制过程。主要是为了提供IT基础架构,支持其他服务管理流程的运作,将变更所带来的业务影响降到最低。我们引入变更管理流程的最终目标就是为了以受控的方式确保有且仅有必要的变更才被实施,并且确保此变更对服务造成的影响最低,从而确保网络与教育技术中心为全校师生提供服务的高质量、可靠性、稳定性。
从去年12月开始,为了使得本中心提供的服务更为标准可靠、与国际化接轨,网络与教育技术中心特意成立了专门的工作小组负责IT服务标准化的相关工作,并且集全中心人员之力梳理中心的详细岗位职责、业务流程等,至此中心的服务管理标准化实践轰轰烈烈地开始了。
二、变更管理流程设计实践
1.变更类别设计
据文献,有人将变更类别分为:硬件、软件、逻辑实体、应用系统,也有人将其分为:硬件、网络、软件、应用、环境、系统。由于网络、应用、逻辑实体、环境、系统最终可拆分为硬件、软件、软硬件的配置项,为了简洁且避免交叉而又能全面地覆盖变更需求,根据本中心的实际情况将服务和架构变更的范围分为硬件、软件、服务及其他,一共四大类。其中硬件又分为主机设备、存储设备、网络设备、机房辅助设备、安全设备、通讯设备、终端设备等。软件又分为底层支撑软件、网管软件、安全软件、应用软件、其他软件等。服务分为新服务、服务级别协议和服务支持合同。
2.变更类型设计
结合网络与教育技术中心的实际情况从紧急程度、业务影响度等方面将变更分成了三大类型,分别为:常规变更、重大变更、紧急变更。其中,常规变更指的是频繁发生、影响范围较小、紧急程度较低、实施风险较小、已经制定了标准实施流程的变更;重大变更指的是实施工作复杂、影响范围广、存在风险、需要制定详细方案、在系统与业务功能方面有重大调整的变更,需要专业技术委员会审批方可执行;紧急变更指的是如果不进行变更,会立即或正在严重而大范围地影响业务运行、服务等级或者带来重大影响的变更。
流程设计之初,变更类型类别确定之后,在中心领导的督促下我们采集了各个业务科室的所有变更需求,然后在中心专业技术委员会的讨论核实下,根据变更类型定义,将中心的所有变更需求分别归入常规变更、重大变更、紧急变更,以便在IT/L系统落实运行的时候有章可循。由于篇幅限制,部分摘录如下:
(1)常规变更
普通硬件上线、维护,例如校园网网络设备硬件更换、出口流控策略变更、域名服务器硬件更换、DHCP服务器硬件更换、无线控制器硬件变更等;
普通软件维护,例如数字人大电子校务系统、邮件系统、计费系统、BB系统、网关系统、出口带宽系统等软件的系统打补丁、系统功能变更等;
新增服务,服务级别协议、服务支持合同等的变更;
(2)重大变更
核心设备上线、维护f需停机)、硬件物理搬迁,例如校园网核心设备或链路调整、域名解析系统调整、校园网出口设备或链路调整等,需要中断服务:
需要厂商支持,工作量在2个月以上,需要多部门协调的软件变更。例如平台的升级(软硬件)、门户的升级、新功能模块的开发等:
涉及多个客户的基础设施改造f如大面积网络改造
(3)紧急变更
关键或重要应用系统故障,严重而且大范围影响用户使用,需要立即进行变更的。包括:校园卡系统、数字人大电子校务系统、邮件系统、学校主页系统、上网计费系统、电子身份认证中心、BB系统、数据交换中心、VPN、域名解析系统、DHCP系统软件运行故障,需要进行主系统与备用系统的切换,或软件升级部署,或硬件更换,或数据库变更等:
校园网核心设备故障、链路故障及校园网出口中断,造成校园网络瘫痪,需要立即进行主系统与备用系统的切换或硬件替换等:
校园卡专网核心设备故障,需要立即进行主系统与备用系统的切换或硬件替换等;
3.变更角色与职责设计
变更管理流程的目的是确保以受控的方式去评估、批准、实施和评审所有变更,从而使得每一条变更都有理可依、有据可查。据此我们设计了变更请求人、变更受理人、变更执行人、变更经理、专业技术委员会等五个角色用以完成变更请求、评估、批准、实施、评审等工作。各个角色的具体职责描述如下:
变更请求人,根据使用、维护自发或项目建设提出的或其他相关流程提出的需求,创建变更请求。变更请求人在申请变更的时候,根据《变更分类、类型定义表》填好变更类别类型,同时对其风险、影响和业务利益作出初步的评估。然后将变更请求单提交给变更受理人进行受理。变更请求人目前由网络与教育技术中心的一、二线工程师担任。
变更受理人,检查由变更请求人提交的每一个变更请求,对变更进行分类和初步的审核,检查变更的正确性和必要性,拒绝不必要的变更请求;针对具体变更请求,评估并分派相应资源,指定变更执行人员,协调必要的变更时间及其他资源等。变更受理人由各个科室的科长担任,分别受理各自科室提交的变更请求。变更执行人,负责设计变更的详细方案,包括:变更的详细内容及实施计划、测试计划、回退计划、应急方案等,并负责变更的构建、测试、实施,必要时根据实际情况执行回退计划或应急方案,确保变更得以正确实施,记录实施的相关信息。变更完成后,进行监控,通报变更实施的进度和结果。变更执行人由中心的一、二线工程师担任。
变更经理,负责对重大变更进行第一次审批,确保只有必要的重大变更才被提交到专业技术委员会进行讨论与审批:参与变更管理流程评估,对流程改进提出意见和建议,与流程负责人共同制定流程改进建议。变更经理由中心主管网络与应用开发的领导担任,因为中心90%以上的变更都是由这两个科室负责。
专业技术委员会,设置用来帮助和支持变更执行人员,对紧急变更进行快速审批,对重大变更进行二次审批。批准后将意见返回给变更受理人,由变更受理人分派资源之后,变更进入计划、测试、构建和实施阶段。专业技术委员会的成员由中心的高级工程师、技术元老担任。
4.变更管理流程设计
如图所示,每一条变更请求都必须由变更请求人在系统中填写完整的变更请求单,然后提交给变更受理人进行受理。变更受理人对变更进行分类、初审等,然后将紧急变更提交专业技术委员会进行紧急变更快速审批。将重大变更提交变更经理进行审批,直接为常规变更指定变更执行人,对其进行分派变更。变更经理接到重大变更请求之后,对其进行评估、审批,若认为此变更确实有必要、能够实施,则提交专业技术委员会进行二次审批专业技术委员会对其进行技术论证,审批通过之后将变更意见返回变更受理人。由变更受理人对变更进行分派,指定变更执行人,协调相关的资源,督促协助变更的顺利实施。变更执行人接到审批通过的变更申请单之后,制定出详细的变更总体方案并按照计划进行实施。实施完成之后,将结果反馈给变更受理人,变更受理人根据需要安排相关人员进行变更回顾、评估等,最终关闭变更。
图变更管理流程
三、流程关联关系
变更管理与事件管理、问题管理、配置管理、发布管理、服务级别管理等都有关联关系,存在以下关联准则。
(1)和事件管理、问题管理、发布管理的关联
解决事件、问题或发布的过程中涉及到需要对软硬件、服务等进行变更的需要触发变更管理流程,在ITIL系统中落实时其记录也与变更记录做了关联。
(2)和配置管理的关联
在制定变更计划时通过查询配置管理数据库,评估变更可能影响的软硬件或服务等配置项信息,制定配置项更新计划,变更实施完成后需确保配置项信息及时更新,配置记录必须与变更记录相关联。落实到ITIL系统上时,需要在变更记录中建立一条链接,将变更记录与相关的配置项信息链接在一起,通过对链接过来的信息进行变更从而完成配置项信息的变更。
值得一提的是,所有配置项信息的变更必须通过变更管理流程控制。
(3)和服务级别管理的关联
服务级别管理中涉及到需要对服务目录、服务内容、服务级别的变更以及第三方服务支持合同的变更等,则服务级别记录必须与变更记录相关联。
变更管理向服务级别管理提交服务计划可用性报告、在这个报告中,变更管理列出对现有服务级别协议的改变和对服务可用性中变更进行计划的影响。
四、总结
规范的变更管理流程形成了规范的变更记录。定期对变更记录进行分析,检查频繁发生的变更、呈现的趋势等。从而对于频发的变更给予更多的关注,进而提出改进措施避免此类情况的再度发生。对于变更呈现的趋势给予干预,使其往更利于提高服务水平的方向发展。
变更管理流程从今年1月落实于ITIL系统,历经多次整改、完善,目前已通过IS020000第一阶段认证审核在这一阶段的运行过程中,有效地规避了不必要的变更,引导了变更执行的标准化,大为减少了变更实施过程中的故障,有效地提高了IT服务的稳定性与可靠性。另一方面,通过对变更进行度量分析,很好地了解到了项目当前的质量状态。
今后,我们将定时进行项目复盘,分析变更产生的原因和解决方法、变更呈现的趋势,及时了解常见错误、错误发生趋势等,有针对性地解决问题,提出改进措施,从而使得我们的开发能力不断得到提高,提供的IT服务质量也更上层楼。
|