遊戲運維的最佳實踐：搜狐暢遊自動化運維之旅！

搜狐黎志剛見證了暢遊遊戲自動化運維平臺的從無到有，經過在其中踩過的坑、解過的結，他向你們來闡述遊戲運維的進階之路。本文主要圍繞暢遊遊戲管理體系與運維自動化的演變歷程、運維自動化的實現及將來運維四方面展開。

暢遊運維管理體系與運維自動化的演變歷程

暢遊運維管理體系演變歷程

從 2008 年畢業以實習生的身份進入搜狐暢遊，我同公司一塊兒成長，經歷了整個運維管理體系從小到大的過程。

整個運維管理體系是從最初石器時代（腳本化），以後的青銅時代（半自動化）、蒸汽時代（DevOPS）一路演變過來，如今處於自動化和智能化過渡階段。

暢遊運維自動化演變歷程

以下圖，是暢遊運維自動化的步驟，分別是數據總線統1、業務自動化、標準化統1、服務驅動和智能運維。

對於已發生故障進行分析發現，40% 的故障由數據不許確致使。出現這樣狀況，是由於自產信息或不少系統之間交互信息帶來的問題。

因此首要作的是數據的系統、準確性、調用及引用接口的統一。以後對數據和文件分發研發了一系列平臺，還有各個平臺標準化的統一。

以下圖，是暢遊運維體系架構：

最底層採用的是混合雲的模式，在這基礎上，又建設了多個如海豹、集中配置管理、管理和服務相關的支撐系統，還有最重要的天使和監控告警系統。

天使系統的主要職責就是權限管理，暢遊各運維人員所負責的遊戲各有不一樣，因爲遊戲版本的特殊性，一旦泄露，會對整個遊戲的營收形成很大影響。

因此，要嚴格管理每一個工程師的權限。監控警報系統之因此重要，是由於涉及到全部遊戲玩家的體驗和收入。

暢遊遊戲運維自動化實現

遊戲運維的特色和痛點

面對這樣的運維體系架構，暢遊都在哪些部分作了自動化呢？咱們先來看看遊戲運維有哪些特色和痛點。

每一個遊戲的構架和應用場景，乃至於所使用的數據庫和開發語言徹底不一樣。還有不一樣國籍開發的遊戲，整個操做系統和數據庫環境、版本都存在大量的不一樣點。這樣一來，運維整個平臺和環境都要面臨很大挑戰。

遊戲運維的痛點有不少，如：

● 運維腳本及工具零散、數量多、難複用。

● 資源需求彈性大。

● 成本、效率與可用性的平衡。

● 大流量的高併發。

● 故障須要實時處理且儘快恢復。

● 多版本管理。

爲克服這些痛點，近四五年，暢遊運維作了不少事情，業務和工程師人數等方面都有變化。

從 2014 年到 2016 年，業務每一年實現 20% 的增加，全職工程師在不斷的減小，這是由於 2014 年到如今，咱們作了大量的自動化工具，利用自動化平臺和資源整合，每一年資源成本減小 30%。

2016 年 CMDB 海豹系統上線，對全部在線資源進行整合，公共集羣建設的完成，把單遊戲和每一組遊戲所需公共服務放在一塊兒，使得資源成本減小 50%。

這裏值得一提的有趣現象是 2014 年到 2015 年的人爲故障數量基本持平，這是自動化帶來的反作用，2016 年人爲故障降低了 30%，此時自動化的做用開始發揮出來了。

2014 年到 2015 年的全局故障率（網絡故障、硬件故障等全部的故障）減小了 20%，2016 年故障率降低了 35%。

咱們爲何能夠在業務增加的狀況下，依然能夠作到故障降低和成本節約？

分析緣由以下：

● 40% 的人爲故障是因爲信息不許確或是人爲操做失誤致使的。

● 30% 的人爲故障是因爲跳流程操做和研發的溝通壁壘。

● 50% 以上的成原本自於空閒資源和故障資源，以及服務器性能資源未能充分使用。

針對這些緣由，暢遊運維作了不少事情，下面主要分享如何經過海豹系統作信息的統一化和標準化、PaaS 平臺實現 Devops 自動化交付以及 Docker 容器技術和混合雲架構等內容。

遊戲運維自動化平臺的技術及邏輯架構

對於遊戲運維自動化平臺應用來講，是既定的計劃，能夠當作任務來執行，全部開服、關服、更新、數據回檔及檔案恢復等全部操做均可以定義成任務或工做流，以後把全部的設計所有按照任務系統的架構來設計便可。

在平臺設計過程當中，系統主要使用 Python 來進行開發。由於從 2015 年開始，咱們發現，若是所有用 Java 來開發的話，運維人員的參與度會很是低。

假設運維人員對 Java 不瞭解，運維和開發之間需求溝通就不暢。這裏的解決方案就是一線運維人員必需要懂 Python，並且要參與到開發過程當中。

以下圖，是自動化運維任務的系統架構：

自動化運維任務系統是結合開源技術與公司現有資源的運維的基礎操做平臺。不只支持腳本執行、定時任務等基礎運維場景外，還提供了流程式開發框架，使運維人員能開發本身須要的業務維護功能。

海豹系統（CMDB）

