产品上线后，在试单过程中，出现一个硬bug，我们系统接入的是百度系统，出现一个http 400错误，这硬bug难倒10几个英雄汉。接下来描述下问题，及我们解决问题的方法及教训：

我们的系统与百度系统是专线访问通道，在上线前肯定确保应用系统是没问题的。双方的访问时基于http协议，接口对接。

访问流程是：百度应用发出一条命令，经过百度网关，然后到达我们的负载，然后是网关，最后转发到应用系统。

问题来了：在百度发出命令后，通过专线到达我们的网关后，我们网关服务器上部署的Apache报出400错误，应用系统没有打印任何日志。

然后我们就找原因：

思考1.400是谁报出来的，已确定只要到达应用，应用就会打印日志，目前应用没有打印日志，就不是应用层；网关的Apache的error没有相关日志，只有正常access文件中有访问日志，那就说明我们的Apache没有坏。但是网关服务器只做转发功能，不做任何报文的转换。

为了排除我们这边的原因，我们做了以下测试：

测试1.使用curl命令，网关IP，正常的报文，从网关自我访问。发现应用层能够正常打印日志。排除了网关向应用层转发错误的可能。

测试2.使用curl命令，负载IP，正常的报文，从负载上自我访问。发现应用层能够正常打印日志。排除了负载向网关转发错误的可能。

测试3.使用curl命令，正确的URL，报文错误的参数，从负载上自我访问。发现应用层能够正常打印日志。排除了报文错误的可能。

思考2.网上查资料，看到400错误可能的原因：1.http版本不一致；2.报文过长；3.报文内容类型与报文内容不匹配（content-type：form与json）。我们观察百度发来的报文与其他合作商发来的报文的区别，发现版本号确实不一致，报文也不短，有1000多字节。然后就自我访问，按照网上资料可能的错误原因进行测试：

测试4.使用curl命令，负载IP，正常的URL，http版本换成百度报文中的版本。发现应用层能够正常打印日志。排除了http版本错误的可能。

测试5.使用curl命令，负载IP，正常的URL，报文长度到达5000字节。发现应用层能够正常打印日志。排除了报文过长的可能。

测试6.使用curl命令，负载IP，正常的URL，将form类型的报文，在content-type中修改为json。发现应用层能够正常打印日志。排除了报文参数值错误的可能。

思考3.经过这些测试，我们基本确定不是应用的问题，而是应用前后各种报文转换配置的问题，那么到底是哪里的出错了呢？然后我们与百度方沟通，是否是在传递命令时，百度方的网关或我们的网关有添加或修改报文。

然后我们猜测是否在网络传输过程丢包了。然后我们就进行抓包测试，从百度发命令，我们在我们的网关入口抓包。经对比分析，没有丢失任何内容。

思考4.那么问题到底在哪，双方几个大拿，开会讨论，确定测试方案。我们既然找不出原因，那么就抽丝剥茧，像剥洋葱一样，从外向里拨，一点点排除各环节的错误。

先写一个简单的页面，以防影响其他的业务，防止业务应用报出错误混淆这个400，便于查看返回数据。

首先是网关对网关，将页面部署到网关Apache上。从百度网关访问我们网关。结果能够正常返回页面数据；排除网关对网关访问异常。

然后是网关对应用，将页面部署到应用服务器上的Tomcat上。从百度网关访问我们的网关，结果能正常返回页面数据；排除网关正常访问我们的应用异常。

最后是应用对应用，将页面部署到应用服务器上的Tomcat上。从百度应用访问我们的网关，结果报出http-400错误；问题定位：百度应用发出的命令经过百度网关后，转换了报文，导致我们的网关直接报错。

到目前为止，已经过去4天了。我们终于将范围缩小到百度应用到百度网关加了什么东西，让我们的系统识别失败。

问题终于找到了。在第5天时，百度人终于找到了问题：

“1.我们在接收http请求时，网关按照header里的 host 字段来进行了一次过滤，过滤的方式应该是正则匹配了ip
2.百度的proxy在转发时host改写为nginx upstream的名字，和我们的网关过滤不匹配”

教训

这次找bug事件中我得出了一些教训：

1.不要总找自身原因。

2.加强沟通

3.解决问题要有调理。有调理的，像剥洋葱一样，一点点剖析、排除问题。

4.什么职位做什么事，既然是产品经理就不要试图指挥技术解决技术的问题。

5.提高双方的配合度。