返回ITIL4Foundation中文翻译目录，点击

5.2服务管理实践

5.2.1可用性管理

关键词：可用性管理实践的目的是确保服务提供商定的可用性级别，以满足客户和用户的需求。

定义：IT服务或其他配置项在需要时执行其约定功能的能力。

可用性管理活动包括：

●协商并商定可实现的可用目标

●设计可提供所需可用性级别的基础架构和应用程序

●确保服务和组件能够收集衡量可用性所需的数据

●监控，分析和报告可用性

●规划可用性的改进。

简单来说，服务的可用性取决于服务失败的频率以及失败后恢复的速度。这些通常表示为平均故障间隔时间（MTBF）和恢复服务的平均时间（MTRS）：

●MTBF测量服务失败的频率。例如，MTBF为四周的服务平均每年失败13次。

●MTRS测量故障后服务恢复的速度。例如，地铁4小时的服务平均可以在4小时内从故障中完全恢复。这并不意味着服务将在四小时内恢复，因为MTRS是许多事件的平均值。

较旧的服务通常设计具有非常高的MTBF，因此它们很少会失败。最近，已经转向优化服务设计以最小化MTRS，从而可以非常快速地恢复服务。最有效的方法是设计反脆弱的解决方案，这些解决方案可以自动且非常快速地恢复，几乎不会对业务产生影响。对于某些服务，即使是非常短的故障也可能是灾难性的，对于这些服务，更重要的是关注增加MTBF。

定义可用性的方式必须适合每个服务。了解用户和客户对可用性的看法以及定义适当的指标，报告和仪表板非常重要。很多组织根据MTBF和MTRS计算百分比可用性，但这些百分比数字很少与客户的体验相匹配，并且不适合大多数服务。其他应考虑的事项包括：

●哪些重要业务功能受到不同应用程序故障的影响

●在什么时候性能很慢，以至于服务实际上无法使用

●何时需要提供服务，以及服务提供商何时可以执行维护活动。

适用于某些服务的测量包括：

●用户中断分钟数：通过将事件持续时间乘以受影响的用户数或通过将每个用户受影响的分钟数相加来计算。这适用于直接支持用户生产力的服务;例如，电子邮件服务。

●丢失的交易数量：通过从该期间预期发生的数量中减去交易数量来计算。这适用于支持基于事务的业务流程的服务，例如制造支持。

●业务价值损失：通过衡量支持服务失败对业务生产力的影响来计算。这很容易被客户理解，并且可用于规划投资以提高可用性。但是，很难确定哪些丢失的业务价值是由IT服务故障引起的，哪些是其他原因造成的。

●用户满意度：服务可用性是服务最重要，最明显的特征之一，对用户满意度有很大影响。除了满足正式商定的可用性目标之外，确保用户对服务可用性感到满意也很重要。

大多数组织没有专门的可用性管理人员。所需的活动通常分布在组织周围。一些组织将可用性管理活动作为风险管理的一部分，而其他组织则将其与服务连续性管理或容量和性能管理相结合。一些组织拥有站点可靠性工程师（SRE），他们负责管理和改进特定产品或服务的可用性。

定期测试故障转移和恢复机制需要一个过程。许多组织还有一个计算和报告可用性指标的流程;然而，可用性管理与文化，经验和知识一样，都是通过以下程序来实现的。

图5.16显示了可用性管理对服务价值链的贡献，实践涉及所有价值链活动：

●计划：必须在服务组合决策中以及为服务和实践设定目标和方向时考虑可用性管理。

●改进：在规划和改进时，可用性管理可确保服务不会降级。

●驱动：必须了解和捕获新服务和变更服务的可用性要求。

●设计和过渡：必须设计新的和变更的服务以满足可用性目标，并且在过渡期间需要测试可用性控制。

●获取/构建：构建组件或从第三方获取组件时，可用性是一个考虑因素。

●交付和支持：此活动包括可用性的度量和对可能影响满足可用性目标的能力的事件的响应。

