yITIL服务设计之容量管理

yITIL服务设计之容量

管理

Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998

容量管理

容量管理贯穿于服务生命周期的始终。容量管理的关键成功因素就是在服务设计阶段已经考虑到它，因此，容量管理的内容包含在本书籍中。容量管理首先在服务战略阶段得到支持，在服务战略阶段，决策和业务要求与客户结果的分析影响着业务活动模型（PBA）的开发、服务的水平(LOS)和服务水平包(SLPs)。这提供了需要调整容量以满足需求的预测性的指标。

意图、目的与目标

“容量管理的目的就是保证在IT的所有领域有成本合理的IT容量，并且及时地满足现在及将来的业务需求。”

容量管理的意图就是对所有的容量及服务和资源相关的性能问题进行关注和管理。

容量管理的目标是：

 生成和维护一个合适的和最新的容量计划，反映当前和将来的业务

需要

 在业务和IT的其他领域提供容量和性能相关问题的建议和指导  通过管理服务和资源的容量及性能，保证服务性能满足或超过所有

既定的性能指标

 为性能和容量相关的故障及问题的诊断和解决提供帮助

 评估容量计划的所有变更所带来的影响，评估所有服务和资源的性

能和容量

 保证提高服务性能的主动措施在成本合理的情况下得到实施

范围

容量管理应该关注所有的IT性能和容量问题。技术管理职能如网络支持、服务器支持、运营管理等实施大部分的日常管理任务，可以为容量管理提供性能信息。容量管理应该包含包括硬件和软件在内的所有技术领域，适合于所有的技术组件和环境。容量管理也要考虑空间规划、环境系统容量和人力资源的某些方面。但是只有人力资源的缺失能导致SLA或OLA目标的违背、端到端性能的延迟、满足将来任务和计划的无能（例如，因为操作人员的缺失以致不能装载磁带，从而导致夜间数据备份不能及时完成）。

通常情况下，容量管理是一种线性管理责任，虽然服务台员工使用同样的容量管理技术。人力资源安排、员工水平、技能水平、能力水平都应该被包含在容量管理的范围中。容量管理的驱动力应该是组织的业务要求和规划能够提供与SLAs（OLAs）一致的服务水平所需要的资源。容量管理需要了解整体的IT和业务环境，包括：

 通过业务活动模型（PBA）来了解当前的业务运营和要求  通过服务组合来了解将来的业务规划和要求

 通过SLAs和标准运营流程来了解服务目标和当前的IT服务运营状

况

 IT技术、容量、性能的所有方面，包括基础设施、数据、环境、应

用程序等

了解所有这些可以使容量管理能够保证服务的当前和将来的容量和性能的所有方面可以成本合理有效地提供。

容量管理也需要了解新服务传递的可能。需要了解新技术，如果合适的话，应客户的要求改革和传递这些服务。容量管理需要重新确认技术变更的比率可能增加并且新技术可以被安全使用以保证IT服务在改变业务期望时仍然让用户满意。需要在服务战略和服务组合间建立一种直接的联系以保证在将来的服务规划中把新兴的技术考虑进来。

容量管理应该包括：

 通过性能、效用、IT服务的生产能力、基础设施、环境、数据、应

用程序组件、正常产出、服务报告、组件容量和性能等监控业务活动模型和服务水平计划

 进行调优以便现有的IT资源达到最有效的使用

 了解用户对IT资源所达成的当前和将来的需求和将来的生产预期  可能与财务管理一起影响需求管理

 生成一个容量计划可以使服务提供商提供符合SLAs所规定质量的

服务并且能够有足够的时间安排来满足将来服务组合和SLRs所规定的服务水平

 为服务或组件相关的任何故障和问题的确认和解决提供辅助作用  在成本合理和满足业务需求的情况下对服务或组件的性能进行主动

性地改进

管理巨大的分布式IT基础设施的容量是一件复杂的和高要求的任务，尤其是IT容量和财务投资一直增加的情况下。所以对增长进行规划显得更有意义。

因为在分布式环境下单一组件的更新成本通常情况下会少于在集成式主机环境下的组件更新成本，所以经常有许多的组件需要更新。当需要购买很多组件时，单个组件的成本由于规模效应而减少。容量管理可以用于服务组合和采购过程以保证在与供应商谈判中达成最好的交易。

容量管理提供单个组件当前的和计划的资源效用的必要信息可以是组织有把握地做出决定：

 哪个组件需要更新（如：更大内存、更快的存储设备、更快的处理

器、更多的带宽）

 什么时候进行更新----理想状态下不能过早，否则导致超出容量的过

多支出；也不能太晚，否则导致不能有效利用新技术、瓶颈、不连续性能、最终地，客户不满意和失去生意机会

 更新的成本是多少----在预算的生命周期中把容量管理的预期因素和

计划因素考虑进来以保证计划性投资。

如果没有容量管理的信息输入，许多其他管理过程的效率会大大降低。例如：

 变更管理在可用性的容量方面能够评估任何变更的效果吗  实施新服务时，服务级别管理能保证新服务的SLRs达到了吗现存

服务的SLAs将不会受到影响

 问题管理能够诊断由低劣性能所导致的故障的潜在原因吗  IT服务持续性管理能够准确确定关键业务流程的容量需求吗

容量管理是一个前瞻性的过程，当进行实施时，可以在业务事件和影响发生前预测到它们。好的容量管理保证服务和组件的设计与性能不会出现惊险的情况。

在组织中，容量管理和服务战略与规划流程有密切的双向的联系。基本方面上，组织的长期战略包含在业务规划的更新中。服务战略反映业务规划，业务规划来自于组织对外部因素如竞争性的市场环境、经济前景、法律法规和内部的人力、供应能力等容量的理解。通常会开发一个短期的战术计划或业务变更来实现短期或中期的必要的变更从而可以进行全局的业务规划和服务战略。容量管理也需要了解短期、中期和长期的业务规划以便提供最新的理念、趋势及硬件软件供应商所开发技术的信息。

组织业务规划驱动特殊的IT服务战略，容量管理需要熟悉服务战略的内容，并为服务战略输入重大的和不断的信息。合适的时间合适的容量，这是很关键的。服务战略可以为容量管理在识别新技术、硬件、软件的获得和实施的时间方面提供帮助。

业务价值

