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

前不久育碧旗下大作《全境封鎖》上線時鬧出個小笑話：由于很多國內(nèi)玩家下載之前沒注意是網(wǎng)游，下意識的以為育碧的游戲肯定是單機，好不容易下完之后才發(fā)現(xiàn)玩不上，進而發(fā)生了不少的騷動。這不是***個發(fā)生這種情況的傳統(tǒng)游戲廠商，肯定也不是***一個，很多有名的游戲公司都在做類似的嘗試，Popcap的《植物大戰(zhàn)僵尸：花園戰(zhàn)爭》系列，暴雪的《暗黑3》等，甚至那些還有單機成分的大作也早就開始網(wǎng)絡(luò)化：大名鼎鼎的《GTA5》、FPS風向標《使命召喚》系列和《戰(zhàn)地》系列，網(wǎng)絡(luò)聯(lián)機部分的比重也在一年一年的增加。

網(wǎng)絡(luò)聯(lián)機，意味著玩家需要登錄官方服務器，“有人的地方就有江湖”，這句話說的不僅是網(wǎng)游里的恩怨情仇，還包括游戲外的種種：“有服務器的地方就有運維。”這便是今天我們要說的話題——游戲運維。

游戲運維編年史

石器時代：端游

想要了解如今的游戲運維，不得不從早期的端游運維開始說起。對于08年入行端游，11年經(jīng)歷過頁游***14年全面接觸手游的吳啟超來說，這幾年的游戲運維經(jīng)歷讓他深切感受到運維思路的巨大轉(zhuǎn)變。

1.端游的運維工種：IDC運維、系統(tǒng)型運維、網(wǎng)絡(luò)運維、業(yè)務型運維、運維值班等。各個工種分工各有側(cè)重。

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

系統(tǒng)運維：安裝各種軟件，調(diào)試各種不兼容的軟件，在各種版本的Linux、Windows上。

網(wǎng)絡(luò)運維：二層交換、三層交換、四層交換，還要區(qū)分華為、思科。

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

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

運維開發(fā)：寫著各種的邏輯，因為業(yè)務、網(wǎng)絡(luò)環(huán)境、BUG、剛剛幫忙扛完服務器。

2.端游運維業(yè)務范圍：在端游時代，大部分游戲公司都是自主做各種業(yè)務環(huán)境，做各種游戲業(yè)務需要的各種環(huán)境。

資產(chǎn)管理：服務器、交換機、各種服務分布位置，端口等。

下載服務器：搭建BT集群，做種子、分發(fā)，供玩家下載游戲客戶端使用。

靜態(tài)緩存服務器：squid + apache|nginx  

郵件服務器：postfix +sasl +ssl 收發(fā)服務、反垃圾郵件服務。

網(wǎng)絡(luò)質(zhì)量監(jiān)控：somkingping各個機房的交換，各個安放點服務器。

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

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

監(jiān)控管理：nagios、catcai 然后是c|perl|python|shell +rrdtool各種業(yè)務監(jiān)控圖。

3.端游游戲服務器架構(gòu)：一般來講都是以一組服務器集群為一個區(qū)服單位，單機上的進程提供不同的服務。

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

青銅時代：頁游

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

1.虛擬化技術(shù)

在2010年11月份左右， kvm出現(xiàn)在RHEL6中，去掉了RHEL 5.X系列中集成的Xen。正是這一次虛擬化技術(shù)的轉(zhuǎn)型，而且當時市場的需要，在2011年-2012年掀起了一場私有云建設(shè)的風潮。在實踐過程中，優(yōu)點很多，但暴露的缺點也不少。在端游占主要市場的情況下，實踐過程中表現(xiàn)出來的不適尤其明顯。

a.虛擬機時鐘不準

b.虛擬機網(wǎng)卡，超負荷down、丟包

c.多虛擬機間爭搶cpu、內(nèi)存

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

e.對于關(guān)系型數(shù)據(jù)庫磁盤讀寫慢問題突出。

f.等等

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

2.社交化的頁游

