在很多初創公司和中小型企業裡，運維還停留在“刀耕火種”的原始狀态，這裡所說的“刀”和“火”就是運維人員的遠程客戶端，例如 SecureCRT 和 Windows 遠程桌面。

在這種工作方式下，服務器的安裝、初始化，軟件部署、服務發布和監控都是通過手動方式來完成的，需要運維人員登錄到服務器上，一台一台去管理和維護。

這種非并發的線性工作方式是制約效率的最大障礙。同時，因為手動的操作方式過于依賴運維人員的執行順序和操作步驟，稍有不慎即可能導緻服務器配置不一緻，也就是同一組服務器的配置上出現差異。

有時候，這種差異是很難直接檢查出來的，例如在一個負載均衡組裡面個别服務器的異常就很難發現。

随着業務的發展，服務器數量越來越多，運維人員開始轉向使用腳本和批量管理工具。

腳本和批量管理工具與“刀耕火種”的工作方式相比，确實提升了效率和工程質量。

但這個方式仍然有很多問題：

• 腳本的非标準化的問題。不同運維人員寫的腳本在所用的編程語言、編碼風格和健壯性方面存在巨大差異，同時這些腳本的版本管理也是一個挑戰。
• 腳本的傳承問題，人員的離職和工作交接，都會導緻腳本無法很好地在運維人員之間傳承和再利用，因為下一個運維人員可能無法理解和修改前一個運維人員編寫的腳本功能。
• 批量管理工具的選擇。不同的管理人員選擇不同的批量管理工具必然會帶來管理混亂的問題，也無法很好地實現在運維人員之間互相備份工作的需求。

因此，對構建自動化運維體系的要求變得越來越迫切。通過自動化運維體系來實現标準化和提高工程效率，是唯一正确的選擇。那麼如何建設自動化運維體系呢？

本案例研究分為三個大的方面：

• 建設自動化運維體系的原因，就是解決“3W”中的 Why 和 What 的問題，即為什麼和是什麼。
• 建設自動化運維體系的目标，介紹我司各個運維子系統是怎樣設計、運行和處理問題的，解決“3W”中的 How 的問題，也就是怎樣去做的。
• 自動化運維體系的結構和運作方式，對我司在自動化運維過程中遇到的一些問題的思考，做一個總結。

建設自動化運維體系的原因

先來看一下我們為什麼要建設一個自動化運維體系。首先來看運維遇到的一些挑戰，如下圖所示：

遊戲的需求

第一個是遊戲的需求，它表現為三個方面：

遊戲數量多，我司現在運營的遊戲多達近百款。

遊戲架構複雜，遊戲公司和一般的互聯網公司有一個很大的區别，就是遊戲的來源可能有很多。

比如有國外的、國内的，有大廠商的、小廠商的；每個遊戲的架構可能不一樣，有的是分區制的，有的是集中制的，各種各樣的需求。

操作系統種類多，這與剛才的情況類似，遊戲開發者的背景與編程喜好不一樣，會有 Windows、Linux 等。

硬件環境

第二個是在硬件環境方面，主要表現為服務器數量多、服務器型号多。因為公司從建立到現在有十幾年的時間了，在這個過程中分批、分期采購的服務器幾乎橫跨各大 OEM 廠商的各大産品線，型号多而雜。

人的因素

最後是人的因素，我們在建設自動化運維體系過程中，有一個比較重要的考慮點是人的因素。

如果大家的技術能力都很強，很多時候一個人可以完成所有工作，可能也就不需要自動化運維體系了。

正是因為每個運維人員的能力不一樣，技術水平參差不齊，甚至是運維習慣和工具也不一樣，導緻我們必須要創建一套規範的自動化運維體系，來提升工作效率。

建設自動化運維體系的目标

再看一下建設這套自動化運維體系的目标，也就是說我們的原則是什麼？筆者将自動化運維體系的建設目标總結為四個詞：

