盛大自動化運維

一、演講內容劃分

第一個方面是咱們來看一下，爲何要作自動化運維體系，就是解決「3W」裏面的爲何以及是什麼，Why和What的問題。

第二個方面是咱們看一下，目前盛大遊戲各個運維子系統是怎樣工做的，是怎樣設計、運行和處理問題的，解決「3W」裏面的How的問題，怎樣去作的。

第三個是對咱們盛大遊戲在自動化運維過程當中遇到的一些問題的一些思考，作一個總結。

二、自動化運維體系簡介

　　首先來看一下咱們爲何要作一個自動化運維體系。首先來看一下運維遇到的一些挑戰，第一個遊戲的需求。它表現爲三個方面。你們知道盛大遊戲是比較知名的老牌遊戲廠商。那它如今運營的遊戲多達數百款。第二個遊戲架構複雜。
　　遊戲公司和通常的互聯網公司有一個很大的區別，就是遊戲來源多是不少，好比說有國外的、國內的，有大廠商、有小廠商的。每一個遊戲的架構多是不同的，有的是分區制的，有的是大區制，各類各樣的需求。
　　另一個是操做系統種類多，這與剛纔的原因相似，開發者的背景與編程喜愛不同，會有Windows、Linux等。第二個是在硬件環境，主要表現爲服務器數量多、服務器型號多。由於公司創建到如今十幾年的時間了，在這個過程當中分批、分期採購的服務器幾乎橫跨各大OEM廠商的各大產品線，型號是比較多和雜的。
　　另外是人的因素，咱們在建設自動化運維體系過程當中個一個比較重要的考慮點是人的因素，若是你們都是很牛的人，不少時候一我的能夠完成全部工做的狀況下，可能你也不須要自動化運維體系了。正是由於咱們每一個人員的能力不同，技術水平良莠不齊，甚至是運維**慣也不同，致使咱們必需要建立一套規範的自動化運維體系，來提高咱們的工做效率。

三、自動化運維體系簡介

再看一下咱們建設這套自動化運維體系的目標，也就是說咱們的原則是什麼？我以爲作任何一件事情，目標和原則都是很是重要的。
我對自動化運維體系的建設目標這塊，總結爲四個詞：

• 第一是"完備"，你這個系統要能涵蓋全部的運維需求；
• 第二個是"簡潔"，簡單好用，若是系統的操做流程和操做界面、設計思想都比較複雜，那運維人員使用起來是打折扣的，那系統的能力、發揮的效率也會所以打折扣；
• 第三個是"高效"，特別是在批量處理或者是進行特定任務時，系統可以及時給用戶反饋；
• 第四個是"安全"，若是一個系統不安全，那麼就可能致使作了之後很快就被人接管了。因此安全也是重要的因素。

四、運維子系統詳解

4.1 自動化安裝系統

　　來看一下盛大遊戲當前自動化運維體系的幾個子系統，它們是怎樣聯合起來工做的。第一個是自動化安裝系統。服務器由自動化安裝系統完成安裝之後，會被自動化運維平臺接管。
　　自動化運維平臺對自動化安檢系統、自動化客戶端更新系統和服務器端更新系統提供底層支撐。自動化數據分析系統和自動化客戶端更新系統會有關聯關係。自動化數據分析系統會對自動化客戶端更新系統的結果給予反饋。

下面咱們來看一下每一個子系統是如何設計和工做的？

　　說到自動化安裝，你們可能並不陌生，咱們剛纔說到挑戰是兩多兩少，型號多、操做系統多，可是人少，可用時間也比較少。整個流程採用通用的框架，首先由PXE啓動，是否安裝Windows，是不是Linux，而後根據Windows系統自動識別出須要安裝的驅動。服務器交付用戶以前，會進行基本的安全設置。好比說防火牆設置，把Windows裏面的共享關閉，這在必定程度上就提升了安全性，另外也減小了人工須要作的一些操做。

4.2 自動化運維平臺

