SRE面试新手必学：Linux网络调试命令（tcpdump/ss/iptables）实战
一句话总结
SRE面试里讲不清tcpdump过滤表达式的人，不是技术不够，是从来没被面试官打断过。真正决定录用与否的，不是你背过多少参数，而是你在压力下能否从现象倒推网络拓扑、定位责任边界、给出可验证的下一步。这不是一场命令默写考试，而是一次生产故障的桌面推演——面试官在找的是"凌晨三点被pager吵醒后能稳住局面"的人，不是"考前突击了三天man page"的人。
适合谁看
三类人最需要把这篇文章读完。
第一类是正在准备Google、Meta、Amazon SRE岗位的新手。这些公司的面试流程高度标准化，但标准本身从不公开。你不知道的是，同一轮System Design之后往往跟着一轮"Live Debugging"，面试官会共享一个终端让你现场排查。
我见过候选人在这一轮用tcpdump抓到了包却读不懂TCP flags，整场面试急转直下。不是他不懂TCP handshake，而是他把面试当成了开卷考试，没有准备"边说边做"的节奏。这类人需要的不是更多命令，而是一套在压力下仍能输出结构化诊断的思维惯性。
第二类是从开发转SRE的工程师。他们通常写过网络代码，甚至在本地用Wireshark分析过问题，但对生产环境的调试工具链缺乏肌肉记忆。开发环境和生产环境的根本差异在于：你不能停服务、不能随意改配置、不能假设有GUI。一个典型的场景是：开发时你双击打开Wireshark，生产环境下你只有ssh和一个CPU使用率已经飙到80%的节点。
iptables规则链是否影响了你的抓包？ss的输出里哪些状态暗示了连接泄露？这些不是"也学学看"的边缘知识，是SRE日常工作的核心工具。
第三类是工作三年以内、正在经历第一次跳槽的SRE。他们的危险在于"会的不考，考的不熟"。日常用惯了的工具可能是公司封装过的内部平台，面试时突然被问到"原生Linux命令"反而生疏。更隐蔽的陷阱是：他们能解决实际问题，但无法把解决过程翻译成面试官能听懂、能打分、能写进hire packet的叙事。面试不是展示你有多忙，而是展示你的判断有多快、多准、多可复制。
薪资参考：硅谷SRE岗位，base $130K-$220K，RSU $50K-$300K/年（四年 vest），bonus 10%-20% of base。总包区间约$200K-$500K，Staff级别以上可突破$700K。
为什么面试官总在tcpdump之后追问"你确认抓到了所有包吗"
这个问题不是技术追问，是判断候选人是否理解网络调试的第一性原理。
大多数候选人的第一反应是打开tcpdump开始抓，抓到SYN就点头，抓到RST就下结论。不是A，而是B：面试官不是在测试你的命令熟练度，而是在测试你对"sampling bias"的敏感度。生产环境的网络流量可能经过VLAN、经过负载均衡的SNAT/DNAT、经过容器网络的veth pair——你在这个节点抓到的包，和那个节点抓到的包，未必是同一回事。
一个有过真实on-call经验的候选人会在执行tcpdump之前先问："我能确认一下这个节点的网络命名空间吗？这个流量是经过iptables NAT规则之后的还是之前的？"
更深一层的问题在于时间窗口。不是"我抓到了包"，而是"我在正确的时间窗口以正确的过滤条件抓到了代表性的包"。
tcpdump的默认buffer大小在高压流量下会丢包，-B参数调的是kernel buffer而不是tcpdump自己的buffer，这个区别在面试里被追问到的概率超过七成。一个候选人如果不知道kernel buffer和tcpdump ring buffer的区别，面试官会在心里标记：这个人可能在生产环境漏掉过关键包，只是没被发现。
2019年我在一个debrief会议上听到两个面试官争论一个候选人的去留。候选人在live debugging环节用tcpdump抓到了客户端发来的SYN，但服务端没有响应SYN-ACK。他立刻结论是"服务端进程挂了"。
反对录用的面试官提出：候选人没有检查iptables是否drop了包，也没有用ss -s看syn backlog是否已满。最终这个候选人被给了weak no-hire，理由是"在证据链不完整时过早下结论，这是SRE的大忌"。不是命令问题，是判断问题。
> 📖 延伸阅读：BCG产品经理面试真题与攻略2026
ss命令的输出里，面试官真正想看懂什么
ss -tlnp的输出有十几列，大多数候选人会一行行念过去。不是A，而是B：面试官不在乎你念对了多少列，他在乎的是你能否从输出中识别出"异常模式"并给出优先级排序。
一个具体的面试场景：面试官给你看一台服务器的ss输出，显示大量TIMEWAIT状态的连接，同时Listen队列有溢出。新手常见的错误是立刻开始调net.ipv4.tcptwreuse，这是开发思维——看到问题就改参数。SRE的思维是：TIMEWAIT是结果，不是原因。需要回答的是：这些TIME_WAIT是从哪个上游来的？
是正常的高峰流量还是某个客户端的异常行为？Listen队列溢出是发生在所有端口还是特定端口？如果是特定端口，那个端口的应用处理逻辑是什么？
我在Google的面试培训中听过一个标准：candidate's narrative arc。意思是候选人需要展示一个完整的诊断弧线，而不是散落的知识点。
用ss的时候，这个弧线通常是：先看连接状态分布（ss -s）→ 定位到异常状态的端口 → 看该端口的详细连接（ss -tan | awk）→ 结合进程信息（ss -tanp）→ 提出可验证的假设。跳过任何一步都可能被打断追问。
另一个反直觉的观察：ss比netstat快，不是因为代码写得好，是因为ss直接读取/proc/net/tcp等内核结构，绕过了netstat的/proc遍历。但面试里被问到"为什么推荐用ss而不是netstat"时，背出这个事实只能得30分。满分回答是：ss的-s选项可以快速给出统计摘要，适合在高压场景下快速判断；
而netstat的-a输出在连接数上万时会产生明显的CPU和IO开销，这在生产环境可能是二次伤害。不是"ss更快"，而是"ss在特定场景下的性能特征更适合SRE的工作模式"。
iptables不是防火墙配置，是责任边界判定工具
这是最容易被误解的一点。候选人花大量时间背iptables的表（table）和链（chain）结构，却不懂面试官为什么要问这个。
真实的面试场景往往这样展开：面试官描述一个故障——"用户报告无法访问服务，但服务进程本身健康检查通过"。候选人如果直接说"我检查一下iptables规则"，方向是对的，但深度不够。面试官期待的是：你能否快速区分"这是平台层的问题还是应用层的问题"。
iptables规则的存在本身就是责任边界的物化——平台团队负责NAT和转发规则，应用团队负责端口监听和业务逻辑。一个SRE的价值不在于他能改多少条规则，而在于他能用iptables的输出来证明"问题不在我这一层"。
不是"我会配置iptables规则"，而是"我能用iptables -t nat -L -n -v --line-numbers的输出证明包有没有被转发、被修改、被丢弃"。具体来说，-v参数显示的计数器是关键证据：如果PREROUTING链的计数器在增加但POSTROUTING没动，说明包被中途drop了；
如果DNAT规则匹配了但后端没有响应，那问题在下游。这些计数器是面试中的"物证"，比任何口头描述都有说服力。
一个hiring manager曾在我参与的HC讨论中说了一句话，我记到现在："我要招的是能在工单系统里写清楚'经排查，iptables规则匹配如下，排除平台层问题，转交应用团队'的人，不是会背-J DROP语法的人。"这句话点破了iptables考察的本质：不是配置能力，是工程写作能力，是在多方协作中定位责任的能力。
> 📖 延伸阅读：Bain产品经理行为面试STAR回答范例2026
面试流程拆解：每一轮到底在考什么
recruiter screen（30分钟）
不是技术面试，是信号筛选。recru会确认你的背景匹配度，同时试探你的沟通清晰度。一个常见的问题是"描述一次你调试网络问题的经历"。这里的关键词不是"网络问题"，是"描述"——他在测试你是否能用非技术语言把技术问题讲清楚。回答结构建议：业务影响 → 你的行动 → 结果量化。不要技术细节轰炸，recru听不懂，也不会给你转述给hiring manager。
phone screen（45-60分钟）
通常是现场编码或命令行操作。对于SRE岗位，这一轮常考的是"给你一个场景，现场用Linux命令诊断"。典型题目：服务响应慢，你有一台可以ssh的跳板机，从哪几个命令开始？
不是考你知道多少命令，是考你的诊断思路是否结构化。一个高分的回答框架：先确认现象（curl/wget测连通性）→ 看连接状态（ss）→ 抓包确认（tcpdump with filters）→ 检查中间层（iptables/nftables）→ 给出假设和验证计划。
onsite/virtual onsite（4-5轮，每轮45-60分钟）
- System Design轮：设计一个高可用服务，网络部分需要讨论LB策略、健康检查机制、故障隔离。不是画架构图漂亮，而是能说出"如果健康检查失败，tcpdump如何验证是LB没发请求还是后端没响应"。
- Troubleshooting/Live Debugging轮：共享终端，现场排查。这是tcpdump/ss/iptables最直接被考察的轮次。关键不是解决多快，是过程中是否展示了假设-验证-调整的闭环。
- Coding轮：Google可能考SRE写Python/Go脚本处理日志或监控数据。不是LeetCode hard，是实际工作中会遇到的文本处理和数据聚合。
- Behavioral轮（Googliness/Leadership Principles）：Amazon的LP轮会深挖"你如何处理没有明确责任归属的问题"。一个好的故事框架：用iptables的例子说明你如何界定边界、收集证据、推动解决。
- Hiring Manager轮：不是技术测试，是动机和团队匹配。会问"你为什么想做SRE而不是SWE"。不是"我喜欢稳定性"，而是"我发现在高压力下快速定位边界问题的成就感，超过了写新feature的成就感"。
debrief
所有面试官聚在一起，用标准维度打分。对于SRE，常见的维度包括：technical competence, troubleshooting approach, communication under pressure, ownership。
不是"你答对了多少题"，而是"你在压力下展示了哪些可迁移的能力"。一个候选人如果在live debugging中展示了结构化的排查思路，即使最终没有定位到root cause，也可能因为"approach"维度的高分而通过。
准备清单
- 在本地或云主机上搭建一个三节点环境（client → LB → server），亲手复现一次完整的TCP握手、一次connection refused、一次SYN flood导致的backlog溢出。不是"看过文档"，而是"肌肉记忆"。
- 用tcpdump分别抓一次HTTP和HTTPS流量，对比明文和TLS handshake的差异。重点不是看到什么，而是能解释"为什么在production调试HTTPS问题时tcpdump的价值有限，以及此时应该转向什么工具"。
- 系统性拆解面试结构，PM面试手册里有完整的SRE live debugging实战复盘可以参考——特别是关于如何在时间压力下保持诊断节奏的部分，不是让你背答案，是让你理解"面试官在听什么"。
- 准备三个自己的"网络调试故事"，分别对应：快速定位（15分钟内解决）、复杂排查（跨团队，涉及多个网络跳跃）、事后复盘（发现了监控盲区）。每个故事按 storytelling 结构打磨：背景一句话 → 你的行动三句话 → 结果量化一句话。
- 手写一遍iptables的三表五链结构图，然后遮住它，在白板上凭记忆画出来。面试中的白板题不是考你画得好看，是考你在压力下的心智模型是否稳定。
- 找一名同行做mock interview，让对方在过程中故意打断你、质疑你、给你矛盾的信息。训练的不是知识，是"被打断后如何优雅地回到主线"的能力。
- 整理一份"面试急救包"——一张纸写下你最可能忘的命令参数和它们的典型使用场景。不是带进考场（当然不行），是在考前反复翻阅形成条件反射。
常见错误
错误一：把tcpdump当拍照工具，不是当证据链
BAD版本：
> "我用tcpdump抓了一下，看到有SYN包，所以客户端是正常的，问题在服务端。"
GOOD版本：
> "我先用tcpdump -i any -n host $clientip and port $serviceport确认了客户端确实发出了SYN，且seq号连续。然后我在服务端同一时间点抓包，没有看到对应的SYN到达。中间经过了LB，我检查LB的iptables计数器，发现DNAT规则匹配数在增加但后端连接数没有对应增长。因此我的假设是LB到后端的网络路径存在问题，下一步我会检查LB的conntrack表是否溢出。"
区别不是信息量，是"假设-证据-下一步"的闭合结构。面试官在听的是：你是否能在信息不完整时管理不确定性，而不是假装确定。
错误二：ss和netstat混用却不自知
BAD版本：
> "我用netstat看了一下，有很多TIME_WAIT。"
GOOD版本：
> "我先用了ss -s快速看了整体状态分布，发现TIME-WAIT有12万，接近历史基线的两倍。然后用ss -tan '( dport = :443 or sport = :443 )' time-wait | head 确认了主要是443端口的连接。结合业务日志，这个时间点刚好是每日批处理任务结束、大量短连接释放。我的判断是正常业务波动，但建议增加twreuse和降低twbucket以加快回收。"
不是"用ss更酷"，而是"我选择ss是因为它的-s输出适合快速判断规模，而netstat在这个连接量级下会阻塞"。这个选择本身就在展示你的生产经验。
错误三：iptables问题定位时越过边界
BAD版本：
> "我发现iptables有一条规则drop了包，我把它删掉了，问题解决了。"
GOOD版本：
> "这条规则在INPUT链的第5条，匹配了来自10.0.0.0/8的到8080端口的流量，动作是DROP，计数器显示在过去一小时匹配了3400次。这条规则没有注释，我检查了git history发现是三个月前一个紧急变更，但相关ticket已经关闭。我的建议是：先临时注释这条规则验证恢复，同时创建follow-up ticket要求规则 owner 补充注释和监控，避免再次踩坑。"
不是"解决了问题"，是"解决了问题且展示了组织意识"。SRE不是独行侠，是在规则中运作的人。
FAQ
"我日常工作中都用公司自研的平台，原生命令不太熟，面试会吃亏吗？"
会，而且这是可以预见的吃亏。不是A，而是B：面试官不是不知道大公司有内部工具，他在测试的是你能否在工具失效时回到第一性原理。一个真实的场景：某候选人的内部监控平台在面试模拟中"假设不可用"，他立刻慌了，因为平时看习惯了dashboard，从没想过底层数据从哪来。
准备建议是：每周抽一小时，故意不用内部平台，只用原生Linux命令完成一次常规检查。不是为了替代工具，是为了理解工具的局限。
"面试官问了一个我不知道的命令参数，我应该直接说不知道，还是试着猜？"
直接说不知道，但要有结构。一个高分回答的模板："这个参数我暂时没有用过，但从命名来看它可能是控制XX行为的。如果我在生产环境遇到需要它的场景，我会先查man page确认语义，然后在测试环境验证，最后再应用到生产。
"不是展示你知道，而是展示你"不知道时如何安全地学习"。面试官更怕的是瞎猜导致生产事故的人，不是诚实承认盲区的人。一个反直觉的数据点：我在debrief中听到的"诚实承认"案例，通过率高于"勉强猜测"案例。
"Live debugging环节时间很紧，我应该追求定位到root cause，还是展示完整的排查思路？"
展示完整的排查思路，但要有意识地管理面试官的预期。一个技巧是：在开始排查前先说"基于当前信息，我计划按X-Y-Z的顺序排查，如果时间允许我会深入到root cause，如果中途发现关键线索我会优先验证"。这不是在找借口，是在展示项目管理能力。
一个真实的反面案例：候选人花了35分钟深挖一个最终证明是red herring的方向，最后5分钟才发现真正的问题，但已经没有时间验证。他的技术能力被认可，但"时间管理和优先级判断"维度得了低分，最终是marginal no-hire。不是"做得多深"，而是"在有限时间内做出最优判断"。
SRE面试的本质不是筛选"会最多命令的人"，是筛选"在信息不完整、时间有限、压力存在的条件下，仍能做出可靠判断的人"。tcpdump、ss、iptables是工具，工具背后的思维模式才是考察对象。准备时少背参数，多练"如果我现在被打断，我刚才说的哪一句是关键假设"。这句话练清楚了，面试就过了大半。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。