什麼是 SRE？一文詳解 SRE 運維體系

可觀測性系統

在任何有必定規模的企業內部，一旦推行起來整個SRE的運維模式，那麼對於可觀測性系統的建設將變得尤其重要，而在整個可觀測性系統中，一般咱們會分爲以下三個方面：

• 指標監控：即各類指標監控，好比基礎資源指標，服務性能指標，業務的調用指標。
• 日誌：各類設備以及服務的運行日誌監控。
• 調用鏈：業務層面的調用鏈分析，一般在分佈式系統中幫助運營、開發以及運維人員快速識別總體調用的瓶頸點

一整套的可觀測系統，它能確保你洞察系統，跟蹤系統的健康狀態、可用性以及系統內部發生的事情。

對於整個可觀測系統的建設，須要注意以下兩點：

• 肯定質量標準是什麼，並確保系統持續逼近或保持在質量標準極限範圍內
• 系統地關注這項工做—而不該該只是隨機地查看一下系統

在整個企業級可觀測系統中，我認爲至少應該包括以下幾個特徵：

• 完備指標採集：能夠對接企業內大部分的設備與技術棧相應的監控指標；同時，支持常見設備的監控指標體系，能夠快速接入監控設備和指標，避免全部設備監控都是從頭構建；對於日誌數據的採集支持
• 海量設備支持：企業IT系統數量和規模愈來愈大，所以監控系統比之前須要監控海量設備監控。
• 監控數據存儲和分析：監控數據是運維分析、運維自動化和智能化的基礎，所以海量監控數據存儲以及基於監控數據的可視化分析是一個監控系統的基本能力。
• 可觀測系統是整個運維體系的基礎，它須要提供整個運維體系的數據化支持。

所以，一個企業級的可觀測性系統應該是平臺化的。一方面能夠經過配置或者開發實現更多 運維指標的接入；另外一方面，亦可對接更多的專業運維工具，整合並打通多元的運維數據，爲更多運維場景提供數據服務。從總體上，可觀測性系統爲企業運維提供了一個數據基礎，讓咱們對事故響應以及容量預測等方面更多使用數據而非憑藉以往經驗和拍腦殼作出決策。

故障響應

若是有什麼東西出了故障，該如何提醒你們並作出迴應？工具能夠幫助解決這個問題，國爲它能夠定義提醒人類的規則。

故障響應是創建在使用可觀測性系統構建的數據之上，並藉助反饋循環，來幫助咱們增強對服務的監控。

故障響應一般包含以下幾個動做:

• 關注: 不管是主動發現瓶頸點或異常點，仍是經過可觀測性系統被動暴露瓶頸點，咱們都應該進行主動關注
• 交流: 及時將觀察到風險點通知到相關方，並告知影響面以及相關的補救措施
• 恢復: 三方達成一致後，根據補救措施進行修復相關風險點和異常點

須要注意的是，若是在前期整個可觀測性系統可以作好，一般故障應當始於一個簡單的告警信息或一個報障電話，所以，一般狀況下，可觀測系統作的足夠好僅能起到追溯和排查的做用，可是沒法起到及時發現的做用，此時就須要依賴於各個觀測數據進行計算和評估告警，以及時將相關的告警通知到相關人，以暴露風險點。

告警只是整個故障響應的第一個環節，解決的是故障如何發現的問題，而大多數的故障響應工做都是關於定義處理策略和提供培訓的，以便人們在收到警報時知道該怎麼作，一般這部分更多的是過去歷史經驗和運維經歷的總結和沉澱，包括經驗的一些抽象和工具化沉澱，以保證故障響應的效率和廣泛化(即不依賴人爲經驗)。

而對於整個告警系統來講，須要確保的是告警的有效性，不然，整個報警系統頗有可能淪落爲垃圾數據製造機，告警有效性意味着須要知足以下兩個需求：

• 告警及時性: 系統有問題須要及時經過告警信息告知運維處理人員及時處理告警;
• 告警準確性: 只要有告警信息系統必然出現問題(對於不少企業可能存在大量的無用告警，好比磁盤問題，mem等相關問題，固然這裏涉及到了自動化、業務形態、告警閾值的問題);

