自動化演進在SRE中的應用

導讀	SRE 是 Site Reliability Engineering 的簡稱，它是源起於谷歌內部產品技術保障過程中演進而來的運維新模型，並且定義了新職位的職責範圍。有別於傳統運維模式，SRE 強調自動化系統，主張透過軟體工程方式開發出一些場景化的自動化維運工具來取代重複和手動操作。本場Chat中我們將透過一些國外 SRE 實務的案例來介紹一下 SRE 自動化的演進。

內容包括：
自動化系統對 SRE 的價值；
自動化系統演進的歷程；
國外網路企業 SRE 自動化應用案例；
國內運維領域自動化實踐。

一、什麼是 SRE ？

SRE是Site Reliability Engineering的簡稱，它是源起於國外網路企業的一個詞語或新定義的職位。在傳統的系統管理員模式時代這個角色我們叫運維，國外稱做Operation。

Google SRE的VP叫Ben Treynor，2003年的時候他加入公司第一個任務就是組成7人的「生產維運小組」。但很快他發現根據Google機器增加的速度，按照傳統的維運模式是無法快速滿足維運可靠需求的。由於他自己本身就是一個資深的軟體開發人員，他就按照組建一個研發團隊一樣來組成這個維運團隊。招收了許多研發工程師，這些工程師具有開發能力，並且了解一些系統管理的知識，最主要的是他們鄙視重複勞動。他們把一些最佳實踐、方式、流程、方法都固化成程式碼，用這種方式去應對規模性的擴張，去面對複雜度的上升。

二、自動化系統對SRE的價值

典型的SRE活動分為：軟體工程、系統工程、瑣事、流程負擔四個部分。其中我們可以看到有一類工作它與日常維運服務直接相關，但是在SRE裡面被定義為低效工作，在谷歌還是用一個專門的詞語-瑣事（Toil）來進行描述。

瑣事是維運服務中手動的，重複的，戰術性的工作。它的成長與服務的成長呈線性關係。這一部分的工作是可以被自動化的。 Google公開提出SRE要確保至少50%的時間在軟體工程專案上，因為如果不加以控制，瑣事會變得越來越多，並迅速佔據SRE人員的大部分時間。減少瑣事和擴大服務規模的工作就是SRE中的E(Engineering)。

從這張片子我們可以看出自動化對於SRE而言的價值主要來自於效能和效率兩方面。提到自動化很多人肯定首先想到的是效率的提升，其實相對單純提升效率而言SRE人員更強調系統效能和快速彈性之間的平衡。自動化透過剔除作業中由於使用人工手動執行帶來的不一致性，確保「一致性地執行範圍明確、步驟已知的程序」以保障系統效能，這才是自動化的首要價值。

自動化系統可以提供一個可以擴充的、廣泛適用的平台。平台可以將問題集中化，規模化地處理系統的錯誤，也能比人能更持續更頻繁地運作任務。而且由於平台可以暴露自身的效能指標，也可以幫助我們發現先前流程中不易察覺的細節。當然平台化的基礎在於正確地設計與實現。而自動化對於效率帶來的提升我們就更容易理解。雖然我們經常會對比分析編寫一個自動化程序所花費的精力和時間和取消手動節省的部分，但是應該看到一旦自動化得以實現，將會把某個操作與具體的操作者解耦，所以在我們進行衡量的時候，自動化所節省的時間和精力應該是來自於所有的使用者。

一位負責Google資料中心叢集上線流程的SRE，Joseph Bironas,曾經說過：「如果我們持續產生不可自動化的流程和解決方案，我們就繼續需要人來進行系統維護。如果我們要雇用人來做這項工作，就像是在用人類的鮮血、汗水和眼淚來養活機器。這就像是一個沒有特效但是充滿了憤怒的系統管理員的Matrix世界。」

三、自動化演進的歷程

Google SRE的自動化歷程經歷了以上幾個階段。第一階段是完全依賴手動操作的無自動化階段，然後使用外部維護的特定係統的自動化腳本來進行操作，特定的系統自動化逐步演進為通用的系統自動化，然後用內部維護的自動化系統取代外部維護的自動化系統，最終演化為納入維運平台無需人工觸發的自動化系統。

四、 國外網路企業 SRE 自動化應用案例