容量管理负责保证IT资源按计划的方式来提供连续的服务水平，其能够与当前和将来的业务需求相符合，这些需求在SLAs和OLAs中被一致同意和文档化了。容量管理结合业务规划，提供了容量规划来指导支撑业务规划所需的的IT资源和资金以及支出费用的成本调整。

策略、原则与基本概念

容量管理保证IT服务和系统的容量和性能以最节约成本和时间的方式符合业务的既定需求。容量管理本质上是一种平衡：

 成本和所需资源的平衡：保证依据业务需要所购买的容量是成本合

理的，并对这些资源进行最有效的使用。

 供求平衡：保证IT处理能力的有用性供应与当前和将来的业务需

求相符合。为一种特定的资源管理或改变需求也是必要的。

容量管理过程和规划必须融合于服务生命周期的所有阶段，从服务战略、服务设计、服务转换、服务运营到服务改进。从战略的角度来看，服务组合包含所有的IT资源和功能。服务导向架构的出现、虚拟化、IT服务条款（provision）中的价值网络使用在容量管理中都是关键的因素。在初始的设计阶段就应该把恰当的容量和性能带到服务和组件中来。这样不仅可以保证新的或变更的服务的性能符合期望的目标，还可以保证所有现存的服务能够继续符合它们的所有目标。这是稳定服务条款的根本。

整体的容量管理过程以持续地成本合理地方式使IT资源和能力符合不断变更的业务需求。这就需要对当前的资源进行调优和优化并对将来的资源规划进行有效的估计，如图例所示。

容量管理是一种极其技术、负责、高要求的过程，为了达成必要的结果，它需要三个3个支撑的小过程。

容量管理的关键活动之一就是生成一个规划，把资源利用和服务性能的当前水平进行文档化，并在慎重考虑服务战略和规划后，预测将来能够支撑业务

活动的IT服务所需要的资源需求。这个计划应该清楚地显示任何所做出的假定。它还要包含任何量化的资源、成本、收益、影响等方面的建议。

需要在预定的时间段内生成和维护容量规划。它本质上是一个投资规划，所以需要每年公布一次，并且与业务或预算生命周期一致，还要在将来预算的协商前完成。在服务规划中，考虑到变化的情况，每季度更新一次规划是必需的，可以增加预测的准确度，还可以提出或提炼出一些建议。这需要额外的活动，但是如果它被定期地更新，容量规划会变得更加准确并能反映变化的业务需求。

容量规划的内容参见附录 J。

业务容量管理把业务需求和规划转变为对服务和IT基础设施的需求，保证IT服务将来的业务需求得到及时地量化、设计、规划和实施。这可以通过对各种服务所使用的当前资源利用情况的现存数据来预报、建模或者预测将来的需求来完成。这些将来的需求来自于服务战略和服务组合，如新流程和服务需求、变更、改进和现存服务的增长。

服务容量管理关注于端到端性能、现实状况的IT服务使用和工作负载的容量的管理、控制和预测。它可以保证服务目标中符合SLAs和SLRs的所有服务的性能得到监控和测量，并可以记录、分析和报告所收集的数据。如有必要，可以实行主动的措施来保证所有服务的性能符合既定的业务目标。这通常是由具有使用端到端服务传递技术的所有领域的知识的员工来执行的，还经常需要向组件容量管理的专家寻求建议。如果可能，应该把自动化的阈值控制技术应用于运营服务，来保证服务目标被违背或威胁时能够及时地得到识别，并使减少或避免潜在影响的成本合理的措施得到实现。

组件容量管理关注于对单个IT技术组件的性能、使用和容量进行管理、控制和预测。这保证拥有限定的资源的IT基础设施内的所有组件得到监控和测量，并可以记录、分析和报告所收集的数据。同样地，如果可能，可以使用自动化的阈值控制技术应用于所有组件，来保证组件使用或性能的服务目标被违背或威胁时能够及时地得到识别，并使减少或避免潜在影响的成本合理的措施得到实现。

这三个子管理过程有许多相似的活动，但是每一个有其不同的关注点。业务容量管理关注于当前和将来的业务需求，服务容量管理关注于支撑业务的现存服务的传递，而组件容量管理关注于支持IT条款的IT基础措施。每个子管理过程在容量管理中所扮演的角色如图例所示。

容量管理所使用的工具应该符合组织管理架构并且与IT系统和自动化处理的其他管理工具进行集成。服务运营中的监控和控制活动将会为容量管理的支持和分析工具提供良好的基础。

活动、方法与技术

容量管理的一些活动是被动的，还有一些是主动的，这些主动的活动包括：

 在性能问题发生前采取必要的措施解决它

 生成当前组件使用情况的趋势分析，估计将来的需求，为计划的更

新和增强使用趋势分析和阈值控制技术

 建模和趋势分析IT服务中的潜在变化，识别IT基础设施和应用中

的服务和组件需要作出的改动，从而保证适当的资源处于可用状态。

 在违背As和服务目标或性能问题出现之前，保证所有的变更被预

算、计划和实施

 在成本合理的情况下主动寻找改进服务性能的机会  调优和优化服务和组件的性能 被动的活动包括：

 监控、测量、报告、回顾服务和组件的当前性能  响应所有容量相关的阈值事件并采取正确的行动

 对特殊的性能问题做出反应和协助。服务台可能把低劣性能故障归

结于技术原因，这就需要使用容量管理技术来解决它们。

关键信息：容量管理的主动活动越成功，需要的被动活动越少。

业务容量管理的主要目标是保证IT服务的将来业务需求（客户结果）能够被考虑和理解，同时保证在合理的时间跨度内支撑新服务或变更的服务的充足IT容量被规划和实施。图例显示了业务活动模型是如何影响业务容量管理的和服务是如何使用的。

容量管理必须随容量需求的改变而改变。新服务或者变更的服务被要求来支撑变更的业务。现存的服务需要修改以提供额外的功能。陈旧的服务被淘汰，从而释放出一些空闲容量。结果是使满足客户SLRs和SLAs的能力也会受到影响。容量管理的责任就是预测变更所需要的容量和管理需求。

新需求可能从许多不同的来源（sources）和由于许多不同的原因引起容量管理的注意，但是供应需求的最主要的来源应该来自需求管理的业务活动模型和为服务组合所生成的服务级别包。例如升级以便利用新技术的建议，或解决性能问题的一个调优活动的实施。图例显示了需求管理的循环过程。

