嗯，问题是这样的，一个月前，我负责的一个项目新版本上线，驻地说某个接口的参数为空，是Bug，然后回滚了版本。耗费很久也无法在那个版本的代码上复现驻地描述的问题，结果季度的绩效因此降低，算了下少说要损失千把块工资，很生气，但因为定位不出问题，只能吃这个哑巴亏。
今天，新版本上线前，测试妹子发现上个月的问题依旧存在，我索性让她不要根据用户id看结果，看看之前有没有同类问题，一查，发现有，还不少。
草！很明显这就不是和我项目版本有关的问题。一路定位下去，发现是一个接口，有两个模块发送给了两个服务器，其中模块A发的是错误的数据，B发的是正确的数据，由于二者是竞争关系，而又几乎是同时发送，所以就会有概率出现错误数据记录的情况。于是就出现了文章开头描述的情景。
至此，问题定位的清清楚楚，根源也搞清楚了，难以释怀的还是绩效因此被减，这个项目，已经额外优化了很多细节，理清了各种复杂逻辑，结果因为非自己的问题而被减少绩效分值，就很窝火。
罢了罢了，如果实在说问题，那还是我的问题，没有把七八年没变动的这个接口增加参数强校验才造成错误的数据被录入系统。不要在意短期收益，眼光放长远，拉长时间线，就这样说服自己好了。
过去的自己，几乎不在绩效上留意过多，有了娃后被老婆教育多了，明白绩效是实打实的钱，所以才会有这篇博文表达下难以释怀的情绪。写完了，也就过去了。
无论任何时候都不要相信上游，是这个历时一个月的问题给我带来最大的收获。去你妹的上游，傻蛋玩意儿，乌合之众。
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。
现在很多时候就是背锅，真的是背锅侠，为什么？凭什么，就是因为上面的人怕自己背锅，甩给下面人接着，而且很多时候是外行指导内行，做的很不顺心，明知道问题所在，但是也改变不了什么。