編者按：
一直以來，中國網游在世界上都處于舉足輕重的地位。從最早的端游到頁游再到手游，不僅市場用戶 爆發式增長，近15年來網游技術的發展也是無比迅速。和單機游戲不同，網游除了游戲制作本身以外還牽涉到服務器端，再好的游戲如果出現鏈接、延遲等問題時 也會造成巨大損失，這時候游戲運維便發揮了舉足輕重的作用。中國網游的發展史，其實也是游戲運維的變革史，今天便由經典武俠手游《大掌門》運維掌門人吳啟 超來向我們講述，進入游戲領域10余年來的風風雨雨。
有服務器的地方就有運維
如今我們說到游戲，可能想到的是火爆異常的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%。成 本巨大虧空，急需技術轉型，這個時間點上出現了兩種概念影響了以后的手游以及云的發展。
1. 虛擬化技術
在2010年11月份左右， kvm出現在RHEL6中，去掉了RHEL 5.X系列中集成的Xen。正是這一次虛擬化技術的轉型，而且當時市場的需要，在2011年-2012年掀起了一場私有云建設的風潮。在實踐過程中，優點 很多，但暴露的缺點也不少。在端游占主要市場的情況下，實踐過程中表現出來的不適尤其明顯。
a. 虛擬機時鐘不準
b. 虛擬機網卡，超負荷down、丟包
c. 多虛擬機間爭搶cpu、內存
d. 多虛擬機間的安全訪問，虛擬機與物理機間的安全管控
e. 對于關系型數據庫磁盤讀寫慢問題突出。
f. 等等
以上幾點隨著時間的推移有的已經然后解決，有的換上了代替方案。時至今日，端游在單純的虛擬云上部署仍是問題，但是隨著物理、虛掩混合云出現，這個局面應該可以被打破。
2. 社交化的頁游
社區化的頁游戲，為什么這樣說呢，因為當時更多的頁游信托社區入口，導入用戶流量，當時最火的 應該是人人網（校內網）的農場偷菜。然后是DZ論壇一堆農場插件襲卷全國，當然這一切都是為了增加用戶粘稠度。但是也影響了頁游技術的選型，當時基本上大 家不約而的選用了于社區相同的LAMP的技術，從而降低開發成本及接入成本。當然現使用JAVA SSH2架構的頁游也有。除技術選型外，同時還帶入了另一個概念：聯運。聯運這個概念在頁游時代對于端游運維就像一個惡夢，不同區服要隨時跨服站，不同區 服要隨時可以合區，所有數據不再是以物理服務器為單位，而是要逐條打標簽，再也看不到賬號，只能拿著一串長長的KEY，四處兌換，然后拿著不知道所謂的表 標問第三方…….
在這個時期，是運維開發的爆發年，隨著虛擬化技術的推廣，越來的越多的運維開始接觸自動化運維的概念，開始了自動化運維的奮斗之路，開始了以項目管理的角度看待運維腳本開發。
3，黃金時代：手游
隨著私有云轉為公有云、云時代推動著云計算以及移動互聯網的發展，網游行業慢慢進入了手游黃金時代，云時代的變革不僅挑戰了整個游戲行業，也挑戰了游戲運維。
3.1 手游的運維工種：系統型運維，業務型運維。
3.2 手游運維業務范圍：阿里云、 亞馬遜 、UCloud、 藍汛CDN、 聽云監控。
3.3 手游游戲服務器架構：一般來講都是以一組服務器集群為一個平臺單位，不同的集群提供不同的服務。
手游的架構理念是提供一組虛擬服務器，當短連接的時候，每開一組服，將玩家引導到Web集群， 隨后被分配到不同的MongoDB，數據緩存用在Redis。當***個服務器玩家請求DB時，會落到Mongo1上；當開第二個服的時候，還是將玩家引導 到Mongo1上；以此類推直到運維發現壓力累積到一定程度時，便會新開一組MongoDB，Web集群也是如此但只有性能不夠時才會添加，一般情況下， 每50個新服可能需要添加1個MongoDB。這便實現并解釋了當時在頁游里希望實現的快速開服方法。
到此為止我們已經回顧了一遍游戲運維從端游到頁游再到手游的演變過程，不難看出，手游對于區服 的架構概念不同于端游：端游認為一個物理集群是一個服，而手游認為一個Web請求落到相應的數據庫上就是一個服。這樣的好處是開服合服都簡單，如果前五十 組服務器需要合并，實現起來很容易，因為同一個DB的數據是互通的，所以只需發一個公告，服務器加標識即可，不需要進行物理操作也不需要數據遷移。
游戲運維***指南
說完了游戲運維的歷史，我們要開始今天的重頭戲，如何做好游戲運維？這里就用吳啟超的一個冷笑 話作為開始：運維為什么存在？a，有服務器；b，因為研發忙不過來。不管是笑沒笑，運維確實因為上面兩個原因才會誕生的。那么回到正題，想成為玩轉上千服 務器的游戲運維應該怎么樣做呢？系統部運維構建大致如下圖：
1，構建CMDB
21世紀什么最重要？信息最重要！運維所需信息要涉及：機房、物理服務器、虛擬機、交換機、網 絡、承載業務、業務配置、承載服務進程、端口等信息。不管是自己采購還是購買云服務，物理服務器和虛擬服務器都做為資產存在，在采購后錄入相關的資產管 理，給它打上標簽，屬于哪個游戲，哪個平臺，這樣不同游戲平臺間就不能混用服務器了。然后，是再給不同的服務器標識它承擔的業務角色，比如它是 MongoDB，我們需要打上的標簽會是大掌門-APPSTORE-MongoDB-主庫-90000端口-***組服務。這樣一個基礎信息錄入就完成了。
這樣的信息只要是用來將來批量化部署、管理服務器使用，以及當出現故障時，運維可以很方便的查詢相當的服務器以及服務信息。但是數據的及時性、準確性、可檢查是一個難點。
2，集中批量化管理
CMDB不是TXT文件，而是要變成EXE文件。運維在面臨大量服務器的情況下，批量化工具的 出現成為必須的結果，在日常的工作當中需要把其流程固化下來，為完成批量化安裝、管理打下基礎。大掌門喜歡使用 ssh sshpass paramiko libssh2這些基礎的技術做批量管理。原因是不用安裝簡單、穩定、安全、可控。當然吳啟超也表示推薦大家使用在市面上流程行puppet、 Ansible、SaltStack等技術，為什么？簡單、簡單、簡單！下圖就是在做自動化半自動化運維過程中的模型。
批量管理的難點在于：
a. 命令的并發執行，要控制各點的超時時間
b. 執行過程中，不同功能的不同權限要求
c. 數據通信安全的保證，以及能夠正常解析數據指令
d. 人員賬號權限管理，權限分發及回收
e. 物理服務器、云服務器統一化安裝及老項目改造
f. 網絡質量不可靠的情況下，執行不完整的情況下業務功能回滾。
3，性能與業務監控
應用性能監控
1、每天都會對服務器進行上線，升級等操作，每款游戲在一個平臺的集群數在幾十個到幾百個不等 （根據平臺大小）。因此每天維護和升級服務器壓力極大，服務器異常或響應慢等問題的發生會給用戶體驗帶來傷害。 這樣的隱患在于一旦發生游戲關服之后就必須對玩家進行游戲中貨幣和元寶的賠償，平均每個玩家補償的元寶至少在5元以上，游戲幣和各類游戲道具若干，以此類 推由于服務器故障造成的損失可想而知。
2、大掌門使用了聽云Server，能夠對服務器響應慢和不可用進行定位，查看慢應用追蹤和Web應用過程功能，能夠實時定位消耗資源***的代碼和語句，這樣就能幫助實時進行有針對性的調整和優化，并且可以快速定位問題時間，最快能到分鐘級別。
3、發生高并發、服務器壓力激增的情況時，平時運行正常的服務器異常概率大幅增加，日常可能的 性能瓶頸點會被成倍放大，這就需要實時定位和解決性能瓶頸點，和提前進行預防改善。一般來說，傳統日志收集方式耗時耗力，效果非常不好，大掌門用了聽云 Server后，可以進行1分鐘級定位能迅速有效發現瓶頸點。同時還結合了聽云Network的壓測功能，能夠在服務器上線前提前發現到高壓力下的瓶頸 點，提前預防，避免由于高并發出現的服務器瓶頸
4、還有一種性能情況需要提前預防，游戲公司盈利在于玩家的充值，對于官網上從登陸到充值全流 程的成功率業務部門極其關注，玩家點擊跳轉的失敗會直接導致充值付費用戶的轉化率。對此，大掌門通過聽云Network的事務流程功能能夠實時對事物流程 進行警報，幫助業務部門提升用戶充值的轉化率
業務監控
除了性能和硬件監控之外，對于游戲業務運轉是否正常也需要建立一套標準去評判。
對此，大掌門開發了一套適用于全公司所有的游戲的統一登陸、充值、交易平臺，解決了前端的 SDK接入的問題，一個所有游戲或第三方的API接口統一接入的平臺。在做業務型監控時，運維會要求后端開發人員寫一個特定賬號，在訪問現有系統時，會完 整的走一遍業務流，這樣就可以看到需要的業務數字。
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、 按照劃分IDC Region。原來從本機向外傳輸數據會占用大量帶寬，對于本身CPU的消耗大的話都會影響游戲的運行。現在按照IDC region做出劃分，每個區域中會有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則進入當天的查詢。在數據倉庫中，數據包按游戲及平臺進行分類，這種格局的安排為了在并發時更好的運 行。由于游戲與游戲之間是隔離的，因此按照這種模式是為了保證數據進行順利并發。
