谷歌SRE與運維工作的思考

來源 | rrd.me/fR8u9

運維部門要保障產品業務穩定性，開發部門要想隨時隨地快速上線新功能，而線上的故障往往是由新的變更導致的——不管是新發布了版本，還是修改配置，或者是改變了使用者某些行為導致流量負載產生變化，傳統意義上這兩個部門在本質目標上是相對的。所以運維部門往往會要求開發部門對變更或釋出做控制，並且規定要走一些繁瑣的流程；而開發部門會想法設法繞過這些繁瑣步驟，以支援新功能更快上線。

谷歌的工作方式：面對運維部門與開發部門之間的產品穩定性與迭代創新速度之間的矛盾，允許產品在設定的“錯誤預算”內發生異常，利用可量化的SLO來達到兩者之間的平衡。比如一個產品的可用性目標是99.99%，那麼只要這個產品當前的可用性高於99.99%情況下，運維團隊會盡可能加快產品功能上線；而當這個產品因變更等事故導致可用性低於99.99%，新的上線和變更請求將不得被處理，直到下個可用性考核週期。

結合我們工作的思考：運維部門從成立之初就建立產品可用率制度，與產品一起設立可用率目標，可以說在量化運維質量目標與平衡產品迭代速度方面做得還可以。可以提升的地方在於推進產品開發部門對可用率目標的重視程度，以及事故改進的協作程度，有些產品往往一味追求產品迭代創新速度而犧牲較多產品穩定性，並且事故改進投入精力不足。

2.運維工作工程化

谷歌SRE透過軟體工程的方式去提高運維效率和解決問題，鄙視手工方式操作，一是傳統運維方式對於快速發展的業務及達到百萬伺服器規模的資料中心，透過堆人的方式已經遠遠滿足不了了，二是谷歌SRE對自身工作的定位與追求，以開發軟體工程模式從繁瑣的重複性、機械性工作中抽脫出來，深入到系統架構、業務中，提高自身運維效率和系統整體的可用性可靠性。

對比思考：

最近兩三年，隨著網易雲音樂、考拉海購等產品業務的迅猛發展，杭研體系整體的伺服器規模數也快速增長，運維部門統計到的支援工單量也已從2016年上半年日均210個上漲到2016下半年日均315個、2017上半年日均319個，在整體人數保持穩定情況下需要在運維效率方面做可持續性提升。

為此，整個運維部門在2017年初確定落實DevOps戰略，對運維工作效率提升做了明確的量化目標，包括工單處理時長、自動化完成率、開放與自助化率等。同時在運維平臺建設方面，在流程串聯和資料互通、效率提升方面會做更多最佳化改進；另外運維部PE、SA、DBA等各組為最佳化自身日常工作，各自衍生開發了自己的管理平臺——鳳凰、FL、OWL，並且這些系統的資料與流程都會連通。到2017年底，我們的目標是有50%的工單可以由開發部門自助完成，基本上大部分操作可以由Stone移動化處理，整體工作效率同比提升50%以上。

3.瑣事與on-call輪值

谷歌SRE強調將日常瑣事工作量控制到50%上限，能有一半時間投入到工程開發中去。瑣事，包括on-call值班、中斷性事務（工單、郵件和IM）、釋出、資料更新恢復相關等。日常瑣事過多，工作經常被中斷，是運維工作效率無法提升的一個難題，谷歌SRE破解這個難題主要有2個方式，一是透過on-call輪值的值班制度，讓一部分人能夠有整段的時間去做工程；二是從整體上評估運維瑣事工作量，增派人力或將運維工作轉移給開發部門來控制整個部門的瑣事佔比。

對比思考：

“工作經常被打斷，技術含量不高的問題太多，開發換了一輪又一輪、重複性問題回答了一遍又一遍...”等等，也是運維人員經常抱怨最大的問題。我們也老早安排了值班，但由於各個產品業務的獨特性與複雜性，值班人員只能處理少部分日常工單，大部分的工單還是需要分配給非值班的人員，所以整體上每個人的日常瑣事非常多，特別是諮詢類工作，往往一個運維人員的IM對話飄窗達到20個以上。我們的應對之道：

1. 小石頭機器人能夠回答常見FAQ。文件和FAQ，我們也有總結，讓開發部門等能夠學習，實踐下來總體效果不理想。實時的互動式問答，問題更聚焦，對於使用者來說是個更快更有效率的方式。為此，我們會嘗試將FAQ做到智慧客服機器人當中，在常用平臺頁面如夸父等接入小石頭機器人，能夠回答使用者的常見問題。我們需要做的就是持續更新FAQ，讓智慧機器人做到更精準匹配回答，並引導使用者使用小石頭。

2. 值班能夠處理更多工作，透過將日常工作規範化、平臺化和WEB化，對值班人員遮蔽不同產品業務工作的獨特性，依賴於我們各個平臺自身的建設，後續將持續投入精力。

3. 開放自助化，輸出運維能力。透過流程控制、任務自動化處理和風險控制，利用夸父等平臺讓開發等部門能夠自己處理日常需求，目前NDP釋出平臺、OWL快取管理等已有嘗試，後續夸父新工單系統將會改造原有流程，在Q3開始實施工單自助化操作並持續開放更多型別工單的自助化。

4.人才招聘與培養

谷歌SRE人才招聘，按照軟體開發工程師一致的標準，並且SRE團隊裡也有各種行業背景的優秀人才，比如原先有負責美國國防部陸空運載設施的GPS與慣性制導系統的，原先是救生員的，原先設計軍用飛機等地勤管理系統的，原先是合成磚石工廠的工程師的，原先是核潛艇工程師的等等，都是對安全性、穩定性、可靠性要求非常高的崗位。在培養方面建立體系化培訓課程、學習事故經驗總結、承擔挑戰性專案並儘早參與on-call見習工作。

對比思考：

我們做得還可以的：重視招聘，一直是我們部門的傳統，做到各個招聘主管的招聘標準一致，除了考核專業能力之外對合作、執行等方面也確立了標準，另外專業能力上需要有工程化思想。以前有一個應聘者回答“為什麼選擇運維崗位”的時候，說道“自己不喜歡開發工作”，雖然各方面能力都不錯我們還是沒有選擇她。

我們可以借鑑的地方：反向工程思維的培養，可以多做一些破壞性工作並修復的演練；多讓新人承擔一些有挑戰性的專案。另外對於其他行業優秀的人才可以多加關注。

最後，開發與運維不是天然對立矛盾的，只是需要大家確立為產品發展的共同目標，在產品創新速度與穩定性之間尋求到平衡。我們在思考自身運維工作的時候，會始終堅持上面這個觀點。以上是在看完谷歌SRE一書之後，我們結合自身工作做的一點點思考，以及後續我們工作改進的一些方向。