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

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

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續整合與持續交付（CI/CD）概覽；持續整合系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

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

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

從 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 等叢集全部接入，不需要做其他的事情。

寫在最後

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

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

原文連結：遊戲運維的最佳實踐：搜狐暢遊自動化運維之旅（作者：黎志剛）

原文釋出時間為：2017-07-27

本文作者：黎志剛

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：遊戲運維的最佳實踐：搜狐暢遊自動化運維之旅