统计项目，已持续做了一年，接手2周
Bug01: order.log-4月份日志总量83万条，采集到数据库中只有61万条，漏了22万条数据
我：为什么会少这么多的数据？我们是按什么条件对日志做了筛选？
研发：没有呀，给什么就采集什么，代码是对的。
我：源头就不对，后面统计的都不会对的，你再看下吧。
研发：采集的时候遇到格式错误，直接跳过当前文件，采集下一个文件了。
最终处理：增加异常处理，并和项目沟通：日志格式不对，导致漏了些数据，需要他跟客户解释。
还以为到这里Bug圆满解决了，过几天后发现按某一内容统计得到的1113，数据库中记录的是1112，好几个内容都是这样的情况。
脑子里充满疑惑，不像是格式不对，于是把1113条数据按时间顺序排好，
cat **/order.log.201904* |grep "|57cea269e75414ead8261d086048c1ab|" |sort > /opt/product/zjxmt/stat/a.txt
再到数据库中查询该内容并按时间顺序排好。
select request_time from order_log lg where lg.content_code="57cea269e75414ead8261d086048c1ab"
and lg.request_time between "2019-04-01" and "2019-05-01" order by request_time;
使用文本对比工具，找出了漏掉的日志。
2019-04-20 14:41:55 这一条日志没有采集到，获取该行的详情对比日志的格式都是对的，唯有return_url比其他日志长很多，统计了下return_url的长度1128，数据库中return_url字段是1024。
研发扩展了字段长度，重新采集日志，日志总量和数据库中采集到的总量对上了。
Bug02:统计内容的播放时长，单个内容的播放时间记录的是秒，统计时换算到小时并用了四舍五入，导致最终每个产品包下的时长比实际播放时长多了十几、上百个小时。
四舍五入是不能随便用的。
Bug03: order.log日志按某一content_code：53adeac62ce894f7f5471a81b2da5442查到记录175条，研发统计结果只有126条。
对比日志发现有126条是series的，49条vod的，但是一个内容就只有一个类型的，比如是电影，就不会是连续剧，而订购触发是可以在连续剧上订购，也可以在某一子集上订购，所以会有vod类型过来，但统计的时候应该把这两种情况统计到同一个内容中。
这个问题我以为非常简单好懂的，但沟通的过程有点不顺。
和研发沟通，他没有明白，然后跟项目经理讲了好一会儿他也没有明白。
我对yz说：我生气，我讲的他们都不明白。
yz: 你跟我讲，我去和项目经理说。
复述一遍问题，yz听懂了，然后她跟项目经理讲通了，让项目经理去跟研发说。
今早研发说：content_type不一样,code一样算重复，所以特意过滤掉了，不进行统计。
然后项目经理就没有声音了，我跟研发解释：订购时间不一样， code一样 content_type 不一样 不能算重复。
yz看到我不耐烦了，盯着项目经理说：你能去和研发讲清楚吗？能吗？你自己懂吗？
项目经理被逼着去沟通了，过一会儿收到研发跟我说：不区分content_type，只按code统计。
也发现了自己的一个Bug，为什么我能和yz合作，不能和其他项目经理合作。
我和yz的合作模式：我发现问题，并告诉她问题，她就会去安排，要不要处理，怎么处理，什么样的解决方案是合理的，她会有自己的判断并把事情安排下去。
我和其他项目经理：我发现问题，并告诉他们问题，然后就没有然后了。
我如果想要问题圆满解决就得我自己去干-说服项目经理、说服研发，而这不是我擅长的，也不是我乐意去做的。
Bug04:推荐时长-统计出来的时长和客户大数据平台统计的完全对不上，看了研发的程序发现很多情况都没有考虑到，重新理的需求。
