一次故障处理引发的思考

ztfstar

    前日接到现场报告，说服务器的不能FTP到客户系统下载任务数据。当时到服务器简单测试了下，发现可以ping通用户服务器地址；可以telnet 到客户服务器IP的21端口，但却没有任何服务回应；ftp服务器，没有相应，返回信息close by remote host ;ftp其他测试公网地址，正常。根据以上信息和以往经验断定问题出在客户服务。
　　 1　客户服务器故障
    2  客户防火墙阻止了我端FTP连接
    3  我端阻止了此FTP连接

  对于1 询问了客户IT部门，发现服务正常。3 我方没有做防火墙调整，并且检查了防火墙策略，未发现异常。所以就没有去理会，只是发了个测试报告说断定是客户方服务有问题。

   过了两日问题仍然未解决，用户来信说要求辅助共同解决。
   这时才想起做个无障碍测试，于是使用备用互联线路直接连接到了公网进行FTP测试，这一测试让我冒了一头冷汗，刚才还说是人家的问题。可直接连在互联网上就可以FTP到对方服务器，看来的确是自己的问题。脑袋里突然浮现出了从对方服务器到我端用户之间的所有网络环节，却不知哪里出了问题。但初步诊断应该是我端防火墙出现的问题。于是在防火墙反复检测日志、单项策略、全局策略，未果。冷静下来想了下，自己忽略了什么呢？到底是被防火墙哪条策略阻止了呢。如果正常的策略没有阻止这个连接那还有什么可以阻止一个服务呢。这时突然想到了一个功能，威胁爆发阻止，防火墙有一个功能是当发现一个地址在一个时段对本网络的连接（ICMP/SYN/TCP/）超过阀值时就会阻止此地址的连接。想到后马上检查了此自动策略，果然在禁止列表内发现了对方服务器地址。问题解决，但缺不知如何与对方解释。虽然最后不了了知，但却是侥幸。
   这个教训是告诉大家，搞管理技术也要给自己台阶下，某些事情真的追究起责任来，还是吃不消的。搞技术管理的人责任心很重要。另外一点就是要不断改进你的问题测试流程，按照一个流程测试下来没发现问题，那就说明你的测试流程有漏洞。一定要不惜代价的修正这个漏洞，否则可能会付出更大的代价。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/51862/showart_1154482.html