1. 先把“会用工具”这件事想清楚
入行网络工程师这些年，我带过不少新人，也面试过不少人。一个很常见的误区是：把“会用工具”等同于“背得出命令”。比如问ping的用法，能背出ping -t、ping -a，但真遇到业务卡顿，连“该在哪台设备上ping、ping网关和ping公网IP分别说明什么问题”都分不清。合格的网络工程师，工具不是背出来的，是一套排查问题的肌肉记忆。
这篇文章我想系统梳理一下，一个日常干活真正离不开的工具清单。不是让你把每个工具都学到精通，而是让你知道：碰到连通性问题该掏什么，碰到慢问题该看什么，碰到“时好时坏”的诡异故障又该信什么数据。适合刚入行的网工、从桌面运维转网络的人，以及那些觉得自己“命令都会但排障没思路”的朋友。
我自己的体会是：工具这东西，学一条命令五分钟，但知道在什么场景下用它、它的输出哪一行才是关键，这才是值钱的部分。所以下面我不会只列工具名，我会连“为什么是它”和“现场怎么用”一起讲。整套东西消化下来，你再去处理故障，思路会完全不一样。
2. 连通性诊断：排障的第一层，也是最后一层
2.1 ping和扩展ping：不是“通了就行”
ping是所有人都会的第一个命令，但多数人只用了它十分之一的能力。普通用户ping一下，看“通”或者“不通”；网工ping，要在脑子里回答三个问题：源地址对不对、路径对不对、延迟和丢包能不能接受。
先说源地址。很多网络设备上多IP很常见，比如交换机有管理IP、业务IP，还有loopback地址。你在设备上直接敲ping 10.1.1.1，系统会按路由表自动选一个源地址，这时候如果路由策略只放行了特定源，结果就会误导你。正确做法是显式指定源，Cisco设备用ping回车进入交互式扩展模式，或者直接ping source <接口IP> 目标地址；华为设备用ping -a <源IP> 目标地址。别小看这一步，很多“通不了”其实是“源不对被策略拦了”。
再说路径。ping通了不代表路径是好的，ping不通也不代表设备宕机——可能中间防火墙丢ICMP，可能路由环路，可能做了策略路由。所以ping的结果要结合traceroute来读，单一工具都是盲人摸象。
最后是延迟和丢包。这里有个实战经验：延迟抖动比延迟绝对值更重要。比如一条链路平时延迟1ms，现在变成50ms，但很稳定，往往是跨路径了；如果延迟一会儿1ms一会儿300ms，那多半是链路拥塞或无线干扰。丢包率方面，ping -c 100 -i 0.2这种高频小包测试，比默认的4个包能暴露更多问题，尤其是在无线和跨运营商链路上。
2.2 traceroute和mtr：看清路径，而不是猜路径
traceroute的原理是逐跳增加TTL（生存时间），让每一跳路由器都给你回一个ICMP超时消息，从而勾勒出整条路径。听着简单，实际坑很多。
第一个坑：防火墙策略。很多设备默认不响应TTL超时的ICMP，于是traceroute里就会出现* * *。这可能让人误以为断在那一跳，其实只是那一跳不回应。所以不要一看到星号就慌，要看最终能不能到达目标、到达前有没有规律性的“断档”。
第二个坑：负载均衡导致的路径抖动。现在的核心设备很多做ECMP（等价多路径），同一个目标可能走两三条不同链路，traceroute每次跑出来的中间跳都不一样。这不是故障，是正常现象。判断方法很简单：多跑几次，如果只是中间几跳在变，最后能到、延迟正常，就没问题；如果路径每次都不同且延迟很高，才值得怀疑。
mtr是traceroute的加强版，它持续发送探测包并统计每一跳的丢包率和延迟，比单次traceroute信息量大得多。Linux上直接mtr -rwz <目标IP>跑几秒钟，输出里重点看两列：一是最终一跳的Loss%，二是中间各跳的Loss%。如果只有某一跳高丢包但后续跳正常，通常是那一跳的策略限制；如果从某一跳开始后面全丢，那才是真正的断点。
我在现网排障时基本把mtr当标配。遇到客户反馈“访问我们官网很慢”，上来先在自己电脑mtr一下官网IP，再让客户也mtr一下，两边一对比，问题是在客户侧、运营商侧还是我们自己的链路，很快就圈定了范围。
2.3 telnet和nc：端口通不通，一句话的事
很多人习惯用ping判断服务是否正常，但ping通只代表主机在线，代表不了TCP端口可用。判断一个Web服务、数据库或中间件的端口是否对外开放，最直接的方式就是尝试TCP连接。telnet虽然老，但干这事儿依然好用：telnet 192.168.1.10 3306，如果能出现一个空光标或者横幅，说明端口通；如果提示Connection refused，说明端口没监听或被防火墙拦了。
不过telnet有个坑：它遇到某些协议会进入交互模式，然后你可能不知道怎么退出。按Ctrl+]进入telnet命令行，再输入quit就能退出。这个细节我见过好几次，有人连上之后硬生生卡在那儿，还以为是设备问题。
nc（netcat）是更现代的选择：nc -vz -w 3 目标IP 端口。-z表示只扫描不发送数据，-v输出详细信息，-w设超时。一次可以扫多个端口：nc -vz 192.168.1.10 22 80 443，输出里会挨个告诉你哪个通哪个不通。批量扫一段端口也能做，比如nc -vz -w 1 192.168.1.10 1-1000，但实际工作中别乱扫生产环境，有些安全设备会触发告警。
2.4 SSH：远程管理的生命线
网络设备、服务器、云主机，日常操作基本都靠SSH。这个工具本身不用多讲，我想强调的是几个容易被忽略的实用点。
一个是跳板机（堡垒机）场景。很多生产环境不允许你直接SSH到目标机器，必须先登录跳板机再跳转。最笨的方法是先SSH到跳板，再在跳板上SSH到目标，但这样要记两套密码，而且跳板上会留下操作记录之外的额外痕迹。更规范的做法是本地配~/.ssh/config：
Host bastion HostName 10.0.0.1 User admin Host internal-server HostName 172.16.1.10 User appuser ProxyJump bastion配好之后直接ssh internal-server，它会自动先连跳板再跳内部机器，整个过程对用户透明。这个配置我第一次用的时候感觉打开了新世界的大门，强烈建议每个网工把自己的~/.ssh/config建起来。
另一个是会话保持。网络设备上敲命令，SSH断一下可能就得重连，关键配置改到一半断了更麻烦。所以能用screen或tmux就用，尤其是通过跳板操作多台设备的时候。tmux里开多个窗口，分别连不同设备，断了还能tmux attach恢复现场。
3. 抓包分析：网络排障的终极手段
3.1 tcpdump：命令行抓包的基本功
很多问题看到现象但找不到原因，最后都得靠抓包定论。比如“应用说超时，但ping正常”，你不抓包永远不知道那几秒到底发生了什么。tcpdump就是Linux下最常用的抓包工具。
基础用法：tcpdump -i eth0 -nn -s 0 -w /tmp/capture.pcap host 10.1.1.1。这个命令里每个参数都有讲究：-i指定网卡，-nn不做域名和端口反解（抓包时反解又会发起DNS查询，纯属添乱），-s 0抓完整包（默认只抓前96字节，很多应用层信息会丢），-w写入文件。生产环境直接抓包会影响CPU，但短时间用小流量filter抓，问题不大。
过滤表达式是tcpdump的灵魂。几个高频场景我列一下：
- 只看某个IP的流量：
host 192.168.1.10 - 只看某个端口的TCP握手：
tcp port 443 - 只看某两个IP之间的HTTP请求：
host 192.168.1.10 and port 80 - 排除噪声：
host 10.1.1.1 and not port 22（别把自己SSH的流量也抓进去）
实战中我经常先抓个几十秒，然后Ctrl+C停止，用-r回放文件，配合grep快速定位可疑包。比如看到大量TCP重传（TCP retransmission），基本可以断定链路丢包或对端处理不过来；看到很多RST包，往往是对端主动断连，多半是应用层问题而非网络问题。
3.2 Wireshark：图形化分析，把数据包读成人话
tcpdump记录的是原始数据，人眼直接看太痛苦，所以抓下来的文件一般拿到Wireshark里分析。Wireshark能自动解析协议，把TCP三次握手、HTTP请求、TLS握手过程直接展示出来。
我最常用的三个功能：一是“着色规则”，默认绿色是正常TCP，红色是错误包，黑色是RST，一屏扫过去哪里红哪里就值得怀疑；二是“统计-流量图”（Flow Graph），能把一次完整会话的交互顺序画出来，谁先发的、谁回的慢，一目了然；三是“统计-分层协议”（Protocol Hierarchy），能看到整体流量里TCP、UDP、HTTP、TLS各自占比，快速判断流量构成。
给新手一个建议：抓包分析别一开始就盯细节，先回答三个问题——有没有TCP三次握手？谁在发第二次握手的ACK时慢了？有没有Retransmission或Dup ACK？这三个问题答完，八成的网络延迟问题已经有了方向。
有个典型场景我遇到过好几次：客户端访问数据库，偶尔超时。抓包发现TCP握手正常，但客户端发完查询请求后，服务器要隔2秒才回数据。再往下看，服务器在收到请求前先回了客户端一个TCP Window Full，说明服务器接收缓冲区满了，客户端在等窗口更新。这其实是数据库连接池配置或服务器端处理慢的问题，跟网络一点关系都没有。不抓包，这种问题能排查三天。
3.3 抓包的时机与姿势
抓包这事，时机比技术重要。很多故障是偶发的，你到现场抓包时它可能已经不犯了。我的经验是：
- 尽量带着抓包工具去复现问题，让业务方配合触发一次故障，比事后抓要有用得多。
- 抓包要抓两个点：客户端侧和服务器侧。只抓一端，你只能看到一半的真相。如果两边都抓了，对照时间线来看，哪一段耗时发生在哪一侧，基本绕不过去。
- 抓包时长不要贪长，抓到关键流量就停。文件太大后Wireshark打开都卡，分析效率反而低。
另外特别提醒：Wireshark能解析的东西有限，如果你抓的是加密流量（比如TLS），看到的只是加密后的数据，能分析的就只有握手阶段和包大小、时序。这时候别浪费时间在内容分析上，集中看连接建立过程、证书协商、吞吐量特征就够了。
4. DNS与HTTP排查：应用层两大高频故障点
4.1 nslookup和dig：DNS问题别靠猜
网络工程师日常被问得最多的问题之一就是“为什么我访问不了这个网站”。一半的情况下，问题出在DNS。nslookup是Windows上自带的DNS查询工具，dig则在Linux和macOS上更强大。它们的核心作用是回答三个问题：域名解析出来是什么IP？用的是哪个DNS服务器解析的？解析结果有没有被缓存、TTL还剩多少？
举一个实战例子。客户反馈“我们域名明明解析到新IP了，但公司内部访问还是老IP”。我在他电脑上执行nslookup www.example.com，看输出里的Server字段是哪个DNS；然后换用公共DNS查询nslookup www.example.com 8.8.8.8，结果发现公共DNS返回的是新IP，而本地DNS返回的是老IP。这就说明问题出在本地DNS缓存或区域同步上，跟客户自己的网络没关系。接下来就去查内网DNS的缓存时间和区域传输配置就行。
dig比nslookup更详细，推荐多用。常用的几个子命令：
dig www.example.com：查A记录dig www.example.com +trace：从根域名服务器开始逐级查询，能看到完整的解析路径，判断是根域、顶级域还是权威域出了问题dig @114.114.114.114 www.example.com：指定DNS服务器查询，用来对比不同DNS的解析结果dig -x 8.8.8.8：反向解析，查IP对应的域名，偶尔排障能用上
还有一个高频坑：改了DNS配置不生效。这多半是本地缓存没刷新。Windows上ipconfig /flushdns，macOS上sudo killall -HUP mDNSResponder，Linux上sudo systemctl restart systemd-resolved或者nscd -i hosts，视系统而定。这个操作简单到很多人不当回事，但遇到“旧IP访问不了新站点”的问题，第一步本来就该先刷DNS。
4.2 curl：不只是下载工具
很多人把curl当成下载文件用的，但在网络排查里，curl是极好的HTTP诊断工具。它比浏览器更纯粹——不受缓存、代理、JavaScript影响，直接发一个HTTP请求给你看原始响应。
最常用的几个参数：
curl -v http://example.com：显示完整请求和响应头，包括DNS解析耗时、TCP连接耗时、TLS握手耗时、HTTP响应耗时，全给你列出来curl -I http://example.com：只请求HEAD，快速看响应头和状态码curl -o /dev/null -s -w '%{time_total}\n' http://example.com：只看总耗时，适合做简单的访问速度测试curl -k https://example.com：跳过证书校验，用来测试证书配置有问题的HTTPS站点（但仅限自己调试用，别滥用）
实际中我排查“网页打开慢”时，习惯先curl -v跑一遍，看耗时卡在哪一步。输出里有一个TLSv1.3或TLSv1.2的握手过程，如果握手阶段就花了好几秒，问题多半在证书链不完整或SSL握手协商上；如果握手很快但Waiting for response时间很长，那就是应用服务器处理慢，跟网络无关。
4.3 HTTP状态码速查思维
排查Web访问问题，其实是在读状态码的语言。200正常、301/302跳转、401/403权限问题、404不存在、500服务器错误、502/504网关超时。网络工程师偶尔会被拉去参与Web故障排查，这时候能把状态码和网络层对上号会非常有帮助。
比如502 Bad Gateway，通常是Nginx反代后面的应用服务挂了；504 Gateway Timeout，则多半是后端响应超时，可能是应用慢，也可能是后端服务器到数据库的网络有问题。遇到504，我通常先去后端的抓包或看后端日志，再回头看Nginx到后端的连通性和延迟。状态码只是线索，排查还得分层验证。
5. 批量操作与自动化：一个人管一百台设备的底气
5.1 SecureCRT、Xshell和FinalShell：终端工具的对比选择
管理网络设备最基础的需求是能同时开多个SSH窗口、保存设备清单、快速重连。SecureCRT是老牌工具，支持标签页、会话管理、脚本录制，很多运维老手用了十年以上；Xshell是后起之秀，个人版免费，界面更现代，在Windows上体验不输SecureCRT；FinalShell自带资源监控和SFTP文件管理，对同时管服务器和网络设备的人比较友好。
我的建议是：Windows环境选Xshell够用，追求稳定和脚本能力选SecureCRT，经常需要在终端和文件传输之间切换的可以看看FinalShell。工具本身没有绝对优劣，顺手且能提高效率的就是好工具。
但真正的效率提升不在于选哪个终端，而在于“批量”两个字。如果你还在用手一个个登录设备敲命令，说明自动化能力还没有建立起来。下面说的Python脚本和Ansible，是进阶路线。
5.2 Python与Netmiko：用脚本代替重复劳动
网络设备的操作很多是重复的：登录、进特权模式、敲几行配置、保存、退出。用Python的Netmiko库可以轻松把这件事自动化。Netmiko是一个支持多厂商设备的SSH自动化库，Cisco、华为、H3C、Juniper这些主流设备基本都支持。
举个例子。批量给一百台交换机改一个SNMP配置（简单网络管理协议配置），手敲可能要一个下午还容易漏，用脚本几分钟跑完。核心代码思路大概是：
from netmiko import ConnectHandler device = { "device_type": "cisco_ios", "host": "192.168.1.1", "username": "admin", "password": "password", "secret": "enable_secret", } conn = ConnectHandler(**device) conn.enable() conn.send_command("show running-config | include snmp") conn.send_config_set(["snmp-server community public RO"]) conn.save_config() conn.disconnect()这只是一个设备的连接示例，实际批量操作时再加一层循环，把设备IP列表读进来逐台执行就行。有一点要注意：批量操作前一定先拿一台测试环境设备验证命令，别拿生产环境当试验田。我早年间吃过亏，脚本里有一条命令写错了，批量执行上去差点把一台核心设备的配置弄乱，从那以后我所有脚本都强制要求“先试跑+命令审核”。
Netmiko适合做交互式操作，但它本质上是“模拟人敲命令”，性能一般。如果要做大规模配置下发或状态采集，Ansible是更标准的选择。
5.3 Ansible：网络设备配置的版本化与标准化
Ansible是红帽出品的自动化工具，核心优势是“幂等”——同一套配置跑一遍和跑十遍，结果一致。这一点对网络设备来说尤其宝贵，因为传统手工配置最怕的就是“改着改着把设备改坏了”，Ansible通过声明式配置把风险降下来。
一个极简的Ansible网络设备playbook大概长这样：
--- - name: Configure interface description hosts: switches gather_facts: no connection: network_cli tasks: - name: Set interface description ios_config: lines: - description "Uplink to Core" parents: interface GigabitEthernet0/1它的价值不只是“自动执行”，而是把配置变成代码，可以放进Git仓库，每次变更都有记录、能回滚。这比“某年某月某人手敲了几条命令，后来没人知道敲了什么”要靠谱太多。现在中型以上企业的网络团队，Ansible基本是标配技能了，属于“可以不会，但不能不知道”的范畴。
5.4 批量Ping与自动化巡检脚本
最后说一个不需要引入重型框架就能立刻上手的场景：批量连通性巡检。我自己写过很多类似的脚本，逻辑很简单：读一个IP清单，逐个ping（在Windows上也可用Python的ping3库或系统ping命令），把不通的IP、延迟、丢包率输出到表格里。这个脚本能在你值班的深夜帮上大忙。
import subprocess import re ip_list = ["192.168.1.1", "192.168.1.2", "192.168.1.254"] for ip in ip_list: result = subprocess.run( ["ping", "-n", "4", ip], capture_output=True, text=True, timeout=30, ) avg_match = re.search(r"Average = (\d+)ms", result.stdout) loss_match = re.search(r"\((\d+)% loss\)", result.stdout) status = "UP" if loss_match and loss_match.group(1) == "0" else "DOWN/SLOW" avg = avg_match.group(1) if avg_match else "N/A" print(f"{ip}\t{status}\t{avg}ms")这种脚本的价值不在于技术含量，而在于稳定复现。它把“人肉巡检”变成了“脚本巡检”，解放出来的时间可以用来做更有价值的分析。我个人的习惯是每周写一次巡检报告，数据全部来自脚本输出，既不遗漏也不主观。
6. 网络监控与文档沉淀：把不确定变成确定
6.1 监控平台：Zabbix、Prometheus与Grafana
网络监控的目的是在用户发现故障之前先发现故障。Zabbix是网络设备监控的老牌平台，支持SNMP（简单网络管理协议）直接采集交换机、路由器的CPU、内存、端口流量、丢包率、错包数，配置起来也比较直观，适合没太多开发背景的网工。
Prometheus配合Grafana是现在更流行的组合。Prometheus擅长采集时间序列数据，Grafana负责可视化。但请注意一个现实问题：网络设备的数据采集主要走SNMP，Prometheus原生支持SNMP较弱，一般需要通过snmp_exporter做转换。这意味着配置复杂度会上升。所以我的建议是：如果团队里已有Zabbix就先把Zabbix用透，不要盲目追新；如果是从零搭建并且团队有开发能力，Prometheus+Grafana的下限更高。
监控里最该关注的指标，我按优先级排一下：端口流量与带宽利用率、端口错包/丢包、设备CPU与内存、设备温度与电源状态、链路时延与抖动。带宽利用率高不一定是问题，但如果端口上错包数量级异常上涨，那基本就是链路劣化或光模块老化的前兆。
6.2 网络拓扑与文档：draw.io的“画图即梳理”
网络工程师如果只活在命令行里，是很危险的。一个团队里如果只有一个人知道核心网络长什么样，这个人请假的时候整个团队都会抓瞎。所以拓扑文档不是“加分项”，而是“保命项”。
draw.io（现在叫diagrams.net）是我最常用的拓扑绘制工具。免费、跨平台、支持导入导出，关键是有很多网络设备图标可以直接拖拽使用。画拓扑图的习惯我现在也养成了：每改一次网络结构，当天或隔天就把拓扑更新掉；每次变更完成后，把变更命令和配置备份一起存档。
别把画拓扑当成负担。我见过很多网工觉得“画图是给领导看的”，其实不是。拓扑图最大的价值是在故障时让你快速定位“哪台设备、哪条链路出了问题”。一张标注了设备IP、互联IP、接口编号、链路带宽的拓扑图，能让排障效率翻倍。
6.3 知识库和笔记：经验不沉淀等于没经验
最后一个容易被忽略的工具，其实是笔记。我带的每一个新人都被要求：所有排查过的故障，必须写一篇复盘笔记，内容包括现象、排查过程、根因、解决方案、后续预防。这一条坚持下来，半年后新人基本能独立处理大半常见故障。
笔记工具方面，Markdown文件配合Git管理是最稳的方案，没有平台绑定，可搜索，可版本回溯。也可以自建一个私有Wiki系统，比如Outline或BookStack，但不要花太多精力在“找最好的笔记系统”上，随手能记录、容易检索才是核心。
我自己有个习惯：每处理完一个故障，会在自己的知识库里加一条“如果再次遇到这个现象，第一件事做什么”。这些复盘卡片积少成多之后，就成了我的个人排障手册。很多看上去很玄的故障，翻一翻手册往往发现以前处理过类似场景。
7. 常见故障排查速查与避坑记录
7.1 高频故障场景对照表
| 现象 | 首要排查方向 | 常用工具 | 常见根因 |
|---|---|---|---|
| 全网ping不通某台服务器 | 网关是否正常、服务器是否在线 | ping、arp、tcpdump | 服务器宕机、VLAN配错、防火墙策略 |
| 能ping通但业务端口不通 | TCP端口是否监听、防火墙是否放行 | telnet、nc、ss | 服务未启动、安全组/防火墙规则 |
| 访问网站时快时慢 | DNS解析时间、链路抖动 | dig、curl、mtr | DNS缓存、链路拥塞、后端处理慢 |
| 视频会议卡顿、丢包多 | 最后一公里链路质量、无线环境 | ping、mtr、Wireshark | 无线干扰、上行带宽不足、QoS缺失 |
| 跨网段时通时不通 | 路由是否对称、是否有游走路由 | traceroute、mtr、路由表检查 | 策略路由、路由协议收敛异常 |
| SSH频繁断连 | 空闲超时配置、链路质量 | ssh -v、抓包 | 会话超时、NAT老化、链路丢包 |
这张表是我长期排障总结出来的优先级顺序。记住一个原则：先确认网络层通不通，再往传输层和应用层排查。顺序乱了，很容易在应用日志里翻半天才发现是网络问题。
7.2 我踩过的几个经典坑
第一个坑：改配置前不备份。年轻时在一台接入交换机上调VLAN，命令敲完发现少了一条switchport trunk allowed vlan，结果业务断了半小时。后来所有变更前强制先show running-config存档，大改动还单独导出配置文件。
第二个坑：抓包时把自己绕进去。有次排查一条链路拥塞，抓包时没排除自己的管理流量，结果看到一堆自己的SSH包，还以为是攻击流量，浪费了整整一个下午。现在抓包前我一定会把管理网段过滤掉。
第三个坑：相信“默认配置”。比如交换机的STP（生成树协议）默认开着的，但有些环境里被人为关掉了；比如端口默认是access还是trunk，不同厂商、不同型号可能不一样。排障时永远不要想当然，上去先show一遍实际配置。
第四个坑：忽略时间同步。很多网络协议（比如RADIUS认证、802.1X）对时间敏感，如果设备时钟不准，认证会失败、日志会乱序、证书会报错。新设备上线第一件事永远是同步NTP。这个习惯我吃了好几次亏才养成的。
7.3 避坑技巧：给新手的五个习惯
- 所有变更前做好备份和回退方案。哪怕只是改一条描述，也要知道怎么改回去。这是网工的第一条铁律，适用于任何设备和场景。
- 排障时先看现象再猜原因。不要一开始就认定是自己心里的那个原因，先把“通不通、端口通不通、有没有丢包、延迟多少”这些数据拿全了再下结论。
- 记录每一步操作和输出。尤其是抓包、traceroute、配置变更这类关键操作，记录输出可以回溯，也可以给别人看。
- 能自动化的事绝不手敲。批量操作必上脚本，人肉操作等于给自己埋坑。
- 多给自己留一条后路。比如远程操作设备时，确保另一条带外通道（比如iDRAC、物理终端）可用，防止配置错误把自己锁在外面。
8. 工具只是起点，思路才是分水岭
工具清单可以写很长，但把它真正装进脑子里需要一个过程。我个人实际使用中的最大体会是：工具是拿来印证思路的，不是拿来替代思考的。你脑子里先有了“这可能是链路问题、这可能是DNS问题、这可能是应用问题”的假设，再用工具去验证或推翻它，排障效率才会高。
最后分享一个小技巧：给自己的工作目录建立一个“工具箱”文档，把常用命令、脚本片段、抓包过滤表达式、常见故障处理流程都整理进去。每次用到一个新命令，顺手补充进去。这个文档跟着你越久越值钱，直到某天你会发现，处理大多数故障你已经不需要到处搜索了，因为你自己的工具箱里都有答案。
这篇梳理是基于我自己多年在真实网络环境里的实操经验写下来的。工具永远在更新，新产品也不断出现，但排查问题的方法论不会变——分层、对比、验证、记录。把这套方法论练扎实了，再用什么工具都只是顺手的事。
