對這文章發表回應
發表限制: 非會員 可以發表
雲端服務品質不卡住？連 Google、微軟都在用的 SLA 你不能不懂！
「資料庫又連不上了啦，是不是網路有問題……」
「MIS 說沒辦法處理啦，已經打電話給系統廠商了……」
「那廠商什麼時候會來？」
「廠商說公司裡沒有人可以馬上來處理……」
以上的情境描述是否有些熟悉呢？這樣的對話，在沒有專職資訊部門的中小企業裡，司空見慣。
數位化工具愈來愈多，每半年一變，對很多中、小企業來說，建置自有的資訊部門不見得是最划算的作法，應用雲端服務可以降低營運成本、增加系統與業務的彈性和擴充性，市場上愈來愈多針對中小企業推出的雲端服務，就是看準這個需求因應而生。
但是，這些應用新服務的中、小企業對技術服務的理解不足，常常連自己需要的服務 KPI 都列不出來，當服務品質出現問題時，完全沒有能力和服務供應商協商改善方式。
為了避免這種情況，中、小企業可以選定適合的評選標準流程幫助自己跨過專業知識不足的門檻。「服務層級協定」（Service Level Agreement，SLA） 就是一套評選供應商的標準作法。很多雲端服務商 Google、微軟的服務條款中，都應用 SLA 的標準作法來訂定服務準則。
- SLA，可以協助買賣雙方就彼此所需達成有效共識
SLA 是服務供應商與客戶之間就服務品質、服務水準以及效能等訂定的協議或契約。內容包含服務品質的定義、權利義務的歸屬、服務目標 (Service Level Objective，SLO) 以及雙方的預期和責任定義。主要是用來保障客戶使用服務後的權利，也做為供應商服務收費的依據。
為了能夠客觀地評估服務水準，雲端服務一般把「能夠提供服務的時間」稱為 Uptime 或 Web Availability。這是指能夠連續不中斷服務的程度，一般以整個月的日數乘以 24 小時為 100%。事實上，在實務中難免會有臨時事件的產生，像主機的服務，免不了為了規劃中的維修保養問題而停機，此時，供應商就會提供 99% 或 99.9% 的連續服務，若低於這個數值，依差異的多寡，給予客戶補償。
「無法提供服務的時間」稱為 Downtime，而服務層級通常是以「一定時間內（例如，一個月或是一年）的 Uptime 百分比」來表示，也就是：
服務層級 ＝ uptime（小時）／ 一定期間（月／年）* 100%
SLA 文件架構一般包含三個部分
1. 服務管理：指服務提供過程中需要進行的技術管理、流程管理與溝通管理。
2. 權利義務歸屬：用來確認服務遞送過程中雙方的責任歸屬，提供具法律效力的服務關係建構內容。
3. 服務／技術衡量基準：做為上述服務管理與權利義務歸屬判斷的基準參考。
- SLA 裡常用的服務關鍵績效指標包括 10 個項目：
1. 系統可用性（System Availability）：客戶使用系統正常運作率會達到 X% 以上，一般以月份為基準單位進行度量。
2. 系統回復性（System Recovery）：系統中斷時會在 X 小時內回復正常運作，系統資料會復原到發生中斷前 X 小時內的狀態。
3. 系統回應時間（System Response）：系統反應時間不會超過 X 秒。
4. 網路服務品質（Quality of Service，QoS）：封包遺失比率（Packet Loss） < X%、封包發送延遲時間（Latency） < X 毫秒（ms）、封包發送延遲時間變異數（Jitter） < X 毫秒（ms）等。
5. 問題回應時間（Incident Response）：系統發生問題後於X 分鐘內回應，一般會將問題區分為不同優先等級，並設定不同的回應時間標準。
6. 問題解決時間（Incident Resolution）：系統發生問題後於 X 小時內解決，一般會將問題區分為不同優先等級，並設定不同的解決時間標準。
7. 平均故障時間（Mean Time to Failure；MTTF）：指工作系統直到發生故障失效的期望時間，這表示此系統僅能失效一次且不可修復，對於不可修復的系統而言，MTTF 為系統可靠度中極為重要的指標。
8. 平均修復時間（Mean Time To Repair；MTTR）：描述系統從故障狀態轉為工作狀態的平均修理時間。MTTR 越短，表示恢復性越好。
9. 平均故障間隔時間（Mean Time Between Failures；MTBF）：指可修復系統兩次相鄰故障之間的平均時間值。MTBF 越長，系統的可靠性越高，工作能力越強。
10. 客服支援時段：明確訂定出支援小組可提供服務的方式和時段，例如，周一到周五上午 9:00 至下午 18:00。
- 最重要的是擬定可執行且有效的賠償政策
除了保證服務水準之外，供應商也必須擬定賠償政策，也就是當供應商的服務發生中斷造成客戶損失時應如何處理，也就是當沒有達到承諾的技術指標時，供應商會提供服務賠償金。一般中斷時間愈久賠償愈多，且依據用戶所支付的服務費用計算，範圍約在 5% 至 100%。
賠償申請與舉證責任通常落在客戶端，若要申請賠償必須需要提供服務中斷的確切資訊，並等供應商確認違反 SLA 才會賠償。
- Google 和微軟的SLA政策怎麼訂？
SLA 在業界應用普遍，我們來看看 Google 如何訂定 SLA。
在 Google Apps 服務水準協議 中載明，「Google Apps 涵蓋服務」的網頁介面每月至少需要有 99.9% 的時間正常提供「客戶」操作與使用」。如果 Google 無法達到「Google Apps SLA」保證，而「客戶」確實履行「Google Apps SLA」所規定的義務，「客戶」即有資格索取下方所述的「服務點數」。當 Google 無法達到「Google Apps SLA」保證時，「客戶」唯一可以使用的專屬補救措施即以「Google Apps SLA」所述者為限。
「服務點數」定義如下：
最後，還要注意的是「除外情形」，例如，「Google Apps SLA 的排除情況」就指出：
「Google Apps SLA」不適用於任何明確排除「Google Apps SLA」的服務，也不適用於因為下述因素而引起的效能問題：(1)「協議」的「不可抗力」一節所述的因素；或是 (2)「客戶」設備、第三方設備或前述兩者 (Google 並非這類設備的主要控制者) 所導致者。
類似的情形，MicroSoft的「Microsoft SQL Azure SLA除外情況」的作法有些不同：
此 SLA 以及任何適用之「服務等級」，並不適用於任何符合下列敘述之效能或可用性問題：
1. 基於 Microsoft 合理控制範圍以外之因素；
2. 因使用非 Microsoft 隨附於 SQL Azure 所提供之硬體而導致；
3. 因「客戶」或第三方採取之行動或未採取行動而導致；
4. 在 Microsoft 建議「客戶」修改其「服務」使用方式之後，若「客戶」未依 照建議修改其使用方式，繼續使用「服務」而導致；
5. 歸因於「客戶」，或「客戶」之員工、代理商、承包商或供應商，或任何利用「客戶」之密碼或設備取得 Microsoft「服務」存取權限者的行為或疏忽；
6. 或者處於 Beta 測試與試用「服務」期間（由 Microsoft 決定）。
若看到「除外情形」一定要慎重考慮在這些特殊狀況下，彼此應該負擔的責任歸屬與處理問題。
（資料來源： Google Apps 服務水準協議、 雲端服務應用之服務水準與使用協定先期研究報告、 Microsoft SQL Azure SLA除外情況；圖片來源： k0a1a.net, CC Licensed）
原文出處：雲端服務品質不卡住？連 Google、微軟都在用的 SLA 你不能不懂！ | TechOrange