騰訊最賺錢的部門是怎麼作運維的？

本文來源：騰訊最賺錢的部門是怎麼作運維的？

http://card.weibo.com/article/h5/s#cid=1001603864876505250090

 

騰訊互動娛樂事業羣的主營業務是遊戲，全部騰訊遊戲都是由這個事業羣作的，估計不少人都玩過，像《英雄聯盟》、《全民突擊》等。我所在的部門叫運營部，負責全部騰訊遊戲的技術運營工做。

 

 

簡單解釋一下，什麼叫技術運營工做，這裏包括了幾個部分：運維，營銷開發，數據分析和數據挖掘，用戶運營（所謂用戶運營，不是傳統的客戶服務，是一些高端的用戶運營。）

好比說在騰訊遊戲上一年花八萬，就是咱們的VIP，咱們有專屬的服務經理對接，就像銀行的VIP用戶同樣。這裏就不展開了，重點說說我所負責的運維管理工做吧：

 

 

 

如上所說，咱們所負責的運維工做，是運營部的一部分工做。咱們如今運維了幾百款遊戲，並且數字還在快速增加，特別手遊加入以來，每一年都有一兩百款。

簡 單介紹一下騰訊遊戲運維團隊的發展歷程：咱們團隊是2003年隨着騰訊代理《凱旋》遊戲而成立的，發展到2005年的時候，咱們作了一件事情，就是DO分 離，DO分離的概念前些年提得比較多，如今你們好像再也不提了。回頭來看，咱們以爲DO分離是頗有必要的，由於開發跟運維須要具有的核心能力是不一樣的。

接下來，在2006年的時候咱們作了QO分離，意思就是咱們把質量管理團隊（QA）和運維分離開了，這個後面我會再講一下。隨着團隊進一步擴張，業務進一步增長，2007年的時候咱們把DBA專業團隊分離出來了。

到2009年的時候發現業務發展很快，老闆不給咱們這麼多人，怎麼辦？光靠人去填的模式已經運行不下去了，因此當時成立了運維開發團隊，專門建設運維工具。同時在2009年咱們還成立了一個內部安全團隊，這個團隊可能不少公司都沒有，比較特殊。

由於你們知道遊戲行業，有些遊戲類道具很是值錢，說不許哪一個同窗手一抖給本身加個幾十萬，因此咱們成立了內部安全團隊，作安全監控，其中也包括權限控制，你們都知道，自動化系統權限控制很是重要，若是這個沒控制好就會出現災難性後果。

時間到了2012年，咱們開始提倡運維轉型，鼓勵運維向運維開發轉型，讓運維本身開發所需的工具來實現自動化。如今，咱們提倡運維服務化和平臺產品化，這個後文會提到。

接下來，我從文化、組織、人、流程、工具這幾個維度分享一下運維管理的點滴經驗。

 

 

咱們團隊的運維文化

 

 

運維文化：當一個團隊規模較大時，例如咱們團隊，有兩三百人的規模，這個時候咱們可能須要一些文化層面的東西來統一你們的思想，讓你們在行爲上按照咱們的文化來思考和執行。

咱們目前提倡的文化，叫「運維四化」：服務化、標準化、自動化、產品化。標準化和自動化你們都比較好理解，我就不講了。重點強調一下咱們爲何提出運維的服務化。

爲何要「服務化」？

 

 

運維的本質究竟是什麼？

我從2002年開始作運維，一直到如今，都算是在運維行業裏摸爬滾打，之前，我以爲作好發佈變動、故障處理，讓業務保持運行穩定就是運維的價值，但經過這幾年的思考和實踐，我以爲那是不夠的。

那麼運維的本質究竟是什麼呢？我以爲是服務，是服務於業務，由於運維是用技術解決業務問題，運維的價值要依託於業務才能體現。

運維不是由於技術高深，或者管理了幾萬臺服務器而很牛逼，也不是能玩轉不少開源工具而很牛逼，這都不是運維的關鍵。

