SRE之道：創造軟件系統來維護系統運行

引言：本文做者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 模型中爲了提升可靠性須要採起一些與常規作法違背的作法，因此須要強有力的管理層支持才能推行下去。例如：因爲一個季度內的錯誤預算耗盡而中止發佈新功能的決定，可能須要管理層的支持才能讓產品研發部門重視起來。 
　　本文選自《SRE：Google運維解密》，點此連接可在博文視點官網查看此書。 
　　　　　　　　　　　　　　　　　　　　　　

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