　　當服務器由自動化安裝系統安裝完成之後，就會被自動化運維平臺接管。自動化運維平臺是運維人員的做業平臺，它主要解決的問題就是服務器、操做系統異構，並且數量特別多。咱們能夠看到在這個圖裏面，咱們操做系統也是五花八門的，咱們在設計系統過程當中有幾個考慮的地方，第一個是把整個系統在用戶界面方面設計成基於瀏覽器的這樣一個架構。運維工程師不管什麼時候何地均可以去管理你的系統進行運維操做，那這樣的話就比較方便。會由Octopod服務器對被操做的機器發佈指令。你們能夠看一下這裏面有一個特色，Windows服務器也是用SSH的方式進行管理的。你們之前對Windows可能感受是深惡痛絕同樣。其實Windows你也能夠管得很好，這裏面你們能夠參考一下，看一下是否可以獲得幫助。咱們使用了開源的SSH方式管理Windows，這樣就能夠對系統進行批量的補丁更新，批量的密碼管理和操做都是能夠的。全部的系統使用SSH管理，而不是本身開發一些Agent在上面，這也體現了自動化運維的觀點，至少我是推崇的，不少時候咱們不必造輪子，本身造一套客戶端的方法，不少時候它並無在生產環境裏面獲得強烈地驗證。可是SSH協議自己已經存在不少年了，並且已經在盛大遊戲使用不少年了，該出的問題已經出了，相對於造輪子，這一點更加穩定，更加經得起驗證，使用起來更加方便。升級什麼的也跟着升，就能夠更加簡單了。

4.3 自動安檢系統

下一個系統是自動化安檢系統，由於咱們的子系統比較多，業務也比較多。那咱們怎樣設計一套系統去保障它們的安全呢？那麼我這裏面講到主要是兩個系統，一個是自動化安檢平臺。
　　遊戲公司和通常的互聯網公司有一個區別，就是它有不少的客戶端，特別是比較大的客戶端，或者是補丁文件須要發送給玩家去更新、下載和安裝。若是這裏面出現病毒和木馬，將會是一個很糟糕的事情，甚至是對業務和公司的聲望形成很大地影響。
當這些文件被髮到玩家電腦以前，必須通過病毒檢測系統去確保它沒有注入相應的病毒代碼。另外是服務器端，主要是經過安全掃描架構去作。你們知道安全不少時候並非一蹴而就或者是一勞永逸的過程，你若是不對你的系統進行持續地檢查、檢測、探測，那麼你的一些誤操做會致使你的系統暴露在互聯網上，或者是暴露在惡意攻擊者的眼皮之下。
　　經過一種主動、自發的安全掃描架構對你全部的服務器進行安全掃描，就能在很大程度上規避這樣的問題。舉一個例子就是咱們在去年的時候，也遇到過一個狀況。某款交換機ACL達到必定的數量的時候，整個就失效了。若是你沒有相關的配套機制去檢查、檢測，那你的服務器，你認爲保護很好的端口或者是敏感的IP可能已經被暴露了。
　　因此經過這種主動的探測就能夠減小不少的系統或者是人爲的安全問題。

4.4 自動化客戶端更新系統

面臨的挑戰

• 數百Gbps下載和更新帶寬的調度
• 小運營商緩存問題
• 同名文件刷新問題
• DNS調度不許確
• DNS污染
• DNS緩存問題（TTL）

　　到客戶端更新這塊，你們知道遊戲是有周期性的，特別是在遊戲發佈當天或者是有版本更新的時候，這時候玩家活躍度很高，下載行爲也是比較多的。可是平時的時候可能更新和下載帶寬並不大，這也是遊戲很顯著的特色。可是這個特色對於咱們構建這樣一個分發系統就提出了很大地挑戰。

　　那麼第一個就是在高峯時候遊戲產生的帶寬可能達到數百G。第二個不少小運營商或者是中小規模的運營商會有一些緩存機制，固然這個緩存機制若是處理很差，會對業務形成影響，也就是非法緩存的問題。

　　另外是關於DNS調度的問題。DNS調度自己是基於玩家自己的Local DNS的機制解析的，針對這個會有調度不許確的問題，另外是DNS污染，或者是DNS TTL的機制致使你的調度不那麼靈敏和準確。

