做好移動APP質量保障工作你需要知道哪些?
原創本文是WOT2016互聯網運維與開發者大會的現場干貨,新一屆主題為WOT2016企業安全技術峰會將在2016年6月24日-25日于北京珠三角JW萬豪酒店隆重召開!
我叫楊強,在阿里巴巴負責的事情比較雜,從線下研發管理、發布流程,到質量保障,到線上客戶端的監控運維等等方向。今天想向大家分享的是我們在手機淘寶端上所做的一些運維以及優化的相關工作。
從2012年加入手機淘寶以后,我發現APP實在是比PC端有太多的痛苦,***是閃退,閃退就導致手淘不可用。第二個,響應時間太慢,有時能長達五六秒鐘,這對用戶來說是很不可接受的一個時間。還有就是耗電和耗流量的問題。還有一些是和PC上類似的問題,比如頁面加載異常或者一些安全上的問題。
面臨這么多困難要解決,解決的思路肯定是發現,發現然后解決,然后再看問題有沒有存在。說起來比較容易,但是端上還是有很多的復雜性。
首先是機型復雜。據不完全統計,線上市面上存在的的機型已經超過兩萬種了。如何保證我們的APP在這兩萬種機型上都是可用的一個狀態,對于我們來說是一個非常困難的事情。我們曾經接到用戶的反饋,說手機淘寶下單不能用,我們在線下試,什么機型都試過來了,線下都可以用,為什么他不能用呢?***客戶拿出來一款黑莓的手機,說黑莓上也可以兼容安卓的APK來使用。
再一個問題是網絡。各位移動開發者可能對網絡這個問題都感到比較頭大,因為這個網絡***個是移動網絡,第二個用戶使用的環境非常多,他在高鐵上,在地下室或者在比較偏遠的山區等等地方,我們都要保證這些場景下軟件的高可用性。
有了以上兩種特點以后,再加上一些其它的原因就產生了另外一個問題,小概率問題特別多。因為我們手淘可能是很多億的用戶,但是有問題的東西,有時候有些問題只有幾百個用戶有或者十個用戶有。發現問題了,就要重現與定位,這個手段不像服務端,在服務器上Bug一下,看一下服務器的日志就可以了,還需要了解手機當時所處的環境。
再有一個問題是修復手段,客戶端是通過應用市場發布交付出去的,但如果出現問題的時候怎么樣解決。現在一個APK可能30M、40M,這樣為了解決一個小Bug而推一個30兆、40兆的包下去,這個成本和代價是相當大的。
那么,針對以上這些問題,我們是如何處理如何解決的?首先是保證客戶端的穩定性。我們做了一下幾個事情:定制各種各樣的聚類算法、多維度的分析和分發、按照業務維度進行告警、監控等。
下面說一下比較常見的錯誤監控。錯誤監控大概分幾類:***個肯定是網絡層,各種超時,各種檢驗失敗等情況。接口調用就是網絡上的接口這種調用的,不管是網絡層的失敗還是業務層的失敗都會有相應的監控。業務錯誤就是在端上,其實你的端有時候也有很多業務這種邏輯,所以我們會把這些邏輯加上一些監控的點。數據錯誤就是說數據本身可能有些都是人為的,本身會由于代碼的修改產生一種格式的變化或者數據量的變化,所以我們對數據本身也要進行一些分析與監控。
本著節約成本辦大事的原則,我們就把這些東西劃分開。首先實時告警可能到分鐘級別,也有到秒級的,它是保證這些關鍵的錯誤點,比如說Crash率、網絡的錯誤,一些業務的錯誤,下單失敗等等各種各樣的這種錯誤類型。然后我們可以用阿里云的大數據的計算服務,達到了一個小時級別或者半小時級別的監控,就是每半個小時或者每一個小時跑出來一份指標,然后與之前的數據進行對比。
有了上面的監控、指標度量等等這種東西以后,可以展開一些專項的工作,去推動一些問題的修復,甚至推動架構的一個變化。當然,我們會有一個主動監控的系統來進行這種功能上的、網絡層面上等等這種主動的監測,說白了就是在線上不斷去跑自動化case,case失敗了就告警。
說完技術上的監控,其實我想說的最重要的一點,用戶的反饋是非常非常重要的。舉一個簡單的例子,比如說APP出現了一個在啟動階段最早的問題,可能它壓根裝上就啟不起來,你什么都感知不到,怎么辦?那只能通過用戶的反饋,用戶在各大市場上他反饋了什么。
輿情系統我們做了幾個事情,當然這個是僅僅針對用戶反饋這一塊。首先我們進行了分類達標,我們把它分為系統故障、體驗問題、產品問題、客戶咨詢。我們就通過輿情系統進行發現,然后進行干預、進行排查、進行修復。
當遇到一連串非常嚴重的業務邏輯錯誤時該怎么辦呢?我們會進行動態部署。對比原來老的包生成一種差量,然后下發到端上。***如果所有手段不行,只能重新發版,當然重新發版也是有策略的。所以我們有一整套發布策略,可以對發版,也可以對發動態部署、Hotpatch配置等等。
智能的放量人為控制,就是說在發布的過程中APP量級非常大的時候,不可能一次性全發的。先放一版,看指標,系統指標合格了,然后再次往上放,不斷放量,是一個逐漸灰度的過程。
***就是全量,用推拉結合的一種方式。拉就是拉接口,推是從通道推一個消息下來,然后接收這個消息。時效性高可能對服務端的壓力也是非常大的,所以這個推拉結合的方式可以提高我們的到達率。
總結上面說的,我們會有實時告警、離線分析,有用戶反饋這種分析,有實時日志分析,還有服務端分布式調用鏈路的分析,也有一整套故障解決方案。不斷去優化線下質量保證的系統,發布策略、發布流程等等?,F階段雖然做了一些工作,但可能也不是那么***,我們一直努力在打造一套端上的運維分析的工具。
我講完了,謝謝大家!
本文整理自,由51CTO傳媒主辦的WOT2016互聯網運維與開發者大會上來自阿里巴巴高級技術專家楊強主題為《移動APP質量保障工作》的精彩演講。
演講視頻:http://edu.51cto.com/lesson/id-100756.html
講師簡介:
楊強,2012年加入阿里巴巴,負責無線產品的研發支撐與無線線上監控運維相關平臺相關工作。支持了手淘、天貓、聚劃算、釘釘等阿里巴巴內部APP的研發支撐和線上監控運維相關工作。