• “完備”，這個系統要能涵蓋所有的運維需求。
• “簡潔”，簡單好用。如果系統的操作流程、操作界面、設計思想都比較複雜，運維人員的學習成本就會很高，使用的效果是會打折扣的，系統的能力、發揮的效率也會因此打折扣。
• “高效”，特别是在批量處理或者執行特定任務時，我們希望系統能夠及時給用戶反饋。
• “安全”，如果一個系統不安全，可能導緻很快就被黑客接管了。所以安全也是重要的因素。

自動化運維體系的結構和運作方式

下圖所示是我司當前自動化運維體系的幾個子系統，我們來看一看它們是怎樣聯合起來工作的。

首先服務器會經由自動化安裝系統完成安裝，然後會被自動化運維平台接管。

自動化運維平台會對自動化安檢系統、自動化客戶端更新系統和服務器端更新系統提供底層支撐。

自動化數據分析系統和自動化客戶端更新系統會有關聯關系。自動化數據分析系統會對自動化客戶端更新系統的結果給予反饋。

自動化運維體系結構圖

下面我們來看一下每個子系統是如何設計和工作的：

自動化安裝系統

說到自動化安裝，大家可能并不陌生，我們剛才說到挑戰是“兩多兩少”，型号多、操作系統多，但是人少，可用時間也比較少。

如下圖所示，整個流程采用通用的框架，首先由 PXE 啟動，選擇需要安裝的操作系統類型（安裝 Windows 或者 Linux），然後根據 Windows 系統自動識别出需要安裝的驅動。

服務器交付用戶之前，會進行基本的安全設置，例如防火牆設置以及關閉 Windows 共享，這在一定程度上提高了安全性，也減少了需要人工做的一些操作。

自動化安裝流程圖

自動化運維平台

當服務器由自動化安裝系統安裝完成以後，就會被自動化運維平台接管。自動化運維平台是運維人員的作業平台，它主要解決的問題就是因服務器、操作系統異構而且數量特别多而帶來的管理問題。

操作系統是五花八門的，我們在設計系統過程中考慮了以下幾個因素：

• 把整個系統的用戶界面設計成基于浏覽器的架構。運維工程師無論何時何地都可以登錄管理系統進行運維操作，這樣的話就比較方便。由 Octopod 服務器對被操作的機器發布指令。
• 統一管理異構服務器。大家以前可能對 Windows 深惡痛絕，其實 Windows 也可以管得很好。我們使用開源的 SSH 方式管理 Windows，這樣就可以對系統進行批量的補丁更新，還可以做批量的密碼管理和操作。
• 充分利用現有協議和工具。這個平台的特點是所有的系統使用 SSH 管理，而不是自己開發一些 Agent，這也體現了自動化運維的觀點。

很多時候我們沒必要重新造輪子，即使自己造出一套客戶端的方法，大部分時候也并沒有在生産環境裡得到嚴格的驗證。

而 SSH 協議本身已經存在很多年了，而且已經在我司使用了很多年，該出的問題已經出了，相對于造輪子，使用 SSH 更加穩定，更經得起考驗，使用起來更方便。

自動化安檢系統

下一個系統是自動化安檢系統。由于我們的子系統比較多，業務也比較多，怎樣設計一套系統去保障它們的安全呢？

這裡主要是兩個系統：

• 自動化安檢平台。遊戲公司和一般的互聯網公司有一個區别，就是前者需要給玩家發送很多的客戶端（特别是有的客戶端比較大），或者補丁文件，去更新、下載和安裝。

如果這些文件裡面出現病毒和木馬，将是一件很糟糕的事情，甚至會對業務和公司的聲譽造成惡劣影響。當這些文件被發到玩家電腦上之前，必須經過病毒檢測系統檢測，确保它沒有被注入相應的病毒代碼。

• 服務器端，主要是通過安全掃描架構來保障安全。安全并不是一蹴而就，一勞永逸的。如果不對系統持續地檢查、檢測、探測，那麼你的一些誤操作會導緻系統暴露在互聯網上，或者是暴露在惡意攻擊者的眼皮之下。

