记一次预发布环境网络极不稳定的排查流程

我司从合作伙伴那里接手了一个项目。测试同学返回预发布环境请求极不稳定，请求超时概率非常大。于是我便进行故常排查。

项目请求路径：

        1. 域名解析到slb

        2. slb把请求负载均衡到gateway物理机80端口(1台)

        3. gateway物理机内的nginx监听80端口，对请求进行转发

        4. api-gateway服务运行在gateway物理机内的docker中，监听物理机的9004端口

        5. nginx将请求转发到9004端口

        6. api-gateway服务将请求转发到集群内的其他服务

故障排查流程：

        1. 查看api-gateway服务的日志，发现超时的请求并没有到达api-gateway

        2. tcpdump对api-gateway服务进行抓包，没有抓到超时请求的数据包

        3. 查看域名解析配置，一切正常

        4. 查看SLB配置，一切正常

        5. tcpdump对gateway物理机80端口进行抓包，抓到了超时请求的数据包，说明请求到达了nginx

        6. 查看nginx的access.log，没有记录超时请求日志

        7. 查看nginx的error.log，发现了请求日志，请求转发到 xxx.xxx.xxx.164 物理机时超时了

        8. 查看gateway物理机物理机ip为 xxx.xxx.xxx.162，真相浮出水面

        9. 查看nginx配置，发现nginx中upstream配置了两台物理机，分别是 xxx.xxx.xxx.162 和 xxx.xxx.xxx.164，实际上只有xxx.xxx.xxx.162在工作

        10. 询问合作伙伴得知，项目移交时，缩减了预发布环境的服务器资源，xxx.xxx.xxx.164 机器释放了，nginx配置文件改漏了。

结案了。