為雲計算開發討標準化SLA的最佳實踐

此外，雲供應商還必須評估自身與供應商、企業資料中心、HTTP://www.aliyun.com/zixun/aggregation/35930.html">網路供應商和內容提供者之間的關係和 SLA。 有很多需要注意的考慮事項。 在本文中，作者將探討標準化 SLA 的最佳實踐。

TM Forum 將 SLA 定義為雙方或多方之間有關服務品質、優先順序和責任的預期。 Cloud Standards Customer Council 則將雲 SLA 視為雲計算使用者和供應商之間對服務的書面預期。 在評估雲電腦供應商方面，以及在對比最終使用者 SLA 時有何預期和需要注意哪些內容方面，它為決策者提供了指導。 決策者還應評估雲計算供應商與供應商、企業資料中心、網路供應商和內容提供者之間具有的 SLA。

當 SLA 是由重大的重組、裁員、服務整合或是向某個雲服務環境的過渡驅動時，SLA 並不是強制的。 它並未擁有來自所涉及的所有相關方的輸入。

SLA 不是一個單方向的解決方案。 一方（比如，雲服務提供者）不應自行決定事情如何完成，在另一方（比如，雲服務使用者）對 SLA 如何制定有不同意見時尤為如此。

SLA 不是一個快速的解決方案。 如果急於推進 SLA 內的條件和條款的談判過程，就無法為各方留下足夠多的時間來理解其他方的預期，尤其在各方對某個術語的意思存不同的理解時。

作者在 SLA 方面的親身體驗

幾年前，developerWorks 發表了我的一個有關 SLA 的文章系列，該系列共有 7 個部分。 後來，美國一個主要的聯邦機構的 Web 服務和麵向服務架構的主管聯繫到我。 他喜歡我的這篇文章 在 Web 服務上下文中使用 SLA，第 7 部分: 用 SLA 保證來降低漏洞的風險。 這篇文章談到了中斷閾值決定了能否將企業從徹底的服務拒絕（DoS）和關鍵系統資產的破壞中拯救出來，以及中斷閾值對 SLA 保證的影響有多大。

在與這位機構主管取得聯繫時，我提到了該系列中的另一篇文章 用 SLA 保證 Web 服務。 在這篇文章中，我談到了在公開服務之前可用來測試 Web 服務特性的 6 種測試類型：

我還提及了 SLA 內可能包含的一些例外：

這位機構主管邀請我去做一次演講，並與他的團隊做一次系統工程方面的討論。 在我的演講中，我闡述了上述所有的要點，還介紹了 SLA 內的退出條款的重要性。 這一條款能夠讓使用者在所承諾的保證多次無法滿足時從該 SLA 退出。

在評論了我的陳述的觀點之後，這位主管發給我一份其機構的 SLA 範本讓我評閱，並請我幫忙制定此範本的第一版以及後續版本。 （出於保密的原因，我不能在此討論其中的細節。 ）它最終成為了聯邦系統的一部分。

這一 SLA 範本可以擴展到所有基於雲的服務。 不管提供的是哪種類型的服務：Web 服務、雲服務和網路接入服務，所有的 SLA 關乎的都是服務保證。 如果服務保證無法滿足就要施以罰責。 所保證的服務的水準在各合作夥伴間是不同的。

並不是所有的 Web 服務（比如一個基於雲的 SOA 應用程式）都是基於雲的。 SOA 是一個設計模式，通過 Web 服務標準由鬆散耦合的、可發現的、可重用的、可交互操作的平臺無關的服務組成。 SaaS 是一個使用模型；它使用由雲服務提供者託管的資源。 SOA 是一個設計模型，在該模型中，對使用者是誰沒有任何限制。