如何建立起一套有效的APP監(jiān)控體系-創(chuàng)新互聯(lián)

概論：

創(chuàng)新互聯(lián)建站2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元淮濱做網(wǎng)站,已為上家服務(wù),為淮濱各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108

移動APP有著自己獨特的運行環(huán)境和使用場景，相比后端服務(wù)，移動APP質(zhì)量同樣需要做到可視、可控。移動APP是近幾年剛剛出現(xiàn)的新產(chǎn)品形態(tài)，如何保障 移動APP質(zhì)量是一個新的挑戰(zhàn)和話題。今天，我們重點介紹APP端問題如何發(fā)現(xiàn)、如何定位、如何止損，以及如何建立起一套有效的監(jiān)控體系，為APP穩(wěn)定應(yīng)用保駕護航。分為“端問題概述、端質(zhì)量監(jiān)控方案、端監(jiān)控能力建設(shè)”三個章節(jié)。

1端問題概述

app客戶端產(chǎn)品上線前，會經(jīng)過全面而且嚴謹?shù)臏y試再發(fā)布到應(yīng)用商店。但，發(fā)布后產(chǎn)品質(zhì)量如何，以往更多地依賴于用戶的反饋信息。對于較大規(guī)模的app產(chǎn)品，測試人員無法做到覆蓋到全部的手機機型和ROM。在這種情況下，如何知道一款產(chǎn)品到用戶手中的質(zhì)量呢？此時，需要一套完善的質(zhì)量監(jiān)控方案，建立一套牢固的監(jiān)控體系。這樣，對線上產(chǎn)品的APP質(zhì)量問題才能第一時間召回，并做到快速修復(fù)。

1.1常見問題

1.適配問題

客戶端測試過程中，測試工程師會覆蓋當前比較主流廠商的機型和ROM,以及市面用戶量比較大的Android/iOS版本。但，畢竟無法覆蓋到市面上所有的機型和ROM，尤其是android系統(tǒng)的手機。所以，用戶在下載一款app后經(jīng)常反饋在自己的手機上頁面很丑，甚至有的文字重疊，控件位置顯示不正確等問題。

舉一個實際遇的問題，當app上線后收到用戶反饋，提到有些頁面滑動比較卡頓，容易造成誤點擊，用戶使用的機型是一款比較主流的手機。在獲取到用戶反饋后，測試工程師馬上找到同款手機進行復(fù)現(xiàn)，但未復(fù)現(xiàn)用戶反饋的問題。后來從用戶得知復(fù)現(xiàn)的手機和用戶的手機雖然相同，但是廠商自己定制的ROM版本不同，后來通過研究ROM代碼發(fā)現(xiàn)廠商在新版ROM中設(shè)計了一些新的邏輯處理，會直接導(dǎo)致app出現(xiàn)卡頓。研發(fā)人員對此做了適配解決了卡頓的問題。此類案例證明，務(wù)必對主流手機及ROM更新保持較高的質(zhì)量敏感性，時刻關(guān)注廠商升級?？焖賾?yīng)變，及時適配到主流機型和ROM。

2.用戶體驗問題

通常，產(chǎn)品經(jīng)理設(shè)計產(chǎn)品功能時，考慮得也不一定很全面，往往抱著試錯的心態(tài)來設(shè)計產(chǎn)品，并希望通過用戶反饋來得知產(chǎn)品的好壞，以及用戶的進一步需求。一旦考慮不周，往往就是取悅一部分用戶，同時傷害到一部分用戶。舉一個實際例子，某一搜索類產(chǎn)品，產(chǎn)品經(jīng)理為讓用戶在夜間瀏覽時有更好的視覺體驗，增加了夜間瀏覽模式的功能。考慮到讓用戶更方便的設(shè)置夜間模式，產(chǎn)品設(shè)定為晚上20點以后自動彈出一個浮層，詢問用戶是否設(shè)置夜間模式，而且一鍵即可設(shè)定，方便了用戶對夜間模式的啟用。但，產(chǎn)品經(jīng)理忽略了一個重要的問題，晚上用戶啟用夜間模式后，第二天早上如何便捷地切換回白天模式？ 而產(chǎn)品并沒有在早上也設(shè)置一個浮層做一鍵切換。這樣，很多用戶在白天也開啟了夜間模式，使用體驗是很糟糕的。問題在于，切換回白天模式的功能雖然具備，但是入口隱蔽，用戶很難找到。從這個問題可以看出，產(chǎn)品體驗是設(shè)計出來的，需要在用戶的實際應(yīng)用中得到檢驗。

