20151112 淡然

续上




4.6      服务级别管理4.6.1      设计目标

在满足监管指引要求的基础上，通过分析我行现状、同业经验，结合ITIL核心理念及ISO20000国际标准，建立闭环的管理流程、保证我行运维管理能力能得到持续的提升。详细的设计目标体现在如下几个方面：                         ITSS培训

•   建立统一的、满足某公司实际需求的服务级别管理流程；

•   需要建立反映信管部门主要职能的IT服务目录；

•   需要建立较为明确、科学的服务级别管理指标；

•   正式任命的服务级别流程经理；

•   定义较为详细、科学的操作级别协议；

•   定期对于服务级别的达成情况，进行回顾；

•   实现与服务绩效考核的关联。

4.6.2      服务级别管理描述

服务级别管理流程根据预先确定的标准服务参数来定义、协商、监控、报告、控制、测量重要的IT服务，并为科学的服务绩效评价机制提供依据。

•   服务目录

服务目录（Service Catalogue）定义了某公司所提供服务的全部种类以及服务目标，服务目录是表达业务部门期望的关键性文档，它是公开的，不论是服务提供者还是业务部门都能方便的查阅这些资料。服务目录会利用一些来自服务质量控制的指标和要求，这些服务质量指标需要进行定期回顾，及时做出相应调整以适应业务部门或者业务的具体需求。

•   服务级别协议（SLA）

在 服务级别管理 流程里，服务级别协议 是很重要的一个组成部分， 它是某公司与其业务部门之间的一种书面协议，规定了服务需要达成的主要目标和双方具体的责任，是有效的衡量考核工具。

在最终成文的 SLA 中，每一个细节都是经过协商、双方同意、并被记录在案作为 服务级别管理 中的一部分。 SLA 是得到某公司高层管理人员授权认可的。

•   操作级别协议（OLA）

操作级别协议 (OLA) 是用来支持 SLA 中的服务级别水平的实现。 OLA 是后台的协议，它定义的服务内容与业务部门不发生直接关系，但却是实现 SLA 所必不可少的。OLA是制定 SLA 的先决条件之一，它明确了某公司的角色和责任，也明确了服务供求双方的责任关系。

•   支持合同（UC）

支持合同是指IT团队与外部供应商之间签订的有关服务实施的供货合同，比如故障检测服务器、维护光纤通讯电缆等。这有一点像与外部供应商之间的 OLA ，在许多公司里， IT 服务是由内部的 IT 部门提供的，所以 OLA 可能只是一份内部协议，不具法律效力，但是 UC 则一定是和外部组织签订的合同，是正规的具备法律效力的。

4.6.3      管理目的

服务级别管理流程的用途是确定能够支持业务需要的IT服务级别需求，通过对服务级别的管理来确保实现承诺的服务级别。

服务级别管理流程的目标是在业务和成本平衡的前提下，维持和逐步提高IT服务质量。

•   定义、设计与管理层商谈制定服务级别并进行管理；

•   维护提高IT服务质量，与管理层的业务需求保持一致；

•   监控、衡量和汇报实际IT服务级别并制定服务改进计划;

•   基于科学的评价机制，考核IT服务相关工作的落实，并为人员绩效考核提供依据。

4.6.4      管理范围

下表对一些容易混淆的方面作了说明，用来表明服务级别管理的工作覆盖范围：

属于	不属于
建立和维护IT服务目录	IT服务规划                           ITSS认证
收集管理层SLA需求	提高服务的战略和服务质量保证和控制
协商和签署服务级别协议	成本核算和具体收费
制定内部支持人员、外部供应商保障协议
服务级别协议监视和报告
评估服务级别
为人员考核提供参考信息

4.6.5      执行的效果

服务级别与考核管理可以为某公司的业务部门和IT部门带来效益具体表现在以下六个方面：

清晰准确的文档来描述提供的服务，同时SLA可以减少低效服务的发生；

对所需服务和组件的清晰定义使得成本和资源管理长期可控；

改善IT服务的质量，确保业务特定的SLA能够满足服务性能的需要，IT服务的设计是用来满足服务级别需求；

日常对服务级别的监控以及必要时启动服务改善行动；

服务级别可以被测量，也就是说服务性能可以被管理和报告；

