面對疾風吧,如何搭建高協同的精準告警體系?

語言: CN / TW / HK

作者|九辯

世上沒有一個系統是百分之百盡善盡美的。如果想要保證可用性,那麼技術團隊就得對服務的各種狀態瞭如指掌,能在第一時間發現問題且快速定位問題原因。但要想做到以上這兩點,只能依賴完善的監控&告警體系去監控服務執行狀態,但技術團隊又不可能時時刻刻都盯著看板並關注到所有方面。因此,告警成為團隊監控服務質量與可用性的最主要手段。

但在實踐過程中,技術團隊所獲取的告警往往不是太少了,而是太多。我們看看某跨境電商系統 SRE 每天的工作日常,或許每個工程師對此都不陌生:

  1. 開啟通訊工具 IM,運維群的告警訊息提示 99+,甚至 999+;
  2. 點開群檢視訊息,滿屏告警標題、等級和分派人,但資訊過多無法快速篩選和確定高優先順序告警;
  3. 挨個開啟資訊,檢視告警內容並評估實際優先順序,這其中包括但不限於服務超時、網路重傳、資料庫響應慢;
  4. 發現等級為“P1”的告警,檢查內容來自交易系統服務超時,告警分派人是交易系統開發同學,開發同學檢查發現交易系統當前沒有異常,認為是資料庫問題,返回群依次點選檢查;
  5. 到了公司開啟告警中心繫統,按告警等級高低排序再點開列表條目,分別與業務開發、網路裝置維護和資料庫 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已整合雲上大部分監控系統,開箱即用。同時支援使用者自定義資料來源。

圖片 1.png

核心場景二:告警壓縮

ARMS 根據常見告警現象自帶 20+ 規則,幫組使用者快速壓縮告警事件,同時支援客戶自定義事件壓縮。

圖片 2.png 圖片 3.png

核心場景三:多種通知渠道配置

支援在釘釘群中處理和分配告警。

圖片 4.png 圖片 5.png

核心場景四:告警資料分析大盤

圖片 6.png

核心場景五:開箱即用的智慧降噪能力

自動識別低資訊熵的告警。

圖片 7.png

前往釘釘搜尋群號(32246773)或掃碼加入社群,及時瞭解「ARMS 告警運維中心」最新產品動態~

二維碼.png

想要體驗更好的告警中心 快來使用 ARMS 應用實時監控服務吧! 點選下方連結,即可體驗! https://www.aliyun.com/product/arms?spm=5176.19720258.J_8058803260.179.c9a82c4aAnljzB