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