那年秋招网易的网申页面刚开放我就抱着“试试不亏”的心态投了技术支持岗。结果一周后收到的笔试通知让我瞬间清醒岗位写着“技术支持”但笔试里对计算机网络、操作系统、数据库和编程基础的考察一点都不比研发岗轻松。当时我对着屏幕上有零有整的三个小时倒计时硬着头皮做了整套卷子靠的完全是大学里攒下来的那点底子。现在回头看这场笔试其实很典型它不像算法岗那样死磕 LeetCode 难题也不像产品岗那样考一堆主观论述它的核心逻辑是——考察一个工程师能不能坐在“技术支持”这个位置上用底层原理去解决真实线上问题。如果你正准备投互联网公司技术支持、运维开发这类偏基础设施的岗位网易这套题的质量算相当高的。这篇文章我就把当时考场上的真实感受、题型分布、记忆里最有代表性的几道题以及考后复盘总结出来的备考思路完整拆一遍。不是为了让你背答案而是帮你理解“技术支持笔试到底在筛什么样的人”。1. 整体题型结构与考点分布复盘1.1 三个小时里到底考了些什么网易2020校招正式批的技术支持笔试设置时长通常是120到180分钟之间我拿到的卷子是150分钟。整张卷子大致分成四大块单选/多选客观题、基础编程题、SQL结构化查询语言编写题、线上故障/场景分析题。比例上客观题和编程题占了六成多剩下的是需要你用文字完整表述排查思路的场景题。客观题覆盖的内容非常“计算机基础”基本把大学阶段的核心课程给串了一遍计算机网络里的 TCP/IP传输控制协议/网际协议分层和三次握手操作系统里的进程调度和内存管理Linux 文件权限和常用命令还有少量数据结构的基础概念。选择题里还有一部分是“综合素质题”类似行测里的逻辑推理和数列找规律这部分不太需要专门复习主要是考察你在时间压力下的临场反应。编程题一般是两道难度不高但很考察“手速”和“边界意识”。一道偏逻辑类比如字符串处理或数组计算一道偏数据结构类比如链表或栈队列的应用。SQL 题一般给你一张或者两张表让你写出满足条件的查询语句需要熟悉 GROUP BY分组、HAVING过滤分组、子查询、JOIN连接这些常用写法。最后压轴的通常是“故障排查”或“方案设计”题比如“用户反馈网页打不开请列出你的排查步骤”或“某业务突然变慢如何定位性能瓶颈”。这类题没有标准答案但非常吃经验。阅卷人想看到的不是一个点一个点零散地蹦原因而是你脑子里有一套清晰的“从底层到应用、从网络到代码”的排查链。1.2 为什么“技术支持”岗要考这么硬核的内容很多同学看到“技术支持”四个字容易联想到客服觉得就是接接电话、记记工单所以备考时往往把重点放在“沟通话术”和“客户服务”上。但网易这种级别的互联网公司对技术支持岗的定位是“技术型岗位”它要求你能独立定位线上事故、能看懂业务日志、能处理高并发场景下出现的各种异常。换句话说技术支持是研发团队和生产环境之间的一道重要防线。这个岗位的人如果不懂 TCP 握手状态就没法判断连接堆积在哪一层如果不懂数据库索引原理就没法解释慢查询为什么会拖垮整个接口如果不会写简单的脚本就只能手动处理重复的运维工作效率完全跟不上。所以笔试设计成这个样子本质就是在捞人捞那些虽然本科不是顶尖学霸但底层知识扎实、遇到问题能动手解决的人。当时我身边有同学因为觉得“网易技术支持”好进裸考就去做了卷子结果客观题里光网络层的题就错了一半。所以别轻视岗位名字里的“技术”两个字它的笔试难度和招聘官网上的“职位要求”栏是严格对齐的。2. 计算机网络与操作系统核心题精解2.1 TCP 三次握手与状态迁移一道绕不开的必考题计算机网络部分最常出现的题目之一就是 TCP 的三次握手。网易这套卷子里它不只是让你默写“SYN同步序列编号、SYNACK同步确认ACK确认”三个步骤而是把问题包装得更贴近实际。卷子里的回忆版本大概是这样的“系统维护人员抓包发现服务器上存在大量 SYN_RECV 状态的连接请分析该现象可能产生的原因并说明如何排查。”这题的价值远高于死记硬背因为它直接引出了“半连接队列”和“SYN Flood同步洪泛攻击”这两个知识点。SYN_RECV 状态意味着服务器已经收到了客户端的 SYN 报文并发出了 SYNACK 响应但一直没有收到客户端的 ACK 确认。正常情况下这个状态只会持续很短的时间。如果这种连接堆积大量出现原因大概有三种客户端确实因为网络问题丢失了服务器的 SYNACK 报文导致客户端一直处于 SYN_SENT 状态无法完成握手。服务器端的半连接队列长度设得过小导致新连接请求被丢弃客户端不断重传 SYN服务器持续处于 SYN_RECV 状态。更恶性的是有人恶意伪造大量不存在的源 IP 地址发起 SYN 请求服务器发出的 SYNACK 永远得不到回应半连接队列被填满这就是经典的 SYN Flood 攻击。排查思路我是这么写的先在服务器上用netstat -antp | grep SYN_RECV | wc -l统计数量再用ss -s看当前 TCP 套接字分布。如果 SYN_RECV 数量持续上涨且来源 IP 段很散就要考虑是否遭受了攻击可以看netstat -an | awk /SYN_RECV/{print $5} | cut -d: -f1 | sort | uniq -c | sort -rn判断是否来自同一个源。如果来源分散基本可以确定是外部恶意请求需要配合防火墙策略比如限制单个 IP 的连接速率或者开启内核参数net.ipv4.tcp_syncookies 1来应对半连接攻击。其实这类题看起来是在考网络协议实际考察的是你“能不能把状态机理解和生产环境的现象联系起来”。技术支持岗日常打交道最多的就是各种异常状态所以备考时不能只记协议的“正常流程”还要去理解“每个状态停留时间过长意味着什么”“哪些参数可以干预这些状态”。2.2 HTTP 状态码看似送分实则暗藏陷阱选择题里有一道关于 HTTP 状态码的题题干很简短“用户在浏览器访问某链接时返回 302 重定向。以下描述正确的是”选项里有几个比较迷惑的“浏览器会直接展示返回内容”“搜索引擎会将该页面视为永久迁移”“该状态码表示资源未修改可以直接使用缓存”“浏览器会重新发起一次 GET 请求到 Location 字段指向的地址”。正确项显然是最后一个。302 是临时重定向服务端在响应头里携带Location字段浏览器接收到之后会重新向这个地址发起请求。而 301 才是永久重定向搜索引擎才会把链接权重传递到新地址。另外状态码 304 表示“未修改”浏览器可以继续用本地缓存这个和 302 完全不是一回事。复习 HTTP 状态码时我建议不要逐个去背最好抓“1xx 提示、2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务端错误”这条主脉然后重点记常见几个200、301、302、304、400、401、403、404、500、502、503。如果你准备的是技术支持岗502 和 503 一定要会区分502 Bad Gateway 意思是网关或代理从上游服务器收到了无效响应本质是“上游挂了”503 Service Unavailable 是服务暂时不可用一般是因为过载或者停机维护本质是“自己这边扛不住了”。2.3 操作系统进程与线程的经典辨析操作系统部分的题也不是让你直接背概念。卷子里的原题大意是“在 Linux 系统中以下哪种方式创建的子进程不共享父进程的内存空间考察 fork 与线程模型”这个题其实在辨析fork()和线程创建的区别。fork()创建的是进程采用写时复制技术Copy-on-Write刚创建出来的子进程拥有独立的内存地址空间父子进程内存互不干扰而线程则共享进程的内存空间包括堆、全局变量和代码段但各自拥有独立的栈和寄存器上下文。我在答题卡上还补充了“进程间通信”的几个常见手段其实这属于送分题了但你如果只是机械地记住“线程开销小、进程开销大”面对这种变形题就很容易拿不准。更合理的理解方式是资源分配的单位是进程CPU 调度的单位是线程。进程是“独立王国”有自己的一亩三分地线程是“合租室友”共享客厅和厨房但也因此需要处理同步、死锁这些麻烦事。这提醒了一件事备考操作系统光背书是不够的最好能结合 Linux 的命令行工具去理解。比如用ps -eLf可以看到线程 PIDTID用top -H可以单独观察某个线程的 CPU 占用。当你真正在命令行里“看到”过进程和线程的差异笔试里的选择题就再也难不住你了。3. SQL 编写与编程基础逻辑解析3.1 学会用 HAVING 和子查询SQL 笔试必带“武器”网易的 SQL 题一向走实用路线不考偏题怪题。我遇到的那道题基本结构是下面这样有两张表。一张是学生表student字段有id、name另一张是成绩表score字段有id、student_id、course_name、score_value。具体要求是“查询所有平均分大于 80 分的学生姓名并按平均分从高到低排序。”这是一个非常经典的聚合查询重点是区分WHERE和HAVING的使用场景。WHERE是在分组之前对原始记录进行过滤而HAVING是在分组聚合之后对组进行过滤。这里因为条件涉及“平均分”必须在GROUP BY之后过滤所以只能用HAVING。我的答案是这样的SELECT s.name, AVG(sc.score_value) AS avg_score FROM student s JOIN score sc ON s.id sc.student_id GROUP BY s.id, s.name HAVING AVG(sc.score_value) 80 ORDER BY avg_score DESC;注意几个容易踩的坑。第一GROUP BY里不能只写s.id虽然大多数数据库支持“函数依赖”的简写但规范的做法是GROUP BY s.id, s.name避免在 only_full_group_by 模式下报错。第二ORDER BY后面最好不要直接用AVG(sc.score_value)而是使用别名avg_score这样更直观且不容易出错。第三如果题目要求“每门课都大于80分”就不能用HAVING AVG而是要用COUNT加条件判断比如SELECT s.name FROM student s JOIN score sc ON s.id sc.student_id GROUP BY s.id, s.name HAVING COUNT(CASE WHEN sc.score_value 80 THEN 1 END) 0;这些细微的差别恰恰是笔试阅卷时区分“会背 SQL”和“会写 SQL”的关键。考场时间紧张不少人一看到“平均分”就直接写 WHERE忽略了分组过滤的语义白丢一道大题的分非常可惜。3.2 编程题字符串处理背后的“边界控制”能力编程题方面网易技术支持岗的难度大约在“剑指 Offer 简单到中等”之间。我抽到的题是“给定一个字符串找出最长公共前缀如果不存在则返回空字符串。”这题本身不难但很考细节。核心思路是“纵向比较”拿第一个字符串作为基准逐一和其余字符串的相同位置字符比较。写的时候要注意三个边界字符串列表为空时返回空串列表里存在空字符串时返回空串比较过程中一旦出现不匹配或某个字符串长度小于当前索引立即返回已经匹配的部分。下面是我在草稿纸上整理的思路最后敲出来的代码大概是这样的def longest_common_prefix(strs): if not strs: return prefix strs[0] for i in range(1, len(strs)): while strs[i].find(prefix) ! 0: prefix prefix[:-1] if not prefix: return return prefix这里用的技巧是“横向扫描”每次拿当前公共前缀和下一个字符串比较不断缩短前缀直到它成为下一个字符串的前缀。find() ! 0是在检查前缀是否出现在字符串开头。这个方法虽然时间复杂度不是最优但代码简洁在笔试环境下不容易出 bug。如果你遇到的是链表反转、括号匹配这类题也别慌。技术支持岗的编程题只要求你“能写出可用代码”不要求“最优解法”。但要注意能跑通和格式规范是两回事提交前一定要检查边界条件比如输入为None、空字符串、长度为一的列表等。我在那次笔试里就碰到一道题我主逻辑一次性写对了但漏了判空直接导致前两个用例运行失败扣掉了一半分数。这种教训太深刻了。3.3 简答题让阅卷人一眼看到你的“排查逻辑”除了 SQL 和代码题卷子里还有一些需要文字回答的场景题。比如“请简述从输入 URL 到页面展示的完整过程”以及“一个接口突然变慢如何从系统层面进行分析”。这类题你千万别小看。技术支持岗的日常就是和“现象、原因、解决方案”打交道阅卷人看你的文字回答就是在看你有没有一套成熟的“问题处理思维”。所以回答一定要讲究层次。比如“URL 输入到页面展示”我建议按照下面这条链来组织本地域名缓存浏览器缓存、系统 hosts 文件、本地 DNS 缓存DNS 递归查询从根域名服务器到顶级域名服务器再到权威域名服务器TCP 连接建立三次握手HTTP 请求发送与服务器处理服务器返回响应状态码、响应头、HTML 内容浏览器渲染HTML 解析、CSS 布局、JavaScript 脚本执行写的时候可以用“先本地后远程”“先网络后应用”这样的口诀来帮自己总结。另外还有一个隐藏加分点如果你能在“TCP 连接建立”之后很自然地提到“如果是 HTTPS还需要经历 TLS 握手包括证书校验、密钥交换”这道题的区分度立刻就有了。因为大多数答题者只背了课本上的基础五步能主动补上“现代互联网中 90% 流量都走 HTTPS”的细节说明你真的对线上环境有认知。4. 线上故障排查题应答方法论4.1 用户反馈“网页打不开”的标准化排查流程网易这套题里最压轴的大题是一道开放性的故障排查题。题意大约是“有用户反馈访问某网站首页时一直打不开浏览器转圈很久后提示‘无法访问此网站’。请列出你的排查思路。”这道题考察的其实不是你是不是刚好知道某个故障原因而是你的排查顺序会不会“跳步”。很多同学上来就写“重启服务器”“清缓存”这会让阅卷人觉得你没有成体系的思路。我当时的回答分了四层第一层先判断影响范围。确认是个别用户反馈还是大面积故障。如果是个别人优先考虑用户本地网络、DNS 缓存、浏览器代理设置如果是大面积就要立刻看服务器负载、机房网络、CDN内容分发网络状态以及是否出现流量突刺或安全攻击。第二层从本地链路入手。让用户先ping一下目标域名能通说明网络链路基本没问题再nslookup解析域名确认 DNS 返回的 IP 是否正常如果解析失败就要考虑本地 hosts 文件或电脑上的安全软件拦截。第三层用telnet或curl -I测试目标服务器的 80/443 端口连通性。如果 TCP 端口不通可能是防火墙屏蔽或服务器宕机如果通但一直无响应说明服务进程可能处于半死状态需要用top、ps去查看进程状态。第四层检查服务和应用层。如果网站是 Nginx 加 Tomcat 的结构要逐层看access.log和error.log。比如 Nginx 返回 502说明后端服务挂了返回 504说明网关超时返回 200 但页面空白可能是后端业务代码本身出了异常需要配合 trace 日志来做排查。这种回答方式的价值在于它展示了一条“从面到点、从外到内”的“漏斗式”路径。真正的技术支持工程师接到故障工单之后的第一反应一定不是瞎猜原因而是先做“故障半径”的判断再一层层缩小范围最后定位到具体模块。这个方法论比记住任何一个具体命令都重要。4.2 系统性能排查命令的“组合拳”用法另一道类似的题是给了一个真实场景“服务器 CPU 使用率突然飙升到 100%如何定位是哪个进程导致的并进一步定位到具体代码位置”这题的常规思路是先top看进程 PID再用top -H -p PID查看该进程下哪个线程占用的 CPU 最高然后通过printf 0x%x\n 线程ID把线程 ID 转成十六进制最后用jstack PID | grep -A 20 十六进制线程ID针对 Java 应用来查清是哪个业务线程在疯狂执行。如果是 Python 应用可以用py-spy dump --pid PID直接拿到当前调用栈。另外还要补充一个知识点单独一个进程 CPU 高不代表一定是业务代码问题也可能是频繁 GC垃圾回收导致的。Java 应用可以在启动参数中加上-XX:PrintGCDetails来开启日志或者用jstat -gcutil PID 1000每秒采样一次查看 Yong GC 和 Full GC 频率。如果 Full GC 频繁且老年代一直不释放那十有八九是内存泄漏这时候就要用jmap -dump:formatb,fileheap.bin PID导出堆转储文件用 MAT 分析工具查找大对象和引用链。其实这些排查手段大学课程里完全不会教但却是互联网公司技术支持的“必修课”。我之所以知道这些是因为当时备考时在牛客网上刷了大量面经自己又在虚拟机上搭了一套 Java 应用反复演练jstack和jstat的用法。纸上得来终觉浅这句话在笔试备考里同样适用。4.3 数据库慢查询优化思路一个让阅卷人“眼前一亮”的加分点在场景题里数据库相关的故障也极为常见。我记得有一道附加问是这样的“某导出功能原本执行只要 2 秒今天突然要 20 秒可能是什么原因如何解决”针对这种题我总结了一个“三板斧”回答框架。第一板斧看元数据是否最新ANALYZE TABLE更新统计信息第二板斧查慢查询日志用EXPLAIN分析执行计划看是否命中了索引第三板斧排查锁等待和事务长事务。具体来说EXPLAIN输出里最需要关注的是type字段从好到差依次是const、eq_ref、ref、range、index、ALL。如果看到ALL说明在做全表扫描性能基本不可能好。比如下面的查询EXPLAIN SELECT * FROM orders WHERE user_id 1024 AND status PAID;如果type显示为ALL那就意味着user_id列上没有索引或者优化器认为数据量太小不值得走索引这时候就要考虑给user_id加个普通索引或者建立(user_id, status)的联合索引来覆盖这个查询场景。至于“长事务”它是很多“之前很快、最近突然变慢”类问题的元凶。一个事务如果迟迟不提交它持有的锁就会一直不释放其他事务只能阻塞等待。排查方法是在 MySQL 里执行SELECT * FROM information_schema.innodb_trx\G查看当前未结束的事务并关注trx_started字段一旦发现某个事务已经跑了十几分钟还没结束基本可以断定它在“锁人”了。把这种“从索引优化到事务排查”的多角度分析写进笔试答案里不愁拿不到高分。5. 从真题出发的备考策略与经验清单5.1 用“底层原理”串联知识体系拒绝碎片化记忆考完复盘时我发现一个规律网易技术支持的笔试极其偏爱“背后的为什么”。它很少直接问“TCP 端口号是多少”这类死记硬背的问题而是喜欢问“当大量 TIME_WAIT 出现时服务器为什么变慢”“为什么ping通了但网页仍然打不开”。这意味着你在备考时如果只刷题库、背答案很容易在新题型的包装下乱了阵脚。我建议按“五层协议 两端思维”来整理知识体系。所谓两层思维就是每学一个技术点都要问自己两个问题这一层解决什么问题站在它上面的一层和下面的一层分别依赖我提供什么比如你学到 HTTP就要往下想到 TCP 如何保证连接稳定往上想到浏览器如何解析渲染。这样整理出来的笔记是“网状”的而不是“线状”的。只有网状的知识结构才经得起笔试里各种角度刁钻的提问。5.2 建立“代码 现象 命令”对应关系考前过三遍如果你离考试还有一到两周时间安排可以分批走。第一个阶段花四五天过一遍 Python 或 Java 的基础数据结构不需要刷难题但要把链表的插入删除、栈和队列的互转、字符串的常见操作写成肌肉记忆。第二阶段用两天专门练 SQL 题从最简单的SELECT到JOIN和窗口函数建议直接在牛客网的在线 SQL 题库刷一遍把常用写法练到“不用想就能写出来”。第三阶段留出一天专门背场景题重点不是背答案而是背“排查顺序”和“关键词”。我给自己设计了一个“命令记忆口诀”比如网络不通用ping、traceroute端口不通用telnet、nc进程状态用ps、top日志排查用tail -f、grep性能定位用vmstat、iostat、free。当你把这些命令和对应的故障现象绑定在一起考场上看到“连接超时”“CPU 飙高”“内存不足”这些词时手自然就知道该往哪个方向写。5.3 时间分配与答题技巧别在选择题上恋战再讲一个几乎所有笔试都会遇到的“灵魂问题”时间不够怎么办。网易这套卷子的客观题和主观题是混在一起的很多人容易死磕一两道不会的选择题导致最后一道 30 分的大题只剩五分钟乱写。我当时的策略是先快速扫一眼整张卷子把分值大的主观题标记出来然后严格控制客观题的时长。遇到不会的选择题允许自己最多纠结两分钟没有思路就先凭第一感觉选一个标记下来等最后有时间了再回看。整套卷子我的时间分配大概是客观题 40 分钟、SQL 和编程题 50 分钟、场景题 40 分钟最后留 20 分钟检查。这个分配比例可以根据你的强弱项微调但有一个原则不能动分值越高的题越要确保有充足时间答得完整。因为阅卷是按点给分的你选择题蒙对十道可能才抵得上一道大题的完整逻辑分。5.4 少走弯路的三个“不要”第一不要只刷面经不写代码。编程题是手写代码不是选答案平时不在编译器里跑通考场上很容易出现语法错误自己还不知道。第二不要只背 SQL 标准写法不看执行计划。笔试里“为什么索引失效”这类问法越来越多只背写法不理解底层很容易被追问卡住。第三不要忽视自我介绍和项目经历的梳理。笔试虽然不考但是很多公司的笔试系统里会附带一份“主观问卷”让你简单描述一个自己解决过的技术问题这部分的分数往往会被忽略但它其实能影响你有没有面试机会。第一次见到这种笔试的时候我觉得“技术支持”考这么深属实有点小题大做但后来真进了这个行业才发现生产环境里的故障远比笔试题残酷得多。笔试期间踩过的坑、翻过的书、敲过的代码最后都变成了我在工位前排查问题时的肌肉记忆。如果你正在准备类似的岗位别焦虑把底层打扎实把命令写顺手网易这套题并没有想象中那么神秘。真到了考场上你就把它当成一次正常的“线上故障模拟”按部就班地分析、拆解、回答分数自然会给你正向的反馈。