ITIL Foundation Series （3）变更管理、发布管理.ppt

《ITIL Foundation Series （3）变更管理、发布管理.ppt》由会员分享，可在线阅读，更多相关《ITIL Foundation Series （3）变更管理、发布管理.ppt（41页珍藏版）》请在三一办公上搜索。

1、ITIL Foundation Series（3）变更管理、发布管理,启示,Receive，follow，or lead changes?,被动变化，跟随变化，引领变化?,变更带来的问题,怎样才能控制变更带来的负面影响？怎样评估变更对生产环境的风险？为什么变更总会带来意想不到的事件？哪些人需要参与到变更管理中来？怎样把所发生的事件或问题与以往的变更关联起来？如果变更不成功，该怎么办？怎样才能有效的管理用户或者使用者的变更？,业务需求,系统性能,业务需求,系统性能,已知差距,未知差距,变更管理概述,关键词最小风险最小影响屏蔽风险控制、审批、协调,为在最短的中断时间内完成基础架构或服务的任一方面的

2、变更而对其进行控制的服务管理流程,目标：确保标准方法和过程可以得到使用，因而变更可能很快地、对服务服务质量可能影响最小地得以处理所有的变更都必须可跟踪，或者说，可以很容易地回答“什么变更了”这样的问题,运作变更管理,项目变更管理,运作变更管理请求,变更实施,变更监控,变更管理的范围,AD Lifecycle Release Management,Service Desk/Incident Control（Service Recovery）,Change Management,Configuration Management Database（CMDB）,Definitive Software

3、Library（DSL）,Incident,New ServicesUpdatesIntegration with Change Management,Release Qualification Release StrategiesTesting RequirementsProduct Sign-offDocumentation Support Requirement,Problem Management（System Problem Elimination）,Problem Record,Known Error Record,Monitor?,Classification&Analysis,

4、Root Cause Analysis,New Problem,Root Cause,Solution?,Development Environment开发环境,Staging Environment筹备环境,Production Environment生产环境,变更类型,标准变更被制造商明确定义并由他们完成的常规管理任务，不需要由变更管理来控制，这种变更被称之为标准变更常规任务例：新建用户帐号，改变网络连接和安装PC等在标准变更的情况下，活动在完整变更管理流程中不是作为变更来执行，但是可以划分为事件管理下的服务请求这些变更定期被执行不是所有的服务请求都是变更非标准变更所有其它管理基础架构的修

5、改都是非标准变更举例,变更类型（续）,紧急变更在事件管理流程中，一种应急措施可以用来解决一个严重的事件。但是如果情况严重且不允许延迟，可能需要启动紧急变更请求（RFC）程序在紧急变更发生之前可能没有足够 的时间做正常的测试，但是之后，正常流程所有必需的步骤都必须完成以保证任何以前跳过的测试现在都被 执行，并且文档（变更记录和CMDB）也得到了更新在需要执行紧急变更的情况下，如果有时间，变更经理可以组织一次CAB/EC的紧急会议，这种会议仅有特定的成员需要对其评价，授权，为其分配资源,区分变更类型的依据/变更的性质,区分变更类型的依据CI的关键度级别不实施的影响技术复杂程度持续时间资源变更的性质

6、事件驱动型变更：故障驱动型排障性预防性计划型变更：需求驱动型，功能模块从无到有从有到优,变更类型：非标准变更,CABChange Advisoring BoardPCABDCAB,CAB/ECEmergency CommittmentCMChange ManagerMBManagement Board,变更请求,定义对一个或多个特定配置项实施变更的正式请求说明了变更的内容及与变更有关的配置项包括标准变更和非标准变更两种为什么要RFC要求解决事件或问题用户或客户对服务不满引入或移除某个配置项升级基础架构组件业务需求改变出现新法规或原有法规发生改变改变位置厂商或承包商提出改动产品或服务,变更请求例