社區(qū)化的頁游戲，為什么這樣說呢，因為當時更多的頁游信托社區(qū)入口，導入用戶流量，當時最火的應該是人人網(wǎng)（校內(nèi)網(wǎng)）的農(nóng)場偷菜。然后是DZ論壇一堆農(nóng)場插件襲卷全國，當然這一切都是為了增加用戶粘稠度。但是也影響了頁游技術(shù)的選型，當時基本上大家不約而的選用了于社區(qū)相同的LAMP的技術(shù)，從而降低開發(fā)成本及接入成本。當然現(xiàn)使用JAVA SSH2架構(gòu)的頁游也有。除技術(shù)選型外，同時還帶入了另一個概念：聯(lián)運。聯(lián)運這個概念在頁游時代對于端游運維就像一個惡夢，不同區(qū)服要隨時跨服站，不同區(qū)服要隨時可以合區(qū)，所有數(shù)據(jù)不再是以物理服務器為單位，而是要逐條打標簽，再也看不到賬號，只能拿著一串長長的KEY，四處兌換，然后拿著不知道所謂的表標問第三方…….

在這個時期，是運維開發(fā)的爆發(fā)年，隨著虛擬化技術(shù)的推廣，越來的越多的運維開始接觸自動化運維的概念，開始了自動化運維的奮斗之路，開始了以項目管理的角度看待運維腳本開發(fā)。

黃金時代：手游

隨著私有云轉(zhuǎn)為公有云、云時代推動著云計算以及移動互聯(lián)網(wǎng)的發(fā)展，網(wǎng)游行業(yè)慢慢進入了手游黃金時代，云時代的變革不僅挑戰(zhàn)了整個游戲行業(yè)，也挑戰(zhàn)了游戲運維。

1.手游的運維工種：系統(tǒng)型運維，業(yè)務型運維。

2.手游運維業(yè)務范圍：阿里云、 亞馬遜 、UCloud、 藍汛CDN、 聽云監(jiān)控。

3.手游游戲服務器架構(gòu)：一般來講都是以一組服務器集群為一個平臺單位，不同的集群提供不同的服務。

手游的架構(gòu)理念是提供一組虛擬服務器，當短連接的時候，每開一組服，將玩家引導到Web集群，隨后被分配到不同的MongoDB，數(shù)據(jù)緩存用在Redis。當***個服務器玩家請求DB時，會落到Mongo1上；當開第二個服的時候，還是將玩家引導到Mongo1上；以此類推直到運維發(fā)現(xiàn)壓力累積到一定程度時，便會新開一組MongoDB，Web集群也是如此但只有性能不夠時才會添加，一般情況下，每50個新服可能需要添加1個MongoDB。這便實現(xiàn)并解釋了當時在頁游里希望實現(xiàn)的快速開服方法。

到此為止我們已經(jīng)回顧了一遍游戲運維從端游到頁游再到手游的演變過程，不難看出，手游對于區(qū)服的架構(gòu)概念不同于端游：端游認為一個物理集群是一個服，而手游認為一個Web請求落到相應的數(shù)據(jù)庫上就是一個服。這樣的好處是開服合服都簡單，如果前五十組服務器需要合并，實現(xiàn)起來很容易，因為同一個DB的數(shù)據(jù)是互通的，所以只需發(fā)一個公告，服務器加標識即可，不需要進行物理操作也不需要數(shù)據(jù)遷移。

游戲運維***指南

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

構(gòu)建CMDB

21世紀什么最重要？信息最重要！運維所需信息要涉及：機房、物理服務器、虛擬機、交換機、網(wǎng)絡(luò)、承載業(yè)務、業(yè)務配置、承載服務進程、端口等信息。不管是自己采購還是購買云服務，物理服務器和虛擬服務器都做為資產(chǎn)存在，在采購后錄入相關(guān)的資產(chǎn)管理，給它打上標簽，屬于哪個游戲，哪個平臺，這樣不同游戲平臺間就不能混用服務器了。然后，是再給不同的服務器標識它承擔的業(yè)務角色，比如它是MongoDB，我們需要打上的標簽會是大掌門-APPSTORE-MongoDB-主庫-90000端口-***組服務。這樣一個基礎(chǔ)信息錄入就完成了。

這樣的信息只要是用來將來批量化部署、管理服務器使用，以及當出現(xiàn)故障時，運維可以很方便的查詢相當?shù)姆掌饕约胺招畔?。但是?shù)據(jù)的及時性、準確性、可檢查是一個難點。

