系统故障分析案例 某移动BOSS系统故障分析 .pdfVIP

某移动公司 BOSS 系统故障分析 报告提交时间 2012-4-23 报告提交人 徐文勇 2012 年 4 月 案例分析 目录 1. 故障描述 1 1.1 故障描述 1 1.2 网络拓扑 1 2. 分析过程 2 2.1 捕获数据包 2 2.2 分析数据包 2 3. 结论及建议 7 3.1 分析结论 7 3.2 建议 7 第1 页 案例分析 1. 故障描述 1.1 故障描述 1. Boss 系统向服务器提交订单，每天会有600 个左右不成功的订单，不成功的订单 需手工录入，极大的影响工作效率；该现像已持续2-3 个月； 2. 持续ping 服务器和boss，未出现任何的丢包现像； 3. 应用部门和应用厂商检查应用程序和规则说一切正常； 4. 网管人员检查网络设备的性能，设置（MTU、MSS 等）一切正常； 5. 管理人员说在boss 系统上抓取的同步数据包大于在PIX 之前抓取的数据包，怀疑 有丢包，但其它应用和ping 都正常，网络丢包没有说服力。 1.2 网络拓扑 第1 页 案例分析 2. 分析过程 2.1 捕获数据包 订单提交不成功则有两种情况，一种是服务端未收到 boss 的请求，另一种则是服务端收 到请求后未响应，由于客户说在boss 和pix 上抓包不一致，先从这里着手，选择抓包位置， 如下图： 2.2 分析数据包 分别提取回溯系统和便携式上的数据包，进行对比分析。 首先来看在6503 上抓取的数据，如下图： 第 2 页 案例分析 在6503 上捕获到0 和6 的会话中，存在多个syn 包无响应的会话， 从而证实确实存在订单提成不成功的问题，而在PIX 的入口并没有捕获到该会话，也就是 说服务端并未收到boss 的应用请求，所以该现像与服务器端无关。 再来看在PIX 前抓取的数据，如下图： 服务端没有收到包 boss 系统的请求包，是不是由于包被丢弃了呢？从拓扑上看，数据经 过的都是路由、交换设备，该包连防火墙都没到，而且该链路上的其它应用一切正常，如 前所说，网络丢包没有说服力，继续看数据包，看能不能找到其它线索。 第 3 页 案例分析 查看“概要”，发现网络中存在大量的FIN 数据包，4452 个数据包就有2498 个包带FIN 标 记： 过滤FIN 数据包，发现绝大部份F