发生在眼前的故事：不做好最坏的打算，往往事情就会去到最坏的地步（三）

续《发生在眼前的故事：做好最坏的打算，往往事情不会去到最坏的地步（二）》

以下事情发生在9月22日的4:30~5:00PM

在分别和项目经理A、架构组同事dy的领导F通完电话后，马上通知负责业务的同事以及相关的领导，让项目的相关干系人了解情况，并且知道技术部门正在处理相关事宜。（后续需要QA将故障处理流程纳入改进计划）

回到公司后，和架构组同事dy以及领导F开会，了解两点办接到故障后截至到目前我们掌握的情况和以及做的相关处理，从沟通中知道目前只是从QQ上接受到项目组传送过来的服务器运行日志server log，还缺少服务器的访问日志access log，也没有拿到疑似“死机”时刻的Thread Dump，从掌握的server log上可以看到怀疑是connection pooling的问题！

我告诫同事，机器和人其实也挺像的，当机器已经疑似“死机”的情况下，一定已经有很多并发症，表象下面可能掩盖了真象，而且真象可能不只一点！我们可以只怀疑connection pooling的问题，但是必须从多个方面的线索来证明，目前还没有拿到12点故障发生时的其他日志，妄下判断没有意义，更何况connection pooling的配置问题上次已经发生，项目组应该有了经验，存在可能性项目组又再忽略了问题，这个可以去电确认，现在赶快拿到其他日志，要求5点半之前分析出一些可能的蛛丝马迹！

 

以下事情发生在9月22日的5:30~6:00PM

快解决下班的时候，去询问了同事dy的工作进展，得到的答复如下：

1. 项目组部署上线的时候，为了性能优化，关闭了系统的access log，所以没有得到今天运行的访问日志；
2. 项目组在中午12点左右疑似“死机”时，项目组进行了Thread Dump，但是在nohup的重定向输出结果中没有Thread Dump的内容；
3. 已经和项目组同事确认检查connection pooling的版本，怀疑存在连接没有释放的情况发生，造成线程挂起，最终导致weblogic挂起；
4. 从server log上，还可以看到有错误信息，显示可能Weblogic没有被正常关闭，又重新启动了Weblogic，怀疑Weblogic运行不正常。

我说没有一本书说为了性能优化，就要关闭access log，那么奥运网站、新浪、网易这些访问量比我们大多的网站，都没有access log吗？人家是全部关掉access log呢，还是有选择地进行access log呢？还有，现在的怀疑都有可能，但是我们要讲证据，关键是那我下一步的行动计划是什么？得到回答如下：

1. 告知项目组打开Weblogic http access 的日志，并且配置了日志格式，在日志中记录请求处理时间以便下次发生时分析；
2. 告知项目组练习Thread dump 的使用，确认能够通过当前操作获取Thread dump的日志；
3. 建议针对本次上线新增的功能进行压力测试，看是否能够重现问题；

对于dy的回答，我的回应如下：

1. 你没有做好最坏的打算！今天我们“好彩”在不繁忙时段出现问题，明天不一定有这样的运气，只是告知项目组练习使用，能确保明天再发生的时候，项目组就已经会并且能做到吗？
2. 如果明天在用户高峰时出现问题，项目组一定是紧急重新启动，越快越好地重新恢复处理，刚才说的这些动作在疑似“死机”情况下，假如项目组都已经正确掌握并且操作，需要执行多少时间，你知道吗？
3. 我的要求是，明天你到现场去，去现场感受压力，做好最坏的打算，出现问题的时候，力保能够获得一手的资料！

做以上的决定，来源与以下的几点经验体会：

1. 法官与侦探：项目组找SDU去救火，我们的工作思维还是慢条斯理，看似专家，其实心态不对，“把资料呈上来吧”的法官老爷姿态是不是不对呢？为了分析问题、定位问题和解决问题，应该像侦探一样去找各种可能的线索，说起侦探，谁听说过不重视现场证据、不去现场的侦探！
2. 医生与医患：我们骂医生没有职业操守和敬业精神，到底什么才是？！地震其实告诉我们答案，感同身受，医者父母心，说的就是这个道理。项目组找SDU，我们的解决办法好像是“你还没有流那么多血，如果多了有生命危险，我们就马上做手术”——摘自一个多月前亲耳听到博士医生对病人说的话！
3. 服务意识：没有了服务意识，下次谁还再来找你，SDU飞虎队不是安出来的名堂，是要靠打出来的威信。做管理是这样，接电话做服务也是这样，写程序做UI也一样，写框架做接口也是一样，没有服务意识，能做好吗？