幾乎所有的云計算用戶都認為服務水平協議(SLA)對云來說很重要，但是大多數用戶都承認他們沒有執行任何加強SLA的措施。沒有正確的考量和工具，即便是一個好的SLA都有可能失敗，因為你不會知道它已經被違反或者原因是什么。要做出正確的云計算SLA決策，你需要將你的云劃分成責任區域，使用分析工具來設置應用的行為基準條件，并將SLA故障當作一個有自身流程的“項目”來處理。
劃分云責任區域
云計算SLA挑戰之一是，云應用交付的體驗是三個或更多個實體的性能總和。搞清楚到底哪一個可能會引起問題是一大挑戰，所以在為云創建一個SLA決策框架時的首要任務是建立一個簡單的實體圖，顯示云服務的每一部分都是由誰來提供的，又會傳輸到何處。
一個典型的云應用從提供用戶連接的用戶自有設備開始。它可以是一個移動設備或者是整個公司網絡。云應用從用戶提供的這一組件通過WAN，通常是互聯網，連接到云提供商的基礎設施。一些用戶使用VPN服務從固定地點訪問云，而其他人可能擁有多個云服務供應商，因此在你的云里可能會有比這三個標準的責任區域更多的責任區域。
云應用產生橫跨這些區域的工作流，對于每種運行的云應用你會想了解這種活動究竟是如何發生的。你可以基于應用的名字說出這些工作流是如何滿足其用戶的需求。此工作流是你的SLA決策的基礎。
為了獲得良好的SLA管理和政策決定，你需要衡量每一個供應商在你的應用云區域內的行為。你應該始終從衡量響應時間的機制開始，再到測量區域邊界點條件。
端到端響應時間的測量最好在用戶連接的時候進行，這樣你可以獲得完整的響應時間。在某些情況下，這意味著將響應時間監控構建到應用里，盡管通常一個設備的TCP/IP軟件可以通過一個管理接口提供一些數據。
對于區域邊界監測任務，某些形式的流量或協議監控可能是最好的選擇。這些工具在網絡的各個地方放置探測器，軟件工具或硬件，它們可以通過一個中央管理控制臺，使用深度包檢測來對應用進行梳理，以查看數據包流量。
避免網絡分析陷阱
用戶在這一點上會犯的一個很大的錯誤是變得越來越注重監測本身而不知道什么才是好的和壞的。網絡管理系統(NMS)可以自動收集在一個數據存儲庫里的數據(例如OpenNMS)。該數據集合允許你運行一個查詢來分析一段時間內的性能和條件，并設置正常行為的基準以及你認為會違反SLA的閾值。如果你的管理系統沒有提供一個數據存儲庫，你需要添加網絡分析工具來收集和關聯管理數據并設置你的性能基準。
網絡分析可以為圍繞云計算服務水平協議的決定奠定堅實的基礎。確保工具有將從云管理系統API獲得的性能數據添加到你自己的NMS獲得的網絡數據的功能。如果你有一個VPN或一個擁有大數據中心的混合云，它甚至可以智能的首先開始在你的主網絡廠商里選擇可能的工具。這些對維護你的IT和網絡基礎設施的性能頗有助益，也有助于管理基于云SLA的決策。
當然，這一切最后都歸結到如何檢測SLA故障。一個好的系統為云計算SLA的決策過程提供三種輸入。一種是主觀的用戶對于性能不佳的報告;第二種是一個檢測到的一個或多個應用的端到端的響應時間問題;第三種是在一個區域邊界的特定問題報告。在任何情況下，你應該先評估該問題的影響，然后再定位可能的原因。
你的工作流程區域地圖會讓你看出這是否是幾個應用在一個區域邊界點的一個普遍問題，還是只有某一個應用的問題在前一種情況下，你可能遇到的是網絡或云基礎設施的問題，在第二種情況下可能是云應用本身的問題。對于第一種情況，你需要使用監控工具來檢查受影響的工作流的所有區域邊界，看看問題到底出在哪里。這個問題應表現為兩個區域邊界點之間更長的延遲或一個區域內的包丟失。你的流量探測器通常都可以確認其中任何一種故障。
以項目的方式來處理云計算SLA決策
如果發生問題，那么修復的過程應該被視為一個小項目，配備一個項目經理和一組固定的任務集，通常稱為升級程序。有些用戶甚至會使用簡單的軟件項目管理或故障跟蹤工具來追蹤從發現問題到解決云計算SLA問題的整個過程。有時候可以使用那些用于軟件項目的故障跟蹤工具，還可以使用某些包括故障跟蹤選項的網絡分析工具。
要讓云計算SLA以及它提供的服務能夠成功，采取有組織的方式和作出加強的決策是至關重要的。如果你在開始審議時就計劃支持SLA決策，那么你會在整體上獲得更好的業務體驗。除非你能按照一個小項目的方式來處理云計算服務水平協議的過程，否則云計算SLA將會失敗。專家Tom Nolle提供給我們3個步驟來創建一個有效的云SLA。
京公網安備 11010502049343號