去年春招我完整复盘了一场游戏公司的系统工程师笔试。和研发岗笔试不太一样系统工程师的笔试很少让你手写LRU更多是丢给你一堆真实环境里的坑线上CPU飙升怎么查、数据库连接被打满怎么办、一台全新的服务器怎么在一天之内变成可上线的生产节点。搜狐畅游这套卷子给我的感觉是它不考你能不能背出Linux命令而是考你在生产环境里有没有从零搭建系统并持续维护的完整认知。这篇文章既是笔试题复盘也是系统工程师日常工作的核心方法总结如果你正在准备春招、或者刚转岗运维/系统工程师希望能帮你少走点弯路。我先把最核心的结论放在前面系统工程师笔试的所有题目本质都在围绕一件事——给你一台裸机你能不能让它变成一个稳定、可监控、可恢复的生产节点。这里的稳定指不轻易宕机可监控指出问题能及时发现可恢复指数据丢了能拿回来、服务挂了能拉起。把这条主线抓住你会发现那些看似零散的题目都能归到一个体系里。1. 系统工程师笔试到底在考什么1.1 系统工程师不是高级网管很多同学一开始会混淆系统工程师和运维工程师、DevOps、SRE这些岗位其实笔试复习前得先把岗位定位搞清楚。在游戏公司或互联网公司里系统工程师更偏向基础架构层主要工作是服务器操作系统管理、网络基础、数据库和中间件部署、脚本自动化、监控告警、故障排查以及最核心的容量规划和成本控制。开发工程师关注的是功能能不能实现系统工程师关注的是功能上线后能不能长期稳定运转。笔试里常见的一个误区是狂刷LeetCode或者花大量时间背Linux命令结果考到给你一台新服务器说说你从装机到上线的完整步骤直接懵了。这种题没有唯一答案但没有生产环境经验的人往往会答成装系统、部署代码、开放端口三句话完全撑不起一个系统工程师该有的思考密度。我复盘下来系统工程师笔试真正考察的是系统思维也就是面对一台空机器时你的决策顺序是什么。先做什么、后做什么、每个步骤为什么这么做、做完怎么验证、失败了怎么回滚这些才是面试官想看到的。命令可以上网查架构思路和风险意识没法临时抱佛脚。1.2 笔试模块与考察权重从搜狐畅游这套题以及同类型公司的笔试风格来看系统工程师笔试通常分几个模块。我根据自己的复习和考试经验整理了一张大致的模块权重表不一定适用于所有公司但可以作为复习方向的参考考察模块主要题型常见考点建议权重Linux基础与系统管理选择题、简答题文件系统、进程管理、权限、systemd20%网络基础选择题、场景题TCP三次握手、HTTP状态码、DNS、负载均衡20%数据库运维简答题、场景题MySQL索引、主从复制、连接数打满、备份恢复20%中间件与Web服务场景题、配置题Nginx转发、Redis缓存、消息队列15%脚本与自动化手写脚本、逻辑题Shell/Python、定时任务、批量处理10%故障排查与监控场景题CPU飙高、磁盘满、延迟排查、告警设计10%安全基础选择题、简答题防火墙、权限管控、最小化原则5%这个权重说明一个很现实的问题系统工程师笔试的重心不在会不会敲命令而在能不能处理生产环境里的实际问题。所以复习的时候我建议把场景题作为主线每复习一个知识点都问自己一句——这个知识点在线上有什么用如果出了故障它能帮我定位什么问题2. 核心考点拆解生产环境从零搭建系统的完整流程2.1 第一步需求分析与容量规划笔试中出现频率极高的一道题就是给你一台8核16G的服务器请你部署一套Web服务你会怎么做很多人的第一反应是装Nginx、装MySQL、把代码扔上去、开放80端口但这个答案在评分时基本拿不到高分。因为一个合格的系统工程师接到任务后第一件事不是装系统而是做需求分析和容量规划。你需要先搞清楚这个系统是给谁用的、并发多大、数据量多少、可用性要求多高。比如游戏业务如果这是一台游戏登录服在线人数峰值假设是2万人每个登录请求平均耗时100ms那么QPS大概在200左右单台服务器理论上没有压力。但如果是游戏逻辑服每个玩家每秒钟可能产生多次协议交互情况就要复杂得多。容量规划里有个很实用的估算思路先定业务指标再反推服务器资源。比如一个Web服务你预期峰值QPS是5000接口平均响应时间50ms单请求占用内存约500KB。算CPU时可以估算单核QPS能力假设一个核心能处理2000个简单请求那么4个核心就能扛住8000 QPS算内存时5000 QPS乘以500KB约2.4GB再叠加应用本身和系统占用8G内存基本够用。磁盘则需要按日志量和数据量来算比如每天产生2GB业务数据、10GB日志保留30天磁盘至少需要360GB再加余量。笔试答题时把需求-指标-资源这条链路写清楚比直接给结论强很多。哪怕是估算也要让面试官看到你有数据意识。容量规划这道题的核心不是精确计算而是你有没有做这件事的思维习惯。2.2 第二步操作系统安装与初始化容量规划做完才轮到操作系统层面。这里有个高频考点Linux发行版怎么选、装完系统后要做哪些初始化。说实话发行版选哪个没有绝对标准但作为系统工程师你必须给得出选择和理由。比如游戏/互联网公司的传统业务很多用CentOS/Rocky Linux新业务可能倾向Ubuntu LTS核心考虑因素是稳定周期、厂商支持、社区生态和团队熟悉度。如果面试中问到CentOS停更了怎么办能够说出迁移到Rocky Linux或跳过中间版本平滑升级的方案会是一个加分项。系统初始化部分笔试中常考的有分区、系统参数、安全设置和基础组件安装。以一台16G内存、500G磁盘的服务器为例我一般建议的分区方案是系统盘和数据盘分开系统分区给50-100G剩余空间全部给数据分区如果数据库业务建议数据目录单独挂载。用一个LVM逻辑卷管理的好处是后续扩容方便不用重新分区。如果机器内存比较大比如64G以上swap可以不用太大或者按内存的0.5-1倍设置避免频繁换页导致性能劣化。装完系统后有一个很关键的步骤调整内核参数和文件描述符限制。这里贴一段我常用的初始化脚本片段笔试里写出关键参数并说明含义比默写整段脚本更讨巧# /etc/sysctl.conf 常见生产参数 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_max_syn_backlog 8192 net.core.somaxconn 65535 net.ipv4.ip_local_port_range 1024 65535 fs.file-max 1000000 # 文件描述符限制 /etc/security/limits.conf * soft nofile 655350 * hard nofile 655350 * soft nproc 655350 * hard nproc 655350为什么这些参数重要简单说tcp_tw_reuse可以加快TIME_WAIT状态的连接回收高并发场景下连接数才不会快速堆积somaxconn和somaxconn能缓解短连接高峰时队列溢出file-max和nofile则直接决定了服务能不能打开足够多的文件描述符。你不需要背下每个参数但至少要能解释清楚高并发下连接数不够用这个经典故障和哪些参数有关。安全初始化也是笔试里容易踩分的点关闭不需要的服务、修改SSH默认端口或禁止root远程登录、配置防火墙只放行业务端口、统一ntp/chrony时间同步。特别是时间同步很多新手会忽略但游戏业务里的跨服交互、数据库日志排序、分布式锁都依赖时间一致系统工程师没有时间同步意识会吃大亏。2.3 第三步基础组件与中间件部署生产环境的组件部署笔试题目中一般会挑一个最常用的组合来考Nginx MySQL Redis。这三件套基本覆盖了Web业务最常见的技术栈也是系统工程师日常维护中最常打交道的东西。Nginx部署最核心的是它在架构里扮演的角色。笔试里常见的问题是Nginx如何做负载均衡和反向代理这时你需要给出一个带关键参数的配置示例并且说明upstream里的策略。比如默认是轮询weight可以配置权重ip_hash可以保持会话least_conn能把请求分给连接数最少的后端。另外Nginx的调优不要只提worker_processes auto还要知道worker_connections要结合ulimit -n来调gzip、keepalive、静态文件缓存这些参数也需要掌握。MySQL部署是重头戏。笔试中我印象最深的是MySQL连接数被打满怎么办这个题其实可以从三层去答先应急把max_connections临时调大或杀掉一些长事务再排查看SHOW PROCESSLIST里是哪些SQL占着连接是不是因为慢查询堆积最后根治从连接池、慢SQL优化、读写分离、缓存多个角度去解决。数据库的innodb_buffer_pool_size设置也很常考一般建议设为物理内存的60%-70%如果服务器同时跑着Nginx和Redis要适当调低避免内存互相争抢。Redis部署则要重点说内存淘汰策略和持久化。maxmemory一定要设置否则Redis可能吃光服务器内存maxmemory-policy的选择要看业务缓存场景用allkeys-lru比较常见有明确过期时间的场景可以用volatile-lruappendonly yes开启AOF可以在一定程度上减少数据丢失但同时要关注磁盘I/O压力。这里加分点是你能答出Redis不是万能的缓存使用前要考虑缓存雪崩、缓存穿透、缓存击穿并给出相应的解决方案。部署过程中的一个笔试技巧是不要只写我安装并启动了MySQL而是写我通过二进制安装MySQL数据目录单独放在/data/mysql关闭了默认的skip-name-resolve并解释原因配置了binlog并验证开启成功。每一个技术选型背后都有原因面试官最反感的是知其然不知其所以然。2.4 第四步交付前的自检清单很多考生答到启动服务就停了但真正的生产环境里服务启动只是开始。笔试里如果让你说说系统上线前要注意什么我会建议用一份自检清单来组织答案这样既显得有条理又能覆盖考官可能追问的各个细节。下面是一份我自己常用的交付前检查清单笔试中写出来会让答案完整度明显提升端口检查ss -lntp确认业务端口已监听并且防火墙只放行了必要端口连通性检查从客户端用curl -I或nc -vz确认服务可访问测试HTTP状态码是否符合预期日志检查tail -f业务日志确认无ERROR级报错确认日志切割已配置进程检查ps -ef确认服务进程正常常驻systemd单元文件已配置restartalways监控检查Node Exporter、Agent等监控组件已部署能在监控平台看到主机指标备份检查MySQL等数据服务的备份任务已配置执行一次备份并验证备份文件非空资源检查free -h、df -h确认资源余量关键目录没有即将写满的风险安全检查SSH禁root登录生效不必要的服务已关闭权限最小化以自检清单切入会自然引出后续维护的话题。我个人的心得是笔试中从零搭建系统这类题想拿高分必须在最后交代验证环节。面试官想看到的是你不会把一个服务假装启动成功就交付而是有完整的验收手段。3. 搞定笔试里最容易被追问的后续维护怎么做3.1 监控告警体系先定指标再选工具笔试题目如果只答到系统上线后面一般还有一个连环追问——上线之后你怎么保证它稳定运行这就是后续维护的核心命题。在这部分监控告警是必考题。很多人的第一反应是装一个Zabbix/Prometheus但只答工具不行你要先回答监控指标怎么定再回答工具怎么搭。监控的核心是指标不是工具。一个生产系统至少需要关注四类指标硬件层CPU、内存、磁盘、网络、应用层进程存活、接口响应时间、错误率、中间件层数据库连接数、缓存命中率、消息堆积量、业务层在线人数、订单量、登录成功率。游戏业务还要特别关注玩家在线数、登录队列长度、跨服通信耗时这类业务指标。在监控工具选型上我现在的习惯是Prometheus Grafana Alertmanager这套组合配合Node Exporter采集主机指标。笔试中如果让你回答如何监控一台服务器你不需要把整个生态名词全堆出来只要能把链路说清楚数据采集、指标存储、规则告警、展示看板。以CPU告警为例写一个Prometheus规则能让答题落地很多groups: - name: node_alerts rules: - alert: HighCpuUsage expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: {{ $labels.instance }} CPU usage high这段规则表达的意思是CPU使用率超过85%并持续10分钟才触发告警。这里有一个容易被忽略的经验——告警一定要避免抖动。如果没有for: 10mCPU稍微波动一下就会刷屏最后告警变成狼来了真正出事时反而没人看。笔试中如果你能主动提到告警阈值要设置持续时间避免误报面试官会认为你踩过坑是真的在生产环境里待过。告警分级也是加分项。我一般分三级紧急服务宕机、数据丢失风险需要立即处理电话/短信通知警告磁盘使用率超过80%、CPU持续高在工作时间内关注通知日常波动只在看板记录。笔试中不要只写CPU超了就告警最好补充不同级别对应不同通知渠道和响应时限。3.2 日志管理与故障排查思路日志是系统工程师最重要的破案线索。笔试中线上故障排查类题目如果没有日志意识基本就是空谈。我复盘时记得有一道题是用户反馈服务变慢你怎么排查很多人上来就说用top看CPU用free看内存但一个合格答案应该先讲排查思路再讲具体命令。我自己的排查思路是把一条用户请求从客户端到后端完整走一遍。比如游戏玩家登录变慢链路是客户端 - DNS - 负载均衡 - Nginx - 游戏逻辑服 - MySQL/Redis。第一步先用ping和dig确认网络和DNS正常第二步用curl -w看Nginx响应时间区分是网络慢还是后端慢第三步进入应用服务器用top看CPU和负载free看内存iostat看磁盘I/O最后再结合日志看请求在哪个环节耗时最多。日志管理层面笔试常考的包括日志切割、日志集中收集、日志备份与清理。日志切割最常用的是logrotate按天切割并保留N份避免单个日志文件无限变大。日志集中收集如果公司规模小可以用Loki Promtail Grafana这套轻量方案比ELK省资源如果日志量大、需要复杂检索再考虑Elasticsearch。笔试里提到ELK时最好能说清每条日志的流转路径Filebeat采集 - Logstash处理/Filter - Elasticsearch存储 - Kibana展示。补充一个我在真实环境踩过的坑日志不是越多越好也不是所有的日志都要收到集中平台。游戏业务经常会打超详细的Debug日志一天几个GB收进ES后存储成本飙升。合理做法是生产环境只收集WARN和ERROR级别的关键日志需要临时排查时再动态调高采样级别。这个取舍意识比单纯会装一套ELK更能体现系统工程师的价值。3.3 备份、容灾与演练没备份就是没运维这句话在系统工程师圈子里是血泪教训。笔试中数据库备份和恢复几乎是必考项特别是游戏公司玩家数据一旦丢失就是灾难性事故。我看到不少考生能背出mysqldump的参数但问怎么验证备份是好的就答不上来这其实才是真正的考点。关于MySQL备份我的方案是小数据量比如10G以内可以用mysqldump逻辑备份简单直观大数据量建议用xtrabackup做物理备份速度更快、对业务影响更小。核心是要说明binlog的作用——全量备份只是某个时间点的快照真正要做到任意时间点恢复必须结合binlog做增量恢复。笔试中如果出一题误删了表中的数据如何恢复你的思路可以是用最近一次全量备份恢复数据文件再通过binlog把数据回放到误删操作之前的时间点。备份的保留策略也可以用一句口诀来记日备保留7天周备保留4周月备保留半年或一年。备份文件要定期做恢复演练不要等到真出事才发现备份文件是坏的。恢复演练这件事笔试里能说出来就是小亮点实际工作中更是救命咒语。云主机的话还可以定期打快照比如每天凌晨一次快照不等于备份但作为补充手段成本低、恢复快。游戏行业还有一个特别的场景合服和开服。开新服时大量的初始化脚本和配置要自动化合服时数据库合并和玩家数据校验必须有完整方案。笔试中如果遇到新开一组游戏服你怎么规划这种开放题可以从容量评估、基础环境初始化、配置文件管理、监控接入、开服验证几个点展开把自己代入真实的运维流程。3.4 变更管理与日常巡检生产环境最怕的不是出问题而是乱变更导致出问题。笔试中关于后续维护的题如果只答监控和备份还不够要有变更管理和巡检制度的意识。比如线上系统需要升级Nginx版本你如何保证不影响业务完整答案至少包含先在测试环境验证、准备好回滚方案、选择业务低峰期操作、分批灰度、操作后观察监控指标。能答出变更前必须准备回滚方案这一点基本就能和普通考生拉开差距。日常巡检也值得写进答案里。巡检不能只是登录服务器敲一遍uptime就完事而是应该有节奏和内容。我一般把巡检分成日、周、月三个级别日检CPU负载、内存使用率、磁盘空间、关键进程状态、昨日错误日志周检数据库备份结果、慢查询数量、证书有效期、系统更新补丁状态月检全量备份恢复演练、日志归档清理、容量趋势分析、漏洞扫描与安全加固巡检不是走过场而是要形成记录。记录里要有当前值、上周值、趋势判断。例如磁盘使用率上周70%、这周78%如果增长率不变多久会到90%这个预判往往比告警来得更早。笔试中如果能把巡检表单化并强调基于趋势提前干预会非常像一个有经验的系统工程师。4. 笔试中常见的坑与答题加分技巧4.1 我看到的高频扣分点复习那些年我见过太多人在同一类问题上丢分这里集中盘点一下如果你正在准备笔试可以拿来自查。第一个大坑是只写操作不写原因。比如我修改了/etc/security/limits.conf但没有解释为什么改、改完怎么验证、对业务有什么影响。系统工程师不是执行命令的人而是决策和执行并重的人。任何操作题我都推荐用目标 - 方案 - 验证三段式来写答案。哪怕笔试时间紧张至少也要在关键操作后补一句原因。第二个大坑是忽略验证和回滚。很多答案停留在服务已启动但没有说明如何确认服务正常也没说如果异常如何回滚。生产环境里任何变更都有风险没有回滚方案的变更就是赌命。笔试答题时主动加上我会先备份原配置变更后立即检查端口、进程和日志异常则迅速恢复这十几个字含金量很高。第三个大坑是不分优先级把所有知识点平铺。比如题目问系统卡顿如何排查有人从DNS一路背到数据库中间没有重点。实际上应该先从负载、CPU、内存、磁盘、网络这五个维度做快速判断定位到瓶颈后再深入。回答要体现先看整体再聚焦局部的思路。第四个大坑是忽视安全与用户权限。作为系统工程师如果答题时提到数据库密码只想到写死在配置里或者没有关闭不必要的端口这些细节都会被扣分。安全不是一个单独的知识点而是贯穿所有系统操作的原则。最小权限、白名单、定期轮换密码这些基本素养要在答案中自然流露。4.2 高频场景题速查笔试场景题是最难临场发挥的因为它考察的是工程经验和解决问题的方式。我把这些年遇到的高频场景题整理成一张速查表建议你复习时对着它练习快速形成排查思路场景首选排查方向关键命令/手段加分补充CPU飙高定位高CPU进程/线程top/pidstat/jstack输出线程堆栈看代码热点磁盘空间满定位大文件/目录df -h/du -sh */lsofgrep deletedinode耗尽检查小文件数量df -i/findwc -lTIME_WAIT过多检查TCP连接状态ss -s/netstat -ant结合tw_reuse/keepalive优化MySQL连接数打满查看processlistSHOW PROCESSLIST杀长事务连接池调优内存不足/Swap飙高检查进程RSSfree -h/ps aux --sort-%mem排查内存泄漏或jvm堆设置网络丢包/延迟分段检查链路ping/mtr/tcpdump区分公网、内网、本机问题Redis缓存穿透检查命中率与热点keyINFO stats/redis-cli monitor加布隆过滤器或空值缓存这张表本身并不神奇神奇的是你要能根据具体题干灵活调整顺序。比如题目如果强调服务器突然负载高就不要一上来抓数据库要先看是CPU还是I/O再判断是正常业务高峰还是异常脚本。系统工程师最忌讳的是用套路硬套问题先收集数据、再下结论才是正确姿势。4.3 怎么把经验感写进答案同样一道笔试大题有经验的系统工程师和应届生写出来的答案区别往往不是知识量而是答案里有没有现场感。我总结了几个写作技巧可以让你的答案看起来更像一个真正维护过生产环境的人。第一使用具体数值而不是模糊描述。比如回答我会定期备份不如写每天凌晨2点用xtrabackup做全量备份保留7天每周六做一次归档备份每月最后一天做一次月度备份并异地拷贝。数值会让答案变得可信但不要胡编尽量贴近常用实践。第二主动写出我如何判断而不是只写我做什么。比如我会用curl -o /dev/null -s -w %{http_code} %{time_total}来判断接口可用性和响应时间这种表达能让面试官看到你具备验证意识。很多操作题其实并不难难的是你能想到去验证。第三会在答案里区分快速止血和根治方案。生产环境出了故障第一时间不是重构代码而是先恢复服务。比如MySQL连接数被打满你可以先临时调大连接数让业务恢复同时马上排查慢SQL最后再决定是优化索引、上读写分离还是加缓存。能分清楚这两个阶段证明你对生产故障有真实认知。第四不要忽略复盘和沉淀这件看似务虚的事。笔试里如果问你怎么提升系统的稳定性不要只答监控告警还可以提到每次故障后要写复盘文档记录故障时间、影响范围、根因分析、处理过程和改进项。系统工程师的价值一方面体现在故障发生时能快速恢复另一方面体现在通过复盘让同样的故障不再发生。最后说点个人体会笔试结束这么久我印象最深的不是某道具体的题目而是这种岗位考察方式背后的逻辑。系统工程师和开发最大的不同不是命令背得多熟而是你有没有把一台服务器当成一个需要长期照看的生命体。上线前做规划运行中盯监控出问题能快速定位事后能复盘并沉淀成文档这一整套循环才是这个岗位真正的核心能力。我自己踩过最大的坑就是刚接触生产环境时只重部署不重验证。服务启动成功了就觉得万事大吉结果第二天发现数据没有备份、磁盘没有监控、日志没有切割差点出大事。那次之后我才明白笔试里反复出现的从零搭建一个系统并做好后续维护从来不是一句空话它就是系统工程师每一天在做的事。准备笔试或刚入职的朋友别急着追求花哨的容器化、自动化先把一台裸机到稳定生产节点这套基本功彻底吃透。地基稳了后面学调度编排、云原生才有根。