3.流量問題

當前，中國的4G資費相對歐美和日韓目前還是比較高的，同時免費的公共wifi覆蓋也不高，用戶對非wifi下的移動流量消費是很在意的。那么，一款移動app產(chǎn)品如何利用最少的流量下提供更多的功能？通過客戶端緩存是一個常見的技術(shù)。舉一個實際例子，以小說閱讀為例，小說目錄一般是羅列很多書籍供用戶來選擇，這些書籍一般都有書籍名，數(shù)據(jù)封面圖及書籍簡介組成。一個頁面的數(shù)據(jù)有150kb，而且這個頁面是小說書單的主入口，所有關(guān)于小說的操作都要由這個頁面開始。如果用戶反復(fù)請求這個頁面，不僅造成流量的浪費也會給服務(wù)端帶來很大的請求壓力。為此，將這個頁面的數(shù)據(jù)緩存到客戶端本地，如果用戶在非wifi的網(wǎng)絡(luò)下就不發(fā)送請求，如果在wifi網(wǎng)絡(luò)環(huán)境下每間隔一定時間去服務(wù)端請求一次數(shù)據(jù)，然后將老數(shù)據(jù)刪除，并將新的數(shù)據(jù)寫到本地，以便用戶能夠獲取到最新內(nèi)容。這樣，不僅解決了流量問題，也解決了一些低配手機本地內(nèi)存經(jīng)常不足的問題。從這個問題來看，在產(chǎn)品設(shè)計時多從用戶的角度出發(fā)考慮問題，用戶不一定直觀地感知到，但實實在在的增加了用戶體驗，且減少不必要的流量消費，你說何樂而不為呢。

1.2 問題特征

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

場景一：用戶反饋在WIFI網(wǎng)絡(luò)下無法發(fā)起搜素，搜索結(jié)果異常。在WIFI環(huán)境下復(fù)現(xiàn)，無法復(fù)現(xiàn)用戶反饋的問題，這時往往會歸結(jié)為網(wǎng)絡(luò)不穩(wěn)定造成的。但用戶可能當時確實是遇到了問題，這種無法穩(wěn)定復(fù)現(xiàn)的問題，往往歸結(jié)為偶發(fā)性的問題。

場景二：用戶反饋離線下載的小說為什么有時候還需要網(wǎng)絡(luò)。由于用戶離線的小說是個連載的小說，當用戶閱讀完離線的內(nèi)容后，假設(shè)這時候小說有更新了，產(chǎn)品經(jīng)理為了讓用戶能夠連續(xù)的閱讀就將產(chǎn)品設(shè)計成聯(lián)網(wǎng)發(fā)送在線請求才能繼續(xù)閱讀，這和用戶的認知就比較相違背。但，如果用戶閱讀完已經(jīng)離線的部分，用戶看到書沒寫完，也會關(guān)心為何沒有新的內(nèi)容呢。類似的這種問題歸結(jié)為長尾問題，需要從產(chǎn)品策略上持續(xù)優(yōu)化來解決。

APP運行在用戶手機端，并且聯(lián)網(wǎng)到后端服務(wù)，許多質(zhì)量問題也有其自己的獨特性。因此，需要通過不同手段，來實現(xiàn)問題的發(fā)現(xiàn)、定位和修復(fù)。

1.3 面臨挑戰(zhàn)

對于上述提到的問題，大家可能會問：這些問題該如何發(fā)現(xiàn)，對于這些問題如何確定是否做馬上修復(fù)，哪些問題才算長尾問題？這就是下面將要介紹的線上問題的召回方式和問題影響面的評估。用戶反饋是召回問題的一種方式，但是這種被動的召回不足以滿足快速召回線上問題的要求，所以搭建一整套完善的監(jiān)控系統(tǒng)就非常必要了。

1.監(jiān)控的挑戰(zhàn)

對于客戶端產(chǎn)品，一旦發(fā)布出去就很難有效的控制產(chǎn)品的質(zhì)量。為此，產(chǎn)品經(jīng)理和數(shù)據(jù)分析師往往在產(chǎn)品發(fā)布前提出的監(jiān)控及統(tǒng)計需求，研發(fā)工程師開發(fā)設(shè)計用于監(jiān)控統(tǒng)計目的的代碼，將用戶的行為、產(chǎn)品的crash等核心質(zhì)量信息以日志的方式上傳到服務(wù)端，這些用戶所產(chǎn)生的數(shù)據(jù)就為后續(xù)分析產(chǎn)品及質(zhì)量問題提供了原始的數(shù)據(jù)依據(jù)。