在所有的战略、规划和设计活动中尽可能早的把容量管理包含进来，例如：

 协助和支持服务战略的开发  参与IT战略和政策的回顾与改进  参与技术架构的回顾与改进

关键信息：容量管理应该优先被客户接纳，而不是最后的选择。 如果在这些过程中容量管理能早些参与进来，IT容量的规划和设计就会与业务需求紧密地结合，并能保证完成和维护服务目标。

协助同意服务级别要求

容量管理应该协助服务级别管理（SLM）依据服务/系统响应时间、期望生产能力、使用模式和用户数量来理解客户容量和性能的需求。容量管理应该提供一定情境下的可能解决方案以便在谈判过程中有所帮助。例如，如果用户数量少于2000，则可以保证响应时间低于2秒；如果多于2000用户的连接数，则应启用额外的网络带宽来保证所要求的响应时间。或者保证降低响应时间是可以被接受的。建模、趋势分析或者应用定型技术经常被用于此来保证预测能够准确地反映现实状况。

设计、获得或修改服务配置

容量管理应该参与到新服务或变更服务的设计中来，并且为硬件和软件的采购提供建议，这种情况下，性能和（或）容量是重要的因素。在一些例子中容量管理其作为变更咨询委员会的一员是通过变更管理来达到新需求的实施的。为了平衡成本与能力，容量管理获得可供选择的解决方案的成本并建议最合适的成本合理的建议。

核实服务等级协议（SLA）

服务等级协议应该包括期待服务能力和性能要求的详细情况。容量管理建议服务级别管理（SLM）监控可达成的目标和服务设计基于其上。容量管理应该充满信心，即服务设计符合SLRs，并且可以提供通过建模、趋势分析和定型技术获得未来增长的能力。

支持服务等级协议谈判

使用预测技术的结果可以验证服务性能。这可能需要服务等级管理给予这些结果重新谈判服务级别协议。容量管理通过建议潜在的解决方案和相关的成本信息为SLM提供支持，重新谈判则显得是必要的。一旦要求可以达到，服务级别管理的职责就是同意服务级别并签署服务级别协议。

控制和实施

所有对服务和资源的容量的变更必须遵循所有的IT流程，如变更、发布、配置和项目管理流程以保证对所有变更的控制和协调是适当的，以及保证任何新的或改变的组件在他们的生命周期中被记录和跟踪。

服务容量管理的主要目标是识别和理解IT服务、资源的使用、工作模式、高峰与低谷，并保证服务达到SLA目标，例如保证IT服务表现得如所期望的

那样。服务容量管理主要关注于管理包含在既定SLAs或SLRs中的目标所决定的服务性能。

服务容量管理保证服务符合既定的服务目标。可以对被监控的服务所提供的数据进行趋势分析，从而在趋势中建立正常的服务等级。通过对这些等级进行定期监控和对比，可以定义、识别和报告异常情况。这样，容量管理可以显示任何服务的服务级别管理的违背或丧失。

存在这样的情况，即涉及容量管理的故障和问题来自于其他流程，或者识别到某项服务可能不能符合SLA目标。在某些情况中，潜在失败的原因并不能由组件容量管理决定。例如，分析失败的原因，可能会发现是因为容量不够或者没有单个组件是超额利用的。然而，即使程序的设计或编码是效率低的，仍需要管理服务性能，也需要管理单个硬件或软件资源。服务容量管理应该监控服务负载和事务处理情况来保证它们仍处于既定的限制和阈值下。

成功的服务容量管理的关键是预测问题，如果可能，可以通过监控性能上的变更和监控变更所带来的影响。这样，其实它是另一个子流程，是主动的、预测性的，甚至是优先的，而不是被动的流程。然而，它需要对特殊的性能问题做出被动地反应，这种情况已经存在多次了。对正在使用的每个服务的性能要求的知识和理解、对应用服务变更的效果的评估、所采取的措施，这些来保证达到所需服务性能的要求。

组件容量管理的主要目标是识别和理解性能、容量及支撑IT服务的技术的单个组件的使用，包括基础架构、环境、数据和应用程序。这可以保证当前硬件和软件资源得到最佳使用从而达到和维持既定的服务等级。IT基础架构下的

所有的硬件组件和许多的软件组件都有限定的容量，达到或超过这一容量，可能引发性能问题。

组件容量管理关注于处理器、内存、磁盘、网络带宽、网络连接等组件。所以需要持续不断地收集资源利用的信息。需要在单个硬件和软件的组件上安装监控器，然后对其进行配置以便收集必要的数据，这些数据需要在一段时间内进行累积和存储。这项活动通常在服务运营部分通过监控和控制得到实施。对组件容量管理进行实时反馈应该应用于这一子流程中。

同服务容量管理一样，成功的组件容量管理的关键也是预测问题，如果

可能，也需要以主动的和预测性的方式进行。然而，组件容量管理需要对特定的问题做出被动地响应，如容量不够或者组件的无效率使用所引起的问题。这种情况也是存在的。来自于对正在运行的服务的资源使用的知识和理解，对服务使用的变更效果的估计，对硬件和软件更新的预算和规划。可供选择的是，对现存资源与服务进行平衡可以达到当前资源的最有效率的利用。

本部分所描述的活动对支持容量管理的子流程是必要的，这些活动可以以被动的或主动的甚至优先的方式进行。

各子流程间最大的不同是被监控和收集的数据及对数据分析的视角。例如在基础架构中单个组件的利用水平，如处理器、磁盘和网络连接，是与组件容量管理相关的，事务处理产出比率和响应时间是和服务容量管理相关的。对于业务容量管理，对在线服务来说，事务处理产出比率需要转化为业务量，例如，以销售发票或订单的形式。容量管理最大的挑战是理解业务需求和业务负载之间的联系，并能转换为对服务和资源的负载和利用的影响和效果，所以可以在每一层级上设置合适的阈值。

调谐（tuning）和优化活动

