一、傳統告警渠道的困局

1.傳統告警——事前

1）業務痛點

溝通群里有各種各樣的告警，如基礎設施的告警、業務接口的告警、中間件的告警，客情輿情的用戶反饋。這些信息通過不同的形式方式以及依賴每個告警工具的建設，推送在群中，導致整個群信息雜亂，處理告警無從下手。

日常告警：海量的數據內容復雜瑣碎，包括業務和中間件的數據。由于效率不足，很多時候大家會直接靜默，錯過一些重要告警，最終導致問題沒有被及時跟進，變成故障，甚至社會輿情。

網絡輿情：不只是個人告警，網絡輿情的數量也很龐大。在微博、知乎等一系列的公開場合每天都有大量網絡輿情。這些客體的數據分布在每個平臺的社交網絡上，網絡感知更快，但難以迅速觸達研發和產品側，錯過最快的抑制時間。

業務客訴：即基于內部的業務客訴。客戶通常通過熱線、在線提工單的方式反饋問題，在線小二、客服將客戶信息轉發到相關群，通知大家處理。但實際上用戶難以真正闡述問題，如果不做相關定性定量，可能在問題反饋初期無法定位問題根因，導致大面積的業務客訴，然后轉化為重大輿情事件。

2）問題所導致的痛點

• 由于告警過多，過于復雜，導致告警疲勞；
• 孤軍奮戰：在傳統告警中，每個人都相當于孤軍奮戰，因為網絡只是輿情的輸入端，而非告警。客訴在群中流轉，日常告警則不斷推送各種各樣的渠道告警，但我們最終只是收到告警，不清楚這條告警通知了誰，有無得到處理，一切都是未知數；
• 存在信息偏差：由于組織架構調整，相關研發和運維人員的信息維護未必非常準確。收到告警的人可能無需收到類似告警，而本應收到告警的新成員，卻未能收到；
• 數據離散：用戶不清楚接收的告警數量，也無法分辨有效告警和無效告警，更無法判斷告警的重要性，導致整個數據無法度量，各個視角（研發、測試、運維、老板）都無法感知自身業務的穩定和應急協同的成效。

3）痛點引發的新問題

• 溝通復雜：如果成員們認為收到的告警表明情況嚴重，則會在群里說一聲，但是群消息非常多，因此在收到重要告警時大家可能察覺不到。
• 問題升級：溝通復雜可能導致告警疲勞，造成問題升級。若小問題得不到及時解決，積累后越來越嚴重，就會導致故障發生。
• 無法度量：由于渠道、產品不統一，無法跟進度量應急時效、有效及后續情況，所以無法評估并提升業務穩定性。 

研發、老板、SRE三大角色需要處理這些風險，各自的困難如下圖：

2.傳統告警——事中

對于傳統預警告警的處理，本質上是處理并解答四個問題：有哪些人？采取什么機制？有哪些信息？用了哪些平臺工具？然而在實踐過程中，可能會遇到各種各樣的挑戰。

• 缺乏標準SOP，研發處理過于依賴個人能力

缺乏標準的SOP應急流程，導致SRE、研發、老板三個角色在問題發生出現時，對預警、故障的處理完全依賴個人的經驗能力。對于一個具有豐富工作經驗的同學來說，不會在處理故障時遇到很大障礙。但對于一些工作時間不長、沒有遇到過線上問題的同學來說，處理故障完全依賴個人理解和能力，這可能導致一些“非標”的動作，或遺漏重要的應急步驟。最終，輕則影響恢復市場，重則擴大故障影響面。

• 實時進展無同步，信息不對稱可能放大故障影響面

在整個操作過程中，由于事態比較緊急，可能會存在操作過程不規范或信息未能及時同步的情況，使得大家雙向操作。其本質問題是實時進展無法同步、信息不對稱，最終放大故障的影響面。

• 人員職責不清晰

一個標準預警的發生，SRE團隊、中間件團隊、業務團隊和基礎設施團隊都可能參與其中，傳統告警無法協同不同角色在各自領域內解決問題。