在整個運維過程當中，咱們常常會發現有大量的可有可無的告警信息，讓運維人員的注意力迷失在告警海洋當中，而一般非運維領域的領導會關注整個告警的響應程度，所以，抑制和消除無效的告警，讓運維人員不被告警風暴所吞沒，也是告警管理中重點建設的內容。

一般狀況，在咱們的各個可觀測系統構建完成後，能夠經過整合到監控平臺中的各類監控數據，應用趨勢預測、短週期檢測、間歇性恢復、基線判斷、重複壓縮等算法和手段實現告警壓縮收斂，強化告警的有效性。

同時，面向一線的運維人員，咱們須要根據同一個系統或設備的多個監控指標進行綜合性建模和分析，彙總成一個健康度的分值，給予一線運維人員系統的基於健康度的系統分層評價體系，真實、直觀反映系統運行狀態，實現問題快速定界。

好比，經過基礎資源的多個指標進行綜合加權計算來總體評估該資源的利用率；經過一個應用關聯的所有資源的資源利用率以及應用的運維架構總體建模分析來計算一個分值來總體評估該應用的健康程度。

這個過程若是作得成熟一些，能夠根據內部已有的解決方案和告警進行閉環打通，一個簡單的場景就是，當磁盤滿時，告警會首先觸發一次標準化的磁盤巡檢，並進行相關的可丟棄數據的刪除，若是依然沒法解決該報警，下次可直接關聯到一線運維進行人工干預，以後進行標準化經驗總結。

故障覆盤

故障覆盤就是對於過去的一些服務異常和服務中斷狀況進行回顧和總結，以確保相同問題下次不會再出現。爲了讓你們團結協做，咱們但願創建一種無指責、透明的過後文化。我的不該該懼怕事故，而是確信若是事故發生，團隊將會響應和改進系統。

備註: 其實在國內的SRE文化中，通常只有對大型，對業務有重大影響的事故纔會進行復盤，但實際上若是在時間和經歷容許的狀況下，對於通常的普通事故也應該在小範圍進行復盤，正所謂大的故障都是從不斷的小問題一點一點積累的。另外，其實對於運維相關的我的而言，咱們也應當及時的進行小故障覆盤，以不斷增強我的的故障處理和修復能力。

我認爲SRE的一個關鍵共識正是認可了系統的不完美性，追求永不停機的系統是不現實的。基於不完美系統，咱們無可避免要面對和經歷系統故障與失敗。

因此咱們重要的並不是找到爲這個故障責任的這我的或者那我的，而是更應該創根問底地覆盤這個故障和失敗的根本緣由是什麼，以及如何避免再次出現相同的故障。系統可靠性是整個團隊共同奮鬥的方向，從失敗中快速恢復並吸收教訓，每一個人放心地提出問題，應對停機，並努力改進系統。

備註: 一般不少企業內部在故障覆盤過程當中，相關人員可能將故障和失敗的根因追溯 不經意間 當作了故障定責和一系列的懲罰措施，經過一些懲戒措施來強行約定故障的發生，這種方式每每是很是不可取的，試想每一個人都不想出現事故，要麼是認知以外，要麼是規則缺陷，永遠沒有一我的明知會有故障而恰恰去製造故障的。

須要牢記的是: 故障是咱們能夠從中學習的東西，而不是讓人懼怕和羞恥的事情！

在平常運維過程當中，出現故障等事故對於咱們而言實際上是一個很好的覆盤學習機會。經過歷史監控數據，分析事故其中的根本緣由，制定後續應對策略，而且經過運維平臺將這些應對策略編輯成標準化、可重用、自動化的運維應用場景，爲後續相同問題的處理提供標準且快捷的解決方案。這正是過後回顧這個過程最真實的價值體現。

測試與發佈

