[[361129]]

 可觀測性系統

在任何有一定規模的企業內部，一旦推行起來整個SRE的運維模式，那么對于可觀測性系統的建設將變得尤為重要，而在整個可觀測性系統中，通常我們會分為如下三個方面：

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

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

對于整個可觀測系統的建設，需要注意如下兩點：

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

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

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

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

故障響應

如果有什么東西出了故障，該如何提醒大家并做出回應？工具可以幫助解決這個問題，國為它可以定義提醒人類的規則。

故障響應是建立在使用可觀測性系統構建的數據之上，并借助反饋循環，來幫助我們加強對服務的監控。

故障響應通常包含如下幾個動作:

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

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

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

而對于整個告警系統來說，需要確保的是告警的有效性，否則，整個報警系統很有可能淪落為垃圾數據制造機，告警有效性意味著需要滿足如下兩個需求：

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

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

通常情況，在我們的各個可觀測系統構建完成后，可以通過整合到監控平臺中的各種監控數據，應用趨勢預測、短周期檢測、間歇性恢復、基線判斷、重復壓縮等算法和手段實現告警壓縮收斂，強化告警的有效性。

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

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

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

故障復盤

故障復盤就是對于過去的一些服務異常和服務中斷情況進行回顧和總結，以確保相同問題下次不會再出現。為了讓大家團結協作，我們希望建立一種無指責、透明的事后文化。個人不應該害怕事故，而是確信如果事故發生，團隊將會響應和改進系統。

備注: 其實在國內的SRE文化中，一般只有對大型，對業務有重大影響的事故才會進行復盤，但實際上如果在時間和經歷允許的情況下，對于一般的普通事故也應該在小范圍進行復盤，正所謂大的故障都是從不斷的小問題一點一點積累的。另外，其實對于運維相關的個人而言，我們也應當及時的進行小故障復盤，以不斷加強個人的故障處理和修復能力。

我認為SRE的一個關鍵共識正是承認了系統的不完美性，追求永不停機的系統是不現實的?；诓煌昝老到y，我們無可避免要面對和經歷系統故障與失敗。

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

備注: 通常很多企業內部在故障復盤過程中，相關人員可能將故障和失敗的根因追溯 不經意間 當做了故障定責和一系列的懲罰措施，通過一些懲戒措施來強行約定故障的發生，這種方式往往是非常不可取的，試想每個人都不想出現事故，要么是認知之外，要么是規則缺陷，永遠沒有一個人明知會有故障而偏偏去制造故障的。

需要牢記的是: 故障是我們可以從中學習的東西，而不是讓人害怕和羞恥的事情！

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

測試與發布

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

作為一個長期從事運維工作的人，可能內心中最為恐懼的莫過于新應用版本發布。因為除了硬件和網絡設備損壞這個屬于天災級別的概率事件外，新應用版本發布的第二天通常是停機與事故的高危期。所以，對于一些量級較大的產品通常會在節假日以及重要活動前夕進行封網操作，以避免新版本上線而導致的業務bug出現。

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

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

除了測試外，應用發布也是一項運維團隊通常要承擔的責任。SRE的一個原則是將一切可以重復性勞動代碼化和工具化；此外，應用發布的復雜程度往往與系統的復雜程度成正比。因此在應用系統上規模企業，往往已經著手基于自動化框架構建自動化的應用發布過程。

通過自動化發布工具，我們可以構建流水線實現部署的過程中所有的操作（如編譯打包、測試發布、生產準備、告警屏蔽、服務停止、數據庫執行、應用部署、服務重啟等）全部自動化。

容量規劃

容量規劃是關于預測未來和發現系統極限的，容量規劃也是為了確保系統可以隨著時間的推移得到完善和增強。

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

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

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

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

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

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

首先，運維平臺需要有極強的數據檢索能力。運維平臺存儲著海量的運維數據，運維人員為了嘗試建立和驗證一個探索性場景的時候，往往多次反復檢索和查詢特定數據。如果運維數據分析平臺的數據查詢很慢或者查詢角度很少的情況下，運維人員建立場景的時間就會拖得很長甚至進行不下去。因此，運維人員可通過平臺可以實現關鍵字、統計函數、單條件、多條件、模糊多維度查找功能，以及實現海量數據秒級查詢，才能更有效幫助運維人員更便捷分析數據。

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

自動化工具開發

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

通過編寫代碼把自己和其他人從重復的工作中解放出來，如果我們不需要人類來完成任務，那么就編寫代碼，這樣人類就不需要參與其中了。

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

自動化運維框架：

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

•  提高效率: 由程序自動化操作，有效地降低運維人力資源的投入，也讓運維人員的精力得以釋放并投向更為重要的領域。
•  操作的標準化: 將原來許多復雜、易錯的手工操作實現統一運維操作入口，實現運維操作白屏化，提升運維操作的可管理性；
•  同時，減少由于運維人員情緒帶來手工誤操作，避免“從刪庫到跑路”這樣的悲劇的發生。
•  運維經驗能力的傳承: 運維自動化工具將原來許多運維團隊積累的經驗以代碼方式總結為各種運維工具，實現自動化和白屏化的運維操作。運維團隊的后來者，可以有效地繼承、重復使用并優化它們。這種代碼化的工作傳承，將個人能力轉變為團隊能力，并減少人員流動帶來對工作的影響。

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

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

用戶體驗

用戶體驗這一層要說的是，作為SRE來講，從用戶的角度來保證業務的穩定性和可用性才是最終目標。這個才傳統意義上的運維人員是不會關注這一點的，因為大家通常只會考慮到我底層運維的系統或底層資源是否穩定，但實際上整個業務的穩定才是SRE需要關心的問題，而業務的穩定性和可用性通常需要站在用戶的角度來模擬和衡量整體的可用性和可靠性。

在前面提到的所有SRE相關的工作范疇，無論是監控、事故響應、回顧、測試與發布、容量規劃以及構建自動化工具，無非都是為了提供更好的系統用戶業務體驗而服務的。因此，我們在運維的過程中無不需要注意關注系統的用戶體驗。

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

這些用戶體驗的信息，對于運維團隊掌握客戶整體的用戶體驗情況、系統可用性的監測以及系統針對性的優化提供著無可替代的作用。

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