最近一段时间，项目从python2转为python3，并伴随的大量的功能重构，于是乎陷入了测试、找BUG、改BUG的循环中。老实说，吐了吐了。
最新的一个BUG，是nmap扫描的问题。
发出3000个IP nmap扫描的任务，最后只收到了不到100个IP有端口。
测了一下，大部分ping不同。
能ping通的再测一下，--min-parallelism设置得太高，同时节点发出大量数据包，可能导致网络拥堵收不到返回包。
那么调用Nmap时 --min-parallelism调低一点，超时调高一点，跑到中间不继续往下跑了，print都没有了？
原来是celery超时了。
过程中，最麻烦的点
一 分布式任务中，复现时无法确定发出的流量是哪个节点接收到了
对于这种情况，要不停用其他节点留下一个节点；要不发出一批流量，挨个节点检测。
为了避免是某个节点的环境出了问题，我选择了挨个检测。
但这两种不管选什么，唉，都在半夜弄吧。毕竟白天扫描器要正常运行，晚上半夜流量少点，可以折腾。
二 日志缺乏或者混乱
之前python2版本的日志是比较完善的，但python3版本这一块功能做了一半，其中有的用Logging输出，有的用Print，有的重定向了输出(找了半天，我输出呢)，苦不堪言。
三 单个任务耗时长
对于nmap或者其他扫描任务，可能是在调用nmap或者扫描时出了错，不能简单地用其他数据替换，所以老老实实跑。
一批IP + nmap扫描，用时超过十分钟。
每次调试，改插件设下print、改任务、重启扫描器(嗯，因为重构，任务这块还有bug，所以还得重启扫描器)、十几分钟过去了，再挨个节点检查一下，一轮下来半小时就过去了。
整个过程不像正常debug一样，运行，看报错，运行，看报错；而是 改动、运行，过去半小时，检查结果。
加一句调试信息，等半小时。
四 该做什么
找BUG心得，尽量 用最小的成本去复现BUG
测试环境其实应该完善好，但因为测试环境的数据远不如线上环境来的正常，插件移植也比较麻烦，所以一直懒得弄。
这一点，应该学习一下其他项目，定期会将线上的 任务/漏洞等数据同步到线下。
迷，凌晨4点，从十点开始，其实也就调试了十几次。
难受啊兄der