活動實錄 | 京東金融PE談如何顛覆應用運維認知

導讀：[GO SRE！] 爲數人云SRE系列活動專題，本文是3月4日北京站線下活動「當西方的SRE趕上東方的互聯網」中京東金融王超老師的分享。

他將從SRE，Devops， PE間的關係開始，介紹企業該如何構建適合本身的運維組織架構並管理團隊，講解持續交付、監控、容量規劃等具體運維場景實操，從工程實踐的角度解讀大規模複雜化的業務場景下運維指導思想的落地。

王超 / 京東金融企業高級PE

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

---

我是今天最後的演講者，前面幾位都是很知名的運維專家，對你們提到的不少運維痛點我都感同身受，談到國內運維行業的發展，我沒有在國外工做的經驗，今天講的經驗都是我在國內不算美好的IT行業環境下的親身實踐和總結，其中也吸取了不少國內運維行業專家前輩的指點，但願對你們有借鑑的意義。

剛畢業時我在一家世界500強的傳統行業公司信息中心作應用運維，後來換到人人網，再後來就是京東金融。從傳統行業跳到人人網的時候，加入的是一個剛創建的技術運維團隊，我從初期的運維工程師，成長爲後來的運維主管。2014年到京東金融的時候，從0開始搭建起整個應用運維團隊，從初期建設團隊到一個比較穩定的狀態，把公司的業務支撐好，這裏面有不少經驗能夠和你們分享。

DevOps

DevOps 是傳統瀑布流的交付方式中的Dev（開發）和Ops（運維）的關係。

開發和運維有一個矛盾點，開發的人以爲寫好代碼交給運維，就能夠上線部署了，後面的事與我無關。代碼像炸彈同樣，上線後若是出了問題老是運維背鍋。運維的人以爲開發的人老是找麻煩，老是不靠譜，因而把控變動的次數和審覈流程，使開發的人不能申請更多的上線，好比一個星期只容許上線一次，就這樣阻礙了業務的發展。DevOps解決了這個矛盾，協調了技術運營、QA還有開發三者間的關係。

DevOps誤區

國內有不少錯誤的作法，好比寫着招聘DevOps職位，但描述的工做職責跟傳統的運維沒有太多明顯的變化，仍是作發佈和SA；有的團隊把名字改爲了DevOps，可是作的是運維開發的工做，要注意「運維開發」不是DevOps。DevOps是一個落實到團隊裏的文化理念和最佳實踐，不僅是運維團隊作，也不僅是開發團隊作，而是你們一塊兒作DevOps，甚至有可能單獨設有有一些協調員去作發佈、交付工做。因此，DevOps不僅是一個團隊的名稱。

我在人人網的時候， DevOps的概念比較火，公司建了一個DevOps團隊，後來在專家的指點下，咱們把團隊名稱改爲了PE團隊。另外，DevOps並非系統管理員加上自動化工具就夠了，在部門裏，SA作發佈用了不少自動化的工具，但你們要知道，自動化只是一種手段和工具，要想好最終的目標解決的是怎樣的問題。最後，DevOps也不是把root權限給了開發人員。開發的人員有root權限會引入很大的風險，DevOps須要控制這個風險。

DevOps技術目標

DevOps的最終目標

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

從技術的角度或者是架構的角度來說，DevOps須要快速部署的平臺。這一點是你們都很承認的，不少如今DevOps培訓都僅僅作技術上的快速部署平臺，可是缺乏對DevOps其餘方面的培訓。DevOps真正的價值是由業務的結果判斷的。最大化輸出業務，而不止是IT項目的範圍或成果，就是對業務產生了多大的影響。

Facebook裏有兩個詞說得特別多，一個是Vision（視野），另外一個是Impact（影響力）。作事前想一想這件事對公司是否是有正向的影響，影響力有多大？視野加上影響力很重要。舉個例子，作一個架構的組件，可能短時間內公司用不上，可是在明年也許會產生很大的效果，產生很大的改變，那就能夠作。作完之後今年可能沒有產生效果，可是明年可能對幾十人、上百人的開發效率產生很是大的提高，這就是有意義的。因此要看最終的結果，而不僅從一個項目的角度去考慮。

DevOps速度&業務連續性

雙峯挑戰。系統基本上均可以分爲這兩類：是關注於快速上線的交互型系統，仍是關注業務的連續性的記錄型（SOR）系統。咱們公司是作金融的，其中的交易系統就屬於對業務連續性要求特別高的。有些產品則更關注於速度，好比web、app的開發，上線後若是有問題立刻回退就好，對用戶不會產生特別大的影響，這就是典型的交互型系統，這類系統也比較適合用DevOps。要區分系統是否適合DevOps，銀行、證券的的核心繫統要把控好，不夠成熟就不要上DevOps。

