摘要:編者按本文作者為,主要介紹告警疲勞的產生原因與對抗告警疲勞的種方法。告警疲勞不僅會影響團隊成員的工作情緒,而且會阻礙軟件交付鏈的成長。利用工具事件管理工具對抵抗告警疲勞大有幫助。
【編者按】本文作者為 Chris Riley,主要介紹告警疲勞的產生原因與對抗告警疲勞的8種方法。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。
各司其職、孤軍作戰非常不利于團隊溝通,一旦發生重大事件,各個部門就很難掌握事件始末,這不僅降低了整個開發團隊的溝通質量,而且對運維工作也造成了極大困擾,即告警疲勞。告警疲勞不僅會影響團隊成員的工作情緒,而且會阻礙軟件交付鏈的成長。
DevOps 的最大優勢是清除溝通障礙并簡化運維操作。通常,DevOps 團隊有兩種類別:一種是面向所有應用程序的集中式團隊,另一種是面向每個應用程序或核心服務的去中心化團隊。前者規模較大,但是比傳統的NOC環境要小,而后者則是很小的團隊。
DevOps 團隊除了負責維護基礎設施以外,有時還要管理發布過程,以及維持生產的正常運行。而最后這項工作是最傷腦經也最耗時的,一旦處理有誤就會影響到整個環境。雖然沒有人愿意值班待命,但我們還是得這樣做,因為平均修復時間(MTTR)越短,問題響應越迅速,接下來的幾天甚至幾周里,大家的日子都會好過些——最重要的是它能維持業務的正常運轉。
但是,一旦值班開始影響到團隊情緒并占據運維團隊大量的時間,就可能招致巨大的風險——集中式團隊和去中心化團隊很容易產生告警疲勞。集中式團隊的疲勞不僅是要解決所有應用上的大量告警,而且還很難找到合適的人來解決問題,因為值班的人很有可能沒法解決告警的問題。至于去中心化團隊的告警疲勞,主要是由于團隊太小而告警太多所致。
告警疲勞對DevOps和IT運維團隊的影響主要體現在四個方面:
士氣低落:如果大部分時間都用于解決問題,你不僅要沒日沒夜地處理事件,而且所做的事情越來越無聊,感覺每天就是滅不完的火,這樣很容易磨滅團隊的溝通熱情,導致工作效率降低。
單點故障:在集中式團隊中,MTTR 主要取決于運維人員通過一組非常有限的值班操作來響應問題并確定根本原因的速度。在去中心化團隊中,確定根本問題的時間會有所增加,但是由于掌握的信息不足,運維人員無法準確地篩選問題并快速解決。再有就是,由于呼叫列表太短,很有可能根本無法解決問題。因此,一旦有問題產生,這些因素都會造成運維瓶頸和單點故障。
機會成本:這是告警疲勞所造成的影響中最容易被忽略的一點——整個團隊和交付鏈所耗費的成本增加。如果你的 DevOps 團隊在告警過程中不堪重負,他們就無法完善和創新交付鏈,因為他們只會機械地響應,沒有精力去開發更好的版本、完善基礎設施的自動化過程或主動預防未來的問題。這不僅阻礙了團隊進步,而且增加了技術成本,因為經常重復的問題并沒有真正得到解決。
發布速度延遲:解決問題所耗費的時間越長,發布速度就越慢。仔細想想你們團隊有多少次推遲了發布時間?
應對告警疲勞最簡單的方式是擴大運維團隊,但是這未必是最好的選擇,因為有些情況下我們也確實需要小一點的DevOps團隊。
所以,建議大家在與告警疲勞作斗爭時試試以下8個方法:
創建更好的升級策略:計劃!不要只是給團隊創建一個呼叫列表,你要考慮告警疲勞可能會對團隊資源和士氣造成哪些影響,然后再制定相應的計劃和策略,也許很小的變動就能帶來極大的幫助,比如打破循環。
安排 QA 和開發人員值班:這需要整個團隊全員上陣,雖然做起來很困難,但是如果你把 QA 團隊和開發人員安排到值班工作中,你獲得的信息就更完善,解決問題的速度也更快。他們即便是與運維團隊的成員并行工作,其效果也可見一斑,因為更廣泛的支持不僅可以提高生產問題的可見性,幫助開發人員解決應用程序的相關問題,而且還可以加強了解,防患于未然。
進行詳細的事件分析:通過事件分析評估告警設置的效果可以讓你隨時改進設置并發現當前存在的瓶頸。同時,數據還可以指出重復性問題。總之,要充分發揮數據的指導性作用。
安排時間以終結重復性問題:分配一定的時間確定之前快速修復的問題并徹底解決,以確保將來不再重復。但是要將問題及所有后續問題完全消滅,這對運維團隊而言是個艱巨的任務。
標準化通知規則:不要讓值班成員任意設置自己的規則,一定要將規則標準化或模板化,以保證一致性和問責制。
允許平行告警:除了垂直呼叫以外,還要有平行告警,這樣多個團隊成員就可以共同攻克問題以縮短MTTR。
利用工具:事件管理工具對抵抗告警疲勞大有幫助。一個好的事件管理解決方案,例如 PagerDuty、OneAlert ,不僅可以幫助你自動處理告警并過濾告警噪音,以防止無關緊要的告警造成過重的負擔;而且還能協助你找準告警以采取更加有效的值班操作。此后,要是在晚上出現告警,你就知道真的出了問題。
優化代碼:提高代碼質量可以減少宕機。這其實很簡單,但又總是被忽略。所以,一定要花時間優化代碼、提高測試覆蓋率、完善系統測試和測試自動化,并將收獲和成果向所有成員展示。
以上這些方法都可以優化運維性能,并且受益面廣。總而言之,告警疲勞是確實存在的問題,它不僅會影響 DevOps 和 ITOps 團隊的幸福感,而且會影響整個開發團隊創新和完善發布代碼的能力。
本文系 OneAPM 工程師編譯整理。OneAlert 是 OneAPM 旗下產品,是國內第一個 SaaS 模式的云告警平臺,集成國內外主流監控/支撐系統,實現一個平臺上集中處理所有 IT 事件,提升 IT 可靠性。想閱讀更多技術文章,請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/7975.html
摘要:例如,把提示無效信用卡賬號的告警替換為一個可執行的告警,比如指示用戶支付成功率急劇下降的告警可能系統會做出較大的變化,需要回滾操作。因此,不斷完善告警也是同樣非常重要的,所以要養成定期瀏覽和刪除不可執行告警的習慣。 對于運維團隊而言,很多告警其實并不能幫助他們解決掉實際的問題,相反有時會加重多余的負擔,這主要是因為大多數的告警并不具備足夠的可執行性: 它們指出的問題壓根兒不需要響應 ...
摘要:月,卡耐基梅隆大學的程序在一對一不限注的撲克比賽中,擊敗了一組的德州撲克職業選手。概述擊敗人類冠軍的三件事的深藍,由卡內基梅隆大學開飯,在年的復賽中擊敗國際象棋世界冠軍卡斯帕羅夫。年,奧克蘭大學發布。 2017年是AI在撲克上取得突破的一年,在AI的發展歷史上,具有里程碑的意義。1月,卡耐基梅隆大學的 AI 程序在一對一不限注的撲克比賽中,擊敗了一組的德州撲克職業選手。出乎所有人的意外,這一...
摘要:在那些緊迫的告警中,找出需要立即處理的告警更則難上加難。是應用性能管理領軍企業公司旗下產品,也是國內首個模式的云告警平臺,集成國內外主流監控支撐系統,實現一個平臺上集中處理所有事件,提升可靠性。 在 OneAlert,我們經常與運維團隊聊天。因為產品開發過程中,這樣的對話有助于了解客戶的真正痛點。「告警垃圾」——監控系統中時常涌現的告警洪流,是運維團隊經常提到的一大痛處。 至于其原因,...
摘要:為了掌握你的告警事件響應時間,在你已經開始處理告警時,強烈建議及時響應認領,例如通過移動端微信頁面移動等方式及時認領。這一點國外做的很棒,在短信電話移動都可以很容易確認認領在微信端可以認領和關閉。 這是《運維不容錯過的4個關鍵指標》的姐妹篇,上篇文章介紹了優秀運維團隊需要關注的4個關鍵指標,我們分享了平均恢復時間 MTTR、平均響應時間 MTTA 等概念。這篇是介紹一些實踐方法,更好的...
摘要:平均解決事件解決時間是衡量業務準備的最佳標準。平均每小時折合損失。說明整個團隊的響應及時率是不錯的。小結致力減少告警數量及時響應如果不能及時響應,能夠升級處理,最終提升解決時間,個核心關鍵指標是運維支撐工作非常關鍵的指標。 很難說,生活在這個數據大爆炸的時代對運維同學是福還是禍。靈活的監控系統、開放 API 和易用的數據可視化資源可以將任何想要的數據圖表化地顯示出來,但是,過多的數據容...
閱讀 1357·2021-09-02 10:19
閱讀 1101·2019-08-26 13:25
閱讀 2108·2019-08-26 11:37
閱讀 2413·2019-08-26 10:18
閱讀 2676·2019-08-23 16:43
閱讀 2989·2019-08-23 16:25
閱讀 775·2019-08-23 15:53
閱讀 3297·2019-08-23 15:11