对抗告警疲劳的8种方法
【編者按】本文作者為 Chris Riley,主要介紹告警疲勞的產生原因與對抗告警疲勞的8種方法。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。
各司其職、孤軍作戰非常不利于團隊溝通,一旦發生重大事件,各個部門就很難掌握事件始末,這不僅降低了整個開發團隊的溝通質量,而且對運維工作也造成了極大困擾,即告警疲勞。告警疲勞不僅會影響團隊成員的工作情緒,而且會阻礙軟件交付鏈的成長。
DevOps 的最大優勢是清除溝通障礙并簡化運維操作。通常,DevOps 團隊有兩種類別:一種是面向所有應用程序的集中式團隊,另一種是面向每個應用程序或核心服務的去中心化團隊。前者規模較大,但是比傳統的NOC環境要小,而后者則是很小的團隊。
DevOps 團隊除了負責維護基礎設施以外,有時還要管理發布過程,以及維持生產的正常運行。而最后這項工作是最傷腦經也最耗時的,一旦處理有誤就會影響到整個環境。雖然沒有人愿意值班待命,但我們還是得這樣做,因為平均修復時間(MTTR)越短,問題響應越迅速,接下來的幾天甚至幾周里,大家的日子都會好過些——最重要的是它能維持業務的正常運轉。
但是,一旦值班開始影響到團隊情緒并占據運維團隊大量的時間,就可能招致巨大的風險——集中式團隊和去中心化團隊很容易產生告警疲勞。集中式團隊的疲勞不僅是要解決所有應用上的大量告警,而且還很難找到合適的人來解決問題,因為值班的人很有可能沒法解決告警的問題。至于去中心化團隊的告警疲勞,主要是由于團隊太小而告警太多所致。
告警疲勞對DevOps和IT運維團隊的影響主要體現在四個方面:
- 士氣低落:如果大部分時間都用于解決問題,你不僅要沒日沒夜地處理事件,而且所做的事情越來越無聊,感覺每天就是滅不完的火,這樣很容易磨滅團隊的溝通熱情,導致工作效率降低。
- 單點故障:在集中式團隊中,MTTR 主要取決于運維人員通過一組非常有限的值班操作來響應問題并確定根本原因的速度。在去中心化團隊中,確定根本問題的時間會有所增加,但是由于掌握的信息不足,運維人員無法準確地篩選問題并快速解決。再有就是,由于呼叫列表太短,很有可能根本無法解決問題。因此,一旦有問題產生,這些因素都會造成運維瓶頸和單點故障。
- 機會成本:這是告警疲勞所造成的影響中最容易被忽略的一點——整個團隊和交付鏈所耗費的成本增加。如果你的 DevOps 團隊在告警過程中不堪重負,他們就無法完善和創新交付鏈,因為他們只會機械地響應,沒有精力去開發更好的版本、完善基礎設施的自動化過程或主動預防未來的問題。這不僅阻礙了團隊進步,而且增加了技術成本,因為經常重復的問題并沒有真正得到解決。
- 發布速度延遲:解決問題所耗費的時間越長,發布速度就越慢。仔細想想你們團隊有多少次推遲了發布時間?
應對告警疲勞最簡單的方式是擴大運維團隊,但是這未必是最好的選擇,因為有些情況下我們也確實需要小一點的DevOps團隊。
所以,建議大家在與告警疲勞作斗爭時試試以下8個方法:
以上這些方法都可以優化運維性能,并且受益面廣。總而言之,告警疲勞是確實存在的問題,它不僅會影響 DevOps 和 ITOps 團隊的幸福感,而且會影響整個開發團隊創新和完善發布代碼的能力。
本文轉自 OneAPM 官方博客
總結
以上是生活随笔為你收集整理的对抗告警疲劳的8种方法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: eclipse创建maven多模块项目(
- 下一篇: MySQL使用详解--根据个人学习总结