项目概况：一个war包，部署了到两个服务，一个是商家店铺装修服务，一个是用户浏览商家店铺服务。

发布内容：1、依赖的第三方接口，由于性能问题，发布了新版dubbo接口。本方做了相应的修改；

              2、修复原spring quartz定时任务基于数据库的单点控制代码bug；

发布后线上表现：先发布装修服务，发布后，服务正常。再发布浏览服务，发布后，服务未正常启动。结果：浏览服务异常，url访问报502错误；dubbo接口注册失败，客户端不停尝试重新注册，注册中心监控到大量高频率的注册行为，紧急联系我方停止服务；

结果：1、浏览服务不能正常访问，主客户端、m站的pop店铺首页均不能正常访问，持续约1小时；2、未发生的最坏结果，大量高频度saf注册行为导致注册中心服务问题，继而影响公司所有依赖了注册中心的服务，基本编辑公司所有的应用；

紧急措施：1、停止浏览服务；2，回滚浏览服务到07-31版本；

问题原因：浏览服务的负载较大，故规划上，定时任务只在装修服务运行，通过spring quartz的定时表达式控制任务在浏览服务上永不执行。spring quartz如果配置定时任务永不执行，在启动的时候会报错，导致应用启动异常。继而出现问题。

测试阶段未发现问题原因：下午新同事提交错了代码，测试重点放到代码回滚后的功能测试上去。只自测了正常执行表达式，未对永不执行的定时表达式进行自测。

后续：1、严格执行自测流程。开发自测应放到非常重要的位置，开发人员对功能实现的逻辑最为清楚，是最好的测试人员，自测是保证功能非常重要的环节。

2、提升测试人员的测试能力。人都有思维盲区，通过其他人的测试，可以佐证功能实现方案，弥补思维盲区；

3、严格执行封包时间点的规定，所有功能必须在上线前的某个时间点测试完成。宁愿延迟上线，也不能发生线上错误；

建议：1、saf注册中心作为一个非常重要的服务，需要由极高可靠性，要考虑应对可能发生的各种极端的业务场景，如当期这种大批量高频度的重试请求；

2、公司f5监测应用可用性，是通过监听对应端口是否存活实现。在实际应用中，端口正常打开不代表服务正常启动，因为这个问题，我已经踩了几次坑了，自动部署系统在重启服务时，由于端口在某些情况下未kill掉，导致应用启动失败，但端口是打开的，故用户请求被分配到此未正常启动实例时，会出现502错误。建议通过监测应用页面是否正常，来监测服务的可用性。