摘要：導讀為數(shù)人云系列活動專題，本文是月日北京站線下活動當西方的遇上東方的互聯(lián)網(wǎng)中京東金融王超老師的分享。王超京東金融企業(yè)高級目前在京東金融平臺負責一個人左右的應用運維團隊團隊，也曾負責人人網(wǎng)團隊。

導讀：[GO SRE！] 為數(shù)人云SRE系列活動專題，本文是3月4日北京站線下活動“當西方的SRE遇上東方的互聯(lián)網(wǎng)”中京東金融王超老師的分享。

他將從SRE，Devops， PE間的關系開始，介紹企業(yè)該如何構建適合自己的運維組織架構并管理團隊，講解持續(xù)交付、監(jiān)控、容量規(guī)劃等具體運維場景實操，從工程實踐的角度解讀大規(guī)模復雜化的業(yè)務場景下運維指導思想的落地。

王超 / 京東金融企業(yè)高級PE

目前在京東金融平臺負責一個20人左右的應用運維團隊（PE團隊），也曾負責人人網(wǎng)PE團隊?，F(xiàn)階段主要關注運維與業(yè)務的融合、業(yè)務可用性保障，運維平臺建設和團隊管理。

我是今天最后的演講者，前面幾位都是很知名的運維專家，對大家提到的很多運維痛點我都感同身受，談到國內運維行業(yè)的發(fā)展，我沒有在國外工作的經(jīng)驗，今天講的經(jīng)驗都是我在國內不算美好的IT行業(yè)環(huán)境下的親身實踐和總結，其中也吸收了很多國內運維行業(yè)專家前輩的指點，希望對大家有借鑒的意義。

剛畢業(yè)時我在一家世界500強的傳統(tǒng)行業(yè)公司信息中心做應用運維，后來換到人人網(wǎng)，再后來就是京東金融。從傳統(tǒng)行業(yè)跳到人人網(wǎng)的時候，加入的是一個剛建立的技術運維團隊，我從初期的運維工程師，成長為后來的運維主管。2014年到京東金融的時候，從0開始搭建起整個應用運維團隊，從初期建設團隊到一個比較穩(wěn)定的狀態(tài)，把公司的業(yè)務支撐好，這里面有很多經(jīng)驗可以和大家分享。

DevOps 是傳統(tǒng)瀑布流的交付方式中的Dev（開發(fā)）和Ops（運維）的關系。

開發(fā)和運維有一個矛盾點，開發(fā)的人覺得寫好代碼交給運維，就可以上線部署了，后面的事與我無關。代碼像炸彈一樣，上線后如果出了問題總是運維背鍋。運維的人覺得開發(fā)的人總是找麻煩，總是不靠譜，于是把控變更的次數(shù)和審核流程，使開發(fā)的人不能申請更多的上線，比如一個星期只允許上線一次，就這樣阻礙了業(yè)務的發(fā)展。DevOps解決了這個矛盾，協(xié)調了技術運營、QA還有開發(fā)三者間的關系。

國內有很多錯誤的做法，比如寫著招聘DevOps職位，但描述的工作職責跟傳統(tǒng)的運維沒有太多明顯的變化，還是做發(fā)布和SA；有的團隊把名字改成了DevOps，但是做的是運維開發(fā)的工作，要注意“運維開發(fā)”不是DevOps。DevOps是一個落實到團隊里的文化理念和最佳實踐，不只是運維團隊做，也不只是開發(fā)團隊做，而是大家一起做DevOps，甚至有可能多帶帶設有有一些協(xié)調員去做發(fā)布、交付工作。所以，DevOps不只是一個團隊的名稱。

我在人人網(wǎng)的時候， DevOps的概念比較火，公司建了一個DevOps團隊，后來在專家的指點下，我們把團隊名稱改成了PE團隊。另外，DevOps并不是系統(tǒng)管理員加上自動化工具就夠了，在部門里，SA做發(fā)布用了很多自動化的工具，但大家要知道，自動化只是一種手段和工具，要想好最終的目標解決的是怎樣的問題。最后，DevOps也不是把root權限給了開發(fā)人員。開發(fā)的人員有root權限會引入很大的風險，DevOps需要控制這個風險。

