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