如何創建起一套有效的APP監控體系

概論：

移動APP有着本身獨特的運行環境和使用場景，相比後端服務，移動APP質量一樣須要作到可視、可控。移動APP是近幾年剛剛出現的新產品形態，如何保障 移動APP質量是一個新的挑戰和話題。今天，咱們重點介紹APP端問題如何發現、如何定位、如何止損，以及如何創建起一套有效的監控體系，爲APP穩定應用保駕護航。分爲「端問題概述、端質量監控方案、端監控能力建設」三個章節。

1端問題概述

app客戶端產品上線前，會通過全面並且嚴謹的測試再發布到應用商店。但，發佈後產品質量如何，以往更多地依賴於用戶的反饋信息。對於較大規模的app產品，測試人員沒法作到覆蓋到所有的手機機型和ROM。在這種狀況下，如何知道一款產品到用戶手中的質量呢？此時，須要一套完善的質量監控方案，創建一套牢固的監控體系。這樣，對線上產品的APP質量問題才能第一時間召回，並作到快速修復。

1.1常見問題

1.適配問題

客戶端測試過程當中，測試工程師會覆蓋當前比較主流廠商的機型和ROM,以及市面用戶量比較大的Android/iOS版本。但，畢竟沒法覆蓋到市面上全部的機型和ROM，尤爲是android系統的手機。因此，用戶在下載一款app後常常反饋在本身的手機上頁面很醜，甚至有的文字重疊，控件位置顯示不正確等問題。

舉一個實際遇的問題，當app上線後收到用戶反饋，提到有些頁面滑動比較卡頓，容易形成誤點擊，用戶使用的機型是一款比較主流的手機。在獲取到用戶反饋後，測試工程師立刻找到同款手機進行復現，但未復現用戶反饋的問題。後來從用戶得知復現的手機和用戶的手機雖然相同，可是廠商本身定製的ROM版本不一樣，後來經過研究ROM代碼發現廠商在新版ROM中設計了一些新的邏輯處理，會直接致使app出現卡頓。研發人員對此作了適配解決了卡頓的問題。此類案例證實，務必對主流手機及ROM更新保持較高的質量敏感性，時刻關注廠商升級。快速應變，及時適配到主流機型和ROM。

2.用戶體驗問題

一般，產品經理設計產品功能時，考慮得也不必定很全面，每每抱着試錯的心態來設計產品，並但願經過用戶反饋來得知產品的好壞，以及用戶的進一步需求。一旦考慮不周，每每就是取悅一部分用戶，同時傷害到一部分用戶。舉一個實際例子，某一搜索類產品，產品經理爲讓用戶在夜間瀏覽時有更好的視覺體驗，增長了夜間瀏覽模式的功能。考慮到讓用戶更方便的設置夜間模式，產品設定爲晚上20點之後自動彈出一個浮層，詢問用戶是否設置夜間模式，並且一鍵便可設定，方便了用戶對夜間模式的啓用。但，產品經理忽略了一個重要的問題，晚上用戶啓用夜間模式後，次日早上如何便捷地切換回白天模式？ 而產品並無在早上也設置一個浮層作一鍵切換。這樣，不少用戶在白天也開啓了夜間模式，使用體驗是很糟糕的。問題在於，切換回白天模式的功能雖然具有，可是入口隱蔽，用戶很難找到。從這個問題能夠看出，產品體驗是設計出來的，須要在用戶的實際應用中獲得檢驗。

3.流量問題

 

當前，中國的4G資費相對歐美和日韓目前仍是比較高的，同時免費的公共wifi覆蓋也不高，用戶對非wifi下的移動流量消費是很在乎的。那麼，一款移動app產品如何利用最少的流量下提供更多的功能？經過客戶端緩存是一個常見的技術。舉一個實際例子，以小說閱讀爲例，小說目錄通常是羅列不少書籍供用戶來選擇，這些書籍通常都有書籍名，數據封面圖及書籍簡介組成。一個頁面的數據有150kb，並且這個頁面是小說書單的主入口，全部關於小說的操做都要由這個頁面開始。若是用戶反覆請求這個頁面，不只形成流量的浪費也會給服務端帶來很大的請求壓力。爲此，將這個頁面的數據緩存到客戶端本地，若是用戶在非wifi的網絡下就不發送請求，若是在wifi網絡環境下每間隔必定時間去服務端請求一次數據，而後將老數據刪除，並將新的數據寫到本地，以便用戶可以獲取到最新內容。這樣，不只解決了流量問題，也解決了一些低配手機本地內存常常不足的問題。從這個問題來看，在產品設計時多從用戶的角度出發考慮問題，用戶不必定直觀地感知到，但實實在在的增長了用戶體驗，且減小沒必要要的流量消費，你說何樂而不爲呢。

