但是如果沒有集中的告警機制進行管理，就會面臨大量的告警噪音的困擾，難及時地跟進處理，而重要的告警信息也容易被遺漏。

CA 可以實現告警的集中化管理，即將生產監控發現的告警事件集中到一起，這樣只看著一個平臺就夠了，同樣地也會更容易分析告警問題，在這一步相同和類似的告警就會被過濾掉，即可直觀掌握現有環境的狀況，發現事件相關性的，有些問題有較強關聯性的，方便跟蹤和后續的統計分析。集中處理，效率就會更高。

建立支撐流程和機制

如果您的系統只采用了一種監控工具，集中化管理則不是必要的，如何有序處理告警信息才是最核心的問題。特別運維團隊是 3-5 人到數十／百人，就很有必要梳理下支撐流程和響應機制了。

如果管理比較細一些，還應該對業務進行拆分，形成一個矩陣，例如一線、二線根據不同專業，如負責網絡和負責不同應用的團隊。同時還要考慮告警嚴重的程度級別，進行差異化處理，對于運維管理嚴格的團隊一般會建立不同的響應級別。

1. 嚴重級別：如大范圍影響業務／終端用戶的，需要及時處理，一般要求多長時間響應處理，如3-10分鐘有人響應，無響應立刻升級；

2. 警告級別：影響范圍和嚴重程度會低一些的故障，處理時長可以長一些；

3. 提醒級別：依次更低。

那么問題來了，這一切如何落地呢？目前看 Zabbix、Nagios、Open-Falcon 等監控工具更多是聚焦如何發現問題，支撐流程屬于處理問題的范疇，或者是說管理范疇，這一點還有很多運維團隊采用“碼人”的方式：一個監控班，7x24值班，人為處理和通知。

而對于 CA 的用戶來說即可用技術的方式實現：CA 可以通過分派策略、通知策略以及排班機制等，實現告警的靈活通知。【自定義分派策略】可以進行流程的設計，根據級別、應用設置對應的一、二線負責人，以及處理時限，超時未響應（確認告警）自動升級。

【自建排班規則】7x24 小時緊繃狀態不是誰都能扛得住的，適當輪班緩解下壓力。CA 中可以通過排班機制，實現白夜班、按周等模式進行輪流值班。

多渠道通知必達

再好的流程和設計，如果沒有及時收到通知并處理，那么整個運維團隊仍然會很郁悶的，關于告警的最后一公里的問題更是至關重要！

目前被運維團隊選擇最多的就是以下這幾種方式：

當然如果您正在使用我們的 CA 平臺，可以根據您企業的自身使用習慣，選擇電話、短信、微信、郵件、APP、釘釘、企業微信、飛書、JIRA 等通知方式，也可以根據自身需求，設置指定級別的告警使用不同的通知方式，也可以自定義工作時間，讓告警在不同的時間段，用不同的通知方式。

告警智能化去重降噪

如果您前 3 步都已經完成了，那么這里面還存在一個問題，就是當告警大規模觸發時，特別是遇到告警風暴的話，很容易撐爆郵箱或者是手機短信了，所以接下來就聊下告警風暴規避的問題。這個問題比較大，基本上有些監控工具做了一部分，但是目前來看這還是一個難點：

目前，在 CA 平臺中對于接收到的所有告警第一步就是自動去重，就是根據告警的 Event ID 來判斷是否合并，Event ID 相同的告警就會自動合并到主告警之中，這樣的告警只會通知主告警，直到告警恢復/關閉。

當然 CA 并不滿足于此，目前 CA 支持的智能降噪包括時間窗口智能降噪和實時智能降噪的通知前降噪以及高聚合智能算法和仿閱讀智能算法的通知后降噪。這里面包括實時計算和離線計算，算法方面參考了相似度、決策樹、分類等算法。以相似度來說：首先采集告警的多維度信息，包括時間、主機、服務、分組 hostgroups、應用 applications、標簽 tags 等基本維度信息，計算不同告警之間相似度，如果達到閾值，如告警 A 和告警 B 有70%相似就關聯起來。以相似度為例因為根據業務不同，各維度的權重，閾值靈敏度有些差異。

事件單記錄和團隊協作處理

如果告警量很大，告警后續處理和跟蹤往往會依賴于外部團隊（部門外或公司外）。但是監控告警粒度太細了，可能很多告警都是一個事情。如上面的告警風暴中，由于應用程序故障，引發引發了大量的異常，之后又產生連鎖反應，其實就是一個事件，只需要處理一個事情就行。一般來說一線人員會采用郵件或者電話方式，直接通知對應負責人，但是這個就很難追蹤和事后分析，所以一套事件管理機制。ITIL規范的事件 Incident 流程很有參考價值，事件工單需要：