　　針對這些問題，咱們有兩套系統來解決問題。第一套是Autopatch系統，它解決的是大文件更新下載，另外是多家CDN廠商流量調度。操做流程也比較簡單，由運維人員上傳文件、安檢，而後同步到CDN，CDN分發到相關邊緣節點最後解壓文件。它有一個特色，剛纔說到遊戲的週期性特色，就是平時帶寬不是很大，可是節點的時候，或者是重大活動的時候帶寬比較大。若是本身構建一套CDN系統，可能不是很划算的，因此咱們引入中國比較大型的多家CDN廠商調度資源。
　　咱們的調度是經過302的方法，而不是把域名給其中一家和其中幾家。由於直接使用CNAME的話很難按比例調度，特別是當大帶寬的時候，一家CDN廠商解決不了，或者是一家發生局部故障，你須要快速切除。經過集中的調度系統就能夠實現這樣的功能。全部用戶下來的請求，第一個都是要在咱們這邊進行調度，可是自己並不產生直接下載帶寬，而是經過相關算法，按比例和區域調度給第三方的CDN廠商，而後客戶端，玩家實際地是由第三方CDN廠商節點去下載。

 

　　剛剛講到小運營商或者是某些運營商它的非法緩存機制會對業務形成影響。那麼對於某些關鍵的文件，若是它緩存到是一箇舊版本，那可能會形成很大地問題。好比說咱們的區服列表，若是咱們服務器端增長了新的區服，在客戶端沒有顯現出來，那就致使玩家沒有辦法進入到新的區服去玩。
　　那針對這些問題，咱們設計了內部代號爲Dorado的系統，由於這些文件自己是比較小的，並且數量也不是特別多，可是須要HTTPS去加密，經過加密規避小運營商的緩存問題。因此咱們對於關鍵文件，對於這些文件咱們所有是有自有節點，在節點上是支持HTTPS加密方法，規避小運營商緩存帶來的一些問題。

4.5 自動化服務器端更新系統

　　再來看看服務器端更新。咱們採用的服務器端更新模式也是比較傳統的一種相似於CDN的方式，是由目標服務器經過緩存節點去到**節點下載，由緩存節點緩存控制，這樣能夠減小網間傳輸的量以及提升效率。這裏面有一個小插曲，咱們在設計這套系統的時候，也想過用P2P去作，可是由於在生產裏面，你們想P2P是一個很炫的東西，或者是很節省帶寬的東西，可是用於生產裏面的大文件分發的時候會有幾個問題，一個安全控制的問題，怎樣讓這些服務器之間又能傳數據又能進行安全端口的保護這是很難的問題。
　　另外是怎樣進行流量控制或者是進行流量限定，在P2P裏面也是一個挑戰，因此最終咱們是採用了一個看起來比較簡單的架構去作。

4.6 自動化數據分析系統

　　說到客戶端更新。更新的效果怎樣，或者是玩家這邊到底有沒有安裝成功或者是進入遊戲。不少時候咱們很茫然或者是能夠看日誌，可是日誌裏面的信息不少是不完善和完整的。你下載客戶端的時候，若是看HTTP的日誌的話，裏面是206的代碼，你難以計算出玩家到底完整下載多少客戶端，甚至他有沒有下載下來校驗結果是否正確也是很難知道的。因此咱們最終設計了這樣一個自動化數據分析系統，它的目標就是要看一下用戶從開始下載的過程開始到你一直登陸到遊戲裏面，到底數據是怎樣轉化的。
　　一種最理想的狀況下多是用戶下載之後，他最終就進入了遊戲，可是這是一個理想狀況。不少時候好比說由於他的網絡很差，致使它最終沒有下載成功，或者是一些帳號的問題，最終他沒有登陸到遊戲裏面去。那麼它展示起來的數據形式就是一個漏斗狀的狀況。那麼咱們的目標就是讓最終登陸的用戶，最終要接近於咱們開始下載的用戶量。

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

看一下例子，這是某個遊戲在某個點內發生了不少的安裝失敗的問題。

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

4.7 自動化數據備份系統

提問：正在運營的遊戲，數據忽然沒有了，並且沒有任何備份，你怎麼辦？

　　把葛優大爺請出來了。你們想一想若是某個遊戲在運營的過程當中，數據忽然沒有了，並且沒有備份。有什麼想法？我以爲葛優大爺作到很到位，基本上就是這個感受，基本上你身體都被掏空了，基本上很難辦了。
　　有沒有人想過用一些方法來解決這個問題，有沒有人舉手的，看來你們都只有一個想法打包走人，是嗎？這裏面講一個小故事，遊戲運營初期不少時候是粗放的，並無備份機制。在這種狀況下，某遊戲公司也確實發生過這樣的問題，最後怎樣作的呢？它實際上是作了一個活動，讓玩家過來填本身的帳號信息以及屬性，以及哪些金幣，你填得對的和系統匹配的給你金幣。那個年代的玩家都很純真的，不少人把信息填上去了，咱們就你填什麼就是什麼，這個數據恢復了不少，遊戲也就運營下去了。
　　在這以後，不少玩家看到這樣的演講就不這樣操做了，因此警告你們備份必定要有，並且要保證備份的可恢復性。

