一個優雅的報警處理系統范例

做運維的同學都知道，運維一定離不開Zabbix、Nagios之類的監控軟件。目前，類似的軟件在監控和數據采集方面已經做到了極致，但是在報警處理上并沒有很完美的解決方案，比如，經常出現高質量報警湮沒在海量報警之中等情況。

本文不探討監控系統的配置優化，只探討監控系統按照它的邏輯發出報警之后我們該做點什么。

報警遇到的痛點  

1. 報警風暴，高質量報警湮沒在海量報警之中；

2. 出現報警后沒人認領，需要在在工作的IM群中溝通；

3. 運維人員進行運維操作必定會引起某些報警，會給不知道真相的同學帶來困惑；

4. 海量報警恢復之后，運維人員很難在第一時間知道還剩下哪些報警沒有恢復；

5. MySQL出現了慢查詢報警，DBA還需要登錄數據庫去查看；

6. 有些報警優先級不高，明明可以白天處理的，卻在晚上第一時間發出來；

7. 同一個報警會反復報出來。

背景現狀  

云極星創作為綜合性云服務提供者，既要做公有云的監控，也要負責私有云的監控。我們的研發團隊已經建立了比較完善的OpenStack監控體系，并且使用了多種監控工具；因為云極星創的運維團隊和客戶分布在全國各地，所以該監控體系的物理位置也是分散。

在公有云場景下，報警需要按照物理位置或者應用類型發給不同的運維同學、運營同學和管理層。在私有云場景下，報警也需要推送給相應的客戶。當前，我們主要采用微信為主，短信為輔的報警方式。

使用微信的優缺點  

使用微信的優點：

   基本免費；

   圖文并茂、字節數限制較為寬裕；

   微信客戶端和服務器端交互方便。

使用微信的缺點：

   可用度依賴騰訊的服務器：

為此特意增加了對微信服務器接口的監控，發現接口有問題之后會發短信報警；

   客戶端需要保持聯網，沒有送達報告：

因此系統提供匯總表功能（詳見后文）。

優秀報警處理系統的三要素  

1. 在合適的時間發給合適的人；

2. 盡可能的提供更多的信息，使得接警人員在不開電腦情況下第一時間能大概知道哪里出了問題；

3. 減少圍繞報警的人員溝通成本。

實施方案  

架構概覽

報警分類

普通報警：根據排班表發送給值班的運維同學，低級別的報警會延時發給對應的應用開發。

ELK日志報警：用戶在微信端可以查看

收到報警：確認、反饋和匯總

報警確認：當用戶點擊確認按鈕之后，對應的人會收到確認信息。

報警處理結果反饋

匯總表：提供批量確認功能

報警收斂

基于關鍵字、主機名、Tag的復合報警收斂

報警升級

如果報警在一定時間沒被確認也沒有自動回復，會有一個報警升級動作

微信 vs 短信 兩個平臺

所有微信接口做了加密處理，防止非授權用戶訪問和關注公眾號。短信平臺主要用來發送災難級別的報警、微信API接口的報警，系統本身可用度的報警。

總結      系統使用的成果

云極星創之前使用的報警方案是郵件加短信的方式，在報警觸發之后，運維交流群會有大量圍繞報警的溝通，并且經常發生報警風暴，將短信發送平臺堵塞，在本系統投入使用之后，基本上所有的溝通都在系統內進行。隨著豐富的報警附加信息，減少了二線運維工程師在處理故障時候開機登錄系統的次數。

    研發歷程

本系統開發歷時半年左右，基本上隨著云極星創的發展而發展壯大起來，初期的想法是因為各家短信發送平臺隨著國家打擊電信詐騙的政策影響，變得越來越不好用，所以誕生了使用普及率非常高的微信來替代短信的想法。

第一個版本就是原封不動的推送Zabbix報警信息，隨著公有云規模的不斷擴大，報警不斷增多，另外私有云客戶也在不斷的增加，需要接受報警的人員也越來越分散，圍繞報警的溝通成本越來越高。

因此本系統的功能點都是圍繞著我們運維同學在處理報警時候遇到的痛點進行開發而成。經過半年的發展，在我們內部已經將運維報警做成了運營的報警。

    未來發展

• 報警系統和工單系統以及CMDB做關聯；

• 快速實現故障根因定位；

• 告警排行分析報表；

（備注：文中截圖來自于預發布環境下的運維測試）

重點在最后，代碼已經托管到github

https://github.com/superbigsea/zabbix-wechat