各類監控系統都會產生告警事件，於是，就產生了 FlashDuty、PagerDuty、Opsgenie 這類產品，做告警事件的收斂降噪、排班認領升級等。如果你想增強自己公司的告警事件處理能力，參考（chao xi）這些產品的功能就可以了 😎。
-
告警整合：目標是在一個Oncall平臺上處理所有告警，一般常見的監控工具，都有對接webhook的能力，因此Oncall平臺可以對不同監控工具進行介面適配，提供一個相應的webhook，對使用者來說配置成本最低。還有一些不那麼開放的監控工具，可能只對外提供了發郵件通知的方式，如果Oncall平臺能夠接受這些郵件並對內容進行解析的話，也是一種兜底的告警整合方式。
-
標籤增強：告警資訊中的標籤越豐富，工程師在接收到告警的時候處理起來就更高效。現實情況中很多監控工具傳送出來的告警只有光禿禿的有限的幾個欄位，比如機器名、監控項、閾值，如果能對接外部後設資料（比如CMDB），對告警的欄位進行擴充，那就可以利用擴充出來的欄位，更自動化的分發告警，以及在處理故障的時候，讓工程師能快速判斷告警的影響面和嚴重程度。
-
聚合降噪：對相似的告警進行聚合、對頻發的告警進行收斂，能夠顯著降低告警數量，減少對工程師的無效打擾。基於規則、基於語義相似度都是可行的聚合方式。告警的聚合，可以跨監控資料來源，比如來源於Zabbix的告警和來源於Prometheus的告警，如果“相似”，就可以聚合。
-
告警抑制：可以是高階別的告警抑制低階別的告警，也可是底層基礎設施的告警抑制上層模組的告警，總而言之是引入了“某種依賴關係”。這些依賴關係的維護成本較高，且不容易解釋，不推薦大規模場景重度使用。
-
值班排班：目的是避免整個團隊被經常性打斷。日常值班、節假日值班、臨時調班、公平輪換都是排班時要考慮的因素，值班輪換交接時，要有清晰的通知機制。值班人也要有角色的概念，比如主備值班人。
-
認領：理論上來說，所有的告警都需要被認領。如果一個告警傳送出來後，沒有人認領，也沒有產生任何不良的後果，那這個告警是無意義的，就不應該傳送出來。通常會用 MTTA 量化告警認領的效率和效果。
-
升級/轉派：針對不同等級的告警，提前建立清晰的升級路線，會降低Oncall工程師心理壓力，有助於快速、準確的解決問題。告警升級可以是手動升級，也可以是自動升級，比如當某個告警超過30分鐘未被處理，且未恢復，那麼就自動升級到主管或者備份人員，確保問題最終得到及時的處理。
-
協同：在告警處理的過程中，可以隨時把相關的人員拉進來協同（通常，把相關人員拉齊，問題就解決了一半，如果能自動建立 warroom 就更好了），新增協同人時需要準確及時的通知到對方，並把告警處理的過程和時間線，清晰的保留下來，供協作方快速瞭解全貌。
-
通知：國外Slack可以連線巨大的周邊生態，很多協同工作是在Slack中完成的，說是協同領域的作業系統也不誇張；在國內那就是企微、飛書、釘釘三足鼎立了，這些IM支援開發應用，在這些內建應用中接收告警、認領、關閉、轉派、處理，是提升Oncall體驗的關鍵方法。移動辦公的體驗感，用過都說好。
-
統計分析運營：告警壓縮率、MTTA、MTTR、告警認領比例、告警數量是衡量Oncall效率的關鍵指標，透過按業務、按團隊、按個人等維度分析以上指標，能夠有效的推動告警的最佳化和治理工作，讓Oncall更有效率。
這類產品缺少開源專案，可能是隨著越來越多的開源作者養家餬口都困難，沒人願意用愛發電了。如果有預算，建議上 FlashDuty，我覺得這是東半球最好用的 OnCall 產品。