和一个外包开发团队的对接经历：一次推送错误的排查记录

最近和一个外包开发团队对接，发生了不少让人头大的事情。今天实在忍不住，想把其中一件事记录下来，算是个小小的吐槽，也顺便复盘一下整个过程。

我们和 JG 企业有合作，他们是做影像系统的，我们负责提供底层系统支持，对接的是他们的外包团队。我们的角色是乙方，他们是丙方，除了开发工作，他们也协助我们做部分实施。

整体印象

刚开始接触的时候，外包团队给我的第一印象并不太好：

• 开发经验看起来偏少
• 沟通方式比较直接，甚至有些生硬
• 系统一出问题就直接 @ 我，连个背景说明都没有

刚开始开发接口那阵子，每天早上还会来催进度。有一次去客户现场，对方还直接告诉我要 “8 点 30 之前到”，语气挺强硬的。

其实这个事情完全可以灵活处理，只需要提前和客户沟通一下，在门口打个电话就能进去。虽然都是小事，但当这样的沟通方式频繁发生的时候，确实会让人感觉压力比较大。

第一个问题：推送报错排查

我负责的工作其实比较简单，就是：

定时将订单信息推送到他们的系统，他们生成在线浏览页面。
所以这部分是用定时任务跑的，需要做 增量推送。

有一天，对方在现场切换了一个环境，然后就发消息给我说推送失败了。

对话过程（第一天）

他：
老师，有个报错，还需要您那边看一下。

（发来一张截图，日志里显示的大体报错是 “找不到推送表”）

我：
这个好像不是代码的问题，更像是没有那个表？

他：
有这个表。

我：
那你把具体的错误信息发一下。

他：
我拍照给你。

我：
能不能把完整日志发一下，尤其是你截图那个地方。

（他发了完整的日志，确实是查不到表）

我：
这个报错其实很明确，是在查一个叫 SYNCDATE 的表，这段代码一直没变过，之前也没出过问题。
你确认一下当前环境连的是哪个数据库？

他：
连的是这个库。

于是我发了段代码截图，解释逻辑：要么没表，要么连错库了，catch 里也没特殊处理，理论上不会报错。

他：
我这边换了一个环境就可以推送成功了。

第二天继续：重复追问

这是第一天晚上 7 点的事，我本以为已经结束了，结果 第二天一早又来了：

他：
老师，昨天那个推送错误还是想确认一下怎么解决。

我：
我这边看代码没问题。你可以试试把表删掉再跑一遍看看。
（我还引用了昨天的代码截图）

他：
怎么删表？我还没删过表……

（还打了电话过来，我没接。心里多少有点担心他真去误删库）

他：
我用 SQL 把数据删除了，还是报错。

我：
你用的是 DELETE 吧，那只是删了数据，表还在啊……

他：
不能用吗？

他：
我没重建表，报错还是一样。

（继续发日志）

我：
这个报错就是 “找不到表”。

他：
那我再建一下表。

我：
建好后，用 小写表名 查一下，有些 DM 数据库是大小写敏感的。

他：
好。

他：
我用了小写，还是这个错。

我：
那你能查出这个表的数据吗？

他：
可以查出来。 9:28
我：
我感觉你就是 连错库 了吧。

9:40 他：
我刚问了一下，确实是连错数据库了……

我：
行，确认就好。

其实在一开始我就怀疑他连错库了，但他当时非常坚定地说“没有”，我也不好直接下结论。只是没想到这事绕了一大圈，最后还是库连错了，但是真的也花了我好长时间，主要是也真生气，我觉得一个开发也不能这样吧，特别还不是我们的开发，我都怀疑他们领导把他扔过来让我带来的。。而且他这样不是一次两次了，每次都言之凿凿的说自己这边没问题，然后就让我排查，排查完了发现就是他的问题。。。 下午发一下第二件事，第二件事让我今天上午气够呛。