對抗不可執行告警的四種措施

對於運維團隊而言，不少告警其實並不能幫助他們解決掉實際的問題，相反有時會加劇多餘的負擔，這主要是由於大多數的告警並不具有足夠的可執行性：

• 它們指出的問題壓根兒不須要響應

• 它們缺乏關鍵的信息，迫使你須要花費很長的時間去尋找更多的源頭，用以來估量它們的緊迫性

過量的不可執行告警會形成告警疲勞，浪費時間和資源，從而耽誤你解決實質性的問題，可能這些已經在你身邊正悄無聲息地發生着：

• 你是否自動忽略收到的多餘告警？

• 你是否收到不少與你無關的告警？

• 每當你收到告警時，是否爲了得到你真正須要的信息而採起一系列常規的行動？

若是有以上這樣的狀況，就能肯定你是在遭受着告警疲勞，本篇將會列出四種常見的不可執行告警及其解決辦法。

一、無益的標題

問題：標題是告警的重要組成部分，由於它是你第一眼看到的東西。含糊不清的標題會迫令人們爲了獲取更多的信息而對告警主體進行沒必要要的挖掘，而當不一樣的告警使用類似的標題時，會使你感到更加沮喪、困惑，致使時間和精力上的浪費。

例子：在收到標題爲「CPU LOAD 1.90」的告警後，你又收到一個標題爲「CPU LOAD 1.80」的告警。這倆告警是不是關於同一個服務器的呢？負載1.80是否關鍵？這個問題會有什麼影響？若是告警能提供解答而不是添加更多的問題，豈不是更好嗎？

改進措施：全部的告警標題都應該簡短且具備必定的描述性，它們應該讓人在看到第一眼的時候就知道問題是什麼，出如今哪裏而且須要怎樣去解決。例如「Server billing-1 load is critical for 5 min」就比「CPU LOAD 1.80」更具備執行性。

二、缺乏必要信息

問題：告警的內容一般是有限或者模糊的，致使咱們爲了獲取更深層次的理解，每每會花費大量的時間去解讀這些告警，以求查找到更多的信息。有時，在 Nagios，Graphite，Pingdom 或 New Relic 的某處發現了相關的信息，但實際上大量的時間並非用在瞭解決問題上，而是花在了尋找上面。

例子：在解決服務器過載問題時，你們都是使用着差很少的套路：譬如鏈接服務器，查看 load 值等。並且，下次一個類似的告警發生時，你還得一次次地執行這些相同的步驟。

改進措施：咱們熟練的打開操做系統鍵入問題信息，來追蹤那些告警的源頭去進行總體考量。假如告警信息這個載體能呈現給咱們更多有用的源信息的話，好比：執行的行爲或者相關資源的連接（這些資源包括腳本、協議或者研發者對問題發生緣由的理解），那麼對於決策和追蹤排查的效能就會有很明顯地提高.

三、不須要解決的告警

問題：生產環境是複雜且動態的。爲了保持系統的穩定性，運維和研發團隊須要讀取到重要的系統信息。直覺告訴咱們，這須要將每一個告警和異常通知都給到這些人，然而實際上，大多數的告警收到後並無採起有效措施，而且還時常會把有用的告警覆蓋掉。

例子：用戶輸入無效的信用卡帳號，會當即發送告警，這個信息應該很是值得關注纔對。但咱們不能控制用戶的行爲，因此通常狀況下這個告警只是額外的噪聲而已，對此咱們也毫無辦法。

改進措施：若是收到告警後不能當即採起行動，那就別發送它，而去找到須要你作出反應的問題。例如，把提示無效信用卡帳號的告警替換爲一個可執行的告警，好比指示用戶支付成功率急劇降低的告警———可能系統會作出較大的變化，須要回滾操做。另一種解決辦法是採用每日或每週報告，彙總不須要實時處理的信息。這樣，真正有用的信息就能夠實時地被接收來處理。

四、告警分派選擇

問題：在不少公司中，每一個人都接收着全部的告警———這種工做模式一般用於小團隊，每一個人都參與着全部的事情。然而，當團隊規模變大，人們開始分工時，「告警風暴」很快就變成了拖累。

例子：咱們使用的第三方支付提供的數據庫鏈接出現了問題，此時交給DBA團隊處理並不能很好的FIX掉問題，還頗有可能由於其餘緣由被忽視。

改進措施：只向和告警相關的人發送告警。因爲告警會由多個不一樣的來源致使，在這些狀況下，咱們能夠爲每一個來源建立特定的告警，選擇指定的路徑，使決策更加合理化。

結論：

具備執行性的告警能夠大大減輕你的痛苦，提升天天的工做效率。經過上面提到的簡單改變，能夠產生巨大的影響。在現在快節奏的環境中，可執行的告警也許很快就變得不相干了。所以，不斷完善告警也是一樣很是重要的，因此要養成按期瀏覽和刪除不可執行告警的習慣。

在 OneAlert，咱們重點幫助你更好地管理、追蹤、休止和分派你的告警，固然若是你有其餘對抗告警可執行性地措施，也歡迎在評論區留下你寶貴的意見。

本文轉自 OneAPM 官方博客