如果在運維工作中收到非常多的告警信息，影響了本身的運維工作，應該從哪幾個方面進行優化和改善？
這些多本身如果都是不同類別都需要單獨處理的，那就可能是你確實幹的很爛，或者報警閾值設的有問題。如果很多是重複的，或者說有連帶依賴關係的，看一條後面就不用再收了的，那麼你就需要重新去考慮你的報警邏輯設置，nagios的parent啊period啊delay啊escalation啊downtime啊是不是都合理。如果不是nagios或者說監控軟體上不合適做這個，那麼你可以自己管理好簡訊貓這邊，一般都是插入一個MySQL這樣，那麼不要讓告警直接寫庫，中間寫個小server緩衝一下，類似的報警打個tag做個歸併也能省很多事。不過這方面建議用nagios啦~Etsy說過：一切監控軟體最終都做成nagios的樣子。
告警信息，需要定製，重點關注以下的內容。
- 哪些業務需要告警？
- 哪種故障需要告警？
- 告警等級如何劃分？
- 故障依賴關係如何定義？
- 告警信息如何彙集？
- 如何做到精準有效的告警？
最終的目的就是少收告警信息，自動處理故障，自動恢復服務，當然，這是一條漫長的路。
如果不解決以上問題，將會被告警信息所淹沒，最終如題主所言，影響運維工作。===================================================================對於監控的告警信息，處理的好，將會提高我們的故障響應速度，處理的不好，會影響我們的工作情緒，適得其反。試想，當一天收到1000封告警信息，是否還會去逐一查看監控告警信息？是否還能分辨是否重大故障，還是一般故障？
對於誤報，漏報，會讓人對信息的警覺性放鬆，時間久了，還會導致對接收監控信息有反感。所以，對於監控告警信息的發送，是一件特別慎重的事情。總結一下，對於監控告警信息，我們有以下的需求：
- 基於業務類型，將告警信息發送給相應的業務用戶，例如IDC人員，WEB運維，CDN運維，網路運維，不同的人員管理不同的設備，因此需要把故障發送給相關用戶處理。
- 基於故障級別，對一個故障，將不同的故障級別發送給不同用戶，例如5分鐘內的故障發送給運維一線人員，10分鐘發送給運維部門主管，30分鐘發送給運維部門經理。重特大故障發送部門相關領導。
- 基於時間發送，比如業務維護期，告警無需發送。
- 故障的相關依賴關係，當A服務發生故障時，發送一般告警，當A，B服務故障時候，發送業務故障告警。
- 對出現故障的服務嘗試用相關命令或者腳本進進行操作處理，嘗試自動恢復，例如重啟服務，重啟伺服器等。
首先，我們要明確告警信息對於運維人員的意義何在？
不論是通過摩卡/orin或者開源osa/cacti/nagios這類開源IT監控軟體發送的告警信息，都是提供給運維人員當前系統運行遇到什麼問題，提供即時甚至帶提前量的重要訊息，從而讓運維人員有了耳目，不至於一直充當滅火隊員角色。我們離不開告警信息，那麼題主的問題，常見的處理方式是什麼？1.監控軟體合理設置告警閥值，如何設置？
網路設備方面核心設置接收信息以上，接入層設備設置只接收告警以上。伺服器方面經常變化數據如（內存/CPU/IO/）取一日/一周/一月監控下來的平均量，最大數值為提示，高於最大數告警。非經常變化的數據如（總硬碟分區大小/網卡/CMDB配置）取能接受的最頂值作為紅線告警比如硬碟分區C佔用90%提醒，95%告警。
記住一個原則：如果報警發給了 一個 不能短期內解決問題 的人。 那麼應該反思這個報警是否有合理的必要。
告警目的是為保障業務可靠性，我在《運維不容錯過的4個關鍵指標》整理了4個關鍵性運維指標，懶得敲了，直接copy：告警事件數量
如果團隊中的事件數量呈現上升趨勢，那麼很有可能是哪裡出了問題：要麼是基礎設施有故障，要麼是監控工具配置錯誤需要調整。
隨著公司的發展，組織結構會調整，同時業務產品也會不斷升級，配套監控也會同步上線，告警事件數量會急劇增加。「我們浪費了大量時間來關閉冗餘報警。」－－相信很多同學都會有類似的體會。告警事件數量是可控的：
- 告警數量可統計，如這周告警數量是多少，與新發布的產品系統有沒有關係，發生哪些問題？
- 告警數量是可操作的，意味著每一個告警都是有意義並且是需要處理和操作的，如果僅僅是瞅一眼的數據，請不要通過告警方式。例如100＋機器時，每台機器的「CPU 使用率高」告警是沒有啥用的，你知道機器 CPU 使用率高後，你能做什麼操作呢？你可能直接忽略掉，當數量大到你把需要處理的告警也忽略掉時，告警就失去了意義。類似指標完全可以通過周報／日報進行數據的性能分析，而不是告警。
所以樓上的告警多，是需要優化的。記得我早期在nokia時代，一天收上千簡訊，基本上不看，就和不告警一樣。
平均解決時間（ MTTR ）解決時間是衡量業務準備的最佳標準。當事件發生時，你的團隊需要多長時間才能解決？ 宕機不僅會影響你的收入，還會傷害客戶用戶體驗和忠誠度，所以確保團隊對所有事件可以快速響應極為關鍵。
- 牛叉如BAT、AWS、google每年都發生多次嚴重故障（挖掘機立功了），但都能較快（相對嚴重程度來說）解決掉。
- 全球500強企業平均每周出現嚴重故障時間長達1.6小時。（有數據跟老闆說了，別怪我）
- 平均每小時摺合損失$96,000。
當然，跟蹤解決時間固然重要，但對其進行規範往往很難，根據環境的複雜性、團隊和基礎設施的責任制、行業及其他因素， MTTR 的有較大差異。但是，規範化的操作手冊、自動化的基礎設施管理、可靠的告警升級策略都有助於減少事件，和提升 MTTR。
優秀的團隊減少事件數量，並及時解決（ MTTR ），所以平均解決事件需要和上面告警數量一樣，需要記錄和統計分析，目前大多監控工具往往不具備類似能力，如果沒有精力或者資源自行開發的話，我們就建議使用第三方雲告警平台。
有關如何減少事件數量，避免告警疲勞的事情，後續將會有獨立文章進行發布。
平均響應時間（ MTTA ）如果說平均解決時間是結果，那麼平均響應時間就是重要的過程指標，這一點往往被大多團隊忽略掉。可以理解為告警越快發現，越快有人響應，就能夠越快的解決（更好的MTTR）。
提升 MTTA 的核心是找對人、找到人。上圖中如果02:01能夠及時通知到位就可以節省至少4個小時時間。
說起來簡單，實際上找對人有些工作（只1人運維的請忽略），一般是從職責責任制、協調機制、工作進程透明、工作量和時間可衡量等幾點進行，後面針對「有序分派」再補充一篇。
除了以上機制，還有一點，就是需要記錄誰什麼時候確認響應告警，並做了哪些處理，能夠持續跟蹤，以及統計分析。
響應時間非常重要，因為它能幫助你了解哪些團隊和個人處於隨叫隨到的狀態。快速響應時間是一個戰備文化的代表，你會發現具備快響應觀念和工具的團隊往往可以更快地修復事件。
如果使用像事件管理系統，[升級超時]有助於推進響應目標。例如，如果你希望所有事件都應該在5分鐘內回復，可以將超時設置為5分鐘，從而確保下一個接收人會收到提醒。再根據團隊的整體表現，來決定是否需要調整目標，然後再跟蹤升級事件的數量。
升級對於大多數使用事件管理工具的組織而言，告警升級是一種異常現象，該跡象表明首次應該響應的時候，無法及時應對事件，或許相關工具和人員技能失效。升級策略是事件管理的必須，各個團隊應努力推動升級，實現升級事件數量的下降。
優秀的運維團隊需要建立起有效的一線、二線、甚至三線響應機制，告警及時通知到一線，如果一線沒有及時處理，可以自動升級至二線運維，保障每一個重要事件能夠得到及時響應和處理。
有些情況下，升級是標準作業實踐的一部分。例如，你可能有一個 NOC，一線支持團隊或者自動修復工具，可根據內容來升級或分診輸入事件。這種情況下，一線更多像一個路由轉發器，可以通過人工＋工具自動化方式實現。
示例分析這是某個團隊一個月的告警數據剖析：
告警數量在11-18前相對穩健，平均在3-5個告警。第3周告警突飛猛進，原因是新的業務上線，引發突增。經過周回顧，優化監控策略，在第4周經過初步優化，告警數量有所降低，運維團隊工作初見成效，還需要繼續優化。
告警響應時間 MTTA ，基本上都能夠比較好的響應，基本在5分鐘內響應。說明整個團隊的響應及時率是不錯的。同時也看到在第3、4周六的時候，明顯的響應時間延遲較大，說明一個問題，周末的支撐工作有提升空間。
恢復時間 MTTR ，基本保持在20分鐘左右，說明恢複比較及時，但是也有可能存在事件無需關注，自動恢復。後者需要針對事件的類型、根源進一步分析，後續文章再剖析。
升級，目前該團隊基本上是5分鐘升級，所以會看到在大部分問題能在5分鐘內響應完成。
小結
致力減少告警數量、及時響應 MTTA 、如果不能及時響應，能夠升級處理，最終提升解決時間 MTTR，4個核心關鍵指標是運維支撐工作非常關鍵的指標。運維是結合管理流程、工具、人員三方面的綜合化工作，目前市面上的類似SaaS雲告警平台有幾個：國外的 PagerDuty , VictorOps , OpsGenie ,國內OneAlert ，感興趣可以去度娘。我思想很直接，把問題都處理乾淨了就沒有告警了。或者告警就不應該發給對告警簡訊感覺厭煩，或影響了他正常工作的人。
我就納悶了，題主問題很簡單，就是如何解決告警風暴的問題，結果看了一堆答案都是在講概念、講意義 (╯‵□′)╯︵┻━┻ 都放著我來！
既然告警多，那就「拉閘」過濾掉沒用的啊！以我們在百度系統部多年的經驗，至少需要以下三道閘啊！
第一道閘：風暴限速
直接簡單粗暴的限制每分鐘可推送的簡訊、電話數量。例如設置簡訊每分鐘最多20條，電話每分鐘最多5通！第二道閘：合併相似報警
同一個告警通通給我合併成一個報給我，想幾分鐘合併一次我說了算！第三道閘：相似關鍵詞合併
像「鏈路」這樣的告警，就不要老給我報啦。把「鏈路」設做合併關鍵詞，有這個詞的告警，通通給我站好，合成一個報給我！哈哈，爽歪歪！什麼，你以為我在YY？我說我們已經把這些「閘」做好了，你信不信？
信不信點下面註冊就知道了！免費！
LinkedSee(靈犀雲告警) - IT告警一站式管理平台|Zabbix報警|OpenFalcon報警
總結一下，對於監控告警信息，我們有以下的需求：
- 基於業務類型，將告警信息發送給相應的業務用戶，例如IDC人員，WEB運維，CDN運維，網路運維，不同的人員管理不同的設備，因此需要把故障發送給相關用戶處理。
- 基於故障級別，對一個故障，將不同的故障級別發送給不同用戶，例如5分鐘內的故障發送給運維一線人員，10分鐘發送給運維部門主管，30分鐘發送給運維部門經理。重特大故障發送部門相關領導。
這倆需求我們用的是靈犀linkedsee雲告警+zabbix結合的，價格是500每月，還行。支持簡訊和語音電話。需要了解可以私信我。
其實可以通過對告警進行降噪處理，不只是關鍵詞合併balabla的。但是基於運維的問題經常會有層級關係，比如A導致B導致C，其實就是A的連鎖反應，但是他會出來3條告警，這就是冗餘的。。。 我知道一家可以通過AI解決這個問題的公司，如果你要是有興趣了解，可以單聊~
你看不看這些報警？如果不看的話為什麼要讓它報？這些報警是應該運維人員看還是對應的應用的負責人看？
個人認為運維是保持環境系統穩定按照流程規範操作
而樓主遇到系統報警較頻繁可以跟自己的老大溝通或者和甲方溝通拉著系統集成商或廠商討論下這個解決方案
蘿蔔坑不需要兔子腿填
1. 無用告警去掉，反正告警了也沒人管的告警有啥用？2. 優先順序設置好，對不緊急的告警設置好優先順序，可以白天處理的決不晚上鬧。3. 警報只發給能處理的人
直接了當，錯都報了就想辦法處理該加設備就加設備，該壓榨性能就壓榨用戶量上去了老闆都摳門就趕緊找下一份工作
直接使用靈犀雲告警就好了呀，可以通過關鍵字智能合併告警信息
推薦閱讀：
※有關lnmp或lamp搭建方式的疑問？
※跪求Linux發展方向？
※做Linux運維需要考一些證書嗎？如果是，需要考什麼樣子的，費用如何？
※生產伺服器的高危操作有哪些？