互聯網技術的發展，離不開運維支撐工作，沒有零 BUG 的程序，沒有不出問題的系統，問題故障不可怕，可怕的是沒能有序的處理故障。尤其對於有數字化服務需要始終在線的業務團隊，一個流暢的應用服務增加了對技術團隊的要求，要求他們隨時準備提供響應。而對於不熟悉 On-Call 的團隊來說，要想做到運維開發人員可以隨叫隨到可能會有一定的挑戰。
在現實的運維場景中一旦突發緊急事件太多，團隊成員會疲於應付，從而造成團隊士氣低下，效率低迷。而重要告警事件被淹沒在大量重複而混雜的告警消息，沒有有序跟進處理，會引發嚴重業務影響。如何有效處理緊急事件驅動的工作，成爲運維工作的重中之重。
而對於睿象雲智能告警平臺 Cloud Alert（以下簡稱：CA）來說，這一功能是我們平臺的一個重要的組成部分，【精準分派相關人員】是我們智能告警平臺的一個重要功能關鍵，可以幫助您與您的團隊，促成一個優秀的排班計劃，形成一個隨叫隨到的技術團隊。睿象雲經過多年與各類型的運維團隊的溝通，圍繞人、流程、工具三方面，形成了一套告警的全生命週期管理系統。
監控告警集中化管理
大多公司都使用了 Zabbix 和 Nagios、Open-Falcon 等監控工具去對自己系統中的硬件、網絡、應用進行監控。 而這就會存在監控分散的問題： · 遇到複雜環境的時候，就用到多個監控工具，如 Cacti 監控網絡，Zabbix 監控應用和服務器； · 如果存在有多個異地數據中心時，還需要同時部署多個 Zabbix 和工具； · 部分關鍵業務，需要單獨的開發監控腳本／工具進行獨立監測； 但是如果沒有集中的告警機制進行管理，就會面臨大量的告警噪音的困擾，難及時地跟進處理，而重要的告警信息也容易被遺漏。
CA 可以實現告警的集中化管理，即將生產監控發現的告警事件集中到一起，這樣只看着一個平臺就夠了，同樣地也會更容易分析告警問題，在這一步相同和類似的告警就會被過濾掉，即可直觀掌握現有環境的狀況，發現事件相關性的，有些問題有較強關聯性的，方便跟蹤和後續的統計分析。集中處理，效率就會更高。
建立支撐流程和機制
如果您的系統只採用了一種監控工具，集中化管理則不是必要的，如何有序處理告警信息纔是最核心的問題。特別運維團隊是 3-5 人到數十／百人，就很有必要梳理下支撐流程和響應機制了。
· 建立一線、二線甚至三線支撐團隊，一線好理解，一般是 7x24 小時值班的同學們； · 二線一般是資深工程師，或者是對應的應用開發／測試同學； · 三線一般是主管或者是外部的廠家，如涉及硬件、IDC 機房等相關服務方。
如果管理比較細一些，還應該對業務進行拆分，形成一個矩陣，例如一線、二線根據不同專業，如負責網絡和負責不同應用的團隊。同時還要考慮告警嚴重的程度級別，進行差異化處理，對於運維管理嚴格的團隊一般會建立不同的響應級別。
- 嚴重級別：如大範圍影響業務／終端用戶的，需要及時處理，一般要求多長時間響應處理，如3-10分鐘有人響應，無響應立刻升級；
- 警告級別：影響範圍和嚴重程度會低一些的故障，處理時長可以長一些；
- 提醒級別：依次更低。
那麼問題來了，這一切如何落地呢？目前看 Zabbix、Nagios、Open-Falcon 等監控工具更多是聚焦如何發現問題，支撐流程屬於處理問題的範疇，或者是說管理範疇，這一點還有很多運維團隊採用“碼人”的方式：一個監控班，7x24值班，人爲處理和通知。
而對於 CA 的用戶來說即可用技術的方式實現：CA 可以通過分派策略、通知策略以及排班機制等，實現告警的靈活通知。
【自定義分派策略】可以進行流程的設計，根據級別、應用設置對應的一、二線負責人，以及處理時限，超時未響應（確認告警）自動升級。
【自建排班規則】7x24 小時緊繃狀態不是誰都能扛得住的，適當輪班緩解下壓力。CA 中可以通過排班機制，實現白夜班、按周等模式進行輪流值班。
多渠道通知必達
再好的流程和設計，如果沒有及時收到通知並處理，那麼整個運維團隊仍然會很鬱悶的，關於告警的最後一公里的問題更是至關重要！
目前被運維團隊選擇最多的就是以下這幾種方式： · 郵件通知：簡單有效，就是不夠及時； · 短信通知：需要開發對接，目前很多公司都有自己的短信服務通道。要注意一個限制：部分運營商會限制一天相類似內容只能發送10－30條； · 移動APP通知：適應移動大潮。微信方式，好處是人人都有，壞處就是告警消息和正常溝通消息會混淆； · 電話語音通知：這個可以說是最重要的救命線了，電話通知可以應對特別重要的告警，例如晚上嚴重的電話通知； · QQ、釘釘、企業微信、JIRA 等協作類工具：這一點屬於彩蛋性質，找到團隊的前後端共同來解決告警問題。
當然如果您正在使用我們的 CA 平臺，可以根據您企業的自身使用習慣，選擇電話、短信、微信、郵件、APP、釘釘、企業微信、飛書、JIRA 等通知方式，也可以根據自身需求，設置指定級別的告警使用不同的通知方式，也可以自定義工作時間，讓告警在不同的時間段，用不同的通知方式。
告警智能化去重降噪
如果您前 3 步都已經完成了，那麼這裏面還存在一個問題，就是當告警大規模觸發時，特別是遇到告警風暴的話，很容易撐爆郵箱或者是手機短信了，所以接下來就聊下告警風暴規避的問題。這個問題比較大，基本上有些監控工具做了一部分，但是目前來看這還是一個難點： 靜態規則方式：需要知識經驗積累，根據業務邏輯梳理出一些父子關係。就比如出現服務器 Down 的告警，肯定該機器上的業務應用也會 Down ，那麼就整理爲一條規則。需要一套告警的過濾引擎，根據告警字段信息進行匹配； 關聯關係分析：依賴 CMDB，服務關聯關係，根據調用依賴關係進行告警的根源追溯。CMDB 的建設和維護是非常困難的事情，數據準確性和實時性是決定 CMDB 效果的根本因素。CMDB 國內落地效果理想的很少，只能依賴自動化，微服務、docker、Devops 大量應用讓IT環境更動態、更復雜，沒有自動化機制保障是非常困難的； 機器學習方式：相比前兩種方式，機器學習更取巧一些，或者是說應該是未來的方向，可以節省大量人力物力。
目前，在 CA 平臺中對於接收到的所有告警第一步就是自動去重，就是根據告警的 Event ID 來判斷是否合併，Event ID 相同的告警就會自動合併到主告警之中，這樣的告警只會通知主告警，直到告警恢復/關閉。
當然 CA 並不滿足於此，目前 CA 支持的智能降噪包括時間窗口智能降噪和實時智能降噪的通知前降噪以及高聚合智能算法和仿閱讀智能算法的通知後降噪。這裏麪包括實時計算和離線計算，算法方面參考了相似度、決策樹、分類等算法。以相似度來說：首先採集告警的多維度信息，包括時間、主機、服務、分組 hostgroups、應用 applications、標籤 tags 等基本維度信息，計算不同告警之間相似度，如果達到閾值，如告警 A 和告警 B 有70%相似就關聯起來。以相似度爲例因爲根據業務不同，各維度的權重，閾值靈敏度有些差異。
事件單記錄和團隊協作處理
如果告警量很大，告警後續處理和跟蹤往往會依賴於外部團隊（部門外或公司外）。但是監控告警粒度太細了，可能很多告警都是一個事情。如上面的告警風暴中，由於應用程序故障，引發引發了大量的異常，之後又產生連鎖反應，其實就是一個事件，只需要處理一個事情就行。 一般來說一線人員會採用郵件或者電話方式，直接通知對應負責人，但是這個就很難追蹤和事後分析，所以一套事件管理機制。
· ITIL規範的事件 Incident 流程很有參考價值，事件工單需要： · 將批量告警轉爲事件工單，這裏包括手動轉發和自動匹配規則轉發； · 手動生成事件工單，一般屬於非告警類觸發，如人工發現或用戶投訴等引發的事件； · 事件工單包括影響範圍、嚴重程度，兩者的交叉矩陣影響到處理的優先級。包括分類、子類、自定義標籤，分類和標記有助於後續的統計分析； · 責任人和責任組，分派到其他團隊或個人，並通知提醒。