對您的云計算服務進行評估并編寫SLA要比為簡單連接服務(如虛擬專用網VPN)制定SLA要復雜得多。為了正確評估云計算SLA，應了解云計算體驗的細節以及實際上是由誰來提供它們。尋找應用程序的工作流程，因為關鍵應用程序問題可以毀了一個很好的SLA。此外，要確定你有一個實際可行有效的驗證和補救方法。
公共云計算服務在其范圍內提供了令人難以置信的靈活性和效率，但是其廣度范圍取決于服務成本、可用性以及性能。這提供了評估云計算SLA中常見錯誤和最佳實踐的信息。其涵蓋內容包括響應時間SLA、從網絡供應商和云計算供應商處獲得保證，混合云計算SLA問題等等。
遵循應用程序的工作流程
云計算服務買家對于云計算SLA的最關鍵錯誤是忘記所有應用程序都是真正的工作流程。一個通過網絡連接從用戶發向應用程序的請求通常是由多個組件組成的。然后，該請求會導致產生流向其他組件的工作——在云計算內的或者返回數據中心的——以及對位于云計算內外數據庫的多次訪問。最終，通過網絡向用戶返回響應結果。
如果SLA只關注于這一過程中的某一點(例如與公共云計算托管相關的一部分)，那么SLA是沒有用的。如果這一工作流程的任意部分中斷，那么應用程序就會發生故障。如果這一流程中的任何部分發生性能問題，那么應用程序的使用體驗質量就會受到影響。當其他環節只是得到籠統的保證時，那么只是針對云計算內性能或可用性的嚴格要求是沒有任何好處的。
讓所有參與者都確保SLA
評估云計算SLA的另一個問題是無法讓所有相關參與者都確保SLA。云計算工作流程通常涉及三方——企業本地自有網絡的員工、讓員工訪問云計算的網絡供應商以及云計算供應商。具體可能還涉及企業的數據中心(網絡與托管)和提供“云計算至數據中心”連接的另一家網絡供應商。供應商通常不會撰寫或接受用于處理他們所不涉及工作流程環節的SLA。你需要讓他們同意成為他們為此收取一定費用的“主要承包商”或者為所涉及的每一方得到或編寫一份SLA。
通常SLA中的最大問題是網絡連接問題，因為在大多數情況下，除了在云計算本身內部的情況外，云計算供應商是不會提供網絡服務。如果你希望嚴格的SLA，那么你將需要為網絡服務編制一份SLA。所以，你應當首先確認你的云計算供應商是否會提供一個VPN或者他們是否能夠與你所使用VPN服務的供應商進行協作。在很多情況下，你仍然需要使用互聯網來實現用戶的連接性，但是VPN將為你提供一個你希望獲得保證的堅實網絡邊界。
思考混合云計算工作流程
混合云計算中的“邊界交叉”也會產生SLA問題。工作流程遵循應用程序和業務邏輯確定的路徑，如果這些路徑在數據中心和云計算之間形成了多個可變交叉，那么就出現了性能與可用性風險。當確保性能或可用性時，你的云計算供應商是無法觸及工作流程模式的移動目標的，因此應試圖確保你不會在你希望公司保證的工作流程中引入明顯的變量。如果你無法做到這一點，那么你將不得不撰寫一份非常詳細復雜的SLA來解決所有的變量，而且很多供應商根本就不會接受它。
定義云計算SLA的邊界
SLA中的最后一個問題就是違規行為的檢測，以及處罰和補救程序。一般而言，你或者你的云計算供應商或者其他的網絡合作方都不會根據其中某一方的參數測量結果來接受一份SLA。好的SLA會在各方都同意的基礎上定義一個邊界測量點供獨立測量使用，從而進行狀態驗證。你自己的SLA應確定這些點、將進行的測量以及用于確定是否違反SLA的被測條件。
通常，包交換網絡和云計算服務的可用性和性能違反都是基于一個相當長的報告期的——即每周或月的停用情況。所以最好采用“停機間隔時間”這樣的協議而不是簡單的故障次數，因為后者無法涉及平均修復時間。響應時間SLA也是很難成文的，因為我們很難正確地測量響應時間。如果你的SLA中包括有響應時間，那么就需要花時間來讓雙方確定將如何對響應時間進行測量。
補救或處罰始終是一個棘手的事。很多用戶認為，如果發生SLA違反(也就是通常所謂的間接傷害)，那么他們就可以根據業務損失得到賠償。這種情況是極少發生而且代價昂貴的;與其試圖通過談判來兌現這一協議，還不如花功夫想辦法讓你的應用程序具有更高的可用性。
用戶報告說，SLA中最有用的處罰是一個自動升級條款。如果發生SLA故障，應向供應商運營中心報告這一故障。如果在規定時間沒有解決這個問題，或者故障發生頻率超過了某一閾值，那么就應向供應商的管理鏈發送這一故障通知——讓更高層人員來負責檢查問題并親自與你聯系討論狀態更新和補救措施。這一條款可確保高級管理人員能夠關注你的問題，從而提高問題解決的概率。
對于SLA 中的經濟處罰，應將處罰金額限于在中斷期間服務成本以下作為基線，如果中斷情況嚴重，那么可加上整個測量間隔服務成本。你是否有機會得到這樣一個懲罰性條款將取決于你的合同規模以及你成為供應商未來客戶的潛力。
京公網安備 11010502049343號