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

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

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

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

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

暢遊運維自動化演變歷程

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

對於已發生故障進行分析發現，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 與持續交付專場的演講內容整理。如有投稿、尋求報道意向技術人請聯絡 [email protected]

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

本文出自 “12562290” 博客，請務必保留此出處http://12572290.blog.51cto.com/12562290/1950708

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