大家好，我是TT。
基本上，无论是网络还是应用引发的问题，也无论是不加密的HTTP还是加密的HTTPS，你应该都已经掌握了一定的方法论和工具集，可以搞定不少问题了。
但是我们也要看到，现实世界里也有不少问题是混合型的，未必一定是跟网络有关。比如，你有没有遇到过类似下面这种问题：
ping正常，抓包看也没有丢包或者乱序现象，但是应用就是缓慢；
Tlnt端口能通，但应用层还是报错。
其实这也说明了，掌握网络排查技能固然重要，但完全脱离操作系统和架构体系方面的知识，仅根据网络知识去做排查，也有可能会面临知识不够用的窘境。所以，作为一个技术人，我们任何时候都不要限制自己的学习和成长的可能，掌握得越多，相当于手里的牌越多，我们就越可能搞定别人搞不定的问题。
所以接下来的内容，我会集中围绕系统方面的案例展开分析，希望可以帮助你构造这方面的能力。等以后你遇到网络和系统扯不清的问题时，也不会发怵，而是可以准确定位，高效推进了。
案例1：高负载和不均衡
这也是我在公有云工作的时候处理的真实案例。当时一个客户是做垂直电商的，他们的体量还不大，所以并没有自建机房，而是放到公有云上运行。他们的架构大致是这样的：
LB运行在第四层，设置的负载均衡策略是roundrobin（轮询），也就是新到达LB的请求，依次派发给后端个Nginx服务器，使得每台机器获得的请求数相同。Nginx运行在第七层，它作为Wb服务器接收HTTP请求，然后通过FastCGI接口传递给本机的php-fpm进程，进行应用层面的处理。
应该说，这就是一个非常典型的负载均衡架构，平时运行也正常。不过有一天，客户忽然报告系统出问题了，网站访问越来越慢，甚至经常会抛出HTTP错误。如下图所示：
我们借助浏览器开发者工具可以看到，这个响应耗时长达60秒，然后抛出了错误。事实上，一般人浏览一个网站的时候，等个十来秒肯定就没耐心了，所以这次的问题确实很严重。
初步检查
这三台Nginx服务器的配置都是8核CPU。从服务端的监控来看，它们的系统负载，也就是CPUload出现了严重的不均衡。其中一台的负载值在7左右，一台在20左右，最后一台居然高达40左右，远远超过它们的CPU核的数量。
我们知道，uptim或者top命令输出里的CPUload值，表示的是待运行的任务队列的长度。比如8核的机器，load到8，那就是8CPU核处理8个任务，全部用满了。不过，能到用满的程度，实际已经对应用的性能产生明显的影响了，所以一般建议load值不超过核数*0.7。也就是8核的机器，建议在load达到5.6的时候，就需要重点