1.2 問題特徵

上節介紹了三類常見問題。有些問題是比較容易復現和解決的，也有一些問題相對是有難度的。舉幾個例子：

場景一：用戶反饋在WIFI網絡下沒法發起搜素，搜索結果異常。在WIFI環境下復現，沒法復現用戶反饋的問題，這時每每會歸結爲網絡不穩定形成的。但用戶可能當時確實是遇到了問題，這種沒法穩定復現的問題，每每歸結爲偶發性的問題。

場景二：用戶反饋離線下載的小說爲何有時候還須要網絡。因爲用戶離線的小說是個連載的小說，當用戶閱讀完離線的內容後，假設這時候小說有更新了，產品經理爲了讓用戶可以連續的閱讀就將產品設計成聯網發送在線請求才能繼續閱讀，這和用戶的認知就比較相違背。但，若是用戶閱讀完已經離線的部分，用戶看到書沒寫完，也會關心爲什麼沒有新的內容呢。相似的這種問題歸結爲長尾問題，須要從產品策略上持續優化來解決。

APP運行在用戶手機端，而且聯網到後端服務，許多質量問題也有其本身的獨特性。所以，須要經過不一樣手段，來實現問題的發現、定位和修復。

1.3 面臨挑戰

 

對於上述提到的問題，你們可能會問：這些問題該如何發現，對於這些問題如何肯定是否作立刻修復，哪些問題纔算長尾問題？這就是下面將要介紹的線上問題的召回方式和問題影響面的評估。用戶反饋是召回問題的一種方式，可是這種被動的召回不足以知足快速召回線上問題的要求，因此搭建一整套完善的監控系統就很是必要了。

1.監控的挑戰

對於客戶端產品，一旦發佈出去就很難有效的控制產品的質量。爲此，產品經理和數據分析師每每在產品發佈前提出的監控及統計需求，研發工程師開發設計用於監控統計目的的代碼，將用戶的行爲、產品的crash等核心質量信息以日誌的方式上傳到服務端，這些用戶所產生的數據就爲後續分析產品及質量問題提供了原始的數據依據。

2.影響面的判斷

利用客戶端上傳的用戶日誌及客戶端崩潰信息，進行統計分析。結合線上問題，可進行影響面的評估。影響面評估主要有三類，包括嚴重問題，特定場景復現問題，不影響主要功能問題。

1) 嚴重問題通常是要發小版原本修復的問題

2) 特定場景復現問題通常不會發小版本修復，但必定會在下一個版本進行修復

3) 不影響主要功能問題視下一個版本的排期進行修復或刪減掉

2端質量監控方案

因爲APP載體多種多樣，產品質量問題表現形式有不少種。咱們以最通用的APP爲例，總結爲如下幾種：

- 來自APP產品所依賴的後端服務的問題

- 來自APP產品自身的問題，包括穩定性問題，表現爲： 應用crash（崩潰）、ANR（APPlication Not Responding）、網絡錯誤、請求響應時間長、用戶交互不流暢、機型、ROM適配度不夠引發的兼容性問題。

- 來自APP和後端服務之間的鏈路問題，通 常有：網絡問題形成的丟包、TCP重傳等等。

對於APP質量監控，能夠從三個方向去佈局一套完善的監控體系：問題發現、問題定位、問題止損。

2.1 問題發現

因爲APP受用戶機型、手機ROM、網絡環境、用戶操做路徑差別的影響較大，QA沒法保證在測試階段暴露全部問題，這就要求咱們創建一套線上問題發現體系，及時召回已經交付到線上的移動產品。一套完善的線上問題發現體系，一般來講須要根據產品的核心業務，抽象出核心指標，實現指標量化；制定質量標準，提供實時監控報警。 

根據咱們的經驗，APP應用的質量指標包括但不侷限於：安裝成功率，崩潰率，ANR比例，網絡錯誤比例，請求響應時間等。質量指標與具體的應用功能緊密相關。理論上抽取指標後，如何量化是最關鍵也是最困難的一步。量化須要有效的問題信息獲取途徑，日誌埋點是一種很是通用的方法，而另一種途徑，用戶反饋， 雖然經常被開發者忽略，卻一樣重要。 