DevOps的最終目標是建立一個流水線、準實時交互及時性的業(yè)務流程，快速把產品推上線，產生業(yè)務價值，最大化業(yè)務輸出。做事一定要想公司的路線圖是什么，公司要做什么樣的事情。公司新發(fā)布一個產品，上線一個在社交網(wǎng)站上的新消息流功能，目標就應該是把這個功能推上線，服務更多的人，而不是簡簡單單的做一個工單的處理。目標不一樣，結果也是不一樣的。

從技術的角度或者是架構的角度來講，DevOps需要快速部署的平臺。這一點是大家都很認可的，很多現(xiàn)在DevOps培訓都僅僅做技術上的快速部署平臺，但是缺少對DevOps其他方面的培訓。DevOps真正的價值是由業(yè)務的結果判斷的。最大化輸出業(yè)務，而不止是IT項目的范圍或成果，就是對業(yè)務產生了多大的影響。

Facebook里有兩個詞說得特別多，一個是Vision（視野），另一個是Impact（影響力）。做事前想想這件事對公司是不是有正向的影響，影響力有多大？視野加上影響力很重要。舉個例子，做一個架構的組件，可能短期內公司用不上，但是在明年也許會產生很大的效果，產生很大的改變，那就可以做。做完以后今年可能沒有產生效果，但是明年可能對幾十人、上百人的開發(fā)效率產生非常大的提升，這就是有意義的。所以要看最終的結果，而不只從一個項目的角度去考慮。

雙峰挑戰(zhàn)。系統(tǒng)基本上都可以分為這兩類：是關注于快速上線的交互型系統(tǒng)，還是關注業(yè)務的連續(xù)性的記錄型（SOR）系統(tǒng)。我們公司是做金融的，其中的交易系統(tǒng)就屬于對業(yè)務連續(xù)性要求特別高的。有些產品則更關注于速度，比如web、app的開發(fā)，上線后如果有問題馬上回退就好，對用戶不會產生特別大的影響，這就是典型的交互型系統(tǒng)，這類系統(tǒng)也比較適合用DevOps。要區(qū)分系統(tǒng)是否適合DevOps，銀行、證券的的核心系統(tǒng)要把控好，不夠成熟就不要上DevOps。

DevSecOps就是除了DevOps，還要注意安全?；ヂ?lián)網(wǎng)公司對三點很關注，那就是速度、成本和質量。要快速的上線、快速的迭代，也要控制好成本。質量不能出問題，業(yè)務連續(xù)性不能斷，如果經(jīng)常丟數(shù)據(jù)，業(yè)務不能使用，公司的品牌會受到很大的影響。金融公司則更關注于安全，假如數(shù)據(jù)被竊取了，用戶數(shù)據(jù)或交易紀錄被篡改，是致命的。數(shù)據(jù)非常重要，所以DevOps里又加了一個DevSecOps 。

關注風險，但沒有絕對的安全。DevOps的經(jīng)典書籍《鳳凰工程》里有一段情節(jié)，有個做審計的人總是特別郁悶，因為總覺得IT的人不按審計的要求去修復所有問題，會出非常大的問題。但是最終的結果是審計成功通過，因為公司里財務的人通過業(yè)務上的檢查，解決了發(fā)現(xiàn)的安全問題，也就是說即使IT上存在一些問題，也可以通過業(yè)務的方式彌補，達到最終的安全。DevOps告訴我們，你要關注風險而不簡單是安全，在避免風險的前提下，制度不應妨礙業(yè)務的發(fā)展和交互。另外，也要通過技術提升安全，簡化流程，盡量實現(xiàn)自動化。設計流程很容易，很多公司里面都有特別多的工單，但是你要想你的工單是不是有作用？比如說是不是所有的項目的上線都需要安全的人審核，如果能自動判斷沒有風險的話，能否自動化流轉？