測試與發佈對於整個穩定性和可靠性的主要出於一個預防的做用，預防是指嘗試限制發生的事故數量，並確保在發佈新代碼時基礎架構和服務可以保持穩定。

做爲一個長期從事運維工做的人，可能心裏中最爲恐懼的莫過於新應用版本發佈。由於除了硬件和網絡設備損壞這個屬於天災級別的機率事件外，新應用版本發佈的次日一般是停機與事故的高危期。因此，對於一些量級較大的產品一般會在節假日以及重要活動前夕進行封網操做，以免新版本上線而致使的業務bug出現。

而測試是在成本和風險之間找到適當的平衡活動。若是過於冒險，大家可能就會疲於應付系統失敗；反過來講，若是你太保守，你就不能足夠快地發佈新東西，讓企業在市場上生存下來。

在錯誤預算比較多（即在一段時間內故障致使系統停機時長較少）的狀況下，能夠適當減小測試資源並放寬系統上線的測試和條件，讓業務能夠有更多的功能上線，以保持業務的敏態；在錯誤預算比較少（即在一段時間內故障致使系統停機時長較多）的狀況下，則要增長測試資源並收緊繫統上線的測試，讓系統的潛在風險獲得更多有效的釋放，避免系統停機保持系統的穩態。這種敏態與穩態之間的平衡，須要整個運維與開發團隊來共同承擔。

除了測試外，應用發佈也是一項運維團隊一般要承擔的責任。SRE的一個原則是將一切能夠重複性勞動代碼化和工具化；此外，應用發佈的複雜程度每每與系統的複雜程度成正比。所以在應用系統上規模企業，每每已經着手基於自動化框架構建自動化的應用發佈過程。

經過自動化發佈工具，咱們能夠構建流水線實現部署的過程當中全部的操做（如編譯打包、測試發佈、生產準備、告警屏蔽、服務中止、數據庫執行、應用部署、服務重啓等）所有自動化。

容量規劃

容量規劃是關於預測將來和發現系統極限的，容量規劃也是爲了確保系統能夠隨着時間的推移獲得完善和加強。

規劃的主要目標是管理風險和指望，對於容量規劃，涉及到將容量擴展到整個業務；所關注的指望是人們在看到業務增加時指望服務如何響應。風險是在額外的基礎設施上花費時間和金錢來處理這個問題。

容量規劃首先是對將來預測性的分析與判斷，其預測的基礎正是海量的運維數據。所以，容量規劃除了有相應的架構和規劃團隊外，一個全面的運維數據中心是實現系統容量規劃的必須設施。

容量趨勢預警和分析將綜合地從各類運維監控、流程管理等數據源中收集、整理、清洗並結構化地存儲各類運維數據，將這些來自於各類工具的運維數據打通融合而且構建各類數據主題。

應用這些數據主題的數據用於幫助運維人員對問題進行評估，包括：

• 當前的容量是多少
• 什麼時候達到容量極限
• 應該如何更改容量
• 執行容量規劃

運維平臺除了能夠提供必要的數據支持外，還須要提供必要的數據可視化支持能力。運維數據可視化提供了一些必要的能力保障運維人員能夠更好地利用其中的運維數據評估容量。

首先，運維平臺須要有極強的數據檢索能力。運維平臺存儲着海量的運維數據，運維人員爲了嘗試創建和驗證一個探索性場景的時候，每每屢次反覆檢索和查詢特定數據。若是運維數據分析平臺的數據查詢很慢或者查詢角度不多的狀況下，運維人員創建場景的時間就會拖得很長甚至進行不下去。所以，運維人員可經過平臺能夠實現關鍵字、統計函數、單條件、多條件、模糊多維度查找功能，以及實現海量數據秒級查詢，才能更有效幫助運維人員更便捷分析數據。

其二，平臺須要強大的數據可視化能力。人們常說「千言萬語不及一圖」，運維人員常常會經過各系統的運維數據進行統計分析並生成各種實時報表，對各種運維數據（如應用日誌、交易日誌、系統日誌）進行多維度、多角度深刻分析、預測及可視化展示，將他們分析的預測結果和經驗向他人表達和推廣。

