昨夜升级不顺，几乎熬了个通宵。
首先准备不是很充分，升级脚本有的地方写得也不对，磕磕绊绊部署上去了。然后就发现有的功能有问题，于是现改bug，再部署。问题还真不少，和晓东一直改到后半夜。我觉得自己挺厉害的，在半夜两三点钟非常困的情况下还能看懂别人的冗长拗口的代码逻辑，并且找到了正确的解决方案。最后一次部署之后似乎没什么问题，四点半的时候终于可以去睡觉了，剩下一个勤奋的龙小许同学还在努力的测试。
然后上午还在做梦的时候就被电话吵醒了——我自己的手机不知道扔哪儿去了，所幸有张sim卡给了丈母娘用，然后我的好梦终于到头了。
好家伙，重大故障，系统服务彻底崩掉，全国的美容院都没法给顾客约服务了。数据库CPU占用飙升到100%，tomcat获取不到连接，所有请求都几乎无法响应。
好在哥大风大浪见得多了，这种事已经见怪不怪。但问题还是很奇怪。特别是数据库连接数改大了之后还是报获取不到连接的错误。困惑了一段时间之后终于发现，坏了，昨晚升级有个配置弄错了，连到测试用的数据库上了。一开始是对的，但是后来改bug，反复部署，到最后终于糊涂了给弄错了。这也就意味着今天上午到目前为止的预约数据全丢了。
切换回正式数据库之后，数据库CPU很快又到了100%，连接也又满了，访问压力太大。检查mysql慢日志，有几个查询比较慢，加了索引之后cpu嗖的就降下来了，连接数也一下子从1000降到了个位数。
总结总结：
- 升级时候的误操作。这个主要还是因为没有做到自动化，然后操作完成后也没有检查，以至于错误的配置没有被发现。
- 对新开发的功能，没有过多关注性能……不过既然功能都是半夜才现改正确的，所以对性能也不能要求太多。测试方面太欠缺了，时间紧任务急，说上就上谁也不知道有没有问题。
再总结一下，这些错误还是属于比较低水平的，那为什么还会出现呢，归根结底就是没有用正确的方法去做事情。那么为什么没有用正确的方法去做事情呢？值得深思。