应该重复地进行一系列的活动并形成一个自然的循环，如图例所示。 这些活动提供了基本的历史性的信息和触发因素，对容量管理的所有其他活动和流程是必要的。应该建立对所有组件和每个服务的监控。如果可能，这些数据应该使用专家系统来对比利用水平和阈值。分析的结果应该以报告的形式表现出来，并包含合适的建议。一些控制机制的表现形式应该对这些建议做出响应。如平衡服务、平衡负载、变更并发数量、增加或删除资源。在这些活动中所累积的所有信息应该存储在容量管理信息系统（CMIS）中，这样，当循环再次开始时，监控发生的任何变更以保证他们能够产生有益的效果并为将来的行动收集更多的数据。

利用监控方式

应该对特定的操作系统、硬件配置、应用程序等实行不同的监控方式。重要的是监控能够收集容量管理所需求的对于某一组件或服务的所有信息。典型的监控数据包括：

 处理器利用情况  内存利用情况

 事务处理类型所占用的CPU百分比

 输入输出比率（物理的和缓冲区的）和设备利用情况  队列长度  磁盘利用情况  事务处理比率  响应时间

 批处理时长  数据库使用情况  索引使用情况  命中率  并发用户数  网络流量比率

在考虑所要包括的数据的时候，还要把监控容量（如吞吐量）收集的数据和监控性能（如响应时间）收集的数据区分开来。服务容量管理和组件容量管理都需要这两种类型的数据。监控和收集的数据需要结合在服务中需要的所有组件，从而监控端到端的用户体验。需要在整体的资源利用水平上收集数据，还要收集每个服务在每个组件上的负载的详细情况。这需要贯穿于整个技术、主机或服务器、网络、本地服务器和客户端（或工作站）之中来进行。

监控活动的一部分就是监控正常操作水平的阈值、基准或配置。如果超出了指标，应该进行报警和发布异常报告。这些阈值和基准应该由当前记录数据的分析结果所决定，并可以在组件和服务水平上进行设置。所有的阈值设置都应低于组件或服务超常利用的水平或者低于SLAs中的目标。这样，在将要达到或达到阈值时，仍然有机会在违背SLA或资源被过度利用之前采取正确的行动，只是存在一段性能不佳的时期。这些事件、阈值、报警的监控和管理在服务运营书籍中有详细的讨论。

通常得到业务容量管理所需要的关于当前业务量的数据是很难的。这些数据可能派生于对服务容量管理和组件容量管理可用的数据。

响应时间监控

许多SLAs把测量用户响应时间作为众多目标之一，但是，同样地，许多组织在支持这一要求是存在很大的困难。IT和网络服务的的响应时间可以由以下方式监控和测量：

 在客户端和服务器应用软件中注入特殊代码：这种方式可以提供完

全的端到端响应时间或者提供中间时间点来分解整体的响应时间到其组成部件上。通过这些工具所得到的数据可以提供实际的响应时间，如同某一个服务的使用者所感觉的一样。

 在终端模拟软件中使用“机器人脚本系统”：这些系统由带有终端模

拟软件的客户端系统（如浏览器或者远程登陆系统）和特殊的脚本软件组成，可以生成和测量事务处理和响应情况。这些系统通常提供的是样本的端到端服务响应时间，不过对于提供代表性的响应时间仍然是有用的，特别是对多阶段的事务处理或复杂的交互来说。这些只是提供了样本的响应时间，不是实际的响应时间，不像某一服务的使用者所感觉的那样。

 使用分布式的代理监控软件：通过带有监控软件的分布式代理系统

监控网络的不同节点（如网络上的不同国家）可以得到关于服务响应时间的有用信息。这些系统可以用来生成访问某一网站的来自不同地域的汇报并提供周期性的测量数据，如同某一网站的国际用户所感觉的那样。然而，再次强调一下，收到的数据只能作为响应时间的指标，不能作为实际的用户响应时间。

 使用特殊的被动的监控系统：跟踪客户端系统的有代表性的样本

数。这种方法依赖于特殊网络监控系统的连接工具，通常作为“嗅探

器”插入到网络上的合适节点。这些工具就能够监控、记录和测定网络中通过某个特殊节点的所有流量了。一旦记录下来，就可以分析这些流量数据从而得到关于服务响应时间的详细信息。再次强调，这只能用于估计实际的用户响应时间，虽然这些信息通常非常接近现实世界中的状况，但是这依靠于在IT基础架构中的监控的位置。

在一些情况下，需要使用一系列系统的组合。响应时间的监控是一项复杂的流程，即使它是一项运行于私有网络的内部的服务。如果是外部的网络服务，这一流程会因为不同组织和技术的卷入而变得更加复杂。

虚构：拥有一个主要网站的私营公司使用外部供应商实现的网络监控服务可以提供网站可用性和相应能力的自动报警。监测点自身的可用性和速度低于被监控网络的可用性和速度，这样，监控服务所得到的是监控服务自身的可用性和相应能力的数据，而不是被监控网站的数据。

提示：当需要实施外部监控服务时，需要保证监控服务的水平和性能承诺超出被监控服务的水平和承诺。

分析

需要对监控所收集到的数据进行分析以便从正常的利用水平和服务水平中识别趋势，或者建立基准。通过定期监控和对比基准，可以定义单个组件或服务的阈值利用的异常条件，可以报告在SLA考核中的违背或有惊无险的情况并做出相应的行动。同时，这些数据也可用来预测将来的资源使用情况，或者监控实际的业务增长是否与预测的增长相抵。

对数据的分析可以识别问题，例如：

 基础架构中的瓶颈或热点

 在有可用资源的情况下负载分发的不恰当  不恰当的数据库索引  应用程序设计中的无效性

 工作负载或事务处理比率出乎预料地增加  调度或内存使用的效率低

每个组件和服务的使用需要在短期、中期、长期中得到考虑，并记录下最小、最大和平均的使用情况。经常地，短期指的是24小时，中期指的是1--4周，长期指的是1年。随着时间的过去，各个IT服务所使用资源的趋势就会变得明显起来。通过记录使用情况中的任何导致高峰或低谷的因素，这可以提高信息的有效性----例如，业务流程或员工的变更应该和正常的使用情况存在差异。

理解这些时期的使用情况是很重要的，这样把在任何服务使用中的变更与单个组件的利用水平上的预测的变更联系起来。识别某个特别IT服务所依靠的特殊的硬件或软件组件的能力通过一个准确的、最新的、综合的容量管理系统（CMS）得到了极大地提高。

