畅享博客 > ITSM-适境而为 > IT服务管理 > [原创]面壁ITIL之发布管理[本文被AMT公共知识库收录,奖励200金币,祝贺]
2007-5-5 21:52:41

[原创]面壁ITIL之发布管理[本文被AMT公共知识库收录,奖励200金币,祝贺]

本文发表于《中国计算机用户》 2007年5月14日 第17期 管理栏

发布管理和变更管理之间你中有我,我中有你的亲密关系已成为ITIL的共识,但正是这种亲密无间的关系也一直在困扰着很多人。互联网上有人提问“从流程上来看,这两个管理类似,都有提出计划,比如测试计划,实施计划等,但是我不知道这两个的分工具体怎么确定,比如说什么样的任务该由变更管理来处理,什么样的任务该由发布管理来处理?”有人回帖:“变更关心的是从变更发起到变更批准或拒绝之间的流程,变更管理中的内容包含发布管理,比如测试计划,回退计划等,但这些计划内容都在发布管理中执行和制作。”

“变更管理中的内容包含发布管理”回帖中的这句话在ITIL中已有描述 “发布管理流程的实施应当在变更管理的控制下进行,发布管理几乎贯穿整个变更管理生命周期”。由此,我们应该将发布管理看作是变更管理的一部分,而不是脱离于变更管理的另外一种管理分工。

1 客户服务中心ITIL框架

1的客户服务中心ITIL框架,让我们看到的是没有变更管理的发布管理。这种ITIL框架不论有何种解释,都有悖于发布管理是变更管理一部分的ITIL共识。如果用皮毛相依来比喻二者之间关系,那么“没有变更管理的发布管理”带给我们的将是一个“皮之不存,毛将焉附”式的疑问。在《面壁ITIL之变更管理》中,笔者也将客户服务中心变更管理的缺位作了一个说明。客户服务中心不久将会建立变更委员会,强化变更管理,以期达到变更风险可控的目的。同时也将改变了客户服务中心的ITIL框架中没有变更管理的设计缺陷。

现假定客户服务中心的变更管理缺位得到妥善解决,发布管理在变更管理的控制下按部就班地工作着,但是仍然有一个问题未得到清晰的回答。网上的问答,回帖者虽然说清了变更管理对发布管理的支配关系,可是仍未能解释清楚发布管理和变更管理之间存在的某种关系。笔者曾就此和一位朋友聊过。笔者当时问这位朋友:“变更都已经完成了,再来发布不是有点事后的意味吗?”朋友回答道:“不能孤立理解的。比如软件的发布,也许是和变更实施同时进行的。问题解决完成,成为一个已知问题,此时对问题进行发布,是在问题解决时完成的。”这段对话,倒是让笔者对变更和发布之间的关系作了一个小小总结:一次变更可以和发布同时发生,也可以在发布之前发生,但决不可能在发布之后发生。推而广之,变更管理可以在发布管理之前进行,也可以和发布管理同时进行,决不可能在发布管理之后进行。错!变更和发布之间可以这么下结论,但变更管理和发布管理之间是不能用这个推论来套用。因为,变更管理是由一个一个的变更控制过程构成,每一个变更控制过程都有可能涉及发布,涉及发布管理。至此,我们似乎找到了变更管理和发布管理之间存在的某种关系,即发布管理贯穿于变更管理流程之中,为变更控制过程服务,并随着变更可大可小,变更小时就作为变更管理的一份子来管理;变更大时,可以单独拿出来作为发布管理运作。

当了解了发布管理和变更管理之间的支配与服务的关系之后,仍然有一个问题需要深入理解。发布管理的范围究竟在哪里?