7、子（RFC）,Backout Plan回退计划Rollout Plan试运行计划,发布管理,主要活动,配置管理流程,提交&登记RFC,筛选&接受RFC,归类&排序,计划&组织,评价&终止,实施,构建,测试,紧急RFC？,可以运行,拒绝,紧急处理程序,启动回撤计划,记录审查归类规划和批准协调评价,记录,主要活动,RFC从哪里来？问题管理：提交处理办法以消除错误，维护服务的稳定运作用户：可能请求更多，更少或其它服务供应商：供应商发布新的版本并更新他们的产品，确定他们所补救的借误，他们可能也与相互通信，表求不再支持某些版本，或者某个版本的执行不安全。这可能引发问题管理或可用性管理提出一个变更请求计划

8、：一项计划往往会带来大量的变更。计划管理必须通过相关的流程有效地与变更管理协调，例如：服务级别管理，能力管理等等所有其它IT人员：原则上，任何人都可以提交意见以提高服务质量，特别地，IT人员对程序和手册的提高作出贡献RFC记录中包括哪些内容,审查,归类,规划和批准,协调,评价,记录,主要活动,如何审查？当RFC被记录后，变更管理将会作出一个初步评估以检查是否有RFC不清楚、不合理、不可行或者不必要如果拒绝这项请求，需要说明原因，并给予提交请求的人解释的机会审查的结果？CMDB中的数据的更改现有CI状况的变更CI与其它CI之间的关系的变更新的CI，或者现有CI的变种CI的新属主或地点变更记录的生

9、成指定的优先级对影响和所需成本的评估变更计划实施数据拒绝请求的原因,审查,归类,规划和批准,协调,评价,记录,主要活动,影响度次要影响：要求很低，且造成重大服务问题的风险也极低，CM无需提交CAB，就批准变更实质影响：需要大量工作，且对服务有切实的影响的变更。这些变更需要在CAB会议上进行讨论以决定所需的工作和潜在的影响重大影响：需要做大量的工作，且会影响到组织的主要部分的变更。变更经理需要有IT管理或IT筹备指导委员会的优先级授权，在此之后，变更必须经过CAB优先级低优先级：一些变更很值得，但可以较长时间后实施一般优先级：没有紧急或重大的影响，但是变更不能被推迟高优先级：影响很多用户的错误或

10、困难，或与其它紧急事件有关的错误，将在下一次CAB会议中给予最高优先级最高优先级：关注严重影响用户使用潜在服务的问题，或紧急变更,审查,归类,规划和批准,协调,评价,量化？具体化？,如何体现？环节、措施,记录,主要活动,变更规划变更管理使用变更日历或者变更进度计划表（FSC（Forward Schedule of Change）来规划变更。FSC包括所有批准的变更及其计划实施数据为了有效地规划，变更管理必须与项目小组成员以及其它创建和实施该变更的人保持密切联系批准的类型最终批准成本/优势分析和预算技术批准影响，必要性和可行性业务批准由要求变更和受变更影响功能的用户批准,审查,归类,规划和批准,

11、协调,评价,记录,主要活动,审查,归类,规划和批准,协调,评价,变更策略RFC可以组合到一个发布中，这样大量的发布本身必须被看作是一项变更，即便是它包含很多每一个都可单独得到批准的变更变更策略必须旨在避免对用户不必要的干扰影响和资源估计受影响服务的能力和执行可靠性和可恢复性IT服务持续性管理备份计划安全性变更对其它服务的影响记录和批准所需的资源和成本（支持和维护）所需专家的数目和可用性变更所需的周期时间,记录,主要活动,创建不是所有变更都有明确的创建阶段。例如：标准变更创建可能包括产生新的版本，新的文档和手册，安装程序，备份计划和硬件变更如果变更没有给出要求的结果，备份程序必须作为变更提交的一

12、部分。如果没有备份程序，变更管理不能批准变更测试备份程序、变更实施和变更预计结果都必须全面测试测试方式：用户验收测试：业务小组（通常是变更用户）测试变更的功能运作验收测试：必须由支持和维护基础架构变更的人进行的独立测试实施任何负责管理IT基础架构的相关部门都可能需要实施变更变更管理确保变更处于变更进度表中需要一个明确的计划显示谁必须知道如果变更不能得到充分的测试，则可在少量用户中实施该变更，并在大规模实施该项变更之前对小规模实施的结果进行评估以了解大规模实施该变更的合理性,审查,归类,规划和批准,协调,评价,记录,主要活动,评价内容变更是否达到预定的目的？用户对结果是否满意？是否有副作用？是否

