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 ManagementService Desk/Incident Control（Service Recovery）Chan

3、ge ManagementConfiguration Management Database（CMDB）Definitive Software Library（DSL）Incident New ServicesUpdatesIntegration with Change ManagementRelease Qualification Release StrategiesTesting RequirementsProduct Sign-offDocumentation Support RequirementProblem Management（System Problem Elimination

4、）Problem RecordKnown Error RecordMonitor? Classification & Analysis Root Cause AnalysisNew ProblemRoot CauseSolution?Development Environment开发环境开发环境Staging Environment筹备环境筹备环境Production Environment生产环境生产环境变更类型变更类型 标准变更 被制造商明确定义并由他们完成的常规管理任务，不需要由变更管理来控制，这种变更被称之为标准变更 常规任务例：新建用户帐号，改变网络连接和安装PC等 在标准变更的情况

5、下，活动在完整变更管理流程中不是作为变更来执行，但是可以划分为事件管理下的服务请求 这些变更定期被执行 不是所有的服务请求都是变更 非标准变更 所有其它管理基础架构的修改都是非标准变更 举例变更类型（续）变更类型（续） 紧急变更 在事件管理流程中，一种应急措施可以用来解决一个严重的事件。但是如果情况严重且不允许延迟，可能需要启动紧急变更请求（RFC）程序 在紧急变更发生之前可能没有足够 的时间做正常的测试，但是之后，正常流程所有必需的步骤都必须完成以保证任何以前跳过的测试现在都被 执行，并且文档（变更记录和CMDB）也得到了更新 在需要执行紧急变更的情况下，如果有时间，变更经理可以组织一次CA

6、B/EC的紧急会议，这种会议仅有特定的成员需要对其评价，授权，为其分配资源区分变更类型的依据区分变更类型的依据/ /变更的性质变更的性质 区分变更类型的依据 CI的关键度级别 不实施的影响 技术复杂程度 持续时间 资源 变更的性质 事件驱动型变更：故障驱动型 排障性 预防性 计划型变更：需求驱动型，功能模块 从无到有 从有到优变更类型：非标准变更变更类型：非标准变更CABChange Advisoring BoardPCABDCABNon-Standard Change CategoriesDescription / InpactCommentsMajorMajor impact and/or

7、 large number of resource requiredHigh complexity-finance impact，number of resources，duration of the project，new functionality Projects that follow PLCKTBE ChangesMajor changes go through the PCAB，TCAB and the DCABSignificantSignificant impact and/or resource requirementsSignificant complexityProjec

8、ts that dont follow PLCBug fixesSignificant changes go through the DCAB onlyMinorFew resources requiredLow complexityMinor changes go through the DCAB onlyCAB/ECEmergency CommittmentCMChange ManagerMBManagement Board变更请求变更请求 定义 对一个或多个特定配置项实施变更的正式请求 说明了变更的内容及与变更有关的配置项 包括标准变更和非标准变更两种为什么要RFC要求解决事件或问题用户

9、或客户对服务不满引入或移除某个配置项升级基础架构组件业务需求改变出现新法规或原有法规发生改变改变位置厂商或承包商提出改动产品或服务变更请求例子（变更请求例子（RFCRFC）Requester InformationNameEmailPhone#Risk AnalysisContractual ObligationRisk / ImpactTechnical Description of Backout PlanWhats the impact of Not implemented?Change Request DetailsType of ChangeService Desk TicketRe

10、quested Date to ProductionBusiness Unit ImpactedEnvironment ImpactedLocated ImpactedStart TimeEstimated DurationTitle of ChangeTechnical Description of ChangeBackout Plan回退计划回退计划Rollout Plan试运行计划试运行计划发布管理主要活动主要活动配置管理流程提交&登记RFC筛选&接受RFC归类&排序计划&组织评价&终止实施构建测试紧急RFC？可以运行拒绝紧急处理程序启动回撤计划 记录 审查 归类 规划和批准 协调 评价

11、记录主要活动主要活动RFC从哪里来？ 问题管理：提交处理办法以消除错误，维护服务的稳定运作 用户：可能请求更多，更少或其它服务 供应商：供应商发布新的版本并更新他们的产品，确定他们所补救的借误，他们可能也与相互通信，表求不再支持某些版本，或者某个版本的执行不安全。这可能引发问题管理或可用性管理提出一个变更请求 计划：一项计划往往会带来大量的变更。计划管理必须通过相关的流程有效地与变更管理协调，例如：服务级别管理，能力管理等等 所有其它IT人员：原则上，任何人都可以提交意见以提高服务质量，特别地，IT人员对程序和手册的提高作出贡献RFC记录中包括哪些内容RFC标识码标识码相关联的问题相关联的问题

