Class SRE implements DevOps
一兩年前看過一個有趣的Video裡面解釋了SRE與DevOps的關係，那時筆者只覺得好高空，『SRE是DevOps的落實』但無法體會其意義。
這兩位Google的大拿(Liz&Seth)，又接著出了一篇SRE落地教程，其中提到了SRE在與客戶(開發單位）訂定服務水準時，通常會詢問PM三個問題：
- 定義可用性是什麼
- 可用性的程度到哪
- 若發生不可用情形的應變計劃
同時透過訂定以下三個指標群，跟PM、以及產品使用者共同來提供：
Service Level Objective(服務水準目標 SLO): 通常是PM與SRE共同制定
舉例：95%th percentile homepage SLI will succeed 99.9% over trailing year
Service Level Indicator(服務水準指標 SLI))：通常由SRE內部制定
舉例：
- Request Latency (過去五分鐘，99% 的連入網站請求，都能在300ms內回覆)
- Batch throughput (過去五分鐘，連線由請求到結束，99%皆應於1s內完成)
- Failures per request (過去五分鐘，連入請求失敗的比例，必須少於1%)
Service Level Agreement (服務水準合約 SLA)：是一種商業合約，通常由PM/Sales與客戶簽訂
舉例：服務可用(Uptime)時間若達不到99.5%，就提供免費的服務補償金
這三者間的關係式，也可利用這句話來了解：
SLIs drive SLOs which inform SLAs
利害關係人：
看完以後，學到了什麼是SLI, SLO, and SLA，可是還是不太懂怎麼幫客戶使用這些技巧。
最近，在玩Google Anthos的同時，發現原來這些是真的可以落實的指標群，希望跟捧油們分享，到底SRE是怎麼落地SLI,SLO, and SLA的：
該如何落地：
理論說一堆，到底我們該怎麼實現這個SLI or SLO? 最重要的是，先建立監控機制。舉例，使用貴鬆鬆的APM，或是開源的Istio平台。以下我們就以一隻有名的微服務Online Bonquet為例，將其部署在K8S叢集內後，再對其部署Istio (1.4.9)，就可以透過Istio Agent的回傳值，了解後端微服務間的延遲時間。
底下我們透過GCP Anthos平台，平台提供量測50%延遲以及99%延遲，VMware的Wavefront也可以達到類似的機制：
- 50%延遲：該段時間窗內的延遲時間中位數
- 99%延遲：該段時間窗內，99%的延遲時間低於該數值
了解各服務的延遲時間後，我們就可以訂定該服務基於延遲時間的SLI，底下我們選擇shoppingcartservice，透過歷史資料，我們大概了解，該服務的99%的延遲約是669個ms以下。
依照歷史資料，我們先訂定SLI（指標）為100ms延遲，我們再訂定SLO(服務水準)約90%，我們就可以得到一個相對穩定的監控指標，如下圖：
但如果PM不接受，希望更改延遲時間為50ms，這時即使通過一樣的SLO（約90%)，我們會得到一個產品沒有修正前，很難達成的SLO。這時就需要要求開發團隊進行產品的補強或變更，不然無法達到PM的要求。
結論：
筆者蠻喜歡Google SRE所用的指標的，也跟大家分享一個真正有機會落地的企業裡的指標群。
其實筆者兩年前看到這個Video時，有問過客戶是否可能進一步討論落地的實務，但客戶的回覆是，我們PM只跟我們單一的指標，叫做不能當。聽了Liz&Seth的分享後，我們了解，『不能當』是個期望，但絕對不能作為服務的SLA，因為有太多的東西不是開發者、網管、甚至是系統管理者可以掌控的(舉例：停電、COVID-19等)。透過SLO/SLI，把PM與維運雙方的認知，拉回一個可以量化的指標，並訂定雙方都可接受的風險範圍，也就是SLO，比大家閉著眼睛，以為可以做到『不能當』是不是更好嗎？
今天我們先聊到這，之後繼續跟Liz&Seth的系列，跟大家分享Risk/Error Budget，以及Toil/Toil Budget，在SRE裡的用處。