我提一個觀點：對於運維來講，服務第一，技術第二。運維技術再牛，若是不能服務於業務，幫助業務取得成功，那價值也是有限的。那麼怎樣服務業務呢？咱們總結了四點：

貼近業務：就是咱們必定要與業務走得比較近，保持信息的暢通；

理解業務： 要知道業務目標是什麼，用戶羣是什麼，商業模式是什麼樣的。以前我見過不少運維，甚至在公司作了半年、一年，還不知道所運維的業務的商業模式是什麼，這樣 的話咱們怎麼能有針對性地提供服務，去幫助業務成功呢？ 理解業務還意味着要站在業務運營的角度思考問題，而不只僅站在運維的角度思考。

挖掘需求背後的價值：咱們常常會收到運營人員提出的需求，在理解業務的基礎上，咱們要挖掘這些業務需求背後的價值，好比說運營人員讓發一個版本，作爲運維，咱們是否是把這個版本發佈完就OK了呢？

確定是不夠的，咱們還要去看業務發這個版本的目的是什麼？多是爲了拉新用戶，也有多是作個活動去拉收入，或者是修復bug。

每 一個版本的目的不同，運維所作的事情是能夠不一樣的。好比這個版本是拉新用戶，咱們把版本發佈完之後，還能夠採集更多的數據，去幫助運營人員分析，看是不 是達到了拉新用戶的目的。或者協助運營人員分析，這個版本的用戶體驗對於拉新用戶是否是有瓶頸。這都是運維可作的事情，也是業務運營很須要的事情。

擴展服務價值：着眼於業務和服務，咱們能夠不斷挖掘到新的價值點，擴展運維服務的價值。

固然了，這裏毫不是說技術不重要，優秀的運維服務須要強大的技術來支持。舉個例子，你想協助運營人員作用戶體驗的分析，這須要較強的技術能力來支撐。由於像上述的版本數據分析對實時性的要求很高，若是你沒有及時分析出來，錯過了運營時機可能就來不及調整了。

能夠說，業務視角和服務意識決定了運維服務能夠拓展到哪裏，而技術能力則決定了這些服務最終能夠實現多少。

前文講了咱們的歷程，在2009年，咱們作了一些組織分工，咱們DBA團隊，開發團隊，安全團隊都從這裏分離出來了。

 

關於組織

這裏想分享的經驗是：當團隊和業務發展到必定規模的時候必定要考慮到專業化分工，業務和團隊規模小的時候不必分的太細，由於業務場景對專業性的要求可能不高，隨着業務發展和團隊變大，專業性的要求就高了。

因此咱們如今的內部劃分紅5個角色，第一個角色是運維規劃。你們能夠認爲它是運維的PM，他起到的做用是充分理解業務需求，挖掘需求背後的價值，同時他也熟悉運維內部的各類資源，能夠協調各類資源來知足業務的需求。這些運維規劃都是從運維成長起來的，懂運維。

第二個角色業務運維，這個就不講了，你們都清楚。

第 三個角色DBA，你們都知道DBA的重要性，他們最重要的職責之一就是要保證數據的安全。一個業務，就算是遇到像攜程此次的狀況，就算所有線上環境都沒有 了，可是隻要數據還在，業務都仍是能夠恢復的，但若是連數據都找不到了，那就真完蛋了，因此DBA必定是獨立的，必定要保證數據是萬無一失的。

系統運維這個角色也不說了，你們也比較清楚。

還有就是運維開發的角色，咱們以爲運維開發不是傳統的開發，運維開發首先是運維，其次纔是開發，他們須要站在運維視角看問題的，站在運維視角開發工具給運維用。

 

關於人員管理和培養體系

 

 

組織裏最重要的是人。在一個必定規模的團隊裏，創建人員的成長和培養體系是很重要的，尤爲像規模到幾百人的時候，咱們怎麼樣保證團隊裏的同窗們具有相應的能力和成長空間。