Google的資源管理系統Borg就是一套典型的GoogleSRE長期使用的自動化應用程式發布系統。為什麼資源管理這麼重要，因為規模太大，營運成本成為演進的唯一障礙。從技術上來講，統一的資源管理系統非常難實現，基礎設施的好壞決定了這個系統的能力。尤其在分散式環境下，不同業務場景下對實體伺服器的要求也不完全一樣。谷歌的Borg能做到統一的資源管理的前提，就是有GoogleFS、BigTable、Chubby、GSLB等核心技術的支撐，SRE是此系統的使用者，為了系統可靠性不斷的回饋和改進Borg系統的使用要求，得以至今Borg仍是Google內部使用的應用程式發布系統。

首先，Borg系統是完全分層的系統架構。從最基礎的檔案系統到最上面的負載分流，每層的技術堆疊在Google內部都是唯一的，這樣做的好處是可以累積經驗復用。國內企業的系統架構，在發展過程中也會經歷分層組織的架構，拋開人的因素，很多分層是多套系統組合在一起搭建而成。從表面來看，我們降低了成本，但其實增加了人力的維護成本。在這個問題點上，國外系統的先進性可以放一放，我們在選擇科技的時候該怎麼辦？從經驗上來講，同儕分享的拼接多套開源系統所組成的一層體係是一種走捷徑的辦法，短期效應明顯。一旦企業業務高速發展，每次重構都是毀滅性的推倒重來工具。從我經歷的大大小小多種企業系統中，我深刻體會出這種改變動力。在SRE裡面，工具的變革思維不是用新的開源工具取代舊的開源工具，而是我們的可靠性訴求應該簡化工具選型的數量，並在此基礎上真正的考慮自己的需求，最終還是要走向自研的自動化系統的道路。

第二，Borg系統的基礎架構技術夠先進，是不是SRE有點多餘？顯然，技術的先進並不能取代SRE的方法論。目前業界最受歡迎的DevOps概念中並沒有更多關於成本、可靠性的描述，重點關心的是自動化、提高生產力等種種實踐。這些實務解決不了業務場景持續發展的最核心問題，就是業務可靠性與成本控制之間的製衡。 SRE的方法就是為了用最低的成本來獲得最大的業務利益。所以，SRE崗位招募的是一個會寫程式的系統維運工程師，如果只是做運維，單純的開發人員肯定留不住。所以拔高認知緯度，從軟體工程的高度，來解決目前企業內部的業務體系。從筆者切身的體會，我們一家研發產品的科技公司，內部包含測試系統、專案管理系統、流程控制系統、發布系統等等。不管公司大小，都會需要。在沒有SRE的驅動下，我們會選擇一個工具來填補空白。但是系統和系統之間並不是關聯的，內部又沒有人能真正驅動這個事情的迭代。最後，我們讓維運或開發來簡單的解決這個問題，實際情況是無法徹底解決這個問題的問題。

第三，SRE在國外網路公司隨處可見，國內卻很少有這樣職位或思想的傳播，是不是文化差異導致的？筆者認為國內維運體系在不斷演進的過程中，發展速度肯定是慢於國外當前的認知水準所導致的現狀。但隨著淘寶網的崛起，阿里的技術保障部其實就是國內SRE的最佳驗證。 SRE的效益是非常明顯的，但是在中小企業中推廣企業會非常困難。核心問題點在於國外的技術服務商體系非常健全，當中小企業想做一些SRE的轉變的過程中，可以獲得一大批技術服務提供者的方案。而企業願意花費部分費用在此類技術的預研過程中。國內企業期望購買的技術應該是成熟技術，不願意投入精力花在基礎建設之上。對於成本的控制，也是基於人力成本的考量之上，很難有技術提供者能有營運空間。那麼在這樣的困境之下，雲端運算業務的發展可以起到潤滑劑的作用。也就是說，共享技術經濟可能是一種SRE落地國內的方式。例如筆者所在的數人雲，一套落地SRE理念的輕量級應用管理平台，透過和企業的合作，完成企業所需的平台建置。在這個合作過程中，演化出來的系統作為附加價值，由數人雲端平台在其他企業中推廣獲得雙贏。從結果來看，企業獲得了SRE的成功實務成果，技術服務商獲得了SRE實務的機會。

第四，SRE都是善用工具的。我們解決問題的方式的變化，從解決問題到深度分析問題，並且給一個解決這個問題的模型和檢查清單。例如Netflix公司的SRE在解決Linux系統效能的時候提供給SRE的清單：

五、國內維運領域自動化實踐

