[[314108]]

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

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

結合我們工作的思考：運維部門從成立之初就建立產(chǎn)品可用率制度，與產(chǎn)品一起設立可用率目標，可以說在量化運維質量目標與平衡產(chǎn)品迭代速度方面做得還可以?？梢蕴嵘牡胤皆谟谕七M產(chǎn)品開發(fā)部門對可用率目標的重視程度，以及事故改進的協(xié)作程度，有些產(chǎn)品往往一味追求產(chǎn)品迭代創(chuàng)新速度而犧牲較多產(chǎn)品穩(wěn)定性，并且事故改進投入精力不足。

2.運維工作工程化

谷歌SRE通過軟件工程的方式去提高運維效率和解決問題，鄙視手工方式操作，一是傳統(tǒng)運維方式對于快速發(fā)展的業(yè)務及達到百萬服務器規(guī)模的數(shù)據(jù)中心，通過堆人的方式已經(jīng)遠遠滿足不了了，二是谷歌SRE對自身工作的定位與追求，以開發(fā)軟件工程模式從繁瑣的重復性、機械性工作中抽脫出來，深入到系統(tǒng)架構、業(yè)務中，提高自身運維效率和系統(tǒng)整體的可用性可靠性。

對比思考：

最近兩三年，隨著網(wǎng)易云音樂、考拉海購等產(chǎn)品業(yè)務的迅猛發(fā)展，杭研體系整體的服務器規(guī)模數(shù)也快速增長，運維部門統(tǒng)計到的支持工單量也已從2016年上半年日均210個上漲到2016下半年日均315個、2017上半年日均319個，在整體人數(shù)保持穩(wěn)定情況下需要在運維效率方面做可持續(xù)性提升。

為此，整個運維部門在2017年初確定落實DevOps戰(zhàn)略，對運維工作效率提升做了明確的量化目標，包括工單處理時長、自動化完成率、開放與自助化率等。同時在運維平臺建設方面，在流程串聯(lián)和數(shù)據(jù)互通、效率提升方面會做更多優(yōu)化改進；另外運維部PE、SA、DBA等各組為優(yōu)化自身日常工作，各自衍生開發(fā)了自己的管理平臺——鳳凰、FL、OWL，并且這些系統(tǒng)的數(shù)據(jù)與流程都會連通。

到2017年底，我們的目標是有50%的工單可以由開發(fā)部門自助完成，基本上大部分操作可以由Stone移動化處理，整體工作效率同比提升50%以上。

3.瑣事與on-call輪值

谷歌SRE強調將日?，嵤鹿ぷ髁靠刂频?0%上限，能有一半時間投入到工程開發(fā)中去?，嵤?，包括on-call值班、中斷性事務（工單、郵件和IM）、發(fā)布、數(shù)據(jù)更新恢復相關等。日?，嵤逻^多，工作經(jīng)常被中斷，是運維工作效率無法提升的一個難題，谷歌SRE破解這個難題主要有2個方式，一是通過on-call輪值的值班制度，讓一部分人能夠有整段的時間去做工程；二是從整體上評估運維瑣事工作量，增派人力或將運維工作轉移給開發(fā)部門來控制整個部門的瑣事占比。

對比思考：

“工作經(jīng)常被打斷，技術含量不高的問題太多，開發(fā)換了一輪又一輪、重復性問題回答了一遍又一遍…”等等，也是運維人員經(jīng)常抱怨最大的問題。我們也老早安排了值班，但由于各個產(chǎn)品業(yè)務的獨特性與復雜性，值班人員只能處理少部分日常工單，大部分的工單還是需要分配給非值班的人員，所以整體上每個人的日?，嵤路浅６啵貏e是咨詢類工作，往往一個運維人員的IM對話飄窗達到20個以上。我們的應對之道：

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

值班能夠處理更多工作，通過將日常工作規(guī)范化、平臺化和WEB化，對值班人員屏蔽不同產(chǎn)品業(yè)務工作的獨特性，依賴于我們各個平臺自身的建設，后續(xù)將持續(xù)投入精力。

開放自助化，輸出運維能力。通過流程控制、任務自動化處理和風險控制，利用夸父等平臺讓開發(fā)等部門能夠自己處理日常需求，目前NDP發(fā)布平臺、OWL緩存管理等已有嘗試，后續(xù)夸父新工單系統(tǒng)將會改造原有流程，在Q3開始實施工單自助化操作并持續(xù)開放更多類型工單的自助化。

[[314109]]

4.人才招聘與培養(yǎng)

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

對比思考：

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

我們可以借鑒的地方：反向工程思維的培養(yǎng)，可以多做一些破壞性工作并修復的演練；多讓新人承擔一些有挑戰(zhàn)性的項目。另外對于其他行業(yè)優(yōu)秀的人才可以多加關注。

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