集中批量化管理

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

批量管理的難點在于：

a.命令的并發(fā)執(zhí)行，要控制各點的超時時間

b.執(zhí)行過程中，不同功能的不同權(quán)限要求

c.數(shù)據(jù)通信安全的保證，以及能夠正常解析數(shù)據(jù)指令

d.人員賬號權(quán)限管理，權(quán)限分發(fā)及回收

e.物理服務器、云服務器統(tǒng)一化安裝及老項目改造

f.網(wǎng)絡(luò)質(zhì)量不可靠的情況下，執(zhí)行不完整的情況下業(yè)務功能回滾。

性能與業(yè)務監(jiān)控

• 應用性能監(jiān)控

1、每天都會對服務器進行上線，升級等操作，每款游戲在一個平臺的集群數(shù)在幾十個到幾百個不等（根據(jù)平臺大?。?。因此每天維護和升級服務器壓力極大，服務器異常或響應慢等問題的發(fā)生會給用戶體驗帶來傷害。 這樣的隱患在于一旦發(fā)生游戲關(guān)服之后就必須對玩家進行游戲中貨幣和元寶的賠償，平均每個玩家補償?shù)脑獙氈辽僭?元以上，游戲幣和各類游戲道具若干，以此類推由于服務器故障造成的損失可想而知。

2、大掌門使用了聽云Server，能夠?qū)Ψ掌黜憫筒豢捎眠M行定位，查看慢應用追蹤和Web應用過程功能，能夠?qū)崟r定位消耗資源***的代碼和語句，這樣就能幫助實時進行有針對性的調(diào)整和優(yōu)化，并且可以快速定位問題時間，最快能到分鐘級別。

3、發(fā)生高并發(fā)、服務器壓力激增的情況時，平時運行正常的服務器異常概率大幅增加，日?？赡艿男阅芷款i點會被成倍放大，這就需要實時定位和解決性能瓶頸點，和提前進行預防改善。一般來說，傳統(tǒng)日志收集方式耗時耗力，效果非常不好，大掌門用了聽云Server后，可以進行1分鐘級定位能迅速有效發(fā)現(xiàn)瓶頸點。同時還結(jié)合了聽云Network的壓測功能，能夠在服務器上線前提前發(fā)現(xiàn)到高壓力下的瓶頸點，提前預防，避免由于高并發(fā)出現(xiàn)的服務器瓶頸。 

4、還有一種性能情況需要提前預防，游戲公司盈利在于玩家的充值，對于官網(wǎng)上從登陸到充值全流程的成功率業(yè)務部門極其關(guān)注，玩家點擊跳轉(zhuǎn)的失敗會直接導致充值付費用戶的轉(zhuǎn)化率。對此，大掌門通過聽云Network的事務流程功能能夠?qū)崟r對事物流程進行警報，幫助業(yè)務部門提升用戶充值的轉(zhuǎn)化率。

• 業(yè)務監(jiān)控

除了性能和硬件監(jiān)控之外，對于游戲業(yè)務運轉(zhuǎn)是否正常也需要建立一套標準去評判。

對此，大掌門開發(fā)了一套適用于全公司所有的游戲的統(tǒng)一登陸、充值、交易平臺，解決了前端的SDK接入的問題，一個所有游戲或第三方的API接口統(tǒng)一接入的平臺。在做業(yè)務型監(jiān)控時，運維會要求后端開發(fā)人員寫一個特定賬號，在訪問現(xiàn)有系統(tǒng)時，會完整的走一遍業(yè)務流，這樣就可以看到需要的業(yè)務數(shù)字。

數(shù)據(jù)倉庫搭建

上圖為大掌門數(shù)據(jù)倉庫的結(jié)構(gòu)圖，由于數(shù)據(jù)倉庫搭建的話題比較大，只是簡單的從數(shù)據(jù)集市的角度來聊聊，DM指的是數(shù)據(jù)集市。由于數(shù)據(jù)集市需要面對不同的人群，因此在數(shù)據(jù)倉庫中需要建立不同的數(shù)據(jù)集市以面對各方的查詢需求，進而對數(shù)據(jù)按照業(yè)務類型進行分類。

1、財務：關(guān)心月度充值數(shù)據(jù)