2.1.1 用戶反饋：海納百川

一款應用想要在應用市場份額中分得一杯羹，長久地留住用戶，須要依賴良好的應用功能和產品體驗。用戶反饋表明着市場對這款應用的滿意度，可以直接反映用戶的判斷和訴求，也是這款應用迭代改進的第一手資料，前期咱們能夠經過市場調研等方式獲取反饋，可是受限於人力和時間成本，咱們很難在用戶量巨大的時候複用此法，或者說市場調研始終只能採樣而沒法全量覆蓋。 

基於上述，只有提供一個入口，讓全部用戶的反饋能夠如江河入海，匯於一處，咱們才能獲取到來自不一樣地域、不一樣網絡、不一樣機型、不一樣場景下的用戶反饋，進而聚類、分析、改進咱們的產品。

用戶反饋的通用方法並沒有太多新奇之處，市面上不少移動應用都會在應用設置頁面中附上一個用戶反饋的入口，如圖2.1中百度雲和愛奇藝視頻的用戶反饋界面。

 

咱們必需要明白一點，現在快節奏的生活中，用戶願意提交一個反饋，那這個問題對他/她來講必定是一個很大的困擾，並且他/她又是一個比較忠實的用戶，同時對這款應用抱有期待，但願開發者能夠改進。因此一旦這個產品開始提供更穩定或者功能更多的收費服務來嘗試變現，那麼這部分用戶會是最大的潛在羣體。

 

一個普通的用戶反饋頁，倒是於細微處見真章的最好實例，這兩個頁面的設計告訴咱們用戶反饋的重要原則：

• 反饋入口路徑儘量短：上述的兩個反饋入口都在應用的設備界面，進入反饋頁面須要2步操做。這一複雜度剛恰好，若是一個反饋須要用戶操做四、5步才能找到，那麼用戶的熱情會被這種來自技術的傲慢消磨殆盡。

• 反饋內容的提交成本儘量低：左側圖片中愛奇藝的用戶反饋，不只事先列出了用戶最可能遇到的幾種問題，還在頁面下方給出了常見問題的FAQ。不要小看了這一細節，咱們能夠經過這樣的方式，在無形之中完成一次用戶問題反饋+調查問卷。

• 對用戶的答覆應該儘量的快：若是想要給用戶反饋的過程提供更實時的體驗，那就要求咱們在用戶反饋頁面完成一個IM的功能，這對大多數處於創業階段的開發者來講並不現實，因此咱們建議採用集成插件的方式來達到這一目的。

 

下面推薦幾款經常使用的用戶反饋平臺：

1)    美洽，基於HTML5開發，只需在IOS/Android支持H5的瀏覽器中打開便可，無需安裝任何軟件程序，代碼植入，一步到位，簡化溝通流程。

2)    Udesk：支持Android、IOS以及APIcloud三大平臺，能夠對用戶反饋的數據作統計分析，並展現結果。

3)    Freshdesk，致力於中小企業網站在線客服技術支持的網站，提供中小企業網站的在線服務質量和用戶體驗度。

 

除了在應用中直接反饋，也能夠建立用戶羣（QQ，微信或其餘企業級IM），針對嚴重問題能夠第一時間發現，直接與用戶溝通，輔助復現、抓取問題現場信息等，這些對問題的定位和解決是相當重要的。

 

2.1.2 日誌埋點：秣馬厲兵

 

在一個移動應用設計之初，開發者一般考慮的是功能、架構、開發週期等問題，這一類問題一般直接影響應用的發佈週期，可是你們每每會忽略一個重要的過程，那就是日誌埋點。

爲什麼要埋點

經過用戶反饋發現問題畢竟有必定的延時，甚至有一些線上問題會阻塞用戶反饋，例如：連續頻繁的崩潰，用戶反饋模塊自身的Bug等。要想更迅速及時的暴露問題，須要咱們主動出擊，獲取用戶操做的關鍵信息。

埋點於何處

日誌埋點的原則：好的埋點能夠達到一夫當關萬夫莫開的效果，將全部咱們須要的信息經過日誌的形式打印出來，選擇性或者全量的上傳給應用的後端服務，用於支持問題發現或服務改進。

受限於APP應用的運行環境，咱們不可能在全部的地方進行埋點，筆者在多年的軟件開發維護過程當中，也見過因爲日誌添加不當引發程序崩潰問題。

 

根據自身經驗，咱們總結出下列日誌埋點的建議：