12、/已知错误码已知错误码相关配置项的描述相关配置项的描述和验证和验证变更原因及不实施变变更原因及不实施变更的后果更的后果要被变更的配置项当前的和要被变更的配置项当前的和新的版本新的版本提交人联系方式提交人联系方式提交建议的时间提交建议的时间估计的资源和时间计划，估计的资源和时间计划，变更优先级变更优先级审查归类规划和批准协调评价记录主要活动主要活动 如何审查？ 当RFC被记录后，变更管理将会作出一个初步评估以检查是否有RFC不清楚、不合理、不可行或者不必要 如果拒绝这项请求，需要说明原因，并给予提交请求的人解释的机会 审查的结果？ CMDB中的数据的更改 现有CI状况的变更 CI与其它CI之间的

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

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

15、终批准成本/优势分析和预算 技术批准影响，必要性和可行性 业务批准由要求变更和受变更影响功能的用户批准审查归类规划和批准协调评价记录主要活动主要活动审查归类规划和批准协调评价 变更策略 RFC可以组合到一个发布中，这样大量的发布本身必须被看作是一项变更，即便是它包含很多每一个都可单独得到批准的变更 变更策略必须旨在避免对用户不必要的干扰 影响和资源估计 受影响服务的能力和执行 可靠性和可恢复性 IT服务持续性管理 备份计划 安全性 变更对其它服务的影响 记录和批准 所需的资源和成本（支持和维护） 所需专家的数目和可用性 变更所需的周期时间记录主要活动主要活动创建 不是所有变更都有明确的创建阶段

16、。例如：标准变更 创建可能包括产生新的版本，新的文档和手册，安装程序，备份计划和硬件变更 如果变更没有给出要求的结果，备份程序必须作为变更提交的一部分。如果没有备份程序，变更管理不能批准变更测试 备份程序、变更实施和变更预计结果都必须全面测试 测试方式： 用户验收测试用户验收测试：业务小组（通常是变更用户）测试变更的功能 运作验收测试运作验收测试：必须由支持和维护基础架构变更的人进行的独立测试实施 任何负责管理IT基础架构的相关部门都可能需要实施变更 变更管理确保变更处于变更进度进度表中 需要一个明确的计划显示谁必须知道 如果变更不能得到充分的测试，则可在少量用户中实施该变更，并在大规模实施该

17、项变更之前对小规模实施的结果进行评估以了解大规模实施该变更的合理性审查归类规划和批准协调评价记录主要活动主要活动 评价内容 变更是否达到预定的目的？用户对结果是否满意？ 是否有副作用？是否超过预估的成本和代价？ 评价结果 如果变更实施成功，变更请求（RFC）结束。通过实施后评审（PIR）来测试 如果变更不成功，流程将采用修正后的方法，从出错的地方重新执行 一般情况下，最好是备份变更，并在原始变更请求的基础上创建一项新的变更请求审查归类规划和批准协调评价与其它流程之间的关系与其它流程之间的关系Change ManagementChange ManagementConfigurationManag

18、ementProblemManagementReleaseManagementIncidentManagement（Plan）（Do）（Register）（Act/Analyse）变更记录影响度分析记录配置项关系配置项的影响变更整合到一个发布，新发布的试运行(Rollout)由变更管理进行控制纠正错误，解决问题，如果变更未很好控制会造成新的错误，新的问题（Check）PDCAPDCAPDCAPDCA？变更管理处理事件管理流程提出的变更请求变更的实施还是可能导致错误和事件可用性管理发起旨在提高服务可用性的变更。如果真的得到了提高，它也会进行验证。可用性管理通常也参与估计变更的潜在影响，反过来，变

19、更的影响又会对服务可用性产生 作用变更管理与IT服务持续性管理密切合作以保证IT持续性管理能知晓所有可能影响修复计划的变更并采取措施确保修复工作的顺利完成在能力计划的基础上，能力管理将有规律地以变更请求的形式提议增加或者变更，以提高现有能力的使用，并对其进行扩展与其它流程之间的关系与其它流程之间的关系Change ManagementChange Management可用性管理能力管理IT服务持续性管理 如果变更可能 带来较大的影 响或风险，则就必要性和时间需与用户讨论。变更管理需向服务级别管理提交服务计划可用性报告，列出对现有服务级别协议的改变服务级别管理关键成功因素和绩效指标关键成功因素和

