前言
Crash（造成使用者無法使用客戶端所承載的服務）作為客戶端穩定治理的最主要問題之一。雲信作為國內業界領先的 RTC/IM PaaS 服務商，對於客戶端 SDK（PaaS 服務商對外服務的主要載體）的 Crash 治理再重視也不為過。關於客戶端 Crash 穩定性治理，儘管業界已有多個成熟的監控平臺，實現了從埋點、上報、展示到報警一站式服務，如 Bugly 平臺、Fabric 平臺等，也有 Crash 捕捉的工具 SDK，方便在此基礎上按需定製監控平臺，如 KSCrash、Breakpad 等。但對於雲信這樣的 RTC&IM PaaS 服務商來講，無論是市面上現有 APP Crash 治理平臺，還是 Crash 捕捉工具 SDK 都是無法解決針對 PaaS 服務商 Crash 異常治理痛點。
• 平臺型別支援有限
業內平臺往往只覆蓋主流的兩個移動端平臺 iOS/Android、對於 Mac OS/PC/Linux/Flutter 不支援。
• APP 與 SDK 監控資料無法有效隔離
業內對外服務的 Crash 收集平臺基本都是設計服務於 APP，後臺分析與展示無法同時對 APP 和 SDK 進行區分。
• 問題治理實現不了閉環處理
以業內著名 Bugly 為例，只提供了對外閉源 SDK，Bugly 後端目前也沒有開放第三方介面，崩潰資訊都要人工去主動搜尋處理，無法與 PaaS 服務商內部 Bug 管理系統進行聯動，異常感知也沒法自動感知與推送，形成不了 Crash 問題從捕獲到研發人員響應處理高效的閉環。
Crash 異常治理建設
為了解決以上 PaaS 服務商穩定性問題治理的痛點，構建一套從異常問題捕捉到研發人員高效問題處理的監控分析系統就顯得格外迫在眉睫了，雲信研發團隊從以下三個維度思考：
• 如何實現數字體驗監控：採集的指標有哪些，以及這些指標的影響是什麼？
• 異常發現、跟蹤及診斷：異常指標如何轉化為具體可處理的方案，如何快速找到問題模組？
• 面向技術人員的自動化運維：如何實現問題分析的精準性，如何降低研發分析耗時與成本？
經過大半年多的努力，終於落地了 Crash 穩定性治理平臺（以下簡稱 Marvel）平臺，實現了 Crash 問題的高效治理。該平臺基於 PaaS 服務商的特點，設計了三級的賬號體系，平臺覆蓋了 Android、iOS、Windows、MAC、Linux、Web 平臺、Flutter 框架, 最終實現從問題捕獲、分析處理問題、修復、覆盤全鏈路的閉環，下文將針對該平臺做較為詳細的介紹。
平臺架構設計
Marvel 平臺架構設計圖
如上圖所示, 從資料流角度可知，當 CI 構建服務完成產品各個客戶端平臺 SDK 包的時候，系統會自動將 SDK 包對應平臺的符號表檔案上傳到 NOS（網易物件儲存）檔案服務，同時將 SDK 版本號、各個 SO 庫的 build_id/uuid、Github 倉庫地址等元資訊記錄到平臺資料庫中，為後續異常解析服務查詢奔潰庫所屬的符號表檔案做準備。當 C 端發生 Crash 問題的時候，系統首先會將 Crash 資訊（棧資訊、使用者操作軌跡、uuid/build_id 等資訊）上傳到 Marvel 後臺服務，系統經過資料清洗以及異常解析之後，精準地分析出該 Crash 屬於哪個模組，平臺支援根據模組歸屬人查詢表或者根據 git commit 記錄查詢出最後程式碼變更人, 最終自動生成 Jira 工單，然後透過公司內部協作工具（POPO）同步異常待處理訊息給對應的研發同學。從而最終實現了線上異常處理的自動化閉環操作。
平臺全景檢視
Marvel 系統全景檢視
雲信當前 Marvel 平臺除了重點落地實現了 Crash 穩定性問題治理之外，同樣也實現了部分平臺其它穩定性問題的治理，如卡頓、記憶體洩漏、記憶體溢位、ANR、Watchdog 等客戶端的穩定性問題，穩定性問題發生的上下文資訊（使用者的行為軌跡、應用的上下文等資訊資料），透過 ES 搜尋引擎和 HBASE 資料庫實現海量資料的儲存以及快速資料聚合查詢，最終能夠快速實現場景還原，實現問題的重現，最終實現快速分析定位問題。
賬號體系設計
傳統的異常捕獲系統是基於 APP 維度來統計 Crash 等異常資訊的，而作為 PaaS 服務商，希望看到的是從 PaaS 服務產品及對應的 SDK 維度來統計 Crash 資訊，因此雲信設計了三級的賬號體系，以支援每個層級來做聚合統計監控。
賬號體系設計圖
三級賬號體系說明如下：
• 公司級別。如易盾、雲信等 PaaS 服務廠商。
• 公司產品SKU。如雲信有 IM SDK、RTC SDK、播放器 SDK。
• SKU 下的子產品。如 RTC SDK 下有美顏、背景替換、水印等外掛化的子產品。
治理涵蓋研發全週期
穩定性問題治理週期
穩定性問題治理需要貫穿整個軟體研發的完整生命週期，包括需求研發、測試、整合、灰度、上線等，上述每個階段，研發同學都應該格外重視穩定性問題的發現和治理。於是針對各個階段的資料採集也就格外的重要，當前雲信的穩定性問題治理平臺已經完成了線下場景的全覆蓋，以及線上場景的部分覆蓋。當前上傳到平臺的資料主要分為 Monitor、Logging、Tracing 三類。Trace 資料主要指的是程式碼呼叫棧資料；Log 主要是使用者行為軌跡資料、客戶端系統日誌等；Monitor 資料主要是與人們異常模型相匹配的異常資料。
端側功能集
端側 Marvel SDK 功能模組
端側 SDK 層面功能以小的顆粒度接入。在設計開發上實現採集功能的模組化，各個應用可以根據自身需要選擇性引用功能模組，從而保證穩定性監控 SDK 對於應用的包體積及效能達到最小影響。除了提供原子的監控採集能力外，為了實現監控 SDK 的容錯與容災能力，Marvel 平臺除了會對線上應用實時採集功能開關控制之外，監控 SDK 當遇到本身執行異常的時候也會自動進行功能關閉，對於問題能夠做到自動隔離。
堆疊解析服務
在每個異常上報中，除了基礎元資訊外，還包括異常型別、異常訊息、異常堆疊等執行時內容，特別是堆疊資訊，能夠有效地協助研發去識別異常點。那麼我們就可以依據堆疊和異常型別來做聚合。
簡單來說，可以按照堆疊資訊做 Hash 比對來去重，雖然該方案能夠大幅減少重複異常，但還是會存在大量同類問題歸結為不同類別的情況，例如在遞迴情況下的異常，遞迴深度不同就會導致 hash 結果不一致。考慮 ROI 比當前我們只擷取非系統的使用者函式堆疊，後期考慮引入些更高階的演算法， 對相似的堆疊能夠更加精準的歸因（如對堆疊距離、TF-IDF 等手段對堆疊的內容進行解析，然後利用相應的公式來計算兩個堆疊之間的相似性）。
從可觀察性的指標來看堆疊資訊對應就是 Tracing 資料，堆疊還原服務是決定後續是否能對問題進行精準分析歸因的關鍵。透過還原後堆疊資訊 Marvel 可以快速定位到程式碼行。然而線上執行時的程式為了安全和安裝包體大小等因素，會對程式碼進行混淆或者壓縮，所以獲取到的堆疊文字是混淆壓縮後的堆疊資訊。為了使開發人員直觀快速地理解堆疊含義，這就需要使用相關的符號檔案來對混淆或者壓縮的程式碼資訊做還原處理。
客戶端平臺堆疊還原支援情況
早期 Marvel 符號化解析主要依賴原生平臺工具，但存在以下問題：
• 低效能
因為各個端提供的是命令列工具，所以需要在服務內部透過命令列呼叫，這種啟動子程式的方式會帶來大量的程式建立和銷燬的效能損耗。此外，因為需要啟動命令列子程式處理，處理跨程式通訊也會帶來較大的效能開銷；透過命令列每次呼叫都要重複讀取解析符號檔案，帶來了額外的效能開銷。
• 難維護
因為命令列是透過子程式處理，無法管理命令列子程式的狀態，對命令列的異常的定位解決帶來了複雜性；不同端的工具會依賴不同語言和執行環境，例如 iOS 的 atos 需要執行在 MacOS 環境下，這個對服務的統一部署非常不友好。
為了解決以上問題，當前 Marvel 採用 Rust 實現了各個端側的符號解析，保證各個符號資訊只做一次解析，並轉為 KV 結構形式快取處理。統一語言後也能降低程式運維複雜性，並服務 docker 容器化的需求。
當前堆疊還原相關的主要有兩個服務：
• 符號表管理服務
負責符號表的上傳、下載、解析、快取等流程的管理。符號表上傳之後，該模組會實時解析檔案，並將其解析為 KV 的形式寫入 Redis 快取之中。同時，還會負責符號表檔案儲存和快取的管理。
• 堆疊還原服務
負責堆疊還原，以 gRPC 的形式提供還原服務。當接收到還原請求時，會在 Redis 中查詢相關的符號資訊，並將這些資訊拼接為完整的堆疊，返回給請求傳送端。
異常問題自動化分發
上一章節介紹了 Marvel 平臺系統的整體架構設計、賬號體系設計、端側功能集、堆疊解析服務等重點模組實現，本章節將重點講解平臺對於 Crash 異常問題的高效分發處理。
一個高效穩定性治理平臺,自動精準分發異常的能力是必不可少的, 幫助 PaaS 服務方快速收到報警、快速響應使用者遇到的問題。關於系統是如何根據堆疊資訊來追蹤與查詢 Crash 處理研發人員了，上節第一 小節已詳細說明，這裡就不再重複了。
問題分發雲信當前主要採取以下兩個策略:
• 包含業務堆疊的異常, 透過構建整合平臺的元件維護人員資訊,直接指派到開發負責人。
• 對於沒有業務棧幀的異常, 根據平臺上專案建立人進行指派。
下文以 iOS 穩定性治理為例展示平臺系統實現。
- 聚類展示
Crash 異常問題聚類 UI 展示
- 異常連結推送
SDK 系統異常連結推送通知
- 工單建立通知
POPO- JIRA 建單連結推送
- 平臺異常與 Jira 關聯
平臺 Crash 異常與 Jira 關聯
- 異常項與 CI 產物符號表關聯
Crash 異常與 SDK 版本符號表關聯
- 異常堆疊還原展示
Crash 異常堆疊還原圖
總結與展望
以上就是雲信研發團隊對於客戶端 Crash 穩定性問題治理與總結，文章針對 Marvel 平臺的架構設計、賬號體系設計、治理週期、端側功能、堆疊解析服務等進行了詳細闡述。該平臺的落地使得雲信的研發效能得到了大大提升。在 Marvel 平臺上線前， Crash 等穩定性問題異常處理如下圖所示，全流程人工作業，排查問題需要前後反覆溝通，並且資料來源完全依賴終端使用者配合匯出崩潰資料，響應鏈路長並且往往存在缺少資料來源而沒法定位的問題，產研側也無法主動感知線下/線上的穩定性問題。
舊流程：
新流程：
後續雲信研發團隊將繼續從以下幾方面進一步建設與完善 Marvel 平臺。
完善端側疑難雜症的問題治理
• 覆蓋與完善更多端側的穩定性問題治理；
• 如 Android oom 治理 ， 完善記憶體治理手段與分析 ，下一步完善問題判定規則。
一站式服務
端側的問題並非孤立存在，它可能會受到後端的服務質量影響，雙端的資料聯通與關聯能夠為業務構建起完整的應用質量地圖。後續 Marvel 將與更多內部平臺聯動如後臺監控、後臺日誌團隊在資料服務上做聯動，為應用服務提供一站式監控、定位、容災服務能力。
智慧歸因分析
本著資料驅動的理念，以及高效挖掘並利用已有資料的思路。Marvel 後續將透過結合研發期間的資料，透過釋出資訊、程式碼變更資訊、測試案例等，構建研發流程畫像，同時結合線上觀測資料與問題詳情構建的線上質量畫像，實現快速聚合分析歸因，做到研發內問題提前預警，以及線上問題的在程式碼和責任人層面的根因分析，降低研發排查問題的時間消耗以及人員溝通成本，助力效能提升。