广发行外部数据整合应用7月投产问题及应对方案

7月投产问题及应对方案

投产过程常常受到重视。投产时间紧迫不应该也不允许产生错误。如果产生故障就会受到各方的巨大压力。这种情况下必须重视因低级错误或疏忽导致的生产故障。

问题列表及分析

情况汇总

 

1，投产过程受到云平台不稳定、设置参数不明确等因素影响，而拖延了投产时间、甚至中断，内存溢出并且保错等。

2，由于负责数据处理的同事的疏忽，没有进行生产主键的逻辑进行校验，导致Es的ID没有按原来的约定生成。在脚本跑了很久时发现，导致第一次修数失败，所有数据被废弃。

3，因负责标准化映射规则的同事没有及时更新映射规则，导致批量同步的数据转换出错。由于标准化规则没按T-1的规律下发，导致程序无法读取到T-1文件夹。直接导致程序报错。

4，因第三方网络不通，导致外发报错，批量外发报错。这个原因耽搁了3天。

5，ES其中一个节点实例假死，导致ES查询超时。

6，mysql因binlog而导致主从集群失效

应对方案

1，        微服务基础应用部署于虚拟机。因为云平台不稳定，把微服务基础部件迁出云平台和docker，在虚拟机上部署。基础应用有API-Gateway，注册中心、配置服务。

2，        开发、测试环境与生产环境尽可能保持一致。在开发环境上建设与生产环境一致的数据库集群以及数据下发机制。其中一个是mysql主从同步集群，另一个是标准化表和有效期值的下发方式和周期。这次的投产就是因为标准化表没有同步进入redis和有效期表T-1的更新方式导致数据不对，而导致修数。

3，        进行完善检查与测试。具体而言，首先针对各个依赖环境做检查，例如标