本文由馬哥教育M18期就職於騰訊遊戲學員推薦，作者為吳啟超、Tom，採編自騰訊課堂，感謝作者辛苦付出。

近期因遊戲造成全民沉淪論的《王者榮耀》可謂是在風頭浪尖上，超2億註冊使用者、日活躍使用者5000萬、一月超30億元的流水——《王者榮耀》已成為社會現象級手遊，隨之問題接踵而來。部分小學生沉迷後為買遊戲道具刷爆家長銀行卡、為搶奪遊戲中“buff(增益效果)”大打出手。

這些問題怎麼產生？

責任又應由誰來承擔？

如何進行有效的防止沉迷監管？

種種問題引發社會廣泛討論。

馬哥Linux作為Linux運維的號，我們不想談論《王者榮耀》的對與錯，只想說的是：適當娛樂，不傷大雅。

今天小編帶大家走進這些不為人知的幕後英雄Linux遊戲運維的世界，一起窺探這神祕世界的一草一木。

王者榮耀從2015下半年至今取得輝煌成就，正所謂最好的愛情莫過於各自努力彼此成就：），運維這期間是Tcaplus伴其成長，遇到了很多風險和挑戰。

Tcaplus的管理模組由儲存服務全域性管理系統(OMS)和tcapcenter組成，OMS向用戶呈現基於web的管理入口，將使用者的指令轉發給tcapcenter，實際的控制、管理工作由tcapcenter完成，OMS則將操作的進度和結果反饋給使用者。每個儲存叢集有一個tcapcenter，而OMS與tcapcenter之間是一對多的關係，因此一個OMS可以管理多個儲存叢集。

2、儲存叢集是一組硬體資源的集合體，對其位置沒有特別的限制，但按照慣例，同一個叢集的節點都應在同一個IDC內，以保證儲存服務的效能。

3、Tcaplus資料服務模組的工作原理：API client連線tcapdir，讀取tcaproxy列表；tcapdir是Tcaplus API使用者在初始化系統時唯一需要提供的資訊；tcapdir可以部署多個，以達到容災的效果；API client獲取tcaproxy列表之後，連線所有的tcaproxy程序。使用者傳送資料讀寫請求，Tcaplus API根據使用者所指定的表名及key欄位資訊，決定將請求傳送給哪個tcaproxy程序。tcaproxy程序接收到請求訊息後，根據其維護的路由表確定目標tcapsvr master，然後將訊息轉發給該tcapsvr master。tcapsvr master接收到請求訊息之後，進行資料讀寫，並生成響應訊息，原路返回經由proxy到達API client. 如果請求訊息型別為寫操作，tcapsvr在傳送響應之前，實際上還會生成一條binlog記錄，在較短時間內（毫秒~秒級）同步至slave，使得slave可實時維護一份與master相同的資料。

Tcaplus整體架構

回到正題，說一說我們的遊戲運維及運維的生存指南和現狀。

一直以來，中國網遊在世界上都處於舉足輕重的地位。從最早的端游到頁遊再到手遊，不僅市場使用者爆發式增長，近15年來網遊技術的發展也是無比迅速。和單機遊戲不同，網遊除了遊戲製作本身以外還牽涉到伺服器端，再好的遊戲如果出現連結、延遲等問題時也會造成巨大損失，這時候遊戲運維便發揮了舉足輕重的作用。

中國網遊的發展史，其實也是遊戲運維的變革史，我們來看看網路遊戲在中國的發展歷程吧。

聯眾桌牌類遊戲始於1998年，當然，嚴格意義上講，這還算不上網遊，真正的網遊應該始於2000年開始的《萬王之王》和里程碑的遊戲《石器時代》；

2002年，《傳奇》出現，為網遊史新增上了濃重的一筆，也算是中國網遊史的分水嶺；

2003年，網路遊戲被國家被納入863計劃，也正式納入管理和審批。

順帶提一下，09年第二季度開始做網遊老大、行業第一的騰訊遊戲，也在這一年，出爐了第一款遊戲，也是一款代理遊戲、試水作:《凱旋》……由此開始，中國網遊進入百花齊放的階段。

