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