谷歌SRE與運維工做的思考

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

谷歌的工做方式：面對運維部門與開發部門之間的產品穩定性與迭代創新速度之間的矛盾，容許產品在設定的「錯誤預算」內發生異常，利用可量化的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一書以後，咱們結合自身工做作的一點點思考，以及後續咱們工做改進的一些方向。