不難看出，中國網遊還是個孩子，遊戲應用運維工程師，更是最近幾年衍生的新生職業領域。 隨著D/O分離的加速，遊戲運維工程師越來越多的承擔著更重要的責任。

一、有伺服器的地方就有運維

如今我們說到遊戲，可能想到的是火爆異常的VR，辦公室裡一言不合帶上眼鏡就地開打；亦或是剛剛虐了李世石的AlphaGo，揚言要挑戰《星際爭霸2》“教主”Flash。然而，除去這些還有一個遊戲行業不可避免的潮流正在發生，那便是網路化。

這裡說的不止是網遊，前不久育碧旗下網遊大作《全境封鎖》上線時鬧出個小笑話：由於很多國內玩家下載之前沒注意是網遊，下意識的以為育碧的遊戲肯定是單機，好不容易下完之後才發現玩不上，進而發生了不少的騷動。這不是第一個發生這種情況的傳統遊戲廠商，肯定也不是最後一個，很多有名的遊戲公司都在做類似的嘗試，Popcap的《植物大戰殭屍：花園戰爭》系列，暴雪的《暗黑3》等，甚至那些還有單機成分的大作也早就開始網路化：大名鼎鼎的《GTA5》、FPS風向標《使命召喚》系列和《戰地》系列，網路聯機部分的比重也在一年一年的增加。

網路聯機，意味著玩家需要登入官方伺服器，“有人的地方就有江湖”，這句話說的不僅是網遊裡的恩怨情仇，還包括遊戲外的種種：“有伺服器的地方就有運維。”這便是今天我們要說的話題——遊戲運維。

二、遊戲運維編年史

1 石器時代：端遊

想要了解如今的遊戲運維，不得不從早期的端遊運維開始說起。對於08年入行端遊，11年經歷過頁遊最後14年全面接觸手遊的吳啟超來說，這幾年的遊戲運維經歷讓他深切感受到運維思路的巨大轉變。

1.1端遊的運維工種：IDC運維、系統型運維、網路運維、業務型運維、運維值班等。各個工種分工各有側重。

IDC運維：裝機、換配件、扛著2U的伺服器全國各個機房來回跑。

系統運維：安裝各種軟體，除錯各種不相容的軟體，在各種版本的Linux、Windows上。

網路運維：二層交換、三層交換、四層交換，還要區分華為、思科。

業務運維：24點維護，零晨2點維護，零晨5點維護，早上7點維護……

運維值班：0點盯著螢幕打電話，1點盯著螢幕打電話，2點盯著螢幕打電話……

運維開發：寫著各種的邏輯，因為業務、網路環境、BUG、剛剛幫忙扛完伺服器。

1.2端遊運維業務範圍：在端遊時代，大部分遊戲公司都是自主做各種業務環境，做各種遊戲業務需要的各種環境。

資產管理：伺服器、交換機、各種服務分佈位置，埠等。

下載伺服器：搭建BT叢集，做種子、分發，供玩家下載遊戲客戶端使用。

靜態快取伺服器：squid+apache|nginx

郵件伺服器：postfix+sasl+ssl收發服務、反垃圾郵件服務。

網路質量監控：somkingping各個機房的交換，各個安放點伺服器。

配置管理：nginx、apache、lighttpd、MySQL。

批量管理：ssh公鑰/私鑰。

監控管理：nagios、catcai然後是c|perl|python|shell+rrdtool各種業務監控圖。

1.3端遊遊戲伺服器架構：一般來講都是以一組伺服器叢集為一個區服單位，單機上的程序提供不同的服務。

傳統運維，任務道遠，正因為有過去那些年的翻譯文件，兼顧整合方案，以及大批分享技術的前輩、社群，踩著前輩一步一個坑的走過來，才能有今天的運維的局面。

2.青銅時代：頁遊

在2011-2013年左右的頁遊運維，遊戲市場處於探索期，其實運維也處於探索期。端遊時代每個新服都要經歷上架、裝系統，裝服務的過程，一般一到兩週可以上線一個區服，對於端遊高粘性低流動的特性來說可能還好，但是當頁游出現時，轉變給運維帶來的衝擊無法估量。頁遊時代1天開100多個新服的概念，是傳統端遊運維所不能理解的。當時的運維認為頁遊就是把所有伺服器實現自動部署服務，同時搭配運維自動部服工具就可以了。但事實上如果在開服時一組一組的使用物理伺服器，開服速度根本跟不上，資源浪費還非常巨大，兩週後用戶留存率僅剩5%-7%。成本巨大虧空，急需技術轉型，這個時間點上出現了兩種概念影響了以後的手遊以及雲的發展。