1）   由目標驅動埋點：一個移動應用，開發者或者用戶但願瞭解的服務指標，必須由日誌埋點解決；

2）   日誌框架通用：應用的第一個版本在日誌框架上面花的時間，直接影響後續版本的開發效率。通用和穩定是這個框架必需要考慮的問題。

3）  日誌上傳：對於已經獲取的埋點日誌，咱們必須考慮它對用戶流量及交互流暢度方面的影響——畢竟它的上傳使用的是用戶網絡，尤爲是在收費的移動網絡下更要慎重。有以下手段可參考：日誌壓縮和私有協議、用抽樣上傳代替全量監控；若是日誌對時效性的要求不高，能夠考慮採用打包總體上傳代替實時上傳的方式，甚至能夠天天上傳一次。這些都須要在框架中提早作好部署工做。

4）    日誌安全：用戶日誌中可能包含用戶我的信息、用戶行爲及隱私，一旦信息泄露，可能給用戶形成經濟、安全等方面的損失，嚴重影響用戶對應用的信任。故日誌安全是重中之重，目前行之有效的方法主要有加密和使用安全協議。相對於加密算法較容易被破解的風險，安全協議提供了更嚴密的保護。目前應用比較普遍的安全協議主要有https，spdy等。

2.問題定位

線上問題的快速定位和解決能夠直接縮短用戶體驗受損的時間，一般有如下幾種定位思路：

1）日誌分析法

當遇到一個問題時，咱們最早想到的可能就是查看日誌，用戶日誌是定位問題的最直接的信息來源和方法。日誌分析又能夠分爲兩種手段：一是從統計學的角度分析大 量的問題日誌，總結聚類，經過其中共性的特徵，發現潛在的問題；另外一種是針對某個有明確問題反饋的用戶，查詢其一段時間內的全部操做流程及結果，經過上下 文推測問題緣由，也能夠輔助線下復現。

固然並非全部的問題均可以經過用戶日誌定位，好比日誌不全或日誌提供的信息並不足以精肯定位問題，怎麼辦呢？那就要求咱們可以復現這一問題。

2）問題復現法

經過用戶對問題的現象描述，以及已有的用戶日誌，嘗試線下復現。復現時須要關注用戶的機型，平臺，網絡類型，是否設置了代理，甚至是用戶所處的地理位置（不 同地域的運營商網絡可能有較大差別）等，結合應用所提供服務的邏輯，推測可能出現該問題的緣由，儘可能增長復現的可能性。

3）推測驗證法

固然，APP的問題很大程度上依賴於當時的問題環境，包括機型，平臺，網絡狀況，手機安裝的應用等，都給線下復現帶來了巨大的困難。而現有的問題日誌又不足 以精準定位。在這種狀況下，能夠經過問題的現象描述和以有的日誌，推測可能的問題緣由，埋點監控，經過分級發佈的模式，當問題再次發生時，驗證哪一個推測是 root cause。

4）上下游合做分析

有些功能須要多方合做實現，當這些模塊出現問題時，你們通力合做，可能就會離問題的解決更近一步。

3.問題止損

線上問題時時刻刻影響着用戶體驗，及時止損頗有必要。問題止損不只僅是指定位到了問題的root cause從而實現完全解決，也包括在問題完全解決以前，如何將對用戶的不良影響降到最低。

 

對於APP產品，不能像後端服務那樣經過緊急下線/上線補丁解決問題，只能依賴於應用發版，而用戶的升級轉化也是一個比較漫長的過程。在這種困境中，雲端控制和熱修復爲咱們帶來了曙光。下面主要闡述雲端開關控制的思路。

 

針對APP上影響/風險比較大的功能模塊，預先設置好開關，發生問題時，能夠經過雲端下發關閉指令，及時止損。雲端控制是一個概念，實現方式因業務和功能而 異。受限於自身經驗，咱們沒法提供通用的多平臺解決方案，可是大道至簡，咱們但願提醒開發者的是：從代碼設計開始，考慮應用、系統、服務三個維度的容災 性。

 

一個簡單的例子：咱們能夠把功能開關置於一個獨立的Web Server中，APP採用輪詢或者更加精準的動態策略去訪問這個靜態文件，當服務某個環節出現問題時，只須要修改WebServer中的開關文件，關閉相關功能或者將相應的服務導向備用地址，便可快速的止損。

