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

1. 自動化系統對 SRE 的價值；
2. 自動化系統演進的歷程；
3. 國外網際網路企業 SRE 自動化應用案例；
4. 國內運維領域自動化實踐。

一、什麼是 SRE ？

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

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

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

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

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

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

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

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

三、自動化演進的歷程

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

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

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

首先，Borg系統是完全分層的系統架構。從最基礎的檔案系統到最上面的負載分流，每層的技術棧在谷歌內部都是唯一的，這樣做的好處是可以積累經驗複用。國內企業的系統架構，在發展過程中也會經歷分層組織的架構，拋開人的因素，很多分層是多套系統組合在一起搭建而成。從表面上來看，我們降低了成本，但是其實增加了人力的維護成本。在這個問題點上，國外系統的先進性可以放一放，我們在選擇技術的時候應該怎麼辦？從經驗上來講，同行分享的拼接多套開源系統組成的一層體系是一種走捷徑的辦法，短期效應明顯。一旦企業業務高速發展，每次重構都是毀滅性的推倒重來工具。從我經歷的大大小小多種企業系統中，我深刻體會出這種變革動力。在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終將會在科技歷史上記錄下深深的烙印。

原文來自：數人云（www.shurenyun.com）