服務品質協議（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 保證 Web 服務

因特網（和企業內部網）的新方向提供了將來自不同來源（通過 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 服務應用程序。

為現實世界做準備：測試機制

必須監視任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服務描述語言（Web Service Description Language，WSDL）的由 SLA 保證的 Web 服務的可伸縮性和性能。在把 SLA 保證的 Web 服務投入到生產環境之前，必須解決所有的 SOAP、WSDL 和其它的互操作性問題。如果服務無法滿足一定的標準，按照 SLA 的條款，提供服務的提供者可能要付財政責任，所以確保所有這些問題都在控制范圍內特別重要。

在建立 SLA 保證的 Web 服務之前，應該使用測試機制 ― 比如來自 PushtoTest 的工具和腳本 ―（請參閱下面的 參考資料部分獲得鏈接）來測試該 Web 服務的各種協議和組件。在啟動服務后，這些測試工具可以充當 SLA 監視器。

表 1是一個核對表示例，當開發者測試一個將被 SLA 保證的服務時，他應該考慮這個表。

表 1. 在發布一個服務之前應該測試的 Web 服務功能

潛在問題

雖然 SLA 的重點是最大上載可用性和帶寬的保證，但 SLA 無法為那些對延遲敏感的 Web 服務應用程序保證一致的響應時間。延遲是數據包從一個地點到另一個地點然后返回這一個來回所花費的時間（通常以毫秒計）。當數據包完成它的旅途花費的時間太長時就會發生延遲問題。例如，當 Web 服務產生的音頻開始斷斷續續或者鼠標指針開始微微顫抖的時候，您就會注意到這些問題。

SLA 應該指定給定時間周期（假設一個月）內的平均來回延遲和數據報丟失。它應該把平均來回延遲定義為它在網絡和其目的地之間的平均來回包傳送，并把包丟失定義為在數據傳送的來回時間內丟失包占總包數的百分比。協議應該把這種丟失限制到一定程度 ― 假設 1% 或更少 ― 如果在同意的時間段內這種丟失超過了這個程度還應該指定賠償，包括償還或退款。

1 Overview

• 3 Common metrics

• 4.1 Backbone Internet providers

• 4.3 Cloud computing

• 5 See also

• 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