无论应用是在云计算基础设施上或在传统的本机硬件配置上运行，用户期望的是相同的服务质量。满足这种期望不仅需要强大的应用软件体系架构和高质量的实施，还需要来自虚拟化的云基础设施、配套技术组件以及连接用户与应用实例的网络等的可接受的服务质量。

用户如何判断应用服务质量 应用的关键质量指标（KQI）被用来表现客户体验应用服务质量的方式。这些KQI的性质各不相同，有时应用与应用之间的差别很大。一个对某个应用来说极其重要的指标可能对另一个应用却没什么意义。但是，有一点对所有的应用是一致的：KQI在表现影响用户对有关服务质量的判断和期望的标准上起到了核心作用。

例如，考虑一些可以描述视频流应用服务质量的KQI。业务的可访问性是至关重要的，因为用户希望能够按需回放视频。播放必须立即开始：没有人愿意在触摸播放按钮后，盯着一个“加载”图标。业务的可保持性也同样重要，因为用户希望视频可以被以一种可接受的质量播放直至结束。频道切换时间、视频的服务质量和语音同步也很重要。如果应用服务能持续满足用户对这些和其他视频服务KQI的期望，它们就会因此满意你的服务。如果没有满足，他们可能会寻求来自你竞争对手的服务。

云服务质量问题

托管在云基础设施上的应用面临一些独特的服务质量的挑战。在云中，用户体验到的服务质量受虚拟化计算、内存、存储和网络资源的影响, 而这些是由托管应用软件执行的由云服务供应商交付的。它也受对应用服务有影响的云技术组件的影响。

这些面向资源的能力带来了额外的服务质量受损的风险。由于资源争用或虚拟机（VM）故障，如死机和不成熟的版本部署，一个应用可能被迫竞争不一致的基础设施资源交付。这些服务质量受损会通过降低应用的服务质量从而影响客户。

基础设施服务时延是基于云的应用面临的一个挑战。图1显示了应用服务时延在本机硬件配置和虚拟化基础设施之间的差别。本机非虚拟化硬件上运行的应用通常提供正常的延迟。对于非虚拟化的应用，最快和最慢的查询响应时间没有显著的不同。运行在虚拟化基础设施上相同的应用往往在服务时延分布上有一个拐点和在此之后的一个尾部，在尾部操作有明显较大的服务时延。在时延分布的尾部遇到特别慢的响应时间的用户可能会对虚拟化应用失去耐心。

图1 ：最终用户体验到的非虚拟化和虚拟化应用的时延比较

作为服务质量下降的另一个例子，图2显示了在三种不同工作负载下电信应用的服务时延尾部分布。需要注意的是在1E-06处最慢的服务时延随负载增加而恶化趋势变得更加显著。

图2： 在虚拟化环境中，增加工作负载导致尾部服务时延增加

新环境带来了新挑战 前面的例子阐明了一种当应用从云计算基础设施访问资源时会遇到的新的服务质量受损的情况。除了处理云基础设施中虚拟化的计算、内存和存储带来的挑战，许多应用会使用由云服务提供商提供的技术组件 ---例如数据库管理系统和负载均衡。为了取得成功，运营基于云应用的企业必须能够快速检测应用服务质量缺陷、故障检测并找准真正的根源、还原用户的业务、并实施纠正措施。

不幸的是，没有一个一刀切的方法来管理应用的服务质量。对于任何特定的应用，用户的服务质量可能对一些基础设施受损很敏感但对其他因素却相对不敏感。更重要的是，不同的应用和架构有不同的敏感性。

即便如此，云服务供应商没必要就给定的目标应用而言并不重要的KQI来过度设计基础设施的性能。例如，视频流应用可将内容缓存在客户端设备上，因此可以容忍某些服务质量的损伤如分组丢失和重传或虚拟机故障和恢复。与此相反，一个视频聊天应用却需要非常低的服务时延，以保持双方之间的对话互动，所以没有时间来重传丢失的数据包。因此，托管交互式视频聊天的云计算基础设施可能比托管预录制视频的基础设施需要较低的丢包率和更严格的资源调度。

