定位问题经验总结

    通过最近定位的两个问题，认识到自己在定位时的一些问题，记下来免得又犯这种错误。

1
一同事阿桃，需要搭建我们产品的环境，由于不熟悉部分配置导致搭建不成功。来电咨询，与他确认过版本，搭建过程后，我判断是某两个进程的消息交互不完全导致。遂要来日志分析，A进程日志表明发消息到B进程后，未收到B进程的响应，而B进程的日志则表明其以发送完响应消息。考虑到消息机制是通过调用其他组同事开发的消息组件API，因此怀疑是该API丢包导致，于是准备要阿桃向另一同事求助定位该问题，他居然不肯。于是进入复读模式，我又一步一步跟他确认过之前确认过的搭建过程。最后，我确认自己这边肯定没有问题了，只好尝试猜测一下是不是内存或CPU占用率导致了丢包，阿桃一看，果然内存占用很高(>99%)，遂建议重启试一下。此时已到饭点。。。 下午阿桃回电，OK了
这个定位过程中，跟阿桃进行二次确认的过程占用了很多的时间，因为一直在怀疑是自己这边的问题，是思维定势，潜意识就认为自己做的东西有问题，如果根据日志直接猜测消息组件在什么情况下会出现丢包，无疑会节约很多时间。

2
这次定位也是怀疑到了自己做的产品代码上，实际上这份代码是自测过的，没问题。但测试人员测试时出现了诡异的现象，从代码上看流程，实在是找不到对应这种现象的流程。终于想到该产品有链接动态库，猜测是不是动态库版本不对，检查后发现测试在系统中存放了两个动态库的副本，其中一份在/usr/lib下，另一份在自定义目录下，前者是老版本，后者是正确版本。由于系统搜索动态库时优先搜索系统默认路径/usr/lib，所以出现不可思议的现象。
本次定位，流程代码是自己写的，也自测过，出现非预期的现象，理应怀疑到环境问题上，能大大节约解决问题的时间。