关联服务考核机制，提供人员考核的数据依据。

4.6.6      与其他管理模块的关系

•   服务台及事件管理

服务级别管理向服务台及事件管理提供服务级别协议中有关服务台与事件处理的协议，服务台向服务级别管理返回服务台工作情况信息，事件管理向服务级别管理返回事件的实际执行状况信息，供服务级别管理制定报告使用。

•   问题管理

问题管理：服务级别管理流程提供服务管理问题给问题管理流程，另一方面问题管理统计各个服务的问题频率，作为服务测量的输入

•   变更管理

SLA中定义了业务部门可以进行的变更，由服务级别管理提交RFC至变更管理流程执行，SLA中还定义了如何响应这些变更，如，何人跟踪变化、变更执行的时间、成本及报告方式等。

•   配置管理

配置管理负责维护CI组件和文档的信息数据库，其中包括SLA的维护。

•   外包管理

服务级别管理根据客户需求，制定外部供应商支持需求输出到采购管理；采购管理流程通过与外部供应商磋商，根据支持需求，制定外部供应商支持合同，返回服务级别管理。

•   容量管理

容量管理负责定义、监控和优化提供IT服务的性能与容量需求。服务级别管理依据与客户签订的或将签订的SLA，为容量管理提供未来容量需求信息。性能与容量为服务级别管理提供新的服务或升级的服务在性能上的影响，以及现有的服务性能和容量数据。

•   可用性管理

可用性管理负责定义、监控和优化服务的可用性。服务级别管理向可用性管理提供服务级别协议中有关可用性的要求，可用性管理向服务级别管理提供实际的可用性数据。

•   连续性管理

连续性管理关注当灾难发生时快速恢复IT服务，并监控恢复过程和手段。连续性管理为服务级别管理提供连续性计划，服务级别管理在制定SLA时，包含了连续性恢复手段和成本。服务级别管理将SLA中有关连续性部分提供给连续性管理，当灾难发生时连续性管理应保证满足SLA中的连续性要求。

4.6.7      本期项目改进重点

编号	现状	改进建议

4.7      容量管理4.7.1      设计目标

在满足监管指引要求的基础上，通过分析我行现状、同业经验，结合ITIL核心理念及ISO20000国际标准，建立闭环的管理流程、保证我行运维管理能力能得到持续的提升。详细的设计目标体现在如下几个方面：

•   建立容量管理流程，明确定义容量数据的收集、记录、分析和跟踪职责；

•   逐步实现对于关键系统的容量规划；

•   必须实现容量数据的线性分析；

•   实现容量类问题处理和流转机制；

•   正式任命的容量流程经理；

•   逐步启动容量监控指标建设，并引导监控系统落实

•   逐步启动容量数据库的建立与维护，以推动容量趋势分析。

4.7.2      容量管理描述

容量管理是在一定的成本下，控制和管理IT的容量，满足不断增长和变化的业务需求的IT运维管理流程。容量管理需要平衡成本与所需资源的矛盾、需求与供应间的矛盾 。

•   平衡成本与所需资源：需要保证购买的资源(如处理能力)以合理的成本满足业务需要，同时要能最有效率地利用这些资源;

•   平衡供应(Supply)与需求(Demand)：需要保证IT处理能力的供应能匹配现在和将来的业务需要，同时它可能还需要管理或影响业务对特定资源的需求。

4.7.3      管理目的

容量管理致力于为与服务和资源有关的所有容量和性能相关问题提供一个关注点(Focus)和管理点。容量管理的目的是所有IT领域的容量能够经济合理，能及时满足当前和未来的协定业务需求。

容量管理通过被动式的活动和主动式的活动来确保IT设备具有足够的容量来运行应用以满足可以预见到的业务需求。被动式的活动包括：

•   监视、测量、报告和审查服务和组件的当前容量；

•   响应所有容量方面的“阈值”事件，并发起纠错措施；

•   对特定容量问题做出响应，并协助采取措施，例如服务台将容量不足导致的故障提交给技术管理，后者使用容量管理技术解决问题。

容量管理主动式的活动包括：

•   采取必要的措施防患于未然，通过采取必要的行动在问题发生前预测容量问题，分析现有资源利用率趋势以及预测未来的资源需求；