考虑某个特殊的资源使用情况的时候，了解这个资源利用的总水平和使用该资源的单个服务的利用情况是很重要的。

例子：如果在峰值时间一个使用率为75%的处理器由服务A和服务B所使用，了解这75%是如何被每个服务所使用的是重要的。假定系统使用了处理器的5%，剩下的70%可能被这两个服务平分了。如果服务A或B中的一个变更估计需要双倍的处理器资源，处理器将会出现超载的情况。

然而，如果服务A使用处理器的60%，服务B使用10%，这种情况下服务A需要双倍处理器资源的时候，处理器将会超载；而服务B需要双倍处理器资源的时候则不会。

调谐（tuning）

对监控数据的分析可以识别配置的领域从而进行调整以便更好地使用服务、系统和组件资源或者提高某个特殊服务的性能。

辅助的调谐技术包括：

 均衡负载和流量：事务处理通过某个特定的网关到达主机或服务

器，依靠于事务处理的发起位置，均衡发起位置到网关的比率可以提供更好的调谐收益。

 均衡磁盘流量：高效地和战略地在磁盘上存储数据，例如，通过多

种方式剥离数据能够减少数据冲突。

 可接受的锁定战略的定义，可以说明什么时候进行锁定是必要的和

恰当的锁定水平，如数据库、页、文件、记录和行----延迟锁定直到更新能够产生收益以致变得必要的时候。

 内存的有效使用--可能包括依据具体的情况使用更多或更少的内存 在实施来自调谐技术所提出的任何建议之前，考虑测试这些建议的有效性是恰当的。例如：“能够使用需求管理来规避实行任何调谐的必要吗”或者“能够对提议的变更在实施之前进行建模以展示它的效果吗”

实施

实施活动的目标是把由监控、分析、调谐活动所确定的任何变更引进实际的运营服务。这些变更的实施需要通过严格的正式的变更管理流程来进行。系

统调谐变更的影响对于使用服务的客户有重大的意义。与这种类型的变更相关的影响和风险可能要比其他类型的变更更大。

重要的是，采取更进一步的监控以便评估变更的影响。必要时需要采取进一步的变更或者调整一些初始的变更。

利用新技术

这设计到了解新技术和科技，以及它们是如何被使用来支持业务和促进改善的。引进新的技术来提高对组织所依赖的IT服务的支持是恰当的。这些信息可以通过学习专业文献（杂志或出版的文章）或者参加以下的活动收集到：

 硬件和软件供应商的宣传研讨会  潜在的硬件和软件的供应商的用户组会议

 为涉及容量管理的其他IT专业人员召开的用户组会议

这些活动都是提供潜在的技术、科技、硬件和软件相关信息的来源，实施它们可以实现业务收益。在所有情况下，容量管理都应该确认新技术的引进和使用是成本合理的并能为业务带来真实的收益。并不只是新技术本身是重要的，容量管理通过使用网格计算、虚拟化和按需计算等技术，应该保持在新技术使用过程中获得的优势。

弹性设计

在IT基础架构或它的任何子集中容量管理协助弹性设计的确认与改进，在任何成本合理的情况下。结合可用性管理，容量管理应该使用组件失败影响分析（CFIA，在可用性管理中有所描述）来确认当前配置是如何地受到影响以致单个组件的失败或超载并提出任何成本合理的解决方案的建议。

容量管理应该有能力确认关于某个失败的可用性资源的影响，和使用剩余资源运行最重要的服务的潜力。所以，备用容量可以作为在失败情况下的弹性准备或故障恢复。

在服务或系统设计的时候总是应该考虑IT基础架构中弹性设计的需求。然而，对许多服务来说，服务的弹性设计只是在实际运用使用之后才被考虑到。在服务设计中结合弹性设计比在服务运营后添加弹性设计更有效果和效率。

监控活动所使用的单个服务和组件的技术限制和约束可以用来设置阈值，从而作为引发报警和发布异常报告的指标。然而，设置阈值的时候必须经过练习，因为许多阈值依靠于运行在某个特别组件上的运作情况。

服务和组件阈值的管理和控制是有效传递服务以满足既定服务水平的基础。它保证所有服务和组件的阈值在恰当的水平上得到维护、连续地自动地得到监控和出现异常的时候发出报警和警告。无论何时，当超过或者威胁到监控的阈值的时候，能够发出报警和生成警告和异常报告。

应该对这种情况进行完全地分析并在合适的时候采取拯救的行动从而保证这种情况不再发生。使用相同的数据项可以确认什么时候违背了或可能违背SLAs或什么时候组件性能降级了或可能降级。通过设置高于或低于实际目标的的阈值，可以采取及时的行动和避免违背SLAs的目标。阈值监控不应该只是对超出阈值进行报警，还应该监控变更的比率和预测达到阈值的时间。例如，磁盘空间监控需要监控增长的的比率并以当前比率的增长速度在接下来的N天内占满磁盘的情况发出报警。假设一块1G磁盘已经使用了90%，增长速度是100KB/天，则需要1000天会占满磁盘空间。如果增长速度是10MB/天，10天

时间就会占满磁盘空间。这些事件和报警的监控和管理在服务运营书籍中有详细的介绍。

可能存在一些场合，需要优化基础架构的组件和资源来维护和提高性能和吞吐量。这通常是由负载管理完成的，它是一个一般的术语，覆盖如下的行动：

 重新调度某个特殊的服务或负载以便在一天的不同时间或者一周的

某天运行

 从一个位置或配置项目的设置转移服务或负载到另一个----通常是为

了平衡利用或流量

 虚拟化技术：设置和使用虚拟化技术和系统来允许围绕基础架构的

流程移动以动态的形式发挥更好的性能/弹性 

对某一负载何时运行及在基础架构中每一负载使用多少资源的良好理解才能使有效地管理负载成为可能。尽心的负载监控和分析，与综合的容量管理信息系统一起，被不断进行地运维基础所需要。

需求管理的主要目标是影响用户和客户对IT服务的需求和管理对IT资源的影响。

需求管理可以作为短期需求来执行，因为没有足够的容量来支持不断进行的工作，或者，作为IT管理的一项经过考虑的政策，来限制长期所需要的容量。