2.影響面的判斷

利用客戶端上傳的用戶日志及客戶端崩潰信息，進行統(tǒng)計分析。結(jié)合線上問題，可進行影響面的評估。影響面評估主要有三類，包括嚴重問題，特定場景復(fù)現(xiàn)問題，不影響主要功能問題。

1) 嚴重問題一般是要發(fā)小版本來修復(fù)的問題

2) 特定場景復(fù)現(xiàn)問題一般不會發(fā)小版本修復(fù)，但一定會在下一個版本進行修復(fù)

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

2端質(zhì)量監(jiān)控方案

由于APP載體多種多樣，產(chǎn)品質(zhì)量問題表現(xiàn)形式有很多種。我們以最通用的APP為例，總結(jié)為以下幾種：

- 來自APP產(chǎn)品所依賴的后端服務(wù)的問題

- 來自APP產(chǎn)品自身的問題，包括穩(wěn)定性問題，表現(xiàn)為： 應(yīng)用crash（崩潰）、ANR（APPlication Not Responding）、網(wǎng)絡(luò)錯誤、請求響應(yīng)時間長、用戶交互不流暢、機型、ROM適配度不夠引起的兼容性問題。

- 來自APP和后端服務(wù)之間的鏈路問題，通 常有：網(wǎng)絡(luò)問題造成的丟包、TCP重傳等等。

對于APP質(zhì)量監(jiān)控，可以從三個方向去布局一套完善的監(jiān)控體系：問題發(fā)現(xiàn)、問題定位、問題止損。

2.1 問題發(fā)現(xiàn)

由于APP受用戶機型、手機ROM、網(wǎng)絡(luò)環(huán)境、用戶操作路徑差異的影響較大，QA無法保證在測試階段暴露所有問題，這就要求我們建立一套線上問題發(fā)現(xiàn)體系，及時召回已經(jīng)交付到線上的移動產(chǎn)品。一套完善的線上問題發(fā)現(xiàn)體系，通常來說需要根據(jù)產(chǎn)品的核心業(yè)務(wù)，抽象出核心指標，實現(xiàn)指標量化；制定質(zhì)量標準，提供實時監(jiān)控報警。

根據(jù)我們的經(jīng)驗，APP應(yīng)用的質(zhì)量指標包括但不局限于：安裝成功率，崩潰率，ANR比例，網(wǎng)絡(luò)錯誤比例，請求響應(yīng)時間等。質(zhì)量指標與具體的應(yīng)用功能緊密相關(guān)。理論上抽取指標后，如何量化是最關(guān)鍵也是最困難的一步。量化需要有效的問題信息獲取途徑，日志埋點是一種非常通用的方法，而另外一種途徑，用戶反饋， 雖然常常被開發(fā)者忽略，卻同樣重要。

2.1.1 用戶反饋：海納百川

一款應(yīng)用想要在應(yīng)用市場份額中分得一杯羹，長久地留住用戶，需要依賴良好的應(yīng)用功能和產(chǎn)品體驗。用戶反饋代表著市場對這款應(yīng)用的滿意度，能夠直接反映用戶的判斷和訴求，也是這款應(yīng)用迭代改進的第一手資料，前期我們可以通過市場調(diào)研等方式獲取反饋，但是受限于人力和時間成本，我們很難在用戶量巨大的時候復(fù)用此法，或者說市場調(diào)研始終只能采樣而無法全量覆蓋。

基于上述，只有提供一個入口，讓所有用戶的反饋可以如江河入海，匯于一處，我們才能獲取到來自不同地域、不同網(wǎng)絡(luò)、不同機型、不同場景下的用戶反饋，進而聚類、分析、改進我們的產(chǎn)品。

用戶反饋的通用方法并無太多新奇之處，市面上很多移動應(yīng)用都會在應(yīng)用設(shè)置頁面中附上一個用戶反饋的入口，如圖2.1中百度云和愛奇藝視頻的用戶反饋界面。

我們必須要明白一點，如今快節(jié)奏的生活中，用戶愿意提交一個反饋，那這個問題對他/她來說一定是一個很大的困擾，而且他/她又是一個比較忠實的用戶，同時對這款應(yīng)用抱有期待，希望開發(fā)者可以改進。所以一旦這個產(chǎn)品開始提供更穩(wěn)定或者功能更多的收費服務(wù)來嘗試變現(xiàn)，那么這部分用戶會是大的潛在群體。

