记一次简单的小修改引发的大问题

      很多公司的产品应该都有登录token失效的这个机制，简单来说就是超过预订时间后将token置为失效状态，需要用户重新进行登录，这样可以提高一定的安全性。同样，我们公司的产品也有这个机制，而前天发生的一件线上事故就是基于这个设定发生的！

      惯例先交代下背景。发生问题的App属于公司内部使用，原本设置的token失效时间是7天，也就是一周。但领导觉得这个时间还是有点儿短了，反正是自己人用，可以设置的长一些，于是口头通知相关开发：将这个时间改为30天。

      很简单的一件事，代码改动就1行，将原来的7天改为30天就OK了。于是接到这个通知后（太简单了，不算需求）开发马上就实施起来。改完后想着，这个之前也改过两次都没啥问题，这次肯定也没问题。于是就直接联系相关人员进行上线了。但恰恰这次改动后就发生问题了。

      上线不久后就陆续收到同事反馈，App登陆后会直接退出，提示token失效，已经无法使用了。所有人知道这个消息后都意识到刚才的修改上线有问题，于是先急忙改回原来的7天时间，然后开始逐一排查问题。那么问题在哪儿呢？首先改动很小，而且之前也有过类似的改动，为什么这次就出现问题了呢？开发一番查找后终于定位了问题：原来过期时间采用的是时间戳，单位为毫秒，30天的过期时间总共为30 * 24 * 60 * 60 * 1000 = 2592000000ms，这个数字超过整型int的范围，导致转换以后出现负数，再和当前时间相加，相当于当前时间往前移了，所以导致token失效。

      这件事，给了我一些警示：

1. 首先，针对任何一次修改都不应该轻视。往往很小的改动就会引发大问题，切记切记，不要败给自己的惰性（好在这次修改是在晚上10点多，而且是公司内部产品，所以影响到的人员不算太多）
2. 这件事如果在测试环境先进行下测试，那么我想一次简单的登录退出就会发现问题。这就暴露出了流程上的缺失，完善的流程也是一种有效的质量保障手段。