遊戲運維編年史：多是目前最詳細遊戲運維指南

文章出自：聽雲博客

編者按： 

       從端游到頁遊再到手遊，15年來中國網遊在世界上都有着舉足輕重的地位。可是再好的遊戲若是出現鏈接、延遲等問題時也會形成巨大損失，這時遊戲運維便發揮了舉足輕重的做用。中國網遊的發展史，其實也是遊戲運維的變革史，今天便由經典武俠手遊《大掌門》運維掌門人吳啓超來向咱們講述，進入遊戲領域10餘年來的風風雨雨。

有服務器的地方就有運維

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

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

       網絡聯機，意味着玩家須要登陸官方服務器，「有人的地方就有江湖」，這句話說的不只是網遊裏的恩怨情仇，還包括遊戲外的種種：「有服務器的地方就有運維。」這即是今天咱們要說的話題——遊戲運維。

遊戲運維編年史

石器時代：端遊

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

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

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

       系統運維：安裝各類軟件，調試各類不兼容的軟件，在各類版本的Linux、Windows上。

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

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

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

       運維開發：寫着各類的邏輯，由於業務、網絡環境、BUG、剛剛幫忙扛完服務器。

2.端遊運維業務範圍：在端遊時代，大部分遊戲公司都是自主作各類業務環境，作各類遊戲業務須要的各類環境。

       資產管理：服務器、交換機、各類服務分佈位置，端口等。

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

       靜態緩存服務器：squid + apache|nginx  

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

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

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

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

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

3.端遊遊戲服務器架構：通常來說都是以一組服務器集羣爲一個區服單位，單機上的進程提供不一樣的服務。

      

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

青銅時代：頁遊

       在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，四處兌換，而後拿着不知道所謂的表標問第三方…….

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

黃金時代：手遊

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

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

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

       3.手遊遊戲服務器架構：通常來說都是以一組服務器集羣爲一個平臺單位，不一樣的集羣提供不一樣的服務。

       

       手遊的架構理念是提供一組虛擬服務器，當短鏈接的時候，每開一組服，將玩家引導到Web集羣，隨後被分配到不一樣的MongoDB，數據緩存用在Redis。當第一個服務器玩家請求DB時，會落到Mongo1上；當開第二個服的時候，仍是將玩家引導到Mongo1上；以此類推直到運維發現壓力累積到必定程度時，便會新開一組MongoDB，Web集羣也是如此但只有性能不夠時纔會添加，通常狀況下，每50個新服可能須要添加1個MongoDB。這便實現並解釋了當時在頁遊裏但願實現的快速開服方法。

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

遊戲運維最強指南

       說完了遊戲運維的歷史，咱們要開始今天的重頭戲，如何作好遊戲運維？這裏就用吳啓超的一個冷笑話做爲開始：運維爲何存在？a，有服務器；b，由於研發忙不過來。無論是笑沒笑，運維確實由於上面兩個緣由纔會誕生的。那麼回到正題，想成爲玩轉上千服務器的遊戲運維應該怎麼樣作呢？系統部運維構建大體以下圖：

       

構建CMDB

       21世紀什麼最重要？信息最重要！運維所需信息要涉及：機房、物理服務器、虛擬機、交換機、網絡、承載業務、業務配置、承載服務進程、端口等信息。無論是本身採購仍是購買雲服務，物理服務器和虛擬服務器都作爲資產存在，在採購後錄入相關的資產管理，給它打上標籤，屬於哪一個遊戲，哪一個平臺，這樣不一樣遊戲平臺間就不能混用服務器了。而後，是再給不一樣的服務器標識它承擔的業務角色，好比它是MongoDB，咱們須要打上的標籤會是大掌門-APPSTORE-MongoDB-主庫-90000端口-第一組服務。這樣一個基礎信息錄入就完成了。

       這樣的信息只要是用來未來批量化部署、管理服務器使用，以及當出現故障時，運維能夠很方便的查詢至關的服務器以及服務信息。可是數據的及時性、準確性、可檢查是一個難點。

集中批量化管理

       CMDB不是TXT文件，而是要變成EXE文件。運維在面臨大量服務器的狀況下，批量化工具的出現成爲必須的結果，在平常的工做當中須要把其流程固化下來，爲完成批量化安裝、管理打下基礎。大掌門喜歡使用 ssh sshpass paramiko libssh2這些基礎的技術作批量管理。緣由是不用安裝簡單、穩定、安全、可控。固然吳啓超也表示推薦你們使用在市面上流程行puppet、Ansible、SaltStack等技術，爲何？簡單、簡單、簡單！下圖就是在作自動化半自動化運維過程當中的模型。 

       