通過一種主動、自發的安全掃描架構對所有服務器進行安全掃描，就能在很大程度上規避這樣的問題。

舉一個例子，去年我們遇到過一個情況，某款交換機 ACL 達到一定的數量的時候，就完全失效了。

如果沒有相關的配套機制去檢查和檢測，那麼你的服務器、你認為保護得很好的端口或者是敏感的 IP 可能已經暴露。所以，通過這種主動的探測可以減少很多系統的或者是人為的安全問題。

自動化客戶端更新系統

遊戲是有周期性的，特别是在遊戲發布當天或者有版本更新的時候，這時候玩家活躍度很高，下載行為也是比較多的，但是平時的更新和下載帶寬可能并不大，這也是遊戲很顯著的特點。

這個特點對于我們構建這樣一個分發系統提出了很大的挑戰：

• 在高峰時遊戲産生的帶寬可能達到數百 GB。
• 很多小運營商或者中小規模的運營商會有一些緩存機制，這個緩存機制如果處理得不好，會對業務造成影響，也就是非法緩存的問題。
• 關于 DNS 調度的問題，DNS 調度本身是基于玩家本身的 Local DNS 的機制解析的，會有調度不準确的問題。
• DNS 污染，或者是 DNS TTL 的機制導緻調度不那麼靈敏和準确。

針對這些問題，我們有下面兩套系統來解決：

• Autopatch 系統
• Dorado 系統

Autopatch 系統

它解決的是大文件更新的下載問題，再就是多家 CDN 廠商流量調度。其操作流程也比較簡單，由運維人員上傳文件、安檢，然後同步到 CDN，由 CDN 分發到相關邊緣節點，最後解壓文件。

剛才說到遊戲的周期性特點，就是平時帶寬不是很大，但是在某個節點的時候，或者是重大活動的時候，帶寬比較大。

如果自己構建一套 CDN 系統，可能不是很劃算，所以我們引入國内多家比較大型的 CDN 廠商調度資源。我們通過 302 的方法調度，而不是把域名給其中一家或幾家。

因為直接使用 CNAME 的話很難按比例調度，特别是帶寬大的時候，一家 CDN 廠商解決不了，或者是一家發生局部故障，需要快速切除。而通過集中的調度系統就可以實現按比例調度的功能。

用戶發過來的所有請求，首先要在我們這邊進行調度，但是本身并不産生直接下載帶寬，而是通過相關算法，按比例和區域調度給第三方的 CDN 廠商，然後玩家實際是由第三方 CDN 廠商節點去下載客戶端的。

Dorado 系統

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

比如我們的區服列表，如果我們服務器端增加了新的區服，在客戶端沒有顯現出來，就導緻玩家沒有辦法進入到新的區服去玩。

針對這些問題，我們設計了内部代号為 Dorado 的系統，因為這些文件本身是比較小的，而且數量也不是特别多，但是需要用 HTTPS 加密，通過加密規避小運營商的緩存問題。

所以我們對于這些關鍵文件，全部有自有節點，在節點上支持 HTTPS 加密方法，規避小運營商緩存帶來的一些問題。

自動化服務器端更新系統

我們采用的服務器端更新模式也是一種比較傳統的類似于 CDN 的方式，是由目标服務器通過緩存節點到中央節點下載，由緩存節點緩存控制，這樣可以減少網間傳輸的數據量以及提高效率。

我們在設計這套系統的時候，也想過用 P2P 去做。大家想 P2P 是很炫，又節省帶寬，但是用于生産環境中大文件分發的時候會有幾個問題：

• 安全控制的問題，很難讓這些服務器之間又能傳數據又能進行安全端口的保護。
• 在 P2P 裡做流量控制或者流量限定也是一個挑戰。

所以最終我們采用了一個看起來比較簡單的架構。

自動化數據分析系統