短期需求管理发生在IT基础架构中某一项关键资源发生局部失败的时候。例如，多处理器的服务器中一个处理器发生故障，从而不可能运行全方位的服务。不过，仍然可以运行全方位服务的一个有限子集。容量管理需要知道每一

服务的业务优先级，了解每一服务的资源需求（在这个例子中，运行某一服务的处理器的数量），这样才能够确认在有限的处理器可用情况下可以运行哪个服务。

长期需求管理发生在难以花费巨大的成本进行升级的时候。例如，许多处理器仅仅在每天的几个小时被严重利用，典型的是上午10点到12点和下午2点到4点。在这些期间内，服务器超载的时间仅仅一到两个小时。对于晚6点到第二天早8点，处理器的负载是很低的并且组件的利用率也是很低的。调整升级的成本仅仅是为24小时中的几个小时提供附加的容量，这可能么或者影响需求或伸展贯穿一天24小时的资源要求，这样可以延迟或避免昂贵的升级的需要，这可能么

需求管理需要了解哪个服务正在使用资源以及当他们必须运行的时候在何种水平上进行调度。这样可以对此服务是否可能影响到资源的使用做出决策，如果可以的话，做出恰当的选择。

对正在运行的服务的影响可能来自：

 物理约束：例如，在某些特定的时间从可用的服务中停止某些服务

或者限制能够使用某个特殊服务的用户数量----例如，限制并发用户数量；对特殊的资源或组件实行约束----例如，限制连接网络路由器或交换机的物理设备数量。

 财务约束：如果为IT服务所做的变更是恰当的，对资源需求少的

时候可以降低每天的某些期间运行服务的比率。这就是所谓的代价。

容量管理的首要目标是在给定的容量和工作种类下预测IT服务的行为。建模活动可以应用于容量管理的任何子流程来产生有益的效果。

建模的不同类型从基于经验和当前资源利用信息的估计延伸到前期研究、原型和全规模的基准。前一种类型对于日常的小决定是便宜的和合理的，后几种类型在实施一项大的工程或服务时是昂贵的，但是却是可取的。通过各种类型的建模，可以获得类似水平的精确度，但是所有这些都依靠于建模人员所使用的信息和建构技巧。

基准

建模的第一阶段是建立一个准确反映正在达成的性能的基准模型。基准模型建立后，预测模型也就完成了，例如，询问一些“如果怎么样，会发生什么”之类的问题来显示失败、计划变更对硬件和（或）负载容量（或种类）的影响。如果基础模型是精确的，潜在失败和变更的结果的精确性也是可以信赖的。

有效的容量管理和建模技术能够回答“如果怎么样，会发生什么”之类的问题。如果服务A的吞吐量加倍，会发生什么如果服务B从当前服务器移到另一台新服务器，会发生什么对这两种服务的响应时间会带来什么样的影响

趋势分析

依靠容量管理收集的资源利用和服务性能的信息可以完成趋势分析。可以在电子表格和图形化的趋势和预测工具中进行分析，用来显示先前一段时间中某项特殊资源的利用情况及将来它会出现怎样的变更。

典型地，趋势分析仅仅对未来资源利用信息进行估计。趋势分析在估计精确的响应时间方面是效果不佳的，这种情况下可以使用分析模型或者模拟模

型。趋势分析在少数变量之间存在线性联系时是最有效的，但是如果变量很多或者变量之间不是线性联系时就不太有效了。

分析模型

分析模型是使用数学技术如多层次网络排队理论的计算机系统行为的代表。典型地，使用个人计算机上的软件包，通过规范需要建模的配置组件和结构以及多种多样的负载或应用程序对组件(如处理器、内存、磁盘等)的利用情况可以建立分析模型。运行模型时，在计算机系统中可以使用排队理论来计算响应时间。如果此模型预测的响应时间足够接近与真实环境下记录的响应时间，那么这个模型就可以被认为是计算机系统的精确代表。

分析模型的技术比模拟模型需要更少的时间和付出，通常得出的也是不够精确的结果。同样的，应该保持模型是最新的。然而，利用情况的误差在5%以内、在线应用程序响应时间的误差在15--20%以内，这样的结果通常是令人满意的。

模拟模型

模拟涉及的是离散事件的模型，如在给定的硬件配置下事务处理的到达比率。模拟模型在新应用的定型或者现存应用变更的效果的预测方面是非常精确的，却是非常耗时的所以成本巨大。

模拟事务处理到达比率的时候，需要一定数量的员工以随机到达的比率从准备好的脚本中键入一系列的指令或者使用软件输入同样的脚本指令。每种途径都需要时间和付出进行准备和运行。然而，这对于拥有大量服务和系统的组织是成本合理的，因为昂贵成本和与之相连的性能承担着巨大的价值。

应用定型具有有限的生命跨度。它开始于一项新服务的设计阶段或者需要对现存服务做出重大变更的时候，终止于实际运营环境接受此应用的时候。定型活动应该包含应用相关的技术的所有方面，而不仅仅是应用本身。即应该包含基础架构、环境、和数据，还经常使用建模和趋势分析技术。

应用定型的主要目标是估计资源需求以支持对现存服务提议的变更或一项新服务的实施，从而保证满足服务等级的要求。为了达到这一目标，应用定型必须作为服务生命周期的一部分。

在最初的需求和设计期间，所需求的服务等级必须在SLR中得到规定。这能够使服务设计和开发使用相关的技术和产品完成设计以符合服务要求的等级。如果服务设计在服务生命周期的开始阶段（而不是其后的阶段）考虑到所要求的服务等级，达到此等级会更加的容易和低廉。

应用定型中其他考虑是弹性设计方面，这对于新服务的设计可能是必须的。容量管理能够为可用性管理在资源需求方面提供建议和指导以提供性能和弹性设计所要求的等级。

应用定型应该和设计、开发一样是精确的。可以在应用定型中使用模型。 不应该孤立地考虑计划的应用开发的SLR。其他服务分享可能会分享应用所利用的资源，必须辨识和管理对现存SLA目标的潜在威胁。

向外部供应商购买软件包的时候，了解支持服务的资源需求是重要的。通常很难从供应商那得到信息，并且它是变化的，依赖于吞吐量的变化。因此，确认产品的相似客户和从那些客户中了解资源的利用情况是有益的。在购买之前进行检查、评估和试验是中肯的。

关键信息：质量必须是内在的。