DevSecOps和DevOps一樣，也要加強人與人之間的溝通、協(xié)作，負責安全的人應該和開發(fā)、運維、測試人員一起防范風險。

談談SRE， SRE需要負責可用性、時延、性能、效率、變更管理、監(jiān)控、應急響應和容量管理等相關的工作，包括工程研發(fā)、日常運維以及監(jiān)控響應方向的工作。

重點分享我正在做的PE是什么，先介紹一下PE的起源。大家比較認可的是從雅虎開始流行的，國內最大的團隊就是阿里的PE團隊，后來受阿里影響很多公司也設了PE職位。PE這個詞有的叫產品運維工程師，有的叫業(yè)務運維工程師，也可以直接認為就是應用運維團隊，簡單來說就是負責業(yè)務或應用相關的一系列工程上的事務。

這是Facebook的招聘描述，PE既擁有軟件也擁有系統(tǒng)方面知識的工程師，要保障Facebook 的服務平滑的運行，有足夠的容量滿足未來的規(guī)劃。這也是剛才說的Facebook很強調兩點：一個是視野，一個是影響力。技術人要有視野，能預見公司未來的業(yè)務發(fā)展，根據(jù)視野做設計。一方面要保證服務平滑運行，另一方面要滿足未來的容量規(guī)劃，以此設計基礎組件，要有長久規(guī)劃設計的能力。每個Facebook 產品，包括基礎設施，都有PE的人。

聽阿里畢玄老師說，阿里的PE團隊打散到不同的BU業(yè)務單元里。大家要根據(jù)自身的情況考慮，F(xiàn)acebook 團隊比較大，每個大團隊都有兩個PE的人跟進，他們有廣闊的視野和經(jīng)驗，背景也比較好，從整個團隊來看，既有新人也有老手，組成了多樣化的團隊。

除了寫代碼，PE也要會寫文檔。做運維的人一定不要抗拒寫文檔，不管在哪里，文檔都很重要。好的文檔能把事情描述清楚，給別人去看，傳播給更多人，而不只是在自己的腦子里面。PE要做容量規(guī)劃，像京東每年都有兩次大促，618大促，雙十一大促，PE要規(guī)劃容量和性能能否夠滿足業(yè)務的發(fā)展。PE需要調試處理最困難的問題，所有運維都知道調試排查問題（Trouble Shooting），但是能做好的很難。很多公司做問題處理的時候，如果有乙方的支持，只要問題能解決，公司的人就不去想是問題的原因。

我們需要反思，再去自我提高，好的PE問題排查和總結范圍的能力都很強，簡單的問題也可以找到深層次的原因并做長期的提升改進。PE要加入到值班輪轉里，在值班的時候處理問題。PE要做產品協(xié)調員，和工程師團隊一同協(xié)作，這和SRE里相關的部分很像。

PE會和很多人打交道，這點對其他職業(yè)也是通用的。我很強調人與人之間的溝通協(xié)作，PE是一個協(xié)調員的角色，要和PM、產品經(jīng)理、程序員、網(wǎng)工，或者SRE溝通，與各個組協(xié)調把事情做好。我招PE的時候，很注意軟技能，如果軟技能方面有問題，只想做技術，很多事情都很難處理，后面的風險會更大。對于個人，不管是運維還是其他職位，想更好的發(fā)展都應該提升軟技能方面的能力，更多地與合作伙伴、同事共同協(xié)作，大家達成一致的目標，協(xié)作完成任務。

目標部分再說一下，管理者還要評估PE的績效，保證業(yè)務正常運轉，這也是管理者的一項重要工作。PE或應用運維工程師如何做發(fā)展計劃？如果不轉型，還是按PE方向發(fā)展，我覺得發(fā)展為架構師是很好的規(guī)劃。

