本文是WOT2016互聯(lián)網(wǎng)運(yùn)維與開(kāi)發(fā)者大會(huì)的現(xiàn)場(chǎng)干貨，新一屆主題為WOT2016企業(yè)安全技術(shù)峰會(huì)將在2016年6月24日-25日于北京珠三角JW萬(wàn)豪酒店隆重召開(kāi)！

關(guān)于本次的技術(shù)分享，主要是游戲行業(yè)運(yùn)維體系的介紹，側(cè)重于游戲行業(yè)的運(yùn)維體系的構(gòu)建。

第一部分，37游戲的運(yùn)維體系

馬辰龍總結(jié)道，公司從創(chuàng)業(yè)到后面的上市基本會(huì)經(jīng)歷四個(gè)階段。

第一個(gè)階段就是標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化的意思是把主機(jī)名、內(nèi)網(wǎng)以及配置文件統(tǒng)一起來(lái)，如果不統(tǒng)一，后面的東西就無(wú)法繼續(xù)。沒(méi)有一個(gè)標(biāo)準(zhǔn)化的環(huán)境，腳本是無(wú)法寫(xiě)下去的。

第二個(gè)階段是自動(dòng)化。中小型企業(yè)階段都是自動(dòng)化到平臺(tái)化的過(guò)渡，平臺(tái)化就是把自動(dòng)化的東西分裝，把功能整合，把數(shù)據(jù)做聚合，然后放在平臺(tái)上來(lái)可視化。

第三個(gè)階段是平臺(tái)化。以后的趨勢(shì)是腳本和功能必須是外部化的，這樣新來(lái)的一個(gè)人才能接手。不用在服務(wù)器上跑腳本，還要同下個(gè)人交代在哪兒裝。

最后一個(gè)階段就是服務(wù)化。服務(wù)化是指現(xiàn)在云平臺(tái)所承載的東西。舉個(gè)例子，搭一個(gè)redis集群，用戶不需要知道服務(wù)器有多少個(gè)，因?yàn)樗峁┑腘OSQL服務(wù)打開(kāi)后，用戶就可以直接使用了。

37游戲的自動(dòng)化工具。37游戲所有的重點(diǎn)數(shù)據(jù)都在CMDB當(dāng)中。公司剛開(kāi)始建立的時(shí)候發(fā)布是很頭疼的事情，雖然利用SVN來(lái)提交，但是沒(méi)有一個(gè)自動(dòng)化的發(fā)布流程。運(yùn)維的重點(diǎn)工作是監(jiān)控，監(jiān)控做好，運(yùn)維就會(huì)清閑許多，因?yàn)榇蟛糠值臅r(shí)間都在接收短信告急。很多公司只知道運(yùn)維是給開(kāi)發(fā)打雜的，熟不知有了運(yùn)維數(shù)據(jù)，便可以推動(dòng)業(yè)務(wù)的發(fā)展。安全管理。如果在大公司里面的話，有專業(yè)的團(tuán)隊(duì)做安全管理，跟運(yùn)維是分離的。如果是在中型企業(yè)的話，安全管理是跟運(yùn)維在一個(gè)部門的，二者是離不開(kāi)的。最后一個(gè)是DB管理，DB是37游戲相關(guān)的關(guān)系型數(shù)據(jù)庫(kù)，NOSQL和集群的管理。

客戶端的分類。服務(wù)器操作類就是用SaltStack做Agent，然后用日志收集logstash，API需要的數(shù)據(jù)可以利用zabbix監(jiān)控獲得。

應(yīng)用的上線。應(yīng)用上線，灰度發(fā)布，應(yīng)用運(yùn)行，應(yīng)用下線，這四點(diǎn)貫穿在運(yùn)維平臺(tái)里。舉個(gè)例子，配置一個(gè)wab服務(wù)，wab服務(wù)首先是應(yīng)用去安裝，從CMDB拉數(shù)據(jù)，再進(jìn)行灰度發(fā)布，然后開(kāi)始上線，使用到最后下線， CMDB自動(dòng)將涉及的子系統(tǒng)中配置進(jìn)行刪除。

CMDB是運(yùn)維里開(kāi)始最麻煩的，其實(shí)最主要是理清關(guān)系，然后信息關(guān)聯(lián)。在這里簡(jiǎn)單地分了幾類，比如域名庫(kù)、軟件庫(kù)、資源庫(kù)、IP庫(kù)、配置庫(kù)，這些建立起來(lái)的話，CMDB必須是可維護(hù)性的，建立這些模型之初一定要想到它的可維護(hù)性，沒(méi)有可維護(hù)性后面的數(shù)據(jù)會(huì)很亂從而自動(dòng)化就不用談了。DB管理、安全管理、監(jiān)控管理。DB管理分為DB部署、DB監(jiān)控，里面是關(guān)于數(shù)據(jù)的操作，權(quán)限的一些劃分。安全管理就是安全規(guī)則管理。

