记录一次数据表丢失数据的修复过程

背景：

近期做了一个话务管理的功能，就是调用大唐电信的接口完成与客户的电话沟通，并将通话信息记录在数据表中。该功能已经上线了两个多月，一直正常运行，但是前天我自己在查询生产数据时发现了一个问题：我们的通话记录中很多字段的值都为null。而这些字段应该是在挂断电话时大唐回调我们的接口更新到我们的数据表中的，所以一开始我怀疑大唐在某些情况下挂断电话是不走回调的，就与大唐的同事沟通，他们的反馈是任何情况下的电话挂断都会回调我们的接口。按说此时我本应该意识到是我们的接口在更新数据时出现了问题，但我竟然没有第一时间去测试我们的接口，而是继续忙其他的事情，直到一天后其他部门的同事反应电话打通之后没有获取到通话记录，此时我才开始测试自己的接口，发现是大唐在回调我们的接口时某个字段的值变长了，我们的数据表的长度不足以存储变长后的数据导致在UPDATE时失败了。关于此，我应该做自我检讨：

1、遇到生产问题时的敏感度不够强，既然是生产问题，就应该第一时间解决，不应该在发现了问题还置之不理，因为生产问题是最重要的问题，很可能造成严重的事故；

2、在遇到问题时应该首先考虑是不是自己的问题并进行测试，在测试完之后再决定是应该修正自己还是去询问别人，而不应该首先考虑或许是别人的问题，就像这一次我应该首先测试一下自己的接口，这样也可以避免一些无效的沟通，当然这次大唐修改接口的返回值没有知会我方也有点不地道；

3、就是自己写的代码的问题：不要盲目的相信自己，任何人的代码都有可能在不同的时间点出现问题，所以要记得把代码中可能出现异常的地方给出前台提示或打印后台日志，方便进行跟踪，尤其是在SQL的INSERT和UPDATE操作的时候，还有就是在try...catch...的时候要注意将捕获的异常信息进行打印，或者给前台提示，或者再抛出，而不要捕获到异常之后什么都不做；

目的：

将大唐的数据恢复至我们的系统数据表中；

过程：

首先，我联系大唐的同事将5号和6号的全部通话记录数据拿到(只有这两天的数据有问题)，发现他们的数据比我们多出了200多条，而且数据的时间有偏差。

我开始觉得该数据是无法修复的，因为在插入通话记录时(我们的通话记录是在振铃时插入表中的，在电话挂断时大唐回调我们的接口将通话的具体信息更新至我们的表中)没有将任何与大唐直接关联的字段插入表中，这就导致了我们无法根据任何一个字段与大唐的数据进行关联，只能根据数据产生的时间，但我们记录的时间和大唐记录的时间又不一致，数据量也不一致。这该如何是好？我忽略了一点(我的小组长的功劳)：我在插入数据时是有这条数据的所有者(我们的系统用户ID)的，而我们的坐席(大唐提供的坐席)配置是与此ID关联的，这样终于找到了我们和大唐之间的关联关系，剩下的任务就是怎么匹配数据的问题了。

思路：建立临时表，将大唐的数据导入临时表中；剔除大唐多出来的数据，然后根据坐席组内排序匹配数据；

1、每个坐席在同一个时间点只能有一次通话，因此可以将我司的数据和大唐的数据分别根据坐席进行分组，并统计每个坐席的通话数量，找出是哪些坐席出现的数据量上的偏差；

2、检查双方通话数量相等的坐席是否有电话呼入，因为我们是以电话呼出来初始化坐席的，所以这些通话数量相同的坐席应该保证没有电话呼入；

3、对于通话数量不相同的坐席：若我们的数据偏多时应该是有呼入，我们的数据偏少时则认为是大唐的数据有问题——以我方的数据为准；

4、剔除多余数据，将双方坐席通话数量不同的坐席择出，并根据时间排序和依据时间比对，时间相差较大的视为无效数据，并将大唐的数据置为失效状态；

5、删除所有失效状态的数据，再次进行组内排序，根据时间排序将大唐的数据插入到我们的数据表中

心得：

1、端正自己的工作态度，要对遇到的问题敏感；

2、解决问题时，不要首先觉得不可能，这会打压自己解决问题的积极性，没有什么是不可能的；首先应该认真寻找解决问题的突破口，不放过任何一个细节，将解决问题的资源关联起来，就算是不可能也应该在努力尝试之后；