记一次改代码后本地正常,开发环境服务能启动,一个生产环境发布正常,另一个生产环境服务启动失败的事故(还好没杀程序员祭天)以警示

问题描述：这两天在工作中的两个项目优化一点同样写死的代码，大概是这样的↓

1203220171237629901和1203220171237629902是写死的，但其实可以通过Redis中动态获取，改完之后一个项目中本地测试跑main方法没问题，服务也能启动↓

另一个项目本地启动服务也能起来，不过有一些相关的报错↓

发布到线上后，服务启动失败，一个Service对象创建失败↓

子系统宕机10分钟，被运维人员吐槽，还好不是白天，要不然真是要杀程序员祭天了，扣绩效都是小事。

 

项目概况和环境：改动涉及到两个工程，都是Spring Boot项目，一个工程是用来定时跑任务的，一个工程是业务后台，跑任务的工程没用配置中心，跑业务后台的工程用了配置中心，配置中心这边有公共的配置文件application.yml，以及多个服务各个环境的配置文件↓

   

 

 

分析问题：

找到创建失败的Service，发现在static代码块有一句代码是通过RedisTemplate获取器的一个方法获取RedisTemplate对象，熟悉Spring的后端开发同学都知道Service对象会纳入Spring Bean管理，自动初始化，static代码块中的代码会随着初始化，此时就会获取RedisTemplate对象，而要获取Redis肯定要依赖配置文件的配置，代码也是这么写的↓

本地环境是dev，会去找application-dev.yml，本地也有这个文件，跑任务的工程发布到开发环境，此时环境也是dev，正常，发布到正式环境是prod，也正常。业务后台的工程当时没有发布到开发环境，直接发到线上去了，服务启动失败。我就很纳闷为什么同样的修改一个生产正常，一个生产事故，后来再仔细想了下，发现问题：跑任务的工程没有用配置中心，线上环境有各个环境对应的application-%s.yml文件并且有Redis配置，跑业务后台的工程用了配置中心，没有application-prod.yml文件导致报错。

 

心得：

1.要遵循发布流程，上生产的代码一定要先上测试环境通过测试

2.要求自己把控好质量关，开发环境一定要验证，而不仅仅只是单元测试或者跑main方法通过就行了

3.加强工作中的沟通，存在不确定时要询问主管或其他同事确认

欢迎各位大佬留言讨论。我还不想死呀，以后要更严谨。