•   识别、分析和管理IT服务和组件的预期变更，保证有可用的资源实施这些变更；

•   确保在违反SLA或发生容量问题之前，为容量升级进行了预算和计划且完成实施工作；

•   主动寻求成本合理情况下改进服务性能，调整和优化服务与组件的性能。

容量管理采取的主动和预测活动越成功，容量管理需要采取的被动活动就越少，组织的容量管理能力就越成熟。

4.7.4      管理范围

流程管理主要包括的活动有监测IT服务及支持组件的性能与吞吐量、通过调优实现资源的优化使用、理解现有资源需求及预测未来需求、与其他流程共同影响资源需求、制定容量计划。容量管理与许多其他运维管理流程存在关系，例如接收来自可用性管理的可用性需求与计划、来自连续性管理的连续性需求、来自问题管理的容量问题、来自变更管理的RFC等，容量管理输出容量计划、容量方案等到其他流程。

下表 说明了哪些工作属于容量管理流程的范围，哪些不属于容量管理流程。

[td]

属于	不属于
容量需求分析	容量需求提出。需求提出由业务部门、项目组提供，以及服务级别、可用性连续性管理流程提供。 容量需求实现。容量需求实现由变更管理、发布管理以及项目管理流程负责。
理解IT基础设施和资产需求	IT基础设施及资产信息收集。这些信息由配置管理实现。
容量/性能的管理	设备的管理。设备管理由资产管理、配置管理等实现。
容量/性能的数据分析	容量/性能的测量与数据收集。测量与数据收集由运维管理实现。
基于历史数据预测容量	新业务需求预测。新的业务需求由业务部门提供。
容量报告及容量规划	根因分析和容量规划实施。根因分析由问题流程负责，规划实施由变更、发布、项目管理流程负责。

4.7.5      执行的效果

容量管理可以为某公司的业务部门和IT部门带来的收益体现在以下四个方面：

•   提高应用系统的可用性

通过对业务、服务、组件容量的主动监控分析,加快解决容量不足引起的故障，主动预防性地排除容量相关的风险，以及预防业务高峰带来的冲击，提高应用稳定性和可用性。

•   支持承诺的服务级别达成

容量管理通过主动性容量需求预测，使服务级别所需的资源得到满足，从而提高正在运行系统的可用性和性能。

•   降低IT成本

通过合理的配置资源，提高资源的利用率，降低运维成本。有效的容量管理可对突发事件管理提供支持，降低支持、维护的费用。

•   提高IT预算的准确性

更准确的容量预测和计划为更准确的IT财务预算提供有效的支持。                             ITSS考试

4.7.6      与其他模块的关系

本部分介绍某公司容量管理流程与某公司服务管理其他流程之间的关系和流程接口。整体的关系如下所示：

•   服务级别管理

服务级别管理要求容量管理保障达成的新需求或变更需求的性能与容量目标。性能依赖于特定的定义在SLA中的工作负载。当出现容量或性能问题时，需要容量管理协助服务级别管理制定和检查OLA和外部合同。

容量管理向服务级别管理提供性能数据和交易量数据。

•   可用性管理

容量和性能问题可以导致系统不可使用，可用性要求也可以影响容量的设计，它们之间存在相互依存的关系，二者应该紧密结合。容量管理需要了解可用性技术手段，以便准确计划容量。容量管理与可用性管理常采用相同的工具，均需要采用通用的计划、监测和告警工具以及CMS等。

制定容量计划时，需要从可用性计划中提取容量相关的需求。

•   连续性管理

容量管理确定了灾难恢复系统的容量需求，为了达到预定的性能和交易水平所需的最小硬件和软件配置。容量计划应能够满足IT服务连续性的需求，RFC应针对灾难恢复方案评估影响。

连续性管理为容量管理提供业务连续性需求，灾难恢复所需的容量必须满足业务需要，匹配生产环境的现有容量。容量计划应能够满足IT服务连续性的需求，RFC应评估针对每一种恢复方式的影响。

•   配置管理

配置管理是容量管理的基础和前提，配置管理为容量管理提供准确和及时的配置项（CI）信息，容量数据库(CMIS)中存储有配置项的容量和性能数据。

•   发布与部署管理