DevOps風險&安全

DevSecOps就是除了DevOps，還要注意安全。互聯網公司對三點很關注，那就是速度、成本和質量。要快速的上線、快速的迭代，也要控制好成本。質量不能出問題，業務連續性不能斷，若是常常丟數據，業務不能使用，公司的品牌會受到很大的影響。金融公司則更關注於安全，假如數據被竊取了，用戶數據或交易紀錄被篡改，是致命的。數據很是重要，因此DevOps裏又加了一個DevSecOps 。

關注風險，但沒有絕對的安全。DevOps的經典書籍《鳳凰工程》裏有一段情節，有個作審計的人老是特別鬱悶，由於總以爲IT的人不按審計的要求去修復全部問題，會出很是大的問題。可是最終的結果是審計成功經過，由於公司裏財務的人經過業務上的檢查，解決了發現的安全問題，也就是說即便IT上存在一些問題，也能夠經過業務的方式彌補，達到最終的安全。DevOps告訴咱們，你要關注風險而不簡單是安全，在避免風險的前提下，制度不該妨礙業務的發展和交互。另外，也要經過技術提高安全，簡化流程，儘可能實現自動化。設計流程很容易，不少公司裏面都有特別多的工單，可是你要想你的工單是否是有做用？好比說是否是全部的項目的上線都須要安全的人審覈，若是能自動判斷沒有風險的話，可否自動化流轉？

DevSecOps和DevOps同樣，也要增強人與人之間的溝通、協做，負責安全的人應該和開發、運維、測試人員一塊兒防範風險。

SRE

談談SRE， SRE須要負責可用性、時延、性能、效率、變動管理、監控、應急響應和容量管理等相關的工做，包括工程研發、平常運維以及監控響應方向的工做。

深究PE

重點分享我正在作的PE是什麼，先介紹一下PE的起源。你們比較承認的是從雅虎開始流行的，國內最大的團隊就是阿里的PE團隊，後來受阿里影響不少公司也設了PE職位。PE這個詞有的叫產品運維工程師，有的叫業務運維工程師，也能夠直接認爲就是應用運維團隊，簡單來講就是負責業務或應用相關的一系列工程上的事務。

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

聽阿里畢玄老師說，阿里的PE團隊打散到不一樣的BU業務單元裏。你們要根據自身的狀況考慮，Facebook 團隊比較大，每一個大團隊都有兩個PE的人跟進，他們有廣闊的視野和經驗，背景也比較好，從整個團隊來看，既有新人也有老手，組成了多樣化的團隊。

除了寫代碼，PE也要會寫文檔。作運維的人必定不要抗拒寫文檔，無論在哪裏，文檔都很重要。好的文檔能把事情描述清楚，給別人去看，傳播給更多人，而不僅是在本身的腦子裏面。PE要作容量規劃，像京東每一年都有兩次大促，618大促，雙十一大促，PE要規劃容量和性能可否夠知足業務的發展。PE須要調試處理最困難的問題，全部運維都知道調試排查問題（Trouble Shooting），可是能作好的很難。不少公司作問題處理的時候，若是有乙方的支持，只要問題能解決，公司的人就不去想是問題的緣由。

咱們須要反思，再去自我提升，好的PE問題排查和總結範圍的能力都很強，簡單的問題也能夠找到深層次的緣由並作長期的提高改進。PE要加入到值班輪轉裏，在值班的時候處理問題。PE要作產品協調員，和工程師團隊一同協做，這和SRE裏相關的部分很像。

PE會和不少人打交道，這點對其餘職業也是通用的。我很強調人與人之間的溝通協做，PE是一個協調員的角色，要和PM、產品經理、程序員、網工，或者SRE溝通，與各個組協調把事情作好。我招PE的時候，很注意軟技能，若是軟技能方面有問題，只想作技術，不少事情都很難處理，後面的風險會更大。對於我的，無論是運維仍是其餘職位，想更好的發展都應該提高軟技能方面的能力，更多地與合做夥伴、同事共同協做，你們達成一致的目標，協做完成任務。

目標部分再說一下，管理者還要評估PE的績效，保證業務正常運轉，這也是管理者的一項重要工做。PE或應用運維工程師如何作發展計劃？若是不轉型，仍是按PE方向發展，我以爲發展爲架構師是很好的規劃。

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

PE實踐及心得

如何結合組織架構設計技術架構

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

