Linux性能问题排查五层漏斗实战指南

1. 这不是教科书里的“性能优化”，而是我每天在终端里敲出来的排查流水线

“排查Linux性能问题一般步骤”——这标题看着平平无奇，像极了运维手册里被翻烂的一页。但如果你真在凌晨三点盯着top输出发呆，CPU飙到98%却找不到元凶；或者客户投诉接口超时，你查遍应用日志却只看到一行模糊的“connection reset”；又或者数据库慢得像在加载GIF动图，而MySQL慢查询日志里偏偏空空如也……这时候，你真正需要的，不是理论框架，而是一套能立刻上手、逐层下钻、不绕弯子的现场作战地图。

我干这行十多年，从某高校实验室的Linux教学服务器维护，到某跨平台系统的SRE岗位，再到带团队做高并发中间件稳定性保障，踩过的坑基本都刻在bash历史记录里了。所谓“一般步骤”，从来不是线性流程图，而是一张动态决策网：它要能兼容CentOS 7的老旧内核，也要适配AlmaLinux 9的eBPF新特性；既要处理Java应用堆外内存泄漏这种隐蔽病灶，也要快速识别dd命令误操作导致的I/O风暴；既得让刚转岗的开发同学看懂iostat输出，也得给资深DBA留出perf record深度分析的空间。

核心关键词就三个：Linux、性能问题、排查步骤——它们不是孤立术语，而是一个闭环动作链：Linux是战场，性能问题是敌情通报，排查步骤则是你的战术手册。它不承诺“一键修复”，但保证每一步都有明确输入、可验证输出、清晰退出条件。比如，当你执行vmstat 1 5后发现si/so列持续非零，那就必须进入内存子流程；如果pidstat -u 1显示某个进程CPU使用率异常但strace -p却卡在futex_wait，那就要立刻切到锁竞争或调度延迟方向。这不是知识罗列，而是经验凝结成的条件反射。

这篇文章写给三类人：一是刚考完RHCE想进真实生产环境的新人，你需要知道课本之外的“脏活”怎么干；二是写了五年业务代码、突然被拉去救火的开发，你得在不惊动架构师的前提下，自己定位到是GC停顿还是磁盘IO瓶颈；三是带团队的技术负责人，你需要一套可复用、可培训、可审计的标准化响应路径。全文没有一句“理论上可以……”，所有内容都来自某次线上事故的完整复盘、某次压测中的实时抓包、某台物理机连续72小时的perf数据采样。接下来，我们就从第一行命令开始，把这张排查地图一格一格铺开。

2. 整体设计思路：为什么是“五层漏斗”，而不是“十大命令”

2.1 拒绝“命令堆砌”，构建有逻辑纵深的诊断漏斗

很多人学Linux性能排查，第一步就是背命令：top、htop、iostat、vmstat、netstat、sar……结果一上生产环境就懵了——20个窗口同时开着，每个都在刷屏，数据互相打架。某次某公司线上服务雪崩，值班同学贴出的截图里，top显示CPU 95%，iostat显示await 200ms，netstat显示TIME_WAIT过万，他问：“到底该先看哪个？”——这问题本身，就暴露了方法论的缺失。

我们设计的“五层漏斗”模型，本质是模拟人类医生的问诊逻辑：先看整体生命体征（系统级），再查局部症状（进程级），接着验血拍片（资源级），然后做病理切片（内核级），最后基因测序（应用级）。每一层都设定了明确的排除阈值和升级触发条件，避免在错误层级死磕。比如，当uptime显示load average远超CPU核心数，但mpstat -P ALL 1却显示所有CPU idle都在90%以上，那问题必然不在CPU计算资源，而是I/O或锁等待——这个判断，比盲目杀掉top里排第一的进程靠谱十倍。

提示：五层漏斗不是固定顺序，而是带反馈的决策树。实际操作中，你可能从第三层（如iotop发现某进程IO异常）直接跳回第二层（ps aux --sort=-%cpu确认进程状态），再折返第一层（dmesg -T | tail -20检查内核OOM日志）。关键在于每一步都有明确的“是/否”出口，而非机械执行。

2.2 工具选型：为什么坚持用原生工具，而非全靠Prometheus+Grafana

