淺談SRE-基礎理論篇

什麼是SRE？

在剛剛接觸SRE時，不少人認爲就是Google的一個具有全棧能力的崗位，能夠獨立解決不少問題的人。

而在深刻探究以後發現，SRE確實能夠解決不少問題，但問題實在太多了，一個崗位或一我的是很難高效快速的解決的。

好比怎麼作容量評估、怎麼進行故障演練、怎麼能作到服務限流、怎麼作到異常熔斷、怎麼讓監控告警更有效等

因此爲了解決這些問題，不難看出須要測試、開發、運維以及其餘相關崗位人員都得進行合做建設，因此會發現其實能夠認爲SRE是一套指導建設的體系化方法。

那SRE的目標是什麼？

提升穩定性

建設SRE體系的目標是「提升穩定性」

而在SRE中對「提升穩定性」這一目標有着兩個衡量的指標

指標	釋義
MTBF（Mean Time Between Failure）	平均故障時間
MTTR（Mean Time To Repair）	故障平均修復時間

從他們的釋義中能夠看出兩個指標與系統運行狀態關係對應以下

指標	系統運行狀態
MTBF	系統正常運行時
MTTR	系統故障時

其實咱們對系統穩定性認識就是讓系統正常運行狀態長時間維持下去，當出現故障時能夠快速處理恢復。

因此提高MTBF，下降MTTR就成爲了「提升穩定性」的目標

這讓咱們在建設SRE作相關工做時，能夠依據是否提高MTBF，下降MTTR去判斷工做的有效性

細分目標

有了這個目標以後，問題就來了，MTBF和MTTR兩個指標是否是有點太大了，即便能夠經過告警、通知或其餘手段梳理出其兩個指標的時間數據，也不清楚如何具體落實改進阿。

其實MTTR還能夠細分4個指標，分別對應系統故障中四個階段，具體以下

指標	釋義	階段
MTTI（Mean Time To Identify）	平均故障發現時間	故障發現：故障發生到響應
MTTK（Mean Time To Know）	平均故障認知時間	故障定位：根因或是根因範圍定位出來爲止
MTTF（Mean Time To Fix）	平均故障解決時間	故障恢復：採起措施恢復業務
MTTV（Mean Time To Verify）	平均故障修復驗證時間	故障恢復驗證：故障解決後驗證業務恢復所用時間

而MTBF也能夠細分2個階段，以下

階段	釋義
Pre-MTBF	故障預防
Post-MTBF	故障改進

因此有了具體的階段分割，咱們就能夠針對着去作工做，好比參考至趙成老師的SRE穩定性保證規劃圖以下

Pre-MTBF（故障預防）	MTTI（故障發現）	MTTK（故障定位）	MTTF&MTTV（故障恢復）	Post-MTBF（故障改進）
故障演練	AIOps	日誌分析	容災切換	故障覆盤
容量評估	輿情感知	鏈路跟蹤	服務降級	改進驗收
持續交付	監控告警	根因定位	服務限流	故障模擬
自動化			異常熔斷	混沌工程
架構設計				容量壓測

在體系建設方面能夠分別對應

Pre-MTBF（故障預防）	MTTI（故障發現）	MTTK（故障定位）	MTTF&MTTV（故障恢復）	Post-MTBF（故障改進）
建設演練/On-Call	應急響應	應急響應	應急響應	覆盤改進/On-Call

在如此清晰明瞭的階段化劃分，咱們建設階段性工做就很是清晰，有針對性的去作，不怕走錯路。

好比Pre-MTBF時，咱們能夠作好架構設計提供限流、降級、熔斷等Design-for-Failure的服務治理手段，提供快速隔離的條件

而Post-MTBF時，咱們須要作好故障覆盤，總結不足以及進行改進措施落地。

在這裏呢，也能夠藉助AIOps能力提升問題定位效率以及告警準確率，下降MTTI和MTTK。

辨別故障的基礎：合適的SLI，對應的SLO

上述咱們知道目標是提高MTBF，下降MTTR基本是圍繞這「故障」這個維度來衡量的，可是系統何時纔是故障呢？

因此這裏咱們須要有個判斷條件或者說是判斷標準，來界定「故障與否」

瞭解監控系統的同窗們會知道「告警」了，就有可能發生「故障」，這裏用「有可能」是由於現實場景中一般下是不必定的。

