SRE 概念速讀 – SLI/SLO/SLA

這邊我會著重挑選幾個SRE中經常使用到的概念來進行說明，這並不是完整的教學，期待是在短時間內提供一個概念的導讀。

Site Reliability Engineering (SRE)和DevOps 總是一起被提及，簡單來說SRE是DevOps的一部份內容，而SRE當中有更清楚、可執行的規範。

那SRE到底是在做什麼的呢？

SRE is what happens when you ask a software engineer to design an operations function.

SRE 就是當你去問一個軟體工程師如何設計一套維運方法的表現。

如何實踐SRE

1. 減少組織孤島: 建立透明開放、良好運作的溝通管道
2. 正常接受失敗: 停止咎責、調整系統、規範與流程來使錯誤不再發生
3. 實施漸進式變革: 逐步更新、將大型更新拆解成小部分進行更新
4. 利用工具和自動化: 加入自動化工具進入流程中、減少重複性工作（應該低於總工時的一半）
5. 一切可衡量: 設定指標、有效評估每個行為與動作成果
6. 使用錯誤容許率(Error Budget): 保留可以或是暫時可以的出錯空間(100%到SLO的空間、SLO到SLA的空間。)

資料導向決策應著重方向

1. 即時監控儀表板
2. 可預估指標
3. 組織文化的調整
4. 緊急情況偵測
5. 系統更新需有自動化管理

執行SRE的好處

1. 讓開發與維運進行合作
2. 讓開發與維運共享責任
3. 清楚可執行的實際目標
4. 清楚可管理的系統風險

必要指標

SLI (service-level indicator): 服務等級指標
SLO (service level objective): 服務等級目標
SLA (service-level agreement): 服務級別協定

SLI (service-level indicator): 服務等級指標

用來說明當前服務的健康狀況。

範例: 過去5分鐘內，95%的首頁請求反應時間低於300毫秒。

以下常用指標類型

請求/回應

• 可用性
• 延遲率
• 回應品質

資料處理情況

• 覆蓋率
• 正確性
• 更新時間
• 延遲性

資料儲存

• 健康存活長度
• 延遲性

SLO (service level objective): 服務等級目標

期望SLI達到的目標，若未達成應給出警示。

範例: 過去1年間，首頁請求有99％的次數達成該SLI

下面提供一些常用的目標

範例 - 成功率: 行為沒有產生錯誤的比率
範例 - 延遲性: 行為通過最慢反應時間的比率
範例 - 品質率: 行為產生正確資料的比率
範例 - 處理覆蓋率: 待處理的資料佔總體資料的比率
範例 - 更新頻率: 最後一次更新的時間
範例 - 重現率: 資料儲存後讀取的時間

SLA (service-level agreement): 服務級別協定

是最低必須要維持的服務品質，若未達成應給出強烈警示。

範例: 過去1年間，首頁請求有95％的次數達成該SLI

四大原則

當 SLO 受到威脅時，暫時不需要on-call工程師，除非未達到SLA。
每次產品進行更新時，DevOps與SRE必須調查與確認該次更新是否影響SLO。
當某項SLI屢次遭到影響時，DevOps與SRE必須調查與追究原因。
當某項SLO長期未達標準時，DevOps與SRE必須進行調查與重新調整目標。