不幸的是，没有一个一刀切的方法来管理应用的服务质量。对于任何特定的应用，用户的服务质量可能对一些基础设施受损很敏感但对其他因素却相对不敏感。更重要的是，不同的应用和架构有不同的敏感性。
即便如此，云服务供应商没必要就给定的目标应用而言并不重要的KQI来过度设计基础设施的性能。例如，视频流应用可将内容缓存在客户端设备上，因此可以容忍某些服务质量的损伤如分组丢失和重传或虚拟机故障和恢复。与此相反，一个视频聊天应用却需要非常低的服务时延，以保持双方之间的对话互动，所以没有时间来重传丢失的数据包。因此，托管交互式视频聊天的云计算基础设施可能比托管预录制视频的基础设施需要较低的丢包率和更严格的资源调度。
由于职责改变带来的服务质量受损
传统的角色、责任和职责在云服务模式中发生了改变。云服务供应商可能把各种来自不同供应商的软件、网络和虚拟化技术集成在一起来实现一个应用服务。这使得问题的跟踪和确定谁来为解决问题负责变得困难。
标准化云计算基础设施服务质量的度量可以帮助云计算消费者和服务供应商管理不可避免的服务质量受损。这些指标有助于快速确定故障部件或服务，以便有关职责方及时恢复服务，并实施适当的纠正措施。有了标准的基础设施的KQI ，云服务供应商可以很清楚地协商给定应用所需的服务等级目标（SLO ）。云服务供应商也可以选择最能满足这些需求的基础设施设备和软件，并确保其能持续满足或超过事先定义的SLO。
由于新的伙伴关系带来的服务质量受损
除了应用软件之外，运行在云计算基础设施之上的应用实例依赖于由合作伙伴提供的重要组件来为用户提供可接受的服务质量。这些组件包括：
针对基于云的应用，用于取代传统计算机或服务器硬件的虚拟机。与传统的硬件类似，虚拟机实例很容易受到损害。然而，虚拟机实体更容易受死机、可变资源的访问延迟、不一致的计时器事件激活、时钟误差和其他异常事件的损伤。这些损伤可能是由于资源共享和底层虚拟化技术（在应用的客户机操作系统与物理硬件之间插入了一层并非完全的硬件仿真）引起。
‘连接即服务’，它提供了应用的虚拟机实体和其他分布式系统与设备之间的网络连接。传统服务供应商使用背板和物理网络基础设施来连接传统的硬件设备。云服务提供商必须把网络连接作为一种服务来提供，让分布式的基于云的应用可以发挥作用，并给客户提供价值。这些提供的’连接即服务’---容易受到数据包丢失、数据包延迟、数据包抖动和业务不可用的损伤。
以服务形式提供的技术组件可以缩短应用的上市时间并降低运营费用。例如‘数据库即服务’和‘负载均衡即服务’允许云服务提供商'买'一个成熟的技术组件服务，而不是“建设”私有和特定应用实例。然而，这些产品很容易受到服务的可靠性、时延、质量和业务不可用等因素的损伤。
采取措施解决服务质量受损
利用三个基本的措施，就可以开始正视和克服由云计算基础设施带给用户服务质量的损伤。这些措施包括：
1.理解不同的应用具有不同的面向用户与云服务供应商缺陷相关的服务质量敏感性。例如，一个面向批处理的应用的服务质量可能对丢包、数据包时延和数据包抖动等损伤不敏感。但对一个高度交互的应用而言，其服务质量可能对丢包、延迟和抖动非常敏感。
2.通过合理的应用设计来减少云基础设施受损对最终用户的影响。此外，要在具有类似服务质量的基础设施条件下测试应用，确保用户持续获得可接受的服务质量。
3.认识到”篱笆扎得牢，邻居处得好”。为所有云计算基础设施的KQI商定SLO，以便在应用业务遇到用户的服务质量问题时能使故障得到快速隔离。进一步明确服务范围和要求将使它更容易找出问题，并确定谁有责任来解决问题的根本起因。
设定可实现的目标
与传统方式部署的应用一样，基于云的应用不可避免地会遇到偶尔的业务损伤和故障。我们的目标应该是在云基础设施上部署稳健和具有成本效益的应用，并确保它们始终如一地满足或超越用户对服务质量的期望。
这意味着要确保一个给定的应用可以快速检测、减轻由云计算基础设施带来的业务损伤并从中恢复过来。这也意味着为‘应用即服务’、‘基础设施即服务’和‘平台即服务’等供应商明确定义角色和职责。通过结合商业技巧为每个责任方实施量化的SLO，运用标准化的指标和明确的问责，一个云服务供应商可以确保一个应用的所有供应商知道他们需要提供什么来满足用户对服务质量的期望。
