系統可用性=可用性=正常運作時間÷（正常運作時間+停機時間）
SLI = 服務水準名額
它是企業最重要的名額。
- 服務的正常運作時間
- 交易數量
- 潛伏
- 錯誤率
- 吞吐量
- 響應時間
- 耐用性
SLO = 服務水準目标
它是圍繞 SLI 建構的。它是指服務水準的目标值或目标範圍。通常是一個百分比并與時間架構相關聯。
90%（正常運作時間的 19）= 10% 的停機時間，這意味着過去 30 天中有 3 天
99%（2 個九的正常運作時間）= 1% 的停機時間，或過去 30 天的 7.2 小時停機時間
99.9%（3 個 9 的正常運作時間）=0.1% 停機時間，或過去 30 天的 43.2 分鐘停機時間
SLA = 服務水準協定
企業與客戶簽訂協定。
- 退還服務費
- 提供一段時間的免費服務
案例分析
假設我有一個網站http://xxx.com。 從2022年1月1日運作到2022年3月15日，要求的資料如下：
- 1月份的請求總數為500，錯誤響應數為20
- 整個2月份的請求總數為600，錯誤響應數為10，停機時間為10分鐘
- 從目前 3 月開始，請求總數為 400，錯誤響應數為 15。
那我算出來的SLI、SLO、SLA分别是多少呢？
SLI, 1 — (20+10+15)/(500+600+400) = 97%
SLO, 1 — (10/(74*24*60))=99.991%
SLA，如果服務商不能滿足SLO未達到99.999%的協定條款，按照簽訂的SLA協定賠償多少。
這是Google 同意向客戶提供 Google Cloud Platform的協定條款。
理想情況下，SLI 應該直接衡量特定的服務品質。但是，在許多情況下，直接測量可能很難被觀察和獲得。是以，隻能使用某種名額。延遲是最直接的監控名額。耐用性也是資料存儲系統監控資料可以保持多長時間不變的重要名額。雖然不可能實作 100% 的可用性，但接近 100% 的可用性名額是可以實作的目标。營運專家經常使用數字 9 來描述可用性。例如，99% 的可用性稱為“2 個 9”，99.99% 的可用性稱為“4 個 9”。谷歌雲計算服務目前的可用性名額是“3.5 個九”——99.95% 的可用性。
選擇目标 SLO 并不是純粹的技術活動，因為這裡還涉及産品和業務級别的決策。SLI 和 SLO 的選擇應該直接反映産品和業務級别的決策。現場可靠性工程師 (SRE) 應讨論可行性和風險并提供建議。這就是為什麼了解系統的各種名額和限制很重要的原因。應該隻選擇足夠多的 SLO 來覆寫系統屬性。
在做出有關系統操作和維護的決策時，SLI 和 SLO 非常有用。
- 監控和測量系統的 SLI
- 比較 SLI 和 SLO 以決定是否需要采取措施
- 如果需要執行某項操作，則由決定具體需要執行什麼操作才能實作目标
- 執行這些操作
例如，如果在第 2 步中，請求延遲正在上升，則将在幾個小時内超過 SLO 而沒有操作。第三步會測試伺服器是否沒有足夠的CPU資源，并添加一些CPU來分散負載。如果沒有 SLO，我們不知道是否（或何時）需要執行該操作。
SLA 要求業務和法律部門選擇合适的後果條款。站點可靠性工程師的作用是幫助業務和法律部門了解滿足 SLA 的 SLO 的機率和難度。谷歌保證該服務的年可用時間≥99.99%。此外，Google 保證在使用者提出技術支援請求後 1 小時内第一時間響應，包括電話、電子郵件等。還附帶大量獎勵和補償細節。