• 系统对接的沟通与协作


    在工作中,有时会有对接其他部门系统的需求,这种需求虽然不复杂,但是跨部门协作,往往会出现各种难以沟通、协调的情况。
    踩的坑多了,就记录下来。

    系统之间不要盲目对接

    系统之间对接时,最好不要盲目从中间系统接数据。
    下游系统,最好从生成数据的最上游系统去接数据,不要从中间系统去拿这些数据。
    中间系统往往会对数据进行加工,如果下游系统出现问题要排查非常困难,很难弄清到底是上游系统出问题,还是中间系统出问题。

    提前商量好系统对接的环境

    不一定所有的系统都会有灰度环境,也不是所有的系统都能在测试环境模拟真实数据。
    有些比较奇葩的系统,甚至测试环境是没数据的,直接在灰度环境测试。
    因此,提前商量好对接的环境挺重要的。

    商量好系统对接的方式

    是http接口,还是MQ消息队列,还是通过大数据平台的Hive、ETL对接等。

    必须排期

    排期包括:
    上游系统什么时候给下游系统,接口url、参数定义,或者MQ集群、消息主题,或者表结构、数据类型等设计细节。
    上下游系统什么时候在测试环境进行对接。
    上游系统什么时候上线功能。下游系统什么时候上线功能。
    上下游系统什么时候在灰度/生产环境进行对接。

    工作要留痕

    对接其他系统,最好双方都发邮件留痕。后续出现问题,才能弄清楚到底是哪个系统,在哪些环节出现问题。
    对接的系统甩锅时,我方系统还能留有证据。

    汇报进度

    如果是特别特别重要的功能,可以每天/每周进行汇报。
    跟上级领导汇报系统对接的进度。
    跟对接系统的负责人沟通进度。

    及时跟进

    如果系统对接方没有在对应日期给出设计,或者是功能没有在承诺的日期上线。
    要及时去跟进,去了解原因,看到底是在哪个环节阻塞了。
    先发消息,紧急的就打电话,电话打不通就直接现场找人,当面沟通。

    重要的功能必须打日志

    打印日志,出现问题,方便排查。
    哪怕不是己方系统的问题,也能把日志相关的参数、时间等重要信息发给系统对接方查看问题。

    解决问题

    系统对接方出现问题,如果对方迟迟解决不了,那就得升级问题。
    可以让对方系统的高级开发去帮忙解决。
    实在没有人力,也可以自己去解决。
    曾经在对接一个系统时,对方有个bug一直解决不了,直接让他共享屏幕,两个人一起定位解决了。
    再不行就跟双方领导汇报,让领导找人,给资源。

    下游系统得做兜底

    作为下游系统,永远都不知道上游系统会传什么样的数据过来。
    可能之前约定好了某个字段是数字类型,上游系统莫名奇妙就发个英文字母或者日期过来。
    因此,下游系统得兜底,做好异常处理,处理掉异常数据、脏数据。

    可以让上游系统给demo示例

    曾经对接过某个系统,给出的接口调不通,明明都是按照文档上的来,怎么都调不通。
    最后要求上游系统给出相关的demo示例。才发现文档是旧的,跟实际不相符。

    记录对接的系统及联系人

    如果一个系统对接了多个系统,最好记录下对接的系统及联系人。
    如果系统的数据比较复杂,也最好把各个功能模块的数据源记录下来,防止人员变动后无法接手。

    上游有变动,及时通知下游

    作为上游系统,不能直接变更系统对接的接口url、参数、字段类型,或者是集群ip,消息主题等信息。
    在变更之前,必须及时通知下游系统,并商议好是否变更,如果确定变更,给出变更日期。

  • 相关阅读:
    搜索框练习
    左侧菜单练习
    Maven Assembly插件介
    (总结)Nginx配置文件nginx.conf中文详解
    nginx、php-fpm、mysql用户权限解析
    全文检索引擎Solr的配置
    解决Discuz安装时报错“该函数需要 php.ini 中 allow_url_fopen 选项开启…”
    solr添加多个core
    精品站
    Win7下IIS的安装与配置
  • 原文地址:https://www.cnblogs.com/expiator/p/16631366.html
Copyright © 2020-2023  润新知