记一次线上Bug解决过程

Bug
线上设置业务时, 选择部门员工, 发现有两个员工怎么都保存不了, 传参员工id正常, 出参查询到的id也正常, 唯一不正常的就是有两个id的员工信息是查不到的

排查
线上bug, 如何debug, 如何找到问题根源? 是很头疼的问题, 因为线上数据是拿不到的, 所以我们无法知道它的入参是什么, api成了一个摆设.
我们决定从线上入手, 使用抓包工具Charles 拿到线上传入与传出参数, 将数据做对比, 发现问题根源在于查询到的员工数据所做的逻辑操作.

思路决定速度
leader带着我调用了一下基础服务所提供的查询员工的Dubbo接口, 并将线上传入的员工参数作为入参传递进去, 发现查询出来的数据是完全正常的
这里我犯了一个错误, 我没有认真看leader传给我的基础服务查询出来的数据, 导致我们认为是基础服务那边的原因, TAT 犯了一个大乌龙
我们认真对比了一下消失的二人数据与正常数据的异同, 发现查询不到的两人是已经被软删除过的, 而我们在查询后, 对软删除数据做了处理, 导致数据夭折在业务逻辑中
问了之前的同事是什么情况, 他们说是历史残留问题, 之前的软删除现在已经被状态给替代了, 所以修改一下就可以了

修改与自测
将软删除判断修改之后, 突然想到, 我自测怎么测? 我图方便, 用线上数据测, 竟然能查到一些数据, 不要学我, 我已经被骂了
自测一定要使用测试数据, 如果没有只能厚脸皮去问测试要测试数据! ! ! !

总结
这次解决线上bug, 经验不足的地方还有很多
1 : 看代码一定要从头看到尾, 如果要修改要先看之前是否已经有重复逻辑
2 : 修改bug要精简, 找到问题根源, 不要急于修改, 想到最佳方案后,在写
3 : 看是否有已经写好的枚举供使用, 如果有尽量用
4 : 修改完成后, 记得自测