關于作者

徐峰

盛大游戲高級研究員

2006年畢業于南京大學，2011年加入盛大游戲，擁有十年運維經驗，曾參與盛大游戲旗下多款大型端游、手游的線上運維，領導統一運維平臺的產品功能設計與實現，并具有工信部認證的高級信息系統項目經理資格

前言

首先，請允許我做一個簡短的自我介紹。我叫徐峰，來自盛大游戲，現任系統工程高級研究員。我寫了一本書，叫《Linux Best 》。

在這次演講中，我把它分為三個方面。

第一個方面，我們來看看為什么要做一個自動化運維系統，也就是解決“3W”中的why和what，why和what的問題。

第二個方面是看盛大游戲的各個運維子系統是如何工作的，如何設計、運營和處理問題，如何解決“3W”問題，如何去做。

三是總結一下我們在盛大游戲自動化運維過程中遇到的一些問題。

自動化運維系統介紹

首先，我們來看看為什么我們需要做一個自動化的運維系統。首先，我們來看看運維中遇到的一些挑戰，以及第一個游戲的要求。它表現在三個方面。我們都知道盛大游戲是比較知名的老牌游戲廠商。它現在運營著數百款游戲。第二種游戲結構復雜。

游戲公司和普通的互聯網公司有一個很大的區別，就是游戲的來源可能有很多，國外的、國內的、大廠商的、小廠商的。每個游戲的結構可能不同，有的分區，有的很大，需求多樣。

另一個是操作系統的種類很多，和剛才的原因差不多。開發者的背景和編程偏好不同，如Linux、Linux等。二是在硬件環境上，主要表現在大量的服務器和大量的服務器型號上。由于公司成立十余年，在這個過程中分批分期采購的服務器幾乎跨越了各大主機廠的主要產品線，而且型號比較多且雜。

另一個是人為因素。在構建自動化運維系統的過程中，比較重要的考慮因素之一就是人的因素。如果每個人都是好人，很多時候一個人可以完成所有的工作。 ，也許你不需要自動化運維系統。正是因為我們每個人的能力不同，技術水平參差不齊，甚至運維習慣也不同，所以我們必須建立一個標準化的自動化運維體系來提高我們的工作效率。

看看我們構建這個自動化運維系統的目標，也就是我們的原則是什么？我認為做任何事情，目標和原則都很重要。

我構建自動化運維系統的目標總結為四個字：

運維子系統詳解

1.自動化安裝系統

我們來看看盛大游戲目前自動化運維系統的幾個子系統，以及它們是如何協同工作的。第一個是自動安裝系統。服務器由自動化安裝系統安裝完成后，由自動化運維平臺接管。

自動化運維平臺為自動化安全檢查系統、自動化客戶端更新系統和服務器端更新系統提供底層支持。自動數據分析系統和自動客戶端更新系統是相關聯的。自動化數據分析系統將反饋自動化客戶端更新系統的結果。

讓我們來看看每個子系統是如何設計和工作的。說到自動化安裝，大家可能并不陌生。我們剛才提到，挑戰是多兩個少兩個，模型和操作系統很多，但是人少，可用時間少。

整個過程采用了一個通用的框架。首先是通過PXE啟動，是否安裝，是否是Linux，然后根據系統自動識別要安裝的驅動。在服務器交付給用戶之前，會進行基本的安全設置。

比如在防火墻設置中，關閉了里面的共享，在一定程度上提高了安全性，也減少了一些需要手動進行的操作。

2.自動化運維平臺

服務器由自動化安裝系統安裝后，將由自動化運維平臺接管。自動化運維平臺是運維人員的操作平臺。它解決的主要問題是服務器和操作系統是異構的，數量非常龐大。

我們可以看到，在這張圖中，我們的操作系統也是五花八門的。在設計系統的過程中，我們有幾個考慮因素。首先是將整個系統設計為基于瀏覽器的用戶界面。一個架構。

運維工程師可以隨時隨地管理您的系統進行運維操作，更加方便。服務器將向正在操作的機器發出指令。你可以看看這里的一個特性，服務器也是由 SSH 管理的。過去每個人都對它的感覺感到厭惡。

事實上，你可以很好地管理它。你可以參考這里，看看你是否能得到幫助。我們采用開源SSH方式進行管理，可以批量更新補丁到系統，批量密碼管理和操作。

所有系統都是通過SSH管理的，而不是在上面開發一些Agent，這也體現了自動化運維的觀點，至少我尊重。很多時候我們不需要自己造輪子，而是自己搭建一個客戶端的方法服務器運維，很多時候在生產環境中并沒有得到強烈的驗證。