第二部分，監(jiān)控、日志數(shù)據(jù)智能分析。

監(jiān)控?cái)?shù)據(jù)，因?yàn)槠脚_(tái)眾多，所以怎么統(tǒng)一這些數(shù)據(jù)？37游戲有Zabbix、Nagios、Cacti各種云資源服務(wù)器的管理數(shù)據(jù)，通過(guò)API拿到這些數(shù)據(jù)。Zabbix應(yīng)該是支持所有的去、增、長(zhǎng)、改、查。Nagios其實(shí)本身是不支持API的，但可以從它的配件文件里面把數(shù)據(jù)抓過(guò)來(lái)。Cacti可以從頁(yè)面上抓下來(lái)，這些都有一些實(shí)踐。只要云服務(wù)商是比較可靠的云，也就可能提供API接口。

如何改善我們的監(jiān)控業(yè)務(wù)，我們的監(jiān)控?cái)?shù)據(jù)從各維度分析，告警定義，就是多層閾值。

還有一個(gè)是降低誤報(bào)率，運(yùn)維每天可能收到一百條短信，大概九十條都是誤報(bào)。

馬辰龍舉了一個(gè)例子：怎么樣用我們的監(jiān)控?cái)?shù)據(jù)去推動(dòng)業(yè)務(wù)？運(yùn)維的工作并不是僅僅處理告警了，也需要推動(dòng)業(yè)務(wù)的進(jìn)程。游戲行業(yè)的環(huán)境是相當(dāng)復(fù)雜的，37游戲有自己的IDC機(jī)房去存放游戲。所有的東西都是通過(guò)接口去取，再把監(jiān)控?cái)?shù)據(jù)匯總到歷史監(jiān)控?cái)?shù)據(jù)里。根據(jù)天、周、月，和系統(tǒng)應(yīng)用、網(wǎng)絡(luò)等其他維度生成一個(gè)報(bào)表。值得注意的是，所得數(shù)據(jù)不是實(shí)時(shí)的，而是監(jiān)控歷史數(shù)據(jù)，因?yàn)橛脤?shí)時(shí)分析的話，只能是一個(gè)告警。之所以判定服務(wù)器出現(xiàn)問(wèn)題，肯定是根據(jù)周期性的平均告警率達(dá)到多少，平均的使用率低于一定閾值了，才會(huì)判定有問(wèn)題。閾值需要同運(yùn)營(yíng)定義。

Web日志的應(yīng)用。場(chǎng)景就是安全人員需要運(yùn)維定期的推送一些異常日志，進(jìn)行XSS注入分析。游戲行業(yè)遇到最多的就是被撞庫(kù)了，每天都在不停的刷賬號(hào)，刷密碼。這個(gè)事不光是在游戲行業(yè)，在其他行業(yè)也會(huì)遇到。

37游戲制訂了一個(gè)目標(biāo)，運(yùn)維負(fù)責(zé)相關(guān)業(yè)務(wù)日志統(tǒng)一匯總，需要有標(biāo)準(zhǔn)的API查詢接口?，F(xiàn)在所有跟跨部門合作，或者同其他人合作都是通過(guò)API。安全人員可以自己定義Web過(guò)濾規(guī)則，寫(xiě)正則，對(duì)異常日志做分析，然后確定攻擊類型，采取相應(yīng)的措施。各平臺(tái)有日志的實(shí)時(shí)匯總，如果是集群的話，則服務(wù)器是分片的，只是每一臺(tái)去統(tǒng)計(jì)防護(hù)失常，或者PV、UV的東西，很難全局性地去判斷。因?yàn)榻?jīng)典的架構(gòu)就是前面ALVS，把它分散到下面的服務(wù)器，數(shù)據(jù)需要先合并，也需要聚合，肯定要花費(fèi)很大、很長(zhǎng)的時(shí)間。

拿到數(shù)據(jù)可以根據(jù)用戶的地區(qū)，優(yōu)化服務(wù)器區(qū)服的配置和用戶體驗(yàn)。游戲的區(qū)域性是很強(qiáng)的，可以根據(jù)IP進(jìn)行精準(zhǔn)定位。

