基于AIOps理念研發(fā)的新一代運(yùn)維監(jiān)大屏 全盤展示IT運(yùn)行狀態(tài)，減輕運(yùn)維人員的重復(fù)性工作量，提高IT系統(tǒng)排錯(cuò)速度，加速運(yùn)維知識(shí)學(xué)習(xí)積累。
DevOps的出現(xiàn)有其必然性。在軟件開發(fā)生命周期中，遇到了兩次瓶頸。第一次瓶頸是在需求階段和開發(fā)階段之間，針對(duì)不斷變化的需求，對(duì)軟件開發(fā)者提出了高要求，后來(lái)出現(xiàn)了敏捷方法論，強(qiáng)調(diào)適應(yīng)需求、快速迭代、持續(xù)交付。第二個(gè)瓶頸是在開發(fā)階段和構(gòu)建部署階段之間，大量完成的開發(fā)任務(wù)可能阻塞在部署階段，影響交付，于是有了DevOps。
DevOps的三大原則：
1、基礎(chǔ)設(shè)施即代碼（Infrastructure as Code） DeveOps的基礎(chǔ)是將重復(fù)的事情使用自動(dòng)化腳本或軟件來(lái)實(shí)現(xiàn)，例如Docker（容器化）、Jenkins（持續(xù)集成）、Puppet（基礎(chǔ)架構(gòu)構(gòu)建）、Vagrant（虛擬化平臺(tái)）等
2、持續(xù)交付（Continuous Delivery）** 持續(xù)交付是在生產(chǎn)環(huán)境發(fā)布可靠的軟件并交付給用戶使用。而持續(xù)部署則不一定交付給用戶使用。涉及到2個(gè)時(shí)間，TTR（Time to Repair）修復(fù)時(shí)間，TTM（Time To Marketing）產(chǎn)品上線時(shí)間。要做到高效交付可靠的軟件，需要盡可能的減少這2個(gè)時(shí)間。部署可以有多種方式，比如藍(lán)綠部署、金絲雀部署等。
3、協(xié)同工作（Culture of Collaboration）開發(fā)者和運(yùn)維人員必須定期進(jìn)行密切的合作。開發(fā)應(yīng)該把運(yùn)維角色理解成軟件的另一個(gè)用戶群體。協(xié)作有幾個(gè)的建議：1、自動(dòng)化（減少不必要的協(xié)作）；2、小范圍（每次修改的內(nèi)容不宜過多，減少發(fā)布的風(fēng)險(xiǎn)）；3、統(tǒng)一信息集散地（如wiki，讓雙方能夠共享信息）；4、標(biāo)準(zhǔn)化協(xié)作工具（比如jenkins）
附上DevOps的定義： DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例**。透過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。
對(duì)自動(dòng)化運(yùn)維體系的需求，是隨著業(yè)務(wù)的增長(zhǎng)、對(duì)運(yùn)維效率和質(zhì)量的要求不斷提高而產(chǎn)生的。
在很多初創(chuàng)公司和中小型企業(yè)里，運(yùn)維還停留在“刀耕火種”的原始狀態(tài)，這里所說的“刀”和“火”就是運(yùn)維人員的遠(yuǎn)程客戶端，例如SecureCRT和windows遠(yuǎn)程桌面。
在這種工作方式下，服務(wù)器的安裝、初始化，軟件部署、服務(wù)發(fā)布和監(jiān)控都是通過手動(dòng)方式來(lái)完成的，需要運(yùn)維人員登錄到服務(wù)器上，一臺(tái)一臺(tái)去管理和維護(hù)。這種非并發(fā)的線性工作方式是制約效率的最大障礙。
同時(shí)，因?yàn)槭謩?dòng)的操作方式過于依賴運(yùn)維人員的執(zhí)行順序和操作步驟，稍有不慎即可能導(dǎo)致服務(wù)器配置不一致，也就是同一組服務(wù)器的配置上出現(xiàn)差異。有時(shí)候，這種差異是很難直接檢查出來(lái)的，例如在一個(gè)負(fù)載均衡組里面?zhèn)€別服務(wù)器的異常就很難發(fā)現(xiàn)。
隨著業(yè)務(wù)的發(fā)展，服務(wù)器數(shù)量越來(lái)越多，運(yùn)維人員開始轉(zhuǎn)向使用腳本和批量管理工具。腳本和批量管理工具與“刀耕火種”的工作方式相比，確實(shí)提升了效率和工程質(zhì)量。
但這個(gè)方式仍然有很多問題。
第一是腳本的非標(biāo)準(zhǔn)化的問題。不同運(yùn)維人員寫的腳本在所用的編程語(yǔ)言、編碼風(fēng)格和健壯性方面存在巨大差異，同時(shí)這些腳本的版本管理也是一個(gè)挑戰(zhàn)。
第二是腳本的傳承問題，人員的離職和工作交接，都會(huì)導(dǎo)致腳本無(wú)法很好地在運(yùn)維人員之間傳承和再利用，因?yàn)橄乱粋€(gè)運(yùn)維人員可能無(wú)法理解和修改前一個(gè)運(yùn)維人員編寫的腳本功能。
第三是批量管理工具的選擇。不同的管理人員選擇不同的批量管理工具必然會(huì)帶來(lái)管理混亂的問題，也無(wú)法很好地實(shí)現(xiàn)在運(yùn)維人員之間互相備份工作的需求。
因此，對(duì)構(gòu)建自動(dòng)化運(yùn)維體系的要求變得越來(lái)越迫切。通過自動(dòng)化運(yùn)維體系來(lái)實(shí)現(xiàn)標(biāo)準(zhǔn)化和提高工程效率，是唯一正確的選擇。那么如何建設(shè)自動(dòng)化運(yùn)維體系呢？
本案例研究分為三個(gè)大的方面：
第一個(gè)是為什么要建設(shè)自動(dòng)化運(yùn)維體系，就是解決“3W”中的Why和What的問題，即為什么和是什么。
第二個(gè)是介紹我司各個(gè)運(yùn)維子系統(tǒng)是怎樣設(shè)計(jì)、運(yùn)行和處理問題的，解決“3W”中的How的問題，也就是怎樣去做的。
第三個(gè)是對(duì)我司在自動(dòng)化運(yùn)維過程中遇到的一些問題的思考，做一個(gè)總結(jié)。
一、建設(shè)自動(dòng)化運(yùn)維體系的原因
先來(lái)看一下我們?yōu)槭裁匆ㄔO(shè)一個(gè)自動(dòng)化運(yùn)維體系。首先來(lái)看運(yùn)維遇到的一些挑戰(zhàn)，如下圖所示。
運(yùn)維面對(duì)的挑戰(zhàn)
第一個(gè)是游戲的需求。它表現(xiàn)為三個(gè)方面:
一是游戲數(shù)量多，我司現(xiàn)在運(yùn)營(yíng)的游戲多達(dá)近百款。
二是游戲架構(gòu)復(fù)雜。游戲公司和一般的互聯(lián)網(wǎng)公司有一個(gè)很大的區(qū)別，就是游戲的來(lái)源可能有很多，比如有國(guó)外的、國(guó)內(nèi)的，有大廠商的、小廠商的；每個(gè)游戲的架構(gòu)可能不一樣，有的是分區(qū)制的，有的是集中制的，各種各樣的需求。
三是操作系統(tǒng)種類多，這與剛才的情況類似，游戲開發(fā)者的背景與編程喜好不一樣，會(huì)有Windows、linux等。
第二個(gè)是在硬件環(huán)境方面，主要表現(xiàn)為服務(wù)器數(shù)量多、服務(wù)器型號(hào)多。因?yàn)楣緩慕⒌浆F(xiàn)在有十幾年的時(shí)間了，在這個(gè)過程中分批、分期采購(gòu)的服務(wù)器幾乎橫跨各大OEM廠商的各大產(chǎn)品線，型號(hào)多而雜。
最后是人的因素。我們?cè)诮ㄔO(shè)自動(dòng)化運(yùn)維體系過程中，有一個(gè)比較重要的考慮點(diǎn)是人的因素。如果大家的技術(shù)能力都很強(qiáng)，很多時(shí)候一個(gè)人可以完成所有工作，可能也就不需要自動(dòng)化運(yùn)維體系了。正是因?yàn)槊總€(gè)運(yùn)維人員的能力不一樣，技術(shù)水平參差不齊，甚至是運(yùn)維習(xí)慣和工具也不一樣，導(dǎo)致我們必須要?jiǎng)?chuàng)建一套規(guī)范的自動(dòng)化運(yùn)維體系，來(lái)提升工作效率。
二、建設(shè)自動(dòng)化運(yùn)維體系的目標(biāo)
再看一下建設(shè)這套自動(dòng)化運(yùn)維體系的目標(biāo)，也就是說我們的原則是什么？筆者將自動(dòng)化運(yùn)維體系的建設(shè)目標(biāo)總結(jié)為四個(gè)詞。
第一個(gè)是“完備”，這個(gè)系統(tǒng)要能涵蓋所有的運(yùn)維需求。
第二個(gè)是“簡(jiǎn)潔”，簡(jiǎn)單好用。如果系統(tǒng)的操作流程、操作界面、設(shè)計(jì)思想都比較復(fù)雜，運(yùn)維人員的學(xué)習(xí)成本就會(huì)很高，使用的效果是會(huì)打折扣的，系統(tǒng)的能力、發(fā)揮的效率也會(huì)因此打折扣。
第三個(gè)是“高效”，特別是在批量處理或者執(zhí)行特定任務(wù)時(shí)，我們希望系統(tǒng)能夠及時(shí)給用戶反饋。
第四個(gè)是“安全”，如果一個(gè)系統(tǒng)不安全，可能導(dǎo)致很快就被黑客接管了。所以安全也是重要的因素。
三、自動(dòng)化運(yùn)維體系的結(jié)構(gòu)和運(yùn)作方式
下圖所示是我司當(dāng)前自動(dòng)化運(yùn)維體系的幾個(gè)子系統(tǒng)，我們來(lái)看一看它們是怎樣聯(lián)合起來(lái)工作的。首先服務(wù)器會(huì)經(jīng)由自動(dòng)化安裝系統(tǒng)完成安裝，然后會(huì)被自動(dòng)化運(yùn)維平臺(tái)接管。自動(dòng)化運(yùn)維平臺(tái)會(huì)對(duì)自動(dòng)化安檢系統(tǒng)、自動(dòng)化客戶端更新系統(tǒng)和服務(wù)器端更新系統(tǒng)提供底層支撐。自動(dòng)化數(shù)據(jù)分析系統(tǒng)和自動(dòng)化客戶端更新系統(tǒng)會(huì)有關(guān)聯(lián)關(guān)系。自動(dòng)化數(shù)據(jù)分析系統(tǒng)會(huì)對(duì)自動(dòng)化客戶端更新系統(tǒng)的結(jié)果給予反饋。
自動(dòng)化運(yùn)維體系結(jié)構(gòu)圖
下面我們來(lái)看一下每個(gè)子系統(tǒng)是如何設(shè)計(jì)和工作的。
3.1、自動(dòng)化安裝系統(tǒng)
說到自動(dòng)化安裝，大家可能并不陌生，我們剛才說到挑戰(zhàn)是“兩多兩少”，型號(hào)多、操作系統(tǒng)多，但是人少，可用時(shí)間也比較少。
如下圖所示，整個(gè)流程采用通用的框架，首先由PXE啟動(dòng)，選擇需要安裝的操作系統(tǒng)類型（安裝Windows或者Linux），然后根據(jù)Windows系統(tǒng)自動(dòng)識(shí)別出需要安裝的驅(qū)動(dòng)。服務(wù)器交付用戶之前，會(huì)進(jìn)行基本的安全設(shè)置，例如防火墻設(shè)置以及關(guān)閉Windows共享，這在一定程度上提高了安全性，也減少了需要人工做的一些操作。
自動(dòng)化安裝流程圖
3.2、自動(dòng)化運(yùn)維平臺(tái)
當(dāng)服務(wù)器由自動(dòng)化安裝系統(tǒng)安裝完成以后，就會(huì)被自動(dòng)化運(yùn)維平臺(tái)接管。自動(dòng)化運(yùn)維平臺(tái)是運(yùn)維人員的作業(yè)平臺(tái)，它主要解決的問題就是因服務(wù)器、操作系統(tǒng)異構(gòu)而且數(shù)量特別多而帶來(lái)的管理問題。操作系統(tǒng)是五花八門的，我們?cè)谠O(shè)計(jì)系統(tǒng)過程中考慮了以下幾個(gè)因素：
把整個(gè)系統(tǒng)的用戶界面設(shè)計(jì)成基于瀏覽器的架構(gòu)。運(yùn)維工程師無(wú)論何時(shí)何地都可以登錄管理系統(tǒng)進(jìn)行運(yùn)維操作，這樣的話就比較方便。由Octopod服務(wù)器對(duì)被操作的機(jī)器發(fā)布指令。
統(tǒng)一管理異構(gòu)服務(wù)器。大家以前可能對(duì)Windows深惡痛絕，其實(shí)Windows也可以管得很好。我們使用開源的SSH方式管理Windows，這樣就可以對(duì)系統(tǒng)進(jìn)行批量的補(bǔ)丁更新，還可以做批量的密碼管理和操作。
充分利用現(xiàn)有協(xié)議和工具。這個(gè)平臺(tái)的特點(diǎn)是所有的系統(tǒng)使用SSH管理，而不是自己開發(fā)一些Agent，這也體現(xiàn)了自動(dòng)化運(yùn)維的觀點(diǎn)。很多時(shí)候我們沒必要重新造輪子，即使自己造出一套客戶端的方法，大部分時(shí)候也并沒有在生產(chǎn)環(huán)境里得到嚴(yán)格的驗(yàn)證。而SSH協(xié)議本身已經(jīng)存在很多年了，而且已經(jīng)在我司使用了很多年，該出的問題已經(jīng)出了，相對(duì)于造輪子，使用SSH更加穩(wěn)定，更經(jīng)得起考驗(yàn)，使用起來(lái)更方便。
3.3、自動(dòng)化安檢系統(tǒng)
下一個(gè)系統(tǒng)是自動(dòng)化安檢系統(tǒng)。由于我們的子系統(tǒng)比較多，業(yè)務(wù)也比較多，怎樣設(shè)計(jì)一套系統(tǒng)去保障它們的安全呢？這里主要是兩個(gè)系統(tǒng)：自動(dòng)化安檢平臺(tái)和服務(wù)器端。
先來(lái)看自動(dòng)化安檢平臺(tái)。游戲公司和一般的互聯(lián)網(wǎng)公司有一個(gè)區(qū)別，就是前者需要給玩家發(fā)送很多的客戶端（特別是有的客戶端比較大），或者補(bǔ)丁文件，去更新、下載和安裝。如果這些文件里面出現(xiàn)病毒和木馬，將是一件很糟糕的事情，甚至?xí)?duì)業(yè)務(wù)和公司的聲譽(yù)造成惡劣影響。當(dāng)這些文件被發(fā)到玩家電腦上之前，必須經(jīng)過病毒檢測(cè)系統(tǒng)檢測(cè)，確保它沒有被注入相應(yīng)的病毒代碼。
再來(lái)看服務(wù)器端，主要是通過安全掃描架構(gòu)來(lái)保障安全。安全并不是一蹴而就，一勞永逸的。如果不對(duì)系統(tǒng)持續(xù)地檢查、檢測(cè)、探測(cè)，那么你的一些誤操作會(huì)導(dǎo)致系統(tǒng)暴露在互聯(lián)網(wǎng)上，或者是暴露在惡意攻擊者的眼皮之下。通過一種主動(dòng)、自發(fā)的安全掃描架構(gòu)對(duì)所有服務(wù)器進(jìn)行安全掃描，就能在很大程度上規(guī)避這樣的問題。舉一個(gè)例子，去年我們遇到過一個(gè)情況，某款交換機(jī)ACL達(dá)到一定的數(shù)量的時(shí)候，就完全失效了。如果沒有相關(guān)的配套機(jī)制去檢查和檢測(cè)，那么你的服務(wù)器、你認(rèn)為保護(hù)得很好的端口或者是敏感的IP可能已經(jīng)暴露。所以，通過這種主動(dòng)的探測(cè)可以減少很多系統(tǒng)的或者是人為的安全問題。
3.4、自動(dòng)化客戶端更新系統(tǒng)
游戲是有周期性的，特別是在游戲發(fā)布當(dāng)天或者有版本更新的時(shí)候，這時(shí)候玩家活躍度很高，下載行為也是比較多的，但是平時(shí)的更新和下載帶寬可能并不大，這也是游戲很顯著的特點(diǎn)。這個(gè)特點(diǎn)對(duì)于我們構(gòu)建這樣一個(gè)分發(fā)系統(tǒng)提出了很大的挑戰(zhàn)。第一個(gè)挑戰(zhàn)就是在高峰時(shí)游戲產(chǎn)生的帶寬可能達(dá)到數(shù)百GB。第二是很多小運(yùn)營(yíng)商或者中小規(guī)模的運(yùn)營(yíng)商會(huì)有一些緩存機(jī)制，這個(gè)緩存機(jī)制如果處理得不好，會(huì)對(duì)業(yè)務(wù)造成影響，也就是非法緩存的問題。第三是關(guān)于DNS調(diào)度的問題。DNS調(diào)度本身是基于玩家本身的Local DNS的機(jī)制解析的，會(huì)有調(diào)度不準(zhǔn)確的問題。第四是DNS污染，或者是DNS TTL的機(jī)制導(dǎo)致調(diào)度不那么靈敏和準(zhǔn)確。針對(duì)這些問題，我們有下面兩套系統(tǒng)來(lái)解決。
第一套是Autopatch系統(tǒng)，它解決的是大文件更新的下載問題，再就是多家CDN廠商流量調(diào)度。其操作流程也比較簡(jiǎn)單，由運(yùn)維人員上傳文件、安檢，然后同步到CDN，由CDN分發(fā)到相關(guān)邊緣節(jié)點(diǎn)，最后解壓文件。剛才說到游戲的周期性特點(diǎn)，就是平時(shí)帶寬不是很大，但是在某個(gè)節(jié)點(diǎn)的時(shí)候，或者是重大活動(dòng)的時(shí)候，帶寬比較大。如果自己構(gòu)建一套CDN系統(tǒng)，可能不是很劃算，所以我們引入國(guó)內(nèi)多家比較大型的CDN廠商調(diào)度資源。我們通過302的方法調(diào)度，而不是把域名給其中一家或幾家。因?yàn)橹苯邮褂肅NAME的話很難按比例調(diào)度，特別是帶寬大的時(shí)候，一家CDN廠商解決不了，或者是一家發(fā)生局部故障，需要快速切除。而通過集中的調(diào)度系統(tǒng)就可以實(shí)現(xiàn)按比例調(diào)度的功能。用戶發(fā)過來(lái)的所有請(qǐng)求，首先要在我們這邊進(jìn)行調(diào)度，但是本身并不產(chǎn)生直接下載帶寬，而是通過相關(guān)算法，按比例和區(qū)域調(diào)度給第三方的CDN廠商，然后玩家實(shí)際是由第三方CDN廠商節(jié)點(diǎn)去下載客戶端的。
第二套是Dorado系統(tǒng)。剛剛講到小運(yùn)營(yíng)商或者某些運(yùn)營(yíng)商的非法緩存機(jī)制會(huì)對(duì)業(yè)務(wù)造成影響，那么對(duì)于某些關(guān)鍵的文件，如果緩存的是一個(gè)舊版本，可能會(huì)造成很大的問題。比如我們的區(qū)服列表，如果我們服務(wù)器端增加了新的區(qū)服，在客戶端沒有顯現(xiàn)出來(lái)，就導(dǎo)致玩家沒有辦法進(jìn)入到新的區(qū)服去玩。針對(duì)這些問題，我們?cè)O(shè)計(jì)了內(nèi)部代號(hào)為Dorado的系統(tǒng)，因?yàn)檫@些文件本身是比較小的，而且數(shù)量也不是特別多，但是需要用HTTPS加密，通過加密規(guī)避小運(yùn)營(yíng)商的緩存問題。所以我們對(duì)于這些關(guān)鍵文件，全部有自有節(jié)點(diǎn)，在節(jié)點(diǎn)上支持HTTPS加密方法，規(guī)避小運(yùn)營(yíng)商緩存帶來(lái)的一些問題。
3.5、自動(dòng)化服務(wù)器端更新系統(tǒng)
我們采用的服務(wù)器端更新模式也是一種比較傳統(tǒng)的類似于CDN的方式，是由目標(biāo)服務(wù)器通過緩存節(jié)點(diǎn)到中央節(jié)點(diǎn)下載，由緩存節(jié)點(diǎn)緩存控制，這樣可以減少網(wǎng)間傳輸?shù)臄?shù)據(jù)量以及提高效率。我們?cè)谠O(shè)計(jì)這套系統(tǒng)的時(shí)候，也想過用P2P去做。大家想P2P是很炫，又節(jié)省帶寬，但是用于生產(chǎn)環(huán)境中大文件分發(fā)的時(shí)候會(huì)有幾個(gè)問題。一是安全控制的問題，很難讓這些服務(wù)器之間又能傳數(shù)據(jù)又能進(jìn)行安全端口的保護(hù)。二是在P2P里做流量控制或者流量限定也是一個(gè)挑戰(zhàn)。所以最終我們采用了一個(gè)看起來(lái)比較簡(jiǎn)單的架構(gòu)。
3.6、自動(dòng)化數(shù)據(jù)分析系統(tǒng)
說到客戶端更新，其實(shí)更新的效果如何，玩家到底有沒有安裝成功或者進(jìn)入游戲，很多時(shí)候我們也很茫然，只能看日志。但是日志里面的很多信息是不完善和不完整的。下載客戶端的時(shí)候，如果看HTTP的日志的話，里面是206的代碼，很難計(jì)算出玩家到底完整下載了多少客戶端，甚至他有沒有下載下來(lái)，校驗(yàn)結(jié)果是否正確，也很難知道。所以我們最終設(shè)計(jì)了一個(gè)自動(dòng)化數(shù)據(jù)分析系統(tǒng)，目標(biāo)就是分析從用戶開始下載到他登錄游戲，數(shù)據(jù)到底是怎樣轉(zhuǎn)化的。最理想的一種情況是用戶下載客戶端以后，就進(jìn)入了游戲，但這是一個(gè)理想情況。很多時(shí)候，比如因?yàn)榫W(wǎng)絡(luò)不好，導(dǎo)致用戶最終沒有下載成功，或者是因?yàn)橘~號(hào)的一些問題，用戶最終沒有登錄到游戲里面去。所以，展現(xiàn)出來(lái)的數(shù)據(jù)就是一個(gè)漏斗狀。我們的目標(biāo)就是讓最終登錄的用戶數(shù)接近于起初下載客戶端的用戶數(shù)。
我們來(lái)看一下系統(tǒng)的架構(gòu)。首先由玩家這邊的下載器或者是安裝客戶端，游戲客戶端里面集成一些SDK，對(duì)于任何一個(gè)關(guān)鍵點(diǎn)，比如“下載”按鈕或者“終止”按鈕的數(shù)據(jù)都上報(bào)，當(dāng)然這里面不會(huì)涉及敏感信息。上報(bào)以后會(huì)有Tomcat集群，集群處理以后會(huì)將數(shù)據(jù)寫入MongoDB。
看一下這個(gè)游戲在引導(dǎo)過程中有什么問題，左邊的這一列它分為三個(gè)文件，有一個(gè)是3MB，有兩個(gè)是2G多的文件，其實(shí)大家可以想像一下。很多時(shí)候玩家看到小的文件就把小的文件直接下載安裝了，但是實(shí)際上并不完整。這一點(diǎn)也告訴我們，其實(shí)很多時(shí)候在運(yùn)營(yíng)或者是業(yè)務(wù)方面，在引導(dǎo)方面也是要比較合理才能去規(guī)避掉一些問題。
3.7、自動(dòng)化數(shù)據(jù)備份系統(tǒng)
我們第一個(gè)版本的備份系統(tǒng)，它的設(shè)計(jì)和實(shí)現(xiàn)是比較簡(jiǎn)單的：不同的機(jī)房會(huì)有一臺(tái)FTP服務(wù)器，本機(jī)房的數(shù)據(jù)寫入FTP服務(wù)器，然后寫入磁帶，但是這樣就導(dǎo)致磁帶是分散的，沒有集中存放的地方；另外，基于FTP的上傳會(huì)有帶寬甚至有延遲的要求。
后來(lái)我們?cè)O(shè)計(jì)了一個(gè)集中的備份系統(tǒng)。它主要解決了以下兩個(gè)問題。
第一是簡(jiǎn)化配置。我們所有機(jī)房的全部配置，用一個(gè)負(fù)載均衡器的IP就可以了，當(dāng)客戶端需要上傳文件時(shí)，通過負(fù)載均衡器獲取實(shí)際上傳的地址，然后上傳文件，由左邊第二個(gè)框里面的服務(wù)器進(jìn)行接收，并且根據(jù)MD5值進(jìn)行校驗(yàn)，如果校驗(yàn)沒有問題，就轉(zhuǎn)到Hadoop的HDFS集群里面去。目前這個(gè)集群有數(shù)十PB的規(guī)模，每天上傳量有幾個(gè)TB。
第二是提高傳輸效率和成功率。大家會(huì)想一個(gè)問題，在中國(guó)，網(wǎng)絡(luò)環(huán)境十分復(fù)雜，運(yùn)營(yíng)商之間存在隔閡甚至是壁壘，導(dǎo)致網(wǎng)絡(luò)不穩(wěn)定，丟包和延遲的問題是怎樣解決的呢？如果基于TCP傳輸大文件，理論上存在單個(gè)連接上帶寬延時(shí)積的限制。這里我們創(chuàng)新的是，客戶端的上傳采用UDP協(xié)議，UDP本身沒有任何控制，說白了就是客戶端可以任意、使勁地發(fā)文件。最終會(huì)由服務(wù)器端檢查你收到了哪些文件片段，然后通知客戶端補(bǔ)傳一些沒上傳的片段就可以了?；谶@種方式能規(guī)避很多因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或網(wǎng)絡(luò)延遲比較大而導(dǎo)致的問題。當(dāng)然，在客戶端做流量控制也是可以的。在遇到問題的時(shí)候多想想，或許能找到不走尋常路的解決方案。
3.8、自動(dòng)化監(jiān)控報(bào)警系統(tǒng)
再看一下游戲的自動(dòng)化監(jiān)控報(bào)警系統(tǒng)。游戲的架構(gòu)中有游戲客戶端、服務(wù)器端、網(wǎng)絡(luò)鏈路，所以必須要有比較完整的體系進(jìn)行全方位、立體式的監(jiān)控，才能保證在業(yè)務(wù)發(fā)生問題之前進(jìn)行預(yù)警，或者在發(fā)生問題時(shí)報(bào)警。
對(duì)于機(jī)房鏈路，有IDC（Internet Data Center）的網(wǎng)絡(luò)質(zhì)量監(jiān)控；在服務(wù)器、網(wǎng)絡(luò)設(shè)備和硬件方面，我們會(huì)做服務(wù)器的健康檢查、性能監(jiān)控，以及網(wǎng)絡(luò)設(shè)備和流量監(jiān)控；在系統(tǒng)程序方面，我們會(huì)收集和分析系統(tǒng)日志；在游戲服務(wù)器端應(yīng)用方面，有服務(wù)器端的程序監(jiān)控；在客戶端方面，我們會(huì)收集植入的SDK做下載更新后的效果，以及收集崩潰的數(shù)據(jù)。
作為運(yùn)維人員，我們考慮問題或者設(shè)計(jì)架構(gòu)的時(shí)候，視角不能僅局限于一個(gè)技術(shù)方面，或者選用多炫酷、多么牛的技術(shù)，要想想技術(shù)在業(yè)務(wù)方面的架構(gòu)，或者能否通過業(yè)務(wù)指標(biāo)監(jiān)控我們的運(yùn)維能力與運(yùn)維系統(tǒng)。在游戲里，有一個(gè)很重要的指標(biāo)就是在線人數(shù)，通過監(jiān)控在線人數(shù)這個(gè)業(yè)務(wù)指標(biāo)，就可以知道系統(tǒng)是否工作正常，是不是有漏報(bào)、誤報(bào)的情況，因?yàn)楹芏鄷r(shí)候任何一個(gè)環(huán)節(jié)出了問題，最終都會(huì)體現(xiàn)在業(yè)務(wù)上，在產(chǎn)生價(jià)值的數(shù)據(jù)上。所以我們有一套監(jiān)控在線人數(shù)的系統(tǒng)，每個(gè)游戲上線之前會(huì)接入這個(gè)系統(tǒng)，把在線的人數(shù)實(shí)時(shí)匯集到系統(tǒng)里面。如果發(fā)生異常的抖動(dòng)，系統(tǒng)中都會(huì)有所顯示，也就可以知道是否發(fā)生了問題。
以上講的是一個(gè)框架，下面我們看一下細(xì)節(jié)，怎樣做服務(wù)器的監(jiān)控。首先由運(yùn)維工程師在監(jiān)控策略平臺(tái)配置監(jiān)控策略，監(jiān)控策略平臺(tái)會(huì)將這些數(shù)據(jù)格式化成相關(guān)格式，然后推送給自動(dòng)化運(yùn)維平臺(tái)。自動(dòng)化運(yùn)維平臺(tái)會(huì)判斷是這些數(shù)據(jù)是外部來(lái)的，還是遠(yuǎn)程檢測(cè)到的；是網(wǎng)絡(luò)模擬的，還是本地的監(jiān)控得到的。比如流量、本地進(jìn)程的監(jiān)控、本地日志的監(jiān)控，會(huì)分別推給遠(yuǎn)程探測(cè)服務(wù)器，或者游戲服務(wù)器本身，然后由它們上報(bào)數(shù)據(jù)。數(shù)據(jù)上報(bào)以后，根據(jù)運(yùn)維工程師配置的閾值，會(huì)觸發(fā)相關(guān)的報(bào)警，然后通知運(yùn)維工程師進(jìn)行相關(guān)處理。因?yàn)殡m然游戲多種多樣，操作系統(tǒng)五花八門，但是總有一些大家可以公用的東西，比如監(jiān)控的模板或者監(jiān)控的策略，我們對(duì)服務(wù)器的東西也進(jìn)行了整合匯總。大家可以看到我們里面有很豐富的插件，運(yùn)維人員只要選擇相關(guān)的插件，配一下閾值和周期，就可以節(jié)省時(shí)間和學(xué)習(xí)成本，提高配置策略的效率。當(dāng)配置策略完成以后，直接綁定到想要監(jiān)控的服務(wù)器上就可以了。
總結(jié)
我們從2000年初到現(xiàn)在一直在做自動(dòng)化運(yùn)維體系，對(duì)過去進(jìn)行總結(jié)，我覺得有3個(gè)方面可以供大家參考。
第一是循序漸進(jìn)的原則，特別是中小公司或者初創(chuàng)公司，很多時(shí)候并不需要一個(gè)“高大上”的系統(tǒng)。聚焦當(dāng)前的問題，把當(dāng)前的問題處理好，后面的問題也就迎刃而解。如果一開始設(shè)計(jì)的系統(tǒng)很龐大、功能特別豐富，會(huì)導(dǎo)致一些無(wú)法控制的局面。比如這個(gè)系統(tǒng)可能最后做不下去了，或者因?yàn)轳詈闲蕴珡?qiáng)，開發(fā)控制不了了，或者項(xiàng)目因?yàn)榻?jīng)費(fèi)問題擱淺了。但是如果一開始的目標(biāo)是解決一些特定的問題，有針對(duì)性，那么推進(jìn)起來(lái)也會(huì)比較簡(jiǎn)單。在我司的自動(dòng)化運(yùn)維體系建設(shè)過程中，我們首先構(gòu)建的是一個(gè)基礎(chǔ)的服務(wù)器批量操作平臺(tái)，先把一部分需要重復(fù)執(zhí)行的工作搬到平臺(tái)上來(lái)，再依據(jù)運(yùn)維的需求豐富這個(gè)操作平臺(tái)的功能和提升效率，最后把周邊的系統(tǒng)打通，相互對(duì)接，形成完整的自動(dòng)化運(yùn)維體系。
第二是考慮可擴(kuò)展性。設(shè)計(jì)系統(tǒng)的時(shí)候，功能或者設(shè)計(jì)方面可能不用考慮那么多，但是要考慮當(dāng)服務(wù)器數(shù)量發(fā)生比較大的擴(kuò)張時(shí)，系統(tǒng)是否還能支撐，比如數(shù)量級(jí)從十到百，或者上千了，這個(gè)系統(tǒng)是否還是可用的。
第三是以實(shí)用為目的。這在我們系統(tǒng)中也是有體現(xiàn)的。很多情況下，市面上可能已經(jīng)有比較成熟的協(xié)議和工具，拿來(lái)評(píng)估看看它們?cè)谏a(chǎn)環(huán)境里面是否可用，如果能用就直接用，沒必要自己再去做一套。自己做的這一套工具，很多方面沒有經(jīng)過驗(yàn)證，可能會(huì)帶來(lái)安全問題。基于成熟的協(xié)議和框架去做，可以提升效率，保證穩(wěn)定性和安全性。在“自動(dòng)化運(yùn)維平臺(tái)”一節(jié)可以看到，我們并沒有自己從頭開始研發(fā)一套Agent植入到被管理的服務(wù)器上，而是用了開源的SSH協(xié)議和成熟的OpenSSH軟件。這體現(xiàn)了優(yōu)先考慮開源方案加一部分二次開發(fā)而不是重復(fù)造輪子的思想。
