婚后第一个white day，却被工作羁绊住了脚步。
历时一年的模板改版终于要上线了！！！ 2周前PM欢天喜地的宣布了他的工作成果，虽然此模块改版的后端是由我个人独立完成的，但是经历了去年十一的二次大改版，去年双十一双十二的两次跳票。早已把业务逻辑完全抛在了脑后。
而甲方在模块改版过程中也经历了两次领导层大换血，新来的领导完全推翻老人的设计，而这个项目居然是我们公司的AC“送”给甲方的，导致甲方在改版时肆无忌惮，业务逻辑变了又变，也许到现在，除了乙方当事人一些隐约的记忆和甲方不肯认领的晦涩的历史邮件，已经没人能理清了。
昨天，组长把投产时间放在上午十点半。我九点多到了办公室，按照事先整理好的流程：
- 先把FTP上的文件存到本地一份打包。
- 又合并了一次代码，并将新合并的代码与昨天测试时合并的代码进行了比对，无差。
- 再从数据库里导出了需要变更的数据，编辑好sql，提交svn，等待十点半。
时间转瞬即逝，十点半...
我先上传图片，同名跳过。再将要提交的代码放到队列中。
接着让组长按顺序运行sql。我同步提交代码，清runtime。前端同事清cdn。
开始测试
首先发现了一张表的数据没有同步过来，于是赶紧上测试数据库导出数据整理成sql让组长运行。
却发现同是那张表中的数据出错了，又赶紧整理出sql进行还原。原来是PM在更改测试数据时，只更改了表中一半的内容（和没改的内容差不多一半一半），幸好该表及其子表内容不多，赶紧诚恳的请求PM把剩下的一半改全了。【测试时没有和PM理清需要更改的地方，导致双方沟通有误。】
接着发现在访问网页时，时常会出现“无法加载模块：XXX”的问题，由ThinkPHP定位到/Common/function.php LINE:112。开始查错。
之后夹杂着一些测试时没有测到的小问题，均及时解决。【其实那些问题在进行更改后每个链接和子页面都点一遍看一遍就能发现，却疏忽了】
查错工作持续到了下午4点多。
期间，我发现报错激发的规则，该错误不仅出现有代码更改过的产品专区，也出现在其他代码未更改过的页面。只要频繁的刷新页面或频繁的进行页面跳转就能激发。去年迁移过服务器，由不知名处迁移至aliyun。
在我的测试过程中，通过chrome的network纪录发现一些线索
- 成功页面的Cache-Control值为private，失败页面的值为no-cache
- 成功页面的X-Powered-By值为ThinkPhp，失败页面的值为php版本号
- 失败的页面不仅出现在代码有改动的产品专区控制器下，也出现在其他控制器下
- 通过ThinkPhp的错误提示和404逆推到App.class.php和Think.class.php
我初步判断失败的原因在于apache配置错误或服务器本身问题，和组长沟通后。
组长通过trace log，由我手动激发错误，将问题定位至php的内置函数basename($path[,$suffix])，该症状表现为：
basename('@/Group/Controller/Action')应返回字符串"Action"，但是在随机的时刻，可能返回空字符串(String "")。
组长初步判断要么是php版本问题，要么是Apache问题，要么是aliyun的服务器问题。
在寻求解决办法的过程中，我查询了github，stackoverflow，bugs.php.com，均没有发现有类似问题提交。
组长重启了一次服务器，问题解决了，事后推断可能是由于太长时间没有重启服务器，导致一些不知名的问题。【也有可能组长通过和高级人才的交流获得了解答】
在重启服务器后，报错页面再也没有出现。此次距离上次重启预估已有小半年时间。
至此，模块改版的投产终于告一段落了。之后也没有新的bug发现。
在椅子上从九点多坐到六点整，中午下去买了个hungry jacks，回到工位上边查错边吃。如此算来这次投产用了整整一天。
现在进行事故总结：
- 一定要和PM讲清楚，哪些会同步，哪些不会同步，不然他一句“我以为”，一点反驳力都没有。
- 在没有测试组的情况下，每新加一个功能，改一个bug，只能靠自己多点点，多看看，模拟上线也要当正式上线来做。
- 服务器在运行时间太久后可能会出现这样那样的问题，但把问题归到服务器上前，还是要尽量查完有效的途径。