• 多團隊跨團隊合作，缺乏協同能力
• 標準恢復操作涉及拉群、定位、觀測、執行運維操作的平臺眾多，來回橫跳影響應急效率。

處理方案：

• 觀測定位：在實戰過程中，一個事件告警產生后，首先不斷地跳轉大量平臺，進行觀測和定位；
• 預案快恢：類似重啟、線上應用配置修改、數據庫執行DDL、等常規手段，涉及平臺極多。平臺執行時難以及時通知整個內部團隊，例如有人進行業務降級時，其他人可能并不知道；
• 應急協同：一旦出現嚴重的問題，大家會拉群溝通，如果跨團隊，或者涉及多人的跨云協作則可能雙方人員都會拉群。但實際工作中已有SRE群、研發群和處理臨時問題的各種群，群的數量劇增，信息同步效率卻不高。以上情況直接導致整個告警處理過程中出現一個極大的業務痛點——即大家無法做到信息對齊，問題會在處理過程中進一步被放大。

3.傳統告警——事后

傳統告警基本沒有事后處理，缺乏對有效占比、原因分類、響應時長、完結時長等一系列標準操作的信息數據度量。數據度量的缺失就意味著難以進行對應數據治理，導致問題處理后，缺乏數據沉淀，也難以避免類似問題再發生。此外，如何判斷告警的有效性，如何治理等問題都缺乏對應抓手和處理依據，這是傳統告警存在的困局。

二、風險預警——閉環風險的全生命周期 

基于上文的困局，我們提出了“風險”的概念。什么是風險？它與故障有什么區別？以下將詳細介紹。

整個風險的生命周期基本實現了全閉環，先風險發現，然后跟蹤和定位風險，最后風險打標。

• 風險發現

風險挖掘需要定義風險。風險覆蓋人工、客情、輿情、工單系統等方面，也可定義為通過業務監控、中間件監控或基礎設施監控發現的風險。風險不等同于故障，故障嚴重影響業務的可用性，而風險意味著可能對業務產生小部分影響，但還未擴大至較高等級的影響，無需通過標準的故障流程來處理。我們通過告警系統或人工上報打通流程，發現對應風險。

• 風險跟蹤

定義和發現風險后，就需要跟蹤和相應風險。基于風險響應，我們制定了一套標準的SOP流程。

• 風險定位

這個風險如何產生？根因是什么？這些都是大家需要關注的重點。

根因定位一旦完成，就需要采取快速恢復的手段。抖動則無需處理，但它可能是一個action，需要后續優化代碼，執行預案，或執行一定的運維操作，比如重啟等行為。快恢操作后，若能確定業務完成了閉環的風險處理，就意味著風險完結。如果風險還未完結，基本上可以確定已升級為故障。

• 風險打標

風險處理完畢后，最后進行風險打標。有了打標才能更好地實現閉環，回溯到第一步的風險挖掘。

基于風險的定義，我們提出了一個“風險場景”的新概念，它是風險預警環節的核心因素。

1.風險告警——事前

針對上圖右方的三種異常，不同人員的關注視角不同，研發和SRE一般關注中間件異常和基礎設施異常，因為它有可能影響業務，也有可能不影響業務。如果不進行妥善處理，后期有可能導致業務異常。至于業務異常，所映射的是穩定性可能出現問題，業務也可能受損。因此不僅研發和SRE需要關注業務異常，老板和穩定性負責人也需要關注。

風險場景的實體關聯了三個要素，分別是規則表達式、監控指標和告警、預案和快恢。

