尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
1 背景
零售雲目標T4-T6級市場的業務，定位更靠譜的智慧零售解決方案和零售服務集成商，實戰式跨界賦能。蘇寧易購TOC的經驗豐富，相關的方案很完善，但是零售雲TOB相關業務啟動後，業務增長迅速，App相關的穩定保障方案缺失。
2 零售雲業務的特殊性
零售雲主要是TOB的業務，目標T4-T6級市場的加盟店，授權店，跟TOC業務相比，有以下有個不同點：
1）用戶量不多，但是每個用戶強依賴零售雲相關App。
2）每筆訂單金額巨大。
3）需要系統穩定。
零售雲的每個用戶都是一家門店的一個角色人員（老板，店長，收銀員…），每家門店每天的進銷存都依賴零售雲配套App（零售雲，零售雲店員，零售雲管家）。零售雲App提供進貨服務，零售雲店員提供銷售服務，零售雲管家提供庫存管理，報表查詢等服務。可以看出，一個用戶使用出現問題，就會影響到一家門店的日常銷售，導致不能正常銷售，每一家門店每天都付著店面租金和人員酬勞，不能營業的後果非常嚴重。
3 前期快速迭代滿足業務遇到的問題
相關廠商內容
2018年末運維技術熱點盤點
如何構建微服務下的性能監控
機器學習在大規模服務器治理複雜場景的實踐
365天看極客時間全部課程，還可獲得100份技術乾貨
Kubernetes的關鍵技術、應用場景以及在企業落地實踐的經驗
相關讚助商
CNUTCon全球運維技術大會，11月16日－17日，上海，精彩內容搶先看！
零售雲主要是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的穩定。再穩定的系統也不能保證百分之百不出問題，所以在應對可能出現的問題時，我們必須要在第一時間發現問題，快速響應解決問題。igo