发布管理.docVIP

[原创]也谈发布管理 ? 从基于对生产环境变更只有唯一的一个入口，也就是发布管理来说，通过对发布管理的分类来进行不同变更的实施，是有积极意义的。因此,涉及到生产环境变更的发布管理的流程分类可以区分如下： 对于新的硬件接入，新软件、新版本或版本的重大升级应该是发布管理的重要控制部分； 而对于一般的变更，或者比较小的变更，则可以简化流程； 而对于紧急变更，则在发布管理里走的流程又是另一个分支； 至于服务的变更，则可以考虑在发布管理里再分出一个类来，走另外一个流程。 这样，将发布管理完全融合进变更管理，在管理方面应该是比较简单一些，没有那么多交叉关系 ITIL发布管理 yadjun 发表于: 2007-11-18 16:42 来源: ITIL中国 字体: 小 中 大 ? 本文发表于《中国计算机用户》 2007年5月14日 第17期 管理栏发布管理和变更管理之间你中有我，我中有你的亲密关系已成为ITIL的共识，但正是这种亲密无间的关系也一直在困扰着很多人。互联网上有人提问“从流程上来看，这两个管理类似，都有提出计划，比如测试计划，实施计划等，但是我不知道这两个的分工具体怎么确定，比如说什么样的任务该由变更管理来处理，什么样的任务该由发布管理来处理？”有人回帖：“变更关心的是从变更发起到变更批准或拒绝之间的流程,变更管理中的内容包含发布管理,比如测试计划,回退计划等，但这些计划内容都在发布管理中执行和制作。”“变更管理中的内容包含发布管理”回帖中的这句话在ITIL中已有描述 “发布管理流程的实施应当在变更管理的控制下进行，发布管理几乎贯穿整个变更管理生命周期”。由此，我们应该将发布管理看作是变更管理的一部分，而不是脱离于变更管理的另外一种管理分工。 图1 客户服务中心ITIL框架 图1的客户服务中心ITIL框架，让我们看到的是没有变更管理的发布管理。这种ITIL框架不论有何种解释，都有悖于发布管理是变更管理一部分的ITIL共识。如果用皮毛相依来比喻二者之间关系，那么“没有变更管理的发布管理”带给我们的将是一个“皮之不存，毛将焉附”式的疑问。在《面壁ITIL之变更管理》中，笔者也将客户服务中心变更管理的缺位作了一个说明。客户服务中心不久将会建立变更委员会，强化变更管理，以期达到变更风险可控的目的。同时也将改变了客户服务中心的ITIL框架中没有变更管理的设计缺陷。现假定客户服务中心的变更管理缺位得到妥善解决，发布管理在变更管理的控制下按部就班地工作着，但是仍然有一个问题未得到清晰的回答。网上的问答，回帖者虽然说清了变更管理对发布管理的支配关系，可是仍未能解释清楚发布管理和变更管理之间存在的某种关系。笔者曾就此和一位朋友聊过。笔者当时问这位朋友：“变更都已经完成了，再来发布不是有点事后的意味吗？”朋友回答道：“不能孤立理解的。比如软件的发布，也许是和变更实施同时进行的。问题解决完成，成为一个已知问题，此时对问题进行发布，是在问题解决时完成的。”这段对话，倒是让笔者对变更和发布之间的关系作了一个小小总结：一次变更可以和发布同时发生，也可以在发布之前发生，但决不可能在发布之后发生。推而广之，变更管理可以在发布管理之前进行，也可以和发布管理同时进行，决不可能在发布管理之后进行。错！变更和发布之间可以这么下结论，但变更管理和发布管理之间是不能用这个推论来套用。因为，变更管理是由一个一个的变更控制过程构成，每一个变更控制过程都有可能涉及发布，涉及发布管理。至此，我们似乎找到了变更管理和发布管理之间存在的某种关系，即发布管理贯穿于变更管理流程之中，为变更控制过程服务，并随着变更可大可小，变更小时就作为变更管理的一份子来管理；变更大时，可以单独拿出来作为发布管理运作。当了解了发布管理和变更管理之间的支配与服务的关系之后，仍然有一个问题需要深入理解。发布管理的范围究竟在哪里？ITIL中变更管理的对象有两个：一个IT基础架构的变更（包含各种软硬件的变更），一个IT服务（服务支持形式或内容的变更等）的变更。从发布管理的定义看，凡经过测试后导入实际应用的新增或修改后的配置项都可以归入发布管理范围。定义似乎已经将发布管理的范围界定清楚，但是，在发布管理的定义之后还有一句话非常令人费解：发布管理以前又称为软件控制与分发。为什么要在这里强调发布管理的历史？再往下读又会发现，无论是在基本概念、目标范围还是主要的活动，发布管理都在讲述的是有关软硬件的发布。这前前后后的矛盾，实在令人有点晕乎。在互联网上搜索配置管理、变更管理和发布管理这三项内容，我们会发现它们都和软件开发相关。可以说ITIL是借鉴了软件开发控制过程中的精华部分，也就不难理解发布管理为什么和软件开发这么近乎。所以，在介绍发布管理的时候，我们了解到更多的是有关软件发布的控制和分发。“发布管理负责