发布管理

[原创]也谈发布管理发布管理，其实是作为变更管理的一部分存在，指的是将变更实施到生产环境中的过程。

从基于对生产环境变更只有唯一的一个入口，也就是发布管理来说，通过对发布管理的分类来进行不同变更的实施，是有积极意义的。

因此,涉及到生产环境变更的发布管理的流程分类可以区分如下：对于新的硬件接入，新软件、新版本或版本的重大升级应该是发布管理的重要控制部分；而对于一般的变更，或者比较小的变更，则可以简化流程；而对于紧急变更，则在发布管理里走的流程又是另一个分支；至于服务的变更，则可以考虑在发布管理里再分出一个类来，走另外一个流程。

这样，将发布管理完全融合进变更管理，在管理方面应该是比较简单一些，没有那么多交叉关系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是借鉴了软件开发控制过程中的精华部分，也就不难理解发布管理为什么和软件开发这么近乎。

所以，在介绍发布管理的时候，我们了解到更多的是有关软件发布的控制和分发。

“发布管理负责的主要组件包括内部开发的应用程序、单位外购的软件产品、外包服务商提供的系统和工具软件以及硬件产品等”ITIL在界定发布管理范围时最后将硬件内容考虑了进去。

这也许是ITIL根据自身特点对源自软件开发控制过程的发布管理作的一个补充。

现在的ITIL已经对IT基础架构中的软硬件组件实现了全面的控制。

于是，又一个问题随之而来。

IT服务的变更是否也应该纳入发布管理？ITIL对于发布管理的通篇论述中并没有看到有关的字眼。

IT服务的变更是否需要发布？如何发布？ITIL没有给出答案，也不需要给出什么答案。

其实IT服务的变更与发布皆可参照IT基础架构的变更与发布模式进行管理。

二者之间没有本质的区别。

变更管理与发布管理之间的“灰色地带”是ITIL众多灰色地带中比较费解的一个。

扯不清的你中有我，我中有你关系，再加之模棱两可的管理分工既让人苦恼，又使人着迷。

如果要用一句话为发布管理做最后的陈述，应该是：发布管理只做正确的事。

数百万个补丁是怎么分发管理的？某部是国家重要的职能部门，它的日常业务繁多而重要，而且大多数业务需要使用它的信息网进行，因此保障信息网的正常运转就非常重要。

该部的信息网是物理隔离网络，覆盖全国各地，由部、省、市三级网络组成。

部级信息中心的主路由交换设备连接全国30多个省级单位网络（包括某部北京城域网网络）。

在建设补丁三级联管理体系之前还没有采用域的方式管理，但信息网已经安装了硬件防火墙系统、网络防病毒系统、入侵检测等多种安全监控设备，在这些设备的严密监控下，来自外部网络和局域网的安全威胁大大减少。

此时，来自网络内部的安全漏洞威胁，才是网络管理人员所需要面对的挑战。

某信息网的大部分使用者为业务人员，他们不熟悉计算机系统，对操作系统的漏洞进行补丁修复的意识也比较淡薄，这就造成某信息网中终端计算机的系统漏洞不能及时地修补，甚至长期不补。

连在某信息网上的计算机大约有数10万台，但是大部分使用人员对于IT不熟悉，所有打补丁的工作就得全部由技术部门的人员来做。

随着微软补丁的发布越来越频繁，传统的手工补丁安装已经远远不能适应大规模网络管理需要，技术人员的工作量非常大，工作负担也非常繁重。

从以前的情况来看，让少数几个技术人员负责打补丁还存在不少弊病，比如进度缓慢，出现漏打补丁等现象。

前期准备不可少面对这样的困境，如何才能够解决呢？首先，要解决外网补丁导入和补丁源统一的问题。

某信息网是物理隔离的网络，从外网向物理隔离的内网导入补丁非常麻烦。

若网络每个终端都从外网下载补丁会消耗过量的网络资源，而且用户随意下载的补丁来源不统一、不可靠，存在网络安全隐患。

北信源公司的补丁分发管理系统利用一个专门的补丁下载服务器统一下载补丁，先由部级的补丁下载服务器从外网中自动获得并更新补丁索引列表。

这个补丁索引列表在制作前已经进行过测试，它排除掉了部分可能导致系统瘫痪或有其他问题的补丁。

根据这个索引列表，补丁下载服务器利用增量式补丁自动分离技术，将补丁导入内网，而且只导入以前没有导入过的补丁。

补丁导入内网后，补丁分析器自动将补丁分类存入内网补丁库。

这样就确保了补丁来源的安全性与可靠性。

补丁安全导入内网的分发也存在问题。

某信息网的终端数量庞大，为了使所下载的补丁具有可行性，在进行全网分发前，先选定少量终端进行真实环境局域网的补丁测试，通过测试的补丁才分发给全网终端。

其次，该信息网是三级管理网络，与之相配的补丁分发管理系统也必须支持三级联管理，可以实现部、省、市三级网络终端补丁的自动分发和统一管理。

北信源公司补丁分发管理系统从部级信息中心统一更新维护部级管理系统及补丁库，自动将最新补丁及时地、强制性地分发至省级管理系统，再由省级管理系统自动分发到市级管理系统。

在分发过程中，网络管理人员通过中央管理控制平台设定补丁安装策略，设定补丁安装策略的分配对象。

补丁安装主动权首先掌握在客户端手中。

客户端通过管理器获取并刷新补丁，利用微软安全基准分析器分析出自己本身已安装的补丁情况。

根据补丁策略和当前补丁情况，客户端决定是否下载并安装新的补丁。

对于必须安装的补丁，网络管理人员可以通过策略强制客户端安装，否则就阻断其正常联网。

为了方便对整个网络补丁安装情况的监控，各级管理系统还详细记录下补丁的分发、接收及修补等情况，查询、统计漏洞情况和补丁修补状况，并且自动向上级管理系统上报相关的信息。

这样网络管理人员的工作量大大减少了，补丁安装的效率也大大提高了。

万台终端的分发难题以上问题顺利解决后，所有客户端都可以统一安装安全可靠的补丁。

但是新的问题又出来了。

那就是，某信息网一个市级管理节点往往管理着数千甚至上万台计算机，若所有的客户端都从同一台服务器上下载补丁，网络负载就会过重，严重时还会造成网络阻塞，影响网络正常的运行。

北信源公司的补丁分发管理系统采用流量控制技术解决了这个问题。

系统利用客户端转发代理，实现补丁的顺利分发。

补丁分发时，部分客户端先通过补丁分发系统下载服务器中的补丁，这些客户端可以称为代理。

其他的计算机则通过这些代理进行相应的补丁下载。

下载时客户端可自动搜索临近的IP地址，选择拥有此补丁文件并且下载速度最快的客户端作为代理进行补丁下载。

这样就提高了网络的利用率，提高了补丁的分发效率。

在该信息网补丁分发管理系统中，该部信息中心的中心节点（一级管理节点），其下属的各省某厅为该系统的二级管理节点，各市某局为系统的三级管理节点。

各级管理节点进行级联。

下级管理节点的补丁库从上级管理节点下载导入补丁。

下级节点所存储的重要信息（如报警信息、重要状态信息、统计信息）经过整理后汇总上报到上级管理节点。

上级管理节点能通过授权进入下级管理节点，以查询所需信息。

该部通过公开招标统一购买了北信源公司服务器端软件500套和不限量安装的客户端软件。

这些软件配发到全国各地各二级、三级管理节点进行安装运行。