限於國內運維領域的發展正在快速迭代，筆者從最為關注的三個領域問題作為突破口為大家分解當前自動化實踐的現狀。
1. 監控警報

國內監控警報工具品種繁多，但是真正能落地的流行方案少之又少。傳統企業最常用的是應該是Zabbix，另外國內小米開源的網路企業級監控工具Open-Falcon也是一個選擇。但是在這兩種場景下，都沒辦法迴避一個非常直接的問題，那麼就是如何用最短的路徑分析出你的問題並且解決業務場景下的實際問題。從監控的角度，有系統層級的，業務層級的，服務層級的多重維度。從SRE的角度處理問題，都是先容量規劃，而不是依照先驗經驗依照各種系統滯後在規劃。所以從一開始，工具就不是最棘手的問題。就拿Zabbix作為例子，可以監控的緯度就是系統的健康，資料庫的QPS，Redis的記憶體。但是如果遇到網站變慢，從監控的角度我是無能為力的。必須要有全鏈路的分析才可以判斷出問題，並解決這個問題。如果按照DevOps的經驗，我們不太可能提出這種問題，只是當遇到問題的時候，怎麼自動切換伺服器，或是自動擴容的方案來解決問題。成本的控制在DevOps的場景之下是不受控制的，管理者只能強制預算成本，上下游都無法充分了解業務運作到底需要多少成本。
2. 日誌監控

國內日誌監控大量使用ELK（Elasticsearch, Logstash, 和 Kibana）技術堆疊。這套技術堆疊非常流行，也解決了大量企業內部日誌的問題。但是在實際場景中，業務日誌的管理仍然是非常痛苦的。一個是即時日誌的查詢，兩個是歷史日誌的匯聚。怎麼有效提供日誌查詢的使用，去哪裡維運團隊共享過一個方法，透過在Apache Mesos之上，為內部部門提供隨需而啟動的ELK服務，讓開發者隨時查詢自己的業務日誌和分析自己的紀錄.查詢完之後，就自動銷毀這個ELK服務實例。筆者認為這種創新方式其實就是SRE思想的實踐。
3. 持續整合與發布系統

#國內運維使用最多的工具就是用Jenkins來完成持續整合和發布。但是我們往往是只要能用上Jenkins就停止了深度的實踐。從SRE的角度來講，我們首先分析出持續整合的業務痛點是什麼，因為在持續整合的過程中，會連接到測試系統。所以筆者認為持續整合的目的是為了讓產品品質持續的改進。有了核心的目標之後，我們管控的就不僅僅是Jenkins的Job是如何管理的，而是測試的效率是否能提高，整合的時間是否能縮短。建立一個目標清單，然後在納入到SRE的改進過程中，就一定會產生出不一樣的結果。持續發布是另一個主題，其實難題在於用戶對於發布的理解並不徹底。發布包括灰階發布、測試發布、滾動發布、回滾發布等多種場景。而每種場景都應該是可以回退的。怎麼解決這個問題，單靠Jenkins是無法解決這個問題的，你需要擴充工具來滿足，例如一套輕量級應用管理平台的輔助。

六、小結

從業界的發展歷程來看，技術的標準化是一個必然的演進過程，而維運自動化其實就是標準化的一種體現。從入手SRE的第一步開始，應該整理和整理工作職責，把需要解決的問題都文檔成檢查清單。方便業務上的快速實施。緊接著就是可視化這些業務指標和場景，幫助公司降低營運成本，量化服務體系的目標。對於有能力的企業，在發展過程中會把各種資源的介面統一，這個歷程會非常長，從筆者的經驗來看，應該小步迭代，按照實際效果謹慎執行。因為不計成本的平台化，只是光鮮亮麗的政績，並沒有有效的解決成本問題。自動化的最高形式肯定是智慧化系統，但是從筆者的角度來看，可能大家的科幻片看多了，反而淡化了軟體工程的目的，就是用科學的方法來最大化軟體效益。但是絕對不是高度智慧的自癒體系。這種人工智慧體系在筆者看來是軟體工程的另一個緯度的體現，就有如諾基亞手機和蘋果手機之間的對比，SRE的模型解決的是如何用好當前的工具鏈發揮諾基亞手機的最大價值，而不是被人工智慧體系取代。或許，在未來的某一天，SRE會直接退休，讓機器人來取代整個維運體系，但SRE終將會在科技史上記錄下深深的烙印。

以上是自動化演進在SRE中的應用的詳細內容。更多資訊請關注PHP中文網其他相關文章！