隨着頁面展示形態的多樣化發展，用戶使用環境的日趨複雜，當代監控越來越無力。傳統監控可以做到在錯誤發生時上報錯誤堆棧信息，甚至更多地引導數據。但當前端出現偶發 Bug 時，最令開發人員困擾，因爲它們大大地增加了排查成本。
針對偶發 Bug 的問題，貝殼找房於 2019 年年初自研了操作回放系統——時光機，作爲燈塔前端監控的擴展系統，時光機通過對用戶操作路徑和動作的收集，關鍵數據的快照存儲，以及並行組裝等能力，提供了一套用戶回放操作技術方案，實現了 100% 用戶操作回放。InfoQ 近日採訪到貝殼找房基礎架構中心前端架構委員會專家陳辰，就目前企業前端監控現狀、攻克偶發 Bug 的技術難點，以及貝殼自研操作回放系統時光機的過程進行了詳細探討，以下爲採訪全文整理。
InfoQ：請介紹您在貝殼找房主要負責的工作。
陳辰：我在貝殼找房主要負責整個公司的架構團隊和前端橫向委員會的工作，對接新房、租賃、二手房、裝修、交易團隊等一線業務團隊的 FE。除去部分編碼工作，還負責技術梯隊的搭建、人才培養、公司架構或業務的技術選型、橫向通用能力的支持等等。
InfoQ：您在即將召開的 ArchSummit 全球架構師峯會（北京站）上分享《監控進階前端操作完美回放》這一演講主題的原因是什麼？
陳辰：在日常的業務開發中，各種監控層出不窮。監控本身可以通過類似報警、錯誤堆棧信息發現一些問題，但有些問題只能在特定操作流程下出現。而且在修復某些偶現問題時，我們可能不清楚這個問題是否真正修復，因爲問題的偶現性無論排查問題，還是驗證修復問題都是非常困難的。也就是說，在許多業務中出現的 Bug 無法得到解決的主要原因是無法復現。基於上述問題，貝殼在 2019 年初啓動了自建的回放系統——時光機，目前已在貝殼大面積應用，因此想就這一項目和大家做一次技術分享。
其實，時光機的出現是由一個很偶然的問題引出來的。產品經理之前總向我們反饋不清楚用戶是如何使用產品的，尤其是房屋交易、查看這種強流程交互類的產品。雖然通過產品數據、漏斗等方式可以觀察到用戶的趨勢，但還是很難分析用戶在操作系統時點擊了什麼，在操作某一步停下來是報錯了，還是在思考，還是不知道下一步如何操作，抑或是驗證碼看不清等問題。最關鍵的是，一個新模塊上線的時候，用戶到底用不用，如何使用等，都是我們想要知道的問題。後來我們做了時光機來滿足這個需求，但是沒有想到的是，時光機在解決 Bug 時發揮了更強的作用。
InfoQ：什麼情況下會出現偶發 Bug？它對開發人員會造成什麼影響？傳統監控還存在哪些不足？
陳辰：其實偶現 Bug 最常出現在流程長的操作中。如果是一個非常簡單的場景，問題還比較容易復現。因爲可能出現的問題點就那麼幾個，比如：接口錯誤、返回結構與解析接口不符、常規 JS 運行時報錯等。但在一個長流程中，可能在流程第四步報錯，而問題的原因在操作的第一步就已經埋下了。
在傳統監控中，預警問題已經不是難事。但是對研發人員而言，除去預警問題，解決問題纔是最重要的。監控本身提供給我們的信息，包括操作截圖、堆棧信息、報警趨勢都沒有操作回放來得直接。
InfoQ：解決偶發 Bug 難在哪？
陳辰：解決偶發 Bug 的難點在於『偶發』二字。主要有兩個難點，第一個難點在於，偶發 Bug 意味着你無法知道 Bug 出現的具體場景。就像一個普通的 JavaScript 報錯，這個錯誤可能出現在成千上萬的場景中，僅憑錯誤的堆棧信息往往還是無法 100% 定位問題；另一個難點在於，即使研發人員修復了也沒有辦法驗證，因爲研發人員不知道如何才能觸發這個 Bug。所以，偶發類 Bug 是前端公認的最難修復的 Bug 之一。
InfoQ：操作回放在前端監控中的主要作用是什麼？
陳辰：主要作用還是針對偶發 Bug 的處理，還有定位一個 Bug 是不是前端 Bug。比如我們的系統經常回放已經修復的偶發 Bug 的操作路徑，來確定 Bug 是否修復。再比如產品本身的邏輯就存在死邏輯，用戶無論如何操作都無法進入下一步操作。這類問題用戶也會以 Bug 的形式報給客服，但是前端工程師接到這種問題根本無從下手，唯有看一下用戶究竟是如何操作的回放，才能定位這個問題的原因。
InfoQ：您瞭解到的一些公司的監控現狀是怎樣的？可否結合實例談談？
陳辰：沒有實踐就沒有發言權，我談談我服務過的幾家公司。我在百度的時候，監控是自建的 DP 平臺，當時大概是 2013 年，主要是收集用戶設備信息，幫助監控前端返回一些前端錯誤，當然也有常規的產品指標 PV、UV 的數據。後來所在的公司採用的是第三方的聽雲監控，在業務中使用聽雲做一些自定義數據的收集也不錯，而且對於前端系統侵入性也少一些。後來我們發現研發工程師修復問題時有很強的操作回放的功能需求，因爲我們主要的用戶是經紀人，他們在描述問題時，可能並不像互聯網用戶那麼專業，而且有的堆棧信息可能確實無法排查問題，所以才自建監控，並研發了操作回放的功能。
InfoQ：請您介紹下貝殼自研項目——時光機的技術原理、實際應用情況，以及與燈塔的關係。
陳辰：時光機的技術原理其實是利用了一個監控底層的 SDK 把用戶操作信息做脫敏操作，加密之後上傳到數據收集服務器，通過任務清洗的方式把有效數據和報錯信息做關聯，最終在用戶需要查詢錯誤信息報錯的時候，我們能夠看到用戶的回放信息。目前，它已經在貝殼得到大面積推廣，而且口碑也非常不錯。至於與燈塔監控之間的關係，可以說，時光機是燈塔前端監控的擴展系統，也是可以單獨提供用戶操作回放服務的系統。
InfoQ：時光機最大的亮點是什麼？請您用三個詞概括。它可以在多大程度上避免偶發 Bug？
陳辰：最大的亮點是模擬用戶操作，讓開發人員站在用戶操作的角度。
第一，100% 回放用戶操作。也就是說，用戶做什麼我們就回放什麼，相當於我們站在用戶身後看着用戶操作。這部分最主要的能力就是解決偶發 Bug，因爲對於偶發 Bug 來講，用戶的操作過程以及依賴數據尤爲重要。
第二，真實操作數據。根據用戶操作可獲取操作信息，根據數據分析用戶場景。尤其在分析某類用戶如何使用具體產品功能時，我們會獲取用戶相關的數據，但是相關數據都會經過脫敏處理，並且在用戶協議中告知用戶數據用途，且做到不上傳、不存儲用戶敏感信息。最關鍵的是，時光機服務的系統均爲公司內部經紀人系統，不會收集普通用戶信息。
第三，時間維度 1：1。用戶三小時不動屏幕，我們就回放三小時（當然有快進和跳過無操作的功能）。
InfoQ：貝殼目前在監控平臺的研發投入情況是怎樣的？
陳辰：目前，貝殼監控系統已經覆蓋了 99% 的項目，大概 300 多個項目，包括新房、二手房、裝修、租賃等事業線。大家耳熟能詳的鏈家網、貝殼網等均接入了貝殼前端監控系統。在貝殼，新的前端項目默認接入前端監控已經形成了一種習慣。其實起初，貝殼前端並沒有監控，大多數 Bug 均來自於我們優秀的 QA 同學和一線用戶的客訴，後來我們引入了聽雲系統做一些常規設備的檢查、PV、UV 等數據的統計，但是針對前端報錯、前端報警、強定製化這類問題還是沒有得到解決。所以後來，我們以“比用戶先發現問題“爲目標開發了貝殼前端監控燈塔系統。
InfoQ：結合貝殼在監控開發過程中踩過的坑，請您談談企業在搭建監控時要規避的問題。
陳辰：主要是前端工程師在搭建監控時，存在服務器端知識欠缺、整體的系統設計性差，以及對任務調度、數據清洗等概念缺失的問題。其實前端監控還是由前端工程師來做最好，一是我們很少能在公司內部爭取到後端資源；二是就算爭取到資源需求，項目本身的需求翻譯、原型圖、效果圖、需求文檔也不是程序員所擅長的。
InfoQ：下一步貝殼要攻克的技術難點是什麼？
陳辰：整體前端的產業升級是我們貝殼下一個階段的主要目標，我們要把貝殼的前端開發模式從作坊式的開發，轉變成爲工廠、車間這種標準化、流程化、統一化的前端生態體系。目前，貝殼前端也在專注探索人效的科學計算、科學排期，評估人效比等這類問題。
專家介紹：
陳辰，貝殼找房基礎架構中心前端架構委員會專家、前端架構師、前端開源項目負責人。著有《前端性能優化 - 基礎認知》、《前端性能優化 - 緩存 SDK》。2019 GMTC 大前端大會明星講師，2019 GIAC 全球架構師大會分享嘉賓。《從零開始搭建前端監控》一書作者。
活動推薦：
在12月6日北京 ArchSummit 架構師峯會上，陳辰老師也會分享回放監控系統時光機的架構設計，以及未來監控系統的規劃內容。此外，滴滴出行、網易、bilibili、美團的技術專家也會同臺介紹性能優化等實踐內容。購票可以聯繫票務經理 灰灰 15600537884。