排查应用系统故障

■

故障现象

最近，公司某生产应用系统升级后，出现一重要模块无法正常使用的故障，比较奇怪的是该模块同时提供国际和国内两种报表服务，而其中只是国际报表不能正常使用。具体现象是提取国际报表时提十几次可能有1次正常输出。在发现问题后，系统研发项目组立即找到运维部门协助排查故障，而笔者有幸参与了故障排除的整个过程。

故障排查

从故障现象看，是系统升级后出现的应用故障，应重点关注应用层面的问题。但项目组认为，同样的国内报表功能都正常，只是国际报表功能不正常，应该看一下安全访问控制策略有没有问题。找到负责信息安全的同事询问最近是否对安全策略有调整，得到的答复是没有。

再次询问项目组这次的应用系统升级修改了哪些地方，回复说只是新增了一些功能（实际上也同时增加了报表内容），没有其他变化。请项目组让使用国内报表功能正常的用户使用国际报表功能看看是否正常，结果是国内报表功能正常的用户提取国际报表时也出现提取失败的现象。继续追问国际报表和国内报表有什么不同，项目组答复是，国际报表一般比国内报表要大，因为内容要多一些，格式等其他都一样（后来发现这就是问题关键）。问题再次陷入了僵局。

既然是应用故障，那就再试一下抓包分析看看有什么异常信息。运维配备的Fluke OPV协议分析仪派上了用场。先将应用系统接口服务器的端口镜像出来，模拟用户使用情况，提取国际报表失败和成功时的数据包做对比分析。与此同时，项目组还搭建了一个模拟生产环境用于测试。在测试过程中发现，在环境搭好后，第一次提取国际或国内报表时，都肯定会失败。难道是系统存在什么未知的Bug？但这个问题很快也被放弃，原因是国内同行没有使用同类型的应用软件，无法帮助我们判断是否存在Bug的问题。

最后，通过大量的数据包比对分析发现，在故障出现时，用户端一般都在发出提取报表请求数据包后的30s时，会再次向服务器端发出停止发送数据包的FIN终止传输信号。然后就会出现我们看到的故障现象，即用户无法正常提取国际报表。

故障分析

那这个30s是否是应用系统设置的阀值还是用户操作系统设置的呢？咨询微软工程师后得到的答复是，操作系统不会设置这个阀值，只能是由应用软件设置。立即询问应用软件工程师，应用软件有没有这个设置，回复是没有。就算是有设置阀值的地方，也是设的60s。对此答复，笔者想到了一个测试方法来验证。

请项目组同事重新搭建一个模拟环境，在第一次提取一个国内报表（内容尽可能少），因为笔者想验证的是，如果提取的报表很小的情况下，并确保在30s内可以完成提取时，还会不会出现每次都会在第一次模拟测试时的失败现象。反复实验结果是，第一次可以正常完成报表提取，同时也就验证了应用软件确实存在30s的响应时间阀值问题。

故障解决

问题最终被定位，即由于应用软件客户端发出请求后，如由于提取的表生成时间超过30s，客户端会自动发送放弃接受数据的请求，而新升级系统后的国际报表内容增加较多，报表生成时间一般都会超过30s，因此升级后才出现了大量国际报表不能正常提取的问题。该应用软件厂商在拿到我们提供的测试结果后，第二天紧急向项目组提供了一个软件升级补丁，修复完成后故障现象随即消失，故障彻底排除。

经验总结

对于此次应用系统故障的排故过程，笔者有几点体会想和同行们分享。

1.在系统发生故障时，首先需要详细询问用户故障现象，是完全不能用还是部分不能用？还是系统响应变慢？这些问题建议通过建立临时的QQ群组来和用户直接沟通，这样用户反应问题迅速，还可以直接语音、视频沟通，以及上传下载测试程序等，总之好处多多。

2.如果是系统功能完全不能用，应首先了解系统硬件是否发生故障或近期有无变更，比如网络设备、服务器或者存储设备。这些可通过用户交叉测试、网络连通性测试等方法验证。

3.如果是部分功能不能用或系统响应变慢，应立即查找应用软件方面的问题。首先应查看是否有安全策略变更，确保不是安全设备策略阻止了新应用数据传输，这通过检查安全设备配置即可迅速判断。另外，还需跟踪数据包流向，确保不是网络配置的问题。

4.如果确认故障在应用软件本身，就需要利用网络分析软件或硬件来帮助查找故障点。这就需要收集大量的数据包进行采样分析，分析人员需要对安全、网络和应用系统都有较为丰富的经验，更有利于帮助问题查找，不至于陷入大海捞针的窘境。研发人员永远都觉得系统的故障基本都是安全或者网络引起的，因此对数据包分析的人员，必须具有较为丰富的知识及个人权威，这纯属个人观点，仅供参考！

5.在做应用软件故障分析时，强烈建议有条件的情况下搭建模拟环境进行测试。这不仅能有效排除其他干扰因素，还能在不影响生产的情况下进行反复模拟测试，这也是我们这次排故比较快速和顺畅的主要原因之一。