缘起
这几天疲于救火，火气有点儿大，今早领导在群里@我了下，说第三方反馈我们的网络有些问题。搞得我一头雾水，我首先问清了事情的原委，原来我们这边某个应用调用了第三方接口，但是应用这边时不时的会甩出那么几条错误，而且近期比较多。这不问题一多，大家就紧张了。为了自证清白，我不得不拿起武器自卫。
措施
思索了一会儿，既然对方说是网络的问题，那么我就从网络着手。解决网络问题莫过于经典的OSI七层模型了，根据我以往的经验排错用七层模型还是很靠谱的，只要定位了问题在那一层基本上问题就解决了一大半儿。就像一个牛人故事里面讲的那样：知道在哪儿画线和画一条线的价值相差天壤。所以找出问题的根源然后再去解决问题才能有正解。
下面直接上两条命令，没有铺垫，后续遇到类似问题还可以参考：
1.首先确定TCP/IP层有无问题
首先想的是ping这个命令，本来还想用traceroute,mtr的，但是对方做了些安全的屏蔽，所以没效果，幸亏ping没有屏蔽否则真说不清了。
ping效果如下：
64 bytes from 58.213.99.80: icmp_seq=626 ttl=51 time=33.5 ms
64 bytes from 58.213.99.80: icmp_seq=627 ttl=51 time=33.6 ms
64 bytes from 58.213.99.80: icmp_seq=628 ttl=51 time=33.5 ms
^C
--- api.domain.com ping statistics ---
628 packets transmitted, 628 received, 0% packet loss, time 639851ms
rtt min/avg/max/mdev = 33.484/33.608/36.531/0.235 ms
看着还不错， 没有超时，ttl也算稳定，不过略大。北京到外地很少超过3000千米的，大多在2000千米内，20ms内才算优质。这里由ping命令可以判断TCP/IP层没有问题。
2.再看应用层主要是http/https协议
curl命令应该是首选，系统大多默认自带，使用方法多样，而且能从功能及性能两个层面来观察问题所在
先查看返回状态码，默认401还算正常因为没有加认证，但是多试几次就差点儿意思了，偶尔会出现503，代表后端处理不过来。这时基本上就发现了问题点儿，后端多半是集群可能是某个节点有问题，问题多半是处理到了瓶颈。
再看响应时间还是挺快的，进一步确认TCP/IP层没有问题。就连出现503时相应时间依然挺快的，感觉可能是第三方这边可能做了优化，默认超过了一个比较小的响应时间这边就会返回一个503，不用等那么久，这一点儿还是很认可的。
[root@188.18 ~]# curl -I https://api.domain.com/api
HTTP/1.1 401 Unauthorized
Server: nginx/1.16.1
Date: Tue, 09 Jun 2020 04:11:40 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 0
Connection: keep-alive
time_connect: 0.033
time_starttransfer: 0.188
time_total: 0.188
[root@188.18 ~]# curl -I https://api.domain.com/api
HTTP/1.1 503 Service Unavailable
Server: nginx/1.16.1
Date: Tue, 09 Jun 2020 04:11:41 GMT
Content-Type: text/html;charset=iso-8859-1
Content-Length: 355
Connection: keep-alive
Cache-Control: must-revalidate,no-cache,no-store
time_connect: 0.047
time_starttransfer: 0.217
time_total: 0.217
后续
建议肯定是没有的，和他方合作，特别是一堆老师们，应该少说话，尽量别越界，把实事讲清楚就行。不用提建议，对方私下里肯定会改善的，毕竟这对人对己都是有好处的。
后续没有后续，做为运维，只要打好底子，就能从本质上去发现解决问题之道。他强任他强,清风拂山岗他横由他横明月照大江。好好的打磨打磨自己的内功，尽量使用最少的招数，解决最大的问题，达到四两拨千斤的效果。
网友评论