前言

SLO和SLA是大家常見的兩個名詞：服務等級目標和服務等級協議。

雲端計算時代，各大雲服務提供商都發布有自己服務的SLA條款，比如Amazon的EC2和S3服務都有相應的SLA條款。這些大公司的SLA看上去如此的高達上，一般是怎麼定義出來的呢？本文就嘗試從技術角度解剖一下SLA的制定過程。

說SLA不能不提SLO，這個是眾所周知的，但是還有一個概念知道的人就不多了，那就是SLI（Service Level Indicator），定義一個可執行的SLA，好的SLO和SLI是必不可少的。

再有就是SLI/SLO/SLA都是和服務聯絡在一起的，脫離了服務這三個概念就沒有什麼意義了。

Service

什麼是服務？

簡單說就是一切提供給客戶的有用功能都可以稱為服務。

服務一般會由服務提供者提供，提供這個有用功能的組織被稱為服務提供者，通常是人加上軟體，軟體的執行需要計算資源，為了能對外提供有用的功能軟體可能會有對其他軟體系統的依賴。

客戶是使用服務提供者提供的服務的人或公司。

SLI

SLI是經過仔細定義的測量指標，它根據不同系統特點確定要測量什麼，SLI的確定是一個非常複雜的過程。

SLI的確定需要回答以下幾個問題：

1. 要測量的指標是什麼？
2. 測量時的系統狀態？
3. 如何彙總處理測量的指標？
4. 測量指標能否準確描述服務質量？
5. 測量指標的可靠度(trustworthy)？

1. 常見的測量指標有以下幾個方面：

• 效能
  • 響應時間(latency)
  • 吞吐量(throughput)
  • 請求量(qps)
  • 實效性(freshness)
• 可用性
  • 執行時間(uptime)
  • 故障時間/頻率
  • 可靠性
• 質量
  • 準確性(accuracy)
  • 正確性(correctness)
  • 完整性(completeness)
  • 覆蓋率(coverage)
  • 相關性(relevance)
• 內部指標
  • 佇列長度(queue length)
  • 記憶體佔用(RAM usage)
• 因素人
  • 響應時間(time to response)
  • 修復時間(time to fix)
  • 修復率(fraction fixed)

下面通過一個例子來說明一下：

• 錯誤率(error rate)計算的是服務返回給使用者的error總數
• 如果錯誤率大於X%，就算是服務down了，開始計算downtime
• 如果錯誤率持續超過Y分鐘，這個downtime就會被計算在內
• 間斷性的小於Y分鐘的downtime是不被計算在內的。

2. 測量時的系統狀態，在什麼情況下測量會嚴重影響測量的結果

• 測量異常(badly-formed)請求，還是失敗(fail)請求還是超時請求(timeout)
• 測量時的系統負載（是否最大負載）
• 測量的發起位置，伺服器端還是客戶端
• 測量的時間視窗（僅工作日、還是一週7天、是否包括計劃內的維護時間段）

3. 如何彙總處理測量的指標？

• 計算的時間區間是什麼：是一個滾動時間視窗，還是簡單的按照月份計算
• 使用平均值還是百分位值，比如：某服務X的ticket處理響應時間SLI的
• 測量指標：統計所有成功解決請求，從使用者建立ticket到問題被解決的時間
• 怎麼測量：用ticket自帶的時間戳，統計所有使用者建立的ticket
• 什麼情況下的測量：只包括工作時間，不包含法定假日
• 用於SLI的資料指標：以一週為滑動視窗，95%分位的解決時間

4. 測量指標能否準確描述服務質量？

• 效能：時效性、是否有偏差
• 準確性：精度、覆蓋率、資料穩定性
• 完整性：資料丟失、無效資料、異常(outlier)資料

5. 測量指標的可靠度

• 是否服務提供者和客戶都認可
• 是否可被獨立驗證，比如三方機構
• 客戶端還是伺服器端測量，取樣間隔
• 錯誤請求是如何計算的

SLO

SLO(服務等級目標)指定了服務所提供功能的一種期望狀態。SLO裡面應該包含什麼呢？所有能夠描述服務應該提供什麼樣功能的資訊。

服務提供者用它來指定系統的預期狀態；開發人員編寫程式碼來實現；客戶依賴於SLO進行商業判斷。SLO裡沒有提到，如果目標達不到會怎麼樣。

SLO是用SLI來描述的，一般描述為：
比如以下SLO：

• 每分鐘平均qps > 100k/s
• 99% 訪問延遲 < 500ms
• 99% 每分鐘頻寬 > 200MB/s

設定SLO時的幾個最佳實踐：

• 指定計算的時間視窗
• 使用一致的時間視窗(XX小時滾動視窗、季度滾動視窗)
• 要有一個免責條款，比如：95%的時間要能夠達到SLO

如果Service是第一次設定SLO，可以遵循以下原則

• 測量系統當前狀態
  • 設定預期(expectations)，而不是保證(guarantees)
  • 初期的SLO不適合作為服務質量的強化工具
• 改進SLO
  • 設定更低的響應時間、更改的吞吐量等
• 保持一定的安全緩衝
  • 內部用的SLO要高於對外宣稱的SLO
• 不要超額完成
  • 定期的downtime來使SLO不超額完成

設定SLO時的目標依賴於系統的不同狀態(conditions)，根據不同狀態設定不同的SLO：總SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

為什麼要有SLO，設定SLO的好處是什麼呢？

• 對於客戶而言，是可預期的服務質量，可以簡化客戶端的系統設計
• 對於服務提供者而言
  • 可預期的服務質量
  • 更好的取捨成本/收益
  • 更好的風險控制(當資源受限的時候)
  • 故障時更快的反應，採取正確措施

SLO設好了，怎麼保證能夠達到目標呢？
需要一個控制系統來：

• 監控/測量SLIs
• 對比檢測到的SLIs值是否達到目標
• 如果需要，修證目標或者修正系統以滿足目標需要
• 實施目標的修改或者系統的修改

該控制系統需要重複的執行以上動作，以形成一個標準的反饋環路，不斷的衡量和改進SLO/服務本身。

我們討論了目標以及目標是怎麼測量的，還討論了控制機制來達到設定的目標，但是如果因為某些原因，設定的目標達不到該怎麼辦呢？

也許是因為大量的新增負載；也許是因為底層依賴不能達到標稱的SLO而影響上次服務的SLO。這就需要SLA出場了。

SLA

SLA是一個涉及2方的合約，雙方必須都要同意並遵守這個合約。當需要對外提供服務時，SLA是非常重要的一個服務質量訊號，需要產品和法務部門的同時介入。

SLA用一個簡單的公式來描述就是： SLA = SLO + 後果

• SLO不能滿足的一系列動作，可以是部分不能達到
  • 比如：達到響應時間SLO+未達到可用性SLO
• 對動作的具體實施
  • 需要一個通用的貨幣來獎勵/懲罰，比如：錢

SLA是一個很好的工具，可以用來幫助合理配置資源。一個有明確SLA的服務最理想的執行狀態是：增加額外資源來改進系統所帶來的收益小於把該資源投給其他服務所帶來的收益。

一個簡單的例子就是某服務可用性從99.9%提高到99.99%所需要的資源和帶來的收益之比，是決定該服務是否應該提供4個9的重要依據。

原文作者：呂巨集利