返回ITIL4Foundation中文翻译目录，点击

5.2服务管理实践

5.2.1可用性管理

关键词：可用性管理实践的目的是确保服务提供商定的可用性级别，以满足客户和用户的需求。

定义：IT服务或其他配置项在需要时执行其约定功能的能力。

可用性管理活动包括：

●协商并商定可实现的可用目标

●设计可提供所需可用性级别的基础架构和应用程序

●确保服务和组件能够收集衡量可用性所需的数据

●监控，分析和报告可用性

●规划可用性的改进。

简单来说，服务的可用性取决于服务失败的频率以及失败后恢复的速度。这些通常表示为平均故障间隔时间（MTBF）和恢复服务的平均时间（MTRS）：

●MTBF测量服务失败的频率。例如，MTBF为四周的服务平均每年失败13次。

●MTRS测量故障后服务恢复的速度。例如，地铁4小时的服务平均可以在4小时内从故障中完全恢复。这并不意味着服务将在四小时内恢复，因为MTRS是许多事件的平均值。

较旧的服务通常设计具有非常高的MTBF，因此它们很少会失败。最近，已经转向优化服务设计以最小化MTRS，从而可以非常快速地恢复服务。最有效的方法是设计反脆弱的解决方案，这些解决方案可以自动且非常快速地恢复，几乎不会对业务产生影响。对于某些服务，即使是非常短的故障也可能是灾难性的，对于这些服务，更重要的是关注增加MTBF。

定义可用性的方式必须适合每个服务。了解用户和客户对可用性的看法以及定义适当的指标，报告和仪表板非常重要。很多组织根据MTBF和MTRS计算百分比可用性，但这些百分比数字很少与客户的体验相匹配，并且不适合大多数服务。其他应考虑的事项包括：

●哪些重要业务功能受到不同应用程序故障的影响

●在什么时候性能很慢，以至于服务实际上无法使用

●何时需要提供服务，以及服务提供商何时可以执行维护活动。

适用于某些服务的测量包括：

●用户中断分钟数：通过将事件持续时间乘以受影响的用户数或通过将每个用户受影响的分钟数相加来计算。这适用于直接支持用户生产力的服务;例如，电子邮件服务。

●丢失的交易数量：通过从该期间预期发生的数量中减去交易数量来计算。这适用于支持基于事务的业务流程的服务，例如制造支持。

●业务价值损失：通过衡量支持服务失败对业务生产力的影响来计算。这很容易被客户理解，并且可用于规划投资以提高可用性。但是，很难确定哪些丢失的业务价值是由IT服务故障引起的，哪些是其他原因造成的。

●用户满意度：服务可用性是服务最重要，最明显的特征之一，对用户满意度有很大影响。除了满足正式商定的可用性目标之外，确保用户对服务可用性感到满意也很重要。

大多数组织没有专门的可用性管理人员。所需的活动通常分布在组织周围。一些组织将可用性管理活动作为风险管理的一部分，而其他组织则将其与服务连续性管理或容量和性能管理相结合。一些组织拥有站点可靠性工程师（SRE），他们负责管理和改进特定产品或服务的可用性。

定期测试故障转移和恢复机制需要一个过程。许多组织还有一个计算和报告可用性指标的流程;然而，可用性管理与文化，经验和知识一样，都是通过以下程序来实现的。

图5.16显示了可用性管理对服务价值链的贡献，实践涉及所有价值链活动：

●计划：必须在服务组合决策中以及为服务和实践设定目标和方向时考虑可用性管理。

●改进：在规划和改进时，可用性管理可确保服务不会降级。

●驱动：必须了解和捕获新服务和变更服务的可用性要求。

●设计和过渡：必须设计新的和变更的服务以满足可用性目标，并且在过渡期间需要测试可用性控制。

●获取/构建：构建组件或从第三方获取组件时，可用性是一个考虑因素。

●交付和支持：此活动包括可用性的度量和对可能影响满足可用性目标的能力的事件的响应。