前言

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

云計算時代，各大云服務提供商都發布有自己服務的SLA條款，比如Amazon的EC2和S3服務都有相應的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)

下面通過一個例子來說明一下：hotmail的downtime SLI

• 錯誤率(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的重要依據。