现在一提监控，必谈Prometheus、Grafana、ELK。它们确实强大，但有个致命短板：数据是滞后的、聚合的、有采样间隔的。某次某支付系统凌晨出现偶发性3秒延迟，监控图表上只看到一条毛刺，而真实请求链路里，是某个Java线程在获取Redis连接池时卡了2.8秒。等你登录Grafana放大时间轴，故障早已过去，连接池状态也恢复了。

我们的工具链坚持“三原生原则”：

• 原生内核接口：优先用/proc、/sys文件系统直接读取，如cat /proc/$(pidof nginx)/status | grep VmRSS获取精确内存占用，比ps的估算值可靠；
• 原生系统命令：vmstat、pidstat、ss这些随发行版自带的工具，无需额外安装，版本兼容性好，输出格式稳定；
• 原生调试能力：perf、bpftrace这类内核级工具，能穿透用户态抽象，直击调度器、页回收、网络栈底层。

当然，不排斥现代工具。我们会把perf script的输出喂给火焰图生成器，把bpftrace的实时事件流推送到轻量级日志中心。但根因定位的起点，永远在本地终端。因为真正的性能问题，往往发生在监控采样间隙，或只影响单个请求的“幽灵线程”上。

2.3 为什么跳过“应用日志分析”作为首步？——一个血泪教训

新手常犯的错误，是第一时间扑向应用日志。某次某电商大促，订单创建接口超时，开发同学花了两小时grep日志，结论是“日志没报错，应该不是代码问题”。而实际上，pidstat -r 1显示JVM进程的%MEM持续攀升，pstack $(pidof java)发现大量线程阻塞在java.net.SocketInputStream.socketRead0——根本原因是下游支付网关连接池耗尽，上游不断重试建立新连接，最终耗光本地端口和内存。

这个案例教会我们：应用日志是症状描述，不是病因报告。它告诉你“哪里疼”，但从不解释“为什么疼”。Linux性能排查的第一性原理，是相信内核不会说谎——/proc/loadavg的数字、/sys/block/sda/stat的IO计数、/proc/net/snmp的TCP重传统计，这些是硬件与内核共同签署的客观证据。日志分析必须放在第四层（应用级）之后，作为交叉验证手段，而非起点。

3. 核心细节解析：五层漏斗的实操要点与避坑指南

3.1 第一层：系统级宏观扫描——10秒锁定战场范围

目标：用不超过10秒的命令组合，回答三个问题：系统是否真的过载？过载表现在哪？影响范围有多大？

核心命令组合：

# 1. 看整体负荷与资源趋势 uptime; echo "---"; free -h; echo "---"; cat /proc/loadavg # 2. 看CPU实时分布（区分用户态/内核态/IO等待） mpstat -P ALL 1 3 | awk 'NR==4 || /Average/' # 3. 看内存水位与交换活动 vmstat 1 3 | tail -1 # 4. 看磁盘IO基础指标 iostat -x 1 3 | grep -E "(avg-cpu|sda|nvme)" # 5. 看网络连接状态（重点TIME_WAIT与连接数） ss -s; ss -tn | wc -l

关键解读技巧：

• uptime的load average不能孤立看。需对比nproc输出的核心数：若load > 2×CPU核心数且持续5分钟，才视为严重过载；若只是瞬时尖峰，可能是正常批处理。
• free -h里available列才是真实可用内存，free列是完全空闲内存，常被误解。某次某容器平台告警内存不足，free显示仅剩200MB，但available仍有3GB——真相是内核缓存占用了大量page cache，随时可回收。
• vmstat的si（swap in）和so（swap out）列，只要任一列>0，就说明已发生交换，这是内存严重不足的铁证。注意：某些云主机启用zram，si/so可能为0但pgpgin/pgpgout飙升，需额外检查cat /sys/block/zram0/mm_stat。

注意：所有命令加-x（扩展模式）、-P ALL（全CPU）、-t（TCP统计）等参数，不是为了炫技，而是消除默认输出的误导性。例如iostat默认不显示%util和await，而这俩是判断磁盘瓶颈的核心。

3.2 第二层：进程级聚焦——揪出“真凶”还是“替罪羊”

目标：从数百个进程中，精准定位消耗资源的Top 5，并区分其行为类型（计算密集？IO密集？内存泄漏？）

核心命令与陷阱：

