项目推进风险、潜在风险梳理

  1. 1.核心组件更换
    1. 1.1.情况一:腾讯LBS更换到高德LBS
    2. 1.2.情况二:未形成统一的中间层
  2. 2.第三方系统对接
  3. 3.系统整合测试
  4. 4.正式环境部署
  5. 5.数据一致性问题

1.核心组件更换

系统原本使用的核心组件,因不可避免的客观原因更换。此类组件更换通常会导致以下情况:

额外的技术预研调整,组件更换有可能导致原本落地的技术组件失效,为了新的组件能够适配原有业务逻辑。这个一般看影响程度,通俗来讲是看原来开发的功能有多少个依赖项是依赖于这个核心组件

1.1.情况一:腾讯LBS更换到高德LBS

目前有个小程序+PC端,目前评估腾讯LBS主要带来的影响有:

管理 PC 端:所有涉及到腾讯LBS功能需要切换到高德LBS,高德LBS接口需要重新对接,接口对应关系需要重新映射,SDK jar包依赖需要重新调整。

微信小程序:wx.getLocation,wx.chooseLocation,wx.onLocationChange等接口均采用腾讯系适配的坐标系,因此地图底层逻辑与高德地图进行交互时,需要做额外的数据转换工作(虽然两者在国内都使用GCJ-02坐标系,但它们在坐标转换算法上可能有所不同,这可能会导致在不同地图服务之间进行坐标转换时出现一些偏差)。

有各自规范:此外两家地图厂商在地图POI点位的命名有各自的数据和规范,同样的点位 腾讯有 高德不一定有。

1.2.情况二:未形成统一的中间层

目前业务还在开发迭代阶段,若没有成标准或者行业生态的话,内部系统和外部系统对接的中间,还得隔一层中间件的,对这种差异做转化,内部系统尽可能维持他的原生态。后面中间件可能比较多,好处是若客户改的话,我们只改中间件就可以更灵活些。

目前对接的客户有部分已有成熟的系统,例如:A公司系统,但是我们再对接一个已有成熟系统的客户,例如:B公司系统。二者业务逻辑和系统差异较大,如果没有一个统一的中间件,一个系统能否包容这两个差异很大的客户?自身系统除了运行自身业务外,还要额外处理外部数据对接,难免会遇到算力问题,系统可能会遇到执行压力过大的情况。目前在体量还未成规模时,自身系统进行这种差异转化暂时没有什么风险。但是,业务体量一旦规模化后,将面临不小的技术风险,可能会涉及到不得不依赖于中间件,届时做组件更换会更加困难。

2.第三方系统对接

第三方业务系统对接,例如:A公司系统B公司系统等。

第三方支付系统对接,例如:支付宝银企直连等。

第三方服务对接,例如:短信平台e签宝爱签内部系统等。

以上对接至少是以周为单位,包含协调沟通、资源协调、测试联动、正式上线等工作,其中涉及与业务系统对接是最复杂且时间最长的。

3.系统整合测试

目前的排期以开发完成为节点,虽然排期上来看提前完成了开发工作,但这个节点标志着系统整合测试的开始,期间可能会遇到各种未知和未发现的问题,需要进行优化和处理。

4.正式环境部署

正式环境部署会遇到许多未知问题,比如网络问题、操作系统参数问题、环境安装和分配问题等。如果用户有更多必要环境要求,满足这些要求会花费更多时间。

5.数据一致性问题

项目上线初期,由于业务体量暂时不会太大,所以数据一致性问题出现的概率较小。但当业务规模扩大后,随着操作事务的增加,可能会出现未知的事务问题,导致脏数据产生。这些问题通常在前期难以发现。因此,一旦后续出现事务问题,系统将不可避免地需要进行补丁维护。