作者｜九辯
世上沒有一個系統是百分之百盡善盡美的。如果想要保證可用性，那麼技術團隊就得對服務的各種狀态了如指掌，能在第一時間發現問題且快速定位問題原因。但要想做到以上這兩點，隻能依賴完善的監控&告警體系去監控服務運作狀态，但技術團隊又不可能時時刻刻都盯着看闆并關注到所有方面。是以，告警成為團隊監控服務品質與可用性的最主要手段。
但在實踐過程中，技術團隊所擷取的告警往往不是太少了，而是太多。我們看看某跨境電商系統 SRE 每天的工作日常，或許每個工程師對此都不陌生：
- 打開通訊工具 IM，運維群的告警消息提示 99+，甚至 999+；
- 點開群檢視消息，滿屏告警标題、等級和分派人，但資訊過多無法快速篩選和确定高優先級告警；
- 挨個打開資訊，檢視告警内容并評估實際優先級，這其中包括但不限于服務逾時、網絡重傳、資料庫響應慢；
- 發現等級為“P1”的告警，檢查内容來自交易系統服務逾時，告警分派人是交易系統開發同學，開發同學檢查發現交易系統目前沒有異常，認為是資料庫問題，傳回群依次點選檢查；
- 到了公司打開告警中心系統，按告警等級高低排序再點開清單條目，分别與業務開發、網絡裝置維護和資料庫 DBA 開會溝通，綜合分析發現“交易系統服務逾時告警”是由于“網絡重傳”引起的“資料庫響應慢”。
可以看到，随着企業數字化不斷深入，IT 系統劃分、異構性都使得企業技術架構變得愈發複雜。為了更好地保障系統穩定性，也為了避免遺漏故障，技術團隊通常會在監控系統中，針對基礎設施、平台、應用設定大量監控名額和告警規則，從網絡到機器、從執行個體到子產品、再到上層業務。雖然極大提高了故障發現能力，但也很容易導緻一個異常或故障觸發大量告警，造成告警風暴。比如，一個機器發生故障時，監控機器健康度的告警規則産生報警；監控機器上執行個體運作狀态的告警規則也産生告警；這些執行個體的上遊應用子產品受到影響也開始告警。比如，應用子產品中的執行個體發出告警，上遊應用子產品也産生告警。當應用子產品中包含的執行個體比較多時，産生數百條告警消息。再有甚者，網絡、機器、域名、應用子產品、業務等同時産生多層次、多方面異常告警，産生數萬條告警消息。
與此同時，在異常發生時傳統告警體系通過郵件、短信、電話等方式向相關人員進行告警，但大量告警消息并不能幫助他們迅速尋找根因和制訂止損方案，反而會淹沒真正有效的資訊。與此同時，問題處理往往需要協同不同團隊并及時同步進展，單點發送不利于問題描述與處理跟進。大量重複描述情況與跨團隊的責任人溝通，大大拖長了 MTTR。
很多中小型網際網路公司都有相對完整的監控與告警系統，告警品質和應急效率相較于大型及超大型企業會高很多。這是由于監控系統都在一個運維團隊開發與維護，業務結構、産品能力及使用方式相對簡單且統一，監控系統的主要使用人為産品運維工程師，配置的監控及告警品質較高。但随着企業規模的不斷增長，中小型企業也将與大型企業面臨着相同問題：
- 監控系統越來越多，各監控系統的操作方式、産品能力無法拉通對齊；
- 大多數監控系統對于技術團隊，功能設計體驗差且學習成本高。技術團隊不知道該配置哪些監控以及告警規則，導緻未做到風險點 100% 覆寫，或者導緻了大量無效告警；
- 不同監控系統對應責任人越來越多，當組織架構發生變化時，各監控系統訂閱關系無法及時更新。
最後的狀況就變成了報警量越來越大，無效報警越來越多，技術團隊放棄監控告警，然後開始惡性循環。具體歸因以上現象，我們發現問題主要集中在以下幾點：
「标準化告警處理流體系」的缺失
告警源資料缺乏統一标準以及統一次元的标簽
企業内各個域的運維系統獨立建設，沒有統一标準且大部分告警資料隻包含标題、等級和基礎内容。運維人員耗費大量時間逐條閱讀告警、分析告警來源和最終原因。而這一過程中，又十分依賴 SRE 的過往經驗。深究其背後原因，主要是由于來自各個域的告警資料，告警政策配置邏輯不一緻，沒有标簽或者标簽定義不統一，SRE 需要在繁雜的告警中識别有效資訊，分析告警之間的關聯性，找到根源。傳統的IT運維系統為了标準化和豐富告警資訊，會從企業層面定義統一的告警資料标準，每個域的告警系統需要按此接入。強制标準化的方法在實踐中一定會遇到如下問題：1）不同運維域改造成本大，項目推動困難；2）資料擴充性差，一個資料标準改動牽動所有運維域。
缺乏全局視角的告警資料處理和富化
IT 系統運維将來自不同域的告警內建統一處理，初衷是掌握更多資訊，進而進行更準确的判斷。但如果隻是被動接受并分派告警，告警運維系統作為運維資訊中樞的價值并未展現，效率與體驗也沒有改善。對此，運維人員可以主動對這些告警内容進行一次“消化”、“吸收”和“豐富”，将充滿噪音的資訊變得清晰規整。那麼，告警運維體系就需要可以對告警進行分解、提取和内容增強的工具。
組織協同處理告警難以落地
如何通過組織協同靈活處理告警？
在一個組織中，各個服務的穩定性往往落實在一個或多個組織的日常工作中。告警處理需要在團隊内、團隊之間進行協同。當告警觸發時根據目前排班計劃對主值班人員進行通知，一段時間未處理則通知備值班人員， 主備值班都未及時處理的情況下更新到管理者。當值班人員發現告警需要上下遊其他團隊處理時，或需要提高優先級處理時，需要能夠修改告警等級，能夠把告警快速轉派給其他人員，并且被轉派的人員能夠獲得該告警處理權限。
如何避免組織隔離的複雜性靈活處理告警？
正常場景下，技術團隊不希望看到其他團隊的告警的同時，也不希望該團隊的告警被其他團隊看到（涉及故障等敏感資訊）。但當告警需要跨團隊協同處理時，又需要能夠快速将這個告警轉派給其他人員且同時對其授權。怎麼在雲上完成這些靈活多變的權限管理需求？目前雲上傳統的授權方法是為每個成員在雲上建立對應的子賬号，對其進行授權。這種方式明顯不适合告警處理，線上業務已經受損了難道還要找管理者授權才能處理告警嗎？面對上述問題，不同規模的企業給出了不同的解決方案：
規模較小企業：把組織内的人配置為雲平台上的告警聯系人，告警觸發後，根據内容通知其中部分人。
優點：當團隊規模較小時，通過簡單配置即可完成告警的分發處理。缺點：需要不斷同步組織架構和告警聯系人的關系，比如新人員入職，老員工離職時需要及時同步。
規模較大企業：把告警通過統一webhook 投遞到内部告警平台中進行二次分發處理。
優點：自建系統可以和企業内部組織架構和權限系統打通，對于滿足組織隔離的複雜性和告警分發的靈活性。缺點：自建告警平台，投入大，成本高。
針對上述兩大問題，我們需要更加完整的思路去解決上述問題，經過大量實踐，我們提供以下思路供大家參考：
「标準化告警事件處理流」
結合上述運維案例的痛點以及告警标準化面臨的困難，我們不再強制推動各運維域在內建前進行适配。開發運維人員使用運維中心提供的“标準化告警事件處理流”功能，憑借以下手段去編排和維護不同場景下的處理流，對不同來源的告警進行标準化和内容增強。
借助告警平台靈活的編排組合能力以及豐富的處理動作，去快速處理多樣化告警場景
從告警運維中心視角來看，不同來源或者場景的告警資料處理流程各不相同。通過所提供的資料處理、資料識别和邏輯控制等豐富的處理流動作，面對标準化或者場景化訴求，SRE 用條件過濾出目前關注的告警，選擇動作編排處理流。經過測試啟用後，告警資料會按照預期的标準存入告警系統進行分派通知；SRE 的告警運維經驗，可以沉澱下來供後續自動化處理。
内容 CMDB 富化，打破資訊孤島
企業IT運維過程中，打破不同來源告警的“資訊孤島”是一件重要且富有挑戰的任務，而企業的 CMDB 資料正是最好的原料。通過維護靜态和 API 接口的方式內建 CMDB 資料，告警事件處理流可以通過 CMDB 對資訊進行富化，使得來自不同域的告警産生次元上的關聯。這樣在告警處理過程中，IT 資源之間的告警可以建立聯系，便于快速分析定位根因。
通過 AI 内容識别，快速了解告警分布
借助于 AI 内容識别能力，對告警内容進行分析歸類。運維人員可以從全局統計中了解系統告警分布，具體開發運維人員能夠一目了然識别出具體告警的對象類型和錯誤分類，縮短了從現象到根因之間到路徑。并且在事後複盤過程中，智能歸類資訊可以作為 IT 系統優化和改進行動的決策參考資料。
「面向告警的組織協同」
在标準化之外，我們可以看到對于告警處理，組織協同需要足夠非常靈活。不能再以“組織”為中心來處理告警，應以“告警”為中心建構組織。當告警發生時需要協調所需的上下遊處理人來建構一個處理告警的臨時組織，在臨時組織中的成員具備告警處理權限，當告警解決後可以快速解散臨時組織，避免被告警頻繁打擾和非必要故障資訊傳播。
聯系人自助注冊到告警系統
對于靈活化的運維團隊而言，應避免手動維護需要處理告警的組織成員在告警系統中的聯系方式。手動維護聯系人的方式不适合于頻繁變動的組織。優秀的告警系統應該由每個組織成員完成自己的聯系方式維護和通知設定，這樣既避免頻繁的組織架構變動對管理者更新聯系人資訊的及時性要求，也能滿足不同人對于通知方式選擇的不同偏好。
複用已有賬号體系，避免在工作中使用多個賬号系統
通常的企業都會使用一個例如釘釘、飛書或者企業微信的辦公類協同IM工具。應當避免在告警處理平台中使用獨立的賬号體系。如果一個企業平時使用釘釘等軟體進行辦公，然後告警系統有支援通過釘釘來處理告警，那麼這個告警系統就很容易能夠加入到企業的生産工具鍊中。反之，如果企業平時都是使用釘釘，但是告警系統需要使用單獨的賬号來登入，不僅需要維護兩套賬号，還容易造成溝通不暢，資訊處理不及時等問題。
靈活的權限配置設定方式
告警權限配置設定方式應是以最快速解決這個告警為目的的，當一個告警産生後值班人員如果不能自己解決，應該第一時間協調所需團隊與資源來解決該告警。同時當告警處理完成後又能夠将臨時協調的成員權限進行回收，確定業務安全，避免資訊洩露。結合工作中常用的告警協調方式，拉群溝通無疑是最符合告警處理的一種方式。當告警發生時值班人員臨時拉人進群檢視并處理告警。此時群就成為了天然的授權載體，進群獲得告警檢視處理權限，退群後不再被告警打擾。
豐富的可擴充能力
團隊協同過程中可能存在諸多協同工具同時運用，比如告警處理過程中，對于重要告警處理需要進行複盤，複盤後可能會指定一些工作内容來從根本上解決告警。這個過程中可能涉及到其他工具的運用，比如協作文檔類工具，項目管理類工具。告警系統需要能夠更友善的對接這些系統，更加全面融入到企業辦公工具鍊條中。
結合上述思路，阿裡雲将之進行産品化，并與 ARMS 監控深度內建，為客戶提供更為完善的告警與監控體系。
ARMS 告警運維中心核心優勢
對接 10+ 的監控資料源
ARMS 本身已經提供應用監控、使用者體驗監控、Prometheus 等資料源，同時對雲上常用的日志服務、雲監控等一系列資料源無縫對接對接，使用者一鍵即可完成大部分報警的接入。
強大的報警關聯能力
基于 ARMS APM 能力，對常見告警問題進行快速關聯，并自動輸出響應的故障分析報告。
基于釘釘建設的 ChatOps 能力
不需要導入組織結構，無需雲賬号。在釘釘群即可完成告警事件的分派，認領等操作，大幅度提升運維效率。
基礎與阿裡故障管理經驗，對告警資料提供深入分析，持續提高告警可用性。
核心場景
核心場景一：多監控系統內建
ARMS已內建雲上大部分監控系統，開箱即用。同時支援使用者自定義資料源。
核心場景二：告警壓縮
ARMS 根據常見告警現象自帶 20+ 規則，幫組使用者快速壓縮告警事件，同時支援客戶自定義事件壓縮。
核心場景三：多種通知管道配置
支援在釘釘群中處理和配置設定告警。
核心場景四：告警資料分析大盤
核心場景五：開箱即用的智能降噪能力
自動識别低資訊熵的告警。
前往釘釘搜尋群号（32246773）或掃碼加入社群，及時了解「ARMS 告警運維中心」最新産品動态~
想要體驗更好的告警中心快來使用 ARMS 應用實時監控服務吧！
産品新使用者免費使用 15 天，首購更有 5 折優惠！
點選閱讀全文，即可體驗！