本文是《SRE，Google運維解密》讀書筆記，連載第三篇。微信公眾號修改了推文邏輯，尤其是 iOS，建議對本公眾號 SRETalk 加星標，以免錯過后續(xù)系列推文。

本文介紹 SLO，曾經(jīng)我發(fā)過一個短時間講解我們做監(jiān)控最應(yīng)該監(jiān)控的是什么，短視頻講了上篇，這篇算是下篇。當時的短視頻可以在這里查閱：

SLI、SLO、SLA

先拎清楚幾個概念：

• SLI：服務(wù)質(zhì)量指標，比如 99 分位的響應(yīng)時間、99 分位的響應(yīng)時間、錯誤率等

• SLO：服務(wù)質(zhì)量目標，所謂的幾個 9 的目標，比如 99 分位的響應(yīng)時間小于 200 毫秒，比如錯誤率小于 0.1%

• SLA：服務(wù)質(zhì)量協(xié)議，是個承諾，是個合同，比如公有云就會提供 SLA，不達標就會有賠付

SRE 在制定 SLx 時的職責

SRE 不參與構(gòu)建 SLA，因為這通常涉及退款賠付之類的，是個商業(yè)行為，但是 SRE 要幫助業(yè)務(wù)確立 SLI，幫助業(yè)務(wù)達成 SLO。

SLI 相關(guān)的一些實踐

首先，千萬不要把能監(jiān)控到的一坨指標都確立為 SLI，SLI 一般也就是四五個，再多就有問題了。不同的服務(wù)的 SLI 舉例：

• 用戶可見的服務(wù)系統(tǒng)：可用性、延遲、吞吐。即：是否能正常處理請求？每個請求花費的時間是多少？多少請求可以被處理？

• 存儲系統(tǒng)：延遲、可用性、數(shù)據(jù)持久性。即：讀寫數(shù)據(jù)需要多少時間？我們是否可以隨時訪問數(shù)據(jù)？一段時間之后數(shù)據(jù)是否還能被讀??？

• 大數(shù)據(jù)系統(tǒng)：比如數(shù)據(jù)處理流水線系統(tǒng)，關(guān)注吞吐量和端到端延遲。即：處理了多少數(shù)據(jù)？數(shù)據(jù)從進來到產(chǎn)出需要多少時間？

• 所有系統(tǒng)都應(yīng)該關(guān)注：正確性。比如是否返回了正確的結(jié)果？當然，正確性更關(guān)注系統(tǒng)內(nèi)部的數(shù)據(jù)而非系統(tǒng)本身，所以SRE通常不會關(guān)注這塊。

總結(jié)：SLI 應(yīng)該是一些上層業(yè)務(wù)或用戶關(guān)注的體驗指標，這些指標如果出問題了，一定是服務(wù)出了大問題了。

另外，一般 SLI 都是分鐘級的匯總，比如成功率是每分鐘產(chǎn)出一個值，延遲也是，延遲盡量不要用平均延遲和50分位，會掩蓋一些長尾問題，比如下圖：

50th, 85th, 95th, and 99th percentile latencies for a system. Note that the Y-axis has a logarithmic scale.

從 10:30 開始，長尾請求的延遲變得頻繁了，尤其是 99 分位和 95 分位，但是 50 分位的值，幾乎不變，如果我們只關(guān)注 50 分位的值，就沒法發(fā)現(xiàn)這個問題了！

定義 SLO 的一些建議

實際制定 SLO 的時候，對內(nèi)對外通常是兩個值，對內(nèi)更嚴格，對外更寬松。而且，即使有能力達成 SLO，也不要做的過高，適當?shù)母銙煲幌路浅Ｓ斜匾?/strong>。比如某個服務(wù)當前季度（SLO 一般按季度統(tǒng)計）的 SLO 是 99.95%，季度末了，100% 可用，此時建議做個放火演練之類的，即使搞出紕漏，對 SLO 的影響也不會太大。其次，上層業(yè)務(wù)也會充分認識到你這個下游服務(wù)不是 100% 可靠的，會有針對性的增強冗余設(shè)計。