2、商務：關(guān)心渠道結(jié)算數(shù)據(jù)

3、運營：關(guān)心用戶登陸量、轉(zhuǎn)化率、留存率、平臺充值額

4、產(chǎn)品：關(guān)心功能熱度、用戶體驗

5、客服：關(guān)心所有數(shù)據(jù)及玩家屬性

對于數(shù)據(jù)方面，運維的壓力來自于需要貫穿及掌握所有的數(shù)據(jù)，并且為所有部門服務。簡單的以下圖的ETL為例：

數(shù)據(jù)對于運維的痛點：

1、日志切割工作誰做？研發(fā)還是運維。日志切割按什么規(guī)則？大小還是日期？

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

3、數(shù)據(jù)的準確性誰來保證？日志內(nèi)容不對、切割不對、傳輸丟失、入hadoop過濾

4、數(shù)據(jù)ETL過程監(jiān)控，如果出現(xiàn)數(shù)據(jù)丟失怎么辦？

5、數(shù)據(jù)采集怎么樣盡可能的保證并發(fā)的采集，縮短時間。

6、數(shù)據(jù)的出現(xiàn)丟失或錯誤，整體數(shù)據(jù)回滾。誰來保證？怎么保證？

7、大量數(shù)據(jù)下，核對數(shù)據(jù)丟失情況怎么樣核對？用什么方法？

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

1、將數(shù)據(jù)日志進行切割（按照業(yè)務打包日志）并合理命名。比如A登陸日志，B充值日志，C消費日志。分門別類進行打包后，對數(shù)據(jù)每5分鐘切割1次，并生成md5包。

2、按照劃分IDC Region。原來從本機向外傳輸數(shù)據(jù)會占用大量帶寬，對于本身CPU的消耗大的話都會影響游戲的運行?，F(xiàn)在按照IDC region做出劃分，每個區(qū)域中會有1-3個中心存儲服務器。將切割下來的數(shù)據(jù)放到中心存儲上，劃分成Aip1、Aip2、Aip3等md5壓縮包，此處無需做合并（原因見3）。

3、建立下載任務。建立好任務列表后，對每5分鐘的壓縮包進行下載。考慮到如果上面的步驟做了合并的話就可能會產(chǎn)生在傳輸?shù)臅r候丟數(shù)據(jù)卻無法確定的情況，因此2步驟無需對數(shù)據(jù)進行合并。

4、將下載后的任務加到Hive數(shù)據(jù)倉庫里。將當天的數(shù)據(jù)放到MySQL中，之前的數(shù)據(jù)放到Hive里。當運營提出數(shù)據(jù)需求時便可以到Hive中下載數(shù)據(jù)。即使數(shù)據(jù)出現(xiàn)錯誤，按照上面建立的每5分鐘的任務列表也可以重新以規(guī)定時間點將數(shù)據(jù)壓縮包重新拉回來。并且該流程可以按照正向、反向雙向進行。

采用5分鐘壓縮包的另外一個原因在于每臺服務器每天產(chǎn)生業(yè)務日志大概有5-6G的數(shù)據(jù)，分到5分鐘后，切割完每個文件就是20M－30M，壓縮后只占用很少的空間。這樣就解決了占用大量帶寬的問題。

5、數(shù)據(jù)傳輸后需將數(shù)據(jù)放到數(shù)據(jù)倉庫（DW）中，數(shù)據(jù)下載完畢后會根據(jù)文件進行存儲，當天的數(shù)據(jù)按照5分鐘1個壓縮包進入MySQL，MySQL則進入當天的查詢。在數(shù)據(jù)倉庫中，數(shù)據(jù)包按游戲及平臺進行分類，這種格局的安排為了在并發(fā)時更好的運行。由于游戲與游戲之間是隔離的，因此按照這種模式是為了保證數(shù)據(jù)進行順利并發(fā)。

關(guān)于聽云

國內(nèi)***的應用性能管理（APM）解決方案提供商，擁有聽云App、聽云Network、聽云Server、聽云Browser、聽云Sys五條重要產(chǎn)品線。在真實用戶體驗視角下實現(xiàn)移動客戶端、服務端與網(wǎng)絡(luò)的性能監(jiān)控與管理。