什麼是SRE？

在剛剛接觸SRE時，很多人認為就是Google的一個具備全棧能力的崗位，可以獨立解決很多問題的人。

而在深入探究之後發現，SRE 確實可以解決很多問題，但問題實在太多了，一個崗位或一個人是很難高效快速的解決的。

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

所以為了解決這些問題，不難看出需要測試、開發、運維以及其他相關崗位人員都得進行合作建設，所以會發現其實可以認為SRE是一套指導建設的體系化方法。

SRE的目標是什麼？

提高穩定性

建設SRE體系的目標是“提高穩定性”

而在SRE中對“提高穩定性”這一目標有著兩個衡量的指標

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

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

所以提升MTBF，降低MTTR就成為了“提高穩定性”的目標。

這讓我們在建設 SRE 做相關工作時，可以依據是否提升MTBF，降低MTTR去判斷工作的有效性。

細分目標

有了這個目標之後，問題就來了，MTBF和MTTR兩個指標是不是有點太大了，即使可以透過告警、通知或其他手段梳理出其兩個指標的時間資料，也不清楚如何具體落實改進。

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

而 MTBF 也可以細分2個階段，如下：

所以有了具體的階段分割，我們就可以針對著去做工作，比如參考SRE穩定性保證規劃圖如下

在體系建設方面可以分別對應

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

比如 Pre-MTBF 時，我們可以做好架構設計提供限流、降級、熔斷等Design-for-Failure的服務治理手段，提供快速隔離的條件。

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

在這裡呢，也可以藉助AIOps能力提高問題定位效率以及告警準確率，降低MTTI和MTTK。

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

上述我們知道目標是提升MTBF，降低MTTR基本是圍繞這“故障”這個維度來衡量的，但是系統什麼時候才是故障呢？

所以這裡我們需要有個判斷條件或者說是判斷標準，來界定“故障與否”

瞭解監控系統的同學們會知道“告警”了，就有可能發生“故障”，這裡用“有可能”是因為現實場景中通常下是不一定的。

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

而提到了SLO就不得不提其相關的 SLI 先。

什麼是SLI

建設監控系統的同學會知道，監控中對目標物件進行監控時會有大量的指標，但是很多指標的作用估計微乎其微。

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

能標識目標物件是否穩定
與使用者體驗強相關或使用者可以明顯感知的

所以SLI更能表達出“目標物件穩不穩定”。

VALET選擇法

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

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

透過以上類別可以快速區分出SLI，在實際使用場景上是一個非常實用的技巧。

但是這裡免不了的就是人工介入，無論是對現有指標的篩選，還是未來接入指標的篩選。

什麼是SLO

好，從SLI可以表達“目標物件穩不穩定“這點，我們就可以讓SLI + 目標 + 時間維度就能更精確的表達穩定性現狀

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

而其就是SLO。

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

但是會發現簡單的將單獨SLO作為“穩定性”的判斷標準，未免會陷入到監控領域類似的告警風暴和誤報這種困境中。

而現實中衡量業務穩定性時，我們通常會透過多個不同的判斷標準和依據來決定業務是否故障。

所以我們也可以透過組合多個SLO，採用與運算的方式，來更加精確的表達業務的穩定性

公式如：Availability = SLO1 & SLO2 & SLO3

所以得所有的 SLO 都達成才能算是達標！

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

關於時間維度

SLO中的時間維度可以分成持續時間和週期，用來覆蓋以下兩種場景

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

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

這裡可以理解為從SLI已經達不到所設閾值已經持續多長時間的角度，來界定這個SLO是否異常了。

比如設定1分鐘內請求成功率低於95%持續10分鐘就是異常，但是這樣的方式在時間細粒度上並不精細，比如出現1分鐘內請求成功頻率多發低於95%，但並沒有持續10分鐘，這樣其實算是有異常的需要關注的，所以可以利用請求維度進行補充。

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

這裡可以理解為在統計週期內SLI是否低於所設閾值，來界定SLO是否異常，比如1天內請求成功率低於95%就是異常。

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

關於SLO與可用性

可用性通常認識就是幾個9，比如 4個9、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 如下：

這樣可以將資料轉換成計分的形式，更加直觀而且感官衝擊力更加強。

所以我們可以透過應用 ErrorBudget 進行資料的歸一化的方式，更好的來推進穩定性目標的達成。

消費 ErrorBudget 資料

穩定性燃盡圖

利用ErrorBudget計分形式，使用柱狀圖形式圖表實時展示其狀態，當然得設定一個週期建議為4個自然周，週期後資料恢復。

對於特殊的場景，可以適當增大ErrorBudget，可以讓其場景合理化，但是還是具體情況具體分析。

故障定級

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

一般故障等級都會分成P0~P4五個級別，0為最高。

常見的故障等級設定如下：

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

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

穩定性共識機制

駕照記分制想必大家都不陌生，在等你發現計分剩下1分時，你開車就會非常的小心，避免犯規導致再教育或駕照吊銷。

所以你會發現ErrorBudget也是如此，一旦剩餘的數量不多時，你會提高警惕，制定相應的行動措施，來避免穩定性目標SLO不達標。

而如何制定行動措施呢？可以考慮以下兩個原則：

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

在日常我們會遇到網路抖動或裝置瞬時切換導致了極短暫系統不穩定，這時有極少一部分客戶反饋或業務使用時遇到了，結果就被投訴業務不穩定，然後技術人員就立刻放下手頭工作去排查問題，後續還要花大量的時間去覆盤總結和彙報。

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

總體來說價效比不高，而且是一個漣漪的擴散影響，這種事情一多了，估計就會引發”海嘯“了吧！

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

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

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

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

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

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

注意要點

這兩點其實是需要大家都要認可並執行的。因為這裡涉及的是多方配合協作問題，有同樣的共識才能保證工作協作上的流暢以及高效。

從多方協作這點出發看待，如果要推行該機制是需要”Top-DOwn“自上而下的，比如技術VP或CTO級別。

而且有問題時還可以逐步上升由CTO角度做決策。

基於錯誤預算的告警

在以往日常工作，經常會收到大量的告警簡訊，但是其價值非常低，導致的後果就是狼來了，大家都開始對告警產生了不信任。

其實這樣的後果是非常嚴重的，因為極有可能有用的資訊被淹沒了，導致業務利益受損，多方擔責。

當然業界也有解決方案，名為”告警收斂“

常用做法有讓相同相似告警合併後在傳送給通知人，比如同一叢集、同一異常告警

但是這種做法也會充斥著很多資訊，無法快速的定位到問題並處理，為什麼這樣說？

因為只是單純的將資訊合併了，資訊量還是沒有變化，除非是結合其他手段將資訊再提煉計算合併，比如所謂的告警決策樹，這樣的話會更加精準。

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

而採用基於錯誤預算告警的方式就能天然的做到告警收斂，因為他是基於業務的SLO的

這也表明我們只關注對穩定性造成影響的告警，而這類告警的出現我們是必須快速響應處理，而且這種告警數量不多

達到收斂效果的同時又非常精準。

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

限於篇幅，本文為節選，更多請看原文。

來源：

傳統運維將消失？體系化的 SRE 可靠性與連續性保障，瞭解一下？