總結一下我對PE的定位。首先，PE應該是服務的第一響應者，有問題要馬上處理。大家要有這個意識，有問題要能快速處理，這也要靠公司機制去保證，并不只是靠人。人不可能7X24小時處理問題，但是機制可以保證，包括輪班，一線二線的人分離任務，在保證核心的人不要太累的同時處理問題。性能分析師，利用有限資源承載更多的業(yè)務，京東每次大促前都要做全鏈路壓測，做評估、擴容，先做性能分析，然后在進行容量規(guī)劃。系統(tǒng)管理員是基本功，要懂操作系統(tǒng)，懂網(wǎng)絡，也要能寫Code，開發(fā)工具等等。開發(fā)工具并不要求是很大的平臺，可以和專業(yè)開發(fā)人員一塊去開發(fā)，解決問題就好。最后，產品工程協(xié)調員，加強人與人之間的溝通。

三個角色的定義都說完了，再說說如何結合組織架構設計技術架構，這里有很經(jīng)典的康威定律原則——組織結構會影響技術架構，技術架構會影響到運維架構。康威定律很重要的一點是說，假如團隊里有N個人，每個人都要跟N-1個人去溝通，團隊越大溝通成本越高。

如何設計結構降低溝通的成本？傳統(tǒng)模式下很多公司都是職能型的團隊，開發(fā)、運維、測試屬于不同的職能團隊，開發(fā)的人寫好代碼給運維的人上線就行了。在新的互聯(lián)網(wǎng)公司中，除了傳統(tǒng)的職能型團隊以外，還有實施矩陣式管理，做單元化、BU化組織架構的，這樣可以降低溝通協(xié)作的成本。

我之前在人人網(wǎng)帶的團隊有7、8個人，現(xiàn)在的團隊比較大，有差不多20人。20人的團隊怎么設計結構？我把業(yè)務線打散到兩個不同的業(yè)務組里，這里也有一個2-pizza team的原則。假如兩個pizza都喂不飽團隊的時候，團隊的溝通成本其實是很高的，管理也有難度。要把團隊打散劃分成更小的線，8人以內是比較合適的。

我也會設一些虛擬的小組，類似于矩陣式管理，有一些技術小組做大數(shù)據(jù)、分布式緩存，Docker、Nginx 等等，目的是什么？有點像Google SRE的50%原則，50%的時間做開發(fā)任務。但是我沒有辦法讓他將50%的時間完全去寫程序，因為有很多事情要去做，而且我們也有專門的開發(fā)團隊，但我可以設一些技術的小組，分離業(yè)務和技術的事。每個人50%的時間去做跟技術相關的事情，這樣他們自己也會覺得有意思一點，最終的目的不僅是做一個純業(yè)務的運維，而是給PE們提升的空間。

下技術管理上的實踐，即使是互聯(lián)網(wǎng)公司，ITIL這樣偏傳統(tǒng)的管理方式也有很多可取的地方，我們現(xiàn)在也用得著，并不是拋棄掉所有傳統(tǒng)的理念，要根據(jù)公司的需要，不管是ITIL還是SRE，還是其它方法都可以借鑒，以此設計你的組織結構。我會保留傳統(tǒng)的東西，像SLM，在SRE里叫SLO。為什么叫SLO不叫SLA了？

因為SLA是服務協(xié)議，更多時候是甲方和乙方簽協(xié)議。公司內部沒有協(xié)議，而是設定一個目標，開發(fā)跟運維間達成一致，要有數(shù)據(jù)化的考量。SLA或SLO都不只是一個可用性的目標，還包括很多的方向，比如維護的時間是否可靠？包括性能、備份、問題解決的時間這些都是考量的指標，不只是數(shù)字。我們內部的SLA會分得很細，根據(jù)業(yè)務的類型，對不同業(yè)務的影響會有很細的評估。

80%的故障都是變更引起。變更很頻繁，互聯(lián)網(wǎng)公司里面每天可能都幾十次、上百次的變更，測試環(huán)境沒有測試到業(yè)務的問題的可能性是很大的。變更管理的內容可以再看一下，比如CMDB，變更的時候還是要有基礎庫做記錄的，有了基礎庫后面才能做很多事情。

