1. 一场笔试题背后的岗位画像系统工程师到底在考什么先说背景。2015年阿里的系统工程师研发笔试题在当时的求职论坛里流传很广原因不在于题目有多难而在于它非常“奇怪”——整套卷子既不完全是开发题也不完全是运维题更像是把一名系统工程师一年里要面对的破事浓缩成两个小时。很多人刷完LeetCode去考直接被第一道Linux启动流程题干懵然后骂骂咧咧退场。我自己是2015年秋季参加过这场笔试的虽然最后没进阿里但那张卷子给我留下的印象极深。后来我在几家互联网公司做过系统工程师、SRE再回头看这些题目才发现当年觉得“偏、怪、不按套路出牌”的地方恰恰是系统工程师日常工作中真正需要的能力。先给不太了解这个岗位的读者做个定位。系统工程师在互联网公司里通常负责的是基础架构层面的工作操作系统选型和调优、服务器批量交付、网络规划、存储方案、数据库部署与备份、监控告警体系搭建以及线上故障的排查和应急。它和纯开发工程师的区别在于开发工程师关心功能怎么实现系统工程师关心的是系统怎么稳定跑起来、出了问题怎么快速恢复。所以这套笔试题的核心逻辑不是考你会不会写某段代码而是考你有没有能力在一台刚拿到的服务器上从零把它变成生产环境的一部分并保证后续可维护。这个定位在题目里贯穿始终。另外提一句2015年正好是阿里去IOE、上云、容器化这些技术变革非常热闹的时期那几年的笔试题也明显带有“云化”和“自动化运维”的影子。很多题目表面上在问Linux命令实际上想让你展现在几千台服务器规模下的管理思路。这个时代背景放在今天的公有云、CDN、容器云大环境下依旧适用甚至更贴近。2. 核心题型拆解Linux、网络、存储与脚本一个都不能少2.1 Linux基础与系统启动流程不是背命令是理解操作系统2015年这套笔试题里Linux相关题目占比非常高大概能到30%以上。最典型的一类是描述系统启动过程从按下电源键到用户登录中间发生了什么。这个问题看起来简单但深挖下去可以考得很细。比如grub引导做了什么内核解压后如何挂载根文件系统init进程当年CentOS 6还是initCentOS 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年那会儿不少公司还在用自建BindDNS运维是系统工程师的基本功。笔试题里经常出现客户端能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数组一次遍历就能完成统计不需要多管道性能更好。笔试时如果能写出这种思路并且在注释里说明为什么不用sortuniq的方式会让阅卷的人觉得你真正写过脚本而不是临时背的。除了日志统计笔试题里还会出现批量部署、批量修改配置的脚本题。比如给你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但它给了我一个很好的方向标。后来的这些年我一直在往这个方向努力把每一个组件搞清楚把每一次变更做好预案把每一个问题彻底分析透。笔试只是起点后面的路还有很多要学。最后再分享一个小技巧准备这类系统工程师面试时把每一次解决过的线上问题都记录下来形成自己的“故障复盘库”。这个库不仅是你的面试素材库更是你日常工作的宝藏。面试官问到任何场景题你都能从库中找到一个真实案例来支撑你的回答。这种从实战中长出来的经验比任何笔试题的参考答案都更有说服力。