點擊關注"故里學Java"
右上角"設爲星標"好文章不錯過
事故描述：
上週客戶的大促活動中，客戶反饋，存在部分已發貨的訂單退款成功，造成了慘重的損失，直接影響在客戶信任感。事後我們對這次事故進行了專項覆盤。
造成影響：
涉及問題訂單100餘單，累計金額近萬元。
什麼原因造成的？
WMS發貨完成後，回傳OMS物流信息，調用訂單發貨接口失敗，訂單發貨接口未做特殊異常處理，導致訂單狀態未能及時同步給平臺。正確的業務邏輯應該是買家發起退款申請，在客服人員手動點擊發貨重新同步平臺狀態之前，進行退款申請，OMS系統自動攔截WMS發貨，此時因爲WMS已發貨成功，所以攔截失敗，但是平臺訂單狀態未更新，所以退款申請默認同意。核心問題是訂單服務的其中一個實例加載mq配置文件失敗，導致這個實例不能發送mq消息，缺乏消息重試機制。
爲什麼沒有及時發現問題？
項目是客戶私服部署，由客戶的運維進行發佈維護，監控系統被替換成客戶自己搞的監控系統。
對於異常的報警機制不完善。
發現異常時做了哪些事情？
-
通過分析日誌，定位到問題
-
聯繫客戶運維人員剔除出問題的訂單服務實例
-
技術手段排查出問題訂單交由客戶業務人員進行問題訂單攔截。
以後如何避免？
通過對這次事故的覆盤，針對這次的事故的解決方案如下：
-
接口異常及時拋出，供調用方進行對應業務邏輯處理
-
消息發送服務提供自動重試機制，如果發送失敗，系統自動重試3次，對異常進行落庫處理
-
對重要節點的異常提供短信和釘釘消息提醒，技術及時處理
-
完善監控系統，監控每個實例狀態，及時處理問題容器。
事故總結：
正視每一次事故，刨析事故原因，有針對性的解決事故原因，對於事故的預防工作該如何優化，避免下一次更嚴重的事故。希望技術人敬畏每一行代碼！
- END -
好文推薦（點擊可閱讀）：
加油打工人！！！
點個贊，證明你還愛