　　這是咱們發生嚴重事故的第一個版本的備份系統，它的設計和實現也是比較純樸、樸素的。就是根據不一樣的機房，咱們會有一臺FTP的服務器，而後本機房的寫入FTP服務器，而後寫入磁帶，這樣會致使你的磁帶是分散的，沒有集中存放的地方。而後基於FTP的上傳是會有帶寬甚至是有延遲的要求。

後來咱們設計了這樣一個集中的備份系統。這樣的話，它主要是解決幾個問題。
　　第一個咱們全部機房所有配置一個負載均衡器的IP就能夠了，當客戶端須要上傳文件，經過負載均衡器獲取實際上傳的地址，而後把文件上傳，由左邊第二個框裏面的服務器進行接收，而且根據MD5值進行校驗，若是校驗沒有問題，轉到Hadoop的HDFS集羣裏面去，目前這個集羣有數十PB的規模，天天上傳量有幾個T。
　　你們會想一個問題，在中國這樣一個對於運維人員來講網絡要求很高的狀況下，甚至是運營商之間的這種隔閡甚至是一些壁壘，致使網絡不穩定、丟包、延遲的問題是怎樣解決的呢？若是在大文件傳輸過程當中，你是基於TCP作的，涉及到單個鏈接上帶寬延時積的理論上的限制。這裏咱們創新的是，咱們客戶端上傳是走UDP的協議，UDP自己沒有任何控制，說白了就是客戶端能夠任意、使勁地發就能夠了。
　　那麼最終會由服務器端檢查你哪些文件片斷收到了，而後通知客戶端補傳一些沒上傳的就能夠了。基於這種方式就能規避不少由於網絡抖動甚至是網絡延遲比較大致使的問題。固然你也能夠在客戶端作流量的控制也是能夠的。你們之後在遇到問題的時候，可能想想有一些不走尋常路的解決方案，也是可能存在的。

4.8 自動化監控報警系統

 

　　再看一下咱們遊戲的監控體系，剛剛說到遊戲的架構決定了有遊戲客戶端、有服務器端，有網絡鏈路，因此你必需要有一個按比較完整的體系去進行全方位、立體式的這樣一個監控，才能保證業務在發生問題以前進行預警，或者是發生問題時報警。
對於機房鏈路方面，咱們是有IDC的網絡質量監控去作。在服務器網絡設備和硬件方面，會有服務器的健康檢查、性能監控以及網絡設備和流量監控。在系統程序方面，咱們會進行系統日誌的收集和分析，在遊戲服務器端應用方面，會有服務器端的程序監控。在客戶端方面，會有植入的SDK進行下載更新效果的收集，以及它崩潰的數據收集。
　　你們看一下左邊這一列，爲何標紅色，是我想強調它的重要性。咱們運維考慮問題或者是設計架構的時候，咱們的視角不只僅侷限於一個技術方面，或者是想技術怎樣炫酷、多麼牛，咱們要想一想技術在業務方面的架構。或者是可否經過業務指標監控咱們的運維能力、運維繫統。
　　在遊戲裏面有一個指標很重要的，就是在線人數，經過監控在線人數這樣一個業務指標，就能夠知道我左邊的系統是否工做正常，是否是有漏報、誤報的狀況，由於不少時候你任何一個環節出了問題。
　　最終表現的問題都是在業務方面，都是在產生價值的數據方面，因此咱們會有一套人數監控的系統，每一個遊戲上線以前會接入系統裏面去，把時時在線的人數聚集到系統裏面，若是發生異常的抖動等狀況都會顯示在裏面，也就能夠告訴你是否發生了問題。

 