发布管理为容量管理提供系统需求，在系统发布之前对系统进行容量评估，若没有足够的容量来支持上线计划中的资源需求，将推迟系统发布或修改发布方案。发布需求应该被提前规划和计划，所需容量应被纳入到容量计划中进行统一管理，尽量减少对非计划容量需求的容量响应。

容量管理协助确定上线发布策略，尤其通过网络进行发布时，容量管理提供性能与容量计划和容量专家来支持发布管理。

•   变更管理

容量管理提供变更对IT容量造成影响的信息，变更顾问委员会（CAB）在现有容量基础上评估变更所产生的影响，识别额外的容量需求。容量管理需要全面考虑容量变更所产生的累积效果。

容量管理的具体相关动作都需要通过变更管理流程付诸实施和控制风险，计划外的容量需求需形成变更请求（RFC），其它如计划内升级、调优、增加新系统等容量需求也要提交RFC。

变更管理发出工单，容量管理返回工作单状态等信息。

•   事件管理

事件管理将容量类事件信息输出给容量管理。

•   问题管理

容量管理响应问题管理流程提交的容量问题，组织各方技术力量解决容量问题。

4.7.7      未来本流程重点改进点：

编号	流程名	现状	应对条款	改进建议	优先级
CAP1	能力管理	需要了解设备和人力资源在当前和未来的容量状况，以便主动适应业务的发展需要。	能力管理 ISO20000 6.5 确保服务提供方在所有时间内具有足够的能力来满足当前及将来商定的顾客的业务要求	容量管理流程规划（服务容量指标、设备容量、人力资源容量、容量计划、容量监控、绩效指标和报表）。	低
CAP2	能力管理	随着业务的发展，业务系统的建设及原有系统压力进一步增加，相应的人力资源配置需要建立一个与之相适应的持续发展规划。	能力管理 ISO20000 6.5 确保服务提供方在所有时间内具有足够的能力来满足当前及将来商定的顾客的业务要求	持续改进组织容量发展规划（业务需求与容量、运营模式设计、人力资源规划）。	低

待续http://www.ITILxf.com/thread-53172-1-1.html

本帖关键字：ITSS

20151112 淡然

续上




4.6      服务级别管理4.6.1      设计目标

在满足监管指引要求的基础上，通过分析我行现状、同业经验，结合ITIL核心理念及ISO20000国际标准，建立闭环的管理流程、保证我行运维管理能力能得到持续的提升。详细的设计目标体现在如下几个方面：                         ITSS培训

•   建立统一的、满足某公司实际需求的服务级别管理流程；

•   需要建立反映信管部门主要职能的IT服务目录；

•   需要建立较为明确、科学的服务级别管理指标；

•   正式任命的服务级别流程经理；

•   定义较为详细、科学的操作级别协议；

•   定期对于服务级别的达成情况，进行回顾；

•   实现与服务绩效考核的关联。

4.6.2      服务级别管理描述

服务级别管理流程根据预先确定的标准服务参数来定义、协商、监控、报告、控制、测量重要的IT服务，并为科学的服务绩效评价机制提供依据。

•   服务目录

服务目录（Service Catalogue）定义了某公司所提供服务的全部种类以及服务目标，服务目录是表达业务部门期望的关键性文档，它是公开的，不论是服务提供者还是业务部门都能方便的查阅这些资料。服务目录会利用一些来自服务质量控制的指标和要求，这些服务质量指标需要进行定期回顾，及时做出相应调整以适应业务部门或者业务的具体需求。

•   服务级别协议（SLA）

在 服务级别管理 流程里，服务级别协议 是很重要的一个组成部分， 它是某公司与其业务部门之间的一种书面协议，规定了服务需要达成的主要目标和双方具体的责任，是有效的衡量考核工具。

在最终成文的 SLA 中，每一个细节都是经过协商、双方同意、并被记录在案作为 服务级别管理 中的一部分。 SLA 是得到某公司高层管理人员授权认可的。

•   操作级别协议（OLA）

操作级别协议 (OLA) 是用来支持 SLA 中的服务级别水平的实现。 OLA 是后台的协议，它定义的服务内容与业务部门不发生直接关系，但却是实现 SLA 所必不可少的。OLA是制定 SLA 的先决条件之一，它明确了某公司的角色和责任，也明确了服务供求双方的责任关系。