海豹系統承載暢遊硬件層、應用層和網絡層等運維層全部信息的記錄，如設備、配置、關聯權限、關聯拓撲、關聯環境、關聯流程等。基於這些信息，以應用爲核心，經過業務場景進行驅動。

以下圖，是海豹系統（CMDB）的功能架構：

整個功能架構從下至上分爲數據來源、數據層和應用層部分。用以管理系統中心的服務器及相關的軟硬件資產信息，是全部系統資產信息的來源。數據層對全部資產進行查詢、變動及管理，經過統計報表模塊圖展現資產的狀況。

以下圖，是海豹系統（CMDB）的功能架構和技術架構：

這是海報系統的最初時期，由不足五人用 Java 寫的核心架構。引擎部分，之因此還在用 JSP 和 Freemarker 引擎，是爲了兼顧老的系統。

以下圖，是海豹系統（CMDB）的界面：

全部的端遊、手遊的信息會集中到海報系統，意味着資產管理專員能夠經過這個平臺作全部資源初始化和分配調度。

PAAS平臺

經過業務邏輯把各個資源統籌起來，資源所見即所得，更容易的實現了持續集成，經過各項基礎服務的組合，實現代碼自動化發佈、應用管理、環境初始化部署、線上運維一體化集成，提高項目代碼編譯、測試、發佈效率。

PAAS 平臺主要職責以下：

提供一致性環境保障。

● 提供應用多租戶隔離以及資源的多租戶隔離。

● 提供服務發現、可彈性伸縮、狀態管理、資源分配、動態調度等能力。

● 支持預發佈、一鍵發佈、一鍵回滾以及自動化部署。

● 提供透明化的監控、容災能力。

● 提供運維、開發、測試多角度業務場景。

以下圖，是 PAAS 平臺的主要技術選型：

從上圖能夠看出，PAAS 平臺裏也包含外部組件，Docker 也包含其中。由於遊戲公司大量代碼基本都放到 SVN，因此咱們也會選在 SVN 來管理。

Docker 容器技術

PAAS 平臺的設計中，核心部分是 Docker。那搜狐暢遊的 Docker 是如何設計的呢？

以下，是原 Docker 架構圖：

以下，是最終版的 Docker 架構圖：

從 2014 年至今，咱們已經迭代過兩個版本，搜狐暢遊在容器監控數據共享、穩定性和鏡像管理等方面進行了優化。

以下圖，是技術演化對比：

因 Ceph 副本之間不穩定，不支持集羣共享，因此改爲 NFS+DRBD。因 Consul 集羣 Leader 切換頻繁，業務數據不一樣步，負載太高，改爲 Etcd，來保證數據同步統一。

爲應對 cAdvisor 沒法彙總，沒法查看歷史數據的問題，咱們自研了 Hunter。操做系統從 2.6 升級到 3.18，應對運行久了後 devicemapper 的信息沒法寫入致使系統異常的問題。

混合雲結構

暢遊運維體系最底層採用的是混合雲結構，開始考慮的方式是直接接入全部公有云，用專業的方式打通，但遊戲須要 BGP（網關協議）。

這意味着必須多線接入，除電信、聯通外，全部的小區寬帶，第三方寬帶也必需要接入，因此須要選擇混合雲的結構。

選擇混合雲相比暢遊 IDC 下降成本在 20% 左右，而且使資源彈性，雲上雲下，擴縮容更快速。在可靠性方面，不只可實現異地雙活，還有抗***、DNS 劫持、冗餘可靠等優點。

暢遊運維管理體系的下一步探索

暢遊運維管理體系的下一步將把持續交付的分層能力和公共服務標準化做爲探索方向。

持續交付的分層能力

在暢遊運維作自動化時，會利用可持續交付的理念和原則去作。工具開發過程當中，必定要注意的問題是：工具越多，工具與工具之間的調用就會出現大量的問題。

因此必定要進行平臺化和作成集羣式服務，不然成本不會下降，反而故障依舊會不少。

公共服務標準化

以下圖，是公共服務平臺整合架構：

暢遊把 redis、Nginx、MySQL 等集羣所有接入，不須要作其餘的事情。

寫在最後

暢遊運維作整個自動化過程當中的心得有三個：

● 簡單有效，不要作特別花哨，由於對應用最實際纔是有用的，對應用或開發人員來講，最有效及效率最高是最好的。

● 符合實際業務，不是脫離研發和應用。

● 高效，遊戲特性決定必須高效，快上快下，快速決策。

以上內容根據黎志剛老師在 DevOps 與持續交付專場的演講內容整理。若有投稿、尋求報道意向技術人請聯絡 wangxy@51cto.com

遊戲行業近十年技術管理經驗。2008 年加入暢遊天下，現任系統運維中心總監及項目管理部經理、打造百萬用戶在線遊戲技術運維平臺。   近年來，致力於建設一流的遊戲技術團隊，負責全面管理運維工做，包括   IDC/網絡/硬件規劃管理、系統運維、數據庫運維、應用運維、運維平臺與工具開發等；創建和完善規範化的運維體系，保障運維質量；   不斷研發與探索運維自動化及各種創新途徑，縮短運維響應時間，減低運維成本。