但是SSH協議本身已經存在很多年了，在盛大游戲中也使用了很多年。問題已解決。與造輪子相比，這更穩定、更可驗證、更易于使用。方便的。升級之后也有升級，可以更簡單。

3.自動安檢系統

下一個系統是自動化安全檢查系統，因為我們有更多的子系統和更多的業務。那么我們如何設計一個系統來保證他們的安全呢？然后我這里講了兩個主要系統，一個是自動化安檢平臺。

游戲公司和一般互聯網公司的一個區別是他們有很多客戶端，尤其是大客戶端，或者需要發送給玩家更新、下載和安裝的補丁文件。如果有病毒和木馬，那將是一件非常糟糕的事情，甚至會對業務和公司的聲譽造成很大的影響。

這些文件在發送到玩家電腦之前，必須經過病毒檢測系統，確保沒有被注入相應的病毒代碼。另一個是服務器端，主要通過安全掃描架構來完成。我們都知道，安全往往不是一朝一夕的過程，也不是一勞永逸的過程。如果您不不斷地檢查、檢測和檢測您的系統，那么您的一些誤操作將導致您的系統暴露在互聯網上或被惡意攻擊。在攻擊者的眼皮底下。

通過一種主動、自發的安全掃描架構，它會掃描您的所有服務器以確保安全，您可以在很大程度上規避這個問題。舉個例子，我們去年也遇到過一個情況。當某臺交換機的ACL達到一定數量時，整個ACL就失效了。如果您沒有相關的支持機制進行檢查和檢測，那么您的服務器、您認為保護良好的端口或敏感IP可能已經暴露。

所以通過這種主動檢測，可以減少很多系統或人的安全問題。

4.自動客戶端更新系統

說到客戶端更新，我們都知道游戲是周期性的，尤其是在游戲發售當天或者有版本更新的時候。這時候玩家很活躍，下載行為也很多。

但是在平時，更新和下載帶寬可能不會很大，這也是游戲一個非常顯著的特點。但是這個特性對我們構建這樣一個分發系統提出了很大的挑戰。

那么第一個就是游戲產生的帶寬在高峰期可能達到數百G。其次，很多小型運營商或中小型運營商都有一些緩存機制。當然，如果這個緩存機制處理不好，就會影響業務，也就是非法緩存的問題。

另一個問題是關于 DNS 調度的。 DNS調度本身是根據玩家自己的Local DNS機制解析的。對此，會出現調度不準確的問題。此外，DNS 污染或 DNS TTL 機制會使您的調度變得不那么敏感和準確。

我們有兩個系統來解決這些問題。第一套是系統，解決大文件的更新下載，多CDN廠商的流量調度。操作過程也比較簡單。運維人員上傳文件，進行安全檢查，然后同步到CDN。 CDN將文件分發到相關的邊緣節點，最后解壓文件。

它有一個特點，剛才提到了游戲的周期性特點，就是平時帶寬不是很大，但是在節點的時候，或者是重大事件的時候，帶寬就比較大了。如果自己搭建CDN系統，可能不太劃算，所以我們引進國內很多大型CDN廠商來調度資源。

我們的調度是通過302的方式，而不是把域名分給其中的一個或幾個。因為直接使用CNAME很難按比例調度，特別是帶寬大的時候，CDN廠商解決不了，或者本地出現故障，需要快速移除。這樣的功能可以通過集中調度系統來實現。

所有用戶的第一個請求是在我方調度，但不產生直接下載帶寬，而是通過相關算法按比例和面積調度給第三方CDN廠商，然后在客戶端，播放器實際上是由第三方 CDN 供應商節點下載的。

剛才提到小運營商或者部分運營商的非法緩存機制會影響業務。那么對于一些關鍵文件，如果緩存到舊版本，可能會造成很大的問題。

比如在我們的區域服務器列表中，如果我們在服務器端添加了一個新的區域服務器，但它沒有出現在客戶端，就會導致玩家無法進入新的區域服務器進行游戲.

針對這些問題，我們設計了內部代號系統，因為這些文件本身比較小，數量也不是特別多，但是需要HTTPS加密，小運營商的緩存問題可以通過加密避免。

所以我們對所有的key文件都有自己的節點，并且在節點上支持HTTPS加密，避免一些小運營商緩存帶來的問題。

5.自動服務器端更新系統

讓我們來看看服務器端更新。我們使用的服務器端更新方式，也是類似于CDN的傳統方式。目標服務器通過緩存節點到中心節點下載，由緩存節點緩存控制，可以減少網絡傳輸量，提高效率。