批量管理的難點在於：

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

       b.執行過程當中，不一樣功能的不一樣權限要求

       c.數據通訊安全的保證，以及可以正常解析數據指令

       d.人員帳號權限管理，權限分發及回收

       e.物理服務器、雲服務器統一化安裝及老項目改造

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

性能與業務監控

• 應用性能監控

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

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

三、發生高併發、服務器壓力激增的狀況時，平時運行正常的服務器異常機率大幅增長，平常可能的性能瓶頸點會被成倍放大，這就須要實時定位和解決性能瓶頸點，和提早進行預防改善。通常來講，傳統日誌收集方式耗時耗力，效果很是很差，大掌門用了聽雲Server後，能夠進行1分鐘級定位能迅速有效發現瓶頸點。同時還結合了聽雲Network的壓測功能，可以在服務器上線前提早發現到高壓力下的瓶頸點，提早預防，避免因爲高併發出現的服務器瓶頸。 

四、還有一種性能狀況須要提早預防，遊戲公司盈利在於玩家的充值，對於官網上從登錄到充值全流程的成功率業務部門極其關注，玩家點擊跳轉的失敗會直接致使充值付費用戶的轉化率。對此，大掌門經過聽雲Network的事務流程功能可以實時對事物流程進行警報，幫助業務部門提高用戶充值的轉化率。

• 業務監控

       除了性能和硬件監控以外，對於遊戲業務運轉是否正常也須要創建一套標準去評判。

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

數據倉庫搭建

       

       上圖爲大掌門數據倉庫的結構圖，因爲數據倉庫搭建的話題比較大，只是簡單的從數據集市的角度來聊聊，DM指的是數據集市。因爲數據集市須要面對不一樣的人羣，所以在數據倉庫中須要創建不一樣的數據集市以面對各方的查詢需求，進而對數據按照業務類型進行分類。

       一、財務：關心月度充值數據

       二、商務：關心渠道結算數據

       三、運營：關心用戶登錄量、轉化率、留存率、平臺充值額

       四、產品：關心功能熱度、用戶體驗

       五、客服：關心全部數據及玩家眷性

       對於數據方面，運維的壓力來自於須要貫穿及掌握全部的數據，而且爲全部部門服務。簡單的如下圖的ETL爲例：

       

數據對於運維的痛點：

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

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

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

       四、數據ETL過程監控，若是出現數據丟失怎麼辦？

       五、數據採集怎麼樣儘量的保證併發的採集，縮短期。

       六、數據的出現丟失或錯誤，總體數據回滾。誰來保證？怎麼保證？

       七、大量數據下，覈對數據丟失狀況怎麼樣覈對？用什麼方法？

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

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

       二、按照劃分IDC Region。原來從本機向外傳輸數據會佔用大量帶寬，對於自己CPU的消耗大的話都會影響遊戲的運行。如今按照IDC region作出劃分，每一個區域中會有1-3箇中心存儲服務器。將切割下來的數據放到中心存儲上，劃分紅Aip一、Aip二、Aip3等md5壓縮包，此處無需作合併（緣由見3）。

       三、創建下載任務。創建好任務列表後，對每5分鐘的壓縮包進行下載。考慮到若是上面的步驟作了合併的話就可能會產生在傳輸的時候丟數據卻沒法肯定的狀況，所以2步驟無需對數據進行合併。

       四、將下載後的任務加到Hive數據倉庫裏。將當天的數據放到MySQL中，以前的數據放到Hive裏。當運營提出數據需求時即可以到Hive中下載數據。即便數據出現錯誤，按照上面創建的每5分鐘的任務列表也能夠從新以規定時間點將數據壓縮包從新拉回來。而且該流程能夠按照正向、反向雙向進行。

       採用5分鐘壓縮包的另一個緣由在於每臺服務器天天產生業務日誌大概有5-6G的數據，分到5分鐘後，切割完每一個文件就是20M－30M，壓縮後只佔用不多的空間。這樣就解決了佔用大量帶寬的問題。

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

 

關於聽雲

       國內最大的應用性能管理（APM）解決方案提供商，擁有聽雲App、聽雲Network、聽雲Server、聽雲Browser、聽雲Sys五條重要產品線。在真實用戶體驗視角下實現移動客戶端、服務端與網絡的性能監控與管理。

 

原文連接：http://blog.tingyun.com/web/article/detail/344