【51CTO.com原創(chuàng)稿件】搜狐黎志剛見證了暢游游戲自動化運維平臺的從無到有，通過在其中踩過的坑、解過的結(jié)，他向大家來闡述游戲運維的進(jìn)階之路。本文主要圍繞暢游游戲管理體系與運維自動化的演變歷程、運維自動化的實現(xiàn)及未來運維四方面展開。

[[197934]]

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

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

從 2008 年畢業(yè)以實習(xí)生的身份進(jìn)入搜狐暢游，我同公司一起成長，經(jīng)歷了整個運維管理體系從小到大的過程。

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

暢游運維自動化演變歷程

如下圖，是暢游運維自動化的步驟，分別是數(shù)據(jù)總線統(tǒng)一、業(yè)務(wù)自動化、標(biāo)準(zhǔn)化統(tǒng)一、服務(wù)驅(qū)動和智能運維。

對于已發(fā)生故障進(jìn)行分析發(fā)現(xiàn)，40% 的故障由數(shù)據(jù)不準(zhǔn)確導(dǎo)致。出現(xiàn)這樣情況，是因為自產(chǎn)信息或很多系統(tǒng)之間交互信息帶來的問題。

所以首要做的是數(shù)據(jù)的系統(tǒng)、準(zhǔn)確性、調(diào)用及引用接口的統(tǒng)一。之后對數(shù)據(jù)和文件分發(fā)研發(fā)了一系列平臺，還有各個平臺標(biāo)準(zhǔn)化的統(tǒng)一。

如下圖，是暢游運維體系架構(gòu)：

最底層采用的是混合云的模式，在這基礎(chǔ)上，又建設(shè)了多個如海豹、集中配置管理、管理和服務(wù)相關(guān)的支撐系統(tǒng)，還有最重要的天使和監(jiān)控告警系統(tǒng)。

天使系統(tǒng)的主要職責(zé)就是權(quán)限管理，暢游各運維人員所負(fù)責(zé)的游戲各有不同，由于游戲版本的特殊性，一旦泄露，會對整個游戲的營收造成很大影響。

所以，要嚴(yán)格管理每個工程師的權(quán)限。監(jiān)控警報系統(tǒng)之所以重要，是因為涉及到所有游戲玩家的體驗和收入。

暢游游戲運維自動化實現(xiàn)

游戲運維的特點和痛點

面對這樣的運維體系架構(gòu)，暢游都在哪些部分做了自動化呢？我們先來看看游戲運維有哪些特點和痛點。

每個游戲的構(gòu)架和應(yīng)用場景，乃至于所使用的數(shù)據(jù)庫和開發(fā)語言完全不同。還有不同國籍開發(fā)的游戲，整個操作系統(tǒng)和數(shù)據(jù)庫環(huán)境、版本都存在大量的不同點。這樣一來，運維整個平臺和環(huán)境都要面臨很大挑戰(zhàn)。

游戲運維的痛點有很多，如：

• 運維腳本及工具零散、數(shù)量多、難復(fù)用。
• 資源需求彈性大。
• 成本、效率與可用性的平衡。
• 大流量的高并發(fā)。
• 故障需要實時處理且盡快恢復(fù)。
• 多版本管理。

為克服這些痛點，近四五年，暢游運維做了很多事情，業(yè)務(wù)和工程師人數(shù)等方面都有變化。

從 2014 年到 2016 年，業(yè)務(wù)每年實現(xiàn) 20% 的增長，全職工程師在不斷的減少，這是因為 2014 年到現(xiàn)在，我們做了大量的自動化工具，利用自動化平臺和資源整合，每年資源成本減少 30%。

2016 年 CMDB 海豹系統(tǒng)上線，對所有在線資源進(jìn)行整合，公共集群建設(shè)的完成，把單游戲和每一組游戲所需公共服務(wù)放在一起，使得資源成本減少 50%。

這里值得一提的有趣現(xiàn)象是 2014 年到 2015 年的人為故障數(shù)量基本持平，這是自動化帶來的副作用，2016 年人為故障下降了 30%，此時自動化的作用開始發(fā)揮出來了。

2014 年到 2015 年的全局故障率（網(wǎng)絡(luò)故障、硬件故障等所有的故障）減少了 20%，2016 年故障率下降了 35%。

我們?yōu)槭裁纯梢栽跇I(yè)務(wù)增長的情況下，依然可以做到故障下降和成本節(jié)約？

分析原因如下：