在实施之后也可以提高服务质量的某些方面（例如，增加额外的硬件以提高性能）。其他方面，特别是应用软件的可靠性和可维护性方面，依赖于内在的质量，因为实际上，在后期阶段尝试添加额外的东西就是重新设计和开发，正常情况下会比原始开发花费更高的成本。即使在上面所举的硬件例子中，在服务实施之后增加额外的容量（而不是作为原始项目的一部分）可能会花费得更多。

触发、输入输出与接口

许多情况会触发容量管理活动。包括：

 违背服务、容量或性能事件和报警，包括阈值事件  异常报告

 当前容量和性能的周期性的修订和预测、报告和计划的回顾  新的或变更的服务需要额外的容量  周期性的趋势分析和建模

 业务和IT规划（和战略）的回顾和修订  设计和战略的回顾和修订

 SLA、OLA、合同或其他协议的回顾和修订 有许多容量管理相关信息的来源，部分如下所述。

 业务信息：来自于组织的业务战略、计划和财务规划及关于当前和将来

需求的信息。

 服务和IT信息：来自于服务战略、IT战略、规划和当前预算，覆盖技

术和技术规划的所有领域，包括基础架构、环境、数据和应用程序及它们与业务战略和规划相关联的方式。

 组件性能和容量信息：来自于制造商和供应商的关于现存技术和新技术

的信息。

 服务性能问题：来自于故障管理和问题管理中性能不佳相关的故障和问

题

 服务信息：来自于服务级别管理，关于服务组合、服务目录、SLAs和

SLRs规定的服务水平目标的服务细节信息，可能来自于SLAs的监控、SLAs的服务回顾和违背的服务细节信息

 财务信息：来自于财务管理，服务规定的成本、资源、组件和升级的成

本、结果的业务收益、财务规划和预算、服务和组件失败相关的成本。一些组件和组件升级的成本来自于采购商、供应商和制造商。  变更信息：来自于变更管理，变更安排和评估所有变更对技术容量的影

响的需要

 性能信息：来自于容量管理信息系统中所有现存服务和IT基础架构组

件的当前性能的信息。

 组件管理系统（CMS）：包含业务、服务、支撑服务与技术之间联系

的信息。

 负载信息：来自于IT运营团队，所有需要运行的工作的调度、不同服

务和信息之间关于依赖关系的信息、某项服务的内部依赖关系的信息

容量管理的输出可以用于容量管理流程的其他部分、其他的流程和组织的其他部门。通常这些信息在共享的领域以电子报告（或展示）的形式或者在内部服务器上的文件被提供，来保证可以使用到最新的信息。提供的信息如下：

 容量管理信息系统（CMIS）：储存容量管理中所有子流程所需要

的信息。例如，作为组件容量管理和服务容量管理的一部分，监控到的和收集的信息可以用于业务容量管理以决定需要什么样的基础架构组件或升级以及什么时候需要。

 容量规划：被业务和IT管理的所有领域所使用。由IT服务提供商

和组织的高级管理层所使用来规划IT基础架构的容量。它还可以作为IT和业务其他领域的输入。它包含了服务和组件的当前使用状况的信息及所做的IT容量的发展以满足现存服务和任何同意的新服务的需要的规划。容量规划可以作为制定政策的基础。经常存在的情况是，建立了容量规划但从来没有参考过或使用过它。  服务性能信息和报告：被许多其他流程所使用。例如容量管理协助

服务等级管理对服务性能、新SLRs开发或现存SLAs变更进行报告和回顾。它还可以协助财务管理确定什么时候为IT基础架构或者新组件的购买提供预算所需的资金。

 负载分析和报告：由IT运营使用，结合容量管理一起来评估和实

施变更以调度或重新调度服务（或负载）的运行时间，保证对可用的资源进行最有效果和有效率的使用。

 容量和性能报告：被容量管理、IT和业务的所有领域所使用来分析

和解决服务和性能问题。

 预测报告：被所有的领域所使用来分析、预测特殊的业务和IT情

境及潜在的解决方案。  阈值、报警和事件。

关键性能指标

一些关键性能指标和度量标准可以用来判断容量管理的效率和效果，包括：

 精确的业务预测：

 按时地对负载产出的预测  对业务趋势预测的百分比精度  及时地把业务规划结合到容量规划中  减少业务规划和容量规划之间的差异  关于当前和将来技术的知识：

 监控所有服务和组件的性能和吞吐量的增强的能力  符合业务需求的新技术的及时调整和实施（时间、成本、功

能）

 减少因为性能或支持所导致的违背SLAs的旧技术的使用。  展示成本效益的能力

 减少在最后时刻进行采购以应付紧急性能问题的情况  减少IT方面的容量过剩  精确预测计划性的支出

 减少由缺乏IT容量导致的业务失败

 相对减少容量规划的成本

 规划和实施恰当的容量以符合业务需求的能力：

 减少因为性能不佳导致的故障的数量  减少因为容量不足导致的业务损失

 所有实施的新服务符合服务等级要求（SLRs）

 减少因为服务性能不佳或组件性能不佳导致的违背SLA的情况

的数量

信息管理

容量管理信息系统的目的是提供相关的容量和性能信息以生成报告和支持容量管理流程。这些报告为许多的IT和服务管理流程提供了有价值的信息。这些报告包括：

基于组件的报告

应该有一个技术团队对每个组件进行控制和管理。这些报告必须图例化地说明组件的性能表现和最大容量内正在使用的容量。

基于服务的报告

这些报告必须图例化地说明服务及其构成组件在遵守整体的服务目标和约束的情况下的性能表现。它们也为服务级别管理报告和客户服务报告提供基础。

异常报告

这些报告显示当某个特定组件或服务的容量和性能变得不可接受的时候需要管理人员和技术人员对容量数据进行分析。在容量管理信息系统中可以为组

件、服务或测量方式设置阈值。例如，阈值可能是某个特定服务器的处理器使用百分比在连续的三个小时都超过70%，或登录用户的并发数量超过规定的限制。

特别地，异常报告可以用于服务级别管理（SLM）以决定是否已经违背了SLAs目标。故障和问题管理也可以使用异常报告来解决故障和问题。

预测报告