2.1虛擬化技術

在2010年11月份左右，kvm出現在RHEL6中，去掉了RHEL5.X系列中整合的Xen。正是這一次虛擬化技術的轉型，而且當時市場的需要，在2011年-2012年掀起了一場私有云建設的風潮。在實踐過程中，優點很多，但暴露的缺點也不少。在端遊佔主要市場的情況下，實踐過程中表現出來的不適尤其明顯。

a.虛擬機器時鐘不準

b.虛擬機器網絡卡，超負荷down、丟包

c.多虛擬機器間爭搶cpu、記憶體

d.多虛擬機器間的安全訪問，虛擬機器與物理機間的安全管控

e.對於關係型資料庫磁碟讀寫慢問題突出。

f.等等

以上幾點隨著時間的推移有的已經然後解決，有的換上了代替方案。時至今日，端遊在單純的虛擬雲上部署仍是問題，但是隨著物理、虛掩混合雲出現，這個局面應該可以被打破。

2.2 社交化的頁遊

社群化的頁遊戲，為什麼這樣說呢，因為當時更多的頁遊信託社群入口，匯入使用者流量，當時最火的應該是人人網（校內網）的農場偷菜。然後是DZ論壇一堆農場外掛襲捲全國，當然這一切都是為了增加使用者粘稠度。但是也影響了頁遊技術的選型，當時基本上大家不約而的選用了於社群相同的LAMP的技術，從而降低開發成本及接入成本。當然現使用JAVASSH2架構的頁遊也有。除技術選型外，同時還帶入了另一個概念：聯運。聯運這個概念在頁遊時代對於端遊運維就像一個惡夢，不同區服要隨時跨服站，不同區服要隨時可以合區，所有資料不再是以物理伺服器為單位，而是要逐條打標籤，再也看不到賬號，只能拿著一串長長的KEY，四處兌換，然後拿著不知道所謂的表標問第三方…….

在這個時期，是運維開發的爆發年，隨著虛擬化技術的推廣，越來的越多的運維開始接觸自動化運維的概念，開始了自動化運維的奮鬥之路，開始了以專案管理的角度看待運維指令碼開發。

3.黃金時代：手遊

隨著私有云轉為公有云、雲時代推動著雲端計算以及移動網際網路的發展，網遊行業慢慢進入了手遊黃金時代，雲時代的變革不僅挑戰了整個遊戲行業，也挑戰了遊戲運維。

3.1手遊的運維工種：系統型運維，業務型運維。

3.2手遊運維業務範圍：阿里雲、亞馬遜、UCloud、藍汛CDN、騰訊藍鯨、聽雲監控。

3.3手遊遊戲伺服器架構：一般來講都是以一組伺服器叢集為一個平臺單位，不同的叢集提供不同的服務。

手遊的架構理念是提供一組虛擬伺服器，當短連線的時候，每開一組服，將玩家引導到Web叢集，隨後被分配到不同的MongoDB，資料快取用在Redis。當第一個伺服器玩家請求DB時，會落到Mongo1上；當開第二個服的時候，還是將玩家引導到Mongo1上；以此類推直到運維發現壓力累積到一定程度時，便會新開一組MongoDB，Web叢集也是如此但只有效能不夠時才會新增，一般情況下，每50個新服可能需要新增1個MongoDB。這便實現並解釋了當時在頁遊裡希望實現的快速開服方法。

到此為止我們已經回顧了一遍遊戲運維從端游到頁遊再到手遊的演變過程，不難看出，手遊對於區服的架構概念不同於端遊：端遊認為一個物理叢集是一個服，而手遊認為一個Web請求落到相應的資料庫上就是一個服。這樣的好處是開服合服都簡單，如果前五十組伺服器需要合併，實現起來很容易，因為同一個DB的資料是互通的，所以只需發一個公告，伺服器加標識即可，不需要進行物理操作也不需要資料遷移。

4.遊戲運維最強指南

