統(tǒng)計項目祈坠，已持續(xù)做了一年忌卤，接手2周
Bug01: order.log-4月份日志總量83萬條，采集到數據庫中只有61萬條，漏了22萬條數據
我：為什么會少這么多的數據领追？我們是按什么條件對日志做了篩選他膳？
研發(fā)：沒有呀，給什么就采集什么绒窑，代碼是對的棕孙。
我：源頭就不對，后面統(tǒng)計的都不會對的些膨，你再看下吧蟀俊。
研發(fā)：采集的時候遇到格式錯誤，直接跳過當前文件订雾，采集下一個文件了肢预。
最終處理：增加異常處理，并和項目溝通：日志格式不對洼哎，導致漏了些數據烫映，需要他跟客戶解釋。
還以為到這里Bug圓滿解決了噩峦，過幾天后發(fā)現按某一內容統(tǒng)計得到的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比其他日志長很多白翻，統(tǒng)計了下return_url的長度1128乍炉，數據庫中return_url字段是1024绢片。
研發(fā)擴展了字段長度，重新采集日志岛琼，日志總量和數據庫中采集到的總量對上了底循。
Bug02:統(tǒng)計內容的播放時長，單個內容的播放時間記錄的是秒槐瑞，統(tǒng)計時換算到小時并用了四舍五入熙涤，導致最終每個產品包下的時長比實際播放時長多了十幾、上百個小時困檩。
四舍五入是不能隨便用的祠挫。
Bug03: order.log日志按某一content_code：53adeac62ce894f7f5471a81b2da5442查到記錄175條，研發(fā)統(tǒng)計結果只有126條悼沿。
對比日志發(fā)現有126條是series的等舔，49條vod的，但是一個內容就只有一個類型的糟趾，比如是電影慌植，就不會是連續(xù)劇，而訂購觸發(fā)是可以在連續(xù)劇上訂購义郑，也可以在某一子集上訂購蝶柿，所以會有vod類型過來，但統(tǒng)計的時候應該把這兩種情況統(tǒng)計到同一個內容中非驮。
這個問題我以為非常簡單好懂的交汤，但溝通的過程有點不順。
和研發(fā)溝通劫笙，他沒有明白蜻展，然后跟項目經理講了好一會兒他也沒有明白。
我對yz說：我生氣邀摆，我講的他們都不明白纵顾。
yz: 你跟我講，我去和項目經理說栋盹。
復述一遍問題施逾，yz聽懂了，然后她跟項目經理講通了例获，讓項目經理去跟研發(fā)說汉额。
今早研發(fā)說：content_type不一樣,code一樣算重復，所以特意過濾掉了榨汤，不進行統(tǒng)計蠕搜。
然后項目經理就沒有聲音了，我跟研發(fā)解釋：訂購時間不一樣收壕， code一樣 content_type 不一樣 不能算重復妓灌。
yz看到我不耐煩了轨蛤，盯著項目經理說：你能去和研發(fā)講清楚嗎？能嗎虫埂？你自己懂嗎祥山？
項目經理被逼著去溝通了，過一會兒收到研發(fā)跟我說：不區(qū)分content_type掉伏，只按code統(tǒng)計缝呕。
也發(fā)現了自己的一個Bug，為什么我能和yz合作斧散，不能和其他項目經理合作供常。
我和yz的合作模式：我發(fā)現問題，并告訴她問題鸡捐，她就會去安排栈暇，要不要處理，怎么處理闯参，什么樣的解決方案是合理的，她會有自己的判斷并把事情安排下去悲立。
我和其他項目經理：我發(fā)現問題鹿寨，并告訴他們問題，然后就沒有然后了薪夕。
我如果想要問題圓滿解決就得我自己去干-說服項目經理脚草、說服研發(fā)，而這不是我擅長的原献，也不是我樂意去做的馏慨。
Bug04:推薦時長-統(tǒng)計出來的時長和客戶大數據平臺統(tǒng)計的完全對不上，看了研發(fā)的程序發(fā)現很多情況都沒有考慮到姑隅，重新理的需求写隶。