• 規則表達式：作用是向穩定性負責人和老板提出異常定義，類似于物理公式，在計算某個值的時候會先給出一個公式。對于穩定性負責人和老板來說，他們并不關心公式的值，但這個公式能明確表達當成功率低于某個值的時候，就可以進行風險認定。
• 監控指標和告警：基于規則表達式，研發需要補全相關信息。因為規則表達式本身只是一個定義和公式，在具體計算時需要關聯對應的指標。監控指標告警與三個概念相關聯，一是指標，二是告警，三是監控實體。這個實體涉及變更和定位，能夠表達規則表達式當中的異常關聯在哪個實體上，也可以確定哪個監控實體或哪個應用實體發生了異常。基于風險場景，規則表達式能表達異常的定義，監控指標告警則關聯表達式，實現基礎的計算能力。
• 預案和快恢：通過人工預案的快恢綁定，也可以通過自動化預案綁定。當它觸發某個場景時，通過整個信息流轉，集成到整個快恢平臺的能力內，置于風險場景上，就能解決事前的配置化工作，類似于獲得一本操作手冊，避免運行時標準化層面的不一致。

綜上所述，我們提出了一個對應的配置頁面，除了場景外，還會引入值班組和預警節點。預警節點即CMDB，用于定義整個業務、部門或應用預警的節點。

• 場景和值班組的關系：值班組包括對應的管理者，處理對應問題的企業微信協同群及對應的升級側。響應機制是5分鐘未接手就升級至負責人，10分鐘未接手則升級至leader。一個風險的預警節點可關聯多個值班組和多個場景。
• 值班組的職能：處理預警節點所對應的場景信息，比如一個大團隊設置了3個值班組，則每個值班組需要處理其中的4個異常場景。通過這些關聯的指標配置，可清晰定義這個節點下需要負責的具體值班組和具體的異常場景，關注點有可能重疊，比如老板的視角會關注所有的場景異常。

通過場景的定義、值班組和預警節點的概念，我們整合出了風險預警的三個核心概念，即哪些值班組在哪個預警節點要處理哪些場景的異常。有了該定義，在事前就能較好梳理風險點的具體位置以及人員職責，避免上文所述的告警混亂和渠道不一致問題。

2.風險告警——事中

• 報警推送

場景觸發異常時，第一個消息就是報警推送。收到告警后，我們會在群里推送一套標準化流程的卡片，標準化的格式是標題內容、告警時間渠道以及最近變更成員，然后進行一定的標準行為操作，比如遇到風險需要接手并響應，加入一個應急的協同群。通過對接不同的監控系統，我們可以清晰定義監控和告警的實體以及用戶關心的內容。針對來自MySQL、SLO、Alarm、公司內部前端的告警和普通的告警，會適配不同的模板，由渠道統一推送。

主要貢獻：統一流程、整合能力、提供協同、適配渠道、精準觸達、

• 行為同步

由于我們已經明確“標準SOP體系下的風險處理”定義，所以告警出現后，自然有人接手。之后再進行轉交，并在排查過程中機型信息的錄入與同步，也可以告知他人自己遇到的問題，這些信息都會在群中同步，如此便實現了事件的閉環。我們還提供了催辦升級能力，同步廣播進展，進行統一的度量。若整個群做到了以上幾點，那么在老板視角就可以及時獲知問題，是否有人處理和響應等。研發也能互相協同，因為一個平臺由多個研發負責，在這個平臺中我們可以了解問題的跟進詳情，問題根因來自誰等，可便于在群中做進一步的溝通。

主要貢獻：閉環事件、催辦升級、廣播進展、統一度量、信息透明

• 預警詳情

除了簡短的卡片信息外，還會提供一些對應的技術指標，比如針對SLO的告警，我們提供了一個相關接口錯誤碼的指標時序圖，以方便研發在預警詳情中通過一個頁面查看過往大量平臺的信息。表面上是平臺整合，但實際上是通過標準的SOP流程明確定義需要關注的平臺，并且借助算法和工程能力查出具體的指標錯誤，同時提供一定的根因分析和預案快恢能力。根因分析和預案快恢的完整行動路線都會通過信息同步的方式在群中進行協同處理，以避免由于信息不一致而導致操作失誤。

• 預警列表

方便用戶在群中快速得知哪些預警仍未完結，通過一個較為標準的處理流程，就能妥當地處理風險。即使一個研發缺乏一定的風險處理能力，但借助這套產品也能極快地處理風險，降低整個業務的風險。