說完了遊戲運維的歷史，我們要開始今天的重頭戲，如何做好遊戲運維？這裡就用吳啟超的一個冷笑話作為開始：運維為什麼存在？a，有伺服器；b，因為研發忙不過來。不管是笑沒笑，運維確實因為上面兩個原因才會誕生的。那麼回到正題，想成為玩轉上千伺服器的遊戲運維應該怎麼樣做呢？系統部運維構建大致如下圖：

4.1構建CMDB

21世紀什麼最重要？資訊最重要！運維所需資訊要涉及：機房、物理伺服器、虛擬機器、交換機、網路、承載業務、業務配置、承載服務程序、埠等資訊。不管是自己採購還是購買雲服務，物理伺服器和虛擬伺服器都做為資產存在，在採購後錄入相關的資產管理，給它打上標籤，屬於哪個遊戲，哪個平臺，這樣不同遊戲平臺間就不能混用伺服器了。然後，是再給不同的伺服器標識它承擔的業務角色，比如它是MongoDB，我們需要打上的標籤會是大掌門-APPSTORE-MongoDB-主庫-90000埠-第一組服務。這樣一個基礎資訊錄入就完成了。

這樣的資訊只要是用來將來批量化部署、管理伺服器使用，以及當出現故障時，運維可以很方便的查詢相當的伺服器以及服務資訊。但是資料的及時性、準確性、可檢查是一個難點。

4.2 集中批量化管理

CMDB不是TXT檔案，而是要變成EXE檔案。運維在面臨大量伺服器的情況下，批量化工具的出現成為必須的結果，在日常的工作當中需要把其流程固化下來，為完成批量化安裝、管理打下基礎。大掌門喜歡使用sshsshpassparamikolibssh2這些基礎的技術做批量管理。原因是不用安裝簡單、穩定、安全、可控。當然吳啟超也表示推薦大家使用在市面上流程行puppet、Ansible、SaltStack等技術，為什麼？簡單、簡單、簡單！下圖就是在做自動化半自動化運維過程中的模型。

批量管理的難點在於：

a.命令的併發執行，要控制各點的超時時間

b.執行過程中，不同功能的不同許可權要求

c.資料通訊安全的保證，以及能夠正常解析資料指令

d.人員賬號許可權管理，許可權分發及回收

e.物理伺服器、雲伺服器統一化安裝及老專案改造

f.網路質量不可靠的情況下，執行不完整的情況下業務功能回滾。

4.3 效能與業務監控

4.3.1 應用效能監控

1、每天都會對伺服器進行上線，升級等操作，每款遊戲在一個平臺的叢集數在幾十個到幾百個不等（根據平臺大小）。因此每天維護和升級伺服器壓力極大，伺服器異常或響應慢等問題的發生會給使用者體驗帶來傷害。?這樣的隱患在於一旦發生遊戲關服之後就必須對玩家進行遊戲中貨幣和元寶的賠償，平均每個玩家補償的元寶至少在5元以上，遊戲幣和各類遊戲道具若干，以此類推由於伺服器故障造成的損失可想而知。

2、大掌門使用了聽雲Server，能夠對伺服器響應慢和不可用進行定位，檢視慢應用追蹤和Web應用過程功能，能夠實時定位消耗資源最大的程式碼和語句，這樣就能幫助實時進行有針對性的調整和優化，並且可以快速定位問題時間，最快能到分鐘級別。

3、發生高併發、伺服器壓力激增的情況時，平時執行正常的伺服器異常概率大幅增加，日常可能的效能瓶頸點會被成倍放大，這就需要實時定位和解決效能瓶頸點，和提前進行預防改善。一般來說，傳統日誌收集方式耗時耗力，效果非常不好，大掌門用了聽雲Server後，可以進行1分鐘級定位能迅速有效發現瓶頸點。同時還結合了聽雲Network的壓測功能，能夠在伺服器上線前提前發現到高壓力下的瓶頸點，提前預防，避免由於高併發出現的伺服器瓶頸

4、還有一種效能情況需要提前預防，遊戲公司盈利在於玩家的充值，對於官網上從登陸到充值全流程的成功率業務部門極其關注，玩家點選跳轉的失敗會直接導致充值付費使用者的轉化率。對此，大掌門通過聽雲Network的事務流程功能能夠實時對事物流程進行警報，幫助業務部門提升使用者充值的轉化率

