在分析疑似网络故障时，哪些是我们必须要做的 一般正常来说可能有以下几点：清楚故障现象、明确网络拓扑、梳理数据流向、合理部署抓包点等。
因应用系统负责人反馈交互较简单，且故障现象随机较频繁，在远端呼叫中心客户端侧暂无技术能力抓包的情况下，遂在服务器侧进行抓包，抓包点在服务器网关交换机上。\
问题分析
首先根据上报的客户端1 IP 192.168.0.1 进行了数据包过滤抓取，观察是否有异常。 TCP 层面有会规律的建立即关闭连接，应该并不是什么问题，只是客户端和服务器之间的心跳包。再捞取唯一有数据字段传输的流，在相应时间内看起来也并没有什么问题，带 [PSH,ACK] 和 [ACK] 的数据包来回交互。
第一次分析尝试貌似并没有取到有用的信息，因此和呼叫中心同事强调客户端源IP以及应用闪退的时间点需进一步明确，要不服务器端的抓包分析很容易被大量数据包所掩盖。
第二次根据上报的问题客户端2 IP 192.168.0.2 ，服务器 IP 10.10.10.2 以及 故障时间点（1分钟内） 进行了数据包过滤抓取
发现客户端主动 RST 了连接，网络上并没有出现因延时或丢包所造成的重传现象。在故障时点内观察该客户端与其他服务器的通讯，发现有同样问题，客户端在同一时间点前后，同样主动 RST 了连接。根据相应数据包现象来看，问题更像是出在应用本身上面。
为进一步佐证结论，再一次回溯分析了客户端3 IP 192.168.0.3 在故障时间点的数据包，同样的现象，且无其他异常。
后续分析
根据业务所上报的问题现象，在不同的客户端、服务器以及不同的故障时间点，综合分析出问题并不是在内部网络上（包括呼叫中心和总部互连的专线），所看到的都是客户端行为，反馈应用系统负责人需进一步排查该应用上的故障日志。
后续应用系统负责人在客户端上调取应用日志，发现在故障时点上应用有调用服务失败现象，紧接着造成应用程序崩溃。后配合分析发现是该应用在办理某项业务时，会调用公网服务，即在呼叫中心本地客户端会产生从公网外出访问至总部数据中心DMZ区域的服务器，而由于安全HW要求，呼叫中心一刀切关闭了公网访问，因此造成了调用失败，导致应用崩溃，而在内网所抓取的数据包 RST 都是该应用崩溃关闭后所产生的后续行为，至此问题处理结束。
总结
回顾整个问题，最后所强调的仍然是开头提到的几点建议，a. 清楚故障现象，明确问题所发生的行为，结合应用或系统日志综合分析；b. 明确网络拓扑，定位客户端和服务器所处的位置，交互方式，判断可能发生的问题点；c. 梳理数据流向，理清数据交互的走向、类型、规律，不要有所遗漏。d. 合理部署抓包点，根据问题的不同，可能需要在客户端、服务器、网络设备前后进行一一抓包对比分析。