• top：按Shift+P（CPU）、Shift+M（内存）、Shift+T（运行时间）排序，但注意其%CPU是采样周期内的平均值，对短时爆发进程不敏感。
• pidstat -u 1：比top更准，-u显示用户态CPU，-k显示内核态，-d显示IO，-r显示内存。实测发现，某Python脚本top显示CPU 30%，pidstat -u 1却显示%usr仅5%、%system高达25%——真相是它在疯狂调用os.stat()触发内核路径查找。
• htop：交互式利器，但需确认/proc/sys/kernel/kptr_restrict为0，否则看不到内核线程名。

进程行为分类法（实战速判）：

避坑心得：
某次排查Web服务延迟，pidstat -u 1显示nginx worker进程CPU 80%，但strace -p <PID> -c统计显示99%时间在epoll_wait——这说明它根本没在干活，只是在等事件。真正的问题是上游Nginx配置了worker_connections 1024，而ulimit -n只有1024，导致连接队列溢出，客户端重试风暴。所以，高CPU未必是坏事，高%wait也不一定是IO瓶颈，必须结合上下文看。

3.3 第三层：资源级深挖——穿透抽象，直击硬件与内核

目标：当确认某类资源（CPU/内存/磁盘/网络）异常时，用底层工具定位具体瓶颈点。

CPU瓶颈深挖：

• perf top -a：全局查看热点函数，-a表示所有CPU。某次发现__do_softirq占比40%，顺藤摸瓜查到是网卡软中断处理不过来，调整/proc/sys/net/core/netdev_budget并启用RPS后解决。
• perf record -e cycles,instructions,cache-references,cache-misses -a -- sleep 10：采集10秒全系统性能事件，perf report可看到指令级缓存命中率，判断是否CPU微架构瓶颈。

内存瓶颈深挖：

• slabtop：看内核slab分配器状态。某次dmesg频繁报slab error，slabtop显示dentry缓存占满80%，执行echo 2 > /proc/sys/vm/vfs_cache_pressure后缓解。
• cat /proc/meminfo | grep -E "^(Mem|Swap|Direct|Anon)"：重点关注AnonPages（匿名页，即进程堆/栈）、Shmem（共享内存）、SReclaimable（可回收slab）。若AnonPages持续增长而MemAvailable锐减，基本锁定用户态内存泄漏。

磁盘IO瓶颈深挖：

• iostat -x 1的await（平均IO等待时间）>100ms需警惕，但更要关注svctm（服务时间）与%util。若await高但svctm低、%util<60%，说明是队列深度大（如RAID卡缓存策略），而非磁盘本身慢。
• blktrace -d /dev/sda -o - | blkparse -i -：块层跟踪神器。某次SSD写入延迟突增，blkparse输出显示大量Q（queue）到G（get request）延迟达500ms，定位到是NVMe驱动bug，升级内核解决。

网络瓶颈深挖：

• ss -i：显示每个socket的详细指标。retrans（重传数）、rto（重传超时）、rcv_space（接收窗口）是关键。某次TCP重传率高，ss -i显示rto从200ms暴涨到2s，tcpping确认是中间网络设备丢包。
• cat /proc/net/snmp | grep -A 2 "Tcp:"：看TCP统计。TCPSynRetrans（SYN重传）高，说明三次握手失败；TCPTimeouts（超时连接）高，说明连接建立后无响应。

提示：这一层工具输出信息量极大，新手易迷失。我的经验是：每次只盯1个指标，配合1个验证命令。比如看到iostat的%util=100%，就立刻执行iotop -o看谁在狂刷IO；看到ss -i的retrans飙升，就马上tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'抓包确认。

3.4 第四层：内核级透视——用eBPF揭开黑盒

目标：当传统工具无法解释现象时，用eBPF动态注入探针，观测内核内部行为。

eBPF入门三板斧：

• bpftool：eBPF程序管理工具。bpftool prog list查看已加载程序，bpftool map dump id <ID>查看BPF map内容。
• bpftrace：高级前端，语法类似awk。一行命令解决经典问题：

  # 监控所有进程的open()系统调用失败原因 bpftrace -e 'tracepoint:syscalls:sys_enter_open { if (args->flags & 512) printf("O_CREAT failed for %s: %d\n", str(args->filename), errno); }' # 统计每个进程的TCP连接建立耗时（从SYN到SYN-ACK） bpftrace -e 'kprobe:tcp_v4_connect { @start[tid] = nsecs; } kretprobe:tcp_v4_connect /@start[tid]/ { $d = nsecs - @start[tid]; @hist[tid] = hist($d); delete(@start[tid]); }'

