服务品质协议（service-level agreement）（SLA）是服务提供者和客户之间的一个正式合同，用来保证可计量的网络性能达到所定义的品质。SLA 为服务提供者提供了一种在当今多变而又竞争激烈的市场中胜过对手的方法。服务提供者可能是一个国内的 IT 组织、一个应用程序服务提供者（ASP）、一个网络服务提供者（NSP）、一个因特网服务提供者（ISP）、一个受管服务提供者（MSP）或者任何其它类型的服务提供者。
SLA 可以非常笼统或者极度详细，它一般都包含出现故障时服务提供者和客户应采取的步骤。服务提供者保证它提供的服务在一定百分比的时间内（例如，99.9%）是可用的。提供者还能够强制向客户通知 SLA 当机时间的最长和平均响应时间，或者在网络接口发生改变之前的最长和平均响应时间，并利用基于因特网的工作流自动化、分发和报告技术。如果经过指定的一段时期后提供者无法达到所定义的性能品质，客户就可以获得一些权利和赔偿。各个 SLA 的权利、赔偿和例外情况是不同的。客户还同意接受协议一般条款的指定例外情况。
在每个 SLA 中都必须精确定义服务品质；否则各方关于 SLA 将以哪种品质衡量什么服务或性能标准将无法达成一致。例如，一个客户可能认为一个双方同意的服务品质将衡量网络 A、网络 B 和网络 C，同时后两者连接到第一个，而服务提供者却认为它只衡量网络 A。还有一点很重要的是正常运行时间可用性百分比的小数位数：例如，一年中的当机小时数和当机天数比，99.999% 的正常运行时间所允许的当机时间比 99.9% 的正常运行时间所允许的当机时间还少。SLA 应该为客户包含进一个退出条款；当因为不能圆满解决经常发生的可用性、可靠性和安全性问题而使客户的业务运转频繁中断时，客户希望他有终止协议的权利。
SLA 已经出现了一段时间了。在二十世纪六十年代，它们是用于达到已定义的服务品质和响应服务问题的一般操作程序，而这些服务问题是用户组织在购买或租用大型机上的机器时间时就已经同意过的。 超大型计算机（big iron）是缺省的企业系统，其它任何技术的处理能力都无法与它相比。
当客户机／服务器和网络桌面系统进入计算机世界时，人们就构思出了分布式网络系统这个概念。这些系统后来发展成了跨网络运行企业资源规划（ERP），供应链管理（SCM）和客户关系管理（CRM）系统的企业范围的系统。
在这个发展过程中，企业对因特网的依赖已经使得公司的应用程序套件的网络延迟影响越来越明显。同时，用户（也就是客户）已经委托一定品质的服务质量保证相关的可用性、可靠性和响应时间以确保业务运转不被中断，并且依赖外部服务提供者来提供应用程序、因特网、网络，受管服务和其它服务。结果，SLA 变得更复杂，范围更广，一个用户可以有与不同提供者签定的几个 SLA。反过来，提供者自己的 SLA 也可以是与其它提供者签定的，每个 SLA 都有一套不同的需求、衡量标准和例外情况。
因特网（和企业内部网）的新方向提供了将来自不同来源（通过 Web 服务）的全异系统聚合并集成在一起的新方法和机会。随着不断扩展的分布式网络系统中提供者之间的关系变得更加复杂，Web 服务已经使 SLA 变得更富有挑战性。我们看到这些 SLA 不仅仅保证网络性能和正常运行时间可用性；由于每个 Web 服务都有不同的特征和网络需求，它们还被用来保证应用程序的性能。目前，一些 SLA 可以或者早已经作为公共 Web 服务公开了。
所有的 Web 服务都提供在 Web 上集成和修改系统组件的灵活性，以允许用户更改需求和在一定网络流量条件下处理网络资源争用。然而，这种灵活性要受到简单对象访问协议（Simple Object Access Protocol，SOAP）和统一描述、发现和集成（Universal Description and Discovery Integration，UDDI）互操作性问题的限制，因为一些主要厂商对这些协议的标准规范的解释是不同的。这意味着在把 Web 服务投入到生产环境和在 UDDI 或另一个公共注册中心将其作为公共服务发布之前，必须解决互操作性问题。对于 SLA 保证的 Web 服务（我们有时候称其为 SLA Web 服务）也是如此，不管该服务是独立的还是作为一套 Web 服务的一部分。后者的一个很好的示例是一个单独的 SLA，它适用于 Web 基础架构的每一段，从因特网到 Web 服务应用程序。
在进行进一步讨论之前，让我们来看一下 SLA 保证的 Web 服务的体系架构。这个体系架构，如下 图 1所示，需要三个服务角色：一个 服务提供者、一个 服务客户和一个 服务代理。通过在适当的平台上创建一个 Web 服务并生成 WSDL 文档和服务的基本 SLA ，服务提供者发布一个由 SLA 保证的 Web 服务。下一步，它把服务细节发送到服务代理以存储在资源库中。服务客户向代理注册，然后在代理的资源库中搜索并发现适当的 Web 服务，检索服务的 WSDL 和 SLA。然后它再与提供者协商把 SLA 正规化、确定下来并绑定到它的 Web 服务。
图 1. SLA 保证的 Web 服务的体系架构
必须监视任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服务描述语言（Web Service Description Language，WSDL）的由 SLA 保证的 Web 服务的可伸缩性和性能。在把 SLA 保证的 Web 服务投入到生产环境之前，必须解决所有的 SOAP、WSDL 和其它的互操作性问题。如果服务无法满足一定的标准，按照 SLA 的条款，提供服务的提供者可能要付财政责任，所以确保所有这些问题都在控制范围内特别重要。
在建立 SLA 保证的 Web 服务之前，应该使用测试机制 ― 比如来自 PushtoTest 的工具和脚本 ―（请参阅下面的 参考资料部分获得链接）来测试该 Web 服务的各种协议和组件。在启动服务后，这些测试工具可以充当 SLA 监视器。
表 1是一个核对表示例，当开发者测试一个将被 SLA 保证的服务时，他应该考虑这个表。
| 测试类型 | 问题 |
| 有状态 | 当您使用 SOAP 设置服务器值时，服务器在并发的状态下是否正确响应？ |
| 访问 | 一个未经授权的用户能成功访问只有经过授权的管理员才能使用的控制权吗？ |
| 响应时间 | Web 服务响应时是不是花费的时间太长（例如，超过了 10 秒）？ |
| 超时 | 当 Web 服务超时时会发生什么事情？ |
| 版本 | 新的构造会破坏现有 Web 服务的功能吗？ |
象任何协议或保险单一样，SLA 通常会指定其条款中的例外情况。Web 服务的 SLA 应该包含关于例外情况的详细信息。我将随意将它们分为四类：故障、不受服务提供者直接控制的网络问题、拒绝服务和预订的维护。表2说明了可以归入这些类别的某些特定情况。
只要客户公司可以得到当机期间的适当赔偿，还可以添加其它一些例外情况来适应提供者的情况。通过在 SLA 中包含进例外情况，提供者可以在出现问题或网络损耗时免负责任。另一方面，如果竞争的服务提供带有极少例外情况的 SLA，客户可以选择那些在业务运转中提供更长正常运行时间并且有更好的服务保障的协议。即使 99.5%、99.9% 和 99.999% 这几个正常运行时间可用性保证之间的差别也可以影响选择 SLA 的决策者。
| 类型 | 示例 |
| 故障 | 硬件故障（请注意，错误的硬件极少） 远程通信故障（例如，提供者无意切断了光缆线） 软件错误／缺陷 监视／测量系统故障 |
| 不受服务提供者直接控制的网络问题 | 主干对等端问题（例如，UUnet 在加利福尼亚的一个路由器坏了，拒绝因特网服务进入整个西海岸） DNS 不受服务提供者的直接控制 |
| 拒绝服务 | 客户疏忽／明知故犯 网络流量过大、黑客攻击和一般攻击 不可抗力、战争、罢工、电讯不可用、无法得到提供 SLA 所需的供给或设备。 |
| 预订的 维护 | 硬件升级 软件升级 备份 |
虽然 SLA 的重点是最大上载可用性和带宽的保证，但 SLA 无法为那些对延迟敏感的 Web 服务应用程序保证一致的响应时间。延迟是数据包从一个地点到另一个地点然后返回这一个来回所花费的时间（通常以毫秒计）。当数据包完成它的旅途花费的时间太长时就会发生延迟问题。例如，当 Web 服务产生的音频开始断断续续或者鼠标指针开始微微颤抖的时候，您就会注意到这些问题。
SLA 应该指定给定时间周期（假设一个月）内的平均来回延迟和数据报丢失。它应该把平均来回延迟定义为它在网络和其目的地之间的平均来回包传送，并把包丢失定义为在数据传送的来回时间内丢失包占总包数的百分比。协议应该把这种丢失限制到一定程度 ― 假设 1% 或更少 ― 如果在同意的时间段内这种丢失超过了这个程度还应该指定赔偿，包括偿还或退款。
目前为止，我已经说明了 SLA 保证的 Web 服务的技术参数。如果您计划为您的付费客户提供 Web 服务，他们通常都想要一个 SLA 以确保获得他们期望的投资回报。本文中讨论的主题应该会让您在准备自己的 Web 服务以满足 SLA 的需求方面处于领先地位。
本文并没有讨论可用于估量客户期望的各种工具；在真实的商界，您可以发现即便您的服务满足同意的服务品质，您的客户仍可能对服务不满意，因为技术上的服务交付能力还没有达到企业的期望。在这些情况下，客户和提供者必须就协议条款重新谈判以确定满足客户的服务品质。对于开发者，在创建和实现 Web 服务时记住这一点很重要。开发者必须既考虑客户的业务期望又考虑技术期望。
wiki中的解释如下：
Service level agreement
A service level agreement (frequently abbreviated as SLA) is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance. As an example, internet service providers will commonly include service level agreements within the terms of their contracts with customers to define the level(s) of service being sold in plain language terms. In this case the SLA will typically have a technical definition in terms of Mean Time Between Failures (MTBF), Mean Time to Repair or Mean time to recovery (MTTR); various data rates; throughput; jitter; or similar measurable details.
Contents[hide] |
[edit]Overview
A service level agreement is a negotiated agreement between two parties wherein one is the customer and the other is the service provider. This can be a legally binding formal or an informal "contract" (for example, internal department relationships). Contracts between the service provider and other third parties are often (incorrectly) called SLAs — because the level of service has been set by the (principal) customer, there can be no "agreement" between third parties; these agreements are simply a "contract." Operating Level Agreements or OLAs, however, may be used by internal groups to support SLAs.
The SLA records a common understanding about services, priorities, responsibilities, guarantees, and warranties. Each area of service scope should have the "level of service" defined. The SLA may specify the levels of availability, serviceability, performance, operation, or other attributes of the service, such as billing. The "level of service" can also be specified as "target" and "minimum," which allows customers to be informed what to expect (the minimum), while providing a measurable (average) target value that shows the level of organization performance. In some contracts, penalties may be agreed upon in the case of non-compliance of the SLA (but see "internal" customers below). It is important to note that the "agreement" relates to the services the customer receives, and not how the service provider delivers that service.
SLAs commonly include segments to address: a definition of services, performance measurement, problem management, customer duties, warranties, disaster recovery, termination of agreement.[1]
SLAs have been used since late 1980s by fixed line telecom operators as part of their contracts with their corporate customers. This practice has spread such that now it is common for a customer to engage a service provider by including a service level agreement in a wide range of service contracts in practically all industries and markets. Internal departments (such as IT, HR, and real estate) in larger organizations have adopted the idea of using service-level agreements with their "internal" customers — users in other departments within the same organization. One benefit of this can be to enable the quality of service to be benchmarked with that agreed to across multiple locations or between different business units. This internal benchmarking can also be used to market test and provide a value comparison between an in-house department and an external service provider.
Service level agreements are, by their nature, "output" based — the result of the service as received by the customer is the subject of the "agreement." The (expert) service provider can demonstrate their value by organizing themselves with ingenuity, capability, and knowledge to deliver the service required, perhaps in an innovative way. Organizations can also specify the way the service is to be delivered, through a specification (a service level specification) and using subordinate "objectives" other than those related to the level of service. This type of agreement is known as an "input" SLA. This latter type of requirement is becoming obsolete as organizations become more demanding and shift the delivery methodology risk on to the service provider.
[edit]Service level agreements at different levels
SLAs are also defined at different levels:
- Customer-Based SLA: An agreement with an individual customer group, covering all the services they use. For example, an SLA between a supplier (IT service provider) and the finance department of a large organization for the services such as finance system, payroll system, billing system, procurement/purchase system, etc.
- Service-Based SLA: An agreement for all customers using the services being delivered by the service provider. For example:
- A car service station offers a routine service to all the customers and offers certain maintenance as a part of offer with the universal charging.
- A mobile service provider offers a routine service to all the customers and offers certain maintenance as a part of offer with the universal charging
- An email system for the entire organization. There are chances of difficulties arising in this type of SLA as level of the services being offered may vary for different customers (for example, head office staff may use high-speed LAN connections while local offices may have to use a lower speed leased line).
- Multilevel SLA: The SLA is split into the different levels, each addressing different set of customers for the same services, in the same SLA.
- Corporate Level SLA: Covering all the generic service level management (often abbreviated as SLM) issues appropriate to every customer throughout the organization. These issues are likely to be less volatile and so updates (SLA reviews) are less frequently required.
- Customer Level SLA: covering all SLM issues relevant to the particular customer group, regardless of the services being used.
- Service Level SLA: covering all SLM issue relevant to the specific services, in relation to this specific customer group.
[edit]Common metrics
Service level agreements can contain numerous service performance metrics with corresponding service level objectives. A common case in IT service management is a call center or service desk. Metrics commonly agreed to in these cases include:
- ABA (Abandonment Rate): Percentage of calls abandoned while waiting to be answered.
- ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be answered by the service desk.
- TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g., 80% in 20 seconds.
- FCR (First-Call Resolution): Percentage of incoming calls that can be resolved without the use of a callback or without having the caller call back the helpdesk to finish resolving the case.
- TAT (Turn-Around Time): Time taken to complete a certain task.
Uptime is also a common metric, often used for data services such as shared hosting, virtual private servers and dedicated servers. Common agreements include percentage of network uptime, power uptime, number of scheduled maintenance windows, etc.
Many SLAs track to the Information Technology Infrastructure Library specifications when applied to IT services.
[edit]Specific examples
[edit]Backbone Internet providers
It is not uncommon for an Internet backbone service provider (or network service provider) to explicitly state its own service level agreement on its Web site.[2][3][4] The Telecommunications Act of 1996 does not expressly mandate that companies have SLAs, but it does provide a framework for firms to do so in Sections 251 and 252.[5] Section 252(c)(1) for example (“Duty to Negotiate”) requires that ILECs negotiate in good faith regarding things like resale, access to rights-of-way, and so forth.
[edit]WSLA
A web service level agreement (WSLA) is a standard for service level agreement compliance monitoring of web services. It allows authors to specify the performance metrics associated with a web service application, desired performance targets, and actions that should be performed when performance is not met.
WSLA Language Specification, version 1.0 was published by IBM on January 28, 2001.
[edit]Cloud computing
Cloud computing (alternatively, grid computing or service-oriented architecture) uses the concept of service level agreements to control the use and receipt of computing resources from, and by, third parties.
Any SLA management strategy considers two well-differentiated phases: the negotiation of the contract and the monitoring of its fulfilment in real-time. Thus, SLA Management encompasses the SLA contract definition: basic schema with the QoS (quality of service) parameters; SLA negotiation; SLA monitoring; and SLA enforcement—according to defined policies.
The main point is to build a new layer upon the grid, cloud, or SOA middleware able to create a negotiation mechanism between providers and consumers of services.[6] An example is the European Union–funded Framework 7 research project, SLA@SOI,[7] which is researching aspects of multi-level, multi-provider SLAs within service-oriented infrastructure and cloud computing.
The underlying benefit of cloud computing is shared resources, which is supported by the underlying nature of a shared infrastructure environment. Thus, service level agreements span across the cloud and are offered by service providers as a service based agreement rather than a customer based agreement. Measuring, monitoring and reporting on cloud performance is based upon an end user experience or the end users ability to consume resources. The downside of cloud computing, relative to SLAs, is the difficultly in determining root cause for service interruptions due to the complex nature of the environment.
[edit]Outsourcing
Outsourcing involves the transfer of responsibility from an organization to a supplier. The management of this new arrangement is through a contract that may include a service level agreement. The contract may involve financial penalties and the right to terminate if SLAs metrics are consistently missed. Setting, tracking, and managing SLAs is an important part of the Outsourcing Relationship Management (ORM) discipline. It is typical that specific SLAs are negotiated up front as part of the outsourcing contract, and they are utilized as one of the primary tools of outsourcing governance.
有时间再翻译，反正英文也能看懂。