•   支持合同（UC）

支持合同是指IT团队与外部供应商之间签订的有关服务实施的供货合同，比如故障检测服务器、维护光纤通讯电缆等。这有一点像与外部供应商之间的 OLA ，在许多公司里， IT 服务是由内部的 IT 部门提供的，所以 OLA 可能只是一份内部协议，不具法律效力，但是 UC 则一定是和外部组织签订的合同，是正规的具备法律效力的。

4.6.3      管理目的

服务级别管理流程的用途是确定能够支持业务需要的IT服务级别需求，通过对服务级别的管理来确保实现承诺的服务级别。

服务级别管理流程的目标是在业务和成本平衡的前提下，维持和逐步提高IT服务质量。

•   定义、设计与管理层商谈制定服务级别并进行管理；

•   维护提高IT服务质量，与管理层的业务需求保持一致；

•   监控、衡量和汇报实际IT服务级别并制定服务改进计划;

•   基于科学的评价机制，考核IT服务相关工作的落实，并为人员绩效考核提供依据。

4.6.4      管理范围

下表对一些容易混淆的方面作了说明，用来表明服务级别管理的工作覆盖范围：

属于	不属于
建立和维护IT服务目录	IT服务规划                           ITSS认证
收集管理层SLA需求	提高服务的战略和服务质量保证和控制
协商和签署服务级别协议	成本核算和具体收费
制定内部支持人员、外部供应商保障协议
服务级别协议监视和报告
评估服务级别
为人员考核提供参考信息

4.6.5      执行的效果

服务级别与考核管理可以为某公司的业务部门和IT部门带来效益具体表现在以下六个方面：

清晰准确的文档来描述提供的服务，同时SLA可以减少低效服务的发生；

对所需服务和组件的清晰定义使得成本和资源管理长期可控；

改善IT服务的质量，确保业务特定的SLA能够满足服务性能的需要，IT服务的设计是用来满足服务级别需求；

日常对服务级别的监控以及必要时启动服务改善行动；

服务级别可以被测量，也就是说服务性能可以被管理和报告；

关联服务考核机制，提供人员考核的数据依据。

4.6.6      与其他管理模块的关系

•   服务台及事件管理

服务级别管理向服务台及事件管理提供服务级别协议中有关服务台与事件处理的协议，服务台向服务级别管理返回服务台工作情况信息，事件管理向服务级别管理返回事件的实际执行状况信息，供服务级别管理制定报告使用。

•   问题管理

问题管理：服务级别管理流程提供服务管理问题给问题管理流程，另一方面问题管理统计各个服务的问题频率，作为服务测量的输入

•   变更管理

SLA中定义了业务部门可以进行的变更，由服务级别管理提交RFC至变更管理流程执行，SLA中还定义了如何响应这些变更，如，何人跟踪变化、变更执行的时间、成本及报告方式等。

•   配置管理

配置管理负责维护CI组件和文档的信息数据库，其中包括SLA的维护。

•   外包管理

服务级别管理根据客户需求，制定外部供应商支持需求输出到采购管理；采购管理流程通过与外部供应商磋商，根据支持需求，制定外部供应商支持合同，返回服务级别管理。

•   容量管理

容量管理负责定义、监控和优化提供IT服务的性能与容量需求。服务级别管理依据与客户签订的或将签订的SLA，为容量管理提供未来容量需求信息。性能与容量为服务级别管理提供新的服务或升级的服务在性能上的影响，以及现有的服务性能和容量数据。

•   可用性管理

可用性管理负责定义、监控和优化服务的可用性。服务级别管理向可用性管理提供服务级别协议中有关可用性的要求，可用性管理向服务级别管理提供实际的可用性数据。

•   连续性管理

连续性管理关注当灾难发生时快速恢复IT服务，并监控恢复过程和手段。连续性管理为服务级别管理提供连续性计划，服务级别管理在制定SLA时，包含了连续性恢复手段和成本。服务级别管理将SLA中有关连续性部分提供给连续性管理，当灾难发生时连续性管理应保证满足SLA中的连续性要求。

4.6.7      本期项目改进重点

编号	现状	改进建议

4.7      容量管理4.7.1      设计目标