• bcc-tools：预编译工具集。execsnoop抓新进程、opensnoop抓文件打开、tcplife抓TCP生命周期，比strace轻量百倍。

真实案例：
某Java服务偶发GC停顿长达5秒，jstat显示Full GC次数极少。perf record -e 'sched:sched_migrate_task' -a -- sleep 30发现大量线程被迁移到不同CPU，怀疑NUMA问题。用bpftrace写脚本监控numa_faults事件，确认是JVM未配置-XX:+UseNUMA，导致内存分配跨NUMA节点，访问延迟激增。添加JVM参数后，GC停顿回归正常。

注意：eBPF需要内核4.18+，且/proc/sys/kernel/unprivileged_bpf_disabled需为0。云主机常默认禁用，需联系管理员开启。别在生产环境贸然跑bpftrace -e 'kprobe:* { @ = count(); }'，这会拖垮系统。

3.5 第五层：应用级归因——让代码自己开口说话

目标：将内核观测结果，映射回具体代码行、配置项或业务逻辑。

Java应用归因：

• jstack <PID>：看线程栈。重点找BLOCKED（锁竞争）、WAITING（Object.wait）、TIMED_WAITING（Thread.sleep）。某次发现大量线程卡在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await，定位到是线程池拒绝策略配置为CallerRunsPolicy，导致主线程被拖慢。
• jmap -histo <PID> | head -20：看对象实例数。若byte[]、char[]数量暴增，大概率是字符串拼接或IO流未关闭。
• async-profiler：比jvisualvm更准的火焰图工具。./profiler.sh -e cpu -d 30 -f /tmp/flame.svg <PID>，生成的SVG可交互下钻。

Python应用归因：

• py-spy record -p <PID> -o /tmp/profile.svg --duration 30：无需修改代码，直接采样Python栈。
• gdb -p <PID>后执行py-bt：看Python线程的完整调用栈，比pstack更准。

通用配置归因：

• lsof -p <PID> | wc -l：对比ulimit -n，判断是否文件描述符耗尽。
• cat /proc/<PID>/limits | grep "Max open files"：确认进程级限制。
• strace -p <PID> -e trace=open,connect,sendto,recvfrom -s 100：抓关键系统调用，看是否在反复连接失败或读取超时。

终极心法：
第五层不是终点，而是闭环的起点。当你用async-profiler发现90%时间花在com.xxx.service.UserService.getUserById，下一步必须回到代码：查getUserById的SQL是否缺少索引？查Redis缓存key是否设计成user:id:123导致穿透？查HTTP客户端是否设置了Connection: close？性能问题的根因，永远在业务逻辑与基础设施的交界处。工具只是手电筒，光打在哪，取决于你对业务的理解深度。

4. 实操过程全记录：一次真实的线上CPU飙高故障复盘

4.1 故障现象与初始响应（00:00-00:03）

凌晨0点，某支付网关告警：gateway-serviceCPU使用率持续高于90%，持续10分钟。值班同学收到企业微信消息，第一反应是kubectl top pod，发现Pod CPU limit 4核，usage 3.8核，接近打满。他SSH登录对应节点，执行：

# 习惯性top，看到java进程排第一 top -b -n1 | head -20 # 输出：PID 12345 java 98.2% CPU...

此时，他犯了第一个错误：直接kill -9 12345重启服务。服务短暂恢复，但3分钟后CPU再次飙升。这违反了排查铁律：故障期间，禁止任何变更，先保现场。

4.2 第一层扫描：系统级快照（00:03-00:08）

我接手后，第一件事是收集基础快照：

# 同时执行，保存到文件 date >> /tmp/perf-$(date +%s).log uptime >> /tmp/perf-$(date +%s).log free -h >> /tmp/perf-$(date +%s).log vmstat 1 5 >> /tmp/perf-$(date +%s).log iostat -x 1 5 >> /tmp/perf-$(date +%s).log ss -s >> /tmp/perf-$(date +%s).log

关键发现：