如何設計結構下降溝通的成本？傳統模式下不少公司都是職能型的團隊，開發、運維、測試屬於不一樣的職能團隊，開發的人寫好代碼給運維的人上線就好了。在新的互聯網公司中，除了傳統的職能型團隊之外，還有實施矩陣式管理，作單元化、BU化組織架構的，這樣能夠下降溝通協做的成本。

我以前在人人網帶的團隊有七、8我的，如今的團隊比較大，有差很少20人。20人的團隊怎麼設計結構？我把業務線打散到兩個不一樣的業務組裏，這裏也有一個2-pizza team的原則。假如兩個pizza都喂不飽團隊的時候，團隊的溝通成本實際上是很高的，管理也有難度。要把團隊打散劃分紅更小的線，8人之內是比較合適的。

我也會設一些虛擬的小組，相似於矩陣式管理，有一些技術小組作大數據、分佈式緩存，Docker、Nginx 等等，目的是什麼？有點像Google SRE的50%原則，50%的時間作開發任務。可是我沒有辦法讓他將50%的時間徹底去寫程序，由於有不少事情要去作，並且咱們也有專門的開發團隊，但我能夠設一些技術的小組，分離業務和技術的事。每一個人50%的時間去作跟技術相關的事情，這樣他們本身也會以爲有意思一點，最終的目的不只是作一個純業務的運維，而是給PE們提高的空間。

SLM服務級別管理

下技術管理上的實踐，即便是互聯網公司，ITIL這樣偏傳統的管理方式也有不少可取的地方，咱們如今也用得着，並非拋棄掉全部傳統的理念，要根據公司的須要，無論是ITIL仍是SRE，仍是其它方法均可以借鑑，以此設計你的組織結構。我會保留傳統的東西，像SLM，在SRE裏叫SLO。爲何叫SLO不叫SLA了？

由於SLA是服務協議，更多時候是甲方和乙方籤協議。公司內部沒有協議，而是設定一個目標，開發跟運維間達成一致，要有數據化的考量。SLA或SLO都不僅是一個可用性的目標，還包括不少的方向，好比維護的時間是否可靠？包括性能、備份、問題解決的時間這些都是考量的指標，不僅是數字。咱們內部的SLA會分得很細，根據業務的類型，對不一樣業務的影響會有很細的評估。

變動管理

80%的故障都是變動引發。變動很頻繁，互聯網公司裏面天天可能都幾十次、上百次的變動，測試環境沒有測試到業務的問題的可能性是很大的。變動管理的內容能夠再看一下，好比CMDB，變動的時候仍是要有基礎庫作記錄的，有了基礎庫後面才能作不少事情。

重大事件及故障管理

重大事件及故障管理，公司有問題的時候怎麼快速的解決，有不少的細則要作，咱們設有服務檯、監控這樣的崗位，經過數據更準確的定位問題，你們一同協做、排查。縮小排查範圍有法可依，好比根因分析法，排錯法。不是簡單的溝通好就好了，還要檢查變動記錄、收集問題。

事件處理流程

不少時候，現場處理問題動做比較快，後面分析時復原問題說不清楚。操做前儘快的把問題現象記錄下來，包括監控信息、堆棧信息等等，以便於後面分析。處理流程儘可能梳理清楚，對應的作分類，看問題是常見的仍是很是見的。常見的問題有對應的應急案，快速的進行處理就好，若是是很是見的，須要技術和決策人蔘與，看究竟是緊急的問題仍是平常的問題，快速決策和解決。這裏更多的仍是須要有協調，有應急預案，應急的預案須要通過演練。

故障分析會

故障分析會也叫覆盤，有了故障之後組織故障分析會，目的是爲了不相同的問題重複的出現，作改進。這時，前面收集的信息就有用了，根據收集的信息覆盤故障，你們看看當時發生了什麼問題，怎麼解決的，有沒有更好的辦法去定義故障級別，而後分析根本緣由，這很重要。開故障分析會應該放鬆心態，開放共享，不要用指責的態度，而是追求事實，去看根本緣由，共同提升、改進，分清因和果。不少時候分析出的問題並不必定是真正的緣由，可能有更深層次的緣由。

五問法， 就是要多問，你們一塊兒討論，不要停留在表面。每個人從本身的視角去看當時發生了什麼，能夠提出不少問題，引導進入深度思考。

雜事—50%時間去作開發或虛擬技術小組的事情，SRE說50%的時間作開發，可是我認爲50%的時間不必定全作開發，開發的時候也能夠作一些技術的事，只要是長遠講，對你的組、對公司有好的影響的事，我以爲就能夠了，目的是同樣的，多作自動化，促進你們提升能力。

