如何從零搭建一個自動化運維體系

1、建設自動化運維體系的緣由

第一個是遊戲的需求。它表現爲三個方面:

• 一是遊戲數量多，我司如今運營的遊戲多達近百款。
• 二是遊戲架構複雜。遊戲公司和通常的互聯網公司有一個很大的區別，就是遊戲的來源可能有不少，好比有國外的、國內的，有大廠商的、小廠商的；每一個遊戲的架構可能不同，有的是分區制的，有的是集中制的，各類各樣的需求。
• 三是操做系統種類多，這與剛纔的狀況相似，遊戲開發者的背景與編程喜愛不同，會有Windows、Linux等。

第二個是在硬件環境方面，主要表現爲服務器數量多、服務器型號多。

由於公司從創建到如今有十幾年的時間了，在這個過程當中分批、分期採購的服務器幾乎橫跨各大OEM廠商的各大產品線，型號多而雜。

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

若是你們的技術能力都很強，不少時候一我的能夠完成全部工做，可能也就不須要自動化運維體系了。

正是由於每一個運維人員的能力不同，技術水平良莠不齊，甚至是運維習慣和工具也不同，致使咱們必需要建立一套規範的自動化運維體系，來提高工做效率。

2、建設自動化運維體系的目標

再看一下建設這套自動化運維體系的目標，也就是說咱們的原則是什麼？

筆者將自動化運維體系的建設目標總結爲四個詞。

• 第一個是「完備」，這個系統要能涵蓋全部的運維需求。
• 第二個是「簡潔」，簡單好用。若是系統的操做流程、操做界面、設計思想都比較複雜，運維人員的學習成本就會很高，使用的效果是會打折扣的，系統的能力、發揮的效率也會所以打折扣。
• 第三個是「高效」，特別是在批量處理或者執行特定任務時，咱們但願系統可以及時給用戶反饋。
• 第四個是「安全」，若是一個系統不安全，可能致使很快就被黑客接管了。因此安全也是重要的因素。

  3、自動化運維體系的結構和運做方式

3.一、自動化安裝系統

說到自動化安裝，你們可能並不陌生，「兩多兩少」，型號多、操做系統多，可是人少，可用時間也比較少。

整個流程採用通用的框架，首先由PXE啓動，選擇須要安裝的操做系統類型（安裝Windows或者Linux），而後根據Windows系統自動識別出須要安裝的驅動。服務器交付用戶以前，會進行基本的安全設置，例如防火牆設置以及關閉Windows共享，這在必定程度上提升了安全性，也減小了須要人工作的一些操做。如圖所示：

                                                           自動安裝流程圖

3.二、自動化運維平臺

當服務器由自動化安裝系統安裝完成之後，就會被自動化運維平臺接管。自動化運維平臺是運維人員的做業平臺，它主要解決的問題就是因服務器、操做系統異構並且數量特別多而帶來的管理問題。操做系統是五花八門的，咱們在設計系統過程當中考慮瞭如下幾個因素：

把整個系統的用戶界面設計成基於瀏覽器的架構。運維工程師不管什麼時候何地均可以登陸管理系統進行運維操做，這樣的話就比較方便。由Octopod服務器對被操做的機器發佈指令。

統一管理異構服務器。你們之前可能對Windows深惡痛絕，其實Windows也能夠管得很好。咱們使用開源的SSH方式管理Windows，這樣就能夠對系統進行批量的補丁更新，還能夠作批量的密碼管理和操做。

充分利用現有協議和工具。這個平臺的特色是全部的系統使用SSH管理，而不是本身開發一些Agent，這也體現了自動化運維的觀點。

不少時候咱們不必從新造輪子，即便本身造出一套客戶端的方法，大部分時候也並無在生產環境裏獲得嚴格的驗證。

而SSH協議自己已經存在不少年了，並且已經在我司使用了不少年，該出的問題已經出了，相對於造輪子，使用SSH更加穩定，更經得起考驗，使用起來更方便。

3.三、自動化安檢系統

下一個系統是自動化安檢系統。因爲咱們的子系統比較多，業務也比較多，怎樣設計一套系統去保障它們的安全呢？這裏主要是兩個系統：自動化安檢平臺和服務器端。

先來看自動化安檢平臺。遊戲公司和通常的互聯網公司有一個區別，就是前者須要給玩家發送不少的客戶端（特別是有的客戶端比較大），或者補丁文件，去更新、下載和安裝。