一個普通的用戶反饋頁，卻是于細微處見真章的最好實例，這兩個頁面的設(shè)計告訴我們用戶反饋的重要原則：

• 反饋入口路徑盡可能短：上述的兩個反饋入口都在應(yīng)用的設(shè)備界面，進入反饋頁面需要2步操作。這一復(fù)雜度剛剛好，如果一個反饋需要用戶操作4、5步才能找到，那么用戶的熱情會被這種來自技術(shù)的傲慢消磨殆盡。

• 反饋內(nèi)容的提交成本盡可能低：左側(cè)圖片中愛奇藝的用戶反饋，不僅事先列出了用戶最可能遇到的幾種問題，還在頁面下方給出了常見問題的FAQ。不要小看了這一細節(jié)，我們可以通過這樣的方式，在無形之中完成一次用戶問題反饋+調(diào)查問卷。

• 對用戶的答復(fù)應(yīng)該盡可能的快：如果想要給用戶反饋的過程提供更實時的體驗，那就要求我們在用戶反饋頁面完成一個IM的功能，這對大多數(shù)處于創(chuàng)業(yè)階段的開發(fā)者來說并不現(xiàn)實，所以我們建議采用集成插件的方式來達到這一目的。

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

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

2)   Udesk：支持Android、IOS以及APIcloud三大平臺，可以對用戶反饋的數(shù)據(jù)做統(tǒng)計分析，并展示結(jié)果。

3)   Freshdesk，致力于中小企業(yè)網(wǎng)站在線客服技術(shù)支持的網(wǎng)站，提供中小企業(yè)網(wǎng)站的在線服務(wù)質(zhì)量和用戶體驗度。

除了在應(yīng)用中直接反饋，也可以創(chuàng)建用戶群（QQ，微信或其他企業(yè)級IM），針對嚴重問題可以第一時間發(fā)現(xiàn)，直接與用戶溝通，輔助復(fù)現(xiàn)、抓取問題現(xiàn)場信息等，這些對問題的定位和解決是至關(guān)重要的。

2.1.2 日志埋點：秣馬厲兵

在一個移動應(yīng)用設(shè)計之初，開發(fā)者通?？紤]的是功能、架構(gòu)、開發(fā)周期等問題，這一類問題通常直接影響應(yīng)用的發(fā)布周期，但是大家往往會忽略一個重要的過程，那就是日志埋點。

為何要埋點

通過用戶反饋發(fā)現(xiàn)問題畢竟有一定的延時，甚至有一些線上問題會阻塞用戶反饋，例如：連續(xù)頻繁的崩潰，用戶反饋模塊自身的Bug等。要想更迅速及時的暴露問題，需要我們主動出擊，獲取用戶操作的關(guān)鍵信息。

埋點于何處

日志埋點的原則：好的埋點可以達到一夫當關(guān)萬夫莫開的效果，將所有我們需要的信息通過日志的形式打印出來，選擇性或者全量的上傳給應(yīng)用的后端服務(wù)，用于支持問題發(fā)現(xiàn)或服務(wù)改進。

受限于APP應(yīng)用的運行環(huán)境，我們不可能在所有的地方進行埋點，筆者在多年的軟件開發(fā)維護過程中，也見過由于日志添加不當引起程序崩潰問題。

根據(jù)自身經(jīng)驗，我們總結(jié)出下列日志埋點的建議：

1）由目標驅(qū)動埋點：一個移動應(yīng)用，開發(fā)者或者用戶希望了解的服務(wù)指標，必須由日志埋點解決；

2）日志框架通用：應(yīng)用的第一個版本在日志框架上面花的時間，直接影響后續(xù)版本的開發(fā)效率。通用和穩(wěn)定是這個框架必須要考慮的問題。

3）日志上傳：對于已經(jīng)獲取的埋點日志，我們必須考慮它對用戶流量及交互流暢度方面的影響——畢竟它的上傳使用的是用戶網(wǎng)絡(luò)，尤其是在收費的移動網(wǎng)絡(luò)下更要慎重。有如下手段可參考：日志壓縮和私有協(xié)議、用抽樣上傳代替全量監(jiān)控；如果日志對時效性的要求不高，可以考慮采用打包整體上傳代替實時上傳的方式，甚至可以每天上傳一次。這些都需要在框架中提前做好部署工作。

4）日志安全：用戶日志中可能包含用戶個人信息、用戶行為及隱私，一旦信息泄露，可能給用戶造成經(jīng)濟、安全等方面的損失，嚴重影響用戶對應(yīng)用的信任。故日志安全是重中之重，目前行之有效的方法主要有加密和使用安全協(xié)議。相對于加密算法較容易被破解的風險，安全協(xié)議提供了更嚴密的保護。目前應(yīng)用比較廣泛的安全協(xié)議主要有https，spdy等。

