超實用案例：美團終端主動監控平臺的建設

摘要

本次演講主要分享美團的終端主動監控平臺建設過程，分別介紹了目前的被動監控的侷限性，以及主動監控的實現難點。

很多公司都會有監控系統，包括前端的效能監控，業務資料監控，後端API服務質量監控等，從運維層面來看這些都非常重要。

一般來說監控在服務端應用的會比較多一些，那麼為什麼我們終端也要做主動監控呢？在討論這個問題之前，我們先來看下上圖展示的兩個場景。一個在退票環節中遇到白屏，另一個是應用loading時間過長。

對於前端來說出現白屏的原因有多種，有可能是Webview初始化的時候出現問題。目前在使用了React 、Vue等框架之後，頁面已經成為了一個大的模組，其他模組都是由這個入口進入，已經沒有了靜態的內容，因此無從判斷具體問題的出處。這種情況其實在測試階段很難被發現，因為它並不是普遍現象。

最後我們對這兩種情況經過排查發現，白屏問題是由運營商劫持造成的。第二種問題是由於在美團應用中使用者選擇的城市和定位城市不一致，導致資料介面返回資料出現問題。

目前業界的監控系統基本上分為3類。一類是業務監控，這應該是每個公司都必備的，比如訂單和GMV的監控。第二類是客服，是否存在客服主要由公司的性質決定。第三類是使用者反饋，最直接的方式就是App Store的使用者評價。以上這三類監控方式其實都是被動式的。

被動監控主要面臨的問題有三個。一是滯後，只有在問題發生且已經造成損失之後才能去著手解決。二是發現難，因為在上線之前已經通過測試解決了普遍性的問題，等到上線之後所出現的問題其實都不具備普遍性。三是復現難，綜合考量使用者基數、裝置、網路環境等各方面的情況就會發現問題的出現有著很多可能，即使使用者給予了反饋也很難再現問題發生時的環境。

既然被動監控存在各種問題，那麼就要開始做主動監控，其目的是為了先於使用者之前發現問題。初期我們的目標是能夠監控白屏、運營商劫持、客戶端介面錯誤等問題。

主動監控的實現需要達到幾個目標。第一個是覆蓋儘可能多的樣本率。第二個是要有時效性，雖然從被動監控的業務資料波動中也能發現問題，但是不同情況下靈敏度會出現差異。第三個是覆蓋，這裡主要指的是覆蓋業務的整個流程，以及各種平臺。最後是自動化，儘可能的減少人工干預的時間。

接下來我們來看下這四個目標所涉及的具體問題。首先是樣本率，主要涵蓋臺、裝置、網路和操作方式四個方面，就以平臺來說移動端的優先順序要高於PC端，另外網路環境不能僅限於WiFi下。其次是時效性，一方面要保證實時性，另一邊要配備相應的報警系統，最後還是要有人值班。到了自動化階段，穩定性是優先要求，其次要有日誌儲存的功能，因為有些問題並不能輕易的復現，另外還要選擇合適的測試框架。最後是覆蓋，我們希望覆蓋的範圍足夠的廣，包括搜尋、支付、退票、驗證碼等。

可以發現這裡面所涉及的問題還是比較多的，也存在不少難點，所以我們一期做的還是比較簡單。首先是樣本率方面，雖然我們的安卓使用者較多，但同時碎片化也非常嚴重，因此初期只選擇了PC和iOS這兩個平臺。裝置上則使用ipad和MacBook Pro跑自動化流程。自動化方面，iOS上採用的是Appium加WDA的方案，PC端採用的是Google的Headless Chrome（puppeteer）。

我們先看下PC的初期方案。這裡首先會有一些業務的case，用來保證整個流程的順利執行，有點類似於自動化的case。圖中左半部分執行在node上，通過Headless Chrome來承載抓包、打碼、diff這幾個功能。

抓包的主要作用是抓取每個請求的包，然後轉化成HLR的包，最後儲存起來方便後續分析問題。

打碼針對的是內部驗證碼，主要是為了滿足自動化的需求。

Diff是為了應付運營商的劫持，我們首先會跑一遍整個業務的流程，然後抓取到所有的js和css，最後將它們與git倉庫中最新的業務程式碼做diff。如果發現有程式碼被篡改就實時發出警報。這套系統之上還有一個訊息系統，用來通知每個負責的人，以及負責收集訊息，它還會連線到報警系統，由報警系統通過簡訊或郵件的方式向內部報警。這裡還需要有日誌系統，一方面記錄業務流程的進展，另一方面記錄每一步請求所抓的包。

最後是值班系統，我們這邊是每週固定一個人值守，值班系統每天會按級別分揀出報警。

我們將一期的方案整個跑下來之後，發現只能算是勉強可用，還是存在各種問題。首先樣本還是太少了，畢竟只有ipad和MacBook Pro，發現問題的機率太小。其次是流程經常中斷，比如支付環節中輸入驗證碼就無法做到自動化。第三在ipad上執行的時候app會有crash，這自然就會中斷流程。第四是case變動頻繁，一旦業務功能發生改變case就要隨之改變。第五是上線的js會壓縮混淆，這樣diff的時候每次都會不一樣，並沒有什麼意義。最後是存在大量報警，其中有效的並不多，需要依靠人工篩選。

為了解決面臨的樣例過少的問題，我們接入了內部的美團點評雲測。它是一個自動化測試系統，包含一個Jenkins和多個server，有著各種測試裝置以及一個儲存系統，可以自動或人工的提交自動化測試任務。

上圖是二期接入美團點評雲測後iOS的解決方案。首先Jenkins會自動的跑任務，之後還是一堆的測試case，再通過Applum加WDS實現流程自動化，測試裝置iPad使用Usb hub連線起來。其他的訊息系統、報警系統和值班系統還是沒有變化，不過這裡多出來了proxy和server。Proxy是為了app中的抓包，抓取的是與服務端的一些請求，包括js、css以及圖片。

對於支付的自動化問題，其實只要開通支付寶白名單就可以免驗證碼，Js的diff改為基於AST之後也能夠正確的驗證。

我們針對Case變動頻繁的解決方案可能會比較激進。就是iOS、Android、H5只做展現，單獨有一層完全使用js寫的業務邏輯，這同時也解決了客戶端的動態化問題。但該方案也存在缺陷，即Android的webview只支援ES5。

大量報警的問題主要是通過人工標記配合決策樹來解決。先通過人工審查標記報警，然後由決策樹對它們進行分類，標記有效報警和無效報警，在積累到一定量之後決策樹就會將某一類的錯誤全部歸類為無效。

經過兩期的實踐，iOS和PC上已經可以自動化，流程覆蓋率達到了95%，報警的時效性基本上在5分鐘以內，上線一個月後發現了4次問題，其中一次較為嚴重。最終我們的可監控範圍包括白屏、頁面效能、資源載入、業務介面、js報錯。

雖然已經做了兩期主動測試，但還是有一些遺留問題。一是對比海量的使用者之後樣本率還是不足。二是地域問題，PC上還可以通過代理模擬地域，但是iOS上暫時不好解決。三是業務的強耦合，針對每個業務都要再去做一套主動測試。

未來我們還準備接入android平臺，解決地域問題，以及其他業務的自動接入。

整個過程總結起來主要有兩點。一是主動與被動相結合，其實大業務量的情況下其實被動監控會更靈敏，所以要發揮他們各自的優勢。二是與自動化測試相結合。

這張圖是我們總結的選型方案，分為普遍性問題和業務量大兩個方向。普遍性問題可以直接通過自動化和人工測試解決。業務量大且又是普遍性問題的情況下被動測試會更靈敏。