ITIL 4容量和性能管理实践【中文】
需要下载 ITIL 4容量和性能管理实践【中文】pdf版全文，请关注微信公众号itilxf ，并回复“容量和性能”即可。
申明：
本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
翻译：傅盛 审校：秦佩君 审核：姚凯
----
1 关于本文档
本文档提供了容量和性能管理实践实用指南，分为五个主要部分，涵盖：
●本实践的一般信息●本实践相关的过程和活动及其在服务价值链中的作用●参与本实践的组织和人员●支持本实践的信息和技术●对本实践的合作伙伴和供应商的考虑
1.1 ITIL 4资格认证计划
本文档中的部分内容可作为以下教学大纲的一部分以供检查：
● ITIL高速IT专家。
详情请参考各部分教学大纲。
2 一般信息
2.1 目的和描述
[*]关键信息
容量和性能管理实践的目的是确保各项服务达到商定和预期的性能水平，并以符合成本效益的方式满足目前和未来的需求。
容量和性能管理实践通常包括服务性能和支持服务的资源（如基础设施、应用程序和第三方服务）的性能。许多组织中，这一实践也包括人员的容量和性能，特别是直接提供服务的人员的容量和性能。
该实践确保按照本组织的战略和承诺，有效了解和履行服务和资源的容量和性能要求。为此，本实践应用于整个组织产品和服务从构思到运营的生命周期。规划和设计产品和服务时，这种实践极其重要。这些阶段所做的决定将影响性能水平和其他约束条件，以及组织监控和管理这些方面的能力。
容量和性能实践与服务可用性、连续性、信息安全各自的实践密切相关。这些实践通常处理的是配置项和服务的相同特征，但侧重于质量的不同方面。在这些领域的服务管理四维模型上共享资源非常有益。但是，在服务连续性和信息安全等外部监管的领域需要明确地职责分离。
2.2 术语和概念
[*]定义：性能
衡量系统、个人、团队、实践或服务达成或交付情况的指标。
服务性能通常与服务处理的速度和在给定需求水平下完成服务事务所需的时间相关。服务性能取决于服务能力，是一个配置项或一项服务可以交付的最大吞吐量。使用的具体指标取决于服务或配置项的技术和业务性质。
性能对消费者是一个重要的服务特征，是协商、协议、监控和报告的主题。这些活动涉及业务分析、关系管理、服务设计、服务级别管理（SLM）、度量和报告实践等多种实践。容量和性能管理与这些实践结合，确保涉及容量和性能的处理充分一致。
服务性能是一个复杂的特性。只有在理解度量前提下，用多种度量和协议分析服务性能才有可能。协议应该取决于服务体系架构、某些事务和支持组件的重要性、质量标准和其他参数。此外，从用户角度看到的性能可能不同于从提供者或客户角度衡量的性能。例如，2.5%的用户体验到服务事务延迟将被这2.5%的用户视为性能不佳，但可能仍然满足商定的性能目标。
容量和性能管理实践应确保所有相关方对容量和性能（预期、同意、设计和实际）有透明、一致和实际的理解。
当为成千上万人提供服务时，通常不能与客户达成一个一致的通用服务性能协议，但整体服务性能对服务提供商至关重要。
2.3 范围
容量和性能管理实践确保服务提供了商定的绩效水平，以符合成本效益的方式满足了客户和用户的需求。为此，容量和性能管理实践包括服务、产品和组件的容量和性能的定义、度量、分析和改进，是处理与容量相关事项的专门知识中心，并支持其他服务管理实践。
容量和性能管理的范围非常广泛。许多实践直接或间接对服务性能有贡献。表2.1列出了与容量和性能管理密切相关的活动。重要的是要记住，ITIL实践仅仅是在价值流环境情景下使用的工具集合，应该根据具体的组织、服务和客户情景进行必要的组合。
活动实践指南
协商和商定客户对容量和性能的要求SLM
将容量和性能控制设计作为服务模型的一部分服务设计
保持容量和性能控制与业务体系架构的一致架构管理
识别与容量和性能相关的风险风险管理
分析变更对容量和性能目标的影响变更支持
监控服务的容量和性能监控和事态管理
验证新的容量和性能控制组合管理
实施风险缓解措施、改变服务基础设施以确保弹性项目管理，变更支持
在服务转换期间测试容量和性能控制服务验证和测试
应对可能影响组织满足容量和性能目标能力的事件管理容量和性能事件
事件管理
持续管理和实施与容量和性能相关的改进持续改进
表2.1与容量和性能管理实践相关的活动
2.4 实践的成功因素
[*]定义：实践的成功因素（Practice Success Factor, PSF）
实践为实现其目的所需的复杂功能性组件。
实践成功因素（PSF）不仅仅是一项任务或活动，包括服务管理四维模型的所有组成部分。在一项实践中，PSFs相关的活动和资源的性质可能不同，但这些活动和资源共同确保实践的有效性。容量和性能管理实践包括以下要素：
[*]识别服务容量和性能要求
[*]测量、评估和报告服务容量和性能
[*]处理服务容量和性能风险
2.4.1 识别服务容量和性能要求
识别服务容量和性能要求包括：
1 了解客户对服务性能的要求 业务分析和SLM实践通常用于与客户沟通，了解客户对IT服务的性能和容量要求，并协商服务级别要求(SLRs)。容量和性能管理实践支持并给到SLM、业务分析和服务设计实践输送资源。容量和性能管理对优化服务设计，在减缓成本增加的同时满足不断增长的容量需求至关重要。
2 确定容量和能力的标准 应清晰界定高低性能之间的界限。在确定服务表现标准时，应考虑下列因素:
[*]服务动作/功能/关键业务功能；服务性能由关键的服务动作定义
[*]执行服务事务时可接受的延迟，不应视为服务降级；不可接受的降级，则应视为不可用
[*]比例因子：服务性能降级通常意味着大量而不是个别用户经历延迟。
3 选择一套正确的容量和性能指标 指标应反映服务降级如何影响服务提供商和客户。
2.4.2 测量、评估和报告服务容量和性能
性能是服务质量最基本的指标之一，因此服务提供者能够测量、评估和报告性能很重要。根据前置时间和每个时间段的事务数量报告性能是广泛接受的实践。确保从用户以及技术的角度理解测量也很重要。要进一步了解如何定义有意义的服务指标，请参考SLM实践指南。
当定义合适的测量时，至关重要的是反映服务降级对业务的影响而非服务组件的技术性能。
容量和性能管理实践有两个最重要的目标，确保充分的容量和性能监控以及将监控数据转化为服务性能信息。
事件记录可能是服务中断数据的来源，但通常很难根据这些数据获得可靠的性能和容量数据，特别是很难将用户报告的事件与商定的服务性能指标保持一致。
更可靠的性能和容量数据的来源是基础设施监控工具。然而，尽管这些方法可以很好地测量资源提供型服务，但仅仅根据基础设施监控数据几乎不可能正确地度量服务事务的性能。真实的用户监控和业务事务监控之类的工具可以帮助解决这个问题。
2.4.3 处理服务容量和性能风险
容量和性能管理实践不仅是关于容量和性能的计划和监控。该实践包括定义和管理控制，进而管理可能影响服务容量和性能的各种风险。为此，该实践与风险管理和其他关注风险的实践（如可用性管理、服务连续性管理和信息安全管理实践）结合使用。商定的性能控制通过服务设计、软件开发和管理以及基础设施和平台管理实践实现。
在风险管理的背景下，风险识别、定义优先级和测量阶段对容量和性能管理实践至关重要。
容量和性能管理实践确保风险将得到有效处理：
[*]评估组件的容量和性能对产品和服务端到端性能的影响，识别相关的漏洞和约束
[*]评估产品和服务的容量和性能对用户和客户体验的影响
[*]设计有效的控制措施和对策，预防、检测和减轻容量和性能风险
[*]持续监控容量和性能风险，并优化实践范围内的风险管理活动
2.5 关键指标
应在每个实践所贡献的价值流情境下评估ITIL实践的有效性和绩效。与任何工具的性能一样，实践的绩效只能在其应用的情境中评估。然而，工具在设计和质量上可能有很大的差异，这些差异定义了工具有效性的潜力或能力。在根据工具的目的使用时，工具是有效的。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
容量和性能管理实践的关键指标映射到其PSFs。这些PSFs可以用作价值流情境下的关键绩效指标，评估实践对这些价值流的效率和效能的贡献。表2.2给出了一些关键指标的示例。
实践成功因素关键指标
定义服务容量和性能需求•在SLAs中明确记录具有容量和性能要求的产品和服务的百分比•符合SLAs中记录的有容量和性能要求的新的或变更的运营产品和服务的百分比•在服务发生重大变化时，及时更新服务容量和性能要求及标准
测量、评估和报告服务容量和性能•符合性能需求的新组件和架构设计的已受理业务用例的百分比•减少使用旧的（不再支持的）组件或架构设计，因为这些设计会引发性能问题从而违反SLAs•以下产品和服务的百分比: •已定义的容量和性能指标 •容量和性能受到监控的 •包含在服务容量和性能报告中的•由容量和性能管理实践者团队记录的已实施改进计划的百分比
处理服务容量和性能风险•计划外的产品、服务和组件容量和性能升级次数•因产品或服务的容量和性能不足造成的实际损失与预期损失的比率
表2.2实践成功因素的关键指标示例
将测量标准正确地汇总成复杂的指标中，将使数据更易用于价值流的持续管理，以及容量和性能管理实践的定期评估和持续改进。对此没有唯一的最佳解决方案。测量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流目标。
3 价值流和流程
3.1 价值流贡献
与其他ITIL管理实践一样，容量和性能管理实践对多条价值流有帮助。重要的是要记住，价值流从来不是由单一实践形成的。容量和性能管理实践与其他实践结合，为消费者提供高质量的服务。实践对价值链活动的主要贡献是：
[*]交付和支持
[*]设计和转换
[*]改进
[*]获取/构建
[*]计划
容量和性能管理实践对服务价值链的贡献如图3.1所示。图3.1容量和性能管理贡献热力图
3.2流程
每个实践可以包括一个或多个流程和活动，这是实现这一实践目的所必需的。
[*]定义：流程
将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了操作的顺序及依赖关系。
容量和性能管理实践活动分为两个流程：
[*]建立容量和性能控制
[*]分析和改善服务容量和性能
3.2.1 建立容量和性能控制
该流程包括表3.1中列出的活动，并将输入转换为输出。
关键输入活动关键输出
业务需要业务流程性能、事务量、活动模式及预测服务组件制造商的要求和标准
识别服务容量和性能需求商定服务容量和性能要求确定容量和性能测量需求
识别、商定和记录服务和组件的需求
服务和度量框架服务报告框架
设计容量和性能指标及报告性能和容量测量要求在监控工具集中设置的性能和容量基线、测量、告警、阈值和报告
SLAs
现存服务和组件性能数据
适当的自动缩放和负载均衡控制（适用时）
表3.1 建立容量和性能控制过程的输入、活动和输出
图3.2 展示流程的工作流图。图3.2建立容量和性能控制过程的工作流
应用该流程的服务类型和服务组件的差异，会导致此流程可能有所不同。表3.2展示了现代云使能服务和一线服务支持人员的活动是如何变化的。
活动云IT基础架构一线支持人员
识别服务容量和性能需求容量和性能管理人员根据活动模式和事务量识别性能需求。这些信息可能已可以从SLM实践中以SLR的形式获取，或从业务用例文档中获得。持续的报告对于识别未被满足的缩放需求也很有用。接着将这些需求与各种服务组件的技术容量特征比较，这些特征可以是计算能力、存储、终端用户设备输入和输出容量以及网络性能参数（带宽、延迟、连接等）。然后，容量和性能实践者建议在性能需求、所需的组件架构和高效的发包模型（个体、社区、公共或混合选项）之间取得最佳平衡。该活动的输出是一个架构设计提案若干计划，为中长期云基础设施设计提供所需的容量。该输出供服务设计和SLM实践进行成本收益分析。区分上述需求和短期服务需要的高峰（例如，营销活动时网站的用户流量增加）很重要。在云环境中，可通过专门的容量扩充工具自动检测和满足这些需求，无需透彻分析。
在需要提供用户支持的地方，必须充分考虑处理用户查询的服务台团队所需的资源。虽然服务台、劳动力和人才管理实践等其他实践也可能会管理员工规划和测量，但容量和性能管理实践可以为这些实践提供业务模式和事务量。容量的实践者还可以推断出实现最佳的服务速度和质量所需的人员数量、技能和容量的最小值，
商定服务容量和性能需求SLM实践负责包括容量和性能服务质量标准在内的SLA协商。容量和性能实践者使用服务组件专业知识支持此活动。重要的是平衡成本/效益比，并在内部沟通服务的价格。不同容量的架构选项，服务的价格可能会有很大的差异。容量和性能是SLA协商的重要组成部分。该实践可建议人员数量和容量的多种组合，以不同的价格和成本提供不同水平的支持。该实践还可建议支持工具的改进计划，帮助优化员工数量，如自助服务界面、在线聊天、社交媒体展示等等。这些分析工作是对服务支持标准的SLA协商的基础。
确定容量和性能测量需求为了分析、报告和改进服务性能，服务提供者必须进行测量。根据商定的需求、报告策略、客户报告需求和监视工具，应定义一种性能监视的方法。容量和性能管理实践者知晓现有的云编排工具可基于一组内部或外部触发器扩展（或减少）现有的付费容量。实践者可设计一组阈值和警报，这些阈值和警报将启动自动容量变更过程。
服务支持的人员绩效测量很可能与持续时间参数相关，例如响应时间、解决时间、直接用户联系等。容量和性能管理实践可能有相关的测量工具（如支持电话线路监测和报告工具）。容量实践者可以提供这些指标作为其他实践管理人员绩效。
设计容量和性能指标和报告此活动侧重于服务性能测量和报告。实践者设计工具，从消费者角度模拟或手动控制服务性能，并将任何技术指标（如实时网络吞吐量）置于次要位置。技术指标仅用于验证服务生产率、响应能力、存储容量等方面的客户体验。
表3.2建立容量和性能控制过程的活动
3.2.2 分析和改进服务容量和性能
该流程包括表3.3中列出的活动，并将输入转换为输出。
关键输入活动关键输出
容量和性能报告和告警新服务设计和架构提议性能相关事件和问题记录变更计划
服务容量和性能分析报告服务容量和性能策划和设计服务容量和性能
向持续改进登记单（Continual Improvement Register, CIR）提交改善措施服务设计和架构的评审和提议与服务设计与运营管理实践保持沟通IT预算计划更新
表3.3分析和改进服务容量和性能流程的输入、活动和输出
图3.3展示流程的工作流图。图3.3分析和改进服务容量和性能流程的工作流
应用该流程的服务类型和服务组件不同，会导致此流程可能有所不同。表3.4展示了现代云使能服务和一线技术支持人员的活动是如何变化的。
活动云IT基础设施一线支持人员
服务容量和性能分析云编排和负载平衡工具集允许自动调整云资源满足需求。然而，业务活动模型的趋势分析可能表明，当前的服务架构可能需要改变，在确保高性能的同时避免过高的成本。容量和性能实践者可监控服务台员工的技术指标，并在出现缺陷或达到阈值时（与服务台实践一起）发出告警。例如，由于一线支持人员很忙，未能接到新用户的电话。这可能是由许多因素造成的，但技术指标是一个值得研究的客观事实。
报告服务和容量性能云编排工具集和云提供商报告，可以提供许多技术指标。然而，云环境中性能分析的核心思想是关注客户的业务流程。技术组件报告可能支持调查的发现，但不应成为最后报告的重点。基于自动化监控工具（如监控支持电话线工具），容量和性能实践者可自动化生成基础技术指标报告，并以原始或汇总的形式向客户提供报告。
策划和设计服务容量性能人们很容易利用云计算中几乎无限的可伸缩性应对变化无常且不断增长的服务需求。然而，当需求达到某个阈值时（例如，修改网络设计以迎合新获得的区域市场用户），更改底层应用程序、中间件和负载平衡架构应更为谨慎。容量实践者具备建议这些优化的必要专业知识，避免与线性扩展相关的过度服务成本。
其他实践可要求容量和性能管理实践，根据人员数量和能力协助进行具体计算，并有助于规划手动支持任务的自动化。这些有效的输出体现在改进计划上。例如，实践者可以建议从终端用户设备中获取自动诊断数据，节省用户问卷调查的时间。
表3.3分析和改进服务容量和性能流程的输入、活动和输出
4组织和人员
4.1 角色、能力和责任
实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注每种实践所特有的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可以承担多个角色，一个角色也可以分配给多个人员。
在流程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。
能力代码能力类型（活动和技能）
L领导Leader 决策、授权、监督其他活动，提供激励和动力，并评估结果
A管理员Administrator 分配任务并确定优先级、保存记录、持续报告，并启动基本改进
C协调者/沟通者Coordinator/Communicator 协调多方，维护利益相关者之间的沟通，并开展宣传活动
M方法和技巧专家Methods and techniques expert 设计和实施工作技巧、文件化步骤、流程咨询、工作分析和持续改进
T技术专家Technical expert 提供技术（IT）专业知识并执行基于专家经验的作业
表4.1能力代码和类型
表4.2列出了容量和性能实践中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
活动负责角色角色类型角色技巧
建立容量和性能控制
服务容量和性能分析容量和性能经理服务负责人技术专家IT质量经理
MT优秀的分析能力具备故障树分析、部件失效影响分析等方法和技术知识熟悉分析工具对服务中断可能造成的业务影响有良好的理解
报告服务容量和性能服务负责人关系经理客户
CA对于协议和期望的认知理解客户的情景沟通和协商
策划和设计服务容量性能容量和性能经理服务设计师技术专家架构经理
TM对弹性选项的良好理解对现存控制的认知对市场上可用技术的认知对服务中断可能带来的业务影响有良好理解
分析和改进服务容量和性能
识别服务容量和性能需求服务或产品负责人关系经理服务设计师客户
CTA业务分析熟悉产生需求的商业活动模式、吞吐量和市场熟悉服务架构和配置沟通和协同
商定服务容量和性能需求服务负责人关系经理客户
CA沟通和协商，并能提出改进意见熟悉服务架构和配置
确定容量和性能测量需求容量和性能经理监控工具管理员监控和事态经理服务设计师技术专家
TM对监控工具和技术的良好理解对市场上可用的监控和事态管理技术的认知
设计容量和性能指标和报告容量和性能经理服务负责人关系经理IT质量经理
CM沟通和协商报告和仪表盘设计技能
表4.2负责容量和性能管理活动的角色示例
4.2 组织结构和团队
虽然正式的职位和工作说明能给予容量和性能实践者以支持，但具有专门的容量和性能管理实践的组织结构很少见。服务容量通常由其他组织职能管理，角色可根据服务的性质组合。
当服务提供商负责有限数量的服务和组件时（例如服务集成商职能），可安排一位容量和性能经理。该角色负责协调实践、职能和组织，确保具有成本效益的服务容量和足够的服务性能水平。
业务和技术知识对这一实践的成功至关重要，同时服务提供商的员工也具备服务和组件性能的计划、监控和报告能力。
管理者和实践者应将沟通和支持能力与技术知识互补，确保在服务设计、协商和运营过程中听取、衡量和处理容量顾虑并进行预测。
5 信息和技术
5.1信息交流
容量和性能管理实践的有效性取决于所用信息的质量。这些信息包括但不限于：
[*]基于组件的报告
[*]基于服务的报告
[*]性能异常报告
[*]性能和工作量预测
[*]不同服务需求范围的架构模型
[*]供应商规模调整建议和模型
信息可有多种形式。实践的关键输入和输出在第3节中列出。
在许多情况下，容量和性能管理实践可从自动化中获得很大好处。在可行且有效的情况下，它可能涉及表5.1中概述的解决方案。
过程活动
自动化方式关键功能对实践有效性的影响
建立容量和性能控制
服务容量和性能分析基础设施和应用监控以及报告工具，内置用户行为监控工具，仪表盘和报告工具，高级分析工具系统和服务健康数据的收集、处理和分析、仪表盘和报告的设计与展示高
报告服务容量和性能仪表盘和报告工具，服务门户和应用程序，Email和其他交流工具，社交媒介报告演示文稿低到高，取决于必须向其报告的服务和利益干系人的数量
策划和设计服务容量和性能架构管理工具，CMDB，变更计划和控制工具确定现存控制和弹性措施改进相关的变更计划和控制
中
分析和改进服务容量和性能
识别服务容量和性能需求服务目录，CMDB，BPM工具，服务模型，性能和容量监控和管理工具，资产管理工具为识别对业务功能至关重要的服务和性能，分析人员应能够访问服务组件和服务操作的信息。BPM工具可以提供有关消费者流程及服务支持的操作信息。
极高
商定服务容量和性能需求合同工具和服务门户备选方案的选择与服务消费者的沟通
低
确定容量和性能测量需求报告和仪表盘工具，服务门户和应用程序报告和仪表盘模板设计低至高，取决于必须向其报告的服务和利益干系人的数量
设计容量和性能指标和报告
表5.1容量和性能管理活动的自动化解决方案
6 合作伙伴和供应商
很少的服务是仅用组织自身资源就能交付的。大部分（如果不是全部的话）依赖于其他服务，通常由组织外的第三方提供（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。在服务设计、供应商管理和SLM的实践指南中有支持服务引入的关系和其依赖关系的相关叙述。
随着服务集成模型在现代企业服务消费者环境中日益普遍时，协调服务性能的重要性也日益明显。当多个外部服务提供商负责不同的服务组件，甚至是整个服务产品时，最终用户体验就有被忽视的风险（尤其是在出现“等待系统响应”等不太明显的提示时）。服务集成和管理机构应负责保持对最终用户的关注，这些用户的服务容量和性能与多个供应商相关。
鼓励服务提供商将性能问题传达给一个集中的（或以用户为中心的）实体有助于协同服务集成工作。这个实体可以是专门的容量和性能经理、服务台收件箱或任何其他主体。不管是谁，分析问题是如何影响最终用户体验的可以实现透明化和快速恢复。这种激励可以在事情出现偏差时，限制责任并防止潜在问题的快速恶化。
在多供应商IT环境中，服务提供商通常将容量增长选项限制为线性模型。当业务的用户基数迅速扩大时，通常会根据不断增长的工作量增加相同的基础设施资源。类似“ ”体验的现代公有云产品可能会鼓励这种行为。但其他架构安排可能适用于不同规模的运营，并可以确保有效的负载平衡、最佳的资源利用，甚至可以提高系统可靠性。
容量管理实践者应对现代IT基础设施架构有深刻的理解。在适当的情况下，实践者应在确保解决成本的前提下，提出改动现有设计，满足增加或变更的需求。服务集成商随后可以向服务提供商建议这些替代模型。
当组织的目标是确保快速有效的容量和性能管理时，通常会尝试与合作伙伴和供应商密切合作，消除沟通、协作和决策过程中形式化的官僚主义障碍。在这种关系中，所有各方都应致力于保证相互透明和对可能影响其他各方的变更的可见性（更多信息请参见供应商管理实践指南）。
7 重要提醒
实践指南的大部分内容应视为组织在建立和培育自身实践时相关领域可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
[*]聚焦价值
[*]从你所处的地方开始
[*]基于反馈迭代推进
[*]协作和提升可视化程度
[*]通盘思考和工作
[*]保持简单实用
[*]优化和自动化
关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
8 致谢
AXELOS有限公司感谢所有为该指南开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
8.1 作者
Konstantin Naryzhny
8.2 审阅者
Roman Jouravlev
页:
[1]