2.問題定位

線上問題的快速定位和解決可以直接縮短用戶體驗受損的時間，通常有以下幾種定位思路：

1）日志分析法

當遇到一個問題時，我們最先想到的可能就是查看日志，用戶日志是定位問題的最直接的信息來源和方法。日志分析又可以分為兩種手段：一是從統(tǒng)計學(xué)的角度分析大 量的問題日志，總結(jié)聚類，通過其中共性的特征，發(fā)現(xiàn)潛在的問題；另一種是針對某個有明確問題反饋的用戶，查詢其一段時間內(nèi)的所有操作流程及結(jié)果，通過上下 文推測問題原因，也可以輔助線下復(fù)現(xiàn)。

當然并不是所有的問題都可以通過用戶日志定位，比如日志不全或日志提供的信息并不足以精確定位問題，怎么辦呢？那就要求我們能夠復(fù)現(xiàn)這一問題。

2）問題復(fù)現(xiàn)法

通過用戶對問題的現(xiàn)象描述，以及已有的用戶日志，嘗試線下復(fù)現(xiàn)。復(fù)現(xiàn)時需要關(guān)注用戶的機型，平臺，網(wǎng)絡(luò)類型，是否設(shè)置了代理，甚至是用戶所處的地理位置（不 同地域的運營商網(wǎng)絡(luò)可能有較大差異）等，結(jié)合應(yīng)用所提供服務(wù)的邏輯，推測可能出現(xiàn)該問題的原因，盡量增加復(fù)現(xiàn)的可能性。

3）推測驗證法

當然，APP的問題很大程度上依賴于當時的問題環(huán)境，包括機型，平臺，網(wǎng)絡(luò)情況，手機安裝的應(yīng)用等，都給線下復(fù)現(xiàn)帶來了巨大的困難。而現(xiàn)有的問題日志又不足 以精準定位。在這種情況下，可以通過問題的現(xiàn)象描述和以有的日志，推測可能的問題原因，埋點監(jiān)控，通過分級發(fā)布的模式，當問題再次發(fā)生時，驗證哪個推測是 root cause。

4）上下游合作分析

有些功能需要多方合作實現(xiàn)，當這些模塊出現(xiàn)問題時，大家通力合作，可能就會離問題的解決更近一步。

3.問題止損

線上問題時時刻刻影響著用戶體驗，及時止損很有必要。問題止損不僅僅是指定位到了問題的root cause從而實現(xiàn)徹底解決，也包括在問題徹底解決之前，如何將對用戶的不良影響降到最低。

對于APP產(chǎn)品，不能像后端服務(wù)那樣通過緊急下線/上線補丁解決問題，只能依賴于應(yīng)用發(fā)版，而用戶的升級轉(zhuǎn)化也是一個比較漫長的過程。在這種困境中，云端控制和熱修復(fù)為我們帶來了曙光。下面主要闡述云端開關(guān)控制的思路。

針對APP上影響/風險比較大的功能模塊，預(yù)先設(shè)置好開關(guān)，發(fā)生問題時，可以通過云端下發(fā)關(guān)閉指令，及時止損。云端控制是一個概念，實現(xiàn)方式因業(yè)務(wù)和功能而 異。受限于自身經(jīng)驗，我們無法提供通用的多平臺解決方案，但是大道至簡，我們希望提醒開發(fā)者的是：從代碼設(shè)計開始，考慮應(yīng)用、系統(tǒng)、服務(wù)三個維度的容災(zāi) 性。

一個簡單的例子：我們可以把功能開關(guān)置于一個獨立的Web Server中，APP采用輪詢或者更加精準的動態(tài)策略去訪問這個靜態(tài)文件，當服務(wù)某個環(huán)節(jié)出現(xiàn)問題時，只需要修改WebServer中的開關(guān)文件，關(guān)閉相關(guān)功能或者將相應(yīng)的服務(wù)導(dǎo)向備用地址，即可快速的止損。

另外一種方式和上述方案類似，只不過實現(xiàn)的時候不使用訪問云端文件，而是由服務(wù)端直接向所有APP應(yīng)用下發(fā)指令，用于啟停某些功能甚至調(diào)整某些內(nèi)部模塊的邏輯。這種方式更直接，但是對APP的代碼的開發(fā)提出了相當高的要求：

