请问汇报前同事工作上的问题的技巧

我一同事去年底离职，他手上的project交给我，当时说是已经差不多做完了，QA已经
做完了大部分测试，我只要fix bugs就可以了。他级别比我高，我肯定不会review他的
code了。

我觉得他的cdoe很奇怪，尽管我有疑问，但不管怎么地，他的code还是能运行的，功能
似乎都实现了。于是我也只管fix bugs，2星期前这个项目终于上production了。

上了之后，一系列的问题，原因不在我啦，QA也没有测试出来，交叉的project也要修
改。这样紧张了2个星期，似乎问题都解决了，用户也比较安静了。我们老板和BA总是
松了口气。

但是我从log里看，其实这个project还是有问题的，random exception，用户重新运行一下，问题就没了，我也无法re-produce这些问题。我第一感觉是这个项目的结构有问题，前同事做这个项目的时候，因为我们都用spring framework做，他从来没用过，简单看了一下我的code，就照葫芦画瓢，画得四不像，我的直觉是这个项目的
configuration不对，导致了data source connection间断地出问题。因为这个牵涉到
结构调整，动作比较大，所以我和我们公司另一组做spring比较厉害的人交流了一下，他的意见也是和我一样。现在我们都不保证这个修改可以解决那些随机的错误，但是这个结构调整是第一步我们能做的。我90%相信就是这个原因导致的。

现在我该只汇报给我老板还是连BA一起报，把这个问题往大里说还是小里说，我觉得结构性的问题还是大问题的。老板搞技术出身，是比较求精的人，如果他知道有潜在的问题，他会想要解决的。BA不懂技术，是一个求粗的人，有问题能捂就捂，她肯定不愿意自己这个项目一上马就这个那个的问题。这个问题我估计BA会捂，因为用户就算遇到这类随机错误，重新运行一下就行了，又不是根本运行不了。

我很烦给别人收烂摊子，弄不好，自己背黑锅。但没办法，真要改也可以，但我希望他们意识到这个改动很大，让我有足够的时间做，所以把问题说大？但是不是这样有点背后说前同事坏话的嫌疑？