說到客戶端更新，其實更新的效果如何，玩家到底有沒有安裝成功或者進入遊戲，很多時候我們也很茫然，隻能看日志。

但是日志裡面的很多信息是不完善和不完整的。下載客戶端的時候，如果看 HTTP 的日志的話，裡面是 206 的代碼，很難計算出玩家到底完整下載了多少客戶端，甚至他有沒有下載下來，校驗結果是否正确，也很難知道。

所以我們最終設計了一個自動化數據分析系統，目标就是分析從用戶開始下載到他登錄遊戲，數據到底是怎樣轉化的。

最理想的一種情況是用戶下載客戶端以後，就進入了遊戲，但這是一個理想情況。

很多時候，比如因為網絡不好，導緻用戶最終沒有下載成功，或者是因為賬号的一些問題，用戶最終沒有登錄到遊戲裡面去。

所以，展現出來的數據就是一個漏鬥狀。我們的目标就是讓最終登錄的用戶數接近于起初下載客戶端的用戶數。

我們來看一下系統的架構。首先由玩家這邊的下載器或者是安裝客戶端，遊戲客戶端裡面集成一些 SDK。

對于任何一個關鍵點，比如“下載”按鈕或者“終止”按鈕的數據都上報，當然這裡面不會涉及敏感信息。上報以後會有 Tomcat 集群，集群處理以後會将數據寫入 MongoDB。

看一下這個遊戲在引導過程中有什麼問題，左邊的這一列它分為三個文件，有一個是 3MB，有兩個是 2G 多的文件，其實大家可以想像一下。

很多時候玩家看到小的文件就把小的文件直接下載安裝了，但是實際上并不完整。

這一點也告訴我們，很多時候在運營或者是業務方面，在引導方面也是要比較合理才能去規避掉一些問題。

自動化數據備份系統

我們第一個版本的備份系統，它的設計和實現是比較簡單的：不同的機房會有一台 FTP 服務器，本機房的數據寫入 FTP 服務器，然後寫入磁帶。

但是這樣就導緻磁帶是分散的，沒有集中存放的地方；另外，基于 FTP 的上傳會有帶寬甚至有延遲的要求。

後來我們設計了一個集中的備份系統，它主要解決了以下兩個問題：

第一是簡化配置。我們所有機房的全部配置，用一個負載均衡器的 IP 就可以了。

當客戶端需要上傳文件時，通過負載均衡器獲取實際上傳的地址，然後上傳文件，由左邊第二個框裡面的服務器進行接收，并且根據 MD5 值進行校驗，如果校驗沒有問題，就轉到 Hadoop 的 HDFS 集群裡面去。目前這個集群有數十 PB 的規模，每天上傳量有幾個 TB。

第二是提高傳輸效率和成功率。大家會想一個問題，在中國，網絡環境十分複雜，運營商之間存在隔閡甚至是壁壘，導緻網絡不穩定，丢包和延遲的問題是怎樣解決的呢？

如果基于 TCP 傳輸大文件，理論上存在單個連接上帶寬延時積的限制。這裡我們創新的是，客戶端的上傳采用 UDP 協議，UDP 本身沒有任何控制，說白了就是客戶端可以任意、使勁地發文件。

最終會由服務器端檢查你收到了哪些文件片段，然後通知客戶端補傳一些沒上傳的片段就可以了。

基于這種方式能規避很多因為網絡抖動或網絡延遲比較大而導緻的問題。當然，在客戶端做流量控制也是可以的。在遇到問題的時候多想想，或許能找到不走尋常路的解決方案。

自動化監控報警系統

再看一下遊戲的自動化監控報警系統，如上圖。遊戲的架構中有遊戲客戶端、服務器端、網絡鍊路。

所以必須要有比較完整的體系進行全方位、立體式的監控，才能保證在業務發生問題之前進行預警，或者在發生問題時報警：

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

作為運維人員，我們考慮問題或者設計架構的時候，視角不能僅局限于一個技術方面，或者選用多炫酷、多麼牛的技術，要想想技術在業務方面的架構，或者能否通過業務指标監控我們的運維能力與運維系統。