在满足监管指引要求的基础上，通过分析我行现状、同业经验，结合ITIL核心理念及ISO20000国际标准，建立闭环的管理流程、保证我行运维管理能力能得到持续的提升。详细的设计目标体现在如下几个方面：

•   建立容量管理流程，明确定义容量数据的收集、记录、分析和跟踪职责；

•   逐步实现对于关键系统的容量规划；

•   必须实现容量数据的线性分析；

•   实现容量类问题处理和流转机制；

•   正式任命的容量流程经理；

•   逐步启动容量监控指标建设，并引导监控系统落实

•   逐步启动容量数据库的建立与维护，以推动容量趋势分析。

4.7.2      容量管理描述

容量管理是在一定的成本下，控制和管理IT的容量，满足不断增长和变化的业务需求的IT运维管理流程。容量管理需要平衡成本与所需资源的矛盾、需求与供应间的矛盾 。

•   平衡成本与所需资源：需要保证购买的资源(如处理能力)以合理的成本满足业务需要，同时要能最有效率地利用这些资源;

•   平衡供应(Supply)与需求(Demand)：需要保证IT处理能力的供应能匹配现在和将来的业务需要，同时它可能还需要管理或影响业务对特定资源的需求。

4.7.3      管理目的

容量管理致力于为与服务和资源有关的所有容量和性能相关问题提供一个关注点(Focus)和管理点。容量管理的目的是所有IT领域的容量能够经济合理，能及时满足当前和未来的协定业务需求。

容量管理通过被动式的活动和主动式的活动来确保IT设备具有足够的容量来运行应用以满足可以预见到的业务需求。被动式的活动包括：

•   监视、测量、报告和审查服务和组件的当前容量；

•   响应所有容量方面的“阈值”事件，并发起纠错措施；

•   对特定容量问题做出响应，并协助采取措施，例如服务台将容量不足导致的故障提交给技术管理，后者使用容量管理技术解决问题。

容量管理主动式的活动包括：

•   采取必要的措施防患于未然，通过采取必要的行动在问题发生前预测容量问题，分析现有资源利用率趋势以及预测未来的资源需求；

•   识别、分析和管理IT服务和组件的预期变更，保证有可用的资源实施这些变更；

•   确保在违反SLA或发生容量问题之前，为容量升级进行了预算和计划且完成实施工作；

•   主动寻求成本合理情况下改进服务性能，调整和优化服务与组件的性能。

容量管理采取的主动和预测活动越成功，容量管理需要采取的被动活动就越少，组织的容量管理能力就越成熟。

4.7.4      管理范围

流程管理主要包括的活动有监测IT服务及支持组件的性能与吞吐量、通过调优实现资源的优化使用、理解现有资源需求及预测未来需求、与其他流程共同影响资源需求、制定容量计划。容量管理与许多其他运维管理流程存在关系，例如接收来自可用性管理的可用性需求与计划、来自连续性管理的连续性需求、来自问题管理的容量问题、来自变更管理的RFC等，容量管理输出容量计划、容量方案等到其他流程。

下表 说明了哪些工作属于容量管理流程的范围，哪些不属于容量管理流程。

[td]

属于	不属于
容量需求分析	容量需求提出。需求提出由业务部门、项目组提供，以及服务级别、可用性连续性管理流程提供。 容量需求实现。容量需求实现由变更管理、发布管理以及项目管理流程负责。
理解IT基础设施和资产需求	IT基础设施及资产信息收集。这些信息由配置管理实现。
容量/性能的管理	设备的管理。设备管理由资产管理、配置管理等实现。
容量/性能的数据分析	容量/性能的测量与数据收集。测量与数据收集由运维管理实现。
基于历史数据预测容量	新业务需求预测。新的业务需求由业务部门提供。
容量报告及容量规划	根因分析和容量规划实施。根因分析由问题流程负责，规划实施由变更、发布、项目管理流程负责。

4.7.5      执行的效果

容量管理可以为某公司的业务部门和IT部门带来的收益体现在以下四个方面：

•   提高应用系统的可用性

通过对业务、服务、组件容量的主动监控分析,加快解决容量不足引起的故障，主动预防性地排除容量相关的风险，以及预防业务高峰带来的冲击，提高应用稳定性和可用性。

