SLA介紹

本文轉載至IBM

[b]介紹：什麼是 SLA？[/b]
服務品質協議（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 應該爲客戶包含進一個退出條款；當因爲不能圓滿解決經常發生的可用性、可靠性和安全性問題而使客戶的業務運轉頻繁中斷時，客戶希望他有終止協議的權利。

[b]SLA 的發展[/b]
SLA 已經出現了一段時間了。在二十世紀六十年代，它們是用於達到已定義的服務品質和響應服務問題的一般操作程序，而這些服務問題是用戶組織在購買或租用大型機上的機器時間時就已經同意過的。 超大型計算機（big iron）是缺省的企業系統，其它任何技術的處理能力都無法與它相比。
當客戶機／服務器和網絡桌面系統進入計算機世界時，人們就構思出了分佈式網絡系統這個概念。這些系統後來發展成了跨網絡運行企業資源規劃（ERP），供應鏈管理（SCM）和客戶關係管理（CRM）系統的企業範圍的系統。
在這個發展過程中，企業對因特網的依賴已經使得公司的應用程序套件的網絡延遲影響越來越明顯。同時，用戶（也就是客戶）已經委託一定品質的服務質量保證相關的可用性、可靠性和響應時間以確保業務運轉不被中斷，並且依賴外部服務提供者來提供應用程序、因特網、網絡，受管服務和其它服務。結果，SLA 變得更復雜，範圍更廣，一個用戶可以有與不同提供者簽定的幾個 SLA。反過來，提供者自己的 SLA 也可以是與其它提供者簽定的，每個 SLA 都有一套不同的需求、衡量標準和例外情況。

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

[b]SLA Web 服務體系架構[/b]
在進行進一步討論之前，讓我們來看一下 SLA 保證的 Web 服務的體系架構。這個體系架構，如下 圖 1所示，需要三個服務角色：一個 服務提供者、一個 服務客戶和一個 服務代理。通過在適當的平臺上創建一個 Web 服務並生成 WSDL 文檔和服務的基本 SLA ，服務提供者發佈一個由 SLA 保證的 Web 服務。下一步，它把服務細節發送到服務代理以存儲在資源庫中。服務客戶向代理註冊，然後在代理的資源庫中搜索並發現適當的 Web 服務，檢索服務的 WSDL 和 SLA。然後它再與提供者協商把 SLA 正規化、確定下來並綁定到它的 Web 服務。


[img]http://dl.iteye.com/upload/attachment/465412/22736235-2a75-371a-9afd-713900daa9a2.gif[/img]

[b]爲現實世界做準備：測試機制[/b]
必須監視任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服務描述語言（Web Service Description Language，WSDL）的由 SLA 保證的 Web 服務的可伸縮性和性能。在把 SLA 保證的 Web 服務投入到生產環境之前，必須解決所有的 SOAP、WSDL 和其它的互操作性問題。如果服務無法滿足一定的標準，按照 SLA 的條款，提供服務的提供者可能要付財政責任，所以確保所有這些問題都在控制範圍內特別重要。
在建立 SLA 保證的 Web 服務之前，應該使用測試機制 ― 比如來自 PushtoTest 的工具和腳本 ―（請參閱下面的 參考資料部分獲得鏈接）來測試該 Web 服務的各種協議和組件。在啓動服務後，這些測試工具可以充當 SLA 監視器。


[b]潛在問題[/b]
雖然 SLA 的重點是最大上載可用性和帶寬的保證，但 SLA 無法爲那些對延遲敏感的 Web 服務應用程序保證一致的響應時間。延遲是數據包從一個地點到另一個地點然後返回這一個來回所花費的時間（通常以毫秒計）。當數據包完成它的旅途花費的時間太長時就會發生延遲問題。例如，當 Web 服務產生的音頻開始斷斷續續或者鼠標指針開始微微顫抖的時候，您就會注意到這些問題。
SLA 應該指定給定時間週期（假設一個月）內的平均來回延遲和數據報丟失。它應該把平均來回延遲定義爲它在網絡和其目的地之間的平均來回包傳送，並把包丟失定義爲在數據傳送的來回時間內丟失包占總包數的百分比。協議應該把這種丟失限制到一定程度 ― 假設 1% 或更少 ― 如果在同意的時間段內這種丟失超過了這個程度還應該指定賠償，包括償還或退款。


[b]結束語[/b]
目前爲止，我已經說明了 SLA 保證的 Web 服務的技術參數。如果您計劃爲您的付費客戶提供 Web 服務，他們通常都想要一個 SLA 以確保獲得他們期望的投資回報。本文中討論的主題應該會讓您在準備自己的 Web 服務以滿足 SLA 的需求方面處於領先地位。
本文並沒有討論可用於估量客戶期望的各種工具；在真實的商界，您可以發現即便您的服務滿足同意的服務品質，您的客戶仍可能對服務不滿意，因爲技術上的服務交付能力還沒有達到企業的期望。在這些情況下，客戶和提供者必須就協議條款重新談判以確定滿足客戶的服務品質。對於開發者，在創建和實現 Web 服務時記住這一點很重要。開發者必須既考慮客戶的業務期望又考慮技術期望。