• uptime：load average 12.5, 11.8, 10.2 （8核机器，明显过载）
• vmstat：r列（运行队列）持续在15-20，cs（上下文切换）高达25000/s（正常<5000）
• iostat：%util仅35%，await8ms，排除磁盘瓶颈
• ss -s：total 12000 connections，其中TIME-WAIT8500，ESTAB3200

结论：CPU过载，但非IO导致；连接数高，TIME-WAIT多，疑似网络连接问题。

4.3 第二层聚焦：进程级深挖（00:08-00:15）

# 查看java进程的详细CPU分布 pidstat -u -p 12345 1 5 # 输出：%usr 15%, %system 82%, %wait 0% # 系统态CPU过高！查系统调用 strace -p 12345 -c -s 100 2>&1 | head -20 # 输出：% time seconds usecs/call calls errors syscall # 92.12 0.123456 1234 1000 epoll_wait # 5.23 0.005678 56 100 futex

epoll_wait占比92%，说明进程大部分时间在等事件，但%system又高达82%——矛盾！继续查：

# 看线程级CPU top -H -p 12345 -b -n1 | head -20 # 发现线程PID 12346 占用85% CPU，且状态为R（Running） # 抓该线程的栈 jstack 12345 | grep -A 20 "12346" # 输出：... at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) # at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) # at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)

真相浮现：Java NIO Selector在epoll_wait，但%system高，说明内核在处理epoll事件时开销大。查/proc/12345/status：

cat /proc/12345/status | grep -E "Threads|SigQ" # Threads: 200 # SigQ: 1024/122880 <-- 信号队列已用1024，上限122880

信号队列没满，排除信号积压。再查：

# 看epoll监听的fd数量 ls -l /proc/12345/fd/ | wc -l # 输出：12000+ <-- 远超ulimit -n 65536? 不，是ulimit -n 1024!

ulimit -n仅为1024，但进程打开了12000+ fd！strace显示大量epoll_ctl(EPOLL_CTL_ADD)返回EMFILE（打开文件数过多），内核被迫在epoll_wait返回前做大量错误处理，导致%system虚高。

4.4 第三层验证：资源级确认（00:15-00:20）

# 确认ulimit cat /proc/12345/limits | grep "Max open files" # Max open files 1024 1024 files # 查看哪些fd是socket ls -l /proc/12345/fd/ | grep socket | wc -l # 11980 sockets # 查看socket状态分布 ss -tan state established | wc -l # 3200 ESTAB ss -tan state time-wait | wc -l # 8500 TIME-WAIT

确认：应用创建了海量连接，但未正确复用或关闭，ulimit -n过低导致epoll_ctl频繁失败，内核陷入错误处理循环。

4.5 第五层归因：代码与配置修复（00:20-00:30）

• 代码层：审计发现，HTTP客户端未配置连接池，每次请求新建HttpClient，且未调用close()。
• 配置层：JVM启动参数未设置-XX:MaxFDLimit，无法突破系统ulimit。
• 系统层：/etc/security/limits.conf中* soft nofile 65536未生效，因服务由systemd启动，需在/etc/systemd/system/gateway.service中加：

  [Service] LimitNOFILE=65536

修复步骤：

1. 紧急：prlimit --nofile=65536 --pid 12345临时提升限制；
2. 代码：引入Apache HttpClient连接池，设置maxConnPerRoute=20,maxConnTotal=200；
3. 配置：更新systemd service文件，重载并重启；
4. 验证：curl -s http://localhost:8080/actuator/metrics/http.client.requests | jq '.measurements[].value'，确认请求数平稳。

效果：CPU从98%降至15%，epoll_wait占比从92%降至5%，%system从82%降至8%。故障根除。

5. 常见问题与独家排查技巧实录

5.1 “CPU使用率100%但找不到高CPU进程”——幽灵CPU问题

现象：top显示CPU 100%，但所有进程%CPU加起来不到20%。

排查路径：

• mpstat -P ALL 1：看是否单个CPU核心100%，其他核心idle。若是，可能是该核绑定的中断过于密集。
• cat /proc/interrupts | grep -E "(eth|nvme|ahci)"：看网卡/NVMe中断是否集中在某CPU。某次eth0中断90%落在CPU0，执行：

  # 将eth0中断均衡到所有CPU echo ffffff > /proc/irq/$(cat /proc/interrupts | grep eth0 | head -1 | awk '{print $1}' | sed 's/://')/smp_affinity_list

