零售雲App穩定保障
1 背景
零售雲目標T4-T6級市場的業務，定位更靠譜的智慧零售解決方案和零售服務整合商，實戰式跨界賦能。蘇寧易購TOC的經驗豐富，相關的方案很完善，但是零售雲TOB相關業務啟動後，業務增長迅速，App相關的穩定保障方案缺失。
2 零售雲業務的特殊性
零售雲主要是TOB的業務，目標T4-T6級市場的加盟店，授權店，跟TOC業務相比，有以下有個不同點：
1）使用者量不多，但是每個使用者強依賴零售雲相關App。
2）每筆訂單金額巨大。
3）需要系統穩定。
零售雲的每個使用者都是一家門店的一個角色人員（老闆，店長，收銀員…），每家門店每天的進銷存都依賴零售雲配套App（零售雲，零售雲店員，零售雲管家）。零售雲App提供進貨服務，零售雲店員提供銷售服務，零售雲管家提供庫存管理，報表查詢等服務。可以看出，一個使用者使用出現問題，就會影響到一家門店的日常銷售，導致不能正常銷售，每一家門店每天都付著店面租金和人員酬勞，不能營業的後果非常嚴重。
3 前期快速迭代滿足業務遇到的問題
零售雲主要是TOB的業務，目標T4-T6級市場的加盟店，授權店，跟TOC業務相比，有以下有個不同點：
1）使用者量不多，但是每個使用者強依賴零售雲相關App。
2）每筆訂單金額巨大。
3）需要系統穩定。
零售雲的每個使用者都是一家門店的一個角色人員（老闆，店長，收銀員。。。），每家門店每天的進銷存都依賴零售雲配套App（零售雲，零售雲店員，零售雲管家）。零售雲App提供進貨服務，零售雲店員提供銷售服務，零售雲管家提供庫存管理，報表查詢等服務。可以看出，一個使用者使用出現問題，就會影響到一家門店的日常銷售，導致不能正常銷售，每一家門店每天都付著店面租金和人員酬勞，不能營業的後果非常嚴重。
4 App穩定保障思路
系統穩定的三個特點：可監控，可灰度，可回溯。對於App來說，一旦新包發出去後，想回溯就不太現實了，辦法無非是提示更新或者熱更新，所以我們主要針對前面兩點來實現。
4.1 可監控
在監控上我們做了兩個方面的工作：
1）雲跡效能監控，類似友盟或者Buggly的效能統計，包括崩潰，卡頓，日活等等；
2）雲跡實時日誌統計分析。
4.2 可灰度
1）實現到店鋪層面的灰度更新
下面我們來展開講講這兩點的實現方式。
5 到人的請求監控（可監控）
類似友盟或者Buggly的效能統計，我相信大部分App也都接入了，這邊不做解釋了，不管TOB還是TOC業務都一樣。
正是基於上面的效能統計，我們得知，零售雲App的使用使用者，60%左右是在WIFI環境下。上面也解釋了TOB業務對系統的強依賴性，但是對於流量消耗的敏感度卻不高。基於前提條件，我們決定把客戶端所有的網路請求資料和業務錯誤軌跡都記錄在雲跡平臺，並且配置錯誤告警。這樣做的好處有兩個：1）通過簡訊和郵件告警，可以快速知道錯誤。2）通過實時日誌埋點可以知道每個使用者的行為和操作軌跡，方便快速定位錯誤。流程圖如下所示：
5.1異常告警
我們根據自己的需求，配置搜尋條件，告警觸發條件，並以簡訊和郵件的方式通知給對應的負責人。如下圖所示：
當有異常觸發告警條件時，對應負責人會簡訊和郵件收到告警通知，第一時間發現問題。
5.2日誌查詢
1. 當收到告警後，對應負責人需要登入到雲跡實時日誌分析平臺 1） 選擇對應的系統名 2） 選擇日誌型別 3）選擇查詢時間 4） 通過kibana查詢語法，即可查詢到該條件下的日誌。
2.我們隨便點開一條日誌，可以看到詳細的使用者資訊。
根據上圖日誌內容可以快速獲取如下關鍵資訊：
1）app版本
2）手機版本，手機型號
3）業務資訊（請求地址，請求引數，返回引數，堆疊資訊）
4）賬號
通過上面資訊可以快速定位到某個時間點下錯誤的請求。
3.某個使用者軌跡
很多時候，某些錯誤是在使用者特定操作下才會觸發，這個時候，需要知道使用者的操作軌跡，我們可以通過kibana查詢語法，篩選出某個使用者的所有日誌，根據請求時間可以很方便的知道，使用者的整個操作軌跡。如圖所示，該使用者最近三小時的操作行為都可以查到。
得到使用者的行為軌跡，很多錯誤場景，研發可以自己模擬，不需要再遠端諮詢門店使用者，方便高效定位問題。
6.到店的移動App灰度釋出（可灰度）
TOC的場景一般是使用者量的灰度，比如一次灰度10000個使用者，但是對於TOB卻不適合，比如一次灰度100個使用者，可能覆蓋到100家店鋪，一旦出問題這100家店鋪正常銷售受到影響，而且統計哪些店鋪受到影響也很困難。針對零售雲特殊的情況，我們制定了特殊的灰度釋出流程。每個app在蘇寧升級平臺（MPCS）上面配置兩個appid，一個為正式版本包，一個為灰度版本包，客戶端根據分銷前臺返回的appId（0/1），區分取正式包還是灰度包的appid，進行版本更新請求。灰度期間，通過分銷前臺配置店鋪白名單，在白名單檔案中的店鋪下的使用者提示升級到最新版本，其他使用者無影響。在灰度成功後，分銷前臺關閉灰度開關，進行全量升級。流程圖如下所示：
灰度期間只有白名單使用者才呼叫灰度包更新介面，其他使用者呼叫正式包升級介面。逐步增加灰度的店鋪，10個->20個->50個->100個->全量，期間注意觀察雲跡異常。
7.避免的生產問題
通過上面的穩定保障，我們避免了不少生產問題，這邊舉兩個例子：
1）四月份的一個下午，突然收到很多告警，開啟雲跡實時日誌查到一個小時內報大量的請求超時，而且集中在某個區域，通過這些關鍵資訊，最後定位是運營商網路的問題，當天就快速修復，對於使用者來說對於整個修復過程無感知。
2）雲跡告警商品詳情頁介面會偶爾失敗，通過雲跡查詢到日誌資訊發現，商品詳情頁需要傳的店鋪編碼，某些時候客戶端傳的是空，但是review客戶端相關模組程式碼，確認每次都是傳了店鋪編碼，這個時候就需要模擬使用者的操作軌跡。通過查詢該使用者所有操作日誌，分析出失敗介面前面幾分鐘的操作行為得知，在四級頁停留了很長時間後登陸失效，再次登陸後店鋪編碼為空，知道具體錯誤後，就可以在下個版本修復避免生產問題。
8.目標展望
為了保障零售雲App的穩定，我們其實還做了很多工作，這裡不一一列舉了，當然我們還有很多的提升空間，未來我們會不斷優化監控和灰度方案，加強資料收集和分析，保障零售雲App的穩定。再穩定的系統也不能保證百分之百不出問題，所以在應對可能出現的問題時，我們必須要在第一時間發現問題，快速響應解決問題。
作者簡介
曹銀飛，蘇寧易購IT總部Android技術專家，擁有多年Android研發和管理經驗。曾就職於聯創，騰訊等大型網際網路公司，現負責蘇寧易購Android開發部產品研發與技術管理工作，在Android專案架構設計，效能優化，團隊管理上有多年的實戰經驗。現致力於打造蘇寧智慧零售相關App，希望將蘇寧的零售技術能力發揮到極致。