對于整個風險預警產品，我們不僅做了標準的SOP流程，還從變更層面挖掘了信息的拓撲能力。

• 快恢覆蓋

快恢即在整個恢復過程中所執行的手段，回滾最為常見，因為超過73%的故障和風險基本上都由變更引起。此外還有中間件和基礎設施的運維操作，以及標準化預案平臺的接入。

通過這些覆蓋，我們在整個事中可以做到賦予研發更多處理問題的手段和能力，借助變更覆蓋和監控覆蓋，結合拓撲覆蓋，我們就能嘗試幫助用戶定位風險的誘因。

圖右側展示了風險預警的定位能力以及對應的覆蓋能力。通過定位，能將內容快速推送到群中；通過接口的監控，告知指標在同環比增加的比率，最后幫助用戶發現問題。

如果上下游出現異常，拓撲覆蓋也能定位。若你的應用發現異常，我們會幫你檢測有無做過對應的變更，若無變更，則通過拓撲信息偵測周圍鏈路上發生的變更，給出一定的推薦，幫助用戶找到對應的人員，從而快速解決問題。

而在快恢層面，我們也會同步所有信息，在整個群中做協同，以避免研發在重復操作或者信息不同步不對稱的情況下，導致故障或風險的二次發生。

3.風險告警——事后

有了恰當的配置和事中的處理，通過相對簡單的方式便能度量事后的數據。

接手時長、接手率、完結時長以及完結率是四個非常核心的技術指標，透過這些指標即能感知每個部門的情況。我們會根據這些情況去溝通，加深對產品的了解，思考產品能夠持續優化的各個方向和層面。

事前涉及基礎設施的風險覆蓋、中間件的風險覆蓋、應用的風險覆蓋以及SLO的風險覆蓋，事中的核心度量就是接手率、完結率和轉故障數。事后則會度量有效率和場景治理。

場景治理包括兩方面，一是正召回，二是負向召回。正召回即召回誤告的告警，負向召回即需要填充未被發覺的告警。事后的度量完成后，整個風險就能產生一個新的閉環，從而解決風險的遺漏風險、告警的失效，以及人員的治理問題，最終就能解決整個風險。

三、風險預警的產品架構&技術架構

1.風險預警總體架構

2.風險預警技術架構

最底層是人員組織的管理，用于表明公司的人員信息；CMDB即預警節點的節點能力，也會搭建基礎服務，以便為上層服務提供權限。場景管理再往上，則會通過一些微服務（如核心的場景管理）實現整個場景的數據配置化能力。

• 監控管理：提供一個標準的監控模型，把不同的監控系統接入到整個平臺中；
• 值班管理：Oncall值班組的能力；
• 變更管理：不但承載封網管控能力，還負責變更信息的錄入。在最底層的業務設計基礎上，分為四部分，分別是配置管理、處理風險、定位恢復和數據度量；
• 配置管理：管理場景、CMDB、人員組織和值班表的相關關系，提供風險挖掘和故障防控的能力；
• 處理風險：除消息推送、應急協同和催辦升級外，也能聚焦于快恢能力。我們的產品主要是解耦式的設計，可以支持外部系統做對應的推送。以MySQL為例，這種場景下如果要做定位，有了解耦式的設計，就能通過DBA自行診斷整合到我們風險預警的應急流程處理中去，更好地服務于研發和SRE，幫助他們解決這個問題。

通過整套技術架構以及領域劃分的設計，它的橫向拓展性相對會更好。針對后續的一些用戶訴求，不管是SRE老板、運維穩定性負責人還是一線研發，都會在這個產品中承擔不同的角色，并滿足不同的訴求。

Q&A

Q1: 影響范圍、上下文和診斷信息等告警信息是否都會給出？