1）  模塊間代碼耦合度要極低，從而能夠做到動態(tài)調(diào)整邏輯；

2）  如果云端控制只用于事故止損，那么就要求所有受影響的應(yīng)用必須保持后臺在線或者前臺運行的狀態(tài)。不過具體到當前市場份額大的幾個手機/移動操作系統(tǒng)，我們可以通過推送通知的方式的，盡可能由用戶主動喚起應(yīng)用，借此來獲得下發(fā)云端命令的機會；

我們建議開發(fā)者可以綜合考慮應(yīng)用的代碼風格、業(yè)務(wù)類型、風險類型，來選擇某一止損的方案。上述兩種方案并非最優(yōu)解，實際的開發(fā)過程中可能需要綜合多種方案來達到高可用服務(wù)的標準。

同時，目前業(yè)界也涌現(xiàn)出一些成熟的解決方案，如iOS平臺的APP動態(tài)更新服務(wù)JSPatch(http://jspatch.com)就是一個專注于此領(lǐng)域的平臺，開發(fā)者可以試用、借鑒。

3監(jiān)控體系建設(shè)

3.1質(zhì)量標準

1.什么是質(zhì)量標準：

質(zhì)量標準是產(chǎn)品生產(chǎn)、檢驗和評定質(zhì)量的技術(shù)依據(jù)。產(chǎn)品質(zhì)量特性一般以定量表示，例如強度、硬度、化學(xué)成分等；所謂標準，指的是衡量某一事物或某項工作應(yīng)該達到的水平、尺度和必須遵守的規(guī)定。而規(guī)定產(chǎn)品質(zhì)量特性應(yīng)達到的技術(shù)要求，稱為“產(chǎn)品質(zhì)量標準”。--（百度百科）

客戶端作為與用戶直接與用戶打交道的產(chǎn)品，其用戶體驗是衡量一個客戶端的重要部分。用戶體驗包含了視覺、友好性、易用性等等方面。但是其視覺等方面很難通過量化的方式進行度量。但是產(chǎn)品的核心功能等卻是通過一些數(shù)據(jù)的度量來衡量產(chǎn)品的易用性等。因此，產(chǎn)品的質(zhì)量標準就應(yīng)運而生。

在服務(wù)類產(chǎn)品中，常用SLA（Service-Level Agreement）作為衡量產(chǎn)品服務(wù)等級的量化指標。按照業(yè)務(wù)的需求對業(yè)務(wù)的，對業(yè)務(wù)的服務(wù)指標制定量化的標準，通過量化的標準來衡量和驅(qū)動產(chǎn)品的服務(wù)越來越好。例如作為APP產(chǎn)品中的crash率，是衡量一個APP穩(wěn)定性的數(shù)據(jù)指標，通過對crash率的統(tǒng)計數(shù)據(jù)衡量分析，來保證每個發(fā)版的APP健壯性得到保障。

2. 質(zhì)量標準應(yīng)如何制定：

質(zhì)量標準的目的是通過對業(yè)務(wù)數(shù)據(jù)的量化與衡量來保證服務(wù)的質(zhì)量，通過質(zhì)量標準的衡量來推動業(yè)務(wù)質(zhì)量變得越來越好。那么應(yīng)該如何來制定質(zhì)量標準呢？

根據(jù)百度云的經(jīng)驗，質(zhì)量標準的建立大致總結(jié)為：一個核心、三個階段：

一個核心：時刻以產(chǎn)品線的業(yè)務(wù)發(fā)展為核心

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

為什么質(zhì)量標準的建立要圍繞發(fā)展來制定。舉個例子，比如百度錢包，錢包在初始階段，其核心的業(yè)務(wù)指標為發(fā)展用戶，那么用戶的登錄，日活等指標為錢包的最核心的指標，當時錢包還沒有APP端，顯然，更不會有Crash率等方面的標準。在錢包發(fā)展到一定階段，綁卡用戶變成了錢包的另一個核心指標。那么幫卡率變成了業(yè)務(wù)的核心發(fā)展指標。相應(yīng)的核心質(zhì)量標準也應(yīng)該變?yōu)榻壙ǔ晒β?。因此，質(zhì)量標準的制定一定要圍繞業(yè)務(wù)發(fā)展為核心。

在業(yè)務(wù)發(fā)展的不同階段所設(shè)定和采納的質(zhì)量標準也是不盡相同的，按照標準由粗到細，量化難度由易到難的階段一步一步發(fā)展而來的。