自動化工具開發

SRE不只涉及運營，還涉及軟件開發，固然這部分指的是和運維以及SRE領域相關的工具和平臺開發。在Google的SRE體系中，SRE工程師將花費大約一半的時間來開發新的工具和服務，這些工具的一部分用於自動化一些手動任務，而其餘部分用於來不斷填補和修復整個SRE體系內部的其餘系統。

經過編寫代碼把本身和其餘人從重複的工做中解放出來，若是咱們不須要人類來完成任務，那麼就編寫代碼，這樣人類就不須要參與其中了。

SRE從心裏上鄙視重複性的工做，將從原有的人工加被動響應，轉變爲更高效、更爲自動化的運維體系。

自動化運維框架：

自動化運維工具的優點和必要性:

• 提升效率: 由程序自動化操做，有效地下降運維人力資源的投入，也讓運維人員的精力得以釋放並投向更爲重要的領域。
• 操做的標準化: 將原來許多複雜、易錯的手工操做實現統一運維操做入口，實現運維操做白屏化，提高運維操做的可管理性；

  同時，減小因爲運維人員情緒帶來手工誤操做，避免「從刪庫到跑路」這樣的悲劇的發生。

• 運維經驗能力的傳承: 運維自動化工具將原來許多運維團隊積累的經驗以代碼方式總結爲各類運維工具，實現自動化和白屏化的運維操做。運維團隊的後來者，能夠有效地繼承、重複使用並優化它們。這種代碼化的工做傳承，將我的能力轉變爲團隊能力，並減小人員流動帶來對工做的影響。

構建自動化運維體系就必須以運維場景爲基礎，這些運維場景是在本企業內反覆迭代和打造，是企業中最經常使用的運維場景。

好比常見的運維場景：軟件安裝部署、應用發佈交付、資產管理、告警自動處理、故障分析、資源申請、自動化巡檢等等。所以，整個自動化運維體系建設時也應支持多種不一樣類型的自動化做業配置能力，經過簡單的腳本開發、場景配置和可視化定製流程實現更多運維場景的實現。

用戶體驗

用戶體驗這一層要說的是，做爲SRE來說，從用戶的角度來保證業務的穩定性和可用性纔是最終目標。這個才傳統意義上的運維人員是不會關注這一點的，由於你們一般只會考慮到我底層運維的系統或底層資源是否穩定，但實際上整個業務的穩定纔是SRE須要關心的問題，而業務的穩定性和可用性一般須要站在用戶的角度來模擬和衡量總體的可用性和可靠性。

在前面提到的全部SRE相關的工做範疇，不管是監控、事故響應、回顧、測試與發佈、容量規劃以及構建自動化工具，無非都是爲了提供更好的系統用戶業務體驗而服務的。所以，咱們在運維的過程當中無不須要注意關注系統的用戶體驗。

而在實際運維工做中，咱們每每能夠經過應用日誌、監控數據、業務拔測等業務相關的用戶體驗信息。在運維數據平臺中，經過這些用戶體驗監測數據之間的關聯和串聯，重現用戶的最終業務調用鏈路以及各應用環節對性能數據的關係。最終造成從業務用戶體驗數據入手，逐步實現系統運行狀態數據、設備運行狀態數據鏈路的打通，讓運維體系實現以最終用戶體驗爲中心的目標。

這些用戶體驗的信息，對於運維團隊掌握客戶總體的用戶體驗狀況、系統可用性的監測以及系統針對性的優化提供着無可替代的做用。

其實，SRE運維體系更爲強調以用戶的體驗爲核心，以自動化和運維數據爲手段，實現應用業務連續性保障，從這個點出發，咱們會發現和以往的傳統運維仍是有很大的區別的，咱們再也不僅僅是單純的安裝和部署工程師，咱們須要經過一系列的技術手段來不斷保障上層業務的穩定性和可靠性。

_來自：BGBiao的SRE人生
連接：https://bgbiao.top/post/sre運...