13、超过预估的成本和代价？评价结果如果变更实施成功，变更请求（RFC）结束。通过实施后评审（PIR）来测试如果变更不成功，流程将采用修正后的方法，从出错的地方重新执行一般情况下，最好是备份变更，并在原始变更请求的基础上创建一项新的变更请求,审查,归类,规划和批准,协调,评价,与其它流程之间的关系,ConfigurationManagement,ProblemManagement,ReleaseManagement,IncidentManagement,（Plan）,（Do）,（Register）,（Act/Analyse）,变更记录影响度分析记录配置项关系配置项的影响,变更整合到一个发布，新发布的

14、试运行(Rollout)由变更管理进行控制,纠正错误，解决问题，如果变更未很好控制会造成新的错误，新的问题,（Check）,PDCA,PDCA,PDCA,PDCA？,变更管理处理事件管理流程提出的变更请求变更的实施还是可能导致错误和事件,可用性管理发起旨在提高服务可用性的变更。如果真的得到了提高，它也会进行验证。可用性管理通常也参与估计变更的潜在影响，反过来，变更的影响又会对服务可用性产生 作用,变更管理与IT服务持续性管理密切合作以保证IT持续性管理能知晓所有可能影响修复计划的变更并采取措施确保修复工作的顺利完成,在能力计划的基础上，能力管理将有规律地以变更请求的形式提议增加或者变更，以提高

15、现有能力的使用，并对其进行扩展,与其它流程之间的关系,可用性管理,能力管理,IT服务持续性管理,如果变更可能 带来较大的影 响或风险，则就必要性和时间需与用户讨论。变更管理需向服务级别管理提交服务计划可用性报告，列出对现有服务级别协议的改变,服务级别管理,关键成功因素和绩效指标,关键成功因素配置管理提供准确的配置信息问题管理提供可靠的问题分析报告和合理的变更请求发布管理与变更管理之间的良好协调明确变更经理的权限和责任组建合理有效的变更顾问委员会关键绩效指标绩效指标使变更管理流程在对现有服务级别影响最小的情况下，处理变更的有效性和高效程序包括每一类变更的数目变更实施的速度引发变更的事件的数目与变

16、更相关的备份数目有资源和时间估计的变更数目,问题：与实际工作结合,优点？,不足？,启示,?,勿以善小而不为，勿以恶小而为之,发布管理定义,定义对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程以前称为软件控制与分发，由变更管理流程控制目标计划和协调软硬件组件的发布设计和实施有效的程序来分发和安装IT系统的变更确保只有正确的、被授权的和经过测试的软硬件版本才能导入实际运作环境结合变更管理，准确发布确切内容和首次发布计划确认所有最终软件库中软件正本的拷贝是安全可靠的，并且在配置管理数据库中得到了更新,Release Management,发布管理范围,范围负责对软件和硬件进行规

17、划、设计、构建、配置和测试，以便为实际运行环境提供一系列的发布组件受控组件自行开发的应用程序外购软件工具软件供应商提供的系统软件硬件和软件的规格说明装配指南和文档，包括用户手册必须要执行发布管理的情形重大或关键硬件的首次运行，特别是当业务系统对某个相关的软件变更具有较大依赖的情形主要软件的首次运行，特别是新的应用程序与其协同软件同时发布的情形将一组相关的变更打包成一个个适当规模的单元的情况,Development,Testing,Production,注意,Production,Testing,Development,Release Management,发布管理范围（续）,Release P

18、olicy,Release Planning,Develop or Purchase,Build&Configure,Functional Testing,Acceptance Testing,Rollout Planning,Communication preparation&Trainning,Distribution,Installation,DSL,Change Management,Configuration Management,发布与发布单元,发布：由一项或多项经过批准的变更所组成发布类型重大发布新硬件和软件的大型试运行，通常是伴随着重大的功能增强通常可以消除一些已知错误，包括临

