騰訊最賺錢的部門是怎麼做運維的？
騰訊遊戲運營管理總監劉棲銅
騰訊互動娛樂事業羣的主營業務是遊戲，所有騰訊遊戲都是由這個事業羣做的，估計很多人都玩過，像《英雄聯盟》、《全民突擊》等。我所在的部門叫運營部，負責所有騰訊遊戲的技術運營工作。
簡單解釋一下，什麼叫技術運營工作，這裏包括了幾個部分：運維，營銷開發，數據分析和數據挖掘，用戶運營（所謂用戶運營，不是傳統的客戶服務，是一些高端的用戶運營。）
比如說在騰訊遊戲上一年花八萬，就是我們的VIP，我們有專屬的服務經理對接，就像銀行的VIP用戶一樣。這裏就不展開了，重點說說我所負責的運維管理工作吧：
如上所說，我們所負責的運維工作，是運營部的一部分工作。我們現在運維了幾百款遊戲，而且數字還在快速增長，特別手遊加入以來，每年都有一兩百款。
簡單介紹一下騰訊遊戲運維團隊的發展歷程：我們團隊是2003年隨着騰訊代理《凱旋》遊戲而成立的，發展到2005年的時候，我們做了一件事情，就是DO分離，DO分離的概念前些年提得比較多，現在大家好像不再提了。回頭來看，我們覺得DO分離是很有必要的，因爲開發跟運維需要具備的核心能力是不同的。
接下來，在2006年的時候我們做了QO分離，意思就是我們把質量管理團隊（QA）和運維分離開了，這個後面我會再講一下。隨着團隊進一步擴張，業務進一步增加，2007年的時候我們把DBA專業團隊分離出來了。
到2009年的時候發現業務發展很快，老闆不給我們這麼多人，怎麼辦？光靠人去填的模式已經運行不下去了，所以當時成立了運維開發團隊，專門建設運維工具。同時在2009年我們還成立了一個內部安全團隊，這個團隊可能很多公司都沒有，比較特殊。
因爲大家知道遊戲行業，有些遊戲類道具非常值錢，說不準哪個同學手一抖給自己加個幾十萬，所以我們成立了內部安全團隊，做安全監控，其中也包括權限控制，大家都知道，自動化系統權限控制非常重要，如果這個沒控制好就會出現災難性後果。
時間到了2012年，我們開始提倡運維轉型，鼓勵運維向運維開發轉型，讓運維自己開發所需的工具來實現自動化。現在，我們提倡運維服務化和平臺產品化，這個後文會提到。
接下來，我從文化、組織、人、流程、工具這幾個維度分享一下運維管理的點滴經驗。
我們團隊的運維文化
運維文化：當一個團隊規模較大時，例如我們團隊，有兩三百人的規模，這個時候我們可能需要一些文化層面的東西來統一大家的思想，讓大家在行爲上按照我們的文化來思考和執行。
我們目前提倡的文化，叫“運維四化”：服務化、標準化、自動化、產品化。標準化和自動化大家都比較好理解，我就不講了。重點強調一下我們爲什麼提出運維的服務化。
爲什麼要“服務化”？
運維的本質到底是什麼？
我從2002年開始做運維，一直到現在，都算是在運維行業裏摸爬滾打，以前，我覺得做好發佈變更、故障處理，讓業務保持運行穩定就是運維的價值，但通過這幾年的思考和實踐，我覺得那是不夠的。
那麼運維的本質到底是什麼呢？我覺得是服務，是服務於業務，因爲運維是用技術解決業務問題，運維的價值要依託於業務才能體現。
運維不是因爲技術高深，或者管理了幾萬臺服務器而很牛逼，也不是能玩轉很多開源工具而很牛逼，這都不是運維的關鍵。
我提一個觀點：對於運維來說，服務第一，技術第二。運維技術再牛，如果不能服務於業務，幫助業務取得成功，那價值也是有限的。那麼怎樣服務業務呢？我們總結了四點：
1.貼近業務：就是我們一定要與業務走得比較近，保持信息的暢通。
2.理解業務： 要知道業務目標是什麼，用戶羣是什麼，商業模式是什麼樣的。之前我見過很多運維，甚至在公司做了半年、一年，還不知道所運維的業務的商業模式是什麼，這樣的話，我們怎麼能有針對性地提供服務，去幫助業務成功呢？ 理解業務還意味着要站在業務運營的角度思考問題，而不僅僅站在運維的角度思考。
3.挖掘需求背後的價值：我們經常會收到運營人員提出的需求，在理解業務的基礎上，我們要挖掘這些業務需求背後的價值，比如說運營人員讓發一個版本，做爲運維，我們是不是把這個版本發佈完就OK了呢？
肯定是不夠的，我們還要去看業務發這個版本的目的是什麼？可能是爲了拉新用戶，也有可能是做個活動去拉收入，或者是修復bug。
每一個版本的目的不一樣，運維所做的事情是可以不同的。比如這個版本是拉新用戶，我們把版本發佈完以後，還可以採集更多的數據，去幫助運營人員分析，看是不是達到了拉新用戶的目的。或者協助運營人員分析，這個版本的用戶體驗對於拉新用戶是不是有瓶頸。這都是運維可做的事情，也是業務運營很需要的事情。
4.擴展服務價值：着眼於業務和服務，我們可以不斷挖掘到新的價值點，擴展運維服務的價值。
當然了，這裏絕不是說技術不重要，優秀的運維服務需要強大的技術來支持。舉個例子，你想協助運營人員做用戶體驗的分析，這需要較強的技術能力來支撐。因爲像上述的版本數據分析對實時性的要求很高，如果你沒有及時分析出來，錯過了運營時機可能就來不及調整了。
可以說，業務視角和服務意識決定了運維服務可以拓展到哪裏，而技術能力則決定了這些服務最終可以實現多少。
前文講了我們的歷程，在2009年，我們做了一些組織分工，我們DBA團隊，開發團隊，安全團隊都從這裏分離出來了。
關於組織
這裏想分享的經驗是：當團隊和業務發展到一定規模的時候一定要考慮到專業化分工，業務和團隊規模小的時候沒必要分的太細，因爲業務場景對專業性的要求可能不高，隨着業務發展和團隊變大，專業性的要求就高了。
所以我們現在的內部劃分成5個角色，第一個角色是運維規劃。大家可以認爲它是運維的PM，他起到的作用是充分理解業務需求，挖掘需求背後的價值，同時他也熟悉運維內部的各種資源，可以協調各種資源來滿足業務的需求。這些運維規劃都是從運維成長起來的，懂運維。
第二個角色業務運維，這個就不講了，大家都清楚。
第三個角色DBA，大家都知道DBA的重要性，他們最重要的職責之一就是要保證數據的安全。一個業務，就算是遇到像攜程這次的情況，就算全部線上環境都沒有了，但是隻要數據還在，業務都還是可以恢復的，但如果連數據都找不到了，那就真完蛋了，所以DBA一定是獨立的，一定要保證數據是萬無一失的。
系統運維這個角色也不說了，大家也比較清楚。
還有就是運維開發的角色，我們覺得運維開發不是傳統的開發，運維開發首先是運維，其次纔是開發，他們需要站在運維視角看問題的，站在運維視角開發工具給運維用。
關於人員管理和培養體系
組織裏最重要的是人。在一個一定規模的團隊裏，建立人員的成長和培養體系是很重要的，尤其像規模到幾百人的時候，我們怎麼樣保證團隊裏的同學們具備相應的能力和成長空間。
在我們團隊裏，有一套運維的成長體系，運維同學希望從事管理或者協調方面的工作，可以往運維規劃方向發展；如果希望從事開發方面的工作，可以向運維開發方向發展。
配合成長體系，有一套培養體系。新人加入以後，首先有新人培訓。這裏所培訓的內容都是與運維相關的，比如運維繫統的培訓，在新人培訓裏有專門的篇幅是安全意識相關的，從剛入職開始就灌輸安全意識。此外，新人培訓中還包括騰訊遊戲運維血淚史，通過分享之前的教訓提高新同學的運維操作意識。
新人在入職以後到轉正有三個月，在這三個月中，一般情況下新同學不能獨立操作正式的運營環境。只能在導師的帶領下操作。
那怎麼才能具備獨立操作能力呢？需要考運維上崗認證，這個認證包括考試和評估兩個環節，考試的內容大部分是新人培訓的內容，例如安全意識、運維操作規範等。
評估的形式是幾位資深的運維現場對被評估者進行評測，考察他們在各種場景的理解和反應，這些是不能通過背書本知識來回答的，所以還是比較考驗新同學的能力和意識的。
通過上崗認證後會拿到一個上崗證，以前是會發一個紅色的證書，現在不發實體證書了，變成電子的了。這個上崗證後面還有一個作用，後面我會講到。
新同學轉正後，日常工作中會接觸到很多技術培訓和分享，這些大部分是由內部同學貢獻的，當然也有公司內外部的各種培訓資源。
當某位同學在團隊內工作了一段時間之後可能會面臨成長的問題，我們會挑選出有潛力的同學上運營規劃培養班或運維開發培訓班。這兩個培養班分別培養運營規劃和運維開發。拿運營規劃培養班做例子，選定的同學經過半年的培養後通過考覈才能成爲的運營規劃，通過率大概在40~60%。
運維人員的考覈體系
運維人員的考覈分爲幾個部分：
第一，業務指標。
業務指標就是業務的一些關鍵性指標，比如可用性、發佈效率等等，還有很多其他指標。這些指標的作用是評估運維人員的基礎工作完成質量，這是由QA，就是前面所述的質量管理團隊統計的，不是運維自己上報的，這樣可以保證其客觀性。
第二，關鍵事件。
關鍵事件是運維自己制定的，用於引導運維不斷優化工作。這個關鍵事件每個月定一次，由運維和他的leader和運維規劃三方一起制定。
舉個例子，我們發現某個遊戲它的發佈時長過長，就可以把發佈時長優化做爲這個遊戲的運維人員這個月的關鍵事件，目標是把這個業務的發佈時長從多少降到多少。制定關鍵事件的目標時比較細，要求是量化的，月底時運維根據完成情況獲得關鍵事件的得分。
第三，加分項目。
例如做分享和培訓都可以加分，積極參加團隊建設也可以獲得加分。
第四，扣分項目
我們的考覈思路是儘量用正向加分的方式引導，一般不扣分。除非是人爲失誤造成業務故障。所謂人爲失誤指運維操作不當造成的問題，我們對人爲失誤持“低容忍” 的態度，因爲我們覺得做爲運維，意識是非常重要的，操作時要時時刻刻秉持小心謹慎的態度，抱着敬畏的心情對待運營環境。
如果出現人爲失誤造成業務故障的情況，對於個人會有什麼影響呢？
前面提到的運維上崗證的另一個作用就在這裏了，大家都知道違章後駕照扣分這項處罰措施挺有威懾力的，我們吸取了經驗，對運維上崗證也實行積分扣分制度：運維上崗證每半年都有10分的積分，如果出現人爲失誤的故障就從中扣除一定的分數，如果分數扣完，上崗證就會被註銷，那麼這位運維就需要被評估是否適合在運維崗位上繼續工作了。
當然，這個扣分制度的目的肯定不是爲了處罰，主要還是希望通過這種方式提高大家的操作意識，避免人爲失誤。有的同學可能會問，爲什麼不靠自動化來降低人爲失誤，而要用這種考覈手段？
這裏我想說，根據我們的經驗，遊戲運維是很複雜的體系，特別是團隊大了以後，自動化程度再高還是有很多人爲失誤的空間，最終的決定性因素還是人，所以，意識強化和考覈手段還是不可或缺的。
關於流程的幾點思考
流程的本質就是管理和控制，其實大家做的每一件事情都有流程，隨便做一個發佈，做的這些步驟就是流程，所以流程其實是無處不在的。
很多運維同學都覺得流程好麻煩，覺得流程就是給運維的桎梏，其實用好流程是可以保護運維的。我們很多時候需要跟運營和研發配合，如果用好了流程這個工具是可以保護運維利益的。
但是，流程執行起來的確有成本，那怎麼降低流程的成本呢？
我們覺得流程應該“隱形化”，就是讓流程融入到運維繫統中，讓運維同學不用花額外的精力去執行流程，感覺不到流程的存在，讓流程起到控制作用的同時，儘量不降低我們的效率。
關於工具建設的幾點思考
首先，我們認爲工具的建設者必須是工具的使用者， 要懂得應用場景，否則的話，造出來的工具是不好用的。因爲在這裏我們是吃過一些虧的，剛纔提到2009年我們就建立了運維開發團隊，但是到2011年發現我們工具覆蓋的情況還是不夠好，運維不願意用，我們建立的是專業的開發團隊，有產品經理、開發、測試，但是爲什麼做出來的工具就不對運維的胃口呢？
我們後來發現，開發團隊並不懂運維場景，雖然他們也會做很多運維需求的訪談，但總是發現做出來的東西不是運維想要的。
所以後來我們改變了工具開發的模式，改成在運維中培養運維開發，讓運維開發自己開發工具給自己用。這樣的話，爲了降低開發成本，我們做了藍鯨平臺，運維只要經過兩週左右的培訓就可以在藍鯨上面開發工具。
標準化是自動化最重要的一個基礎，如果沒有標準化的話自動化是不會長久的。如果業務之間架構差異過大怎麼辦呢？可以降低標準化的維度，比如我們去實現原子操作的標準化。
瞭解的同學應該知道，遊戲架構是很不標準化的，遊戲不像Web應用，有很多框架模型，它沒有，各家廠商各做各的，因此我們只能做原子操作的標準化，然後再在其上去組裝各種場景作業。
我們做自動化一定要打通企業內的各個信息孤島，全流程的自動化纔是真正的自動化。只有都打通了，在作業執行過程中纔不會中斷，可以實現無人值守的自動化，藍鯨平臺就是這樣的，它有一條ESB，打通了很多外部的系統接口。運維在藍鯨上開發工具需要打通其他系統的直接調用就行了，大大提高了開發效率。
產品化：運維平臺要以產品理念建設
最後，我想說的是，前面提到運維文化中有一個產品化，爲什麼提產品化？因爲我覺得運維平臺是要以產品的理念來建設的，這裏包括很多的層面，這裏就簡單提其中一點：重視平臺的用戶交互。以前，大家覺得運維平臺是內部系統，能用就行，交互好不好無所謂。
但是我們發現，內部平臺也需要交互優良，如果交互不好的話，可能有以下負面作用：一是交互不好容易造成誤操作的情況引發故障；二是交互不好，很難用的話可能會被內部用戶拋棄，被新的系統或平臺替代。
所以，運維平臺做爲內部平臺，也需要重視用戶的交互，一定要有良好的界面，要讓用戶操作起來比較方便而且不容易發生誤操作。