「黑匣子」工程 - 用戶端監控保障體系建設

做者：張鑫，資深工程師，點餐團隊成員。本文同步發佈於知乎專欄： 張鑫技術男。

業務背景

美團點評的業務發展歷程是一個不斷深刻挖掘行業價值的過程。

從用戶評價，到團購，到外賣，到預訂，再到點餐，越是後期的業務越須要向系統底層打通，對商家運營的介入程度愈來愈深。

對商家運營的介入程度加深以後的附帶效應是：

• 系統的不可替代性愈來愈強
  
• 系統的複雜程度愈來愈高
  
• 對系統穩定性的要求愈來愈高
  

這三個附帶效應，對咱們的服務能力提出了更高的要求。打個比方，若是說過去咱們爲用戶提供的是自行車，那麼如今咱們要爲用戶提供的是飛機。飛機的不可替代性、複雜程度、系統穩定性要求都遠高於自行車。

爲了保障系統穩定運行，主要從兩個方向入手：

• 技術架構上和開發流程管控方面下功夫，防患於未然，系統性地下降風險。
  
• 從故障響應方面下功夫，提升故障預警、分析、處理能力，作到快速響應快速解決。
  

所謂「黑匣子」工程，就是要建設一整套用戶端監控保障體系。這套體系能夠理解爲給系統中每一個商家或者用戶加裝一個記錄用戶行爲和用戶端內部狀態的黑匣子。當故障發生時，咱們要可以從黑匣子中獲得全面的用戶端數據，以數據分析的思路來解決難以復現的疑難問題。

咱們建設用戶端監控保障體系，就是要爲整個業務的故障響應能力賦能。

關於黑匣子

定義

「A flight recorder, commonly known as a black box, although it is now orange-coloured, is an electronic recording device placed in an aircraft for the purpose of facilitating the investigation of aviation accidents and incidents.」

一種比喻

航空界使用黑匣子來助力事故分析，互聯網領域同樣能夠借鑑其思路。

對於SAAS系統，整個系統能夠理解爲一個航空公司，用戶能夠理解爲乘客，用戶端能夠理解爲一架架在飛行的飛機。

對於系統後臺，咱們的監控數據一般是比較全面的。可是對於用戶端，監控數據則十分匱乏，不少狀況下，用戶端只有簡單的性能監控或者crash監控。

這就至關於一個航空公司只知道哪些飛機準點到達了，哪些飛機墜毀了，可是不知道飛機內部發生了什麼，也就是沒有黑匣子，這樣難以對故障進行分析處理。

SAAS系統的用戶端，也同樣須要全面的監控數據來助力故障響應。

與黑匣子的類比關係：

• The flight data recorder (FDR) - 記錄用戶端內部的關鍵數據
  
• The cockpit voice recorder (CVR) - 記錄用戶端與各個後端服務的通信
  

從過程復現到數據分析

在沒有用戶端「黑匣子」的系統中，咱們處理問題的思路就至關於與在空難現場收集線索，而後試圖根據碎片中的信息重現空難，在反覆重現的過程當中尋找問題的緣由。

有了黑匣子，咱們就能夠直接調取發生故障時用戶端的具體信息，從數據分析的角度查找緣由。

傳統思路：過程復現

傳統思路是將用戶與系統的交互視做一個過程，經過復現交互過程來定位並解決問題。

基本模式：

收集反饋 - 重複操做 - 復現問題 - 調試代碼 - 定位問題

傳統思路的缺陷：

• 用戶的反饋是片面的，系統內部的信息無從瞭解，難以真實還原交互過程

• 疑難問題每每是小几率發生的，難以復現，甚至不可能在開發者所在的環境下復現

新思路：數據分析

新思路是將全部用戶行爲和系統行爲視做數據集合，經過數據來記錄用戶在交互過程當中的真實狀態，經過數據分析的方法來定位並解決問題。

基本模式：

收集數據 - 調取數據 - 分析數據 - 定位問題

新思路的條件：

• 有完善的支撐系統來支持數據的收集和分析

• 改造代碼來實現信息的全量上報

• 開發者具有數據分析的能力

用戶端監控保障機制

用戶端監控保障機制的核心是數據。一方面在於對於用戶行爲和系統狀態的全量信息收集，另外一方面是利用數據分析的思路解決問題，加快問題反饋閉環。

監控數據收集

關鍵目標：「全流程，全服務，全信息」的監控覆蓋。

• 全流程 - 從頁面訪問，到行爲記錄，到接口請求與反饋的全流程都要在監控範圍內
  
• 全服務 - 後臺服務，平臺服務，第三方服務
  
• 全信息 - 要包括時間，地點，任務，網絡情況，設備等上下文信息
  

問題反饋閉環

關鍵目標：每條問題反饋都能找到對應的監控記錄。

問題反饋能夠是用戶主動反饋的，也能夠是運營或技術人員分析發現的，也能夠是系統的自動報警。

經過問題反饋，獲得上下文信息，根據上下文信息經過多維度查詢找到相關的監控記錄，分析監控記錄造成處理方案，處理方案通過積累沉澱再助力於問題反饋，造成整個閉環。

「3+3」監控覆蓋

3+3：

• 3個主要環節：資源到達，頁面渲染，用戶操做
  
• 3種主要服務：後臺服務，平臺服務，第三方服務
  

監控的兩種類型：

• 記錄型監控：記錄系統各個關鍵環節的工做日誌，用於正向確認系統狀態正常
  
• 捕捉型監控：記錄具體錯誤信息，用於負向確認系統狀態異常
  

捕捉型監控的缺陷在於咱們對錯誤的捕捉是有預設性的，而不少疑難問題並不能被咱們預設的條件捕捉到。

記錄型監控與捕捉型監控必須相互配合才能準肯定位問題，二者都很重要。

支撐系統建設

主要需求：

• 全量的數據收集
  
• 支持多維度的數據查詢
  
• 支持實時的數據分析
  
• 支持指標報警
  
• 使用簡單快速
  

目前已有支撐系統的主要問題在於尚未一個現有系統可以同時知足全部主要需求。並且多數監控系統都是針對於後臺的，專業的而用戶端監控系統還在建設中。

實踐中須要各個系統配合使用，或者基於已有系統作二次開發。

全面的用戶數據上報，勢必帶來數據體量方面的挑戰：

• 大量數據上報的帶寬壓力
  
• 大量數據的存儲壓力
  
• 大量數據的快速檢索與實時分析
  

監控數據分析

場景還原法是用數據還原系統在故障發生時的真實狀態。

從故障相關的監控記錄中，先向下查找交互過程當中的斷點，再從斷點出發，向上查找具體錯誤緣由。

管理保障

管理手段是輔助，目的是加快問題反饋閉環的運行速度。

運營人員根據故障FAQ來快速響應，並決定是否進入故障響應流程。確認須要研發人員介入以後，研發人員根據故障處理手冊中的指導來排查問題。

問題處理完成以後，寫成CaseReview，並沉澱成故障FAQ的一部分。

總結

隨着移動互聯網時代的結束，作線下服務的企業進入了深挖地底礦的新時代。隨着咱們的業務對商家運營的介入程度愈來愈深，對於穩定性的保障須要完成從自行車到飛機的轉變。

「黑匣子」工程是給用戶端系統裝上收集數據的黑匣子，而且以數據分析的思路來解決疑難問題，加快問題反饋閉環，爲整個業務的故障響應能力賦能。

文本給出了關於用戶端監控保障體系建設方面的總體思考，後續會找機會將一些細節的設計與你們分享。歡迎你們批評指正。

---

本文對你有幫助？歡迎掃碼加入前端學習小組微信羣：