游戲平臺的運維自動化擴展：故障自愈

馬辰龍，負責某大型網頁游戲平臺的運維開發，專注于運維自動化、監控系統故障自愈研究，擅長Perl開發、正則表達式、日志精確匹配。

網絡游戲是對用戶體驗要求最嚴苛的IT行業之一，任何IT問題造成的業務不穩定，都可能導致玩家的流失，進而影響游戲商的營收。因此，自動化運維對于游戲平臺的重要不言而喻。

相比起對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的面太大，這里細節就不多說了。

 

來自：http://mp.weixin.qq.com/s/yFRCeX26VOgIycSq1bL1lg