而SRE體系中，有着更好、更準確的衡量標準 SLO（Service Level Objective）來界定「故障與否」。

而提到了SLO就不得不提其相關的SLI(Service Level Indicator) 先

什麼是SLI

建設監控系統的同窗會知道，監控中對目標對象進行監控時會有大量的指標，可是不少指標的做用估計微乎其微。

而經過遵循如下兩個原則從中脫穎而出讓其做用發光發熱的指標就是SLI。

1. 能標識目標對象是否穩定
2. 與用戶體驗強相關或用戶能夠明顯感知的

因此SLI更能表達出「目標對象穩不穩定」。

VALET選擇法

挑選SLI時，不少同窗估計會有點摸不着頭腦，畢竟僅有原則也很難辨別。

業界也深知這個問題，因此也有一套VALET選擇方法依據指標的特質進行分類甄別，指標分類以下所示

類別	解釋
Volume（容量）	服務承諾的最大容量是多少。好比QPS、TPS、會話數、吞吐能力以及鏈接數等等
Availablity（可用性）	表明服務是否正常，好比請求調用的非5xx狀態成功率、任務執行成功狀況
Latency（時延）	響應是否足夠快，好比時延，但時延的分佈符合正態分佈，需指定不一樣的置信區間，有針對性解決。
Error（錯誤率）	有多少錯誤率，好比5xx、4xx，也能夠自定義狀態碼
Ticket（人工介入）	是否須要人工介入，好比任務失敗需人工介入恢復

經過以上類別能夠快速區分出SLI，在實際使用場景上是一個很是實用的技巧。

可是這裏免不了的就是人工介入，不管是對現有指標的篩選，仍是將來接入指標的篩選。

什麼是SLO

好，從SLI能夠表達「目標對象穩不穩定「這點，咱們就可讓SLI + 目標 + 時間維度就能更精確的表達穩定性現狀

好比 1個小時內 90% 時延 <= 80ms

而其就是SLO。

若是以上例子值高於80ms時，就已經表明該SLO已經不達標了，有可能發生故障了。

可是會發現簡單的將單獨SLO做爲「穩定性」的判斷標準，未免會陷入到監控領域相似的告警風暴和誤報這種困境中。

而現實中衡量業務穩定性時，咱們一般會經過多個不一樣的判斷標準和依據來決定業務是否故障

因此咱們也能夠經過組合多個SLO，採用與運算的方式，來更加精確的表達業務的穩定性

公式如：Availability = SLO1 & SLO2 & SLO3

因此得全部的SLO都達成才能算是達標！

而簡單來講SLO的出現讓業務的穩定性表達的更加精確、可靠。

關於時間維度

SLO中的時間維度能夠分紅持續時間和週期，用來覆蓋如下兩種場景

1. 時間維度：從故障角度評估
2. 請求維度：從成功請求佔比評估

時間維度：從故障角度評估

這裏能夠理解爲從SLI已經達不到所設閾值已經持續多長時間的角度，來界定這個SLO是否異常了

好比設定1分鐘內請求成功率低於95%持續10分鐘就是異常

可是這樣的方式在時間細粒度上並不精細

好比出現1分鐘內請求成功頻率多發低於95%，但並無持續10分鐘，這樣其實算是有異常的須要關注的，因此能夠利用請求維度進行補充

請求維度：從成功請求佔比評估

這裏能夠理解爲在統計週期內SLI是否低於所設閾值，來界定SLO是否異常

好比1天內請求成功率低於95%就是異常

這種方式有效的補充了時間維度的不足，一般就是相輔相成的存在

關於SLO與可用性

可用性一般認識就是幾個9，好比 4個九、3個9

可是可用性一直被人詬病的是其數據的準確率問題，而經過SLO組合計算的方式來表達可用性能夠保證準確率問題

由於其底層基礎就是可表達目標對象是否穩定的SLI + 根據業務特徵調整的目標 + 根據業務調整的時間。

經過不斷的調整優化改進，可用性的準確率就會持續提高，並且更加貼近業務表現。

關於SLO與故障

從上述表達，SLO能夠有效的表達穩定性是否達標，因此經過SLO去設置告警能夠有效的告知系統是否處於故障中，

固然經過多個SLO組合後的SLO的告警會更爲穩妥，

由於這樣不止能夠達到告警收斂的效果，也可讓告警更加精確有效，防止狼來了現象。