4.3.2 業務監控

除了效能和硬體監控之外，對於遊戲業務運轉是否正常也需要建立一套標準去評判。

對此，大掌門開發了一套適用於全公司所有的遊戲的統一登陸、充值、交易平臺，解決了前端的SDK接入的問題，一個所有遊戲或第三方的API介面統一接入的平臺。在做業務型監控時，運維會要求後端開發人員寫一個特定賬號，在訪問現有系統時，會完整的走一遍業務流，這樣就可以看到需要的業務數字。

4.4 資料倉庫搭建

上圖為大掌門資料倉庫的結構圖，由於資料倉庫搭建的話題比較大，只是簡單的從資料集市的角度來聊聊，DM指的是資料集市。由於資料集市需要面對不同的人群，因此在資料倉庫中需要建立不同的資料集市以面對各方的查詢需求，進而對資料按照業務型別進行分類。

1、財務：關心月度充值資料

2、商務：關心渠道結算資料

3、運營：關心使用者登陸量、轉化率、留存率、平臺充值額

4、產品：關心功能熱度、使用者體驗

5、客服：關心所有資料及玩家屬性

對於資料方面，運維的壓力來自於需要貫穿及掌握所有的資料，並且為所有部門服務。簡單的以下圖的ETL為例：

資料對於運維的痛點：

1、日誌切割工作誰做？研發還是運維。日誌切割按什麼規則？大小還是日期？

2、使用什麼工具進行日誌收集？scribe還是flume還是sls？

3、資料的準確性誰來保證？日誌內容不對、切割不對、傳輸丟失、入hadoop過濾

4、資料ETL過程監控，如果出現數據丟失怎麼辦？

5、資料採集怎麼樣儘可能的保證併發的採集，縮短時間。

6、資料的出現丟失或錯誤，整體資料回滾。誰來保證？怎麼保證？

7、大量資料下，核對資料丟失情況怎麼樣核對？用什麼方法？

那大掌門又是如何解決這些問題的呢：

1、將資料日誌進行切割（按照業務打包日誌）併合理命名。比如A登陸日誌，B充值日誌，C消費日誌。分門別類進行打包後，對資料每5分鐘切割1次，並生成md5包。

2、按照劃分IDCRegion。原來從本機向外傳輸資料會佔用大量頻寬，對於本身CPU的消耗大的話都會影響遊戲的執行。現在按照IDCregion做出劃分，每個區域中會有1-3箇中心儲存伺服器。將切割下來的資料放到中心儲存上，劃分成Aip1、Aip2、Aip3等md5壓縮包，此處無需做合併（原因見3）。

3、建立下載任務。建立好任務列表後，對每5分鐘的壓縮包進行下載。考慮到如果上面的步驟做了合併的話就可能會產生在傳輸的時候丟資料卻無法確定的情況，因此2步驟無需對資料進行合併。

4、將下載後的任務加到Hive資料倉庫裡。將當天的資料放到MySQL中，之前的資料放到Hive裡。當運營提出資料需求時便可以到Hive中下載資料。即使資料出現錯誤，按照上面建立的每5分鐘的任務列表也可以重新以規定時間點將資料壓縮包重新拉回來。並且該流程可以按照正向、反向雙向進行。

採用5分鐘壓縮包的另外一個原因在於每臺伺服器每天產生業務日誌大概有5-6G的資料，分到5分鐘後，切割完每個檔案就是20M－30M，壓縮後只佔用很少的空間。這樣就解決了佔用大量頻寬的問題。

5、資料傳輸後需將資料放到資料倉庫（DW）中，資料下載完畢後會根據檔案進行儲存，當天的資料按照5分鐘1個壓縮包進入MySQL，MySQL則進入當天的查詢。在資料倉庫中，資料包按遊戲及平臺進行分類，這種格局的安排為了在併發時更好的執行。由於遊戲與遊戲之間是隔離的，因此按照這種模式是為了保證資料進行順利併發。

三、遊戲應用運維工程師的工作現狀

1、對待需求：