•   支持承诺的服务级别达成

容量管理通过主动性容量需求预测，使服务级别所需的资源得到满足，从而提高正在运行系统的可用性和性能。

•   降低IT成本

通过合理的配置资源，提高资源的利用率，降低运维成本。有效的容量管理可对突发事件管理提供支持，降低支持、维护的费用。

•   提高IT预算的准确性

更准确的容量预测和计划为更准确的IT财务预算提供有效的支持。                             ITSS考试

4.7.6      与其他模块的关系

本部分介绍某公司容量管理流程与某公司服务管理其他流程之间的关系和流程接口。整体的关系如下所示：

•   服务级别管理

服务级别管理要求容量管理保障达成的新需求或变更需求的性能与容量目标。性能依赖于特定的定义在SLA中的工作负载。当出现容量或性能问题时，需要容量管理协助服务级别管理制定和检查OLA和外部合同。

容量管理向服务级别管理提供性能数据和交易量数据。

•   可用性管理

容量和性能问题可以导致系统不可使用，可用性要求也可以影响容量的设计，它们之间存在相互依存的关系，二者应该紧密结合。容量管理需要了解可用性技术手段，以便准确计划容量。容量管理与可用性管理常采用相同的工具，均需要采用通用的计划、监测和告警工具以及CMS等。

制定容量计划时，需要从可用性计划中提取容量相关的需求。

•   连续性管理

容量管理确定了灾难恢复系统的容量需求，为了达到预定的性能和交易水平所需的最小硬件和软件配置。容量计划应能够满足IT服务连续性的需求，RFC应针对灾难恢复方案评估影响。

连续性管理为容量管理提供业务连续性需求，灾难恢复所需的容量必须满足业务需要，匹配生产环境的现有容量。容量计划应能够满足IT服务连续性的需求，RFC应评估针对每一种恢复方式的影响。

•   配置管理

配置管理是容量管理的基础和前提，配置管理为容量管理提供准确和及时的配置项（CI）信息，容量数据库(CMIS)中存储有配置项的容量和性能数据。

•   发布与部署管理

发布管理为容量管理提供系统需求，在系统发布之前对系统进行容量评估，若没有足够的容量来支持上线计划中的资源需求，将推迟系统发布或修改发布方案。发布需求应该被提前规划和计划，所需容量应被纳入到容量计划中进行统一管理，尽量减少对非计划容量需求的容量响应。

容量管理协助确定上线发布策略，尤其通过网络进行发布时，容量管理提供性能与容量计划和容量专家来支持发布管理。

•   变更管理

容量管理提供变更对IT容量造成影响的信息，变更顾问委员会（CAB）在现有容量基础上评估变更所产生的影响，识别额外的容量需求。容量管理需要全面考虑容量变更所产生的累积效果。

容量管理的具体相关动作都需要通过变更管理流程付诸实施和控制风险，计划外的容量需求需形成变更请求（RFC），其它如计划内升级、调优、增加新系统等容量需求也要提交RFC。

变更管理发出工单，容量管理返回工作单状态等信息。

•   事件管理

事件管理将容量类事件信息输出给容量管理。

•   问题管理

容量管理响应问题管理流程提交的容量问题，组织各方技术力量解决容量问题。

4.7.7      未来本流程重点改进点：

编号	流程名	现状	应对条款	改进建议	优先级
CAP1	能力管理	需要了解设备和人力资源在当前和未来的容量状况，以便主动适应业务的发展需要。	能力管理 ISO20000 6.5 确保服务提供方在所有时间内具有足够的能力来满足当前及将来商定的顾客的业务要求	容量管理流程规划（服务容量指标、设备容量、人力资源容量、容量计划、容量监控、绩效指标和报表）。	低
CAP2	能力管理	随着业务的发展，业务系统的建设及原有系统压力进一步增加，相应的人力资源配置需要建立一个与之相适应的持续发展规划。	能力管理 ISO20000 6.5 确保服务提供方在所有时间内具有足够的能力来满足当前及将来商定的顾客的业务要求	持续改进组织容量发展规划（业务需求与容量、运营模式设计、人力资源规划）。	低

待续http://www.ITILxf.com/thread-53172-1-1.html

本帖关键字：ITSS