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