重大事件及故障管理，公司有問題的時候怎么快速的解決，有很多的細則要做，我們設有服務臺、監(jiān)控這樣的崗位，通過數(shù)據(jù)更準確的定位問題，大家一同協(xié)作、排查?？s小排查范圍有法可依，比如根因分析法，排錯法。不是簡單的溝通好就行了，還要檢查變更記錄、收集問題。

很多時候，現(xiàn)場處理問題動作比較快，后面分析時復原問題說不清楚。操作前盡快的把問題現(xiàn)象記錄下來，包括監(jiān)控信息、堆棧信息等等，以便于后面分析。處理流程盡量梳理清楚，對應的做分類，看問題是常見的還是非常見的。常見的問題有對應的應急案，快速的進行處理就好，如果是非常見的，需要技術和決策人參與，看到底是緊急的問題還是日常的問題，快速決策和解決。這里更多的還是需要有協(xié)調，有應急預案，應急的預案需要經(jīng)過演練。

故障分析會也叫復盤，有了故障以后組織故障分析會，目的是為了避免相同的問題重復的出現(xiàn)，做改進。這時，前面收集的信息就有用了，根據(jù)收集的信息復盤故障，大家看看當時發(fā)生了什么問題，怎么解決的，有沒有更好的辦法去定義故障級別，然后分析根本原因，這很重要。開故障分析會應該放松心態(tài)，開放共享，不要用指責的態(tài)度，而是追求事實，去看根本原因，共同提高、改進，分清因和果。很多時候分析出的問題并不一定是真正的原因，可能有更深層次的原因。

五問法， 就是要多問，大家一起討論，不要停留在表面。每一個人從自己的視角去看當時發(fā)生了什么，可以提出很多問題，引導進入深度思考。

瑣事—50%時間去做開發(fā)或虛擬技術小組的事情，SRE說50%的時間做開發(fā)，但是我認為50%的時間不一定全做開發(fā)，開發(fā)的時候也可以做一些技術的事，只要是長遠講，對你的組、對公司有好的影響的事，我覺得就可以了，目的是一樣的，多做自動化，促進大家提高能力。

自動化—減少重復性工作，減少手工操作帶來的不確定性。很多公司做自動化的同時，導致風險也變多了，所以怎么樣做正確的自動化？正確的自動化減少了重復性的工作，減少了錯誤，解放了人類，但是錯誤的自動化對應的只是把人類機械化了。以前手工做很多次的，現(xiàn)在變成一次就執(zhí)行了，系統(tǒng)沒有給你正確的反饋。這和DevOps說的一樣，不僅能更快速迭代的發(fā)布，還要有反饋的信息，收到有反饋的異常信息以后能快速的回滾，這點很重要。

很多的DevOps平臺都只是做了自動化，但是風險是不是控制好了？系統(tǒng)能否有效反饋？發(fā)布失敗的時候能不能停下來？要做好對應的信息反饋。錯誤的自動化對應的會給出錯誤的信息，導致決策失誤，這是一定要注意的。比如金融證券行業(yè)，做了一定的自動化交易（量化分析），程序自動做投資、買賣股權、買賣股票，完全自動化。但是如果系統(tǒng)沒有做好，就是災難性的，風險還是很嚴重的。核心系統(tǒng)一定不要缺少人工干預，并不是完全自動化就不需要運維了，決策或者風險非常高的地方，還是需要人去做。

最后一點，理解構建的東西，設計任何一個系統(tǒng)一定要知道下面具體的實現(xiàn)。發(fā)布的時候告訴研發(fā)的人后面有什么風險，系統(tǒng)是怎么設計的，懂了原理之后才能規(guī)避更多的風險。