有一個小插曲。我們在設計這個系統的時候也想過用P2P來做，但是因為在生產中大家都覺得P2P是一個很炫的東西，或者說是節省帶寬的東西。 ，但是在生產中用于分發大文件時存在幾個問題。一是安全控制問題。如何在這些服務器之間傳輸數據并保護安全端口是一個難題。

另外，如何控制流量或限制流量也是P2P中的一個挑戰，所以最終我們采用了一個比較簡單的結構來做。

6.自動化數據分析系統

說到客戶端更新。更新有什么效果，或者玩家是否安裝成功或進入游戲。很多時候我們不知所措或者可以看日志，但是日志中的很多信息是不完整的服務器運維，不完整的。

下載客戶端的時候，如果查看HTTP日志，里面有一個206代碼。你很難計算出玩家完整下載了多少客戶端，甚至很難知道他是否下載了驗證結果。 所以我們最終設計了這樣一個自動化的數據分析系統。它的目標是查看從下載過程開始到您登錄游戲時數據是如何轉換的。

一個理想的情況可能是用戶下載后進入游戲，但這是一個理想的情況。很多時候，比如他的網絡不好，最后下載不成功，或者是賬號有問題，最后沒有登錄游戲。

那么它呈現的數據形式就是一個漏斗狀的情況。那么我們的目標就是讓最終登錄的用戶數接近我們開始下載的用戶數。

讓我們來看看系統架構。首先，播放器端有下載器或安裝客戶端。部分 SDK 集成在游戲客戶端列表中。對于任何一個關鍵點，比如下載按鈕或者終止按鈕NYU上報數據，當然不會涉及敏感信息。上報后會有一個集群，然后集群處理后寫入。

看一個例子，這是一款在某個時間點大量安裝失敗的游戲。

在啟動過程中查看此游戲的問題。左邊一欄分為三個文件，一個是3MB，兩個是2G以上的文件。事實上，你可以想象它。很多時候玩家看到小文件直接下載安裝小文件，其實并不完整。這也告訴我們，在很多情況下，無論是運營還是業務上，都需要在引導上更加合理，避免出現一些問題。

7.自動數據備份系統

請葛優叔叔出去。大家想想如果一個游戲在運行過程中，數據突然沒了，沒有備份。有任何想法嗎？我覺得葛優叔做得很好。基本上，就是這種感覺。基本上，你的身體已經被掏空了，基本都難以駕馭。

有沒有人想過解決這個問題的辦法，有沒有人舉手，看來大家只有一個想法收拾行李走吧？這是一個小故事。游戲運營初期，很多時候都是粗放，沒有備份機制。

在這種情況下，某游戲公司確實有這樣的問題，他們到底是怎么做的？它實際上是一個活動，讓玩家來填寫他們的賬戶信息和屬性，以及你正確填寫了哪些金幣，系統會為你匹配金幣。那個時代的玩家是很無辜的。很多人填的信息，我們就填你填的。這個數據恢復了很多，游戲繼續運行。

在這之后，很多玩家看到這樣的言論就不會這樣做了，所以我提醒大家做好備份，并保證備份的可恢復性。

這是我們第一個發生嚴重事故的備份系統版本，其設計和實現都比較簡單和簡單。也就是根據不同的機房，我們會有一個FTP服務器，然后寫入機房的FTP服務器，再寫入磁帶，這樣會導致你的磁帶分散，沒有集中存儲地方。那么基于FTP上傳會有帶寬甚至延遲的要求。

然后我們設計了這樣一個集中式備份系統。在這種情況下，它主要解決了幾個問題。

第一個是為我們所有的機房配置一個負載均衡器IP。客戶端需要上傳文件時，通過負載均衡器獲取實際上傳地址，然后從左側第二個框開始上傳文件。如果驗證沒有問題，則轉入HDFS集群。目前該集群規模為數十PB，日上傳量為數T。

每個人都會思考一個問題。在中國，對運維人員的網絡要求非常高，運營商之間的差距甚至是一些壁壘，導致網絡不穩定，丟包，如何解決時延問題？如果在大文件傳輸過程中基于 TCP 進行，則涉及到單個連接上帶寬延遲乘積的理論限制。我們這里創新的是我們的客戶端上傳使用UDP協議，UDP本身沒有控制權。說白了就是客戶端可以任意硬發送。

