日志排查问题总结

写在前面：

因为公司负责的项目流程链路很长，经常需要排查问题定位问题。目前项目是把每个service的方法前后都加上了入参和返回值的打印。接管项目后，总结了一下通过日志定位问题的经验，希望以后排查问题能有一些帮助。

第二版：

运单后台排查问题的方法总结：

1.先查看微信预警群是否有该问题相关的报警；
2.业务后台检查相关运单/机器人状态；
3.优先确定是否是配置（权限配置）不正确等原因引起；

代码逻辑熟悉时：
4.再根据测试/现场人员描述的描述以及自己熟知的业务流程简单分析一下可能出现的原因；     
5.根据问题产生的时机尽量先预期到某个节点的日志正常情况/异常情况；
6.去相关日志节点验证自己猜测。

代码逻辑不熟悉时：
4.对于不熟悉的业务逻辑场景，目前是代码+关键节点日志信息梳理当时机器人的业务行为；
5.定位到某个可能产生问题的方法后，查看方法入参和返回值信息是否符合预期；
6.若不符合预期继续分析并向前/向后追溯产生异常数据的原因；

7.还原当时机器人状态以便确定问题是云端/导航/业务app/配置错误引起；
8.最后还无法定位，再在特定节点添加日志信息，待复现后再确认。
9.复现后根据所加日志进一步确定问题代码的范围。

通过现阶段运单业务的支持工作，暂得出如下总结：
1.上文1，2，3三点可以通过推动产品/运营/测试人员去优先自主定位问题，并通过业务后台解决问题。以便减少开发人员的支持工作。
2.快速排查问题，定位并解决问题的前置条件