ITIL V3 服务转换篇 之 开发部署管理

一、与发布管理有关的概念

1.发布

      发布是由一项或多项经过批准的变更所组成。根据层次的不同，它可分为以下三类。
        a). 重大发布:新的硬件和软件的大型试运行，通常是伴随着重大的功能增强。这种发布通常可以消除多个已知错误，包括临时性的应急措施和临时性修复。
        b). 小型软件发布和硬件升级: 这种发布通常是指对已知错误进行的一些小的改进和修复。有些可能已经作为紧急修复在早些时候实施了，但现在统一纳入到发布中。这种发布还可以确保“前可信任状态”得到更新。
        c). 紧急修复: 通常用来对某个问题或已知错误进行临时性修复。

2.发布单元

      发布单元(Release Unit)描述的是出于对实施的变更进行控制和确保变更效果而同时发布的IT 基础设施的组合。发布管理政策必须确定变更的组件是否应该在这些层次进行发布，以及该层次上相关的所有组件是否都应该被包括在发布单元中。该流程还针对一个发布中应该有的最少单元制定相应政策。

3.发布识别

      发布政策定义了软件的拷贝如何从最终软件库(DSL)分发到相关的环境。
            A). 开发环境: 以最终软件库(DSL)中的一个旧有版本为基础开发新的版本。版本的编号随着每一个新版本的出现而递增。软件一般只能在开发环境中进行变更。
            B). 测试环境: 用于版本测试的环境。一般可以分为开发人员用的技术测试区、用户使用的功能测试区和发布构建者使用的实施测试区。也可能还有供用户和管理部门使用的最终验收测试区。
            C). 生产环境: 信息系统对用户开放的实际运作环境。
            D). 存档: 保留旧版本的软件。这些旧版本一般是不再使用的，但是如果有必要实施针对新发布的撤销计划，可能需要重新起用这些旧版本。由于可能同时存在多个发布，因此通常给每个发布分配惟一的识别符。发布识别应该指出相关的配置项并包括一个含有两位或更多数字的版本号，例如：
                    a)  重大发布—— 工资管理系统V.1，V.2，V.3 等；
                    b)  小型发布—— 工资管理系统V.1.1，V.1.2，V.1.3 等；
                    c)  紧急修复发布—— 工资管理系统V.1.1.1，V.1.1.2，V.1.1.3 等。

4.发布类型

           A) 德尔塔发布: 德尔塔发布是一种局部发布，它只包括那些发生变发布某个变更。更的硬件和软件组件。德尔塔发布的优点在于只需要花很少的工作来构建测试环境。
           B) 全发布: 全发布指同时对发布单元内的所有组件进行构建、测试和分发，包括那些无需变更的组件。这种方法在不是完全清楚哪些组件会发生变更的情况下使用特别有用。在这种发布方式下，软件和硬件将得到更彻底的测试，因而在实施变更后产生的事件会更少。不过，全发布比德尔塔发布需要更多的准备工作和资源。
           C) 包发布: 包发布是指由一组相关的应用系统和基础设施的全发布和(或)德尔塔发布组成。它一般在更长的时间间隔内进行。它通过修复小的软件错误以及将多项新的功能有效地组合到一起为用户提供了更长时间的稳定期。通常，对诸如系统软件和办公应用软件等第三方软件的计划性升级适宜采用包发布。

二、发布管理的活动流程 1.发布政策制定和发布规划

      针对每一个系统，发布经理都应当制定一项发布政策来定义一项发布怎样以及在何时得以配置。重大发布应该提前对其发布识别或版本号进行规划，以便在恰当的时候可以考虑添加某项(些)变更。
      发布经理还需要规定在什么层次上配置项可以彼此独立地进行分发(发布单元)。这取决于处在发布控制之下的系统的性质。在对一项发布进行规划之前，需要收集有关产品生命周期、将要移交的产品、相关IT 服务及其服务级别的描述，以及相关变更请求的批准情况等方面的信息。

2.设计、构建和配置

       为发布的设计、构建和配置开发标准的程序是一种明智的做法。一项发布一般是基于自行开发或从第三方供应商购进并构建的一套组件。安装说明文档和配置发布的说明文档也应当被视为是发布的一部分，也应当被作为配置项处于变更管理和配置管理的控制之下。在现场安装之前，在“实验室”中构建和测试所有的硬件和软件是一种明智的做法。

