做運維的同學都知道，運維一定離不開Zabbix、Nagios之類的監控軟件。目前，類似的軟件在監控和數據採集方面已經做到了極致，但是在報警處理上並沒有很完美的解決方案，比如，經常出現高質量報警湮沒在海量報警之中等情況。
本文不探討監控系統的配置優化，只探討監控系統按照它的邏輯發出報警之後我們該做點什麼。
報警遇到的痛點
報警風暴，高質量報警湮沒在海量報警之中；
出現報警後沒人認領，需要在在工作的IM羣中溝通；
運維人員進行運維操作必定會引起某些報警，會給不知道真相的同學帶來困惑；
海量報警恢復之後，運維人員很難在第一時間知道還剩下哪些報警沒有恢復；
MySQL出現了慢查詢報警，DBA還需要登錄數據庫去查看；
有些報警優先級不高，明明可以白天處理的，卻在晚上第一時間發出來；
同一個報警會反覆報出來。
背景現狀
雲極星創作爲綜合性雲服務提供者，既要做公有云的監控，也要負責私有云的監控。我們的研發團隊已經建立了比較完善的OpenStack監控體系，並且使用了多種監控工具；因爲雲極星創的運維團隊和客戶分佈在全國各地，所以該監控體系的物理位置也是分散。
在公有云場景下，報警需要按照物理位置或者應用類型發給不同的運維同學、運營同學和管理層。在私有云場景下，報警也需要推送給相應的客戶。當前，我們主要採用微信爲主，短信爲輔的報警方式。
使用微信的優缺點
使用微信的優點：
基本免費；
圖文並茂、字節數限制較爲寬裕；
微信客戶端和服務器端交互方便。
使用微信的缺點：
可用度依賴騰訊的服務器：
爲此特意增加了對微信服務器接口的監控，發現接口有問題之後會發短信報警；
客戶端需要保持聯網，沒有送達報告：
因此係統提供彙總表功能（詳見後文）。
優秀報警處理系統的三要素
在合適的時間發給合適的人；
儘可能的提供更多的信息，使得接警人員在不開電腦情況下第一時間能大概知道哪裏出了問題；
減少圍繞報警的人員溝通成本。
實施方案
架構概覽
報警分類
普通報警：根據排班表發送給值班的運維同學，低級別的報警會延時發給對應的應用開發。
ELK日誌報警：用戶在微信端可以查看
收到報警：確認、反饋和彙總
報警確認：當用戶點擊確認按鈕之後，對應的人會收到確認信息。
報警處理結果反饋
彙總表：提供批量確認功能
報警收斂
基於關鍵字、主機名、Tag的複合報警收斂
報警升級
如果報警在一定時間沒被確認也沒有自動回覆，會有一個報警升級動作
微信 vs 短信 兩個平臺
所有微信接口做了加密處理，防止非授權用戶訪問和關注公衆號。短信平臺主要用來發送災難級別的報警、微信API接口的報警，系統本身可用度的報警。
總結 系統使用的成果
雲極星創之前使用的報警方案是郵件加短信的方式，在報警觸發之後，運維交流羣會有大量圍繞報警的溝通，並且經常發生報警風暴，將短信發送平臺堵塞，在本系統投入使用之後，基本上所有的溝通都在系統內進行。隨着豐富的報警附加信息，減少了二線運維工程師在處理故障時候開機登錄系統的次數。
研發歷程
本系統開發歷時半年左右，基本上隨着雲極星創的發展而發展壯大起來，初期的想法是因爲各家短信發送平臺隨着國家打擊電信詐騙的政策影響，變得越來越不好用，所以誕生了使用普及率非常高的微信來替代短信的想法。
第一個版本就是原封不動的推送Zabbix報警信息，隨着公有云規模的不斷擴大，報警不斷增多，另外私有云客戶也在不斷的增加，需要接受報警的人員也越來越分散，圍繞報警的溝通成本越來越高。
因此本系統的功能點都是圍繞着我們運維同學在處理報警時候遇到的痛點進行開發而成。經過半年的發展，在我們內部已經將運維報警做成了運營的報警。
未來發展
報警系統和工單系統以及CMDB做關聯；
快速實現故障根因定位；
告警排行分析報表；
（備註：文中截圖來自於預發佈環境下的運維測試）
重點在最後，代碼已經託管到github
https://github.com/superbigsea/zabbix-wechat