由于职责改变带来的服务质量受损

传统的角色、责任和职责在云服务模式中发生了改变。云服务供应商可能把各种来自不同供应商的软件、网络和虚拟化技术集成在一起来实现一个应用服务。这使得问题的跟踪和确定谁来为解决问题负责变得困难。

标准化云计算基础设施服务质量的度量可以帮助云计算消费者和服务供应商管理不可避免的服务质量受损。这些指标有助于快速确定故障部件或服务，以便有关职责方及时恢复服务，并实施适当的纠正措施。有了标准的基础设施的KQI ，云服务供应商可以很清楚地协商给定应用所需的服务等级目标（SLO ）。云服务供应商也可以选择最能满足这些需求的基础设施设备和软件，并确保其能持续满足或超过事先定义的SLO。

由于新的伙伴关系带来的服务质量受损

除了应用软件之外，运行在云计算基础设施之上的应用实例依赖于由合作伙伴提供的重要组件来为用户提供可接受的服务质量。这些组件包括：

针对基于云的应用，用于取代传统计算机或服务器硬件的虚拟机。与传统的硬件类似，虚拟机实例很容易受到损害。然而，虚拟机实体更容易受死机、可变资源的访问延迟、不一致的计时器事件激活、时钟误差和其他异常事件的损伤。这些损伤可能是由于资源共享和底层虚拟化技术（在应用的客户机操作系统与物理硬件之间插入了一层并非完全的硬件仿真）引起。 ‘连接即服务’，它提供了应用的虚拟机实体和其他分布式系统与设备之间的网络连接。传统服务供应商使用背板和物理网络基础设施来连接传统的硬件设备。云服务提供商必须把网络连接作为一种服务来提供，让分布式的基于云的应用可以发挥作用，并给客户提供价值。这些提供的’连接即服务’---容易受到数据包丢失、数据包延迟、数据包抖动和业务不可用的损伤。以服务形式提供的技术组件可以缩短应用的上市时间并降低运营费用。例如‘数据库即服务’和‘负载均衡即服务’允许云服务提供商'买'一个成熟的技术组件服务，而不是“建设”私有和特定应用实例。然而，这些产品很容易受到服务的可靠性、时延、质量和业务不可用等因素的损伤。

采取措施解决服务质量受损

利用三个基本的措施，就可以开始正视和克服由云计算基础设施带给用户服务质量的损伤。这些措施包括：

理解不同的应用具有不同的面向用户与云服务供应商缺陷相关的服务质量敏感性。例如，一个面向批处理的应用的服务质量可能对丢包、数据包时延和数据包抖动等损伤不敏感。但对一个高度交互的应用而言，其服务质量可能对丢包、延迟和抖动非常敏感。通过合理的应用设计来减少云基础设施受损对最终用户的影响。此外，要在具有类似服务质量的基础设施条件下测试应用，确保用户持续获得可接受的服务质量。认识到”篱笆扎得牢，邻居处得好”。为所有云计算基础设施的KQI商定SLO，以便在应用业务遇到用户的服务质量问题时能使故障得到快速隔离。进一步明确服务范围和要求将使它更容易找出问题，并确定谁有责任来解决问题的根本起因。

    设定可实现的目标

与传统方式部署的应用一样，基于云的应用不可避免地会遇到偶尔的业务损伤和故障。我们的目标应该是在云基础设施上部署稳健和具有成本效益的应用，并确保它们始终如一地满足或超越用户对服务质量的期望。

这意味着要确保一个给定的应用可以快速检测、减轻由云计算基础设施带来的业务损伤并从中恢复过来。这也意味着为‘应用即服务’、‘基础设施即服务’和‘平台即服务’等供应商明确定义角色和职责。通过结合商业技巧为每个责任方实施量化的SLO，运用标准化的指标和明确的问责，一个云服务供应商可以确保一个应用的所有供应商知道他们需要提供什么来满足用户对服务质量的期望。