引言：本文作者Ben Treynor Sloss，Google 運維團隊的高階副總裁，SRE 名稱的發明者，在這裡提供了他對SRE 的定義。 
本文選自《SRE：Google運維解密》。

　　大家都知道， 計算機軟體系統離開人通常是無法自主執行的。那麼，究竟應該如何去運維一個日趨複雜的大型分散式計算系統呢？僱傭系統管理員（sysadmin）運維複雜的計算機系統，是行業內一直以來的普遍做法。而Google 的解決之道是——SRE。 
　　SRE 團隊通過僱傭軟體工程師，創造軟體系統來維護系統執行以替代傳統模型中的人工操作。 
　　SRE 究竟是如何在Google 起源的呢？ 其實我的答案非常簡單：SRE 就是讓軟體工程師來設計一個新型運維團隊的結果。當我在2003 年加入Google 的時候，我的任務就是領導一個由7 名軟體工程師組成的“生產環境維護組”。當時，我的整個職業生涯都專注於軟體工程，所以很自然，我按照自己最習慣的工作方式和管理方式來組建了這個團隊。 
　　時過境遷，當年的7 人團隊已經成長為公司內部1000 餘人的SRE 團隊，但是SRE 團隊的指導理念和工作方式還是基本保持了我最初的想法。 
　　SRE 方法論中的主要模組，就是SRE 團隊的構成。每個SRE 團隊裡基本上有兩類工程師。 
　　第一類，團隊中 50%~60% 是標準的軟體工程師，具體來講，就是那些能夠正常通過Google 軟體工程師招聘流程的人。第二類，其他40%~50% 則是一些基本滿足Google軟體工程師標準（具備85%~99% 所要求的技能），但是同時具有一定程度的其他技術能力的工程師。 目前來看， UNIX 系統內部細節和1~3 層網路知識是Google 最看重的兩類額外的技術能力。 
　　除此之外， 所有的SRE 團隊成員都必須非常願意、也非常相信用軟體工程方法可以解決複雜的運維問題。Google 一直密切關注這兩類候選人在招聘通過之後在SRE 團隊中的表現，但是到目前為止還沒有發現他們在工作上和成績上的顯著差異。事實上，由於兩類工程師技術背景互補，SRE 團隊經常能夠尋找到全新的、高效的解決問題的方法。 
按照這個標準來招聘和管理SRE 團隊，我們很快發現SRE 團隊成員具有如下特點： 
　　(a) 對重複性、手工性的操作有天然的排斥感。 
　　(b) 有足夠的技術能力快速開發出軟體系統以替代手工操作。 
　　同時，SRE 團隊和產品研發部門在學術和工作背景上非常相似。因此，從本質上來說，SRE 就是在用軟體工程的思維和方法論完成以前由系統管理員團隊手動完成的任務。這些SRE 傾向於通過設計、構建自動化工具來取代人工操作。 
　　SRE 模型成功的關鍵在於對工程的關注。如果沒有持續的、工程化的解決方案，運維的壓力就會不斷增加，團隊也就需要更多的人來完成工作。傳統的Ops 團隊的大小基本與所服務的產品負載呈線性同步增長。如果一個產品非常成功，使用者流量越來越大，就需要更多的團隊成員來重複進行同樣的事情。 
　　為了避免這一點，負責運維這個服務的團隊必須有足夠的時間程式設計，否則他們就會被運維工作所淹沒。因此，Google 為整個SRE 團隊所做的所有傳統運維工作設立了一個50% 的上限值。傳統運維工作包括：工單處理、手工操作等。設立這樣一個上限值確保了SRE 團隊有足夠的時間改進所維護的服務，將其變得更穩定和更易於維護。這個上限值並不是目標值。隨著時間推移，SRE 團隊應該傾向於將基本的運維工作全部消除，全力投入在研發任務上。因為整個系統應該可以自主執行，可以自動修復問題。我們的終極目標是推動整個系統趨向於無人化執行，而不僅僅是自動化某些人工流程。當然，在實際執行中，服務規模的不斷擴張和新功能的上線已經讓SRE 夠忙了！ 
　　Google 的經驗法則是，SRE 團隊必須將50% 的精力花在真實的開發工作上。那麼我們是如何確保每個團隊都是這樣做的呢？首先，我們必須不斷地度量每個團隊的工作時間分配。依靠這個資料，SRE 管理層會對在開發工作上投入時間不夠的團隊進行調整。通常，管理層會要求該團隊將一些常見的運維工作交還給產品研發部門操作，或者從產品研發部門抽調人力參與團隊輪值值班工作。此外，還可以停止該SRE 團隊的一切新增運維工作。只有管理層主動維護每個SRE 團隊的工作平衡，我們才能保障他們有足夠的時間和精力去進行真正有創造性的、自主的研發工作，同時，這也保障了SRE 團隊有足夠的運維經驗，從而讓他們設計出切實解決問題的系統。 
　　我們發現 Google SRE 模型在運維大規模複雜系統時有很多優勢。由於SRE 在調整Google 系統的過程中常常直接參與開發、修改程式碼，SRE 文化在公司內部基本代表了一種快速、創新、擁抱變化的文化。實踐證明，SRE 團隊執行、維護、改進一個複雜系統所需要的成員數量與系統部署規模呈非線性增長。而運維同樣的系統，用傳統的系統管理員模型維護則需要更多數量的人。最後，SRE 模型不僅消除了傳統模型中研發團隊和運維團隊的衝突焦點，反而促進了整個產品部門水平的整體提高。因為SRE 團隊和研發團隊之間的成員可以自由流動，整個產品部門的人員都有機會學習和參與大規模運維部署活動，從中獲得平時難以獲得的寶貴知識。普通的開發人員有多少機會能將自己的程式同時跑在100 萬個CPU 的分散式系統上呢？ 
　　雖然SRE 模型帶來了一些優勢，但也存在一些問題。Google 面對的一個永續性的難題就是如何招聘合適的SRE。首先SRE 要和產品研發部門招聘傳統的軟體開發工程師競爭。 
　　其次，由於SRE 要求同時具備多項技能，市場上具有相關從業背景和經驗的人就更少了。由於SRE 模型也比較新，行業內關於如何建立和維護SRE 團隊的相關資訊並不多。最後，SRE 團隊建立之後，由於SRE 模型中為了提高可靠性需要採取一些與常規做法違背的做法，所以需要強有力的管理層支援才能推行下去。例如：由於一個季度內的錯誤預算耗盡而停止釋出新功能的決定，可能需要管理層的支援才能讓產品研發部門重視起來。 
　　

想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。