A1：我們有一定的拓撲能力，會把每一個節點封裝成一個對應的實體，這個實體會關聯對應的中間件依賴以及上下游的依賴。當我們接入一個告警信息時，它的上下游信息會根據HTTP和RPC的標準指標將紅色的異常節點進行定義，在告警信息中給出對應的診斷。

由于它依賴指標的計算所以在技術上使用了異步模式，當它推送告警信息后，如果它在1~2分鐘內判斷出大概的影響范圍和上下文，就會補充診斷信息，將可能導致告警的原因告知用戶——自身應用導致還是上游檢測出的依賴方的調用出現了環比的突增？最終都會給出診斷。

Q2：如何確認預警告警本身的準確性和有效性？

A2：首先我們會通過風險的挖掘，告知用戶具體的風險。在出現風險告警時，研發確實會接收到大量的無效告警，但在我們的處理過程中，會有一個閉環，在風險度量時就能看出哪些是誤告率極高的告警，所以這時透過周報就能看到相關信息，從而篩選出準確有效的告警，并通過數據的閉環幫助用戶做對應的治理。

你也可以一鍵優化規則，或者通過屏蔽無效告警、比如代碼屏蔽errorCode的方式來確認，比如用戶未登錄而執行某些結果導致鑒權報錯，針對這種情況就可以用上述的方法。

因此，數據閉環的作用是驅使研發自閉環地判斷告警本身的準確性和有效性，并據此做對應的治理，這是整個風險預警的重要貢獻之一。

Q3：預警對故障的容忍度如何，怎樣設置閾值？

A3：首先，中間件異常和基礎設施異常也有可能不影響業務故障，比如四臺機器掛兩臺，如果流量不高，則業務上可能無感知，我們會把這方面劃分在預警的領域內。至于容忍度，則需要SRE制定一個標準的SLI，因為它可能通過pv/uv、或者一些資損得到一個對應的結果，因此若SLI認為某個指標的成功率低于90%則為故障，那么對預警而言，可能就會將值設置為95%或96%，具體基于研發對自己系統業務上的規則定義。

注意以下兩點：容忍度必須比故障更高一些，比如故障的指標是90%，你就可以設置95%時發出一條預警，思考低于95%時是否需要開始介入，以避免發生更進一步的故障；比如宿主機發生異常，或者整個中間的鏈路上分支環節上出現異常的時候，可能還未對故障的指標產生影響，通過預警就能迅速容忍故障的發生。這就是它能防控故障的原因，因為它做到了對場景業務更為精細化的管理。

Q4：發生雪崩效應大面積告警故障時，能否快速定位故障源，具體如何實現？

A4：無論從內部復盤還是整個行業的經驗上看，絕大部分的大面積故障都源于兩方面，一方面是變更，另一方面則是運維的操作，運維操作也可以定義為變更，一個是發代碼，一個是發配置。

基于這兩點，我們接入了變更的整個拓撲數據，還接入了CMDB。CMDB是配置時的拓撲信息，運行時則是通過分析 Discovery數據拓撲—一個鏈路的實時動態和調用關系，將它們結合分析，基本上就能基于告警的爆炸中心找到對應上下游的變更情況，以及對應的核心指標。以應用為例，我們定義了HTTP和RPC，就能快速定位可能存在的故障源，不過這只是一種可能。整個底層模型是一個拓撲的樹形結構，當它發現最頂層的異常時，通過分析依賴關系可以通過快速找到對應的故障點，因為我們認為往下都是果，最頂層才是因。

Q5：為什么要有風險的概念？用這套流程來做故障處理不是同樣可以嗎？

A5：風險和故障之間有比較明確的界定，不影響業務的異常（如中間件的異常）更需要研發關注。比如我有六個下游做同一件事情，每個下游是六分之一的分流，且有兩個下游異常，這時業務并不感知，但是它可以通過風險來處理，因為六個業務中有兩個供應商可能異常，這需要我們定義。

