点击关注"故里学Java"
右上角"设为星标"好文章不错过
事故描述:
上周客户的大促活动中,客户反馈,存在部分已发货的订单退款成功,造成了惨重的损失,直接影响在客户信任感。事后我们对这次事故进行了专项复盘。
造成影响:
涉及问题订单100余单,累计金额近万元。
什么原因造成的?
WMS发货完成后,回传OMS物流信息,调用订单发货接口失败,订单发货接口未做特殊异常处理,导致订单状态未能及时同步给平台。正确的业务逻辑应该是买家发起退款申请,在客服人员手动点击发货重新同步平台状态之前,进行退款申请,OMS系统自动拦截WMS发货,此时因为WMS已发货成功,所以拦截失败,但是平台订单状态未更新,所以退款申请默认同意。核心问题是订单服务的其中一个实例加载mq配置文件失败,导致这个实例不能发送mq消息,缺乏消息重试机制。
为什么没有及时发现问题?
项目是客户私服部署,由客户的运维进行发布维护,监控系统被替换成客户自己搞的监控系统。
对于异常的报警机制不完善。
发现异常时做了哪些事情?
-
通过分析日志,定位到问题
-
联系客户运维人员剔除出问题的订单服务实例
-
技术手段排查出问题订单交由客户业务人员进行问题订单拦截。
以后如何避免?
通过对这次事故的复盘,针对这次的事故的解决方案如下:
-
接口异常及时抛出,供调用方进行对应业务逻辑处理
-
消息发送服务提供自动重试机制,如果发送失败,系统自动重试3次,对异常进行落库处理
-
对重要节点的异常提供短信和钉钉消息提醒,技术及时处理
-
完善监控系统,监控每个实例状态,及时处理问题容器。
事故总结:
正视每一次事故,刨析事故原因,有针对性的解决事故原因,对于事故的预防工作该如何优化,避免下一次更严重的事故。希望技术人敬畏每一行代码!
- END -
好文推荐(点击可阅读):
加油打工人!!!
点个赞,证明你还爱