20、绩效指标 关键成功因素 配置管理提供准确的配置信息 问题管理提供可靠的问题分析报告和合理的变更请求 发布管理与变更管理之间的良好协调 明确变更经理的权限和责任 组建合理有效的变更顾问委员会 关键绩效指标 绩效指标使变更管理流程在对现有服务级别影响最小的情况下，处理变更的有效性和高效程序 包括 每一类变更的数目 变更实施的速度 引发变更的事件的数目 与变更相关的备份数目 有资源和时间估计的变更数目问题：与实际工作结合问题：与实际工作结合 优点？ 不足？启示启示 ? 勿以善小而不为，勿以恶小而勿以善小而不为，勿以恶小而为之为之发布管理定义发布管理定义 定义 对经过测试后导入实际应用的新增或修改后的

21、配置项进行分发和宣传的管理流程 以前称为软件控制与分发，由变更管理流程控制 目标 计划和协调软硬件组件的发布 设计和实施有效的程序来分发和安装IT系统的变更 确保只有正确的、被授权的和经过测试的软硬件版本才能导入实际运作环境 结合变更管理，准确发布确切内容和首次发布计划 确认所有最终软件库中软件正本的拷贝是安全可靠的，并且在配置管理数据库中得到了更新Release Management发布管理范围发布管理范围 范围 负责对软件和硬件进行规划、设计、构建、配置和测试，以便为实际运行环境提供一系列的发布组件 受控组件 自行开发的应用程序 外购软件 工具软件工具软件 供应商提供的系统软件 硬件和软件

22、的规格说明硬件和软件的规格说明 装配指南和文档，包括用户手册装配指南和文档，包括用户手册 必须要执行发布管理的情形 重大或关键硬件的首次运行，特别是当业务系统对某个相关的软件变更具有较大依赖的情形 主要软件的首次运行，特别是新的应用程序与其协同软件同时发布的情形 将一组相关的变更打包成一个个适当规模的单元的情况DevelopmentTestingProduction注意注意ProductionTestingDevelopmentRelease Management发布管理范围（续）发布管理范围（续）Release PolicyRelease PlanningDevelop or Purchas

23、eBuild & ConfigureFunctional TestingAcceptance TestingRollout PlanningCommunication preparation & TrainningDistributionInstallationDSLChange ManagementConfiguration Management发布与发布单元发布与发布单元 发布发布：由一项或多项经过批准的变更所组成 发布类型 重大发布 新硬件和软件的大型试运行，通常是伴随着重大的功能增强 通常可以消除一些已知错误，包括临时性的应急措施和临时性修复 小型软件发布和硬件升级 对已知错误进行的一

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

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

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

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

28、件库中开始的整个软件生命周期 最终硬件库（Definitive Hardware Store） 定义：最终硬件库中包含了硬件的备件和库存 这些备用组件和配件得到与它们在实际运作环境中的对应组件相同级别的维护，可以用来替换或修复IT基础架构中相似的配置，其配置构成的详细信息应该被记录在配置管理数据库（CMDB）中。主要活动主要活动 发布政策制定和发布规划 发布设计、构建和配置 测试和发布验收 试运行规划 沟通、准备和培训 发布分发和安装设计开发环境受控测试环境生产环境发布管理发布政策发布规划设计开发或订购构建和配置发布适用性测试发布验收上线计划沟通和培训分发及安装配置管理数据库CMDB最终软件库

29、（DSL）政策和规划主要活动主要活动 制定发布政策 针对每一个系统，发布经理都应当制定一项发布政策来定义一项发布怎样以及何时得以配置 发布规划 重大发布应该提前对其发布识别或版本号进行规划，以便在恰当的时候可以考虑添加某项（些）变更 发布经理还需要规定在什么层次上配置项或以彼此独立地进行分发（发布单元） 在规划一项发布时需要考虑以下问题 协调发布内容 协商并确定发布日程安排、地点组织单元 制定沟通计划 现场考察 协商并确定角色和职责 获取详细报价单并与供应商谈判 制定撤销计划 制定质量计划 由管理部门和用户共同对发布验收进行规划设计和配置 测试和验收 沟通和培训 安装和分发政策和规划主要活动主