• 40% 的人為故障是由于信息不準(zhǔn)確或是人為操作失誤導(dǎo)致的。
• 30% 的人為故障是由于跳流程操作和研發(fā)的溝通壁壘。
• 50% 以上的成本來自于空閑資源和故障資源，以及服務(wù)器性能資源未能充分使用。

針對這些原因，暢游運維做了很多事情，下面主要分享如何通過海豹系統(tǒng)做信息的統(tǒng)一化和標(biāo)準(zhǔn)化、PaaS 平臺實現(xiàn) Devops 自動化交付以及 Docker 容器技術(shù)和混合云架構(gòu)等內(nèi)容。

游戲運維自動化平臺的技術(shù)及邏輯架構(gòu)

對于游戲運維自動化平臺應(yīng)用來說，是既定的計劃，可以當(dāng)做任務(wù)來執(zhí)行，所有開服、關(guān)服、更新、數(shù)據(jù)回檔及檔案恢復(fù)等所有操作都可以定義成任務(wù)或工作流，之后把所有的設(shè)計全部按照任務(wù)系統(tǒng)的架構(gòu)來設(shè)計即可。

在平臺設(shè)計過程中，系統(tǒng)主要使用 Python 來進(jìn)行開發(fā)。因為從 2015 年開始，我們發(fā)現(xiàn)，如果全部用 Java 來開發(fā)的話，運維人員的參與度會非常低。

假設(shè)運維人員對 Java 不了解，運維和開發(fā)之間需求溝通就不順暢。這里的解決方案就是一線運維人員必須要懂 Python，而且要參與到開發(fā)過程中。

如下圖，是自動化運維任務(wù)的系統(tǒng)架構(gòu)：

自動化運維任務(wù)系統(tǒng)是結(jié)合開源技術(shù)與公司現(xiàn)有資源的運維的基礎(chǔ)操作平臺。不僅支持腳本執(zhí)行、定時任務(wù)等基礎(chǔ)運維場景外，還提供了流程式開發(fā)框架，使運維人員能開發(fā)自己需要的業(yè)務(wù)維護(hù)功能。

海豹系統(tǒng)（CMDB）

海豹系統(tǒng)承載暢游硬件層、應(yīng)用層和網(wǎng)絡(luò)層等運維層所有信息的記錄，如設(shè)備、配置、關(guān)聯(lián)權(quán)限、關(guān)聯(lián)拓?fù)洹㈥P(guān)聯(lián)環(huán)境、關(guān)聯(lián)流程等?；谶@些信息，以應(yīng)用為核心，通過業(yè)務(wù)場景進(jìn)行驅(qū)動。

如下圖，是海豹系統(tǒng)（CMDB）的功能架構(gòu)：

整個功能架構(gòu)從下至上分為數(shù)據(jù)來源、數(shù)據(jù)層和應(yīng)用層部分。用以管理系統(tǒng)中心的服務(wù)器及相關(guān)的軟硬件資產(chǎn)信息，是所有系統(tǒng)資產(chǎn)信息的來源。數(shù)據(jù)層對所有資產(chǎn)進(jìn)行查詢、變更及管理，通過統(tǒng)計報表模塊圖展示資產(chǎn)的情況。

如下圖，是海豹系統(tǒng)（CMDB）的功能架構(gòu)和技術(shù)架構(gòu)：

這是海報系統(tǒng)的最初時期，由不足五人用 Java 寫的核心架構(gòu)。引擎部分，之所以還在用 JSP 和 Freemarker 引擎，是為了兼顧老的系統(tǒng)。

如下圖，是海豹系統(tǒng)（CMDB）的界面：

所有的端游、手游的信息會集中到海報系統(tǒng)，意味著資產(chǎn)管理專員可以通過這個平臺做所有資源初始化和分配調(diào)度。

PAAS平臺

通過業(yè)務(wù)邏輯把各個資源統(tǒng)籌起來，資源所見即所得，更容易的實現(xiàn)了持續(xù)集成，通過各項基礎(chǔ)服務(wù)的組合，實現(xiàn)代碼自動化發(fā)布、應(yīng)用管理、環(huán)境初始化部署、線上運維一體化集成，提升項目代碼編譯、測試、發(fā)布效率。

PAAS 平臺主要職責(zé)如下：

提供一致性環(huán)境保障。

• 提供應(yīng)用多租戶隔離以及資源的多租戶隔離。
• 提供服務(wù)發(fā)現(xiàn)、可彈性伸縮、狀態(tài)管理、資源分配、動態(tài)調(diào)度等能力。
• 支持預(yù)發(fā)布、一鍵發(fā)布、一鍵回滾以及自動化部署。
• 提供透明化的監(jiān)控、容災(zāi)能力。
• 提供運維、開發(fā)、測試多角度業(yè)務(wù)場景。