在遊戲裡，有一個很重要的指标就是在線人數，通過監控在線人數這個業務指标，就可以知道系統是否工作正常，是不是有漏報、誤報的情況。

因為很多時候任何一個環節出了問題，最終都會體現在業務上，在産生價值的數據上。

所以我們有一套監控在線人數的系統，每個遊戲上線之前會接入這個系統，把在線的人數實時彙集到系統裡面。

如果發生異常的抖動，系統中都會有所顯示，也就可以知道是否發生了問題。

以上講的是一個框架，下面我們看一下細節，怎樣做服務器的監控。

首先由運維工程師在監控策略平台配置監控策略，監控策略平台會将這些數據格式化成相關格式，然後推送給自動化運維平台。

自動化運維平台會判斷這些數據是外部來的，還是遠程檢測到的；是網絡模拟的，還是本地的監控得到的。

比如流量、本地進程的監控、本地日志的監控，會分别推給遠程探測服務器，或者遊戲服務器本身，然後由它們上報數據。

數據上報以後，根據運維工程師配置的阈值，會觸發相關的報警，然後通知運維工程師進行相關處理。

因為雖然遊戲多種多樣，操作系統五花八門，但是總有一些大家可以公用的東西，比如監控的模闆或者監控的策略，我們對服務器的東西也進行了整合彙總。

大家可以看到我們裡面有很豐富的插件，運維人員隻要選擇相關的插件，配一下阈值和周期，就可以節省時間和學習成本，提高配置策略的效率。當配置策略完成以後，直接綁定到想要監控的服務器上就可以了。

總結

我們從 2000 年初到現在一直在做自動化運維體系，對過去進行總結，我覺得有三個方面可以供大家參考。

循序漸進的原則

特别是中小公司或者初創公司，很多時候并不需要一個“高大上”的系統。聚焦當前的問題，把當前的問題處理好，後面的問題也就迎刃而解。

如果一開始設計的系統很龐大、功能特别豐富，會導緻一些無法控制的局面。

比如這個系統可能最後做不下去了，或者因為耦合性太強，開發控制不了了，或者項目因為經費問題擱淺了。

但是如果一開始的目标是解決一些特定的問題，有針對性，那麼推進起來也會比較簡單。

在我司的自動化運維體系建設過程中，我們首先構建的是一個基礎的服務器批量操作平台，先把一部分需要重複執行的工作搬到平台上來，再依據運維的需求豐富這個操作平台的功能和提升效率，最後把周邊的系統打通，相互對接，形成完整的自動化運維體系。

考慮可擴展性

設計系統的時候，功能或者設計方面可能不用考慮那麼多，但是要考慮當服務器數量發生比較大的擴張時，系統是否還能支撐，比如數量級從十到百，或者上千了，這個系統是否還是可用的。

以實用為目的

這在我們系統中也是有體現的。很多情況下，市面上可能已經有比較成熟的協議和工具，拿來評估看看它們在生産環境裡面是否可用，如果能用就直接用，沒必要自己再去做一套。

自己做的這一套工具，很多方面沒有經過驗證，可能會帶來安全問題。基于成熟的協議和框架去做，可以提升效率，保證穩定性和安全性。

在“自動化運維平台”一節可以看到，我們并沒有自己從頭開始研發一套 Agent 植入到被管理的服務器上，而是用了開源的 SSH 協議和成熟的 OpenSSH 軟件。

這體現了優先考慮開源方案加一部分二次開發而不是重複造輪子的思想。

胥峰，著有暢銷書《Linux 運維最佳實踐》、譯著《DevOps：軟件架構師行動指南》，資深運維專家，有 11 年運維經驗，在業界頗具威望和影響力。2006 年畢業于南京大學，曾就職于盛大遊戲等大型知名互聯網公司，現就職于Garena Singapore 。擁有工信部認證高級信息系統項目管理師資格。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!