對抗告警疲勞的8種方法

【編者按】本文作者為 chris riley，主要介紹告警疲勞的產生原因與對抗告警疲勞的8種方法。文章系國內 itom 管理平台 oneapm 編譯呈現。

各司其職、孤軍作戰非常不利於團隊溝通，一旦發生重大事件，各個部門就很難掌握事件始末，這不僅降低了整個開發團隊的溝通質量，而且對運維工作也造成了極大困擾，即告警疲勞。告警疲勞不僅會影響團隊成員的工作情緒，而且會阻礙軟體交付鏈的成長。

devops 的最大優勢是清除溝通障礙並簡化運維操作。通常，devops 團隊有兩種類別：一種是面向所有應用程式的集中式團隊，另一種是面向每個應用程式或核心服務的去中心化團隊。前者規模較大，但是比傳統的noc環境要小，而後者則是很小的團隊。

devops 團隊除了負責維護基礎設施以外，有時還要管理發布過程，以及維持生產的正常執行。而最後這項工作是最傷腦經也最耗時的，一旦處理有誤就會影響到整個環境。雖然沒有人願意值班待命，但我們還是得這樣做，因為平均修復時間（mttr）越短，問題響應越迅速，接下來的幾天甚至幾周裡，大家的日子都會好過些——最重要的是它能維持業務的正常運轉。

但是，一旦值班開始影響到團隊情緒並佔據運維團隊大量的時間，就可能招致巨大的風險——集中式團隊和去中心化團隊很容易產生告警疲勞。集中式團隊的疲勞不僅是要解決所有應用上的大量告警，而且還很難找到合適的人來解決問題，因為值班的人很有可能沒法解決告警的問題。至於去中心化團隊的告警疲勞，主要是由於團隊太小而告警太多所致。

告警疲勞對devops和it運維團隊的影響主要體現在四個方面：

應對告警疲勞最簡單的方式是擴大運維團隊，但是這未必是最好的選擇，因為有些情況下我們也確實需要小一點的devops團隊。

建立更好的公升級策略：計畫！不要只是給團隊建立乙個呼叫列表，你要考慮告警疲勞可能會對團隊資源和士氣造成哪些影響，然後再制定相應的計畫和策略，也許很小的變動就能帶來極大的幫助，比如打破迴圈。

安排 qa 和開發人員值班：這需要整個團隊全員上陣，雖然做起來很困難，但是如果你把 qa 團隊和開發人員安排到值班工作中，你獲得的資訊就更完善，解決問題的速度也更快。他們即便是與運維團隊的成員並行工作，其效果也可見一斑，因為更廣泛的支援不僅可以提高生產問題的可見性，幫助開發人員解決應用程式的相關問題，而且還可以加強了解，防患於未然。

進行詳細的事件分析：通過事件分析評估告警設定的效果可以讓你隨時改進設定並發現當前存在的瓶頸。同時，資料還可以指出重複性問題。總之，要充分發揮資料的指導性作用。

安排時間以終結重複性問題：分配一定的時間確定之前快速修復的問題並徹底解決，以確保將來不再重複。但是要將問題及所有後續問題完全消滅，這對運維團隊而言是個艱鉅的任務。

標準化通知規則：不要讓值班成員任意設定自己的規則，一定要將規則標準化或模板化，以保證一致性和問責制。

允許平行告警：除了垂直呼叫以外，還要有平行告警，這樣多個團隊成員就可以共同攻克問題以縮短mttr。

利用工具：事件管理工具對抵抗告警疲勞大有幫助。乙個好的事件管理解決方案，例如 pagerduty、onealert ，不僅可以幫助你自動處理告警並過濾告警噪音，以防止無關緊要的告警造成過重的負擔；而且還能協助你找準告警以採取更加有效的值班操作。此後，要是在晚上出現告警，你就知道真的出了問題。

優化**：提高**質量可以減少宕機。這其實很簡單，但又總是被忽略。所以，一定要花時間優化**、提高測試覆蓋率、完善系統測試和測試自動化，並將收穫和成果向所有成員展示。

以上這些方法都可以優化運維效能，並且受益面廣。總而言之，告警疲勞是確實存在的問題，它不僅會影響 devops 和 itops 團隊的幸福感，而且會影響整個開發團隊創新和完善發布**的能力。

本文** oneapm 官方部落格

對抗告警疲勞的8種方法

對抗告警疲勞的8種方法

對抗告警疲勞的8種方法

關閉窗體的8種方法

相關推薦