如下圖，是 PAAS 平臺的主要技術(shù)選型：

從上圖可以看出，PAAS 平臺里也包含外部組件，Docker 也包含其中。因為游戲公司大量代碼基本都放到 SVN，所以我們也會選在 SVN 來管理。

Docker 容器技術(shù)

PAAS 平臺的設(shè)計中，核心部分是 Docker。那搜狐暢游的 Docker 是如何設(shè)計的呢？

如下，是原 Docker 架構(gòu)圖：

如下，是最終版的 Docker 架構(gòu)圖：

從 2014 年至今，我們已經(jīng)迭代過兩個版本，搜狐暢游在容器監(jiān)控數(shù)據(jù)共享、穩(wěn)定性和鏡像管理等方面進(jìn)行了優(yōu)化。

如下圖，是技術(shù)演化對比：

因 Ceph 副本之間不穩(wěn)定，不支持集群共享，所以改成 NFS+DRBD。因 Consul 集群 Leader 切換頻繁，業(yè)務(wù)數(shù)據(jù)不同步，負(fù)載過高，改成 Etcd，來保證數(shù)據(jù)同步統(tǒng)一。

為應(yīng)對 cAdvisor 無法匯總，無法查看歷史數(shù)據(jù)的問題，我們自研了 Hunter。操作系統(tǒng)從 2.6 升級到 3.18，應(yīng)對運行久了后 devicemapper 的信息無法寫入導(dǎo)致系統(tǒng)異常的問題。

混合云結(jié)構(gòu)

暢游運維體系最底層采用的是混合云結(jié)構(gòu)，開始考慮的方式是直接接入所有公有云，用專業(yè)的方式打通，但游戲需要 BGP（網(wǎng)關(guān)協(xié)議）。

這意味著必須多線接入，除電信、聯(lián)通外，所有的小區(qū)寬帶，第三方寬帶也必須要接入，所以需要選擇混合云的結(jié)構(gòu)。

選擇混合云相比暢游 IDC 降低成本在 20% 左右，并且使資源彈性，云上云下，擴(kuò)縮容更快速。在可靠性方面，不僅可實現(xiàn)異地雙活，還有抗攻擊、DNS 劫持、冗余可靠等優(yōu)勢。

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

暢游運維管理體系的下一步將把持續(xù)交付的分層能力和公共服務(wù)標(biāo)準(zhǔn)化作為探索方向。

持續(xù)交付的分層能力

在暢游運維做自動化時，會利用可持續(xù)交付的理念和原則去做。工具開發(fā)過程中，一定要注意的問題是：工具越多，工具與工具之間的調(diào)用就會出現(xiàn)大量的問題。

所以一定要進(jìn)行平臺化和做成集群式服務(wù)，否則成本不會降低，反而故障依舊會很多。

公共服務(wù)標(biāo)準(zhǔn)化

如下圖，是公共服務(wù)平臺整合架構(gòu)：

暢游把 redis、Nginx、MySQL 等集群全部接入，不需要做其他的事情。

寫在最后

暢游運維做整個自動化過程中的心得有三個：

• 簡單有效，不要做特別花哨，因為對應(yīng)用最實際才是有用的，對應(yīng)用或開發(fā)人員來說，最有效及效率最高是最好的。
• 符合實際業(yè)務(wù)，不是脫離研發(fā)和應(yīng)用。
• 高效，游戲特性決定必須高效，快上快下，快速決策。

以上內(nèi)容根據(jù)黎志剛老師在 DevOps 與持續(xù)交付專場的演講內(nèi)容整理。如有投稿、尋求報道意向技術(shù)人請聯(lián)絡(luò) wangxy@51cto.com 

[[197936]]

游戲行業(yè)近十年技術(shù)管理經(jīng)驗。2008 年加入暢游天下，現(xiàn)任系統(tǒng)運維中心總監(jiān)及項目管理部經(jīng)理、打造百萬用戶在線游戲技術(shù)運維平臺。 近年來，致力于建設(shè)一流的游戲技術(shù)團(tuán)隊，負(fù)責(zé)全面管理運維工作，包括 IDC/網(wǎng)絡(luò)/硬件規(guī)劃管理、系統(tǒng)運維、數(shù)據(jù)庫運維、應(yīng)用運維、運維平臺與工具開發(fā)等；建立和完善規(guī)范化的運維體系，保障運維質(zhì)量； 不斷研發(fā)與探索運維自動化及各類創(chuàng)新途徑，縮短運維響應(yīng)時間，減低運維成本。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】