在网络服务中服务等级协议（SLA）是很常见的，它们常常被用来表述网络服务的限制因素——通常被称为“QoS”（服务质量）。但是，在云计算或平台服务中，我们就很难找到可用的指标来作为SLA谈判的标准。

　　从整体上来看，这两者遇到的问题是一样的——你必须制定一个服务质量标准，如果没有达到标准就要想办法去改善它。最大的差别是在细节方面，你肯定要从用户的应用体验限制因素下手去解决这一问题。对于企业而言，利用云计算是出于提高可用性范围和系统性能的目的，这也正是SLA必须要解决的问题。

　　在云计算SLA中最重要的一点是要明白所有与应用体验相关的东西都不属于云计算。从应用运行的角度来讲，云计算的性能就是网络性能、应用性能以及云计算基础架构性能的总和。云供应商只能对最后一个因素负责，而不能对前两者负责。因此，在编订SLA时要明白其它的两个因素究竟会对云计算的整体性能起到什么作用，这一点很重要。

　　通过Internet或其它服务来访问云计算服务将很难去创建一个合适的云计算SLA，因为网络中的延迟、丢包或传输失败率完全是动态变化的。如果你想让用户所体验的传输/应用性能得到保证，你就需要采取一些办法来限制这些变化。如果你的云供应商可以拥有专用的ISP（网络服务供应商）与其直连，你就可以和他进行SLA谈判。如果你想要从多个地点或ISPs访问云应用，那就很难制定一个合适的应用性能标准。

　　如果你将应用性能的变化排除在外，你就可以利用本地的服务器和网络资源来运行应用，在理想的环境来对应用进行衡量。这其中应该包括内存、存储的变化会对性能产生哪些影响，因为这些因素在云计算服务中也是经常变化的。此外，你最好尽可能多地对云中的IT资源进行复制来测试性能，这点很重要。

　　当处理完应用和网络性能因素之后，就可以用所得到的信息来设定云计算性能标准了。例如，如果一个应用在本地运行会有1秒的传输响应时间，还有0.5秒的网络双向连接延迟（对Internet或VPNs来说有些不合理），总共的性能延迟时间就是1.5秒。如果你的业务部门想要将系统响应时间保证在2秒之内，那留给云计算的延迟时间就只有0.5秒。
　　
　　下一个重要的步骤是将应用性能转换成一套可以在云供应商的基础架构内进行测试的标准。只有你为云服务进行了专用的配置，这才能发挥作用。因此，你需要和你的云供应商（或候选供应商）通力合作，来设计一套最佳的云计算配置满足自己的需求。

　　这其中包括，你是否需要使用预留的、或是专用的云资源，你所运行的应用每次需要启动的镜像文件数量，他们所需要的运行环境，所使用的数据库、系统类型和内存大小等等。你还需要对这些配置进行测试，确保它能满足应用用户的基本性能需求。此外，这种配置测试有助于你确定与系统性能和可靠性直接相关的云的特点——比如说从失败的应用案例或案例的负载均衡角度。

　　当前，你必须利用云供应商的管理工具或能力在这套配置当中创建一系列的资源使用、应用可靠性及性能指标。理想的状态是——如果这些标准都能得到满足，配置就可以按照你的设计运行，应用用户的业务目标也可以实现。

　　记住，尽管说你制定云计算SLA的目标是保证传输或应用的性能，但这也是你自己的责任，你需要创建一套用户体验的性能标准，然后利用它来制定云计算和网络的性能目标。

　　为了对你的云计算SLA实现高效的利用，你需要配置故障隔离工具，将故障与网络或云中的应用隔离开来。同时，你还需要将其与你从云计算供应商那里得到的云管理工具整合起来创建一套监控机制，利用它对系统性能进行主动监测并对用户的控诉给予反馈。