解析ITIL众多灰色地带中比较费解的问题

oops1

作者：孙翊威 来源：赛迪网 字体[放大、标准、缩小]

变更管理与发布管理之间的“灰色地带”是ITIL众多灰色地带中比较费解的一个。扯不清的你中有我，我中有你关系，再加上模棱两可的管理分工，既让人苦恼，又使人着迷。

皮之不存，毛将焉附

发布管理和变更管理之间你中有我，我中有你的亲密关系已成为ITIL的共识，但正是这种亲密无间的关系也一直在困扰着很多人。

互联网上有人提问：“从流程上来看，这两个管理类似，都有提出计划，比如测试计划，实施计划等，但是我不知道这两个流程的分工具体该怎么确定，比如说什么样的任务该由变更管理来处理，什么样的任务该由发布管理来处理？”

有人回帖：“变更关心的是从变更发起到变更批准或拒绝之间的流程,变更管理中的内容包含发布管理,比如测试计划,回退计划等，但这些计划内容都在发布管理中执行和制作。”

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

图1所示是我们公司客户服务中心ITIL的框架，让我们看到的是没有变更管理的发布管理。这种ITIL框架不论有何种解释，都有悖于发布管理是变更管理一部分的ITIL共识。如果用皮毛相依来比喻二者之间关系，那么“没有变更管理的发布管理”带给我们的将是一个“皮之不存，毛将焉附”式的疑问。

流程相互贯穿

笔者曾将客户服务中心变更管理的缺位作过一个说明。客户服务中心不久将会建立变更委员会，强化变更管理，以期达到变更风险可控的目的。同时也将改变客户服务中心的ITIL框架中没有变更管理的设计缺陷。

现假定客户服务中心的变更管理缺位得到妥善解决，发布管理在变更管理的控制下按部就班地工作着，但是仍然有一个问题未得到清晰的回答。网上的问答，回帖者虽然说清了变更管理对发布管理的支配关系，可是仍未能解释清楚发布管理和变更管理之间存在的某种关系。

笔者曾就此和一位朋友聊过。笔者当时问这位朋友：“变更都已经完成了，再来发布不是有点事后的意味吗？”朋友回答道：“不能孤立理解。比如软件的发布，也许是和变更实施同时进行的。问题解决完成，成为一个已知问题，此时对问题进行发布，是在问题解决时完成的。”

这段对话，倒是让笔者对变更和发布之间的关系作了一个小小总结：一次变更可以和发布同时发生，也可以在发布之前发生，但决不可能在发布之后发生。推而广之，变更管理可以在发布管理之前进行，也可以和发布管理同时进行，决不可能在发布管理之后进行。

真是这样的吗？错！变更和发布之间可以这么下结论，但变更管理和发布管理之间是不能用这个推论来套用的。因为，变更管理是由一个一个的变更控制过程构成，每一个变更控制过程都有可能涉及发布，涉及发布管理。

至此，我们似乎找到了变更管理和发布管理之间存在的某种关系，即发布管理贯穿于变更管理流程之中，为变更控制过程服务，并随着变更可大可小，变更小时就作为变更管理的一份子来管理；变更大时，可以单独拿出来作为发布管理运作。


发布管理的范围

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

ITIL中变更管理的对象有两个：一个IT基础架构的变更（包含各种软硬件的变更），一个IT服务（服务支持形式或内容等）的变更。从发布管理的定义看，凡经过测试后导入实际应用的新增或修改后的配置项都可以归入发布管理范围。定义似乎已经将发布管理的范围界定清楚，但是，在发布管理的定义之后还有一句话非常令人费解：发布管理以前又称为软件控制与分发。

为什么要在这里强调发布管理的历史？再往下读又会发现，无论是在基本概念、目标范围还是主要的活动，发布管理都在讲述的是有关软硬件的发布。这前前后后的矛盾，实在令人有点晕乎。

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

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

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

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

发布管理的目标

对IT基础设施实施的变更一般都发生在一个复杂、分布式的环境里。在现在的客户/服务器应用模式下，这种变更经常会同时对客户端和服务器端产生影响。在这种情况下，硬件和软件的发布和实施需要进行审慎的规划。一项发布就是一组新的或变更后的配置项，它们是经过测试后一起被导入实际运营环境的。它由其所要实施的变更请求（RFC）来决定。发布管理采用一种项目规划的方法来实施IT服务中的变更，它负责处理变更项目所有技术和非技术方面的问题。

变更管理的目标是要通过正式的程序来确保生产环境的质量以及在实施新的版本时对其进行检查。

与变更管理不同，发布管理主要关注的是变更的实施，而变更管理则涉及整个变更流程，并且主要关注与变更有关的风险。发布管理与配置管理和变更管理密切配合，以确保每项发布都被更新到公用的配置管理数据库中。发布管理还要确保发布的内容在最终软件库中也得到更新。总体而言，发布管理主要涉及的还是软件方面。(X228)