風險有可能影響業務，但不足以啟動整個故障的流程處理。所以我們提出風險自閉環能力，它并不是一個管控手段，而故障更多的是一種行政管控手段，可以將它理解為一個獎懲機制。你觸發了故障，就要按照標準的流程處理，必須第一時間解決問題，必須要復盤，最后計入穩定性分析，可能還會有各種各樣的掛鉤，但風險始終是自閉環。

故障確實有部分協同與風險一致，但在數據度量以及對應的手段上，故障本身不需要接入一些中間件、基礎設施或者指標自定義的告警，它接入更多的是強勢的業務管理，比如交易成功率低于多少，下單成功率或者彈幕的發送成功率低于多少等，這是與風險的最大區別。

Q6：事件變更如何要求所有業務的變更都去變更平臺錄入變更信息？若不錄入，他們就無法進行變更嗎？

A6：我們不會找所有的業務，而是對接整個公司，比如應用的發布平臺、編譯平臺以及配置的發布平臺，以及數據庫的DDL變更，把整個變更平臺的信息視作標準化的結構錄入。

Q7：故障的影響范圍如何快速評估？

A7：故障影響范圍的快速評估主要通過四種方式，第一是監控指標，整個業務會不斷地在應急協同群中反饋哪些業務受影響。第二種，比如我做了網絡變更，導致網絡異常，但我知道網絡有可能會影響哪些業務，所以故障的影響方本身也可以做到影響范圍的快速評估。第三即拓撲能力，它可以快速拉出整個鏈路的影響范圍。但在實戰過程中，如果遇到了大故障，我們的定位系統壓力極大，基本算不過來，這種情況就無需再定位，因為影響面太廣，大家基本已全部得知。第四種即客情，一旦出現大故障，在微博上必定會出現客情，產生一定的社會影響面，所以可以借助整個社會的反饋來做評估。

Q8：風險預警的定義門檻比故障更低，如何讓技術人員對風險預警足夠重視，又不至于被過多的預警轟炸到麻木？

A8：首先，我們產品的核心與故障有本質區別，故障更多的是一種管控手段，風險預警則是我們給研發提供自閉環風險的概念，也就是說，理論上研發對風險預警擁有接收自由，我們并沒有強制研發一定要接收風險預警。

針對整個風險預警的定義，它是一個產品，用于幫助技術人員或者研發等不同的角色提高風險對應的管理能力。故障相對而言強制性更強，對公司來說可以稱為一種政治手段。風險預警是一個產品化的能力，它幫助技術人員去做這個事情。技術人員可能是最底層的一線技術人員，也可能是技術人員的老板，希望通過風險預警提供一個抓手，提高整個團隊對風險的管控能力。他也有可能是穩定性負責人，希望更快獲知風險。

這個產品提供了一定的技術能力，并且將在后續的迭代中不斷豐富，比如更精準的定位能力、更精準的快恢、接入更多的快恢平臺，制定恢復預案等，將這些技術能力整合在一起，幫助技術人員更好地解決風險。借助該產品，他們可以迅速獲得業務結果，以最小的成本實現穩定性的建設。如果他們意識到以上的好處，他們也會認同并相信風險預警能解決對應的業務痛點。

至于如何避免被過多的預警轟炸到麻木，第一配置成本會調高；第二，我們會進行數據復盤，在整個大盤中告知哪些預警的規則可能存在問題。我們不會讓用戶簡單地打標告警有效或無效，會闡述清楚是抖動還是監控異常，或是規則不合理，還是偶發事件無需處理等等一系列原因，幫助研發通過整個大盤的數據得知自己上周的應急協同數據，即獲知每天處理的風險數量以及有效率，哪些風險需要重視等，通過一個閉環清除無效的告警，幫助研發挖掘更多可能需要覆蓋的風險點。綜上所述，當技術人員認為這個產品對他有幫助，他就會自發使用。

谷林濤

嗶哩嗶哩 

基礎架構部 資深開發工程師

B站事件運營中心研發負責人，負責建設Bilibili內部穩定性平臺產品，提升線上問題的應急協同效能。同時負責工單、封網管控、拓撲定位產品，總體保障業務系統的安全生產。