從這點出發，接下來會介紹的一種量化SLO的數據ErrorBudget更加將這個優點發揮的更加出色

指導工做的量化數據：ErrorBudget

當咱們設定好SLO，可是該怎麼開展具體工做呢？這時候就沒那麼直觀

因此咱們須要有個可量化的數據，能夠用於提醒並觀測SLO的狀況

而SRE中經過反向推導SLO的方式，得出一個量化數據 ErrorBudget（錯誤預算）就能達到這個效果

什麼是ErrorBudget

ErrorBudget，錯誤預算，能夠直白的理解其爲「提示你還有多少次犯錯的機會」

好比 4周爲一週期，應用的請求次數是 4,653,680，反向推導如下SLO得出 ErrorBudget 以下

SLO	ErrorBudget
99.95% 可用性	23,268
90% 時延 <= 80ms	465,368
99% 時延 <= 200ms	46,536

這樣能夠將數據轉換成計分的形式，更加直觀並且感官衝擊力更增強。

因此咱們能夠經過應用 ErrorBudget進行數據的歸一化 的方式，更好的來推動穩定性目標的達成

消費 ErrorBudget 數據

穩定性燃盡圖

利用ErrorBudget計分形式，使用柱狀圖形式圖表實時展現其狀態，固然得設定一個週期建議爲4個天然周，週期後數據恢復。

對於特殊的場景，能夠適當增大ErrorBudget，可讓其場景合理化，可是仍是具體狀況具體分析。

故障定級

利用ErrorBudget歸一化成次數時，能夠利用其消耗數百分比來制定故障等級，這樣全部不一樣的SLO均可以利用同一份規則去作故障定級，達到統一規範的目的。

通常故障等級都會分紅P0~P4五個級別，0爲最高。

常見的故障等級設定以下

單次消耗比例	故障等級
比例<=5%	P4
5%<比例<=20%	P3
20%<比例<=30%	P2
30%<比例<=50%	P1
50%<比例	P0

好比 ErrorBudget爲25000，問題產生錯誤請求超過5000，也就是消耗20%以上既能夠定級爲P2級以此類推。

具體的等級設定須要根據業務的狀況和容忍度去制定。

穩定性共識機制

駕照記分制想必你們都不陌生，在等你發現計分剩下1分時，你開車就會很是的當心，避免犯規致使再教育或駕照吊銷。

因此你會發現ErrorBudget也是如此，一旦剩餘的數量很少時，你會提升警戒，制定相應的行動措施，來避免穩定性目標SLO不達標。

而如何制定行動措施呢？能夠考慮如下兩個原則

1. 當剩餘預算充足或未消耗以前，對問題的發生要有容忍度

在平常咱們會遇到網絡抖動或設備瞬時切換致使了極短暫系統不穩定， 這時有極少一部分客戶反饋或業務使用時遇到了，結果就被投訴業務不穩定，而後技術人員就馬上放下手頭工做去排查問題，後續還要花大量的時間去覆盤總結和彙報。

這樣消耗了技術人員大量的時間和精力，排查結果對業務沒什麼大幫助，這樣致使的結果會有技術人員手頭工做沒法完成，也浪費了其餘協助人員的時間。

整體來講性價比不高，並且是一個漣漪的擴散影響，這種事情一多了，估計就會引起」海嘯「了吧！

如今有了SLO和錯誤預算判斷標準，就有了明確的應對思路：若是預算充足就應該有所容忍不該該被投訴，也不該該高優先級響應。

2. 當剩餘預算消耗過快或即將消耗完以前，SRE有權停止和拒絕任何線上變動

這種情形下，能夠理解成一個帶病的工程師，還在堅持上班工做，可是這時他的工做完成的並不理想，並且有可能會直接倒下的風險

你還忍心給他分配新的任務或讓他繼續以這樣的狀態工做下去嘛？

這時應該讓他恢復健康，才能繼續好好的幹下去！

從這點類比可看，團隊應該是要優先配合解決影響穩定性的問題，直至問題解決，等到下個週期有了新的錯誤預算後再恢復正常的變動節奏

注意要點

這兩點實際上是須要你們都要承認並執行的。由於這裏涉及的是多方配合協做問題，有一樣的共識才能保證工做協做上的流暢以及高效。

從多方協做這點出發看待，若是要推行該機制是須要」Top-DOwn「自上而下的，好比技術VP或CTO級別。