另一種方式和上述方案相似，只不過實現的時候不使用訪問雲端文件，而是由服務端直接向全部APP應用下發指令，用於啓停某些功能甚至調整某些內部模塊的邏輯。這種方式更直接，可是對APP的代碼的開發提出了至關高的要求：

1）  模塊間代碼耦合度要極低，從而可以作到動態調整邏輯；

2）  若是雲端控制只用於事故止損，那麼就要求全部受影響的應用必須保持後臺在線或者前臺運行的狀態。不過具體到當前市場份額最大的幾個手機/移動操做系統，咱們能夠經過推送通知的方式的，儘量由用戶主動喚起應用，藉此來得到下發雲端命令的機會；

 

咱們建議開發者能夠綜合考慮應用的代碼風格、業務類型、風險類型，來選擇某一止損的方案。上述兩種方案並不是最優解，實際的開發過程當中可能須要綜合多種方案來達到高可用服務的標準。

 

同時，目前業界也涌現出一些成熟的解決方案，如iOS平臺的APP動態更新服務JSPatch(http://jspatch.com)就是一個專一於此領域的平臺，開發者能夠試用、借鑑。

 

3監控體系建設

3.1質量標準

1.什麼是質量標準：

質量標準是產品生產、檢驗和評定質量的技術依據。產品質量特性通常以定量表示，例如強度、硬度、化學成分等；所謂標準，指的是衡量某一事物或某項工做應該達到的水平、尺度和必須遵照的規定。而規定產品質量特性應達到的技術要求，稱爲「產品質量標準」。--（百度百科）

客戶端做爲與用戶直接與用戶打交道的產品，其用戶體驗是衡量一個客戶端的重要部分。用戶體驗包含了視覺、友好性、易用性等等方面。可是其視覺等方面很難經過量化的方式進行度量。可是產品的核心功能等倒是經過一些數據的度量來衡量產品的易用性等。所以，產品的質量標準就應運而生。

在服務類產品中，經常使用SLA（Service-Level Agreement）做爲衡量產品服務等級的量化指標。按照業務的需求對業務的，對業務的服務指標制定量化的標準，經過量化的標準來衡量和驅動產品的服務愈來愈好。例如做爲APP產品中的crash率，是衡量一個APP穩定性的數據指標，經過對crash率的統計數據衡量分析，來保證每一個發版的APP健壯性獲得保障。

2. 質量標準應如何制定：

質量標準的目的是經過對業務數據的量化與衡量來保證服務的質量，經過質量標準的衡量來推進業務質量變得愈來愈好。那麼應該如何來制定質量標準呢？

根據百度雲的經驗，質量標準的創建大體總結爲：一個核心、三個階段：

一個核心：時刻以產品線的業務發展爲核心

三個階段：初期階段、中期階段和進階階段

爲何質量標準的創建要圍繞發展來制定。舉個例子，好比百度錢包，錢包在初始階段，其核心的業務指標爲發展用戶，那麼用戶的登陸，日活等指標爲錢包的最核心的指標，當時錢包尚未APP端，顯然，更不會有Crash率等方面的標準。在錢包發展到必定階段，綁卡用戶變成了錢包的另外一個核心指標。那麼幫卡率變成了業務的核心發展指標。相應的核心質量標準也應該變爲綁卡成功率。所以，質量標準的制定必定要圍繞業務發展爲核心。

在業務發展的不一樣階段所設定和採納的質量標準也是不盡相同的，按照標準由粗到細，量化難度由易到難的階段一步一步發展而來的。

初期階段：業務發展的初期或者業務發展到必定的階段，經過需求或者用戶反饋來收集到產品線在發展過程當中須要核心保證的top功能，這個核心的功能是一個產品生存的支柱，也就是咱們須要經過質量標準來衡量咱們核心業務提供的服務好壞程度。舉個例子，客戶端的崩潰狀況，是每一個產品線所要保證的最基本的質量防線，崩潰率的高低，決定了用戶的留存狀況，所以，全部產品線都應將崩潰率做爲最基本質量標準。而對於不一樣的產品線，則有各自自身的核心業務指標，好比手百，死鏈的狀況則是關係到用戶體驗的最核心指標；下載的成功率是百度雲用戶體驗的最核心指標；定位和路線的準確性是地圖最核心的用戶體驗指標。這些也就是各個產品在最初創建質量標準時最關係的方向。

中期階段：中期階段，是在初期階段的質量指標創建完以後，而且在指標的數據獲取，指標的計算公式都獲得檢驗以後（尤爲是獲得peer角色的承認），進入到成熟階段。中期階段的目標是創建多個完整的子業務質量閉環。客戶端的呈如今用戶面前的服務能力和用戶體驗，是每一個業務的綜合能力體驗，對於客戶端自身的業務、服務端的服務能力、中間網絡抖動狀況都密不可分。所以，想要達到一個服務單元的完整質量閉環，必須能cover到整個業務鏈條中的每一個質量節點。好比百度雲的下載業務，一個完整的下載，從層級上面看，大體分爲三個層級：1.APP自身下載邏輯，主要涉及到下載的重試、併發、容錯等 2. 中間業務層， 主要是在下載過程當中的下載分發、防盜鏈、PASS校驗、CDN回源等等。3. 底層數據拉取，主要是分片數據的重組文件、跨機房的文件拉取等等。因此要完成一個整個下載的質量閉環，必須cover整個質量閉環的關鍵節點， 每一個關鍵節點都會指定相應節點的標準，每一個節點的質量好壞的變化，都會在端的質量數據中有所體現。 

進階階段：進階階段是在中期階段相對成熟以後，針對於業務複雜的每一個子業務都能經過服務單元中的核心節點數據來對質量作出評價。進階階段，對於每一個細節的標準都很全面。任何影響到產品體驗，和客戶端的運行質量的，都能經過數據分析獲得。在中期階段，有了各個垂類業務的數據，以及在垂類的鏈條上面的關鍵節點的數據，可以清晰的知道垂類業務的質量。對於比較複雜的業務，其每一個質量節點影響的不僅僅是一個垂類的業務。在進階階段，經過對詳細子業務以及子業務之間的關係進行聯繫與刻畫，造成了一張聯動的質聯網。

3.質量標準的用處：

質量標準的設定主要的目的是經過質量標準的驅動來驅使業務質量變好。質量標準按照覆蓋範圍來分主要分爲兩大類：一是通用型，好比 crash率；二是與自身業務緊密相關的。

 

1)    質量標準最初級的用處：衡量業務的好與壞。經過量化的手段，對於業務的服務，APP的運營質量，進行度量。

