1、演講內容划分
第一個方面是我們來看一下，為什么要做自動化運維體系，就是解決“3W”里面的為什么以及是什么，Why和What的問題。
第二個方面是我們看一下，目前盛大游戲各個運維子系統是怎樣工作的，是怎樣設計、運行和處理問題的，解決“3W”里面的How的問題，怎樣去做的。
第三個是對我們盛大游戲在自動化運維過程中遇到的一些問題的一些思考，做一個總結。
2、自動化運維體系簡介
首先來看一下我們為什么要做一個自動化運維體系。首先來看一下運維遇到的一些挑戰，第一個游戲的需求。它表現為三個方面。大家知道盛大游戲是比較知名的老牌游戲廠商。那它現在運營的游戲多達數百款。第二個游戲架構復雜。
游戲公司和一般的互聯網公司有一個很大的區別，就是游戲來源可能是很多，比如說有國外的、國內的，有大廠商、有小廠商的。每個游戲的架構可能是不一樣的，有的是分區制的，有的是大區制，各種各樣的需求。
另外一個是操作系統種類多，這與剛才的緣由類似，開發者的背景與編程喜好不一樣，會有Windows、Linux等。第二個是在硬件環境，主要表現為服務器數量多、服務器型號多。因為公司建立到現在十幾年的時間了，在這個過程中分批、分期采購的服務器幾乎橫跨各大OEM廠商的各大產品線，型號是比較多和雜的。
另外是人的因素，我們在建設自動化運維體系過程中個一個比較重要的考慮點是人的因素，如果大家都是很牛的人，很多時候一個人可以完成所有工作的情況下，可能你也不需要自動化運維體系了。正是因為我們每個人員的能力不一樣，技術水平參差不齊，甚至是運維**慣也不一樣，導致我們必須要創建一套規范的自動化運維體系，來提升我們的工作效率。
3、自動化運維體系簡介
再看一下我們建設這套自動化運維體系的目標，也就是說我們的原則是什么？我覺得做任何一件事情，目標和原則都是非常重要的。
我對自動化運維體系的建設目標這塊，總結為四個詞：
- 第一是"完備"，你這個系統要能涵蓋所有的運維需求；
- 第二個是"簡潔"，簡單好用，如果系統的操作流程和操作界面、設計思想都比較復雜，那運維人員使用起來是打折扣的，那系統的能力、發揮的效率也會因此打折扣；
- 第三個是"高效"，特別是在批量處理或者是進行特定任務時，系統能夠及時給用戶反饋；
- 第四個是"安全"，如果一個系統不安全，那么就可能導致做了以后很快就被人接管了。所以安全也是重要的因素。
4、運維子系統詳解
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講到的自動化運維平台，自動化運維平台會監控是外部來的，還是遠程檢測，還是網絡模擬還是本地的監控進行的。
比如說流量、本地進程的監控、本地日志的監控，它分別推給遠程探測服務器，或者是游戲服務器本身。然后由它們進行數據上報，數據上報以后根據運維工程師配置的閾值，會觸發相關的報警，然后通知運維工程師進行相關處理。因為雖然游戲是多種多樣的，操作系統是多種多樣的，或者是操作系統是五花八門的，但是總有一些可以大家公用的東西。
大家可以認為是監控的模板或者是監控的策略，我們對服務器的東西也進行了整合匯總。大家可以看到我們里面有很豐富的插件，運維人員只要個選擇相關的插件，把閾值配一下，把時間配一下，就可以節省每個人的時間和學**的成本，提高你配置策略的效率。
當配置策略完成以后，你直接綁定到你想要監控的服務器上就可以了。
5、總結
構建自動化體系的三個建議
- 循序漸進
- 以實用為目的
- 考慮可擴展性
我們從2000年初到現在，一直在做自動化運維體系，這么多年以來我們也想也在考慮一個問題，對我們過去進行總結，我覺得是有3個方面可以給到大家建議。
第一個是一個循序漸進的原則，特別是中小公司或者是初創公司，很多時候我們並不需要一個高大上、白富美的系統，你可能需要聚焦當前的問題，把當前的問題處理好、處理完美了，后面的問題也是一個迎刃而解的情況。如果你開始設計的系統很龐大、功能特別豐富，就會導致一些無法控制的局面。
比如說這個系統可能最后做不下去了，或者是因為耦合性太強，開發控制不了了，或者是項目費擱淺了也是有可能的。
但是如果開始的目標是解決一些特定的問題，有一些針對性的，推進起來也是比較簡單的。
另外是考慮可擴展性，我們設計系統的時候，功能或者是設計方面你可能不用考慮那么多，但是針對當前的問題你要考慮你的服務器，當發生一些比較大的擴張的時候，是否還能支撐它們，比如說數量級從十到一百、一千了，是否還是可用的，這也是要考慮的問題，就是要考慮可擴展性。
另外是以實用為目的，這在我們系統也是有體現的，很多情況下，市面上可能有一些比較成熟的協議和工具做這個東西，我們只是需要通過相關的評估認為它在生產里面可用，很多時候沒必要自己再去做一套。
你再做一套很多時候沒有經過驗證的，可能會帶來安全的問題。基於成熟的協議和框架去做，而不是自己再造輪子，很多時候是可以提升你的效率，保證你的穩定性和安全性。
Q & A
Q：
我想問一下對於數據服務器傳輸，你是說新的架構采用UDP傳輸的方式。我想問一下具體用什么軟件，因為這種架構可能要兩個中轉機，一邊發一邊收，可能還存在不穩定的因素。您可能用這個技術比較成熟了，我想聽聽整體架構的基礎方案。
A：
這位同學提的問題非常棒，可能這一點也是分享里面比較有價值的思路。因為UDP本身的設計初衷並不是被用於傳文件，只是進行不可靠消息傳送，比如說DNS里面普遍使用UDP。本來不是用於傳文件，當然我們將它用於傳文件就要考慮剛才這位同學所說的問題。
這里面我們這個工具是自研的，市面上這個工具並不太多，市場上也有一些商業的產品，美國有一家公司好像是被IBM收購了，蠻貴的。這個實現起來並不困難，UDP沒有一些鏈路檢測的機制，很多東西其實是在服務器端控制。
打個形象比喻，比如說客戶端把這個文件Seek到某個位置里面去傳就可以了。那服務器端根據收到的文件它最終會進行一個組合，這個和HTTP Range請求的思路相反。
服務器會看0—100兆文件里面我收到了哪些，哪些是錯誤的，這個時候再通知客戶端補傳就可以了，最終服務器端和客戶端進行校驗，就可以確保你是否完全OK了。這個應該自己做也不是特別復雜的事情。