19、时性的应急措施和临时性修复小型软件发布和硬件升级对已知错误进行的一些小的改进和修复有些可能已经作为紧急修复在早些时候实施了，但现在统一纳入到发布中这种发布还可以确保“前可信任状态”（即所有测试的出发点）得到更新紧急修复通常是作为对某个问题或已知错误的一次临时性修复而实施的发布单元：为了实现对变更控制以及保证其效果而一起发布的IT基础架构的一部分例：基于哪个层次？（系统、套件、程序或模块），DLL的更新,发布识别,发布识别定义软件的副本如何从DSL分发到相关的环境开发环境：以最终软件库（DSL）中的一个旧有版本为基础开发新的版本。版本的编号随着每一个新版本的出现而递增。软件一般只能在开发环境中进

20、行变更。测试环境：用于版本测试的环境，一般可以分为开发人员用的技术测试区、用户使用的功能测试区和发布构建者使用的实施测试区。也有可能还有供用户和管理部门使用的最终验收测试区。生产环境：信息系统对用户开放的实际运作环境存档：保留旧版本的软件。这些旧版本一般是不再使用的。但是如果有必要实施针对新发布的撤销计划是可能需要重新起用这些旧版本。,发布类型：德尔塔发布/全发布,德尔塔发布（“”）德尔塔发布是一种局部发布，它只包括那些发生变更的硬件和软件组件。（通常在紧急修复或临时修复时使用）缺点：不能对发布所包括的组件以外的环境进行测试那些不再被软件调用的模块也被删除了优点：需要花更少的工作来构建测试环境

21、全发布发布单元内的所有组件都同时被构建、测试和分发，包括那些没有变更的组件。（通常在不确切清楚变更的组件情况下使用）缺点：更多的准备工作和资源优点：多项变更同时实施准备工作可以使用既定的安装指南程序环境可以得到清理,包发布,全发布,德尔塔发布,发布类型：包发布,包发布指由一组相关的应用系统和基础架构的全发布和（或）德尔塔发布组成一般在更长的时间间隔内进行，通过修复小的软件错误以及将多项新的功能有效的组合到一起为用户提供了更长时间的稳定期,M1,M2,M3,M4,M1,C1,C2,软件1,软件2,M1,M2,M3,M4,M1,M2,M3,M4,C1,最终软件库（DSL）最终硬件库（DHS）,最终

22、软件库（Definitive Software Library）定义：最终软件库是一个存储所有软件配置项的最终批准版本（正本）的安全储存库DSL在物理上可能分布在多个地点，并且由安全的仓库和防火的保险柜组成。DSL中可能包括同一种软件的多个版本，包括存档版本、相应的文档记录和源代码等。需要定期备份，因为它包括当前的版本以及实施撤销计划时需要起用的旧版本。如果分布在多个地方进行管理，则每个地方应当备有一个最终软件库的拷贝以应付软件的试运行（Rollout）发布管理涉及从软件被纳入到最终软件库中开始的整个软件生命周期最终硬件库（Definitive Hardware Store）定义：最终硬件库中

23、包含了硬件的备件和库存这些备用组件和配件得到与它们在实际运作环境中的对应组件相同级别的维护，可以用来替换或修复IT基础架构中相似的配置，其配置构成的详细信息应该被记录在配置管理数据库（CMDB）中。,主要活动,发布政策制定和发布规划发布设计、构建和配置测试和发布验收试运行规划沟通、准备和培训发布分发和安装,配置管理数据库CMDB最终软件库（DSL）,政策和规划,主要活动,制定发布政策针对每一个系统，发布经理都应当制定一项发布政策来定义一项发布怎样以及何时得以配置发布规划重大发布应该提前对其发布识别或版本号进行规划，以便在恰当的时候可以考虑添加某项（些）变更发布经理还需要规定在什么层次上配置项或

24、以彼此独立地进行分发（发布单元）,在规划一项发布时需要考虑以下问题协调发布内容协商并确定发布日程安排、地点组织单元制定沟通计划现场考察协商并确定角色和职责获取详细报价单并与供应商谈判制定撤销计划制定质量计划由管理部门和用户共同对发布验收进行规划,设计和配置,测试和验收,沟通和培训,安装和分发,政策和规划,主要活动,设计、构建和配置为发布的设计、构建和配置开发标准的程序是一种明智和做法一项发布一般是基于自行开发或从第三方供应商购进并构建的一套组件（配置项）安装指示和配置发布的指示也应当被视为是发布的一部分，也应当被作为配置项处于变更管理和配置管理的控制之下。,回滚计划（Back-out Plan

