记一次一个枚举引发线上事故风暴
背景
在2018年8月15号下午6点左右突然有一个调用我们服务的业务方告知我们大量调用出现异常失败或超时,并不停的出现一个未设置结束日志的错误。
问题定位
收到相关的信息后,我立即展开问题排查
1、通过服务管理平台查看业务是否出现超时情况以及对比今天和昨天问题接口整体的响应时间,排查后没有发现任何异常。
2、查看日志是否出现不可知的异常,但是显示结果一切正常
3、我有根据业务方提供的返回错误日志然后全局搜可能出现的地方,我发现这个返回枚举值除了添加接口引用无其他接口引用,此时我就非常纳闷怎么就一个永远不会返回这个错误信息的接口出现了这个错误信息
4、通过上面的情况我想是不是枚举填充错位或者被攻击了,为了证明猜想我本地开启一个程序调用线上服务,发现返回的结果值是正确的,此时更迷茫了到底是一个什么异常呢,然后在次让招聘他们调用服务,但是他们一调用那个错误立即出现
5、当时这个问题我们已经连续排查第二天的凌晨依然得不到结果,最后想万能的重启试试,也可能是某个内存出问题了,我们重启了其中2台机器,并将这两台分组给调用方,结果调用方正常了,正当说要先准备回家睡觉然后在继续追踪问题发现诡异的问题有出息了,重启解决不了.
6、然后一个同事不经意说是不是有人篡改了枚举值,我们恍然大悟,立即看这个枚举是否能被set,果不其然有一个public的set值,然后我们搜索项目中有一个接口分支调用了这个set值
7、问题基本都已经定位完毕,引发这个bug是同事在6点刚好上线,他们在添加时候没有传入日期导致了bug被复现
解决方案
我们删除了set这段代码,然后采用返回实体,线下验证正常后进行上线,上线后问题业务方的调用恢复正常。
后续规避
1、定义部门中的相关规划(如禁止枚举开放set值)
2、加强代码review,重要的项目保证2个人同时开发,避免问题的产生