30、要活动 设计、构建和配置 为发布的设计、构建和配置开发标准的程序是一种明智和做法 一项发布一般是基于自行开发或从第三方供应商购进并构建的一套组件（配置项） 安装指示和配置发布的指示也应当被视为是发布的一部分，也应当被作为配置项处于变更管理和配置管理的控制之下。回滚计划（Back-out Plan） 针对整个发布的撤销计划定义了在发布出现问题的情况下恢复服务所需进行的活动 变更管理负责撤销计划的制定，而发布管理需要确保撤销计划符合实际的要求 特别是在实施一项组合了多项变更请求的包发布时，对不同的撤销计划符合实际的要求 一旦一项全发布或德尔塔发布出现了问题，则明智的做法是将该发布完全撤回到“前信任

31、状态”。如果某项发布不能被完全撤回到原来的状态，则需要采取应急措施来尽可能多地恢复服务设计和配置 测试和验收 沟通和培训 安装和分发政策和规划主要活动主要活动 发布测试 不满意的变更和发布的最常见的原因是缺乏足够的测试。在实施之前，发布应该由用户代表对其进行功能测试并由IT管理人员进行运营测试。 发布验收 在发布管理可以开始运行（Rollout）前，变更管理必须安排由用户进行正式的验收以及由开发人员签发开发结束的标记 对每一个步骤的正式验收必须由变更管理来进行 发布应该在一个受控测试环境中进行验收以便该项发布可以被恢复至一个可知的配置状态设计和配置 测试和验收 沟通和培训 安装和分发政策和规划

32、主要活动主要活动 试运行计划 日程安排和人力资源清单 新安装、停止、退出的配置项清单 每个地点可能的活动计划 与有关方面进行沟通 硬件、软件采购计划 购买、存储、识别和记录所有配置管理数据库中即将发布的配置项 与高层、管理、变更管理以及用户代表安排更新/评审会议 试运行实施的方式 全面试运行“大爆炸”的方法 分阶段试运行，该方式又具体包括以下几种方案： 功能递增：所有用户在同一时间获得新的功能 地点递增：首先对某些用户群进行试运行，然后再扩散至所有的用户 演进方式：功能分阶段扩展设计和配置 测试和验收 沟通和培训 安装和分发政策和规划主要活动主要活动 沟通、准备和培训 负责与客户沟通的人员（服

33、务台和客户关系管理）、运营人员以及客户组织的代表都应该清楚发布计划的内容以及该计划将如何影响日常活动 通过联合培训、合作和联合参与发布验收来实现 如果发布是分阶段进行的，则应该向用户告知计划的应细内容，并告诉什么时候可以期望新功能正式上线 针对服务级别协议（SLA）、运营级别协议（OLA），和支持合同（UC）所作的变更应该提前向所有相关人员进行传达设计和配置 测试和验收 沟通和培训 安装和分发政策和规划主要活动主要活动 安装和分发 发布管理为软件和硬件的采购、存储、运输、交付和移交监控整个物流流程。该流程由一些相应的程序、记录以及包装单据等附属文档来支持，从而可以为配置管理提供可靠的信息 硬件

34、和软件存储设施应该确保安全并且只有经过授权的人员才可以进入 最好使用自动工具来进行软件分发和安装，这样可以减少分发所需要的时间、提高发布的质量，减少需要的资源 安装之前，检查发布即将导入的环境是否满足一些条件，如：房间，电源，磁盘空间等 在安装后，配置管理数据库（CMDB）中的信息应立即进行更新以便可以检验任何的许可证协议设计和配置 测试和验收 沟通和培训 安装和分发关键成功因素与关键成功因素与KPIKPI 关键成功因素 与变更管理流程的良好协调 准确的配置管理数据 制定明确的发布政策和发布计划 制定完善的首次运行计划 与客户进行良好的沟通，对客户进行必要的培训 充分的发布测试和发布验收 关键绩效指标 在资源预算的限度内按计划构建和实施发布的数量 构建失败的次数 最终软件库（DSL）管理的安全性和准确性 所有进入最终软件库（DSL）中的软件都通过了质量检验 所有外购软件都符合有关的法律规定 准确地将发布的软硬件版本分发至所有远程地点 没有未经授权的版本替代以前的版本 发布构建中没有出现浪费的复制版本 计划的发布项目与实际的发布项目保持一致 发布管理所需的IT和人力资源得到良好的后续规划和安排后记后记谢谢