加班记(二)

Posted by 咖啡不苦 on September 6, 2015

今天又去公司处理了一个线上问题:我们依赖的一个接口可用率为0了!

故事大概是这样的:我们依赖的一个写接口,最早主键是int类型的。虽然我们的sequence工具生成的是long型的数,但是为了“适应”接口就强转成int后再调用接口了。某一天,接口提供方意识到用int类型做为主键,随着业务发展很可能突破上限而造成麻烦。于是接口提供方将入参类型改成了long。于是我们的某位码农又将int强转成long给了接口!今天,就在今天。终于这个sequence的值超过了21亿+,就是有符号整形的最大值。然后将这个值强转成int后(其实是个负数)。用这个负数去调接口,然后就都out of range了。然后就没有然后了。

解决的办法当然是将“画蛇添足”的程序逻辑修正。去掉long->int->long的过程,另外也发现数据库的字段类型是int(10),顺手改成了bigint(20)。一切妥当后,可用率恢复。

现在回过头来复盘,发现可以改进甚至避免这场“灾难”的地方太多了。

在最初期,需要调用一个以int作为主键的接口时应该就是最好的避免灾难的时刻。这个时候如果调用方(我们)能提出疑问并协调修改的话。应该就不会有后面的事儿了。一方面,说明我们有业务主键类型最好别用int的意识。另一方面,又说明我们可能有“各人自扫门前雪,莫管他人瓦上霜”的坏毛病。或者,这可能是由于“跨部门合作太难了”之类的借口。但那真的是借口。更多的是自己的懒惰,不愿意推动罢了。

然后是当接口提供方意识到问题,将入参类型进行了调整之后。我们的做法居然又是在入口做了一次强转!这几乎是一个不能容忍的低级错误!至于解决方案,除了强调,宣贯,恐怕就只能招有更好的习惯的人了,(当然,招人带来的其他一系列问题不在今天的讨论范围内)

再然后是为什么我要跑到公司去处理这个问题。还好我去公司还算方便,十几分钟车程便到。但作为一个码农,这种工作方式还是挺丢人的。我的借口是公司的vpn难用,难申请。自己找的小软件又关键时刻掉链子。擦,这些都是借口好吗。回去上班第一件事儿就先把vpn申请下来吧!

最后又是一个鄙视自己的地方了。都不好意思在这说,我改完代码,预发验证,通过,上正式,遗憾的是期待的可用率飙升并没有到来。百思不得其解之际down了一下刚上线的包。纳尼,竟然没有我刚改的代码!wtf,在git里只commit而没有push就build线上包了!好吧,自己面壁去了。