手機(jī)淘寶：億級用戶APP的快速運(yùn)維交付實(shí)踐
作者簡介：
倪生華
淘寶網(wǎng) 資深技術(shù)專家
花名玄黎，12年加入淘寶無線事業(yè)部，經(jīng)歷了手淘從幾十萬日活到現(xiàn)在億級日活的過程，一直負(fù)責(zé)手淘端研發(fā)運(yùn)維等工程效率相關(guān)的工作，團(tuán)隊(duì)負(fù)責(zé)開發(fā)的支撐體系，很好的解決目前手淘目前快速迭代和大團(tuán)隊(duì)協(xié)作的問題，主導(dǎo)發(fā)起了客戶端側(cè)的技術(shù)監(jiān)控、動態(tài)修復(fù)等體系。
一、前言
我個人比較關(guān)注于整個工程效率以及質(zhì)量、性能、穩(wěn)定性這一塊。移動客戶端運(yùn)維這塊，從一開始就沒有專職運(yùn)維工程師做，一直是研發(fā)工程師自己在做，所以我有時候也會關(guān)注一些所謂的移動化運(yùn)維的事情，本文將圍繞手淘 APP 的運(yùn)維交付實(shí)踐進(jìn)行介紹。
二、我們面對的挑戰(zhàn)
如果大家用過客戶端或者有團(tuán)隊(duì)做 APP 開發(fā)的話，應(yīng)該經(jīng)常會被老板問到這個問題，突然有用戶反饋說為什么我手機(jī)突然圖片打不開了，或者視頻打不開了，或者為什么老是網(wǎng)絡(luò)錯誤，甚至可能老板突然跟你說，為什么我用著用著突然發(fā)現(xiàn)不行了。
你聽到這個信息的時候，基本上會一頭懵逼。因?yàn)檫@些情況會有很多種場景，有可能用戶只在山東或者北京的某個區(qū)域出現(xiàn)，在我們的測試環(huán)境，根本沒法重現(xiàn)。
傳統(tǒng)運(yùn)維中，我們運(yùn)維的對象都是機(jī)房的服務(wù)器、PC機(jī)，到了客戶端這一塊，你運(yùn)維的就是一個個獨(dú)立的手機(jī)，問題的根源可能是某幾個用戶的反饋或者十幾個用戶的反饋。
因?yàn)檫@種運(yùn)維對象的轉(zhuǎn)變，整個運(yùn)維的重點(diǎn)從原先的集群資源管控變成了更多是監(jiān)控、排查、分析以及快速修復(fù)的能力。
三、我們的運(yùn)維場景
手機(jī)淘寶從2013年開始，整個團(tuán)隊(duì)快速發(fā)展，2013年開始整個手機(jī)淘寶每年會發(fā)版40多次，大概一個月或者半個月會發(fā)版一次。
到2014年的時候，整個阿里集團(tuán)進(jìn)行了 All-In，團(tuán)隊(duì)從之前的六七十人，突然擴(kuò)張到兩百多人，最多的時候到四百多人，整個發(fā)布突然從42次到200次。
到2015年開始，我們在思考今天有這么多人，我們怎么快速交付給用戶一個非常好體驗(yàn)的 APP ？所以我們采取了一些措施，發(fā)布的策略從2014年的200多次變成500多次。
500多次什么概念？基本上我們每天都在給用戶推送帶用新的功能、新的版本的 APP 。到2016年9月份，發(fā)版466次，基本上一天會給用戶推送1.7個版本。
目前整個手機(jī)淘寶，光手機(jī)淘寶部門大概會有400多個工程師，除了手機(jī)淘寶之外，整個阿里系還會有20多個BU同時在為手機(jī)淘寶貢獻(xiàn)代碼。
我們在這么快的節(jié)奏、這么多人的情況下，目前我們的崩潰率基本上在萬分之五，從接到用戶反饋到整個問題的定位、修復(fù)，基本上是小時范圍內(nèi)，把整個問題全部解決掉。
四、重壓下的交付體系
我們經(jīng)常講傳統(tǒng)的運(yùn)維，等到開發(fā)工程師把所謂的機(jī)器部署上之后，真正上線了，運(yùn)維工程師才開始接，我們只管我們的機(jī)器、機(jī)房、容器。
在整個客戶端這塊，我們內(nèi)部有句話：“在你測試完成開始，你的運(yùn)維工作就開始了”。測試完成之后，這就是一個最終的交付產(chǎn)物。
我們研發(fā)工程師會搞定所有的事情，主要核心的內(nèi)容是快速交付，包括 APP 的研發(fā)，交付測試，灰度驗(yàn)證、問題修復(fù)。我們認(rèn)為在整個移動端來說，運(yùn)維重點(diǎn)關(guān)注是這兩個環(huán)節(jié)。
灰度環(huán)節(jié)
因?yàn)橐苿佣似鋵?shí)跟 PC 端還不太一樣，PC 端很多東西都可控，在服務(wù)器里面發(fā)現(xiàn)問題了隨時可以下掉。
但如果說今天你的 APP 用戶大規(guī)模安裝之后出現(xiàn)了問題，基本上是非常嚴(yán)重的問題，需要等到用戶全部重新安裝一遍，可能這個時間是7天或者14天。
在整個移動端來講，多快能夠灰度出一個 APP ，得到反饋驗(yàn)證，是一個非常重要的能力。
發(fā)現(xiàn)問題解決問題環(huán)節(jié)
另一個是發(fā)現(xiàn)問題解決問題的環(huán)節(jié)，今天你灰度出去了，你怎么快速發(fā)現(xiàn)問題？這些問題的原因是什么？怎么快速定位解決這個問題的能力？
可能以前在服務(wù)器端，所有東西在你自己的機(jī)房里，發(fā)現(xiàn)問題你自己上去看一下日志或者查一下監(jiān)控就可以。
現(xiàn)在的挑戰(zhàn)是，你所有的機(jī)器都在用戶的手機(jī)上，用戶機(jī)器的差別、網(wǎng)絡(luò)的差別、手機(jī)上硬件的差別等，這方方面面的不一樣帶來了非常多的多樣性，怎么樣把這些個體的情況都能發(fā)現(xiàn)？
在這兩個環(huán)節(jié)里，也有我們非常注重的幾個能力。
灰度能力
怎么樣快速把我們的問題、我們新的包或新的改動，能夠快速交付到用戶上面去，能夠通過用戶的使用快速發(fā)現(xiàn)我們的問題，能夠加快我們的迭代速度。
監(jiān)控能力
灰度完之后需要一個監(jiān)控體系，我們需要快速拿到我們所有的想要的東西，包括功能上、性能上甚至穩(wěn)定性上的。所以整個監(jiān)控體系的搭建是非常有必要的。
Trace能力
發(fā)現(xiàn)了問題，我怎么能夠快速知道原因，到底是因?yàn)榫W(wǎng)絡(luò)的問題還是因?yàn)槲覀兂绦虻膯栴}甚至因?yàn)槠渌麊栴}，整個 Trace 體系也是非常重要的一塊問題。
恢復(fù)機(jī)制
你發(fā)現(xiàn)問題了，要去修復(fù)，這可能不像服務(wù)端，今天把機(jī)器下掉就可以了，有可能你的 APP 已經(jīng)放到用戶手上去了，你怎么快速把它修復(fù)？
五、 APP的灰度體系建設(shè)
我們來看看整個 APP 的灰度體系是怎么建立起來的。
快速產(chǎn)出灰度包
一個好的灰度 APP 首先第一件事情是我們需要快速產(chǎn)出我們的灰度包，我們希望我們今天的灰度包變更能夠盡量少，或者我今天發(fā)現(xiàn)問題以后，能夠快速重新再出來一個灰度包去驗(yàn)證。
快速分發(fā)灰度包
今天灰度我包有了，我怎么樣快速分發(fā)給用戶。傳統(tǒng)意義上的灰度像我們前幾年，找一個20萬用戶的群體，發(fā)個消息給用戶，讓用戶裝一下，這在整個互聯(lián)網(wǎng)公司是非常低效的。
怎么在幾十分鐘或者半個小時之內(nèi)快速把整個改動包推送到用戶端，甚至讓用戶是可以控制的。
快速度量灰度包
今天我的灰度包出去了，今天我們灰度上面的效果數(shù)據(jù)的評估，我們應(yīng)該怎么來做？
快速回滾灰度包
這一塊是說如果技術(shù)條件允許的情況下，希望我們的灰度包能夠做一些回滾的機(jī)制，這個在安卓上是完全可以做到的，今天用戶推送灰度包之后發(fā)現(xiàn)不行，我可以對用戶進(jìn)行回滾，可能用戶完全沒有感知。
整體來講，整個灰度體系的搭建我們通過三個手段來做
通過推拉結(jié)合的升級方式，這一塊的做法，我們希望整個灰度的包能夠快速的到達(dá)用戶，希望用戶說他今天可能在30分鐘之內(nèi)我們快速到達(dá)用戶。
我們希望精確的用戶量控制，我們可能一開始希望用戶是10個，到100個，到1000個，到10000個。
希望灰度對象可靈活地選擇。這個就要求今天我們的灰度接口里面，需要天然的放一些因子上去，在服務(wù)單中我們會對這些因子進(jìn)行篩選，在整個服務(wù)端挑選出來一些符合我們條件的用戶。
六、灰度操作控制臺實(shí)例
這個其實(shí)是在我們整個內(nèi)部所謂的灰度常見的控制臺操作，我們會對整個灰度進(jìn)行批次操作。
當(dāng)一開始灰度的時候只灰度2000或者2萬個用戶，在上面可以實(shí)時看到當(dāng)天升級的用戶數(shù)，包括我們當(dāng)前的整個UV，這些灰度用戶的用戶反饋、輿情反饋數(shù)，我們希望在整個操作人員能夠?qū)崟r看到當(dāng)前這批灰度用戶的影響。
如果覺得沒有問題，一開始可能推2萬，2萬發(fā)現(xiàn)沒問題，再推10萬，發(fā)現(xiàn)10萬沒問題，再推30萬，依次往上加。這樣它的灰度操作就可能很簡單，也可能不需要專業(yè)的技術(shù)人員做這件事情。
我們把整個所謂的灰度的粉線控制做得非常小。
通過人的批次上來控制，風(fēng)險(xiǎn)是依次累加的過程，2萬個用戶沒問題才會推送到5萬個用戶，5萬個用戶沒問題才會推送到100萬個用戶。
我們把所有可能直接影響用戶的反饋信息，他的數(shù)據(jù)信息在整個平臺上做了一一的展現(xiàn)，甚至在我們整個系統(tǒng)上我們會有個閾值，如果灰度突然暴漲，平臺自動會把整個灰度給終止掉。
這樣做的好處是，今天我們把整個灰度能力放開給所有人，所有的開發(fā)工程師、測試工程師大家都可以做這個事情。
今天的手機(jī)淘寶，我們基本上10分鐘就可以灰度到30萬用戶，全天24小時任何時候，你只要推送一個灰度上去，10分鐘時間可以達(dá)到我們想要的用戶數(shù)。在30分鐘之內(nèi)，我們就可以評估到我們的性能、穩(wěn)定性、功能上是不是OK。
七、度量&監(jiān)控體系的建設(shè)
我們通過灰度把包放出去后，我們怎么知道這個包好不好用？其實(shí)我們有一套監(jiān)控體系，在手機(jī)端監(jiān)控的面會分為四個方面。
穩(wěn)定性
APP 這個端最關(guān)注的就是穩(wěn)定性，我們會實(shí)時關(guān)注用戶的包括 Crash、ANR、主線程卡頓甚至于耗電這些數(shù)據(jù)。
性能體驗(yàn)
因?yàn)榭赡茉谡麄€ APP 端，你的功能好用，但是如果非常耗電、非?？ǎ鋵?shí)對整個產(chǎn)品的數(shù)據(jù)是非常有影響的。
所以希望能夠灰度出去的數(shù)據(jù)，我們能夠?qū)崟r看到性能數(shù)據(jù)。其中最關(guān)心的包括我們的啟動時間、頁面響應(yīng)時間、流暢度的數(shù)據(jù)。
核心指標(biāo)
比如頁面點(diǎn)擊轉(zhuǎn)化率、用戶的停留時間。
用戶輿情
我們在灰度上面可能會做一些特殊的事情，我們會把我們灰度的用戶反饋的標(biāo)在所有頁面進(jìn)行（透出），灰度可能在任何地方，用著用著就出現(xiàn)一個灰度的反饋。我們可能原來只有10個用戶的灰度量，但是它的整個反饋量可以達(dá)到現(xiàn)網(wǎng)上幾千萬用戶的反饋量，可以快速幫助我們得到非常多的信息。
八、評估標(biāo)準(zhǔn)的制定
穩(wěn)定性指標(biāo)大家可能做 APP 的都會比較了解，今天我們關(guān)注的是哪些點(diǎn)？
Crash 率，今天有多少用戶是閃退的；
主線程卡頓，我們通過 SDK 的方式能實(shí)時獲取到；
ANR 數(shù)據(jù)，上圖可看到有兩條線，我們會拿我們的灰度版本跟我們線上的版本進(jìn)行對比；
發(fā)現(xiàn)這個版本的數(shù)據(jù)有沒有變差或者有差異性，這個會作為我們發(fā)布之前非常重要的一個指標(biāo)，我們會來判斷今天整個穩(wěn)定性上有沒有因?yàn)槟愕母膭訉?dǎo)致我們 APP 變差。
九、性能監(jiān)控體系實(shí)例
上圖是一個性能監(jiān)控的截圖，大家知道在整個移動端或者說在服務(wù)端，做性能很簡單，去壓測一下。但現(xiàn)在很多人說服務(wù)端環(huán)境可能跟線上環(huán)境不一樣，客戶端來說這個東西更加不可信，所謂的網(wǎng)絡(luò)的差異，機(jī)型的差異，帶來的整個性能差異是非常大的。
在我們灰度完之后，我們會實(shí)時產(chǎn)出一份所有頁面的整個性能數(shù)據(jù)，包括網(wǎng)絡(luò)端甚至于各個端的性能的分布圖，做監(jiān)控?cái)?shù)據(jù)都知道，這個平均值是非常容易欺騙人的，我們可能除了關(guān)注整個平均值之外，我們會更加關(guān)注長尾用戶的情況。
因?yàn)檫@套機(jī)制，我們發(fā)現(xiàn)對整個階段會進(jìn)行區(qū)分，在測試階段，更多的做卡口，拿一個標(biāo)準(zhǔn)的路徑，比如大家同時是 Wifi 下面，只要你不超過一定的范圍，沒有做一些非常嚴(yán)重的（殺退），我們允許你灰度出去。
通過灰度出去，我們會做一些大規(guī)模的機(jī)型網(wǎng)絡(luò)情況的驗(yàn)證。對于一些復(fù)雜情況，如果說一些非常異常的機(jī)型，這里會有分布圖，我們會把我們的異常機(jī)型拿出來看一下，是不是對這個機(jī)型是一些普遍的現(xiàn)象。
這樣通過我們灰度的機(jī)制加我們實(shí)時的反饋機(jī)制，可以在30分鐘之內(nèi)或者1個小時之內(nèi)，可以拿到之前可能需要一天兩天在實(shí)驗(yàn)室里面拿出來的數(shù)據(jù)，可能還不一定完整。
最后一點(diǎn)，技術(shù)的數(shù)據(jù)都是非?？陀^或者冰冷的數(shù)據(jù)，有時候我們還需要能夠看到今天整個用戶對整個產(chǎn)品的體驗(yàn)是怎么樣的。
十、用戶反饋體系實(shí)例
剛才講到我們會在整個 APP 端進(jìn)行很多的埋點(diǎn)的反饋布局，在用戶操作一段時間之后，我們就會彈出來說今天你是不是要反饋一下，在整個后臺上會實(shí)時打通我們所有的用戶反饋體系。
在這個反饋體系里會把用戶當(dāng)時所處的各種環(huán)境全部打下來，我們會把用戶在輿情市場、新浪微博甚至在客戶端反饋的所有輿情數(shù)據(jù)都能夠?qū)崟r抓取下來。
通過一些關(guān)鍵字的聚合，通過標(biāo)簽的分類，甚至通過一些語義的分析，自動能夠產(chǎn)生各種類別，我們會把這些類別的信息自動推送給各個產(chǎn)品線的開發(fā)負(fù)責(zé)人、測試負(fù)責(zé)人甚至于產(chǎn)品負(fù)責(zé)人。
通過反饋的布點(diǎn)、自動化的語義分析以及報(bào)警，可以讓所有的研發(fā)工程師、產(chǎn)品負(fù)責(zé)人，他在灰度完之后，半天時間之內(nèi)能夠快速觀察他的產(chǎn)品對用戶的體驗(yàn)的情況。
十一、遠(yuǎn)程日志體系的建設(shè)
剛才我們講了很多今天我灰度出去之后突然來了一些數(shù)據(jù)，這些數(shù)據(jù)發(fā)現(xiàn)很多問題。
但是監(jiān)控只是第一步，我發(fā)現(xiàn)問題說 APP 很卡，但很多時候不知道用戶到底什么原因卡？肯定希望今天有個手段能夠更加精確定位到用戶到底什么原因卡。
在我們內(nèi)部會有很多手段，簡單講兩個手段。
1. 遠(yuǎn)程日志體系
我們會有一個遠(yuǎn)程日志體系，日志這一塊大家在服務(wù)端可能都非常了解，所謂的日志，所謂的服務(wù)端的報(bào)警都是基于日志來做的，客戶端日志大家可能很多沒有感受過，因?yàn)榭蛻舳硕际窃谑謾C(jī)上面，我們不可能讓用戶實(shí)時把整個日志傳輸上來。
在客戶端上面我們自己做了一套高性能壓縮的遠(yuǎn)程日志的方案，這個日志做什么事情，我們會在 APP 端對一些常見的操作，比如主要是做用戶的網(wǎng)絡(luò)流水、當(dāng)時用戶的網(wǎng)絡(luò)情況甚至一些自己寫的自定義協(xié)議的網(wǎng)絡(luò)的調(diào)試信息。
這些日志我們會經(jīng)過嚴(yán)格的加密以及壓縮，在用戶手機(jī)端上可能每天會有一個循環(huán)的日志產(chǎn)生，它可以存儲下來一個用戶在手機(jī)上操作的所有的日志情況。
不知道剛才大家看到整個用戶反饋的時候有沒有看到標(biāo)紅的東西，這里有所謂的 log 信息，在用戶反饋的信息，比如他反饋打不開，我們自然會把這些日志信息全部帶上來。
用個案例來講，我們怎么利用這些日志快速定位到用戶的問題，通過用戶把這些日志循環(huán)的存儲在整個手機(jī)端上，我們會有一種機(jī)制把這些日志存上來。
剛才大家看到今天反饋的同時自動帶上來，我們稱之為主動的方式，還有個被動的方式，我們會對用戶推送上傳信息，會把他的日志通過一個加密的通道上傳到我們服務(wù)器端，通過自定義的方式展現(xiàn)出來。
這個基本上我們來做的是功能級別的定位，除了功能的問題之外還會有些性能的問題，性能問題可能會更復(fù)雜，因?yàn)槟愎饪匆粋€日志，你只能知道說這個功能是不是 OK，性能我可能需要得到信息會更多。
2. 遠(yuǎn)程性能 Trace 體系
所以在手機(jī)端上我們會簡單實(shí)現(xiàn)一套所謂遠(yuǎn)程性能的Trace，大家如果做過性能測試，這個東西是開發(fā)工程師、運(yùn)維工程師經(jīng)常用的手段。
我們在客戶端上怎么來做，我們可能自己在整個設(shè)備商會實(shí)現(xiàn)一套我們自定義的三波 Trace，但是這個 Trace 我們會基于整個客戶端的插件機(jī)制，可能動態(tài)的下發(fā)給用戶。
比如我們基于剛才看到的會有一個性能的日志情況，我們會抓取你最慢的幾臺機(jī)器，中間找一些用戶，對這些用戶我們內(nèi)部稱之為負(fù)面樣本，就是它性能異常的設(shè)備。
對這些設(shè)備我們會下發(fā)一個 Trace Bundle，用戶拿到這個 Trace Bundle 之后，我們會在用戶手機(jī)上面開啟三波 Trace，這三波Trace可能會對整個用戶的性能會有10%的損耗。
采集完一次之后，Bundle 會自動把它下掉，會自動上傳一個 Trace 信息到遠(yuǎn)程服務(wù)器上，我們會通過一個簡單的遠(yuǎn)程 Trace，定位到今天他跟我們實(shí)驗(yàn)室的差別是什么，到底是哪個線程比較慢，是因?yàn)檎麄€用戶機(jī)器的問題還是說某種場景在我們開發(fā)環(huán)境、測試環(huán)境沒有想到。
十二、主動日志上報(bào)體系
今天我們有這么多手段，除了今天我動態(tài)去拉之外，我們還希望有一些東西更加高效，我們其實(shí)會也一個上傳的機(jī)制的體系設(shè)計(jì)。
用戶進(jìn)行輿情反饋時上報(bào)
比如說用戶在進(jìn)行輿情反饋的時候，比如說打不開，為什么圖片打不開，會自動觸發(fā)我們的 Trace 抓取日志，我們會在遠(yuǎn)端配取一個自動抓取的關(guān)鍵詞庫，我們發(fā)現(xiàn)只要用戶的反饋上面馬上命中了我們這個關(guān)鍵詞，會自動啟動剛才所說的 Trace 體系，把用戶所謂的日志體系隨他的反饋同時帶上來。
業(yè)務(wù)發(fā)生主動觸發(fā)上報(bào)
我們現(xiàn)場經(jīng)常會碰到一些問題，他打電話給客服說今天我這個東西下不了了，客服會要求說你上報(bào)一下信息過來。
系統(tǒng)發(fā)生Crash時上報(bào)
整個系統(tǒng)發(fā)生 Crash，或者說監(jiān)控指標(biāo)，大家都知道整個監(jiān)控是基于大數(shù)據(jù)來做的。
但大數(shù)據(jù)只能告訴我們一個概要，我們還需要能看到更加細(xì)的東西，所以我們在內(nèi)部會有一套機(jī)制，比如大數(shù)據(jù)上面我們會有個閾值，觸達(dá)10%的用戶，會在這10%的機(jī)器上去抽樣，自動下發(fā) Trace 信息過去，對這些信息自動上報(bào)我們的 Trace 信息過來。
十三、問題定位案例分析
簡單講幾個案例，這幾個案例可能是我們今年雙十一之前經(jīng)常碰到的一個問題，這個案例是雙十一之前一個非常常見的問題，我們在整個灰度的過程中，突然發(fā)現(xiàn)用戶反饋是說為什么我的評論我的圖片不能展示，我不能評論了。
那個時候我們來看整個服務(wù)端、整個客戶端都 ok，沒有任何問題，我們就對整個用戶下發(fā)了 Trace，右邊可能是說今天 Trace 幾分鐘之后，用戶當(dāng)時的整個網(wǎng)絡(luò)日志、網(wǎng)絡(luò)情況，全部都要上報(bào)到整個服務(wù)器上。
右邊是經(jīng)過我們解密過之后的整個服務(wù)器的流水信息，大家發(fā)現(xiàn)他去訪問的一個 CDN 節(jié)點(diǎn)好像是有些問題，后來在這個日志去看，他訪問了 UIO，報(bào)了一個404，我們拿過去一看，可能 CDN 節(jié)點(diǎn)有上千臺甚至上萬臺機(jī)器，其中有一臺機(jī)器有問題。
我們馬上找到這個 CDN 節(jié)點(diǎn)，我們把它下掉。這個在以前的情況下，有些 CDN 節(jié)點(diǎn)可能監(jiān)控上發(fā)現(xiàn)的沒那么細(xì)，因?yàn)樗麄€百分比可能只有0.001%，但是得用戶來講，這個節(jié)點(diǎn)服務(wù)幾十萬用戶，完全不能起作用了。
我們通過這個手段解決了很多之前所謂的 CDN 節(jié)點(diǎn)、網(wǎng)絡(luò)節(jié)點(diǎn)上面的一些非常個例的問題。
這些東西其實(shí)對整個用戶輿情是非常嚴(yán)重的，大家知道客戶端上會有很不好的現(xiàn)象，用戶如果用得好他不會來反饋，他用得差的時候，他會在所有的用戶輿情、微博上進(jìn)行產(chǎn)波，如果一不小心剛好一個大V碰到了，可能會引起公關(guān)事件。
通過這種手段你可以快速定位到一些大家之前認(rèn)為基本上不可能會出現(xiàn)的小白問題。
十四、性能問題案例分析
我們在雙十一之前發(fā)了一個版本，我們突然發(fā)現(xiàn)某一個版本整個啟動時間下降了2秒以內(nèi)，但在實(shí)驗(yàn)室里怎么都發(fā)現(xiàn)不了。
這個時候做了一件事情，基于剛才的性能數(shù)據(jù)，我們對10%的數(shù)據(jù)下發(fā)了 Trace 異常數(shù)據(jù)，線上的正常用戶我們也會拉一份 Trace 出來，異常用戶也會拉一份 Trace 出來。
我們做了對比，左邊是大家非常常見的火焰圖的概念，我們把兩份 Trace 進(jìn)行了時間序列的拉平擬合之后，把這兩份 Trace 做了一次擬合。紅色的是兩份 Trace，異常的樣本 Trace 跟正常 Trace 差異超過10 毫秒以上，我們會對它進(jìn)行標(biāo)紅。
看這個圖就可以看出來，今天啟動的時候，慢的那幾個用戶，他在某些 Trace 方法里多了很多。同時我們會對整個 Trace 的方法堆棧進(jìn)行歸類歸總，因?yàn)樗械姆椒ǘ褩Ｔ谖覀儍?nèi)部都可以看出來是哪個模塊發(fā)出來的。
對比之后大家會發(fā)現(xiàn)，正常的一個應(yīng)用上發(fā)現(xiàn)某幾個模塊沒有調(diào)用，但是在異常模塊上多了這個調(diào)用，而且整個數(shù)量非常多，整個次數(shù)非常溫和，一看時間剛好和異常時間是比較吻合的，原來是在某些場景下會觸發(fā)一個我們之前從沒有想過的流程，這個流程可能現(xiàn)在在線上概率還是比較高的。
知道原因之后，把這個問題解決掉就 ok 了。
十五、整體回顧
灰度也好，監(jiān)控也好，Trace 也好，我們內(nèi)部分類，其實(shí)整個東西可以分為好幾塊。
首先，我們在客戶端上面可以有很多 SDK，比如性能、Crash、輿情、動態(tài)修復(fù)等。
這些東西其實(shí)是一些 SDK 的產(chǎn)品，通過這些 SDK 預(yù)埋在客戶端這邊，在我們服務(wù)端，我們會有客戶端數(shù)據(jù)實(shí)時的監(jiān)控，實(shí)時處理，實(shí)時分析，包括大家看到的性能評估、Crash 展示、輿情展示，還有一塊業(yè)務(wù)的展示，或者跟 BR 配合。
如果發(fā)現(xiàn)有問題之后，我們會快速推送我們的 Patch 包，我們來修復(fù)這個問題，把 Patch 包放到 CDN 上。
今天有一塊東西沒講，Patch 怎么來解決，這個跟端側(cè)的技術(shù)有非常大的關(guān)系，安卓上可能會有動態(tài)部署或者 Patch，這塊都是后面如果有興趣可以聽我們其他一些動態(tài)部署、動態(tài)歇伏的課程。
整個回顧來看，在整個客戶端側(cè)，整個運(yùn)維體系最關(guān)鍵是三塊：
是在整個端側(cè)，怎么通過 SDK 能力發(fā)現(xiàn)問題。
在服務(wù)端，怎么快速通過監(jiān)控?cái)?shù)據(jù)發(fā)現(xiàn)一些用戶的問題。
是說知道這些問題之后，怎么通過一個手段能夠 Trace 當(dāng)天用戶具體的原因，知道原因以后把這些問題快速修復(fù)。
近日好文：
GOPS的這個阿里巴巴大咖演講，您中意不？
就在4月21日-22日的GOPS2017深圳站喲。
GOPS2017·深圳站
今年 雙十一 是否順利
就靠 GOPS 的干貨了
會議地點(diǎn)：南山區(qū)圣淘沙酒店（翡翠店）
會議時間：2017年4月21日-22日
您可點(diǎn)擊“閱讀原文”，享受折扣購票
