一個優雅的報警處理系統範例：微信為主，簡訊為輔

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

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

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

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

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

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

• MySQL出現了慢查詢報警，DBA還需要登錄資料庫去查看；

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

• 同一個報警會反覆報出來。

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

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

使用微信的優點：

• 基本免費；

• 圖文並茂、位元組數限制較為寬裕；

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

使用微信的缺點：

• 可用度依賴騰訊的伺服器：

為此特意增加了對微信伺服器介面的監控，發現介面有問題之後會發簡訊報警；

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

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

• 在合適的時間發給合適的人；

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

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

架構概覽

報警分類

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

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

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

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

報警處理結果反饋

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

報警收斂

基於關鍵字、主機名、Tag的複合報警收斂

報警升級

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

微信 vs 簡訊 兩個平台

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

系統使用的成果

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

研發歷程

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

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

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

未來發展

作者介紹

安新海，雲極星創高級運維工程師。十年軍旅生涯，曾在解放軍某部負責過大型雲平台建設。退役后一直從事互聯網雲平台運維工作，擅長Zabbix、OpenStack、VMware等系統的運維、調優。

QCon北京2017將於4月16日~18日在北京·國家會議中心舉行。