現(xiàn)在都說數(shù)據(jù)化運維，有點類似于運營，有些運維做得比較好的話還是可以往公司的運營方向轉。很巧的是，運維和運營的英文的單詞都是“operation”，都是偏運營的方向，目標也是一樣的，做運維做得好的時候，應該有更多數(shù)據(jù)化的東西給公司做決策參考。尤其是監(jiān)控跟線上處理相關的，對應的數(shù)據(jù)都是你的來源，這些來源都會做智能運維的數(shù)據(jù)采集，比如說網(wǎng)絡監(jiān)控，操作系統(tǒng)監(jiān)控，DNS等服務監(jiān)控，基礎組件的監(jiān)控?；A技術組件服務，像DB、緩存、消息等，架構的組件都需要做數(shù)據(jù)化的參考，沒有這兩部分數(shù)據(jù)的話，做應用級性能分析的時候就很難。

這些信息之間也會做一些聯(lián)動，舉個例子，比如某應用的接口訪問慢了，到底是因為網(wǎng)絡原因慢了，還是緩存慢了，還是DB慢了？要把這些信息做聯(lián)動才能做更好的分析，如果做數(shù)據(jù)化運維就需要很多數(shù)據(jù)做分析。京東金融也做了分布式調用的跟蹤，我們現(xiàn)在說的微服務，以前叫服務化，再往前是SOA，對應的都會涉及調用鏈的關系。一個請求下來可能后面有幾十個、上百個應用，這時怎么發(fā)現(xiàn)是鏈條上的哪個請求變慢了？我們用的是自己開發(fā)的分布式調用跟蹤系統(tǒng)，也可以使用日志監(jiān)控，業(yè)務的解決方案，比如ELK、Splunk，日志易等。自己開發(fā)的系統(tǒng)能滿足我們大規(guī)模高復雜度場景的需要，還能和我們的CMDB，統(tǒng)一告警中心等系統(tǒng)做深度的整合。

下面兩個是業(yè)務指標，比如，支付系統(tǒng)會有支付可用率的指標監(jiān)控，也有對應每個銀行分類的可用率，全局業(yè)務的監(jiān)控大盤，這些都是業(yè)務方向的監(jiān)控需求，方便進行快速的分析決策。所以，對業(yè)務連續(xù)性要求高的系統(tǒng)大多會設置一個監(jiān)控中心或是作戰(zhàn)指揮室，有很多監(jiān)控的大屏，做數(shù)據(jù)化的運維，用數(shù)據(jù)做決策、分析。數(shù)據(jù)化運維今后的發(fā)展空間是很大的。

采集大量的數(shù)據(jù)是基礎，再發(fā)展的話，還會做事件匯總，打標簽的數(shù)據(jù)積累。詳細來講，一方面做數(shù)據(jù)采集，一方面按事件分類。觸發(fā)一次代碼的變更上線，或者業(yè)務的機房間流量切換，或者一個網(wǎng)絡的工單，都是不同的事件，什么樣的事件導致了數(shù)據(jù)的波動，他們是有相關性的，要綜合的分析找出根本問題。

再智能一點，像我們報警會做降級或者是升級，自動判斷問題。報警問題對業(yè)務是否有影響？是不是重復報警？級別比較低，經(jīng)常重復報又不需要人去處理的就降低級別。另外，智能預估和自動擴容，人工的規(guī)則向機器學習過渡，多打數(shù)據(jù)標簽，做一些智能化的處理。智能運維是未來的方向，空間還是很大的。

從實踐經(jīng)驗看，首先一定要明確公司團隊的定位、發(fā)展方向，公司的使命、愿景和價值觀是什么。讓每個人都理解，才能產生比較好的團隊作戰(zhàn)能力，根據(jù)公司的情況去看組織結構，根據(jù)組織架構招到合適的人，設計系統(tǒng)、不斷實踐、持續(xù)迭代，分析、總結，長期規(guī)劃。我們雖然做技術、管理，很多時候也要借鑒商業(yè)的模式，怎樣更快速的做一個新的產業(yè)出來。

最后一點我說一下“帶來變化”，不管在哪家公司，都應該嘗試一些新的改變，而不是簡單的做重復的事情。要有一些長遠的規(guī)劃，多做長期能帶來更大影響的事情，多做推動個人，公司，社會進步的事情。