若是這些文件裏面出現病毒和木馬，將是一件很糟糕的事情，甚至會對業務和公司的聲譽形成惡劣影響。當這些文件被髮到玩家電腦上以前，必須通過病毒檢測系統檢測，確保它沒有被注入相應的病毒代碼。

再來看服務器端，主要是經過安全掃描架構來保障安全。

安全並非一蹴而就，一勞永逸的。若是不對系統持續地檢查、檢測、探測，那麼你的一些誤操做會致使系統暴露在互聯網上，或者是暴露在惡意攻擊者的眼皮之下。

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

舉一個例子，去年咱們遇到過一個狀況，某款交換機ACL達到必定的數量的時候，就徹底失效了。

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

3.四、自動化客戶端更新系統

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

這個特色對於咱們構建這樣一個分發系統提出了很大的挑戰。

第一個挑戰就是在高峯時遊戲產生的帶寬可能達到數百GB。

第二是不少小運營商或者中小規模的運營商會有一些緩存機制，這個緩存機制若是處理得很差，會對業務形成影響，也就是非法緩存的問題。

第三是關於DNS調度的問題。

DNS調度自己是基於玩家自己的Local DNS的機制解析的，會有調度不許確的問題。

第四是DNS污染，或者是DNS TTL的機制致使調度不那麼靈敏和準確。針對這些問題，咱們有下面兩套系統來解決。

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

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

若是本身構建一套CDN系統，可能不是很划算，因此咱們引入國內多家比較大型的CDN廠商調度資源。咱們經過302的方法調度，而不是把域名給其中一家或幾家。

由於直接使用CNAME的話很難按比例調度，特別是帶寬大的時候，一家CDN廠商解決不了，或者是一家發生局部故障，須要快速切除。

而經過集中的調度系統就能夠實現按比例調度的功能。用戶發過來的全部請求，首先要在咱們這邊進行調度，可是自己並不產生直接下載帶寬，而是經過相關算法，按比例和區域調度給第三方的CDN廠商，而後玩家實際是由第三方CDN廠商節點去下載客戶端的。

第二套是Dorado系統。剛剛講到小運營商或者某些運營商的非法緩存機制會對業務形成影響，那麼對於某些關鍵的文件，若是緩存的是一箇舊版本，可能會形成很大的問題。好比咱們的區服列表，若是咱們服務器端增長了新的區服，在客戶端沒有顯現出來，就致使玩家沒有辦法進入到新的區服去玩。

針對這些問題，咱們設計了內部代號爲Dorado的系統，由於這些文件自己是比較小的，並且數量也不是特別多，可是須要用HTTPS加密，經過加密規避小運營商的緩存問題。

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

3.五、自動化服務器端更新系統

咱們採用的服務器端更新模式也是一種比較傳統的相似於CDN的方式，是由目標服務器經過緩存節點到中央節點下載，由緩存節點緩存控制，這樣能夠減小網間傳輸的數據量以及提升效率。

咱們在設計這套系統的時候，也想過用P2P去作。你們想P2P是很炫，又節省帶寬，可是用於生產環境中大文件分發的時候會有幾個問題。

一是安全控制的問題，很難讓這些服務器之間又能傳數據又能進行安全端口的保護。

二是在P2P裏作流量控制或者流量限定也是一個挑戰。因此最終咱們採用了一個看起來比較簡單的架構。

3.六、自動化數據分析系統

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

可是日誌裏面的不少信息是不完善和不完整的。下載客戶端的時候，若是看HTTP的日誌的話，裏面是206的代碼，很難計算出玩家到底完整下載了多少客戶端，甚至他有沒有下載下來，校驗結果是否正確，也很難知道。因此咱們最終設計了一個自動化數據分析系統，目標就是分析從用戶開始下載到他登陸游戲，數據究竟是怎樣轉化的。

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

不少時候，好比由於網絡很差，致使用戶最終沒有下載成功，或者是由於帳號的一些問題，用戶最終沒有登陸到遊戲裏面去。

因此，展示出來的數據就是一個漏斗狀。咱們的目標就是讓最終登陸的用戶數接近於起初下載客戶端的用戶數。

咱們來看一下系統的架構。首先由玩家這邊的下載器或者是安裝客戶端，遊戲客戶端裏面集成一些SDK，對於任何一個關鍵點，好比「下載」按鈕或者「終止」按鈕的數據都上報，固然這裏面不會涉及敏感信息。上報之後會有Tomcat集羣，集羣處理之後會將數據寫入MongoDB。