25、）针对整个发布的撤销计划定义了在发布出现问题的情况下恢复服务所需进行的活动变更管理负责撤销计划的制定，而发布管理需要确保撤销计划符合实际的要求特别是在实施一项组合了多项变更请求的包发布时，对不同的撤销计划符合实际的要求一旦一项全发布或德尔塔发布出现了问题，则明智的做法是将该发布完全撤回到“前信任状态”。如果某项发布不能被完全撤回到原来的状态，则需要采取应急措施来尽可能多地恢复服务,设计和配置,测试和验收,沟通和培训,安装和分发,政策和规划,主要活动,发布测试不满意的变更和发布的最常见的原因是缺乏足够的测试。在实施之前，发布应该由用户代表对其进行功能测试并由IT管理人员进行运营测试。,发布验收在

26、发布管理可以开始运行（Rollout）前，变更管理必须安排由用户进行正式的验收以及由开发人员签发开发结束的标记对每一个步骤的正式验收必须由变更管理来进行发布应该在一个受控测试环境中进行验收以便该项发布可以被恢复至一个可知的配置状态,设计和配置,测试和验收,沟通和培训,安装和分发,政策和规划,主要活动,试运行计划日程安排和人力资源清单新安装、停止、退出的配置项清单每个地点可能的活动计划与有关方面进行沟通硬件、软件采购计划购买、存储、识别和记录所有配置管理数据库中即将发布的配置项与高层、管理、变更管理以及用户代表安排更新/评审会议,试运行实施的方式全面试运行“大爆炸”的方法分阶段试运行，该方式又具

27、体包括以下几种方案：功能递增：所有用户在同一时间获得新的功能地点递增：首先对某些用户群进行试运行，然后再扩散至所有的用户演进方式：功能分阶段扩展,设计和配置,测试和验收,沟通和培训,安装和分发,政策和规划,主要活动,沟通、准备和培训负责与客户沟通的人员（服务台和客户关系管理）、运营人员以及客户组织的代表都应该清楚发布计划的内容以及该计划将如何影响日常活动通过联合培训、合作和联合参与发布验收来实现如果发布是分阶段进行的，则应该向用户告知计划的应细内容，并告诉什么时候可以期望新功能正式上线针对服务级别协议（SLA）、运营级别协议（OLA），和支持合同（UC）所作的变更应该提前向所有相关人员进行传达

28、,设计和配置,测试和验收,沟通和培训,安装和分发,政策和规划,主要活动,安装和分发发布管理为软件和硬件的采购、存储、运输、交付和移交监控整个物流流程。该流程由一些相应的程序、记录以及包装单据等附属文档来支持，从而可以为配置管理提供可靠的信息硬件和软件存储设施应该确保安全并且只有经过授权的人员才可以进入最好使用自动工具来进行软件分发和安装，这样可以减少分发所需要的时间、提高发布的质量，减少需要的资源安装之前，检查发布即将导入的环境是否满足一些条件，如：房间，电源，磁盘空间等在安装后，配置管理数据库（CMDB）中的信息应立即进行更新以便可以检验任何的许可证协议,设计和配置,测试和验收,沟通和培训,

29、安装和分发,关键成功因素与KPI,关键成功因素与变更管理流程的良好协调准确的配置管理数据制定明确的发布政策和发布计划制定完善的首次运行计划与客户进行良好的沟通，对客户进行必要的培训充分的发布测试和发布验收关键绩效指标在资源预算的限度内按计划构建和实施发布的数量,构建失败的次数最终软件库（DSL）管理的安全性和准确性所有进入最终软件库（DSL）中的软件都通过了质量检验所有外购软件都符合有关的法律规定准确地将发布的软硬件版本分发至所有远程地点没有未经授权的版本替代以前的版本发布构建中没有出现浪费的复制版本计划的发布项目与实际的发布项目保持一致发布管理所需的IT和人力资源得到良好的后续规划和安排,后记,谢谢,