初期階段：業(yè)務(wù)發(fā)展的初期或者業(yè)務(wù)發(fā)展到一定的階段，通過需求或者用戶反饋來收集到產(chǎn)品線在發(fā)展過程中需要核心保證的top功能，這個核心的功能是一個產(chǎn)品生存的支柱，也就是我們需要通過質(zhì)量標準來衡量我們核心業(yè)務(wù)提供的服務(wù)好壞程度。舉個例子，客戶端的崩潰情況，是每個產(chǎn)品線所要保證的最基本的質(zhì)量防線，崩潰率的高低，決定了用戶的留存情況，因此，所有產(chǎn)品線都應(yīng)將崩潰率作為最基本質(zhì)量標準。而對于不同的產(chǎn)品線，則有各自自身的核心業(yè)務(wù)指標，比如手百，死鏈的情況則是關(guān)系到用戶體驗的最核心指標；下載的成功率是百度云用戶體驗的最核心指標；定位和路線的準確性是地圖最核心的用戶體驗指標。這些也就是各個產(chǎn)品在最初建立質(zhì)量標準時最關(guān)系的方向。

中期階段：中期階段，是在初期階段的質(zhì)量指標建立完之后，并且在指標的數(shù)據(jù)獲取，指標的計算公式都得到檢驗之后（尤其是得到peer角色的認可），進入到成熟階段。中期階段的目標是建立多個完整的子業(yè)務(wù)質(zhì)量閉環(huán)。客戶端的呈現(xiàn)在用戶面前的服務(wù)能力和用戶體驗，是每個業(yè)務(wù)的綜合能力體驗，對于客戶端自身的業(yè)務(wù)、服務(wù)端的服務(wù)能力、中間網(wǎng)絡(luò)抖動情況都密不可分。因此，想要達到一個服務(wù)單元的完整質(zhì)量閉環(huán)，必須能cover到整個業(yè)務(wù)鏈條中的每個質(zhì)量節(jié)點。比如百度云的下載業(yè)務(wù)，一個完整的下載，從層級上面看，大致分為三個層級：1.APP自身下載邏輯，主要涉及到下載的重試、并發(fā)、容錯等 2. 中間業(yè)務(wù)層， 主要是在下載過程中的下載分發(fā)、防盜鏈、PASS校驗、CDN回源等等。3. 底層數(shù)據(jù)拉取，主要是分片數(shù)據(jù)的重組文件、跨機房的文件拉取等等。所以要完成一個整個下載的質(zhì)量閉環(huán)，必須cover整個質(zhì)量閉環(huán)的關(guān)鍵節(jié)點， 每個關(guān)鍵節(jié)點都會指定相應(yīng)節(jié)點的標準，每個節(jié)點的質(zhì)量好壞的變化，都會在端的質(zhì)量數(shù)據(jù)中有所體現(xiàn)。

進階階段：進階階段是在中期階段相對成熟之后，針對于業(yè)務(wù)復(fù)雜的每個子業(yè)務(wù)都能通過服務(wù)單元中的核心節(jié)點數(shù)據(jù)來對質(zhì)量做出評價。進階階段，對于每個細節(jié)的標準都很全面。任何影響到產(chǎn)品體驗，和客戶端的運行質(zhì)量的，都能通過數(shù)據(jù)分析得到。在中期階段，有了各個垂類業(yè)務(wù)的數(shù)據(jù)，以及在垂類的鏈條上面的關(guān)鍵節(jié)點的數(shù)據(jù)，能夠清晰的知道垂類業(yè)務(wù)的質(zhì)量。對于比較復(fù)雜的業(yè)務(wù)，其每個質(zhì)量節(jié)點影響的不單單是一個垂類的業(yè)務(wù)。在進階階段，通過對詳細子業(yè)務(wù)以及子業(yè)務(wù)之間的關(guān)系進行聯(lián)系與刻畫，形成了一張聯(lián)動的質(zhì)聯(lián)網(wǎng)。

3.質(zhì)量標準的用處：

質(zhì)量標準的設(shè)定主要的目的是通過質(zhì)量標準的驅(qū)動來驅(qū)使業(yè)務(wù)質(zhì)量變好。質(zhì)量標準按照覆蓋范圍來分主要分為兩大類：一是通用型，比如 crash率；二是與自身業(yè)務(wù)緊密相關(guān)的。

1)   質(zhì)量標準最初級的用處：衡量業(yè)務(wù)的好與壞。通過量化的手段，對于業(yè)務(wù)的服務(wù)，APP的運營質(zhì)量，進行度量。