3.撤销计划

      针对整个发布的撤销计划定义了在发布出现问题的情况下恢复服务所需进行的活动。变更管理负责撤销计划的制定，而发布管理需要确保撤销计划符合实际的要求。一旦一项全发布或德尔塔发布出现了问题，则明智的做法是将该发布完全撤回到原来稳定的状态。如果某项发布不能被完全撤回到原来的状态，则需要采取应急措施来尽可能多地恢复服务。最好的做法是事先就满足撤销计划的一些要求，如制作备份和提供备用服务器等。

4.测试和发布验收

      失败的变更和发布最常见的原因是缺乏足够的测试。在实施之前，发布应该由用户代表对其进行功能测试并由IT 管理人员进行操作测试，在测试的过程中，IT 管理人员还需要考虑技术操作、功能、运营、绩效以及与基础设施其他部分集成等方面的问题。测试还应该涉及安装手册、撤销程序以及对管理程序的任何变更。对每一个步骤的正式验收必须由变更管理来进行。最后一个步骤是批准可以实施的发布。在发布管理可以开始试运行之前，变更管理必须安排由用户进行的正式验收以及由开发人员签发的开发结束的标记。发布应该在一个受控测试环境中进行验收以便该项发布可以被恢复至一个可知的配置状态。

5.试运行规划

      在前期阶段制定的发布计划现在要由确切的实施活动和日程安排方面的信息来加以补充。

6. 沟通、准备和培训

      负责与客户沟通的人员(服务台和客户关系管理)、运营人员以及客户组织的代表都应该清楚发布计划的内容以及该计划将如何影响日常活动。这可以通过联合培训、合作和联合参与发布验收来实现。相关的职责应该得到充分的传达，并应该核实是否每个人都清楚他们的职责。此外，如果发布是分阶段进行的，则应该向用户告知计划的详细内容，并告诉他们什么时候可以期望新功能正式上线。针对服务级别协议(SLA)、运营级别协议(OLA)和支持合同(UC)所作的变更应该提前向所有相关人员进行传达。

7.分发和安装

      发布管理监控软件和硬件的采购、存储、运输、交付和移交的整个物流流程。该流程由一些相应的程序、记录以及包装单据等附属文档来支持，从而可以为配置管理提供可靠的信息。硬件和软件存储设施应该确保安全并且只有经过授权的人员才可以进入。可能的话，最好使用自动工具来进行软件分发和安装。这样可以减少分发所需要的时间、提高发布的质量。

三、发布流程的触发

      收到一个经过批准的变更请求后，发布流程开始运行。将发布包部署到目标环境中

1.发布流程的输入

     a) 已授权的变更
     b) 服务包、服务级别包
     c) 服务模式和服务验收标准
     d) 服务连续性计划
     e) 服务管理、运营计划和标准
     f) 技术、采购标准和目录
     g) 已获得的服务资产、组件及其文档
     h) 构建计划和模式
     i)  环境要求、构建规范、测试、发布、培训、灾难恢复、试点和部署
     j) 服务设计中的发布规则、发布设计
     k) 发布模式及其计划模板
     l) 发布各阶段执行和终止的标准

2.发布流程的输出

     a) 发布计划
     b) 已完成的发布活动的服务变更请求
     c) 服务通知
     d) 更新服务目录中新服务和变更过的服务的相关信息
     e) 对能力与环境进行测试
     f) 新的或变更过的服务管理文档
     g) 服务包包括客户的需求
     h) 服务级别协议、运营级别协议、合同
     i) 服务模型
     j) 新的 和变更过的服务报告
     k) 测试连续性计划
     l) 完整准确的配置项清单以及发布包、新的变更过的服务、基础设施配置 这些配置项的审计痕迹
     m) 与业务相关的服务能力计划
     n) 部署准备发布的发布包

四、关键指标

1.客户对性能需求的差异
2.服务事件数量
3.增强满意度
4.降低因服务测试问题或未经检验造成的问题而带来的客户不满
5.减少生产部署产生问题、诊断和修复事故的资源和成本
6.提高服务转换时流程与支持性文件的重复利用率
7.减少配置项与审计的偏差

 

其他相关文章：

 

ITIL V3 服务转换篇 之 资产和配置管理

ITIL V3 服务转换篇 之 变更管理 下篇

ITIL V3 服务转换篇 之 变更管理 中篇

ITIL V3 服务转换篇 之 变更管理 上

ITIL V3 服务转换篇 概述