這是一個框架，那咱們看一下細節的，關於服務器的監控咱們是怎樣作的。
　　架構是這樣的，首先由運維工程師來配置監控策略，到監控策略平臺裏面去，監控策略平臺會根據這些數據，將這些數據進行格式化，格式化成相關格式，而後**給剛剛在第三頁PPT講到的自動化運維平臺，自動化運維平臺會監控是外部來的，仍是遠程檢測，仍是網絡模擬仍是本地的監控進行的。
　　好比說流量、本地進程的監控、本地日誌的監控，它分別推給遠程探測服務器，或者是遊戲服務器自己。而後由它們進行數據上報，數據上報之後根據運維工程師配置的閾值，會觸發相關的報警，而後通知運維工程師進行相關處理。由於雖然遊戲是多種多樣的，操做系統是多種多樣的，或者是操做系統是五花八門的，可是總有一些能夠你們公用的東西。
　　你們能夠認爲是監控的模板或者是監控的策略，咱們對服務器的東西也進行了整合彙總。你們能夠看到咱們裏面有很豐富的插件，運維人員只要個選擇相關的插件，把閾值配一下，把時間配一下，就能夠節省每一個人的時間和學**的成本，提升你配置策略的效率。
　　當配置策略完成之後，你直接綁定到你想要監控的服務器上就能夠了。

五、總結

構建自動化體系的三個建議

• 按部就班
• 以實用爲目的
• 考慮可擴展性

　咱們從2000年初到如今，一直在作自動化運維體系，這麼多年以來咱們也想也在考慮一個問題，對咱們過去進行總結，我以爲是有3個方面能夠給到你們建議。
　　第一個是一個按部就班的原則，特別是中小公司或者是初創公司，不少時候咱們並不須要一個高大上、白富美的系統，你可能須要聚焦當前的問題，把當前的問題處理好、處理完美了，後面的問題也是一個迎刃而解的狀況。若是你開始設計的系統很龐大、功能特別豐富，就會致使一些沒法控制的局面。
好比說這個系統可能最後作不下去了，或者是由於耦合性太強，開發控制不了了，或者是項目費擱淺了也是有可能的。
可是若是開始的目標是解決一些特定的問題，有一些針對性的，推動起來也是比較簡單的。
另外是考慮可擴展性，咱們設計系統的時候，功能或者是設計方面你可能不用考慮那麼多，可是針對當前的問題你要考慮你的服務器，當發生一些比較大的擴張的時候，是否還能支撐它們，好比說數量級從十到一百、一千了，是否仍是可用的，這也是要考慮的問題，就是要考慮可擴展性。
　　另外是以實用爲目的，這在咱們系統也是有體現的，不少狀況下，市面上可能有一些比較成熟的協議和工具作這個東西，咱們只是須要經過相關的評估認爲它在生產裏面可用，不少時候不必本身再去作一套。
你再作一套不少時候沒有通過驗證的，可能會帶來安全的問題。基於成熟的協議和框架去作，而不是本身再造輪子，不少時候是能夠提高你的效率，保證你的穩定性和安全性。
Q & A
Q：
　　我想問一下對於數據服務器傳輸，你是說新的架構採用UDP傳輸的方式。我想問一下具體用什麼軟件，由於這種架構可能要兩個中起色，一邊發一邊收，可能還存在不穩定的因素。您可能用這個技術比較成熟了，我想聽聽總體架構的基礎方案。
A：
　　這位同窗提的問題很是棒，可能這一點也是分享裏面比較有價值的思路。由於UDP自己的設計初衷並非被用於傳文件，只是進行不可靠消息傳送，好比說DNS裏面廣泛使用UDP。原本不是用於傳文件，固然咱們將它用於傳文件就要考慮剛纔這位同窗所說的問題。
這裏面咱們這個工具是自研的，市面上這個工具並不太多，市場上也有一些商業的產品，美國有一家公司好像是被IBM收購了，蠻貴的。這個實現起來並不困難，UDP沒有一些鏈路檢測的機制，不少東西實際上是在服務器端控制。
打個形象比喻，好比說客戶端把這個文件Seek到某個位置裏面去傳就能夠了。那服務器端根據收到的文件它最終會進行一個組合，這個和HTTP Range請求的思路相反。
服務器會看0—100兆文件裏面我收到了哪些，哪些是錯誤的，這個時候再通知客戶端補傳就能夠了，最終服務器端和客戶端進行校驗，就能夠確保你是否徹底OK了。這個應該本身作也不是特別複雜的事情。

出處：http://www.cnblogs.com/madsnotes/

聲明：本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接。