昨天遇到了一件感触很深的事情,把一个不是问题的问题当成问题认真严肃地对待了一个下午,甚至到晚上七点半才"解决",用一句歌词来表达我明白怎么回事儿时候的心情就是——最后知道真相的我,眼泪流下来!
随后,在朋友圈发了一个状态——被坑的有点惨,还是*哥靠谱,go(回家)。(*哥是同事C)
为什么说被坑呢?首先,我能够百分之一万的确定,我的修改和出现的问题一毛钱关系都没有,我只是在精简参数,而必须的参数以及取值都没变,可选的参数及取值更是无关紧要。其次,修改完调试,发现出了问题,于是我以极其虔诚认真的态度在解决一个问题,不了解真相之前我确实把它当成问题的。
为什么说有点惨呢?其实有点夸张了一下,今天周五本应该早点下班回家的,而且更是答应了老婆早点回家,结果没有,心里不舒服。
最初遇到这个问题时,我就按照通常的思路去分析日志和定位代码。这个问题的表现很简单,调用基础服务ECS的REST API,返回的错误信息说"the flavoerID xxx not found"(找不到),基本上就是调用基础服务时ECS镜像ID用错了。于是我就去配置文件中查找另外一个ID,换了之后发现这个ID连前台检查都通不过,接着又看了一通,这个流程前后看了一遍,以前这个地方都没有出过问题,因此显然这个ID更是不对,于是又确认了一遍测试给我的自动化脚本中的镜像规格ID,又换回去。这个最初的规格ID对应的问题自然不会消失,于是我就开始怀疑了,是不是基础服务ECS的问题,或者是OPENSTACK的Glangce出了数据损坏或者丢失,导致这个原本应该存在的镜像规格ID不见了??
为什么第一次遇到问题时没有这样怀疑呢,因为这个是类生产环境,从整个框架部署调通后一直稳定运行(不像beta环境,用的物理机东拼西凑,各个服务老是停工拒绝服务),从来没有过"乱七八糟"的问题,不太有理由让我首先怀疑这里。既然怀疑是基础服务的锅(背锅的锅,后来笑哭),接下来就去找团队的同事C对此事,问我们能不能查基础服务的镜像服务,看看到底有没有这个规格ID,同事C说我们没有xxx的权限,需要找到对应的管理员才能查看,而彼时已经是周五的晚上七点了,意味着大部分人都早点下班回家了。
怎么办?人找不到,第二天周末,这个问题不解决,一直到周一都感觉是个事儿(会别扭)。
于是回到工位,前前后后又下发几次创建,看了几遍日志和代码,问题依旧。
办公上的玩具沙漏,漏了几个回合。
此时已经无计可施,发现同事C还没有走,就又过去了解一下创建VM时这个镜像规格ID的使用情况(我们服务使用的镜像是同事C制作并上传到镜像服务的)。我们一起看了初始配置文件中的规格ID,以及我创建时使用的规格ID,配置文件中规格ID不止一个,我用的默认的那个,在数据库resspec表中也有这条记录,初步看起来也没啥异常。
于是进一步查看,同事C说,配置文件和resspec表中有记录还不行,其实还有一处需要修改,就是104。
实际上除了上面两处记录,还有一个resspecattr的数据库表,这三个地方有一个共同的属性,就是规格ID,第二个数据库表还有另外一个字段,这个字段的值必须是104才行,是104传给ECS它才认可这个规格ID真正有效。
而我最信任,最没有任何一丁点儿怀疑,使用的出问题的规格ID,所在表格记录中相应字段的值不是104。
真相终于水落石出。
此处省略一大段,有些事情不适合发出来(毕竟只能对事不对人)。。。
这件事情对我触动很大,周末的早晨竟然睡不着,还在想着这个事儿,原谅我经历这类的事情少,毕竟它没有对得起周五下午的时间。
因为真相和104有关,我把它称为个人职业生涯历史上的104事件(一般国际大事用发生的时间来表示该事件,这里的104不是指时间,而是一个还原真相的值)。
最后,我该信任谁呢?!或者该信任什么呢?!