新炬首架梁铭图：从70万字SRE神作提炼出7千字精华与君共勉
梁銘圖
DBAplus社群（dbaplus)
讀完需要
20
分鐘速讀僅需 5 分鐘
作者介紹
梁銘圖，新炬網絡首席架構師，10年以上數據庫運維、數據分析、數據庫設計以及系統規劃建設經驗，在數據架構管理以及數據資產管理方面有深入研究。
讀《SRE Google運維解密》是我首次比較系統地了解和學習Google內部SRE運作的指導思想、實踐以及相關問題，最近又花了一些時間，仔細閱讀了關于SRE的第二本書籍《SRE生存指南》。
《SRE?Google運維解密》與《SRE生存指南》
SRE首先是一套方法論，它從傳統運維中與穩定性相關的工作內容提煉出來進行升華，構建了SRE的方法論體系。冗余和容災、容量規劃、系統自動保護、失敗預案、監控能力、發布與變更管理、故障應急處理等構成了SRE領域的藍圖，并不斷地快速迭代著。
方法論的落地實施離不開相關組織和個人，傳統的運維工程師在SRE方法論的熏陶下在系統可用性方面的技能得到了極大的提高，其中一部分傳統運維工程師“進化”成了技術含金量極高的SRE工程師，他們聚合在一起，構成了專職的SRE團隊。
同樣，方法論的落地還需要有一系列配套的技術產品和工具來支撐，與SRE相關的技術體系在近幾年也得到迅速發展，特別是隨著AI技術的發展、演進，兩者結合產生了奇妙的“化學反應”，使系統可用性保障的效率和性能都獲得了極大的提升。
書中的一些思路讓我對Google SRE這個龐大的運維體系有了全新的認識，里面許多的內容令人印象深刻，例如“Mikey金字塔”、“監控是研究一個系統運維的基礎”、“故障事后回顧”、“測試表明缺陷的存在，而不是不存在”等等觀點，對長期從事于運維這個行當的人來說應該會有不少啟發。
下文是我結合書中的理念和我們日常運維實踐作出的一些解讀，整理并供大家參考。
Mikey 金字塔
? ?
Mikey金字塔是由美國數字服務公司的Mikey Dickerson設計的。層次結構是為了說明，當嘗試提高系統可靠性時需要按部就班，在到達更高級別之前滿足每個低別級的要求。
Mikey金字塔
Mikey金字塔可以說是本書作者總結SRE運維體系的靈魂，自下而上分為監控、事故響應、事后回顧、測試與發布、容量規劃、構建工具、用戶體驗等七層。每一層都建立在前一層的基礎之上，每一層都被溝通這個基本要求所包圍。
從這個框架內容，我個人認為SRE運維所遵守幾個基本原則：
1）以業務連續性為目標
SRE的根本出發點和目標就是業務連續性。由于軟件做不到100%完全可靠，一方面，我們基礎設施做不到完美，各部分出故障是常態，這會影響到應用可用性；另一方面，我們的軟件是人編寫的，所以Bug不可避免，Bug出現也會引起異常停機。SRE做到的是盡可能快的發現和處理故障，并找到可能發生的故障，在預算范圍內以有用的方式優化應用、基礎設施，滿足用戶體驗的需求。
2）從技術到業務
從監控、事故響應、事后回顧、測試與發布、容量規劃、開發到用戶體驗這七層的遞進，可以看出SRE運維不只是單純的技術棧（主機、存儲、基礎軟件設施等）的設備運維，SRE還逐步延伸業務運維領域，管理應用發布、業務需求以及用戶對系統體驗的總體期望。這種從技術棧到業務棧的遞進，體現了SRE運維體系對傳統運維體系演進和拓展。
3）高度自動化和工具化
SRE本身是一個軟件工程師以軟件工程的方法解決運維問題的體系，因此就自身而言，SRE極度鄙視重復性的運維工作，更傾向于使用代碼的方式去應對各種重復性的運維操作。因此SRE運維體系是一個將自動化和工具化提高到戰略高度的運維體系模型，正如書中所言：“SRE的誕生是因為軟件工程師觸及了運維。目標是將50%的時間用于編寫代碼，30%時間用于與人打交道、20%時間用于應對緊急情況。”
4）預防與事故應對
盡管Mikey金字塔七層模型中仍然有監控、事件響度和事件回顧等層次，與當前傳統應對型運維體系有近似的地方。但是從整體上，SRE整個運維體系非常強調預防的重要性。通過事件回顧、測試與發布、容量規劃、開發等層次的工作來持續優化應用，提升系統的可靠性。“預防勝于治療”這句話，在IT系統建設和運維領域同樣適用。
5）平衡風險
SRE運維體系首先認定新業務需求和新軟件版本的發布無論如何總會引入bug；與此同時，較長的開發周期與更嚴密的測試會發現并修正bug，但是亦會延遲業務需求實現以及新版本發布的時間。快速實現業務需求與由于bug引起宕機的風險之間需要得到平衡。SRE通過制定合理的SLO以及錯誤預算，嘗試在系統風險與業務快速迭代之間實現可量化的平衡。
1
? ?
監控
第一層是監控，它確保你洞察系統，跟蹤系統的健康狀態、可用性以及系統內部發生的事情。監控兩個關鍵點：首先，需要確定質量標準是什么，并確保系統持續逼近或保持在質量標準極限范圍內。其次，需要系統地關注這項工作—而不應該只是隨機地查看一下系統。監控不僅僅是工具，因為它也需要溝通。
毫無疑問，系統監控是整個運維體系的基礎，它是最基本的運維工作。在自動化監控工具沒有完全普及的年代，人們已經用紙筆記錄著計算機上讀數和指標。隨著IT規模的不斷擴展，人們開始建設自動化的監控系統。如今，一個企業級的監控系統我認為至少應該包括如下幾個特征：
1）完備指標采集，可以對接企業內大部分的設備與技術棧相應的監控指標；同時，支持常見設備的監控指標體系，可以快速接入監控設備和指標，避免所有設備監控都是從頭構建。
2）日志采集能力，除了傳統的指標數據采集外，針對于目前顯得越來越重要的日志數據，監控工具也需要支持常見日志采集、切割、結構化以及入庫分析能力。
3）海量設備支持，企業IT系統數量和規模越來越大，因此監控系統比以前需要監控海量設備監控。
4）監控數據存儲和分析，監控數據是運維分析、運維自動化和智能化的基礎，因此海量監控數據存儲以及基于監控數據的可視化分析是一個監控系統的基本能力。
新炬網絡統一運維監控
監控是整個運維體系的基礎，它需要提供整個運維體系的數據化支持。因此，一個企業級的監控系統更應該是平臺化的。一方面可以通過配置或者開發實現更多 運維指標的接入；另一方面，亦可對接更多的專業運維工具，整合并打通多元的運維數據，為更多運維場景提供數據服務。從整體上，監控為企業運維提供了一個數據基礎，讓我們對事故響應以及容量預測等方面更多使用數據而非憑借以往經驗和拍腦袋做出決策。
2
? ?
事故響應
第二層是事故響應。如果有什么東西出了故障，該如何提醒大家并做出回應？工具可以幫助解決這個問題，國為它可以定義提醒人類的規則。事故響應是建立在使用監控構建的數據之上，并借助反饋循環，來幫助我們加強對服務的監控。
事故響應通常包括以下幾個動作：
關注，注意到有些東西不對勁
交流，告訴別人哪些東西不對勁
恢復，糾正不對勁的東西
事故響應往往始于簡單的一句告警信息或一個報障電話。因此，在監控系統的基礎上如何實現更有效率的告警和告警處理是故障響應和處理的重中之重。工具可以幫助解決這個問題，因為它可以定義提醒人類的規則。而大多數的事故響應都是關于定義處理策略和提供培訓的，以便人們在收到警報時知道該怎么做。
在長期的運維工作中，我認為有效的告警意味著：告警及時性，系統有問題需要及時通過告警信息告知運維處理人員及時處理告警；告警準確性，只要有告警信息系統必然出現問題。這意味著，錯誤報警等同于有問題但沒有報出來。因 為過多過頻繁甚至誤報的告警，讓運維人員的注意力迷失告警海洋當中。抑制和消除無效的告警，讓運維人員不被告警風暴所吞沒，也是告警管理中重點建設的內容。
從日常運維實踐中，我們往往可以通過整合到監控平臺中的各種監控數據，應用趨勢預測、短周期檢測、間歇性恢復、基線判斷、重復壓縮等算法和手段實現告警壓縮收斂，強化告警的有效性。
告警壓縮與收斂
同時，面向一線使用人員的場景，我們又往往根據綜合同一個系統或設備的多個監控指標進行綜合性建模和分析，匯總成一個健康度的分值，給予一線運維人員系統的基于健康度的系統分層評價體系，真實、直觀反映系統運行狀態，實現問題快速定界。
系統健康度指標
最后，對于常見告警信息，我們也往往會對接一些配置化的自動化處理動作，例如，一些特殊的應急處理手段（某個文件系統快滿了，清理掉當中沒有價值的文件）或者一些關鍵故障信息采集（出現死鎖的數據庫里面，自動采集引起死鎖的進程信息）作供運維人員進一步分析和確認使用。
3
? ?
事后回顧
第三層是事后回顧。一旦發生服務中斷，那么如何確保問題不會再次發生？為了讓大家團結協作，我們希望建立一種無指責、透明的事后文化。個人不應該害怕事故，而是確信如果事故發生，團隊將會響應和改進系統。
我認為SRE的一個關鍵共識正是承認了系統的不完美性，追求永不停機的系統是不現實的。基于不完美系統，我們無可避免要面對和經歷系統故障與失敗。所以我們重要的并非找到為這個故障責任的這個人或者那個人，而是更應該創根問底地復盤這個故障和失敗的根本原因是什么，以及如何避免再次出現相同的故障。系統可靠性是整個團隊共同奮斗的方向，從失敗中快速恢復并吸取教訓，每個人放心地提出問題，應對停機，并努力改進系統。
事故是我們可以從中學習的東西，而不是讓人害怕和羞恥的事情！
在日常運維過程中，出現故障等事故對于我們而言其實是一個很好的復盤學習機會。通過歷史監控數據，分析事故其中的根本原因，制定后續應對策略，并且通過運維平臺將這些應對策略編輯成標準化、可重用、自動化的運維應用場景，為后續相同問題的處理提供標準且快捷的解決方案。這正是事后回顧這個過程最真實的價值體現。
此外，事故響應建立在使用監控構建的數據之上，并借助反饋循環，來幫助我們加強對服務的監控。這向我們展示了什么是重要的。因為如果沒有得到警報，而是有人告訴我們服務沒有正常工作，那么我們的監控就是不到位的。
4
? ?
測試與發布
第四層是測試和發布軟件。這個層級是Mikey金字塔中第一個專注于預防而不是事后處理的層級。預防是指嘗試限制發生的事故數量，并確保在發布新代碼時基礎架構和服務能夠保持穩定。
在《SRE Google運維解密》，我首次接觸了基于服務水平目標（SLO）而制定的錯誤預算（Error Budget）。《SRE生存指南》本書則是通過測試與發布這個章節提供了一個更為具像化的案例。
作為一個長期從事運維工作的人，可能內心中最為恐懼的莫過于新應用版本發布。因為除了硬件和網絡設備損壞這個屬于天災級別的概率事件外，新應用版本發布的第二天通常是停機與事故的高危期。以電信運營商行業為例，在一些系統穩定性要求特別高的日子如春節、國慶、奧運會等重大節日或者特別時期，往往有所謂封網的行為，其實質就是通過拒絕非緊急Bug和業務功能上線來提升一段特殊時期內的系統可靠性。正如書中所說，測試是在成本和風險之間找到適當的平衡活動。如果過于冒險，你們可能就會疲于應付系統失敗；反過來說，如果你太保守，你就不能足夠快地發布新東西，讓企業在市場上生存下來。
在錯誤預算比較多（即在一段時間內故障導致系統停機時長較少）的情況下，可以適當減少測試資源并放寬系統上線的測試和條件，讓業務可以有更多的功能上線，以保持業務的敏態；在錯誤預算比較少（即在一段時間內故障導致系統停機時長較多）的情況下，則要增加測試資源并收緊系統上線的測試，讓系統的潛在風險得到更多有效的釋放，避免系統停機保持系統的穩態。這種敏態與穩態之間的平衡，需要整個運維與開發團隊來共同承擔。
除了測試外，應用發布也是一項運維團隊通常要承擔的責任。SRE的一個原則是將一切可以重復性勞動代碼化和工具化；此外，應用發布的復雜程度往往與系統的復雜程度成正比。因此在應用系統上規模企業，往往已經著手基于自動化框架構建自動化的應用發布過程。
新炬網絡基于自動化框架的應用發布
通過自動化發布工具，我們可以構建流水線實現部署的過程中所有的操作（如編譯打包、測試發布、生產準備、告警屏蔽、服務停止、數據庫執行、應用部署、服務重啟等）全部自動化，無需人工手工干預解決以往手工發布存在問題：
整個過程都需要人員參與，占用大量的時間，效率低下
上線、更新、回滾速度慢
規范化低，存在一定的管理混亂，人為誤操作的機率增大
5
? ?
容量規劃
第五層是容量規劃。關于預測未來和發現系統極限的。容量規劃也是為了確保系統可以隨著時間的推移得到完善和增強。規劃的主要目標是管理風險和期望。對于容量規劃，涉及到將容量擴展到整個業務。所關注的期望是人們在看到業務增長時期望服務如何響應。風險是在額外的基礎設施上花費時間和金錢來處理這個問題。
容量規劃首先是對未來預測性的分析與判斷，其預測的基礎正是海量的運維數據。因此，容量規劃除了有相應的架構和規劃團隊外，一個全面的運維數據中心是實現系統容量規劃的必須設施。
容量趨勢分析和預警
它將綜合地從各種運維監控、流程管理等數據源中收集、整理、清洗并結構化地存儲各種運維數據，將這些來自于各種工具的運維數據打通融合并且構建各種數據主題。應用這些數據主題的數據用于幫助運維人員對問題進行評估，包括：
當前的容量是多少
何時達到容量極限
應該如何更改容量
執行容量規劃
運維平臺除了可以提供必要的數據支持外，還需要提供必要的數據可視化支持能力。運維數據可視化提供了一些必要的能力保障運維人員可以更好地利用其中的運維數據評估容量。
運維數據可視化分析
首先，運維平臺需要有極強的數據檢索能力。運維平臺存儲著海量的運維數據，運維人員為了嘗試建立和驗證一個探索性場景的時候，往往多次反復檢索和查詢特定數據。如果運維數據分析平臺的數據查詢很慢或者查詢角度很少的情況下，運維人員建立場景的時間就會拖得很長甚至進行不下去。因此，運維人員可通過平臺可以實現關鍵字、統計函數、單條件、多條件、模糊多維度查找功能，以及實現海量數據秒級查詢，才能更有效幫助運維人員更便捷分析數據。
其二，平臺需要強大的數據可視化能力。人們常說“千言萬語不及一圖”，運維人員經常會通過各系統的運維數據進行統計分析并生成各類實時報表，對各類運維數據（如應用日志、交易日志、系統日志）進行多維度、多角度深入分析、預測及可視化展現，將他們分析的預測結果和經驗向他人表達和推廣。
6
? ?
構建工具
第六層是開發新工具和服務。SRE不僅涉及運營，還涉及軟件開發。SRE工程師將花費大約一半的時間來開發新的工具和服務。這些工具中的一部分將用于自動 化一些手工任務，而其他工具將用于改進Mikey金字塔的其余部分。通過編寫代碼把自己和其他人從重復的工作中解放出來。如果我們不需要人類來完成任務，那么就編寫代碼，這樣人類就不需要參與其中了。
SRE從內心上鄙視重復性的工作，將從原有的人工加被動響應，轉變為更高效、更為自動化的運維體系。事實上，在我們負責運維的客戶中，IT系統規模的增速已經遠遠超越由于運維團隊規模的增長。例如,一些電信運營商企業連每天早上大規模營業前對所有IT系統的設備進行一次常規狀態檢查都難以維持。為解決這個矛盾，專門部署并開發了我們的自動化監控和運維工具，將這些每天重復性的大量機械性操作交由機器實現。只需要定義好相關的巡檢模板，機器就會十年如一日地按照我們定義的規范進行各種巡檢操作。如巡檢結果中出現任何異常，運維人員的手機就會出現該問題的告警短信，通知相關運維人員處理。
新炬網絡自動化運維框架
構建自動化運維工具，其優勢在于：
1）讓機器管理機器，將大量重復、機械的運維工作交給機器執行，有效地降低運維人力資源的投入，也讓運維人員的精力得以釋放并投向更為重要的領域。
2）運維操作的標準化，將原來許多復雜、易錯的手工操作實現統一運維操作入口，實現運維操作白屏化，提升運維操作的可管理性；同時，減少由于運維人員情緒帶來手工誤操作，避免“從刪庫到跑路”這樣的悲劇的發生。
3）運維經驗能力的傳承，運維自動化工具將原來許多運維團隊積累的經驗以代碼方式總結為各種運維工具，實現自動化和白屏化的運維操作。運維團隊的后來者，可以有效地繼承、重復使用并優化它們。這種代碼化的工作傳承，將個人能力轉變為團隊能力，并減少人員流動帶來對工作的影響。
構建自動化運維體系就必須以運維場景為基礎，這些運維場景是在本企業內反復迭代和打造，是企業中最常用的運維場景。例如上文提到的自動化巡檢、軟件安裝部署、應用發布交付、資產管理、告警自動處理、故障分析、資源開通等。所以，自動化運維應支持多種不同類型的自動化作業配置能力，通過簡單的腳本開發、場景配置和可視化定制流程實現更多運維場景的實現。
7
? ?
用戶體驗
最后一層是用戶體驗，即確保用戶獲得良好的體驗。與用戶研究人員合作，以及確保良好的用戶體驗。這與SRE有兩種關系。首先，我們需要支持我們所支持的系統的用戶體驗。例如，確保應用程序具有響應性和可用性，可以讓用戶獲得一致的體驗。其次，我們的工具需要提供良好的體驗。良好的體驗意味著我們構建和支持的服務的用戶愿意使用它們。
用戶體驗的管理是SRE的最高層次實現，它實際上正是運維的最終目標。此前的層次，無論是監控、事故響應、回顧、測試與發布、容量規劃以及構建自動化工具，無非都是為了提供更好的系統用戶業務體驗而服務的。因此，我們在運維的過程中無不需要注意關注系統的用戶體驗。例如，在實際運維工作中，我們往往可以通過應用日志、監控數據、業務拔測等業務相關的用戶體驗信息。在運維數據平臺中，通過這些用戶體驗監測數據之間的關聯和串聯，重現用戶的最終業務調用鏈路以及各應用環節對性能數據的關系。最終形成從業務用戶體驗數據入手，逐步實現系統運行狀態數據、設備運行狀態數據鏈路的打通，讓運維體系實現以最終用戶體驗為中心的目標。
這些用戶體驗的信息，對于運維團隊掌握客戶整體的用戶體驗情況、系統可用性的監測以及系統針對性的優化提供著無可替代的作用。
8
? ?
寫在最后
SRE是Google這類典型國外互聯網企業的運維體系建設理念。我認為與傳統以設備為中心的運維體系不同，SRE運維體系更為強調以用戶的體驗為核心，以自動化和運維數據為手段，實現應用業務連續性保障。與其說是系統運維，不如說是系統運營體系或會更為適當。
當然，不同的企業會有其自身不同的文化、制度和背景，SRE這套運維體系不能生搬硬套。但是里面提到的很多理念和方法，還是很值得我們借鑒的。如果大家有機會詳細閱讀本書，亦希望能分享一下你們的見解。
廣而告之
隨著人工智能的興起，運維迎來了新的契機，想破解運維轉型困局，讓Gdevops全球敏捷運維峰會北京站給你新思路：
《浙江移動AIOps實踐》浙江移動云計算中心NOC及AIOps負責人 潘宇虹
《數據智能時代：構建能力開放的運營商大數據DataOps體系》中國聯通大數據基礎平臺負責人/資深架構師 尹正軍
《云時代下，傳統行業的運維轉型，如何破局？》新炬網絡董事/副總經理 程永新
《銀行日志監控系統優化手記》中國銀行DevOps負責人 付大亮和中國銀行 高級軟件工程師 李曉寧
《民生銀行智能運維平臺實踐之路》民生銀行智能運維平臺負責人/應用運維專家 張舒偉
《建設敏捷型消費金融中臺及云原生下的DevOps實踐》中郵消費金融總經理助理 李遠鑫
讓我們在新技術的沖擊下站穩腳跟，攀登運維高峰！那么2020年9月11日，我們在北京不見不散。
9
? ?
推薦閱讀
中生代技術社區提供內推服務，對應BAT，網易，頭條等大廠對接到用人部門，
有需求請添加群合伙人大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
? ?END ? ?? #接力技術，鏈接價值#總結
以上是生活随笔為你收集整理的新炬首架梁铭图：从70万字SRE神作提炼出7千字精华与君共勉的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： nyoj 61 传纸条（一） （双线动归
- 下一篇： Jeecg-boot 2.4.6+ 多租