规范“变更管理” 减少IT运维的随意性
摘要：ITIL并不是因为炫丽而惹得企业热捧，通过实践证明，ITIL在解决并纠正出现在IT运维管理中的弊端，是极其有效的方法。企业实施ITIL，可以有助于最终进行完善的服务管理，实现对业务功能及流程进行重新设计，降低成本、缩短周转时间、提高质量和增进客户满意度。然而，在IT组织中有相当大的比例在历史上都是从“事件管理”开始的。这种决定通常都是基于“直觉”，而不是其它方面因素。毕竟，事件管理就是使IT能快速为业务恢复服务，但这种基于“恢复”的ITIL并不能预防问题再次发生，所以越来越多的企业将ITIL的起点设定在变更管理上，这有两个基本原因：它可以在问题出现之前预防问题发生，而且它确实能够减少IT运维中随性而为。
关键词：ITIL；变更管理；事件管理；流程管理； CMDB
一、IT运维管理中随意操作的后果
据权威机构的调查一项IT运维管理数据显示，在日常IT运维中，有80%的事故源自所以的配置变更。我们知道，在日常的网络管理和业务系统的维护过程中，需要对系统和服务进行调整，这种改变包括升级应用程序、操作系统安全维护、补丁修复、添加和删除组件、调整安全策略和配置参数。也正是因为如此，企业中出现的一些业务系统故障就是因为这种变更操作所产生的。 有这样一个客户的案例：系统运维人员接到故障报告，原因是业务部门的ERP系统无法查询销售表单了。系统运维人员经过调查发现，原因是Web服务器访问数据库被拒绝了。根据事件分析，他将故障处理转发给数据库管理员，请其查询数据库权限是否进行过更改。可是整个事件很快被数据库管理员退了回来，理由是：“我没有对数据库做过任何改变，所以一定不是数据库方面的问题”。系统运维人员只能再从别的方面入手调查这个问题，并继续与数据库管理员沟通，但是他始终确信自己没有修改过数据库。时间在流逝，这个故障在一天时间里面都没有得到解决。业务部门的绩效受到严重影响，因此颇为不满，认为IT部门效率太低。 隔天，数据库管理员突然想到：“好像是恢复过数据库的访问地址限制策略，只有许可列表里的IP地址才能访问该数据库。“经过与系统管理员双发确认，这次发生故障的web服务器的IP地址曾经在一个月以前变更过，他并不知道这次变更，所以Web服务器不在许可列表上。这两次变更（IP变更+安全策略变更）失误直接导致了IT部门服务质量的下降，更影响了企业正常业务系统的使用。类似的事件在企业网络中屡有发生，究其原因是没有严密的变更流程控制，变更前缺乏充分的业务影响分析和风险评估，另外没有形成详细可查的变更记录，也没有审核记录，知识只能依赖“关键人员的脑子”，信息未能共享，致使故障发生时，无从追踪。 二、ITIL落地以变更管理作为起点
变更在日常运维中扮演着重要的角色，但对其过程的管理往往不尽如人意。由于疏忽、缺少资源、准备不充分等缘故导致变更失败或产生新事故的状况屡屡发生。针对上述问题，如何对变更进行有效管理日渐成为企业IT部门所关注的课题。 变更管理是目前业界普遍认可、国际通用的ITIL（IT基础设施库）最佳实践流程（事件管理、问题管理、配置管理、变更管理和发布管理）之一，它是通过一套系统的方法和流程，来保证变更顺利的实现，包括变更的分析、计划、执行和回顾四个阶段。它的目标是通过一系列严密的审核、审批等流程控制，针对当前或新的IT基础架构实施已获得批准的变更，将成本控制在合理的范围内，将风险控制在可接受的范围内，把对业务的影响降至最低。如果把变更管理与配置管理数据库（CMDB）联系起来，那么凡是影响到CI（配置项）的都应叫做变更，这样配置管理和变更管理就紧密结合起来了。 企业的CIO都知晓一个问题，他们要想跨所有障碍一下子实施ITIL，即便不是不可能的，也是不现实的，组织必须决定他们到底想从哪里开始。但经过权威机构对ITIL实施的企业调查问卷显示，在IT组织中引入ITIL管理，有相当大的比例都是从事件管理开始的。这种决定通常都是基于“直觉”，而不是其它方面因素。毕竟，事件管理就是使IT能快速为业务恢复服务。在ITIL教程中，有一句话印象深刻：“服务台的功能经常与突发事件管理功能紧密结合，用来连接其它的服务管理流程，逐渐被称为一线服务支持的代名词。”为什么会对此印象深刻呢？因为这句话在实践中体会的最深，从实践中体会到服务台和事件管理之间一种“点”与“面”的紧密关系。 但为什么，我们建议要从变更管理开始作为ITIL的起点呢？试想一下，IT部门的价值是用解决问题的时间来衡量的吗？肯定不是。所以说，保证系统不出问题才是IT运维成熟的表现。不然，东边修完，西边修的结果，IT部门永远会沦为救火队员的角色不能翻身。 在日常运维中，变更操作分为两个方面，被动变更和主动变更。一方面，运维人员发现系统出现了问题，要从本质上进行故障修复，降低这些事故发生的频率，减少带来的负面影响，必须实施一定的变更以消除事故产生的根本原因，这是被动变更。另一方面，随着信息技术的快速发展和企业竞争的加剧，IT基础架构和IT服务必须不断更新以适应这种外在的变化，这是主动变更。因此，围绕主动变更，消除隐患，让IT系统能符合企业业务创新的要求才是IT价值的关键所在。 三、变更管理流程的“死与活”
ITIL作为IT管理实践的最佳指南，它的光环几乎吸引所有大型企业的IT管理团队，高管们都希望能够通过它改善和提高IT服务的水平。然而，不是人人都会获得成功，当企业借助ITIL标准化实施ITSM的时，面临的最大挑战就是流程必须根据业务人员的实际需求而进行调整，可一旦出现“流程”不能舒畅“流”下去的时候，很多ITIL项目要么停顿不前，或是完全失败。 “变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响减到最小，并因此改进公司的日常运作。但通过调查发现：一些企业的IT管理层认为配置管理流程太过官僚和死板，因为每一个变动都需要在CMDB中作记录。IT部门的个别人可能借此作为不执行流程全部活动的借口。然而，很多人至今无法相信 ITSM项目成功就取决于这种“死板”的机制，很多失败的原因是企业无法利用ITSM工具及时调整不合理流程，这些ITSM工具的死板，造成了每一次的流程变更要“从头再来”或重新研发，这才是用户和IT部门无法忍受的。 例来说，某公司的产品销售部的一台终端出现无法上网的问题，调查后发现因为主机原来进行过网卡更换处理，而原有在交换机上有配置了MAC地址绑定的功能。如果使用原来的ITSM系统流程，首先销售人员会登录ITSM系统的服务台告知故障现象，然后走故障管理流程。随之这个故障上升成为了一个事件，触发了事件管理流程，然后问题就出现了：原有的ITSM系统中无法定义紧急变更流程的输入、输出功能，因此这个事件也就停在了这里。 当然，变更也可分为若干种，有大的、小的，还有一些标准的变更。所谓标准变更，指的是一些常规动作，经过一次审批以后，可以反复进行，或者说已经被固化的，比如每个月都需要做一次常规备份，这种常规备份是经过批准的，必须按照规定程序做。还有一些是紧急的变更，相当于“救场”，这时候，需要采取一些临时措施，而IT部门的所有人员和管理者都要对这次变更知晓和负责。还有一些变更是不需要授权的，按常规流程走就可以了。但即使这样，所有的变更也都有文档记录在案。例如：变更请求文档，用于审批的；变更进度计划，用于执行变更；变更预案，也就是预计这种变更带来的后果和如何消除此次变更可能带来的影响。 一旦有了变更请求，如果是常规的变更，变更管理员马上就可以做，自动获得授权；如果不是，就要提交变更委员会，这通常包括业务负责人和运维部门的所有人，要召开会议，给出授权；如果还有重大的变更，这种变更简直就是大换血，这种时候，高层管理层统统要介入。为什么要建立这样一种架构呢？就是为了要明确责任和规范操作。 再者，在IT运维技术，尤其是ITSM工具的最新进展方面，已经使得ITIL变更管理比以往更具吸引力。例如，配置管理数据库（CMDB）的改革已经给IT管理变更的方法带来了更多的灵活性。结果，配置管理正变得更成熟，超越了基本的IT资产清单，达到了自动识别和配置项定义的成熟度，关系和依赖使得变更管理和影响评估成为现实。这些技术，都为变更管理的实践提供了有力的支撑。
关键词：ITIL；变更管理；事件管理；流程管理； CMDB
一、IT运维管理中随意操作的后果
据权威机构的调查一项IT运维管理数据显示，在日常IT运维中，有80%的事故源自所以的配置变更。我们知道，在日常的网络管理和业务系统的维护过程中，需要对系统和服务进行调整，这种改变包括升级应用程序、操作系统安全维护、补丁修复、添加和删除组件、调整安全策略和配置参数。也正是因为如此，企业中出现的一些业务系统故障就是因为这种变更操作所产生的。 有这样一个客户的案例：系统运维人员接到故障报告，原因是业务部门的ERP系统无法查询销售表单了。系统运维人员经过调查发现，原因是Web服务器访问数据库被拒绝了。根据事件分析，他将故障处理转发给数据库管理员，请其查询数据库权限是否进行过更改。可是整个事件很快被数据库管理员退了回来，理由是：“我没有对数据库做过任何改变，所以一定不是数据库方面的问题”。系统运维人员只能再从别的方面入手调查这个问题，并继续与数据库管理员沟通，但是他始终确信自己没有修改过数据库。时间在流逝，这个故障在一天时间里面都没有得到解决。业务部门的绩效受到严重影响，因此颇为不满，认为IT部门效率太低。 隔天，数据库管理员突然想到：“好像是恢复过数据库的访问地址限制策略，只有许可列表里的IP地址才能访问该数据库。“经过与系统管理员双发确认，这次发生故障的web服务器的IP地址曾经在一个月以前变更过，他并不知道这次变更，所以Web服务器不在许可列表上。这两次变更（IP变更+安全策略变更）失误直接导致了IT部门服务质量的下降，更影响了企业正常业务系统的使用。类似的事件在企业网络中屡有发生，究其原因是没有严密的变更流程控制，变更前缺乏充分的业务影响分析和风险评估，另外没有形成详细可查的变更记录，也没有审核记录，知识只能依赖“关键人员的脑子”，信息未能共享，致使故障发生时，无从追踪。 二、ITIL落地以变更管理作为起点
变更在日常运维中扮演着重要的角色，但对其过程的管理往往不尽如人意。由于疏忽、缺少资源、准备不充分等缘故导致变更失败或产生新事故的状况屡屡发生。针对上述问题，如何对变更进行有效管理日渐成为企业IT部门所关注的课题。 变更管理是目前业界普遍认可、国际通用的ITIL（IT基础设施库）最佳实践流程（事件管理、问题管理、配置管理、变更管理和发布管理）之一，它是通过一套系统的方法和流程，来保证变更顺利的实现，包括变更的分析、计划、执行和回顾四个阶段。它的目标是通过一系列严密的审核、审批等流程控制，针对当前或新的IT基础架构实施已获得批准的变更，将成本控制在合理的范围内，将风险控制在可接受的范围内，把对业务的影响降至最低。如果把变更管理与配置管理数据库（CMDB）联系起来，那么凡是影响到CI（配置项）的都应叫做变更，这样配置管理和变更管理就紧密结合起来了。 企业的CIO都知晓一个问题，他们要想跨所有障碍一下子实施ITIL，即便不是不可能的，也是不现实的，组织必须决定他们到底想从哪里开始。但经过权威机构对ITIL实施的企业调查问卷显示，在IT组织中引入ITIL管理，有相当大的比例都是从事件管理开始的。这种决定通常都是基于“直觉”，而不是其它方面因素。毕竟，事件管理就是使IT能快速为业务恢复服务。在ITIL教程中，有一句话印象深刻：“服务台的功能经常与突发事件管理功能紧密结合，用来连接其它的服务管理流程，逐渐被称为一线服务支持的代名词。”为什么会对此印象深刻呢？因为这句话在实践中体会的最深，从实践中体会到服务台和事件管理之间一种“点”与“面”的紧密关系。 但为什么，我们建议要从变更管理开始作为ITIL的起点呢？试想一下，IT部门的价值是用解决问题的时间来衡量的吗？肯定不是。所以说，保证系统不出问题才是IT运维成熟的表现。不然，东边修完，西边修的结果，IT部门永远会沦为救火队员的角色不能翻身。 在日常运维中，变更操作分为两个方面，被动变更和主动变更。一方面，运维人员发现系统出现了问题，要从本质上进行故障修复，降低这些事故发生的频率，减少带来的负面影响，必须实施一定的变更以消除事故产生的根本原因，这是被动变更。另一方面，随着信息技术的快速发展和企业竞争的加剧，IT基础架构和IT服务必须不断更新以适应这种外在的变化，这是主动变更。因此，围绕主动变更，消除隐患，让IT系统能符合企业业务创新的要求才是IT价值的关键所在。 三、变更管理流程的“死与活”
ITIL作为IT管理实践的最佳指南，它的光环几乎吸引所有大型企业的IT管理团队，高管们都希望能够通过它改善和提高IT服务的水平。然而，不是人人都会获得成功，当企业借助ITIL标准化实施ITSM的时，面临的最大挑战就是流程必须根据业务人员的实际需求而进行调整，可一旦出现“流程”不能舒畅“流”下去的时候，很多ITIL项目要么停顿不前，或是完全失败。 “变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响减到最小，并因此改进公司的日常运作。但通过调查发现：一些企业的IT管理层认为配置管理流程太过官僚和死板，因为每一个变动都需要在CMDB中作记录。IT部门的个别人可能借此作为不执行流程全部活动的借口。然而，很多人至今无法相信 ITSM项目成功就取决于这种“死板”的机制，很多失败的原因是企业无法利用ITSM工具及时调整不合理流程，这些ITSM工具的死板，造成了每一次的流程变更要“从头再来”或重新研发，这才是用户和IT部门无法忍受的。 例来说，某公司的产品销售部的一台终端出现无法上网的问题，调查后发现因为主机原来进行过网卡更换处理，而原有在交换机上有配置了MAC地址绑定的功能。如果使用原来的ITSM系统流程，首先销售人员会登录ITSM系统的服务台告知故障现象，然后走故障管理流程。随之这个故障上升成为了一个事件，触发了事件管理流程，然后问题就出现了：原有的ITSM系统中无法定义紧急变更流程的输入、输出功能，因此这个事件也就停在了这里。 当然，变更也可分为若干种，有大的、小的，还有一些标准的变更。所谓标准变更，指的是一些常规动作，经过一次审批以后，可以反复进行，或者说已经被固化的，比如每个月都需要做一次常规备份，这种常规备份是经过批准的，必须按照规定程序做。还有一些是紧急的变更，相当于“救场”，这时候，需要采取一些临时措施，而IT部门的所有人员和管理者都要对这次变更知晓和负责。还有一些变更是不需要授权的，按常规流程走就可以了。但即使这样，所有的变更也都有文档记录在案。例如：变更请求文档，用于审批的；变更进度计划，用于执行变更；变更预案，也就是预计这种变更带来的后果和如何消除此次变更可能带来的影响。 一旦有了变更请求，如果是常规的变更，变更管理员马上就可以做，自动获得授权；如果不是，就要提交变更委员会，这通常包括业务负责人和运维部门的所有人，要召开会议，给出授权；如果还有重大的变更，这种变更简直就是大换血，这种时候，高层管理层统统要介入。为什么要建立这样一种架构呢？就是为了要明确责任和规范操作。 再者，在IT运维技术，尤其是ITSM工具的最新进展方面，已经使得ITIL变更管理比以往更具吸引力。例如，配置管理数据库（CMDB）的改革已经给IT管理变更的方法带来了更多的灵活性。结果，配置管理正变得更成熟，超越了基本的IT资产清单，达到了自动识别和配置项定义的成熟度，关系和依赖使得变更管理和影响评估成为现实。这些技术，都为变更管理的实践提供了有力的支撑。