2)    發現業務中的缺陷：經過對服務單元中的質量數據度量，發現業務質量中的薄弱環節，對於問題的發現和業務的優化提供數據支撐。

3)    業務貢獻：經過對質量數據的分析與整合，對於產品策略提供數據支撐和評判。

 

3.2能力指標

1. 數據獲取的能力：

基礎數據是質量標準創建的基石，數據獲取是一個產品線成熟度的一個標識。通常APP的數據獲取途徑主要有兩大類：1. 通用第三方統計平臺：例如mtj以及一些第三方的數據統計平臺，經過提供SDK的方式，對APP的運行狀態等指標進行統計上報，並給出圖形化的分析報告。2. 自身業務的數據上報：經過業務埋點或者本身編寫的SDK捕捉上報。針對自身埋點或者本身編寫SDK的方式，更加靈活。可是須要投入相應的人力和機器資源。

2. 數據分析的能力：

在數據獲取的基礎之上，數據分析是數據轉化成質量數據、質量標準的必經之路。數據分析的過程，是離散的業務數據，經過按照對業務梳理的方面進行劃分、統計聚合，變爲對業務有用的數據。業務數據的分析的能力集中體如今兩個方面：1. 數據計算能力，對於離散數據的計算，須要大量的數據計算才能完成，一套高效、運行流暢的計算框架是對於大數據計算的前提。2. 業務梳理能力，須要對業務的理解和上下游串聯有比較細粒度的認識。3. 業務數據分析的能力，對於統計後的數據，可以對應到業務的表現，並能經過數據的變化來預測或者對於平臺業務的好壞。

3. 質量數據的閉環：

質量數據的閉環是一個比較長期的過程，經過對數據的獲取、數據的分析後，得出業務中不合理或者比較薄弱的地方，經過制定合理的優化方案，對業務進行調整優化。而後循環往復來達到質量數據的閉環。

3.3數據利用

數據分析，是整個監控的最核心，也是難度最大的工做。數據分析，是結合業務的邏輯，經過基礎數據進行計算統計後，分析對應到業務邏輯。經過數據的變化，來解釋業務的變化與好壞程度。

數據可視化，是數據監控的一個效果展現。好數據展現，能保證用戶更好的分析數據的變化與數據直接的內在聯繫。數據的可視化的重要程度也是不言而喻，其像發動機的潤滑油，可以讓整個監控體系，更高效，更加順暢的運轉起來。