2)   發(fā)現(xiàn)業(yè)務(wù)中的缺陷：通過對服務(wù)單元中的質(zhì)量數(shù)據(jù)度量，發(fā)現(xiàn)業(yè)務(wù)質(zhì)量中的薄弱環(huán)節(jié)，對于問題的發(fā)現(xiàn)和業(yè)務(wù)的優(yōu)化提供數(shù)據(jù)支撐。

3)   業(yè)務(wù)貢獻：通過對質(zhì)量數(shù)據(jù)的分析與整合，對于產(chǎn)品策略提供數(shù)據(jù)支撐和評判。

3.2能力指標

1. 數(shù)據(jù)獲取的能力：

基礎(chǔ)數(shù)據(jù)是質(zhì)量標準建立的基石，數(shù)據(jù)獲取是一個產(chǎn)品線成熟度的一個標識。一般APP的數(shù)據(jù)獲取途徑主要有兩大類：1. 通用第三方統(tǒng)計平臺：例如mtj以及一些第三方的數(shù)據(jù)統(tǒng)計平臺，通過提供SDK的方式，對APP的運行狀態(tài)等指標進行統(tǒng)計上報，并給出圖形化的分析報告。2. 自身業(yè)務(wù)的數(shù)據(jù)上報：通過業(yè)務(wù)埋點或者自己編寫的SDK捕捉上報。針對自身埋點或者自己編寫SDK的方式，更加靈活。但是需要投入相應(yīng)的人力和機器資源。

2. 數(shù)據(jù)分析的能力：

在數(shù)據(jù)獲取的基礎(chǔ)之上，數(shù)據(jù)分析是數(shù)據(jù)轉(zhuǎn)化成質(zhì)量數(shù)據(jù)、質(zhì)量標準的必經(jīng)之路。數(shù)據(jù)分析的過程，是離散的業(yè)務(wù)數(shù)據(jù)，通過按照對業(yè)務(wù)梳理的方面進行劃分、統(tǒng)計聚合，變?yōu)閷I(yè)務(wù)有用的數(shù)據(jù)。業(yè)務(wù)數(shù)據(jù)的分析的能力集中體現(xiàn)在兩個方面：1. 數(shù)據(jù)計算能力，對于離散數(shù)據(jù)的計算，需要大量的數(shù)據(jù)計算才能完成，一套高效、運行流暢的計算框架是對于大數(shù)據(jù)計算的前提。2. 業(yè)務(wù)梳理能力，需要對業(yè)務(wù)的理解和上下游串聯(lián)有比較細粒度的認識。3. 業(yè)務(wù)數(shù)據(jù)分析的能力，對于統(tǒng)計后的數(shù)據(jù)，能夠?qū)?yīng)到業(yè)務(wù)的表現(xiàn)，并能通過數(shù)據(jù)的變化來預(yù)測或者對于平臺業(yè)務(wù)的好壞。

3. 質(zhì)量數(shù)據(jù)的閉環(huán)：

質(zhì)量數(shù)據(jù)的閉環(huán)是一個比較長期的過程，通過對數(shù)據(jù)的獲取、數(shù)據(jù)的分析后，得出業(yè)務(wù)中不合理或者比較薄弱的地方，通過制定合理的優(yōu)化方案，對業(yè)務(wù)進行調(diào)整優(yōu)化。然后循環(huán)往復(fù)來達到質(zhì)量數(shù)據(jù)的閉環(huán)。

3.3數(shù)據(jù)利用

數(shù)據(jù)分析，是整個監(jiān)控的最核心，也是難度大的工作。數(shù)據(jù)分析，是結(jié)合業(yè)務(wù)的邏輯，通過基礎(chǔ)數(shù)據(jù)進行計算統(tǒng)計后，分析對應(yīng)到業(yè)務(wù)邏輯。通過數(shù)據(jù)的變化，來解釋業(yè)務(wù)的變化與好壞程度。

數(shù)據(jù)可視化，是數(shù)據(jù)監(jiān)控的一個效果展示。好數(shù)據(jù)展示，能保證用戶更好的分析數(shù)據(jù)的變化與數(shù)據(jù)直接的內(nèi)在聯(lián)系。數(shù)據(jù)的可視化的重要程度也是不言而喻，其像發(fā)動機的潤滑油，能夠讓整個監(jiān)控體系，更高效，更加順暢的運轉(zhuǎn)起來。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

名稱欄目：如何建立起一套有效的APP監(jiān)控體系-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://muchs.cn/article6/cdchog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、標簽優(yōu)化、響應(yīng)式網(wǎng)站、定制開發(fā)、外貿(mào)建站、App設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)