37游戲用的是互聯(lián)網(wǎng)比較經(jīng)典的架構(gòu)ELK。logstash收集日志，隊(duì)列用redis，放到redis里面，然后logstash再取，放給ElasticSearch，最后去存儲(chǔ)。建立初期可以直接用圖形化，用Kibana做圖形化視圖的分析。中間的redis只是充當(dāng)一個(gè)隊(duì)列，但是架構(gòu)是不變的，所以上手是非常之快的。如果有開(kāi)發(fā)運(yùn)維的話，直接可以從Lsearch里面把日志分析出來(lái)。web端用自己的過(guò)濾規(guī)則。如果有問(wèn)題就扔到黑名單里面，業(yè)務(wù)在前端做邏輯控制。

第三部分，故障自愈。

現(xiàn)在大部分中型的企業(yè)都有自己的API，監(jiān)控?cái)?shù)據(jù)的聚合，告警數(shù)據(jù)的收斂，很多做自動(dòng)化。這些做起來(lái)并不是很難，關(guān)鍵是在做未來(lái)的時(shí)候，去挖掘故障信息，去制定自己的故障自愈規(guī)則。

其所面臨的問(wèn)題就是系統(tǒng)網(wǎng)絡(luò)，業(yè)務(wù)層面自生的邏輯造成的一些異常，監(jiān)控誤報(bào)還有監(jiān)控自身的一些可靠性。還有非自愈業(yè)務(wù)，因?yàn)楣收献杂皇侨f(wàn)能的，就像現(xiàn)在的人工智能一樣，有些東西是機(jī)器代替不了的。比如說(shuō)復(fù)雜的業(yè)務(wù)場(chǎng)景，可能機(jī)器是沒(méi)辦法判斷的，可能有些東西是需要人工看，才能知道應(yīng)該怎么處理。

37游戲所有的告警信息都是發(fā)送到告警信息處理中心的，比如說(shuō)的短信告警，這些都是經(jīng)過(guò)信息統(tǒng)一推送。

這里馬辰龍分享了一個(gè)實(shí)例，搬到任意一個(gè)場(chǎng)景下都可以應(yīng)用。用自己的Zabbix監(jiān)控或者somkeping監(jiān)控甚至第三方監(jiān)控，獲取監(jiān)控信息。然后把所有的監(jiān)控信息全部推送，推送到回調(diào)隊(duì)列里面去，然后去分析這個(gè)告警信息。

故障自愈能帶來(lái)什么呢？非工作時(shí)間可以處理自己私人的事情，運(yùn)維第一個(gè)要求就是24小時(shí)要待命。減少直接對(duì)線上的操作，比如出現(xiàn)了故障，直接去操作線上，很有可能會(huì)出現(xiàn)二次故障。所以必須要從故障原因里面分析，鍛煉運(yùn)維人員對(duì)工作的積極性，并不是每天都是鼓噪的東西。長(zhǎng)遠(yuǎn)看來(lái)，對(duì)玩家，對(duì)公司利益，以及自身價(jià)值都將有顯著的提升。

最后馬辰龍總結(jié)了一點(diǎn)：一定要在自己的領(lǐng)域有獨(dú)特的解決方案。

“有很多開(kāi)源方案是不能直接用的，必須要用到自己的生產(chǎn)環(huán)境當(dāng)中，有自己的一些解決方案。運(yùn)維工具的設(shè)計(jì)要很簡(jiǎn)單，因?yàn)橐紤]下一個(gè)接手你的東西的時(shí)候，維護(hù)成本有多高。敲過(guò)代碼的人都知道，重寫(xiě)會(huì)比維護(hù)代碼好很多。所有的東西都要以業(yè)務(wù)為核心，一旦脫離了業(yè)務(wù)，你做的數(shù)據(jù)其實(shí)并沒(méi)有什么用。最后要說(shuō)的是，好的架構(gòu)是演化來(lái)的，不是設(shè)計(jì)出來(lái)的。”馬辰龍講到。

本文整理自，由51CTO傳媒主辦的WOT2016互聯(lián)網(wǎng)運(yùn)維與開(kāi)發(fā)者大會(huì)上來(lái)自37游戲運(yùn)維架構(gòu)師馬辰龍主題為《游戲行業(yè)運(yùn)維自動(dòng)化與故障自愈》的精彩演講。
演講視頻：http://edu.51cto.com/lesson/id-100749.html
講師簡(jiǎn)介：

[[166505]]
馬辰龍，負(fù)責(zé)37游戲運(yùn)維平臺(tái)開(kāi)發(fā)，目前專注游戲行業(yè)運(yùn)維自動(dòng)化，監(jiān)控系統(tǒng)故障自愈，擅長(zhǎng)perl開(kāi)發(fā)，正則表達(dá)式，日志精確匹配。