那么服務器最終會檢查你收到了哪些文件段，然后通知客戶端重新上傳一些沒有上傳的文件。基于這種方法，可以避免很多由網絡抖動甚至大的網絡延遲引起的問題。當然，你也可以在客戶端做流量控制。以后遇到問題的時候，可能會想一些非常規的解決方案，也可能存在。

8.自動監控報警系統

我們來看看我們游戲的監控系統。剛才提到游戲的架構決定了有游戲客戶端，有服務器，有網絡鏈路，所以你必須有一個比較完善的系統才能全方位進行，這樣的三維監控可以保證業務會在問題發生前發出預警，或在問題發生時發出警報。

對于機房鏈路，我們有IDC的網絡質量監控來做。在服務器網絡設備和硬件方面，將有服務器健康檢查、性能監控、網絡設備和流量監控。在系統程序方面，我們會收集和分析系統日志，在游戲服務器端應用方面，會有服務器端程序監控。在客戶端，會有一個植入的SDK，用于收集下載和更新效果，以及收集其崩潰的數據。

看左邊那一欄，為什么用紅色標出，因為我想強調它的重要性。當我們考慮運維或架構設計的問題時，我們的視角不局限于技術方面，或者我們想思考技術有多酷和牛逼，我們必須考慮技術在業務中的架構。方面。或者我們是否可以通過業務指標來監控我們的運維能力和運維系統。

游戲中的一個重要指標是在線人數。通過監控在線人數等一個業務指標，可以知道我左邊的系統是否正常工作，是否有漏報或誤報，因為很多時候任何一個環節都有問題。

最終表現的問題，都是關于業務和產生價值的數據，所以我們會有一個監控人數的系統。每款游戲上線前，都會與系統連接，采集一直在線的人數。在系統中，如果出現異常抖動等，會顯示在里面，可以告訴你是否有問題。

這是一個框架，讓我們來看看細節，我們如何進行服務器監控。

結構是這樣的。首先運維工程師配置監控策略，然后到監控策略平臺。監控策略平臺會根據數據對數據進行格式化，格式化成相關格式，然后推送到第三頁PPT中提到的自動化運維平臺，自動化運維平臺會監控是否它來自外部來源，遠程檢測，網絡模擬或本地監控。

例如監控流量、本地進程、本地日志等推送到遠程檢測服務器，或者游戲服務器本身。

然后他們會報告數據。數據上報后，會根據運維工程師配置的閾值觸發相關告警，然后通知運維工程師進行相關處理。因為雖然有各種各樣的游戲，各種各樣的操作系統，或者各種各樣的操作系統，但總有一些東西是大家可以共享的。

您可以將其視為監控模板或監控策略。我們還對服務器的東西進行了整合和總結。你可以看到我們有很多插件。運維人員只需選擇相關插件，匹配閾值，匹配時間，可以節省大家的時間和學習成本，提高你的配置策略效率。 .

配置策略完成后，可以直接綁定到你要監控的服務器。

總結

從 2000 年初到現在，我們一直致力于自動化運維系統。這么多年，我們也想考慮一個問題。總結我們的過去，我覺得可以從三個方面給大家建議。

第一個是循序漸進的原則，尤其是對于中小型公司或初創公司。很多時候我們不需要一個高級的、白色的、豐富的系統。您可能需要專注于當前的問題并妥善處理它們。 ，處理完美，后面的問題也是可以輕松解決的情況。如果您開始設計一個非常龐大且功能豐富的系統，可能會導致一些無法控制的情況。

比如這個系統最終可能不工作，或者因為耦合太強，開發無法控制，或者項目費用擱淺。

但是如果最初的目標是解決一些具體的問題，有一些針對性，推進起來也比較簡單。

另一個是考慮可擴展性。在我們設計系統的時候，你可能不需要在功能或者設計上考慮那么多，但是對于當前的問題，你需要考慮你的服務器。當一些比較大的擴展發生時，是否還能支持它??們，比如十到一百、一千的數量級，仍然可以使用，這也是一個需要考慮的問題，也就是考慮可擴展性。

另外，它是出于實用目的，這也體現在我們的系統中。在很多情況下，市場上可能有一些相對成熟的協議和工具可以做到這一點。我們只需要通過相關的評估就可以認為它在生產中。可用，很多時候不需要自己再做一套。

你做的另一套沒有經過多次驗證，可能會帶來安全問題。基于成熟的協議和框架來做，而不是自己重新發明輪子，通常可以提高你的效率，確保你的穩定性和安全性。

問答

更多精彩繼續

12月16-17日，北京站將在國際會議中心舉行，將為您呈現更多精彩內容。

立即注冊，在 10 月 30 日前享受早鳥價 20% 的折扣。