有的響應需求，處理的很好，但，不懂得加入自己的思想和總結，每天積極的響應，但，長此以往，一直是積極的響應，像一部長期運轉的機器……

有的響應需求，但在處理的基礎上，分析需求，優化需求，儘可能的提升後期處理類似的效率；對於不合理的需求，儘快溝通、協調，當然，這是在充分了解遊戲的基礎上，可以知道需求可以對專案、對運營帶來什麼樣的影響和作用。

2、對待遊戲接入：

有的是要求什麼做什麼，哪怕之前有遊戲運維的經驗，也不太去考慮，前期的接入遺留的詬病，勢必影響後期的運營

有的分析之前的遊戲所有可能出現的風險、對待架構慎之又慎，儘可能規避所有後期可能遇到的短板。

3、對待遊戲上線維護：

有的只是堅持著、做著，~~~

有的用周邊可能用到的一切工具或者資源，去分析所有可能存在優化的地方

4、對待部門流程和建議：

有的不太主動思考，因此總結不多，即使有，也隨著隨之而來的需求、工作瞬間夭折而去~~~

有的儘可能多的去整理合理化建議、共享自己的所有的心得和總結，是交流，也是傳承……

5、還有很多類似的點，但，總歸一點，就是是否主動

是否主動思考、是否主動總結、是否主動優化、是否主動分享，是否有主動的心，決定一個 遊戲運維人員在做什麼和他可能提升的高度

四、遊戲應用運維工程師的技能和素質要求？

會寫指令碼、會遊戲的釋出等操作、可以應付一些突發故障的處理、熟練操作linux就是一名合格的遊戲應用運維工程師麼？嗯，算，算是入門了吧

那麼我們來看看一名遊戲應用運維工程師的技能和素質要求吧

讓我們開啟你喜歡的任何一款搜尋引擎，去搜索：“遊戲 + 運維工程師 ” 去看看目前主流的遊戲公司對這方面同學的要求吧，簡單羅列一個，如下:

a、本科以上學歷；

b、有一年以上伺服器運維經驗；

c、熟悉linux/UNIX等作業系統，有2年以上linux平臺操作經驗；

d、熟悉Shell程式設計，熟悉Perl/Python者優先；

e、熟悉主流資料庫(Mysql/Oracle)；

f、高度的責任心、良好的溝通技巧和團隊合作精神，正直進取，有上進心；

g、擁有網路遊戲運維經驗者優先。

1、技能要求:每條後面都會跟一些註解

如果你翻一下大部分的搜尋結果，其實答案已經明瞭:

A、有運維經驗

培養一名真正的運維工程師相對付出的成本是相對較大的，因為，他說來說去是一個複合型職業，雖然D/O分離弱化了一部分比如開發相關的要求，但，網路、系統、指令碼程式設計、資料庫、遊戲架構方面的知識等等都需要較多的積累和學習，否則，開始相對較為吃力

B、熟悉或者熟練 Linux/Unix等作業系統，並有比較久的操作經驗

系統級的越熟練越有用，當然，基本的命令是必須的

C、熟悉任何一種指令碼程式語言

基本上來說，shell程式設計基本要精通最好

D、主流資料庫，比如Mysql、Oracle等至少要熟悉

也就是說，應用要至少沒有問題，當然，優化等可以進行更好了，一些問題定位和處理、最基本的統計、優化建議等等都需要這些。

E、較豐富的安全、網路知識

很多時候，需要依靠這些知識去定位和解決問題

2、素質要求

A、主動性、積極、樂觀

為什麼要把這個排在第一位呢，其實，這個是運維效率提升的根本和對內外部滿意度提升最有效果的一個素質，也是前面提到現狀裡運維人員出現差異和不同的決定因素；

優化和效率提升需要主動性和積極的驅動；

問題的解決需要主動性；

溝通需要主動性和樂觀的驅使；

……

B、較強的溝通協調能力

遊戲應用運維工程師面對的介面可能多達十幾個:安全組、網路組、DBA（如果有單獨設立的話）、運營、策劃、研發、周邊開發（運營分析系統、應對客服使用的受理系統、周邊分析平臺）等等，看著這些羅列，就應該不難想象，如果沒有較強的溝通和協調能力，遊戲應用運維工程師的工作將是非常被動和狼狽的。

