遊戲平台運維自動化擴充之故障自愈

馬辰龍，負責某大型網頁遊戲平台的運維開發，專注于運維自動化、監控系統故障自愈研究，擅長Perl開發、正規表達式、日志精确比對。

網絡遊戲是對使用者體驗要求最嚴苛的IT行業之一，任何IT問題造成的業務不穩定，都可能導緻玩家的流失，進而影響遊戲商的營收。是以，自動化運維對于遊戲平台的重要不言而喻，各種DevOps産品和自動化運維技術方案不斷湧現，包含釋出變更、容量伸縮、故障自愈等多種場景的遊戲運維技術日趨成熟，這些改變都讓運維工作流程越來越簡化。

然而流程的簡化并不意味着運維變得容易，恰恰相反随着雲計算、移動網際網路的廣泛應用，遊戲業務對運維的要求水漲船高！相比起對IT基礎設施運維操作的需求，業務側更需要運維提供高品質的業務保障服務，包括對業務架構及部署的持續優化，精細化的遊戲健康度管理，以及快速的故障處理服務等。

以下就是由馬辰龍先生為我們分享他在日常工作中總結的《遊戲平台運維自動化擴充之故障自愈》：

大家好，我們用一個例子作為今天分享的開始，越來越複雜的網絡問題常常會造成各種誤報，導緻各種誤報資訊的轟炸，出現報警我們一般先看報警内容，這種情況大家都遇到過吧？久而久之就造成了對告警資訊的麻木。比如淩晨2點某機房切割網絡抖動，一下過來幾百條告警短信，相信大家不可能一條條的看。

首先我們要解決的是誤報的問題。現在的監控軟體無非就是Zabbix 、Nagios或者 SmokePing 這類，還會有一些單點監控軟體。如果想消除誤報隻有多IDC去部署監控伺服器，搭建多節點去監控網絡問題，但這就需要使用大量的伺服器資源，有沒有什麼好的解決方案呢？而且即使我們搭建了大量的監控伺服器，又怎麼去集中處理告警消息呢？

經過對市面上流行的監控類産品進行廣泛調研，發現雲智慧的監控寶可以通過分布式監測節點，多區域同時監控伺服器、網站的健康狀況，同時還提供一些國外節點（我們的業務涉及海外）監測海外使用者的業務通路體驗，而且門檻值和監控方式也可以根據業務的實際需求去自定義。

當然作為一個崇尚運維自動化的運維人員，我看中的不僅是這些，更重要的是能夠callback告警消息。如果是因為伺服器網絡或者其他原因導緻當機，在收到告警消息之後，讓後端系統能夠根據消息去自動處理是不是會更好呢。給大家看一副圖來了解下：

根據回調資訊，事先将其定義成一些規則，當我們比對到了告警資訊中的特定資訊可以自主切換。

監控寶的URL回調可以在這裡設定：

運維監控的發展： 

過去：Nagios、Cacti、Zabbix 監控單一，對告警後知後覺；

現在：API監控資料聚合、告警資訊收斂，自動化感覺；

未來：挖掘故障資訊，制定故障自愈規則，提前感覺。

運維的建設有四個階段，簡稱為四化建設：第一個階段就是标準化。标準化的意思是把主機名、内網以及配置檔案統一起來，如果不統一，後面的東西就無法繼續。沒有一個标準化的環境，腳本是無法寫下去的。第二個階段是自動化。中小型企業階段都是自動化到平台化的過渡，平台化就是把自動化的東西分裝，把功能整合，把資料做聚合，然後放在平台上來可視化。第三個階段是平台化。以後的趨勢是腳本和功能必須是外部化的，這樣新來的一個人才能接手。不用在伺服器上跑腳本，還要同下個人交代在哪兒裝。最後一個階段就是服務化。服務化是指現在雲平台所承載的東西。舉個例子，搭一個redis叢集，使用者不需要知道伺服器有多少個，因為所提供的NOSQL服務打開後，使用者就可以直接使用了。

是以我們未來要做的就是收集告警資訊進行自動化處理，而不是通知運維上線處理。我們要脫離那種每天等着告警資訊去處理故障，要主動出擊，不要等到故障了再去處理，而且即使事後處理好了，那麼時間成本也是很高的。

再舉個栗子，一個網站在全國各地會解析為多個IP，而且還會有備用IP用來切換（被DDOS的時候，IP被封，我們需要切換）。我們會有一個腳本去檢測這些IP的狀态，當這些IP正常的時候才會切換到這些IP上，如果Ping不通或者有其他故障就不會去切換，否則去切換一個故障IP不是沒有用嗎？

我們在做監控的時候需要考慮很多不可控的因素，是以在寫代碼的時候要首先考慮異常狀态，否則會造成二次故障，這是我們不願意看到的。當故障IP 2小時内不丢包，我們就把他去掉，下次切換的時候就可以用到，反之亦然。這裡提示下，對于這種時間周期可以使用redis，expire 指定ttl。

給大家一張圖來了解下告警資訊的分類：

我們要做到能自動化的盡量自動化，不能自動化的我們要讓它半自動，人工介入處理是最後的方案，因為是人就會犯錯，尤其在業務出現異常，操作都是不可控的。

說這麼多 ，核心就是需要建立自己的消息進行中心來分析問題，充分利用告警資訊，大概的模型可以是這樣：

最後，故障自愈能夠給我們帶來什麼：

1、非工作時間運維人員處理故障以及響應時間；

2、減少直接的線上操作、避免出現人為原因的二次故障；

3、提高運維人員對故障原因的分析、以及工作積極性；

4、提升運維的自身價值。

Q&A

問：如何做告警收斂？

答：比如我們以一台伺服器為機關，每分鐘的告警資訊分為系統和網絡告警，統一處理。（當然也能以收件人，業務關聯為機關。）

問：對于傳染型的故障，不知道有沒有什麼好的方案呢，就是反複通路一個問題導緻骨牌性的反應。

答：比如網站報了500錯誤，那麼我們發現500錯誤的時候，在告警的時候可以讓它去錯誤日志裡收集關于相同IP的error，一起發送。

問：怎麼自動化的？

答：減少我們去伺服器查日志的時間，頻繁的grep xxx。

問：百度爬蟲并發大沒抗住，怎麼自動化處理？

答：首先你是想讓它爬還是不爬，不爬就比對useragent。

問：你們故障自愈是哪些情況？是通過日志？還是api url監控？通過特定故障傳回特定值？？因為java的日志各種情況都有。

答：面對DDOS流量型攻擊，通過分析url使用防火牆封禁，首先是日志。

問：DDOS怎麼分析url？？有什麼特征嗎？？

答：DDOS是沒有日志的，可以通過網絡告警去觸發，CC攻擊分析你的URL，規則可以自己去定義，有些注入、刷API等通過正則去比對。運維人員要利用好日志，所有的問題都是從日志中分析行為發現的。

問：我們上了ELK，Java除了假死自動重新開機，好像沒什麼自愈的。

答：ELK可以使用API拉日志，去分析業務的運作狀态，ELK的面太大，這裡細節就不多說了。

雲智慧是業務運維解決方案服務商，旗下産品監控寶（www.jiankongbao.com）、透視寶（www.toushibao.com）、壓測寶（www.yacebao.com），已累計為電商、移動網際網路、廣告傳媒、線上遊戲、教育醫療、金融證券、政企等行業的幾十萬使用者提供了一站式的應用性能監控、管理及測試服務。