某项目接口任务失败的原因总结

昨天听某位同事说，他所负责的某个项目，由于当天凌晨接口任务运行失败，导致接口表无数据，客户没有取到数据，被客户投诉。。。

这个失败的接口任务，主要是从一个业务表里取数，然后插入到接口表，整个接口任务运行结束，逻辑非常简单。

他问开发，为什么任务会失败，得到的答复是：uat环境中接口表某个字段长度是50，而正式环境中接口表某个字段的长度是100，由于之前一直是在uat环境上测试，也没问题，前天把接口移到正式上后，就因为正式环境中，这个字段的实际数据长度超过了50，导致插入时溢出了，所以报错，任务失败

。

这个问题是表结构不一致导致的，针对这个问题，大致上有4个解决方案：

（1）在开发新接口时，确保uat环境上的数据库，是用正式环境最新备份还原的。

就这个例子来说，客户uat环境的服务器硬盘很小，放不下正式环境的数据库

（硬盘小于300G，不知道客户的服务器是从哪里找的

，不知道的还以为是从二手市场收购的。。。，实际情况可能是虚拟机中给分配的硬盘太小了）。
这种情况下，只能和客户说明情况，强调环境一致的重要性，采购新硬盘，或者给虚拟机调大硬盘空间。

上面的情节，听上去好假，像是编的，如有雷同实属巧合。

（2）对数据库的ddl操作，都要记录下来

可以在uat环境，运行记录下来的ddl日志，这样就能保证表结构一致。
不过这个需要基于公司的制度，记录人和执行人分开，采用记录ddl日志+dba执行ddl日志，要执行任何ddl代码，只能先记录在日志文件，然后提交给dba执行。

（3）仔细检查表结构是否正常，或者在正是环境试运行接口

如果上面2个都实现不了，要么在部署的时候仔细检查字段，看是否一致。
要么在正式环境部署好后，创建临时接口表（表结构一致），然后试运行接口任务，看是否正常。

（4）增加监控
一旦运行失败，就能及时发现，运维介入处理，如果处理不了及时转给开发处理，更早的发现问题、解决问题。