C、能熬夜….（似乎當你真正投入到工作上，無論是開發、策劃、運維、或者其他任何職位，不能熬夜的話，估計都是個杯具）

這個嘛，因為遊戲的釋出多半會選擇在線上最低的晚上、凌晨、或者早上，所以，熬夜是必不可少的經歷之一了，當然，陪著他們的還可能有測試、運營等；偶爾，半夜被叫起來定位問題，也是不可避免的。

D、絕對強的抗壓性與必須的細心、細緻和一絲不苟

經過上面種種的介紹，或許已經可以預料到，無論是運營、客服，還是研發，任何問題必須經過的一環便是遊戲應用運維了，在高壓的狀態下，如何保持清醒的頭腦和邏輯分析以及合理安排時間，顯得極為重要，更重要的是，需要有在這種高壓下持續作戰的能力；當一切阻礙被慢慢改進、優化或者消除掉的時候，壓力自然會就會少了。成長，也會伴隨著這種壓力自始至終……

當然，還有一點，他們是admin/root權利的擁有者，他們的一個操作可能使一切天翻地覆，任何的操作可能都需要細心的護航。

E、正直為先

遊戲內資料的敏感性大家都已經很清楚；

他們的一絲邪念，修改資料以獲取暴利，或許就會毀掉一個人的一生（遊戲業裡因為這個被開掉或者被訴諸法律的也應該有過先例了吧）

但，這種做法和偷竊、搶劫毫無區別，當然，可以通過種種手段去限制和把控，但，防，只是手段而已。所以，正直，必須的條件之一，也是比較隱晦的條件…

F、較強的總結、創新能力

一切為了儘可能的提高運營力：質量和效率永遠是運營支撐追求的目標。

G、前瞻性

每款遊戲都有它的生命週期和發展走向

一切都需要時刻去想著:它會如何？後面該怎麼做？目前的這種狀態會保持多久？目前的支撐運營能力夠不夠？是否有優化點？如此種種~~~

H、一顆優化的心（優化和主動，已經是反覆強調的東西了）

無論是針對產品本身支撐層面的優化，還是針對整個部門平臺或者公共元件的優化（當然，公共的東西，更多的是需要 建議和優化思路）

當然，優化不是一時腦熱，也不是豪放和粗狂，是點點滴滴的積累和每日的總結與凝聚的合力。

五、遊戲運維職業的迷惘與發展前景

迷惘和職業現狀：

遊戲運維工程師經過幾年的發展，逐漸已經成為遊戲上線、運營不可或缺的主要組成部分，並對遊戲運營產生比較大的影響和作用。但，目前大部分人對遊戲運維的職業仍然會帶給人不少迷惘，因為它不像其他諸如遊戲研發、遊戲策劃、遊戲美工等職位有非常明確的職業定位和比較明確的職業規劃、沒有這些職位有較強的職業認同感和成就感。

1、這個職業尚年輕，很多公司還處於成長和摸索階段，由於起工作特性，可能很多小的公司D/O分離甚至都沒有完全，很多公司的遊戲運維工程師還在做著類似機房機器的上架、硬體級的維護等兼職工作。

2、自動化管理還未普及和完備，讓這個工作的重複工作相對很大。

3、體系化的理念和技術還在建設和摸索

發展前景：

1、中國網遊潛力依然巨大、各遊戲公司對有經驗的遊戲運維工程師的需求量依然會很大

2、運維工程師技術含量及要求會越來越高，同時也是對公司應用、架構最瞭解最熟悉的人、越來越得到重視

3、遊戲運維是一個融合網路、系統、開發、安全、架構、儲存等的綜合性技術崗位，給大家提供一個很好的個人能力與技術廣度的發展空間

4、運維工作的相關經驗將會變得非常重要，而且也將成為個人的核心競爭力，具備很好的架構知識、各層面問題的解決能力及方案提供、全域性思考能力等

5、如果真要以後不想做運維了，轉到其它崗位也比較容易，因為你所做的就是遊戲運營，你所接觸的，都是遊戲運營的各類角色。這一切依賴你的經驗和用心程度。

6、技術發展方向：遊戲系統架構師、遊戲運維專家

文章來自微信公眾號： 馬哥Linux運維