今天又去公司处理了一个线上问题：我们依赖的一个接口可用率为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线上包了！好吧，自己面壁去了。
