SRE (DevOps) 如何定義，SLI、SLO、SLA 是什麼?

前言

身為一個想要應徵 SRE(Site Reliability Engineering) 工程師的我，最近被朋友問到說 SRE 的工作內容要做什麼，居然沒辦法解釋得很清楚，也代表我對於這個名詞還不夠熟悉吧…
因為 SRE 也不是什麼多新的詞了，網路上不少資源可以翻閱，不過之前常常看過之後覺得自己會了，然後被問又講不清楚，所以就想說不如自己整理一篇文章吧，這樣至少忘記的時候可以快速複習一下~
SRE 是由 Google 所提出的一個應用與實現，其中會使用 SLO，SLA，SLI 三項來評估服務的 可靠性。

服務水準指標 (Service-Level Indicator, SLI)

顧名思義，SLI 是用來定義服務水準的，也就是說服務的品質是好或壞就會使用這邊的定義來決定。

SLI 範例： 如 300ms 的請求延遲。或是 HTTP 狀態碼為 200 的回應次數，佔總回應次數的比率。

請求延遲，系統吞吐量，請求失敗占比等，都是可以被拿來測量 SLI 的指標。有了指標，就可以來定義系統是否有到達一定的服務水準。

服務水準目標 (Service-Level Objective, SLO)

測量了 SLI 之後，就可以定義一個更明確的目標來評估服務的品質是否有達到要求。
SLO 是由以下三種元素組成：**SLI、一段時間區間、目標 (通常以百分比呈現)**。

SLO 範例：在一個月之中，99.9% 的請求延遲有在 300ms 內。

也就是說是 SLI 的指標加上了時間與目標，即為 SLO。
另外要注意到，實務上不太可能追求 100% 的可用，原因是成本太高並且沒有必要。
過高的可靠性會拉長開發時程導致更新困難，可能就有一些新功能不好上線 (違反 SRE 快速交付的原則)。

服務水準協議 (Service-Level Agreement, SLA)

SLA 與 SLO 很接近，但 SLA 更像是給客戶的承諾，其中會承諾其 SLO 應在一段時間內達到特定水準，若未達到保證的目標則會產生罰則。
通常在 SLA 中定義的 SLO 會比內部的 SLO 再寬鬆一點：

SLA 範例：給客戶承諾一個月內的可用性 SLO(SLA) 為 99.9%，而內部 SLO 為 99.95% (較嚴謹)

SRE (DevOps) 定義

在描述完三項指標之後，再來定義一下所謂 SRE 工程師 到底要負責些什麼。
而很常與 SRE 綁在一起的 DevOps 網路上的定義很多，整理如下：

DevOps 指的是一種文化，打破 Dev 與 Ops 溝通上的問題
SRE 為 DevOps 的實踐

那麼在 DevOps 文化上，有5個基本的大方向原則：

• Accept failure as normal (接受失敗是常態)：定義 SLO 時不可能會有 100% 好的服務，再檢討過程中要顧及：人、文化、心理上的安全感，以及不責罵的文化。
• Reduce organisational silos (降低組織隔閡)：SRE 的實踐就是在維運與 product team 共同分擔。
• Implement gradual change (漸進式更動)：如金絲雀進退版，導入 CI/CD 等，降低錯誤的 cost。
• Leverage tooling and automation (利用工具與自動化)：把重複做的事情自動化。
• Measure everything：能夠監控服務上的指標等等，並且定義 SLA 的數值。

SRE 實作了 DevOps 的精神，希望可以降低 Dev 與 Ops 兩個部門的衝突：

• Dev：想要最新最酷的技術，有新東西就想要趕快上線看看。
• Ops：機房能不動最穩定，連重開機都不太想，想達到 100% 的可用性。

所以這兩個部門的衝突要由 SRE 工程師來解決：

1. 自動化：透過自動化來提高效率，並考慮導入 CI/CD 等流程建置自動化流程。
2. 經常檢討：為提高可用性去分析及檢討根本的問題。
3. 事前演練 ：事故發生時透過事先演練，達到預防勝於治療的成效。

SRE 的任務

先看一段 Red Hat 官網對 SRE 的描述：

SRE teams are responsible for how code is deployed, configured, and monitored, as well as the availability, latency, change management, emergency response, and capacity management of services in production.
(如何部屬、設定、監控 Code，同時兼顧可用性，延遲，緊急回應，空間管理等)

簡單來說，SRE 的任務包含了：

• Availability (可用性)
• Latency (延遲)
• Performance (效能)
• Efficiency (效率)
• Change management (變更管理)
• Monitoring (監控)
• Incident response (事故應變)
• Capacity planning (容量規劃)

總結

因為最先提出 SRE 的為 Google 的工程師，所以一開始提到的三項服務水準 (SLI, SLO, SLA) 很重要，可以作為是基本評估服務的標準。
再來搞清楚 SRE 工程師實際上在公司的定位，雖然說好像會依照每家公司的定義而會有差異，但我先找到我自己的定義然後來實踐練習，也比較能說出一點東西。
最後在 SRE 的觀點中，有應用了 不責罵原則，當錯誤產生時不去責罵任何一個人，而是針對錯誤進行紀錄，並且文件化，讓下次遇到類似狀況時能有個依據並且快速處理。
以 Team 的方式去看待每一次失敗，失敗沒什麼，如何修正與預防才是關鍵。

以上就是一個新手小白對於 SRE 的理解，如果內容有疑慮歡迎與我討論 (批評) 。

參考資料

SRE 必修課：一次搞懂 SLI、SLO、SLA 差異，Google DevOps 理念實踐 - iKala Cloud
SRE 是什麼？ 維運管理與 SRE 的關係 - Cloud Ace 技術部落格 (cloud-ace.tw)
What is SRE? (redhat.com)
(YouTube) What is DevOps? REALLY understand it | DevOps vs SRE