在咱們團隊裏，有一套運維的成長體系，運維同窗但願從事管理或者協調方面的工做，能夠往運維規劃方向發展；若是但願從事開發方面的工做，能夠向運維開發方向發展。

配 合成長體系，有一套培養體系。新人加入之後，首先有新人培訓。這裏所培訓的內容都是與運維相關的，好比運維繫統的培訓，在新人培訓裏有專門的篇幅是安全意 識相關的，從剛入職開始就灌輸安全意識。此外，新人培訓中還包括騰訊遊戲運維血淚史，經過分享以前的教訓提升新同窗的運維操做意識。

新人在入職之後到轉正有三個月，在這三個月中，通常狀況下新同窗不能獨立操做正式的運營環境。只能在導師的帶領下操做。

那怎麼才能具有獨立操做能力呢？須要考運維上崗認證，這個認證包括考試和評估兩個環節，考試的內容大部分是新人培訓的內容，例如安全意識、運維操做規範等。

評估的形式是幾位資深的運維現場對被評估者進行評測，考察他們在各類場景的理解和反應，這些是不能經過背書本知識來回答的，因此仍是比較考驗新同窗的能力和意識的。

經過上崗認證後會拿到一個上崗證，之前是會發一個紅色的證書，如今不發了實體證書了，變成電子的了。這個上崗證後面還有一個做用，後面我會講到。

新同窗轉正後，平常工做中會接觸到不少技術培訓和分享，這些大部分是由內部同窗貢獻的，固然也有公司內外部的各類培訓資源。

當 某位同窗在團隊內工做了一段時間以後可能會面臨成長的問題，咱們會挑選出有潛力的同窗上運營規劃培養班或運維開發培訓班。這兩個培養班分別培養運營規劃和 運維開發。拿運營規劃培養班作例子，選定的同窗通過半年的培養後經過考覈才能成爲的運營規劃，經過率大概在40~60%；

運維人員的考覈體系

 

 

運維人員的考覈分爲幾個部分：

第一，業務指標。

業務指標就是業務的一些關鍵性指標，好比可用性、發佈效率等等，還有不少其餘指標。這些指標的做用是評估運維人員的基礎工做完成質量，這是由QA，就是前面所述的質量管理團隊統計的，不是運維本身上報的，這樣能夠保證其客觀性。

第二，關鍵事件。

關鍵事件是運維本身制定的，用於引導運維不斷優化工做。這個關鍵事件每月定一次，由運維和他的leader和運維規劃三方一塊兒制定。

舉個例子，咱們發現某個遊戲它的發佈時長過長，就能夠把發佈時長優化作爲這個遊戲的運維人員這個月的關鍵事件，目標是把這個業務的發佈時長從多少降到多少。制定關鍵事件的目標時比較細，要求是量化的，月底時運維根據完成狀況得到關鍵事件的得分。

第三，加分項目。

例如作分享和培訓均可以加分，積極參加團隊建設也能夠得到加分。

第四，扣分項目

我 們的考覈思路是儘可能用正向加分的方式引導，通常不扣分。除非是人爲失誤形成業務故障。所謂人爲失誤指運維操做不當形成的問題，咱們對人爲失誤持「低容忍」 的態度，由於咱們以爲作爲運維，意識是很是重要的，操做時要時時刻刻秉持當心謹慎的態度，抱着敬畏的心情對待運營環境。

若是出現人爲失誤形成業務故障的狀況，對於我的會有什麼影響呢？

前 面提到的運維上崗證的另外一個做用就在這裏了，你們都知道違章後駕照扣分這項處罰措施挺有威懾力的，咱們吸收了經驗，對運維上崗證也實行積分扣分制度：運維 上崗證每半年都有10分的積分，若是出現人爲失誤的故障就從中扣除必定的分數，若是分數扣完，上崗證就會被註銷，那麼這位運維就須要被評估是否適合在運維 崗位上繼續工做了。

