零售雲主要是to b的業務，目標t4-t6級市場的加盟店，授權店，跟to c業務相比，有以下有個不同點：
1）系統問題需要門店上報給運營，運營再同步給研發負責人，問題的流程較長響應比較慢。
2）研發需要跟門店人員確認操作過程，甚至借用登入賬號，體驗不好。
在監控上我們做了兩個方面的工作：
1）雲跡效能監控，類似友盟或者buggly的效能統計，包括崩潰，卡頓，日活等等；
2）雲跡實時日誌統計分析。
1）實現到店鋪層面的灰度更新
下面我們來展開講講這兩點的實現方式。
我們根據自己的需求，配置搜尋條件，告警觸發條件，並以簡訊和郵件的方式通知給對應的負責人。如下圖所示：
當有異常觸發告警條件時，對應負責人會簡訊和郵件收到告警通知，第一時間發現問題。
1.當收到告警後，對應負責人需要登入到雲跡實時日誌分析平台 1） 選擇對應的系統名 2） 選擇日誌型別 3）選擇查詢時間 4） 通過kibana查詢語法，即可查詢到該條件下的日誌。
2.我們隨便點開一條日誌，可以看到詳細的使用者資訊。
根據上圖日誌內容可以快速獲取如下關鍵資訊：
通過上面資訊可以快速定位到某個時間點下錯誤的請求。
3.某個使用者軌跡
很多時候，某些錯誤是在使用者特定操作下才會觸發，這個時候，需要知道使用者的操作軌跡，我們可以通過kibana查詢語法，篩選出某個使用者的所有日誌，根據請求時間可以很方便的知道，使用者的整個操作軌跡。如圖所示，該使用者最近三小時的操作行為都可以查到。
得到使用者的行為軌跡，很多錯誤場景，研發可以自己模擬，不需要再遠端諮詢門店使用者，方便高效定位問題。
灰度期間只有白名單使用者才呼叫灰度包更新介面，其他使用者呼叫正式包公升級介面。逐步增加灰度的店鋪，10個-\u0026gt;20個-\u0026gt;50個-\u0026gt;100個-\u0026gt;全量，期間注意觀察雲跡異常。
通過上面的穩定保障，我們避免了不少生產問題，這邊舉兩個例子：
1）四月份的乙個下午，突然收到很多告警，開啟雲跡實時日誌查到乙個小時內報大量的請求超時，而且集中在某個區域，通過這些關鍵資訊，最後定位是運營商網路的問題，當天就快速修復，對於使用者來說對於整個修復過程無感知。
2）雲跡告警商品詳情頁介面會偶爾失敗，通過雲跡查詢到日誌資訊發現，商品詳情頁需要傳的店鋪編碼，某些時候客戶端傳的是空，但是review客戶端相關模組**，確認每次都是傳了店鋪編碼，這個時候就需要模擬使用者的操作軌跡。通過查詢該使用者所有操作日誌，分析出失敗介面前面幾分鐘的操作行為得知，在四級頁停留了很長時間後登陸失效，再次登陸後店鋪編碼為空，知道具體錯誤後，就可以在下個版本修復避免生產問題。
作者簡介
蘇寧零售雲 App 穩定保障實踐
n n 零售雲主要是to b的業務，目標t4 t6級市場的加盟店，授權店，跟to c業務相比，有以下有個不同點 n n 1 系統問題需要門店上報給運營，運營再同步給研發負責人，問題的流程較長響應比較慢。n2 研發需要跟門店人員確認操作過程，甚至借用登入賬號，體驗不好。n n 在監控上我們做了兩個方面...
蘇寧零售雲 App 穩定保障實踐
零售雲主要是to b的業務，目標t4 t6級市場的加盟店，授權店，跟to c業務相比，有以下有個不同點 1 系統問題需要門店上報給運營，運營再同步給研發負責人，問題的流程較長響應比較慢。2 研發需要跟門店人員確認操作過程，甚至借用登入賬號，體驗不好。在監控上我們做了兩個方面的工作 1 雲跡效能監控，...
蘇寧零售雲 App 穩定保障實踐
零售雲主要是to b的業務，目標t4 t6級市場的加盟店，授權店，跟to c業務相比，有以下有個不同點 1 系統問題需要門店上報給運營，運營再同步給研發負責人，問題的流程較長響應比較慢。2 研發需要跟門店人員確認操作過程，甚至借用登入賬號，體驗不好。在監控上我們做了兩個方面的工作 1 雲跡效能監控，...