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

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

以下事情发生在9月23日的10:10~12:00AM

比dy早5分钟到了现场，先进行分工协助，不要因为出现了故障而乱了手脚！

1. 统一思想，项目经理A、负责电话和QQ服务的同事不用分心，继续维持服务，并且还要保证服务的质量不能下降！
2. 如果我们再次提前发现出现疑似“死机”的事故征兆，继续保持目前故障公告流程，让业主以及最终用户及时知道；
3. 如果是最终用户或者业主发现问题，一定先做好对最终用户和业主的致歉、沟通工作，并且告知技术人员正在跟进此问题，今天确实发生了这种情况给大家的工作造成了不便，并告知系统在10分钟后可以正常使用。（因为目前都是采用重启的恢复手段，所以可以这样告知用户）；
4. 有关的最新处理情况，我们会主动发布给服务小组。

dy已经到现场，知道他肯定还挂念着java的connection pooling的问题，安排他落实connection pooling的参数化配置情况。

接着和负责健康监控的cdw沟通，跟进他的监控方法发现可以进行改进，以往检查是否可以访问登录页面的监控方法只能确定、断定故障是否发生，我们需要对故障是否即将发生进行预警。火线培训cdw、wxy同事Weblogic的监控方法，让同事知道我们还能够提前预警，让负责服务的同事知道，可能未来将有故障发生，并且将监控工作转wxy同事负责。

（下周我们要开展针对Weblogic服务器的系统监控培训，让更多的同事具备常规检查能力）

和cdw跟进本日的服务日志、访问日志、程序日志等，希望定位故障发生之前或者确切发生时，业主或者用户当时访问什么、进行什么业务处理。从服务日志上可以看到发生的情况与昨日9月22日发生的情况一致，错误信息雷同；从访问日志上看发现没有包含请求耗时time-taken的访问日志，可以断定可能访问日志还没有完全正确设置，并且让dy和项目经理A调整了日志设置。

接着，和cdw一起对日志进行分析，通过疑似“死机”时的访问日志分析，虽然没有包含请求耗时time-taken，但是可以发现三点定性的结论：

1. 从日志上可以看到本日有一些业主、最终用户从6点半就开始使用我们的IT系统；
2. 从肉眼对日志上分析，可以看到每分钟这些业主、最终用户的访问量不是很大，因为日志记录了每个访问者的IP地址，结合cdw给我们的解释，可以看到并发的请求数不是很大；
3. 特别是在疑似“死机”的时刻，也可以确定当时的并发量不是很大，因为日志记录在解决“繁忙”的疑似“死机”时刻，并发的访问量也不是很大，IP地址在日志记录中，基本上还是保持顺序记录。

从上面的基本分析，如果分析是正确，那么我们从新打开的time-taken的访问日志上，就可以找到造成性能隐患、阻塞访问隐患、死锁访问隐患的业务功能列表，通过大约40分钟的日志分析，我们从包含time-taken的access log分析出10个可疑的功能点。

能得到以上的部分结论，并且找出10个可疑功能点，来源于以往经验和体会：

1. 出现疑似“死机”状态的系统一般是出现了一些并发症，不要轻易地认为已经找到症结，要象CSI一样细致进行“尸体解剖”，多怀疑可能的原因，找到证据去推翻或者证明可疑的原因！这种思维导向，往往更加有效，救火和现在对付金融危机的救市一样，要打组合拳。
2. 不要小看每一秒的改进，10个可疑的功能点，每个功能的耗时都是几秒级别，每减少一秒，意味着可以有更多的服务资源可以服务其它请求！

（补充：如何分析出10个可疑功能点，内容涉及较多技术术语，可待以后再出CSI版本的故障分析报告，但是心态和方法是一样。）