版本发布后的几点总结

     原定于上周四进行一个项目的改版上线，结果由于各方面原因一拖再拖，直到昨天，终于开始上了。

     但无巧不成书，昨天主管请假了，我只能和组内的另一个人上，生怕会出现什么问题，可怕什么来什么。中间还是出事了，造成线上的系统访问时页面直接出来了错误堆栈，我当时都傻眼了，经查是新发布的模板与原来的模板不兼容造成的，可我又太自信了，更新模板时，原模板的内容并没有备份，所以也无法回退到可用的状态，还好DBA用备份数据进行了恢复，虽然上线操作加入的数据都没有了，至少保证用户可以访问。

      这事的影响很不好，主管听说后很是生气，直接在电话里把我责备了一顿，我只能默默承受。客观的说，我的发布操作和预发布操作是一样的，没有什么错误，但问题在于，我们的新版本和线上的原来版本的某些类发生冲突了，而这种冲突是不可替换的。在线上测试的时候，我们也忽略了这种可能，于是导致了无法按新版上线。

      接下来的两天，我们则忙于比对导致冲突的新旧版本的所有情况并逐个更新，直到今天下午，更新终于完成。虽然完成了，但这是一次失败的更新，有很多问题本来是可以避免的，同时有很多东西需要总结。

      首先是备份问题，虽然这不是导致本次更新失败的主要原因，但却是直接原因。如果我在更新模板时先对原模板做一个备份的话，那么即使有问题了，我也能快速的回退，不至于采用万不得已的全数据库恢复，而且也可以少做那么多的无用功。

      其次是版本冲突问题，在线下测试时，我们只是将线上的最新数据结构导到了线下进行修改，却忽略了类及逻辑的变化，从而导致了不一致，所以，在做版本升级的时候，一定要基于上一次的版本做改动，而且要清楚本次的修改会对原版本的哪些方面产生影响，是不是可以做到无缝更新。

      第三是程序的关联问题，为了避免第二点的冲突，我们其实是做了一些准备的，就是我们线上有两台服务器，上线时，先将流量导到另一台，空出一台专门发布新版本，等线上测试完毕，再做同步操作。但问题是，由于两台机器使用的相同的缓存数据库，导致在一下发布新版本时，会同时根据缓存数据更新两台机器的某些模板文件，这样实际上是没有做到隔离发布，也就避免不了产生问题。

      第四是人为问题，这主要是我的问题，因为这个项目的更新主要由我来做，由于我考虑不周，没有整理好版本间的差异，也没有预见更新版本可能出现的问题，如果我自己在线下测试这一环境充分考虑这些问题的话，那就能在线下解决，不至于产生线上错误。

 

      这是一个很严重的失误，一定要汲取教训，尤其是备份，我在这方面一直做得很差。