业务逻辑复杂,历史久远的接口出现数据错误怎么办?原创
接口返回数据错误,如何快速找到问题原因并进行修复?
01背景
1.1 下班时,业务反馈:线上数据错了
1.2 分析
找前端同学确认控制“点击咨询期货”是由接口返回的“skuLt”字段控制:
02BugShooting
2.1 排查思路1:梳理接口逻辑找到原因
业务太复杂链路太长,难以快速找到重点
数据链路长,业务逻辑多,难以快速找到原因。。。
这是2-3年前的代码了,上线后就没有再去过了,都不记得了。
想快速fix bug,通过梳理业务逻辑较难以办到。梳理业务逻辑,放到第二象限。看看有没有别的办法可以快速bugshooting
2.2 换个思路:同样的接口,为什么有的sku信息是正确的呢?
会不会是因为这些参数关联的sku不同导致的?
譬如“爆款精选”中的有一些特殊的sku信息缺失,导致获取"skuLt"时出现了未知错误
✪ 查询参数不同的原因?
这个地方的确应该不同,线索断了。
走,去看看日志中有没有其它线索
✪ 日志
“爆款精选”楼层的接口有报错信息!
问题是,这两个sku是存在的,且可以正常展示:
并且,sku信息有缓存,不应该再次去【商品中心中台】去查!
✪ 很可能是查询参数的问题!
果然:
请求参数果然有问题!
"%C2%A0"被转换为空格字符" ",因为它是URL编码中表示空格字符的形式。
ChatGPT3
✪ 错误的数据是从哪来的?
配置的数据就是错的!
解决办法:通过后台管理把这个“空格”删除就好了。
如果有两种或两种以上的方式去做某件事情,而其中一种选择方式将导致灾难,则必定有人会做出这种选择。
墨菲定律
但,没有一个地方!!!
03小结
3.1 业务场景
1、线上出现问题,通过梳理业务逻辑不能快速fix bug
2、分析接口发现:接口相同,有的正确,有的错误,怀疑有错误的入参
3、分析日志:发现有报错,且报错的代码与当前bug业务域相同
4、发现配置的参数有错误
5、更改错误的参数,问题解决。