前言
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的確定需要回答以下幾個問題：
要測量的指標是什麼？
測量時的系統狀態？
如何彙總處理測量的指標？
測量指標能否準確描述服務質量？
測量指標的可靠度(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的重要依據。
案例：
首先，SLI 和 SLO 是 SRE 工程實踐裏非常核心的概念，但是在同時提到這些概念的時候，經常容易混淆。
說明一下，下圖假設所討論的 SLA 個數爲 1，使用了軟件工程中 ER 圖的表達方式，但也有所變化。
術語清單
SLA = Service Level Agreement = 服務質量/水平協議（對外承諾）
SLO = Service Level Objective = 服務質量/水平目標（對內產品目標）
SLI = Services Level Indicator = 服務質量/水平指標（對內產品服務質量評價指標）
人（用從上到下，從左到右的順序）
客戶 - 每 1 個客戶在使用產品服務時，都顯性或隱性的基於某 1 個 SLA，SLA 和客戶之間是一種 1 對 1 的文檔關係，這份協議文檔就顯性或者隱性的存在於系統中。客戶使用 1 種，或者 n 種連接方式訪問產品服務的 1 個或者 n 個應用系統。
銷售 - SLA 本身是所銷售產品服務的一部分，它規定了承諾給客戶的產品功用和質量。基於 SLA，客戶可以選擇用付費或者免費的方式使用產品。1 個/份 SLA 的銷售工作可以由 1 到 n 位銷售完成。銷售和客戶都幻想着幾乎完美的 SLA，這樣代表企業利益的銷售，以及產品的客戶就都可以達到雙贏的局面，皆大歡喜。
產品 - 通過與銷售的間接互動，或者直接的客戶調研，產品經理能夠確定應用系統所應該具有的功能和發展方向。
SRE - SRE 和產品共同制定了每個 SLA 相關應用系統的 SLO，SLO 定量的定義了每 1 個應用系統所應該具備的服務質量，1 個應用系統的 SLO 被該產品服務的 SLO 文檔定義，在該文檔中 SLO 被映射到 1 個或者 n 個 SLI，每個 SLI 都需要用監控工具持續採集數據，通常它們的數值單位各不相同。所有 SLO 都是用百分比數值形式表達的，例如：99.99% 的成功率，90％ 的請求延遲 < 400 毫秒等。SRE 和產品經理/專家還應該共同關注運行應用系統的基礎設施層，確保基礎設施的可用性和容量足以滿足目標數量的用戶訪問，而且還要考慮和設計底層資源的容災和跨區多活等複雜場景。
開發/運維 - 重要但暫不做討論。
事（用從下往上的順序）
IaaS 雲服務 - 也可以是其它類型的可以供應用系統運行的環境。這裏存在着 1 到 n 種子服務。它和上層的 n 個應用系統通常是 n 對 n 的關係。
應用系統 - 1 個到 n 個應用系統構成了 1 個產品服務（內含SLA），在和客戶的互動中實現着產品服務的業務價值。
文檔 - 以網頁或者紙張的形式向用戶描述了某個應用服務所提供的服務內容和質量信息。向用戶提供這個文檔並不是強制、顯性和必須的。
結束語
結合你的實際工作場景，想象並描繪一下 SLA 、SLO 和 SLI 在你周圍的人事物中關係網。在SRE 的工作實踐中，定義 SLO，並梳理 SLI，將量化以後的目標和說明文檔化，並讓各個干係人認同並簽署，是一項基礎的起步工作。
————————————————
版權聲明：本文爲CSDN博主「木給哇啦丶」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lquarius/article/details/120244396