在工作中，有时会有对接其他部门系统的需求，这种需求虽然不复杂，但是跨部门协作，往往会出现各种难以沟通、协调的情况。
踩的坑多了，就记录下来。
系统之间不要盲目对接
系统之间对接时，最好不要盲目从中间系统接数据。
下游系统，最好从生成数据的最上游系统去接数据，不要从中间系统去拿这些数据。
中间系统往往会对数据进行加工，如果下游系统出现问题要排查非常困难，很难弄清到底是上游系统出问题，还是中间系统出问题。
提前商量好系统对接的环境
不一定所有的系统都会有灰度环境，也不是所有的系统都能在测试环境模拟真实数据。
有些比较奇葩的系统，甚至测试环境是没数据的，直接在灰度环境测试。
因此，提前商量好对接的环境挺重要的。
商量好系统对接的方式
是http接口，还是MQ消息队列，还是通过大数据平台的Hive、ETL对接等。
必须排期
排期包括：
上游系统什么时候给下游系统，接口url、参数定义，或者MQ集群、消息主题，或者表结构、数据类型等设计细节。
上下游系统什么时候在测试环境进行对接。
上游系统什么时候上线功能。下游系统什么时候上线功能。
上下游系统什么时候在灰度/生产环境进行对接。
工作要留痕
对接其他系统，最好双方都发邮件留痕。后续出现问题，才能弄清楚到底是哪个系统，在哪些环节出现问题。
对接的系统甩锅时，我方系统还能留有证据。
汇报进度
如果是特别特别重要的功能，可以每天/每周进行汇报。
跟上级领导汇报系统对接的进度。
跟对接系统的负责人沟通进度。
及时跟进
如果系统对接方没有在对应日期给出设计，或者是功能没有在承诺的日期上线。
要及时去跟进，去了解原因，看到底是在哪个环节阻塞了。
先发消息，紧急的就打电话，电话打不通就直接现场找人，当面沟通。
重要的功能必须打日志
打印日志，出现问题，方便排查。
哪怕不是己方系统的问题，也能把日志相关的参数、时间等重要信息发给系统对接方查看问题。
解决问题
系统对接方出现问题，如果对方迟迟解决不了，那就得升级问题。
可以让对方系统的高级开发去帮忙解决。
实在没有人力，也可以自己去解决。
曾经在对接一个系统时，对方有个bug一直解决不了，直接让他共享屏幕，两个人一起定位解决了。
再不行就跟双方领导汇报，让领导找人，给资源。
下游系统得做兜底
作为下游系统，永远都不知道上游系统会传什么样的数据过来。
可能之前约定好了某个字段是数字类型，上游系统莫名奇妙就发个英文字母或者日期过来。
因此，下游系统得兜底，做好异常处理，处理掉异常数据、脏数据。
可以让上游系统给demo示例
曾经对接过某个系统，给出的接口调不通，明明都是按照文档上的来，怎么都调不通。
最后要求上游系统给出相关的demo示例。才发现文档是旧的，跟实际不相符。
记录对接的系统及联系人
如果一个系统对接了多个系统，最好记录下对接的系统及联系人。
如果系统的数据比较复杂，也最好把各个功能模块的数据源记录下来，防止人员变动后无法接手。
上游有变动，及时通知下游
作为上游系统，不能直接变更系统对接的接口url、参数、字段类型，或者是集群ip，消息主题等信息。
在变更之前，必须及时通知下游系统，并商议好是否变更，如果确定变更，给出变更日期。
标签：上游,沟通,对接,系统,问题,协作,下游,数据 来源： https://www.cnblogs.com/expiator/p/16631366.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。