零售雲主要是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 雲跡效能監控,...