固然，這個扣分制度的目的確定不是爲了處罰，主要仍是但願經過這種方式提升你們的操做意識，避免人爲失誤。有的同窗可能會問，爲何不靠自動化來下降人爲失誤，而要用這種考覈手段？

這裏我想說，根據咱們的經驗，遊戲運維是很複雜的體系，特別是團隊大了之後，自動化程度再高仍是有不少人爲失誤的空間，最終的決定性因素仍是人，因此，意識強化和考覈手段仍是不可或缺的。

 

關於流程的幾點思考

 

 

流程的本質就是管理和控制，其實你們作的每一件事情都有流程，隨便作一個發佈，作的這些步驟就是流程，因此流程實際上是無處不在的。

不少運維同窗都以爲流程好麻煩，以爲流程就是給運維的桎梏，其實用好流程是能夠保護運維的。咱們不少時候須要跟運營和研發配合，若是用好了流程這個工具是能夠保護運維利益的。

可是，流程執行起來的確有成本，那怎麼下降流程的成本呢？

咱們以爲流程應該「隱形化」，就是讓流程融入到運維繫統中，讓運維同窗不用花額外的精力去執行流程，感受不到流程的存在，讓流程起到控制做用的同時，儘可能不下降咱們的效率。

 

關於工具建設的幾點思考

 

首先，咱們認爲工具的建設者必須是工具的使用者， 要懂得應用場景，不然的話，造出來的工具是很差用的。由於在這裏咱們是吃過一些虧的，剛纔提到2009年咱們就創建了運維開發團隊，可是到2011年發現 咱們工具覆蓋的狀況仍是不夠好，運維不肯意用，咱們創建的是專業的開發團隊，有產品經理、開發、測試，可是爲何作出來的工具就不對運維的胃口呢？

咱們後來發現，開發團隊並不懂運維場景，雖然他們也會作不少運維需求的訪談，但老是發現作出來的東西不是運維想要的。

因此後來咱們改變了工具開發的模式，改爲在運維中培養運維開發，讓運維開發本身開發工具給本身用。這樣的話，爲了下降開發成本，咱們作了藍鯨平臺，運維只要通過兩週左右的培訓就能夠在藍鯨上面開發工具。

標準化是自動化最重要的一個基礎，若是沒有標準化的話自動化是不會長久的。若是業務之間架構差別過大怎麼辦呢？能夠下降標準化的維度，好比咱們去實現原子操做的標準化。

瞭解的同窗應該知道，遊戲架構是很不標準化的，遊戲不像Web應用，有不少框架模型，它沒有，各家廠商各作各的，所以咱們只能作原子操做的標準化，而後再在其上去組裝各類場景做業。

我 們作自動化必定要打通企業內的各個信息孤島，全流程的自動化纔是真正的自動化。只有都打通了，在做業執行過程當中纔不會中斷，能夠實現無人值守的自動化，藍 鯨平臺就是這樣的，它有一條ESB，打通了不少外部的系統接口。運維在藍鯨上開發工具須要打通其餘系統的直接調用就好了，大大提升了開發效率。

產品化：運維平臺要以產品理念建設

最後，我想說的是，前面提到運維文化中有一個產品化，爲何提產品化？由於我以爲運維平臺是要以產品的理念來建設的，這裏包括不少的層面，這裏就簡單提其中一點：重視平臺的用戶交互。之前，你們以爲運維平臺是內部系統，能用就行，交互好很差無所謂。

可是咱們發現，內部平臺也須要交互優良，若是交互很差的話，可能有如下負面做用：一是交互很差容易形成誤操做的狀況引起故障；二是交互很差，很難用的話可能會被內部用戶拋棄，被新的系統或平臺替代。

因此，運維平臺作爲內部平臺，也須要重視用戶的交互，必定要有良好的界面，要讓用戶操做起來比較方便並且不容易發生誤操做。