並且有問題時還能夠逐步上升由CTO角度作決策。

基於錯誤預算的告警

在以往平常工做，常常會收到大量的告警短信，可是其價值很是低，致使的後果就是狼來了，你們都開始對告警產生了不信任。

其實這樣的後果是很是嚴重的，由於極有可能有用的信息被淹沒了，致使業務利益受損，多方擔責。

固然業界也有解決方案，名爲」告警收斂「

經常使用作法有讓相同類似告警合併後在發送給通知人，好比同一集羣、同一異常告警

可是這種作法也會充斥着不少信息，沒法快速的定位到問題並處理，爲何這樣說？

由於只是單純的將信息合併了，信息量仍是沒有變化，除非是結合其餘手段將信息再提煉計算合併，好比所謂的告警決策樹，這樣的話會更加精準。

可是這種建設的成本也不低，涉及到收斂的規則設計、對象邏輯層級設計、決策邏輯處理實現等。

而採用基於錯誤預算告警的方式就能自然的作到告警收斂，由於他是基於業務的SLO的

這也代表咱們只關注對穩定性形成影響的告警，而這類告警的出現咱們是必須快速響應處理，並且這種告警數量很少

達到收斂效果的同時又很是精準。

簡單作法就是將故障定級的閾值進行告警設置，更詳細精準的作法會涉及到AIOps領域相關的，

能夠從谷歌基於SLO和錯誤預算的幾種告警算法瞭解

如何衡量SLO是否有效

雖然咱們定好的SLO，可是SLO是否有效的反映出業務的穩定性，以及其反推出來的ErrorBudget是否真的能有效指導工做呢？

咱們仍是須要去進行驗證檢測，並持續優化的。

這裏就須要從三個維度去梳理場景，以及根據三種策略去處理相應狀況

哪三個維度？

咱們能夠從三個維度去評估

維度	狀態
SLO達成狀況	達成（met）或未達標（miss）
"人肉"投入程度	高（high）或低（low）
用戶滿意度	高（high）或低（low）

根據這三個維度不一樣的組裝有8種狀況

哪三種策略？

而在咱們能夠用如下三種策略去處理

1. 收緊SLO
   用戶滿意度低時，而目標反而達成了，這時咱們就要收緊SLO，縮小目標，逐步調整成能反饋出真實狀況
2. 放寬SLO
   用戶滿意度高時，目標反而沒達成，這時咱們就能夠適當的鬆綁，將目標調大，也適當增大發布次數，加快業務增加
3. 針對問題，持續優化
   這裏需按狀況分析出問題的緣由，針對性優化
   好比三種維度都符合預期時，增長迭代次數，提高業務生產效能
   三種維度都沒符合預期時，分析業務特徵不斷調整優化SLO，落實優化改進措施持續提高

應對狀況策略

梳理具體的狀況應對錶格以下

SLO達成狀況	「人肉」投入程度	用戶滿意度	執行策略
Met	Low	High	持續優化：產品用戶體驗差的問題，因此放寬發佈和部署流程並提升速度，或先推遲規劃實現，更多專一於提高服務可靠性
Met	Low	Low	收緊SLO
Met	High	High	持續優化：若是是告警產生錯誤的導向，下降敏感度。不然臨時放鬆SLO或減小人工投入、修復產品和提升故障自愈能力。
Met	High	Low	收緊SLO
Missed	Low	High	放鬆SLO
Missed	Low	Low	持續優化：告警設置質量不足，需提高告警的敏感度
Missed	High	High	放鬆SLO
Missed	High	Low	持續優化：減小人工投入、修復產品和提高故障自愈能力

怎麼落地SLO？

前面說了一堆SLO的各類好，那落地的話該怎麼入手呢？

其實前面或多或少也說了一點，可是這個篇幅咱們就把他揪出來

找出核心鏈路

實踐SRE無非就是服務於業務，因此應從分析業務入手，找出核心點

而雖然業務中應用衆多，可是能創造核心價值的是顯而易見的，畢竟用戶訪問量、業務業績、業務特徵從這些角度就能夠篩選出整個具備核心價值的鏈路出來

因此優先從業務角度先整理辨別核心和非核心應用，從而梳理出核心鏈路，就是咱們的指導方針。

其實這裏當前並無很好的自動化手段去整理，畢竟貼近用戶的，除了利用機器學習的方式去推斷貌似也沒什麼好解決方法

