前一段时间我们公司的mail系统客户，一直反映我们的mail系统有问题，销售、客服人员以及运维人员都搞不定。具体的症状大体是这样：“通过webmail系统收发邮件非常慢，很多时候直接断掉了”。这个客户是我们的一个大客户，属于中字头的公司，态度强硬，巨牛。运维人员反映说：客户的网络是光纤接入，速度非常快，ping值不超过5ms，而且没有丢包现象，所以应该不是网络的原因。
所有人反映的情况，似乎都直接指向了产品有问题。事实上，这么多客户都没有问题，为什么唯独它们有问题的，这个道理根本就无法说通，询问他们是不是网络有变动，他们矢口否认，坚持是我们的产品有问题。我作为产品的研发者，竟然成了第一责任人，在这种情形下，被迫担当了一回“超级客服”。我相信有因才有果，计算机程序只能按照人的意志运行，它绝不会骗人。
某天下午，我跟公司的销售来到了客户现场，进行问题排查，过程如下所述。我把这个过程写下来，只是为大家提供一种做事的方式。
排查过程如下：
--------------------------------------------------------------------
用户环境问题排查
1、客户演示操作过程，问题可以重现，说明他们提出的问题确实存在。
2、与网管协商，将我携带的笔记本配置完整后，接入他们的内网。
3、我通过我的账号（主要便于我们排查），发现问题依然存在。
这一步证明：不是用户机器环境的问题，而是网络环境可能存在问题。
-------------------------------------------------------------------
网速排查：
1、使用ping工具进行网速测试，ping xxx.xxx.xxx.xxx -t -l 1500 ,经一段时间测试，仅丢一个包，丢包率为0，包反馈时间在10ms左右，说明网速很快，链路正常。
2、再登录我的账号，问题重现。
这一步证明：不是因为网络环境不稳定造成的问题。
--------------------------------------------------------------------
病毒排查：
我最初怀疑可能是arp欺骗，以至于传输过程中的数据包被转向，或被篡改。
1、使用arp -a命令列出目前本机缓存的地址映射表，然后开启防火墙，屏蔽掉除网关ip(10.135.1.254)之外的所有其它ip地址，防止造成干扰。
2、与网管人员协商拿到网关的mac地址，使用arp -s 来绑定网关ip地址和mac地址，防止网关mac地址被篡改。
结果问题依然存在。
这一步证明：不是因为arp欺骗造成。
---------------------------------------------------------------------
程序应用层排查
1、使用httpwatch进行应用层数据的监控分析。结果发现数据发送一部分后断掉，没有收到服务器的回应。
2、切换到旧版mail系统，进行发送数据的测试，发现结果一样，问题也依然存在。
这一步证明：新mail程序没有问题。客户端（浏览器）因为收不到服务器端的响应，所以处于等待状态。
---------------------------------------------------------------------
系统网络层排查
1、使用sniffer（轻量级的minisniffer）进行网络层数据抓包。经长时间抓取的数据进行对比分析，发现异常情况：每一次邮件数据发出部分后，间隔一段时间，网关要求重新发送。也就说第一次发送的数据被网关（或者网关之后的设备）判定丢失或不合法，网关要求客户机再次发送，客户机发送后链路断掉。
这一部证明：因为我们的服务器是正常的，所以问题肯定出现在网关和目的机之间的链路。
-------------------------------------------------------------------------
在这个环节有问题，我可是没法再追查了，只有他们的网管才有这个权力。我就与用户进行交流，最后才得知：最近他们上了一套上网代理系统。这是他们网络环境唯一的变化，它出现的位置完全符合我判定的环节，出现问题的时间也靠谱。
于是，我与网管协商，是否可以将代理系统暂停几分钟，以便我们进行测试。网管虽然不愿意这么做，但最终还是给出另一个途径，调出一个没有经过代理系统的ip地址。
经过ip地址变换后，发现问题消失，一切正常。重新回到原ip地址,问题重现。
终于证明：问题出现在代理系统上。
问题终于解决，超级客服耗费了4个多小时。客户啊，你可够混的，真想抽丫的。
以上解决问题的方法，专业术语称为“隔离分析”，感谢朋友们的指点。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wanghao72214/archive/2009/02/06/3866903.aspx
所有人反映的情况，似乎都直接指向了产品有问题。事实上，这么多客户都没有问题，为什么唯独它们有问题的，这个道理根本就无法说通，询问他们是不是网络有变动，他们矢口否认，坚持是我们的产品有问题。我作为产品的研发者，竟然成了第一责任人，在这种情形下，被迫担当了一回“超级客服”。我相信有因才有果，计算机程序只能按照人的意志运行，它绝不会骗人。
某天下午，我跟公司的销售来到了客户现场，进行问题排查，过程如下所述。我把这个过程写下来，只是为大家提供一种做事的方式。
排查过程如下：
--------------------------------------------------------------------
用户环境问题排查
1、客户演示操作过程，问题可以重现，说明他们提出的问题确实存在。
2、与网管协商，将我携带的笔记本配置完整后，接入他们的内网。
3、我通过我的账号（主要便于我们排查），发现问题依然存在。
这一步证明：不是用户机器环境的问题，而是网络环境可能存在问题。
-------------------------------------------------------------------
网速排查：
1、使用ping工具进行网速测试，ping xxx.xxx.xxx.xxx -t -l 1500 ,经一段时间测试，仅丢一个包，丢包率为0，包反馈时间在10ms左右，说明网速很快，链路正常。
2、再登录我的账号，问题重现。
这一步证明：不是因为网络环境不稳定造成的问题。
--------------------------------------------------------------------
病毒排查：
我最初怀疑可能是arp欺骗，以至于传输过程中的数据包被转向，或被篡改。
1、使用arp -a命令列出目前本机缓存的地址映射表，然后开启防火墙，屏蔽掉除网关ip(10.135.1.254)之外的所有其它ip地址，防止造成干扰。
2、与网管人员协商拿到网关的mac地址，使用arp -s 来绑定网关ip地址和mac地址，防止网关mac地址被篡改。
结果问题依然存在。
这一步证明：不是因为arp欺骗造成。
---------------------------------------------------------------------
程序应用层排查
1、使用httpwatch进行应用层数据的监控分析。结果发现数据发送一部分后断掉，没有收到服务器的回应。
2、切换到旧版mail系统，进行发送数据的测试，发现结果一样，问题也依然存在。
这一步证明：新mail程序没有问题。客户端（浏览器）因为收不到服务器端的响应，所以处于等待状态。
---------------------------------------------------------------------
系统网络层排查
1、使用sniffer（轻量级的minisniffer）进行网络层数据抓包。经长时间抓取的数据进行对比分析，发现异常情况：每一次邮件数据发出部分后，间隔一段时间，网关要求重新发送。也就说第一次发送的数据被网关（或者网关之后的设备）判定丢失或不合法，网关要求客户机再次发送，客户机发送后链路断掉。
这一部证明：因为我们的服务器是正常的，所以问题肯定出现在网关和目的机之间的链路。
-------------------------------------------------------------------------
在这个环节有问题，我可是没法再追查了，只有他们的网管才有这个权力。我就与用户进行交流，最后才得知：最近他们上了一套上网代理系统。这是他们网络环境唯一的变化，它出现的位置完全符合我判定的环节，出现问题的时间也靠谱。
于是，我与网管协商，是否可以将代理系统暂停几分钟，以便我们进行测试。网管虽然不愿意这么做，但最终还是给出另一个途径，调出一个没有经过代理系统的ip地址。
经过ip地址变换后，发现问题消失，一切正常。重新回到原ip地址,问题重现。
终于证明：问题出现在代理系统上。
问题终于解决，超级客服耗费了4个多小时。客户啊，你可够混的，真想抽丫的。
以上解决问题的方法，专业术语称为“隔离分析”，感谢朋友们的指点。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wanghao72214/archive/2009/02/06/3866903.aspx
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/2924/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
一个网吧网管在自杀前的遗书
做一个高素质的程序员评论列表