自動化—減小重複性工做，減小手工操做帶來的不肯定性。不少公司作自動化的同時，致使風險也變多了，因此怎麼樣作正確的自動化？正確的自動化減小了重複性的工做，減小了錯誤，解放了人類，可是錯誤的自動化對應的只是把人類機械化了。之前手工作不少次的，如今變成一次就執行了，系統沒有給你正確的反饋。這和DevOps說的同樣，不只能更快速迭代的發佈，還要有反饋的信息，收到有反饋的異常信息之後能快速的回滾，這點很重要。

不少的DevOps平臺都只是作了自動化，可是風險是否是控制好了？系統可否有效反饋？發佈失敗的時候能不能停下來？要作好對應的信息反饋。錯誤的自動化對應的會給出錯誤的信息，致使決策失誤，這是必定要注意的。好比金融證券行業，作了必定的自動化交易（量化分析），程序自動作投資、買賣股權、買賣股票，徹底自動化。可是若是系統沒有作好，就是災難性的，風險仍是很嚴重的。核心系統必定不要缺乏人工干預，並非徹底自動化就不須要運維了，決策或者風險很是高的地方，仍是須要人去作。

最後一點，理解構建的東西，設計任何一個系統必定要知道下面具體的實現。發佈的時候告訴研發的人後面有什麼風險，系統是怎麼設計的，懂了原理以後才能規避更多的風險。

數據化運維

如今都說數據化運維，有點相似於運營，有些運維作得比較好的話仍是能夠往公司的運營方向轉。很巧的是，運維和運營的英文的單詞都是「operation」，都是偏運營的方向，目標也是同樣的，作運維作得好的時候，應該有更多數據化的東西給公司作決策參考。尤爲是監控跟線上處理相關的，對應的數據都是你的來源，這些來源都會作智能運維的數據採集，好比說網絡監控，操做系統監控，DNS等服務監控，基礎組件的監控。基礎技術組件服務，像DB、緩存、消息等，架構的組件都須要作數據化的參考，沒有這兩部分數據的話，作應用級性能分析的時候就很難。

這些信息之間也會作一些聯動，舉個例子，好比某應用的接口訪問慢了，究竟是由於網絡緣由慢了，仍是緩存慢了，仍是DB慢了？要把這些信息作聯動才能作更好的分析，若是作數據化運維就須要不少數據作分析。京東金融也作了分佈式調用的跟蹤，咱們如今說的微服務，之前叫服務化，再往前是SOA，對應的都會涉及調用鏈的關係。一個請求下來可能後面有幾十個、上百個應用，這時怎麼發現是鏈條上的哪一個請求變慢了？咱們用的是本身開發的分佈式調用跟蹤系統，也可使用日誌監控，業務的解決方案，好比ELK、Splunk，日誌易等。本身開發的系統能知足咱們大規模高複雜度場景的須要，還能和咱們的CMDB，統一告警中心等系統作深度的整合。

下面兩個是業務指標，好比，支付系統會有支付可用率的指標監控，也有對應每一個銀行分類的可用率，全局業務的監控大盤，這些都是業務方向的監控需求，方便進行快速的分析決策。因此，對業務連續性要求高的系統大多會設置一個監控中心或是做戰指揮室，有不少監控的大屏，作數據化的運維，用數據作決策、分析。數據化運維從此的發展空間是很大的。

智能運維

採集大量的數據是基礎，再發展的話，還會作事件彙總，打標籤的數據積累。詳細來說，一方面作數據採集，一方面按事件分類。觸發一次代碼的變動上線，或者業務的機房間流量切換，或者一個網絡的工單，都是不一樣的事件，什麼樣的事件致使了數據的波動，他們是有相關性的，要綜合的分析找出根本問題。

再智能一點，像咱們報警會作降級或者是升級，自動判斷問題。報警問題對業務是否有影響？是否是重複報警？級別比較低，常常重複報又不須要人去處理的就下降級別。另外，智能預估和自動擴容，人工的規則向機器學習過渡，多打數據標籤，作一些智能化的處理。智能運維是將來的方向，空間仍是很大的。

總結

從實踐經驗看，首先必定要明確公司團隊的定位、發展方向，公司的使命、願景和價值觀是什麼。讓每一個人都理解，才能產生比較好的團隊做戰能力，根據公司的狀況去看組織結構，根據組織架構招到合適的人，設計系統、不斷實踐、持續迭代，分析、總結，長期規劃。咱們雖然作技術、管理，不少時候也要借鑑商業的模式，怎樣更快速的作一個新的產業出來。

最後一點我說一下「帶來變化」，無論在哪家公司，都應該嘗試一些新的改變，而不是簡單的作重複的事情。要有一些長遠的規劃，多作長期能帶來更大影響的事情，多作推進我的，公司，社會進步的事情。