因此這裏會充斥着大量的人肉工做，這裏涉及的架構的梳理、業務方的溝通、技術棧的梳理等等。

可是這個付出是值得的，由於這樣就會對整個業務有着通盤的理解，之後也更好的開展工做。

梳理應用間關係

當核心鏈路整理出來後，裏面的核心應用與非核心應用都會相應的整理出來，畢竟核心鏈路就是由核心應用所構成的

而在處理應用與應用直接的關係時，分強弱兩種，具體組合狀況分類以下

應用角色	應用角色	關係強弱
核心	核心	強
核心	非核心	弱
非核心	非核心	弱

當咱們梳理好關係以後，咱們既能夠分而治之，對其設定SLO

設定應用SLO

設定應用的SLO，能夠遵循四個原則

1. 核心應用SLO要更嚴格，非核心應用能夠放寬

讓咱們建設更加關注核心業務上

2. 強依賴的核心應用之間SLO要一致：

能夠理解他們是同一條道路上的，一旦某個路段出現阻塞時，影響的是整條道路的車輛運行狀況。

3. 弱依賴中核心應用對非核心的依賴要有降級、熔斷和限流等服務治理手段

主要目的在於下降非核心應用對核心應用的影響，保證用戶的最高權益

4. ErrorBudget策略，核心應用的錯誤預算要共享

若是某個核心ErrorBudget消耗完了，一定是對整個鏈路有影響的，從而對用戶體驗上形成影響，這是原則上是要中止鏈路上全部變動操做的，優先修復。
固然能夠根據實際狀況放鬆，好比某個核心應用自身預算充足且不影響核心鏈路功能，固然這點決策須要很是謹慎。

驗證

固然咱們設定完，以後都須要驗證一把，給出相應的實證，否則就成「自娛自樂」了。

而這裏手段，如今所瞭解到的有兩種

1. 容量壓測
2. 混沌工程（Chaos Engineering）

容量壓測

容量壓測主要做用是對SLO中的Volume類的進行驗證，通常容量類的指標有業務的QPS、TPS，

因此會依據這些指標進行容量的進行壓力測試，從而暴露依賴關係問題，和各類服務治理措施是否有效。

好比模擬用戶訪問請求提高TPS併發訪問到SLO所設定的數值，而後觀察業務是否有影響，原先所設置的的限流降級策略是否生效，達到預期

混沌工程（Chaos Engineering）

混沌工程主要做用是模擬故障發生場景，主動產生線上異常和故障

好比機房斷電驗證異地雙活、打滿流量驗證網絡、寫滿磁盤或跑滿CPU等等操做

混沌工程是很是複雜的系統化工程，由於要線上製造故障，或多或少都要對線上業務形成影響，若是模擬故障形成的真實影響超過預估影響，也要可以快速隔離，並快速恢復正常業務。

看到這句話是否是以爲有點恐怖，貌似跟維穩有點違背阿。

因此混沌工程的實施要很是的謹慎當心。

其中模擬策略必需要通過大量的反覆驗證，包括異常恢復原實施，確保影響可控以後，通過多方評審或驗證才能線上實施。

因此混沌工程並不會在SRE體系初期就會嘗試的東西，

必須是在高級階段，也就是服務治理、容量壓測、鏈路跟蹤、監控告警、運維自動化等相對基礎和必需的部分很是完善的狀況纔回去考慮的東西。

混沌工程其實就是從未知中挖掘出問題，從而讓業務對自身瞭解更加清晰，更能保障本身，簡單來講就是「在失敗中成長」。

何時作驗證？

咱們知道要作驗證，可是何時作呢?

參考Google的建議，核心就是錯誤預算充足時能夠嘗試，儘可能避開錯誤預算不足的時間段。

正常的業務下，完成SLO也不是一件簡單的事情，並且也不能給系統穩定性形成風險。

並且得評估故障模擬的影響，好比須要考慮是否損害公司收益？是否損害用戶體驗？

若是對業務影響很大時，還要將方案粒度細化，分步驟、避免形成不可預估的損失。

因此實際實踐中，時間段須要根據業務特徵去選擇，要考慮故障恢復時間，準備必定要充分，不可大意。

結語

本文爲學習趙成老師的SRE實戰手冊，所總結得出本身對SRE的理解。但願對各位有興趣的同仁們有所幫助。