看一下這個遊戲在引導過程當中有什麼問題，左邊的這一列它分爲三個文件，有一個是3MB，有兩個是2G多的文件，其實你們能夠想像一下。不少時候玩家看到小的文件就把小的文件直接下載安裝了，可是實際上並不完整。這一點也告訴咱們，其實不少時候在運營或者是業務方面，在引導方面也是要比較合理才能去規避掉一些問題。

3.七、自動化數據備份系統

咱們第一個版本的備份系統，它的設計和實現是比較簡單的：不一樣的機房會有一臺FTP服務器，本機房的數據寫入FTP服務器，而後寫入磁帶，可是這樣就致使磁帶是分散的，沒有集中存放的地方；另外，基於FTP的上傳會有帶寬甚至有延遲的要求。

後來咱們設計了一個集中的備份系統。它主要解決了如下兩個問題。
第一是簡化配置。咱們全部機房的所有配置，用一個負載均衡器的IP就能夠了，當客戶端須要上傳文件時，經過負載均衡器獲取實際上傳的地址，而後上傳文件，由左邊第二個框裏面的服務器進行接收，而且根據MD5值進行校驗，若是校驗沒有問題，就轉到Hadoop的HDFS集羣裏面去。目前這個集羣有數十PB的規模，天天上傳量有幾個TB。

第二是提升傳輸效率和成功率。你們會想一個問題，在中國，網絡環境十分複雜，運營商之間存在隔閡甚至是壁壘，致使網絡不穩定，丟包和延遲的問題是怎樣解決的呢？若是基於TCP傳輸大文件，理論上存在單個鏈接上帶寬延時積的限制。

這裏咱們創新的是，客戶端的上傳採用UDP協議，UDP自己沒有任何控制，說白了就是客戶端能夠任意、使勁地發文件。最終會由服務器端檢查你收到了哪些文件片斷，而後通知客戶端補傳一些沒上傳的片斷就能夠了。基於這種方式能規避不少由於網絡抖動或網絡延遲比較大而致使的問題。固然，在客戶端作流量控制也是能夠的。在遇到問題的時候多想一想，或許能找到不走尋常路的解決方案。

3.八、自動化監控報警系統

再看一下游戲的自動化監控報警系統（以下圖所示）。遊戲的架構中有遊戲客戶端、服務器端、網絡鏈路，因此必需要有比較完整的體系進行全方位、立體式的監控，才能保證在業務發生問題以前進行預警，或者在發生問題時報警。

對於機房鏈路，有IDC（Internet Data Center）的網絡質量監控；在服務器、網絡設備和硬件方面，咱們會作服務器的健康檢查、性能監控，以及網絡設備和流量監控；

在系統程序方面，咱們會收集和分析系統日誌；在遊戲服務器端應用方面，有服務器端的程序監控；在客戶端方面，咱們會收集植入的SDK作下載更新後的效果，以及收集崩潰的數據。

做爲運維人員，咱們考慮問題或者設計架構的時候，視角不能僅侷限於一個技術方面，或者選用多炫酷、多麼牛的技術，要想一想技術在業務方面的架構，或者可否經過業務指標監控咱們的運維能力與運維繫統。

在遊戲裏，有一個很重要的指標就是在線人數，經過監控在線人數這個業務指標，就能夠知道系統是否工做正常，是否是有漏報、誤報的狀況，由於不少時候任何一個環節出了問題，最終都會體如今業務上，在產生價值的數據上。

因此咱們有一套監控在線人數的系統，每一個遊戲上線以前會接入這個系統，把在線的人數實時聚集到系統裏面。若是發生異常的抖動，系統中都會有所顯示，也就能夠知道是否發生了問題。

以上講的是一個框架，下面咱們看一下細節，怎樣作服務器的監控。首先由運維工程師在監控策略平臺配置監控策略，監控策略平臺會將這些數據格式化成相關格式，而後推送給自動化運維平臺。

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

好比流量、本地進程的監控、本地日誌的監控，會分別推給遠程探測服務器，或者遊戲服務器自己，而後由它們上報數據。數據上報之後，根據運維工程師配置的閾值，會觸發相關的報警，而後通知運維工程師進行相關處理。由於雖然遊戲多種多樣，操做系統五花八門，可是總有一些你們能夠公用的東西，好比監控的模板或者監控的策略，咱們對服務器的東西也進行了整合彙總。