广发行外部数据整合应用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，        进行完善检查与测试。具体而言，首先针对各个依赖环境做检查，例如标准化数据是否已经进入了redis，有效期值是否已经下发，是否按约定的T-1下发。例如与第三方接口的网联链路是否已经接通。尽量做到无死角。

设计之初就应该全面思考测试场景。功能测试、边界测试、压力测试都编写用例并执行。

4，        维护依赖检查列表。对外部数据应用的整个链路抽象出一张依赖图。针对各个依赖环节所需要的技术检查点，逐一说明和记录。用于生产过程逐一检查。以往虽然做了技术检查，但因为没有列表和架构图，会有漏掉的情况。以后在开发过程中对架构的修正，如果存在依赖的地方，都维护到架构图和技术检查点列表中。

 

5，        维护问题解决方法列表。由于经常性、突发性地发生故障，开发者需要去生产环境差错，导致开发者情绪不稳，同时也延误开发的本职工作。如果能有专人专职，根据问题解决方法列表去查错，会更大限度的提高协调效率。

6，        为技术选型提供更高的自由度，为非业务功能提供更多时间，不断改进架构。例如，如果觉得ES在某些方面不合适，在已经合理科学的论证过，是否可以选择其他的数据存储。

 

检查点列表

犯错误不可怕，但如果犯的是低级错误，难道不觉得惋惜吗？

1，检查征信系统已经下发了有效期表。

2，检查有效期的值是正确维护的。曾因有效期值错误而使存储的数据有效期错误，变成脏数据。直接导致对ES修数。

3，检查标准化映射是最新规则。曾因为标准化规则变化但没有维护，导致存储的数据标准化操作错误。直接导致对ES修数。

4，检查标准化规则是否同步到redis。曾因为标准化映射没有同步到redis，导致存储的数据未进行标准化操作。直接导致对ES修数。

5，检查行内网联链路是否联通。

6，检查行外网联链路是否联通。因为第三方链路不通，导致整个链路查询异常，直接引起整个流程都报错。

7，检查云平台是否一直稳定运行。

8，检查卡夫卡是否正常运作。

9，检查mysql。曾因主从同步集群删除了一大批历史数据，而导致binlog一直在读写，导致IO线程和sql线程满负荷，从而主从失效。

10，检查ES实例节点的健康度。曾因ES某一个实力假死，导致查询一直报错：ES查询超时。