系統監控告警，是架構設計中必不可少的一部分。可很多公司，由于告警太多，工程師完全忽視告警消息，最終導致告警失效。為什么會這樣？根本原因，是分級告警策略的缺失。

啥是告警？

監控平臺發現系統異常，向系統負責人發出文字（例如，郵件/短信），色彩（有些公司，編譯不過，CI平臺會亮紅燈），聲音（有些公司，有蜂鳴器嗡嗡響，研發壓力大呀）等警示，就是告警。

絕大部分公司，主要是通過文字發出系統異常告警信息。

文字告警有哪些常見的方法？

常見有三類，成本，到達率，實時性都不一樣：

• 短信：成本高，實時性好，到達率高；
• 郵件：成本低，實時性差，到達率高；
• 釘釘/微信：成本低，實時性中，到達率中；

啥是告警策略？

絕大部分公司，可能都沒有考慮系統監控告警策略，一旦發生異常，就發郵件/短信通知系統負責人，這樣可能導致這樣一些問題：

• 同一個集群的不同實例出問題，可能會造成重復告警，浪費帶寬資源，升高短信成本；
• 系統負責人短時間內手機被告警短信刷屏，導致產生麻木感；
• 系統負責人短時間內手機，郵箱，釘釘，微信同時對一個故障告警，導致員工產生巨大壓力；
• 員工不重視告警，無法判斷告警的優先級，leader又不知情，導致事故影響擴大；

為了解決上述問題，針對不同的服務，在不同的時間段，不同的員工層級，應該設定不同的告警策略，有哪些常見的告警策略呢？

(1) 模塊告警收斂策略：當一個模塊/服務異常時，與其對應的所有接口監控，與其對應集群的多有實例，都會告警，此時，應該收斂為一個模塊/服務告警，常見的實現方式是，模塊/服務按照集群名稱做告警去重；

(2) 接口告警收斂策略：當一個模塊/服務的一個接口異常，與其對應集群的多個實例，都會告警，此時，應該收斂為一個接口告警，常見的實現方式是，按照接口名稱做告警去重；

(3) 告警頻率收斂策略：對同一個服務或者接口，應該在固定的時間內，只發送有限的告警，常見的方式是，按照1分鐘1次限制告警次數，一來降低研發的緊張感與壓力感，二來節省成本；

(4) 不同時段區分告警方式策略：工作日工作時段在公司時，通過郵件/釘釘/微信發送告警能更加節省成本；半夜或者周末發生故障時，通過郵件發送告警能保證實時性；

(5) 逐層上報告警策略：每個模塊都應該有負責人，原則上告警會發送給模塊的負責人，但如果告警連續1小時未恢復正常，告警會自動發送給系統負責人的直屬leader，如果告警連續3個小時未恢復正常，告警會自動發送給系統負責人的二級leader；

(6) 黑白跳動策略：當系統由正常變為異常，異常恢復正常，出現正反的變化時，都應該發出告警；

畫外音：額，這么人性化，是“別人家”的公司么？

知其然，知其所以然。 思路比結論更重要。