• perf record -e cycles,instructions -a -- sleep 10 && perf report：看[kernel.kallsyms]下的函数，如native_safe_halt（CPU空转）、cpuidle_enter_state（空闲状态），确认是否在空转。

独家技巧：用stress-ng --cpu 1 --timeout 10s制造可控CPU负载，对比perf report输出，建立“健康基线”。

5.2 “内存充足但频繁OOM Killer”——内存碎片化陷阱

现象：free -h显示available4GB，但dmesg持续报Out of memory: Kill process java。

根源：内核内存管理中，kmalloc分配小内存（<128KB）走slab，大内存（>128KB）走buddy system。当buddy system中order-3（8页）及以上连续内存块不足时，即使总内存充裕，也会OOM。

验证命令：

# 查看buddy system各阶空闲页数 cat /proc/buddyinfo # 输出：Node 0, zone DMA 123 45 23 12 5 2 1 0 0 0 0 # Node 0, zone Normal 567 234 102 45 12 3 0 0 0 0 0 # 关键看最后一列（order-10，4MB块），若为0且`PageAlloc`失败日志多，则是碎片化 # 查看内存碎片指数 cat /sys/kernel/debug/extfrag/extfrag_index # 值越接近0，碎片越严重

解决方案：

• 临时：echo 1 > /proc/sys/vm/compact_memory触发内存整理；
• 长期：调整vm.min_free_kbytes（增大预留内存，减少碎片），或启用CONFIG_COMPACTION=y内核配置。

5.3 “网络延迟高但ping正常”——TCP栈参数失配

现象：ping延迟<1ms，但curl请求耗时3秒，ss -i显示rto从200ms涨到2000ms。

排查重点：

• sysctl net.ipv4.tcp_rmem：rmem_default应≥应用接收缓冲区，否则recv()阻塞；
• sysctl net.core.rmem_max：必须≥tcp_rmem第三值，否则setsockopt(SO_RCVBUF)失败；
• ss -i的rcv_space：若远小于rmem_default，说明应用未调用setsockopt(SO_RCVBUF)或内核限制。

实操技巧：
用tc qdisc add dev eth0 root netem delay 100ms在测试环境模拟高延迟，观察ss -i中rto变化规律，反向推导生产环境参数。

5.4 “磁盘IO等待高但iostat不报警”——队列深度幻觉

现象：iostat -x显示%util40%，await15ms，但应用日志报“DB query timeout”。

真相：%util是设备忙时间占比，对SSD意义不大；await是平均等待时间，掩盖了长尾。某次NVMe盘await12ms，但P99延迟达500ms。

破局工具：

• iostat -x -d 1：加-d显示设备名，避免RAID虚拟设备干扰；
• blktrace+biolatency.py（bcc工具）：生成IO延迟直方图，看P99/P999；
• cat /sys/block/nvme0n1/queue/nr_requests：检查队列深度，NVMe默认256，可调至1024。

我的经验：对SSD，await参考价值低，紧盯biolatency.py输出的usecs列，>100000（100ms）即需干预。

5.5 “排查步骤执行完仍无解”——终极兜底方案

当五层漏斗都走过，问题依旧，按此清单逐项核对：

1. 确认时间同步：ntpq -p，时间不同步会导致SSL证书校验失败、分布式锁异常；
2. 检查SELinux/AppArmor：sestatus，ausearch -m avc -ts recent，权限拦截常表现为“Operation not permitted”；
3. 验证硬件健康：smartctl -a /dev/sda（磁盘）、ipmitool sensor（服务器传感器）、memtester 1G 1（内存压力测试）；
4. 内核版本陷阱：uname -r，某些老内核（如3.10.0-327）有已知调度器bug，升级内核是唯一解；
5. 容器逃逸嫌疑：ls -l /proc/1/ns/，对比宿主机/proc/1/ns/，若不一致，可能被容器逃逸攻击。

最后分享一个小技巧：把本文的五层漏斗做成一张A4纸速查表，贴在显示器边框。每次故障，就按表打钩，强迫自己不跳步。我带过的十几位新人，用这个方法，平均故障定位时间从2小时缩短到20分钟。技术没有捷径，但有经过验证的路径。