ITIL中变更管理的对象有两个:一个IT基础架构的变更(包含各种软硬件的变更),一个IT服务(服务支持形式或内容的变更等)的变更。从发布管理的定义看,凡经过测试后导入实际应用的新增或修改后的配置项都可以归入发布管理范围。定义似乎已经将发布管理的范围界定清楚,但是,在发布管理的定义之后还有一句话非常令人费解:发布管理以前又称为软件控制与分发。为什么要在这里强调发布管理的历史?再往下读又会发现,无论是在基本概念、目标范围还是主要的活动,发布管理都在讲述的是有关软硬件的发布。这前前后后的矛盾,实在令人有点晕乎。

在互联网上搜索配置管理、变更管理和发布管理这三项内容,我们会发现它们都和软件开发相关。可以说ITIL是借鉴了软件开发控制过程中的精华部分,也就不难理解发布管理为什么和软件开发这么近乎。所以,在介绍发布管理的时候,我们了解到更多的是有关软件发布的控制和分发。

“发布管理负责的主要组件包括内部开发的应用程序、单位外购的软件产品、外包服务商提供的系统和工具软件以及硬件产品等”ITIL在界定发布管理范围时最后将硬件内容考虑了进去。这也许是ITIL根据自身特点对源自软件开发控制过程的发布管理作的一个补充。现在的ITIL已经对IT基础架构中的软硬件组件实现了全面的控制。

于是,又一个问题随之而来。IT服务的变更是否也应该纳入发布管理?ITIL对于发布管理的通篇论述中并没有看到有关的字眼。IT服务的变更是否需要发布?如何发布? ITIL没有给出答案,也不需要给出什么答案。其实IT服务的变更与发布皆可参照IT基础架构的变更与发布模式进行管理。二者之间没有本质的区别。

变更管理与发布管理之间的“灰色地带”是ITIL众多灰色地带中比较费解的一个。扯不清的你中有我,我中有你关系,再加之模棱两可的管理分工既让人苦恼,又使人着迷。如果要用一句话为发布管理做最后的陈述,应该是:发布管理只做正确的事。


推荐到鲜果: 查阅更多相关主题的帖子: ITIL ITSM IT服务管理 ITIL发布管理 IT治理 IT治理

评论

发布管理,其实是作为变更管理的一部分存在,指的是将变更实施到生产环境中的过程。

 

从基于对生产环境变更只有唯一的一个入口,也就是发布管理来说,通过对发布管理的分类来进行不同变更的实施,是有积极意义的。因此,涉及到生产环境变更的发布管理的流程分类可以区分如下:

对于新的硬件接入,新软件、新版本或版本的重大升级应该是发布管理的重要控制部分;

而对于一般的变更,或者比较小的变更,则可以简化流程;

而对于紧急变更,则在发布管理里走的流程又是另一个分支;

至于服务的变更,则可以考虑在发布管理里再分出一个类来,走另外一个流程。

这样,将发布管理完全融合进变更管理,在管理方面应该是比较简单一些,没有那么多交叉关系。


发布者 天笑
2007-5-7 11:14:25


谢谢天笑的补充。

发布者 ewaysun
2007-5-7 14:08:03


受益匪浅

发布者 匿名用户
2007-5-15 9:13:42


楼主,可以留下你的MSN么?我最近在研究发布管理,希望可以和楼主探讨,学习

发布者 匿名用户
2007-6-28 14:22:52


发布者 ewaysun
2007-6-28 14:47:00


ITIL之发布管理

发布者 pilang
2007-7-2 22:47:11


还有一点令人费解的是:为何要将发布流程独立出来,其实单单有一个变更流程也是可以的,有什么不妥?将发布的职能统一交由变更也是可以的。

发布者 匿名用户
2008-1-22 11:17:30


在实际中,如果变更流程能够很好地控制发布,那么可以不用单独设立发布流程。但是,其实正是因为发布流程的存在和规范才使得变更管理能做到很好的控制。基于发布的重要性,单独列为一个流程也未尝不可。

发布者 ewaysun
2008-1-22 12:15:10


您正在以 匿名用户 的身份发表评论  快速登录
(不得超过 50 个汉字)
       看不清,换一个
提示消息
(输入完内容可以直接按Ctrl+Enter提交)