为保证IT服务提供者能够继续提供所要求的服务水平，容量管理必须预测未来的负载和增长。为了做到这些，必须预测未来的组件和服务的容量和性能。依靠所使用的技术和科技，可以有不同的方式来完成预测。新功能和服务的开发和实施所带来的对负载的变更必须在由业务增长驱动的当前功能和服务的情况下得到考虑。容量预测的一个简单的例子是业务驱动和组件利用之间的关联，例如，处理器的利用以用户数量为背景。这些相关的数据可以发现增加用户数量对处理器利用的影响。如果未来的容量需求预测需要增加资源，则这种需求需要输入到容量规划中并包含在IT预算周期中。

通常情况下容量报告合并存储在内网上以便任何人可以访问和参考它们。 通常情况下容量数据存储在特定的技术工具和数据库中，组织不能得到数据、信息和数据分析的完整的价值。只有当数据被组合到集成的信息存储的单一集合或数据库的单一集合的时候才能获得真正的价值。

容量管理信息系统是成功的容量管理的基石。容量管理信息系统所存储的信息可以被容量管理的所有子流程所使用和分析，因为它包含了来自科技不同领域的不同类型的数据，包括业务、服务、资源、利用情况和财务数据等。

然而，容量管理信息系统不太可能是一个单一的数据库，可能存在于几个物理地点。为了进行分析、技术规定和管理报告，可以融合来自科技所有领域和组成IT服务的所有组件的数据。只有集成所有的信息才能产生端到端的服务报告。需要妥善地管理容量管理信息系统中数据的完整性和精确性。如果容量管理信息系统不是整体的内容管理系统或者服务知识管理系统的一部分，则需要在这些系统间建立关联以保证系统中所记录信息的一致性和精确性。

容量管理信息系统中的信息可以用于形成传递到客户、IT管理人员、技术人员的性能、容量管理报告和视图的基础。这些数据也可以用于生成未来的容量预测和允许容量管理为未来的容量需求进行规划。通常情况下，通常需要提供连接容量管理信息系统的网络接口以便容量管理之外的流程进行访问和浏览。

容量管理信息系统储存的数据类型包括： 业务数据

具有关于当前和未来业务需要的高质量的信息是必要的。需要考虑组织未来的业务规划和了解对IT服务的影响。需要使用业务数据来预测业务变更对IT基础架构的容量和性能所造成的影响。业务数据应该包含业务事务处理情况或测量方式，如用户数量、生成的发票数量、产品线数量等。

服务数据

为达到服务导向的目标，服务数据应该储存在容量管理信息系统中。典型的服务数据包括事务响应时间、事务处理比率、负载量等等。通常，SLAs和SLRs提供服务目标，为了这些目标，容量管理需要记录和监控数据。为了达到

SLAs目标，应该把服务级别管理的阈值包括进来，以便监控活动能够测量这些阈值并在服务目标被违背之前发出异常警告和报告。

组件利用数据

容量管理信息系统还需要记录资源数据，这些数据包含支撑服务的所有技术组件的利用、阈值和限制信息。多数的IT组件在使用它们的级别上有限制。超出这种限制，资源就会被过度使用，并且使用该资源的服务性能将受到损害。例如，对处理器利用的最大值建议可能是80%，或者对共享的以太网区段的利用不能超过40%。

同样，组件有许多不同的物理限制，超过这一限制以达到更好的连接或限制是不可能的。例如，通过一个程序或网关的最大连接数是100，或者特定类型的磁盘其物理容量是15G。所以容量管理信息系统应该包含每个组件的最大性能和容量限制、当前和过去的利用率以及相关的组件阈值。经过一段时间，容量管理信息系统能够积累大量的数据，所以需要良好的技术来分析、聚集和归档这些数据。

财务数据

容量管理需要财务数据。在容量规划中提议多种方案的时候，为了评估这些可选的升级方案，必须考虑IT基础架构中组件升级的财务成本和当前IT硬件的预算信息。对于IT服务流程来说，这些数据的大多数来自于财务管理，但是容量管理在管理未来的业务需求的时候需要考虑这些信息。

挑战、关键成功因素与风险

容量管理的主要挑战之一是促使业务提供关于战略业务规划的信息，从而使IT服务供应商组织能够提供有效地业务持续性管理（BCM）。这真实地存在服务外包的情境中，在那种情境中，可能是因为商业的或机密的原因导致不能够共享数据。即使关于战略业务规划的数据是可用的，与业务持续性管理相关的业务规划中所包含数据的质量和精确度的问题仍然可能出现。

另一个挑战是整合所有的组件容量管理（CCM）数据到一个集成的信息集合中，便于以一致的方式进行分析来提供服务的所有组件使用情况的细节，尤其是来自不同技术的这些信息由不同的工具以不同的格式所提供的时候。通常，关于技术性能的组件信息在质量和精确度方面是变化的。

由业务容量管理（BCM）尤其是服务容量管理（SCM）和组件容量(CCM)产生的信息量是巨大的，对其进行分析是很难完成的。这就需要人们和流程关注主要的资源及其使用情况，同时不要忽略其他的方面。为了做到这些，必须在工具和技术中使用恰当的阈值，以便在事情严重偏离正常情况的时候能够自动地管理技术和发出警报和告警。

容量管理的关键成功因素（CSF）是：

 精确的业务预测

 关于当前和未来技术的知识  展示成本收益的能力

 规划和实施恰当的容量以符合业务需求的能力 容量管理相关的主要风险包括：

 缺少来自业务的对容量管理的承诺

 缺少来自也业务的关于未来规划和战略的适当的信息  缺少对容量管理的高级管理人员的承诺、资源和（或）预算  由业务容量管理的艰难或缺少恰当和精确的业务信息导致的服务容

量管理和组件容量管理的孤立  流程变得过于官僚化和集中化

 流程过多地关注于技术（CCM）而对服务（SCM）和业务

（BCM）的关注度不够

 提供的报告和信息太过庞大或技术性，不能给出客户和业务所要求

的信息

备注：

Level：水平、等级、级别 Upgrade：更新、升级 Cost：成本、代价 CMS：组件管理系统 CMIS：容量管理信息系统 Utilization：利用、利用情况 Area：领域、方面 Workload：负载 Throughput：吞吐量 Agreed：规定的、既定的 CMS：内容管理系统 SKMS：服务知识管理系统

Effect：效果、影响 Threshold：阈值 Produce:生成、制定