1. 一场笔试题背后的岗位画像：系统工程师到底在考什么
先说背景。2015年阿里的系统工程师研发笔试题，在当时的求职论坛里流传很广，原因不在于题目有多难，而在于它非常“奇怪”——整套卷子既不完全是开发题，也不完全是运维题，更像是把一名系统工程师一年里要面对的破事浓缩成两个小时。很多人刷完LeetCode去考，直接被第一道Linux启动流程题干懵，然后骂骂咧咧退场。
我自己是2015年秋季参加过这场笔试的，虽然最后没进阿里，但那张卷子给我留下的印象极深。后来我在几家互联网公司做过系统工程师、SRE，再回头看这些题目，才发现当年觉得“偏、怪、不按套路出牌”的地方，恰恰是系统工程师日常工作中真正需要的能力。
先给不太了解这个岗位的读者做个定位。系统工程师在互联网公司里，通常负责的是基础架构层面的工作：操作系统选型和调优、服务器批量交付、网络规划、存储方案、数据库部署与备份、监控告警体系搭建，以及线上故障的排查和应急。它和纯开发工程师的区别在于，开发工程师关心功能怎么实现，系统工程师关心的是系统怎么稳定跑起来、出了问题怎么快速恢复。
所以这套笔试题的核心逻辑，不是考你会不会写某段代码，而是考你有没有能力在一台刚拿到的服务器上，从零把它变成生产环境的一部分，并保证后续可维护。这个定位在题目里贯穿始终。
另外提一句，2015年正好是阿里去IOE、上云、容器化这些技术变革非常热闹的时期，那几年的笔试题也明显带有“云化”和“自动化运维”的影子。很多题目表面上在问Linux命令，实际上想让你展现在几千台服务器规模下的管理思路。这个时代背景，放在今天的公有云、CDN、容器云大环境下依旧适用，甚至更贴近。
2. 核心题型拆解：Linux、网络、存储与脚本一个都不能少
2.1 Linux基础与系统启动流程：不是背命令，是理解操作系统
2015年这套笔试题里，Linux相关题目占比非常高，大概能到30%以上。最典型的一类，是描述系统启动过程：从按下电源键到用户登录，中间发生了什么。
这个问题看起来简单，但深挖下去可以考得很细。比如grub引导做了什么，内核解压后如何挂载根文件系统，init进程（当年CentOS 6还是init，CentOS 7刚出来没多久）如何读取/etc/inittab，运行级别的切换，以及rc.sysinit里做了什么。更深一点，还会问你如何修改系统默认运行级别、如何进入单用户模式重置root密码。
这种题目的用意，表面上是考察基础扎实程度，实际上是在测试一个系统工程师是否有能力在没有光驱、没有救援卡的情况下，通过单用户模式修复一台起不来的生产服务器。线上环境里，这种场景太常见了——内核参数配错、fstab挂载项写错、rc.local里塞了一个死循环脚本，都能让服务器在开机时挂掉。
还有一类经典题目是性能排查。给你一台CPU跑满、负载异常高的服务器，让你用top、vmstat、iostat、sar、free等命令定位瓶颈，并给出优化建议。2015年那会儿容器还没完全普及，物理机上是数据库、缓存、Web服务混部，性能问题极其常见。现在的情况更复杂，但排查思路依然是那套：先看负载是个什么状态，再用perf、strace这类工具去追具体的进程上下文。
这类题目的关键，不是把工具选项背全，而是形成一套自己的排查路径。我的习惯是先看top的load average和CPU状态的us/sy/wa/id比例，如果wa高就转去看iostat的await和util，判断是不是磁盘瓶颈；如果sy高就去检查是不是系统调用频繁、锁竞争严重；如果us高再去定位是CPU密集任务还是内存换页导致。这套思路，在笔试答案里如果能写出来，比单纯罗列工具名要得分得多。
2.2 网络与协议：从TCP三次握手到生产故障排查
网络相关的题目在系统工程师笔试里同样是重头戏。2015年的题里，TCP三次握手和四次挥手是必考的，但阿里的题往往不会只让你背状态流转，而是会给你一个实际场景：某台服务器出现大量TIME_WAIT，你该如何分析和处理。
这个问题本质上是考你对TCP状态机的理解深度，以及实际生产中的排查经验。TIME_WAIT大量出现，通常意味着高并发短连接场景下，主动关闭连接的一方在等待2MSL超时。常见解法包括：调整内核参数net.ipv4.tcp_tw_reuse和tcp_tw_recycle（后者在NAT环境慎用）、开启tcp_fin_timeout调短等待时间、或者从架构层面改为长连接。但如果只回答“改内核参数”而不说清原理和风险，面试官一听就知道你没有真正处理过线上问题。
网络方面还会考子网划分、CIDR计算、路由表解读、iptables规则编写。这些题目本身不难，但考察的是你在生产环境里有没有真正配过网络。比如给一个网段，让你尽可能多地划分子网供不同业务使用；或者给一段iptables配置，让你判断这条规则有没有生效、为什么。
值得一提的还有DNS相关的题目。2015年那会儿，不少公司还在用自建Bind，DNS运维是系统工程师的基本功。笔试题里经常出现：客户端能ping通DNS服务器，但nslookup解析超时，怎么排查。这个问题的排查路径非常典型：先确认服务器本身能否解析、防火墙是否放行了53端口、Bind是否正常监听、是不是被递归限速了，之后还要看是不是被运营商劫持了。放到今天，这套排查思路依然完全适用，只不过把Bind换成了CoreDNS或云厂商的解析服务。
2.3 存储、文件系统与数据库备份：数据安全是底线
存储这块大概是很多人的薄弱环节，因为平时开发很少接触到。但系统工程师笔试一定会考，原因很简单：没有存储基础，根本做不了生产环境的规划与灾备。
2015年的真题里，有一道很典型的题是：内核是怎么把文件从磁盘读出来的？从VFS、文件系统实现（ext4当时居多）、page cache到磁盘驱动，整个过程需要你讲清楚。这道题背后的实际意义是：当你发现文件读写慢的时候，你至少要知道瓶颈可能出现在哪个环节。是page cache命中率低、还是文件系统本身碎片化严重、还是RAID卡策略导致IOPS上不去。
存储相关的计算题也很常见。比如给你磁盘大小、文件系统块大小、inode数量，让你计算可以存放的文件数量上限；或者给你RAID5的磁盘组配置，让你计算可用容量和单盘故障后的重建过程。这类题目没有技巧，靠的是平时真正摆弄过文件系统、玩过软RAID，积累了这些概念之后自然就能算出来。
数据库备份也是系统工程师的必修课。笔试里常考mysqldump和xtrabackup的区别、备份策略设计、主从复制原理。2015年的时候，阿里已经大规模用MySQL，并且开源了AliSQL，系统工程师至少要懂InnoDB的日志机制。题目经常是这样：一台MySQL主库磁盘损坏，你怎么从备份恢复数据，尽可能减少丢失的数据量。这题没有标准答案，考察的是你脑子里有没有一套备份恢复的完整链路：定期全量备份 + binlog增量备份 + 备份完整性校验 + 恢复演练。我在后来做生产系统维护时，深刻体会到“备份不等于能恢复”，所以这类题目我会在答案中特别强调演练。
2.4 Shell脚本：系统工程师的“手和脚”
系统工程师的笔试里，脚本编程几乎是必考的，而且不止一道。2015年那份题里，有一道是根据nginx访问日志统计出访问量最大的IP，要求用Shell或者Python实现。
这类题目考的是自动化能力。系统工程师面对的是几十上百台服务器，如果每件事都手动执行，效率极低。写脚本解决重复性问题，是这个岗位的基本素养。笔试题不会出得特别复杂，但会给一些有坑的场景：日志格式里有特殊字符、字段位置不固定、需要处理空行和异常数据。
比如统计访问量最大的IP，用awk一行就能搞定：
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -10这行命令看起来简单，但里面包含了几层逻辑：日志的字段位置对不对、sort的必要性、uniq -c的计数方式、sort -nr的降序排序。如果日志是Nginx默认的combined格式，第1列是IP，第11列是User-Agent，中间有可能包含空格，这时候直接按列取就不行了，得用更严谨的方式。
我自己当年写这道题时，特意把脚本写成了容错性更强的版本：
awk '{ip[$1]++} END {for (k in ip) print ip[k], k}' access.log | sort -rn | head -10这里用的是awk数组，一次遍历就能完成统计，不需要多管道，性能更好。笔试时如果能写出这种思路，并且在注释里说明为什么不用sort+uniq的方式，会让阅卷的人觉得你真正写过脚本，而不是临时背的。
除了日志统计，笔试题里还会出现批量部署、批量修改配置的脚本题。比如给你100台服务器的IP列表，要求写一个脚本，把所有服务器的nginx配置更新并平滑重载。这种题目的核心是：要有并发控制、要有失败重试、要有结果反馈。仅靠一条for循环很可能会超时，需要xargs -P或者并发后台进程的方式。这些细节，都是笔试里体现经验层次的地方。
2.5 系统设计题：生产环境从零搭建的面试官版
2015年阿里系统工程师研发笔试题里，还有一类综合应用题，通常是给你一个业务场景，让你设计一套部署架构。这类题目在笔试卷子里出现，很多人认为超纲，但其实是核心。
典型题目是这样的：假设你负责一个新业务，需要在生产环境从零搭建一套系统，包括Web服务器、应用服务器、数据库、缓存、文件存储，请画出架构图，并说明各个组件的选型理由、部署方式、高可用方案以及日常维护要点。
这道题在当年就是热词里“作为一个运维工程师，如何在生产环境从零搭建一个系统并做好后续维护”的笔试版本。要答好这道题，不能只画个拓扑图，得把决策过程写清楚。
我当年是这样拆解的：先明确业务规模和访问量预估，再考虑预算和运维人力。如果是中小业务规模，部署架构可以是两台Nginx做负载均衡，后面挂两台应用服务器，MySQL用主从复制，Redis做缓存。Nginx和应用的节点都放在同一个内网，通过keepalived做VIP漂移。存储方面，如果用阿里云就直接挂云盘，如果自建机房则需要考虑本地磁盘还是分布式存储，这取决于数据量。
高可用方案上，核心是消除单点。Nginx至少两台做热备，MySQL主库故障时要能自动切换，Redis要启用持久化并且做主从。日常维护，重点是监控和备份：系统层面对CPU、内存、磁盘、网络做基础监控，业务层面则要盯响应时间和错误率；数据库每天全量备份，binlog实时备份，并且定期做恢复演练。
这个方案不管是当年还是现在，都能看出一个系统工程师对自己环境是否有全局认知。笔试题的评分标准通常不是方案本身的好坏，而是你有没有覆盖到高可用、灾备、监控、安全这些维度。哪怕你用的是最简单的主从架构，只要能说清楚每一个环节的失效场景和应对措施，就能拿高分。
3. 超出技术之外：笔试里那些容易被忽略的考察点
3.1 工作习惯与流程意识：写注释是一种态度
阿里这类大厂的笔试题，往往还会有一些主观题或者综合题，考察的是工作习惯和流程意识。比如题目要求你写一段脚本，说明你会以什么方式来组织代码、如何加注释、如何考虑错误处理。
这里想说一个细节：2015年那套卷子，题量其实不算小，两个小时紧巴巴的。很多人拿到题就埋头狂写，忽略了在关键步骤上做注释和说明。我考完跟几个同学交流，发现得分高的卷子往往有一个共同点：答案里除了结论，还写了分析过程、依据、甚至备选方案。这说明答题的人是真在做事，不是在背题。
系统工程师的工作，很多是“事后复盘”：你为什么要这样配置、出了问题时怎么回滚、有什么替代方案。把这些写进答案，就是在模拟真实的工作汇报。我在后来带团队时，经常告诉新同学：你提交的脚本、配置、变更记录，就是你的工作说明书。不要觉得多写几个字是浪费时间，关键时刻能救你一命。
3.2 故障应急思路：先恢复，后根治
还有一类题目专门考察应急处理思路。比如：某天凌晨3点，线上系统报警，数据库主库负载异常，大量慢查询，这时候你要怎么处理。
这种题没有标准答案，但有一条核心原则：先止损，再定位，最后根治。我通常的思路是：
- 快速判断影响面：如果是慢查询导致的，先看是否有大事务或锁竞争，可以考虑kill掉异常会话，优先恢复服务。
- 在保证数据一致性的前提下，切入只读模式或者把业务切到从库，避免故障扩散。
- 保留现场证据：慢查询日志、ps输出、系统状态快照，为后续分析提供素材。
- 恢复后，彻底分析根因，是SQL本身有问题，还是数据量增长导致索引失效，或者是配置参数不合理。
- 形成改进项：优化SQL、增加监控、调整容量规划，避免再次发生。
这个思考过程，在笔试时如果能条理清晰地写出来，比写任何华丽的技术方案都更能代表你的水平。因为面试官知道，系统工程师最重要的能力不是“避免所有故障”，而是“故障来了能扛住、能快速恢复”。这也是我在生产环境里摔打多年后最深的一点体会。
3.3 容量规划与成本意识：大厂面试官的真实意图
2015年阿里的笔试里，虽然直接问容量规划的题目不多，但很多题目背后都在考察这个点。比如给了你一台服务器的规格，让你预估它能扛多少QPS；或者给了你一个业务增长预期，让你规划需要多少台机器。
这类题目的核心不是精确计算，而是你有没有容量规划的意识和基本估算能力。我当时遇到一道题，问的是“一台8核16G的服务器，跑Nginx，能支撑多少并发连接”，我知道这取决于连接类型和业务逻辑，所以给了个区间估计，并写出了计算依据：Keepalive连接和短连接的区别、worker_processes和worker_connections的关系、内存中每个连接大概消耗多少。
这种写法比直接给一个数字要好得多。因为系统工程师做容量规划时，永远是在不精确的数据上做决策——你只能预估，然后通过压测验证，再根据监控数据持续调整。笔试里及早展现出这个思维模式，会让面试官觉得你是个能独立思考的人，而不是只会背命令的执行者。
4. 备战这类笔试的方法论：别刷题，去折腾真环境
4.1 考前一两个月，动手搭一套Linux环境
想通过这类笔试，最有效的方法不是刷面试题，而是实打实去折腾一套Linux环境。我强烈建议用一台旧电脑或者虚拟机，装一个CentOS或者Ubuntu Server，然后强迫自己在终端里完成所有操作。
你可以从这些事情开始：编译安装一个Nginx、配置PHP或者Tomcat、搭建MySQL主从、用iptables封端口、写脚本监控磁盘空间、设置crontab定期备份、模拟一次boot分区满了导致系统起不来的故障并修复。这些操作都是笔试题里的常客，自己动手做一遍，比背一百道题都管用。
当年我为了准备面试，给自己定了个任务：每周在虚拟机上折腾一个主题。第一周是网络配置和SSH加固，第二周是LVM扩容和磁盘故障模拟，第三周是Nginx反代和负载均衡，第四周是MySQL备份恢复。这样一个月下来，Linux的知识体系基本就能建立起来，而且碰上考试里的场景题，马上能联想到自己实际操作的细节。
4.2 形成自己的知识树：从命令到原理
很多人准备笔试喜欢背命令，比如“查看端口用netstat”、“查看磁盘用df -h”，但这只能应付最基础的选择题。碰到场景题、分析题，必须理解命令背后的原理。
比如df和du有什么区别？df看的是文件系统层面的统计，du是遍历目录计算实际占用，两者结果不同是非常正常的。不了解底层机制的人，遇到“df显示磁盘满了，但du找不到大文件”这种场景题，就会一头雾水。实际生产中这个现象很常见，原因多半是删除了文件但进程还持有句柄，或者文件被删除但空间没释放。如果知道这一点，结合lsof | grep deleted就能排查出来。
所以我的建议是：每学一个命令，都要追问三个问题：它读取的是什么数据？它显示的字段分别代表什么？如果结果和预期不符，问题可能出在哪。把自己当成科班出身去理解操作系统，而不是把自己当成命令背诵机，这才是准备系统工程师笔试的核心方法论。
4.3 多看故障排查文章和复盘报告
笔试题里的场景，几乎都是真实故障的简化版。所以积累故障排查经验最有效的方式，就是多读公开的故障复盘报告、技术博客里的踩坑记录。2015年那会儿，阿里、新浪、美团这些公司还有不少公开的技术分享，里面包含了大量生产环境的真实问题。现在虽然分享少了，但类似的内容分散在公众号、知乎、掘金里，依然很有价值。
读这些文章时，不要只看结论，要跟着作者的排查思路走：他先做了什么，为什么这么做，遇到了什么坑，最后怎么定位的。读多了以后，你的脑子里就会积累很多“模式”：CPU高可能是什么原因、磁盘IO慢可能是什么原因、网络超时可能是什么原因。笔试时遇到场景题，你就能迅速匹配到对应的模式，再结合题目给的条件细化答案。
4.4 练习限定时间答题：两小时模拟真实笔试
最后说说答题节奏。2015年那套题，我印象里题量很大，有选择题、简答题、编程题、设计题。很多人栽在时间分配上：前面选择填空花太多时间，最后的大题没时间写。
我的经验是拿到卷子先花3分钟浏览一遍全部题目，快速判断哪些题是送分题、哪些题是拿分大头、哪些题需要多想。一般来说，Linux命令类题目可以快速答，场景分析和系统设计题必须留足时间，脚本编程题至少留出20分钟。
模拟训练很重要，找一个安静的时间段，定时两小时，用往年真题或者类似难度的题目做一次完整体验。做完之后认真复盘，看自己卡在哪类题上，是基础知识不牢还是思路不清，再有针对性地补强。这个过程比你漫无目的地多看一百篇经验帖更有效。
5. 从笔试走出去：系统工程师的真实成长路径
写完这些，其实我最想说的是：任何一份笔试题目，都不可能完全反映一个人是否适合做系统工程师。但它一定能够反映出一个人的基础是否扎实、思路是否清晰、有没有真正的经验积累。
我在生产环境摸爬滚打这么多年，最大的感受是：系统工程师这个岗位，技术本身只是入场券。真正决定你做得好的，是责任心和严谨度。你改动一个内核参数，会影响整台机器上所有服务的稳定性；你写错一条iptables规则，可能把公司的业务全部堵死；你漏了一次备份的完整性校验，可能让整个团队几个月的努力付诸东流。
所以如果你正在准备类似的笔试，不要只盯着题目本身，而是要想一想：这套题希望我成为一个什么样的工程师？它考察的是我能否独立思考、能否在压力下保持冷静、能否在复杂系统中找到关键路径。
对我来说，2015年那场笔试虽然没有拿到offer，但它给了我一个很好的方向标。后来的这些年，我一直在往这个方向努力：把每一个组件搞清楚，把每一次变更做好预案，把每一个问题彻底分析透。笔试只是起点，后面的路还有很多要学。
最后再分享一个小技巧：准备这类系统工程师面试时，把每一次解决过的线上问题都记录下来，形成自己的“故障复盘库”。这个库不仅是你的面试素材库，更是你日常工作的宝藏。面试官问到任何场景题，你都能从库中找到一个真实案例来支撑你的回答。这种从实战中长出来的经验，比任何笔试题的参考答案都更有说服力。
