运维校招笔试攻略：从Linux排障到Kubernetes核心链路

又到一年校招季后台也陆续有读者留言问运维笔试题怎么准备。说实在的运维笔试不像开发岗那样有那么多标准答案它更看重你是否真正理解系统底层、有没有排障思路、能不能扛住线上故障。我翻出早年间整理的网易2018校园招聘运维工程师笔试卷回忆版重新做了一遍感触还挺多。今天不打算逐题给答案那没意义我更想借这份试卷聊聊它背后的考察逻辑、高频技术点以及一个校招生该怎样从能答对题进化成能扛住生产环境。这篇文章适合正在备战校招的人、刚入行的初级运维也适合想系统梳理知识体系的转行朋友。1. 重新审视这份笔试卷它到底在考什么1.1 网易运维团队想要什么样的人很多人以为运维笔试就是考Linux命令、考网络协议其实这只是表层的筛选。网易这样的公司招聘运维工程师的时候核心是想找一种能凌晨三点爬起来处理故障还能保持头脑清醒的人。笔试阶段没有办法测试你的抗压能力但它可以通过场景题、综合题来看你有没有排障思维遇到问题是不是手足无措能不能先复现、再定位、再解决、再总结这跟背多少命令没太大关系。我记得那份试卷里印象深刻的不是那些单纯什么是TCP三次握手的知识题而是一道类似网站访问变慢你怎么排查的开放题。这题没有唯一答案但能看出答题人的思路是线性的、还是网状的。优秀的人会先确认现象是全部页面慢还是部分慢是新功能上线后变慢还是一直慢再分层排查客户端、DNS、网络、负载均衡、应用、数据库、存储最后给出可执行的排查工具和命令。这样的答案哪怕不完全正确也能让面试官觉得这个人能干活。1.2 从题型分布反推核心知识域结合回忆版的题型这类笔试卷通常会覆盖七个模块Linux基础与系统管理、网络与协议、数据库、脚本编程Shell/Python、监控与告警、集群与虚拟化、安全基础。占比上Linux和网络加起来可能接近一半脚本和数据库各占一两成其余是场景题。这个分布其实非常合理因为运维日常就是跟服务器、跟网络上的流量打交道而这些底层能力决定了你能走多远。这里说点我的看法近几年笔试卷里容器和云原生的比重明显增加但2018年这个时间点Docker和Kubernetes还处在快速普及阶段所以关于容器的问题更多停留在是什么和怎么用很少直接让你写一个Pod的编排文件。但是放到今天去看如果还只准备当年的知识范围肯定是不够的。后面我会单独讲一下Kubernetes和containerd这条调用链那是云原生运维绕不开的硬知识。2. 高频核心技术点深度拆解2.1 Linux和系统管理不只是背命令Linux是运维的地基。笔试里常考的包括文件权限rwx、SUID、SGID、sticky bit、进程管理ps、top、htop、kill、僵尸进程、磁盘管理df、du、inode、分区、LVM、系统启动流程BIOS到systemd。这些知识点看起来零碎但它们背后都指向一个能力你对一个正在运行的操作系统模型是不是有清晰认知。举个例子题目可能问系统load average很高但CPU使用率不高是什么原因。很多人第一反应就是CPU不够加上核数。但实际现网里最常见的原因是D状态进程不可中断睡眠通常是磁盘IO卡住或者NFS挂载超时导致的。当年我遇到过一次这样的情况一台跑批任务的机器load到了80多但top里看到CPU才10%最后用ps -eo stat,pid,comm | grep ^D发现一堆进程卡在读取远程存储上因为存储端专线闪断。所以笔试考load average不是考你记不记得三个数而是考你能不能把load和CPU、IO、进程状态联系起来。答题时如果可以写出先看vmstat的r和b列再看iostat的await就能和普通背命令的候选人拉开差距。再比如systemd管理服务题目可能让你写一个service unit文件。这种题很多人会栽在细节上ExecStart必须写绝对路径Type有simple、forking、oneshot的区别Restartalways后面要不要加RestartSec。我建议笔试时即使不要求写完整也要把关键参数写对并简单解释为什么这些参数重要。比如LimitNOFILE不设置的话服务默认只能打开1024个文件高并发下必然报too many open files。2.2 网络基础与排障思维网络题在运维笔试里的地位不亚于Linux。考察点基本围绕TCP/IP协议栈、HTTP、DNS、负载均衡这些。三次挥手四次握手、TIME_WAIT大量出现怎么处理、HTTP 502/504的区别这些都是老生常谈。但我觉得更有价值的是看你能不能把这些知识串联到一次真实的排障过程里。比如线上出现大量TIME_WAIT这个经典问题。有经验的运维会先回答TIME_WAIT是TCP主动关闭连接后进入的状态一般出现在服务端主动关闭大量短连接时。然后会分析原因高并发短连接、服务端设置了短keepalive、连接池没复用等。解决方案可以从内核参数net.ipv4.tcp_tw_reuse在客户端场景、tcp_fin_timeout减小等入手但更要紧的是在应用层优化连接池。你如果只在试卷上写调内核参数面试官会觉得你不够全面甚至可能踩坑比如tcp_tw_recycle在NAT场景下会导致连接异常这个参数已经在较新内核里废弃了。再提一下tcpdump。现在很多年轻的运维太依赖监控图表反而到了需要抓包的时候不知道怎么分析。笔试试卷里如果出现如何抓取本机访问某个IP的80端口数据包这种题标准答案就是tcpdump -i eth0 host 192.168.1.10 and port 80 -nn -w /tmp/xx.cap再配合Wireshark分析。写答案时一定要记得加-nn不解析主机名和端口名不然抓包的时候会发DNS查询干扰现场-c限制包数量避免抓太多导致文件过大。2.3 数据库运维主从复制与慢查询数据库这类题笔试里一般不会让你写特别复杂的SQL更多是问索引、事务隔离级别、主从复制原理、慢查询优化。MySQL是出场率最高的。主从复制流程必须要会默写主库binlog记录变更从库IO线程拉取binlog并写入relay log从库SQL线程重放relay log。然后会问主从延迟怎么办常见原因有大事务、DDL、从库机器性能差、网络延迟、刷盘策略等。答题时可以提到Seconds_Behind_Master这个指标但要指出它只能作为参考因为如果从库IO线程或SQL线程卡住这个值可能不准确。更高级一点可以提到pt-heartbeat这种基于主键时间戳的精确检测工具。慢查询优化也是高频。给一条SELECT * FROM orders WHERE user_id123 ORDER BY create_time DESC的题目你得能想到给(user_id, create_time)建立联合索引并且理解为什么覆盖索引能避免回表。很多候选人会写加索引但不写索引字段顺序等于白答。我在生产环境调慢查询时经常会被这条规则坑到联合索引最左前缀原则。如果条件里有等值又有排序索引顺序应该是等值字段在前排序字段在后。2.4 容器与Kubernetes从containerd调用讲到底层链路最近看到热词里有一条想知道kubernetes是如何调用containerd的这其实踩中了云原生运维的命门。作为一个从事运维多年的人我强烈建议各位在准备运维笔试的时候不要只停留在会写Dockerfile, 至少要搞明白一条核心链路Kubelet通过CRI调用containerdcontainerd再通过CNI配置网络通过containerd-shim拉起runcrunc最终通过Linux内核命名空间和cgroups创建容器进程。这个链路怎么去理解打个比方Kubernetes是酒店前台你要订房间调度PodKubelet是楼层服务员接收前台指令告诉后厨containerd该做饭了containerd是后厨总管负责准备食材、安排厨师但它自己不做菜而是让runc这个厨师进入一个有独立隔离炉灶命名空间和资源限额cgroups的小隔间里把菜炒出来。containerd-shim则是后厨总管和厨师之间的传菜窗口即使后厨总管挂了厨师也能继续炒完手里那道菜。笔试或者面试里如果让你写Pod创建过程你可以按这个顺序展开客户端请求写到etcd - scheduler调度到某节点 - kubelet通过CRI接口调用containerd - containerd准备镜像、创建沙箱和容器 - 调用runc - runc通过clone()创建进程并应用命名空间和cgroup - 配置CNI网络 - 启动容器进程。能把这个链路讲清楚基本就超过90%的候选人了。再深挖一层containerd为每个Pod启动一个containerd-shim进程这个shim的作用不只是转发命令还负责收集容器进程的退出状态并上报给Kubelet。这样K8s才能做优雅终止和垃圾回收。所以如果你在试卷上遇到containerd和Docker是什么关系这种题不要简单答Docker是容器引擎而是说Docker使用的容器运行时默认是containerdKubernetes通过CRI对接的是containerd而不是Docker daemon这也是Kubernetes从1.24之后移除dockershim的根本原因。3. 从笔试卷到真实职场生产环境从零搭建的完整框架3.1 需求分析与架构规划笔试中可能给你一个场景从零搭建一套Web系统你需要做哪些事情。这种题很贴近生产实际也特别好答出彩。我建议按需求-规划-部署-运维四步来写每一步都带上具体产物。先说需求分析。你至少要确认几个问题系统承载什么业务预计访问量多少峰值是多少数据量多大需要几台服务器这些不是笔试题要你算出来的精确值而是考察你有没有体量意识。比如一个面向全校师生的抢课系统和一个内部办公OA规格肯定不一样。前者要提前评估QPS可能要上负载均衡和缓存后者可能一台高配机器就够了。然后是架构规划。我的经验是先把目录规范和命名规范定了不然后面全是坑。比如统一用/data作为数据盘挂载点/data/logs放日志/data/backup放备份主机名用dc01-web-01这种格式让人一眼看出它在哪个机房、什么角色、第几台。监控里最怕看到一堆localhost或者hostname毫无规律的机器出了问题根本定位不了。3.2 自动化部署与配置管理生产环境从零搭建如果全部手动装系统、敲命令那运维的尊严就没有了。笔试如果问如何批量部署100台服务器你要想到三层自动化系统安装层用PXE加Kickstart现在也可以用Cobbler或MAAS配置层面用Ansible/SaltStack/Puppet我比较推荐Ansible因为无Agent、基于SSH、学习曲线平缓业务发布层面可以用Jenkins或GitLab CI加自研脚本。我实际做过一个小规模的生产集群初始化用的就是Ansible加一个init.ymlplaybook。这个playbook会做以下几件事设置主机名、配置yum源、关闭SELinux、调整系统文件描述符、写入sysctl内核参数、安装基础工具包、配置统一的history格式记录操作时间和操作者、拉取公司标准化的.bashrc和.vimrc。看起来琐碎但这些就是线上环境一致性的保障。为什么一致性这么重要因为运维界最大的敌人不是故障而是环境差异。昨天你在一台机器上改了配置今天新开的机器没有这个配置到了出问题的时候到处都找不到原因。笔试时你如果能主动提到配置管理保证一致性这个点已经比大多数只讲用脚本批量执行命令的答案高一个段位。3.3 监控与日志体系搭建如何监控一套系统几乎是必考题。我的基本盘是采集层用Prometheus加node_exporter抓服务器指标用blackbox_exporter做探活数据都存在Prometheus里展示层用Grafana画面板告警用Alertmanager。日志层面则是Filebeat采集、Kafka缓冲、Logstash过滤、Elasticsearch存储、Kibana展示也就是常说的ELK套件。写答案的时候要记住一个原则监控不是越多越好而是要在发现故障和不打扰人之间取得平衡。很多新手喜欢把阈值设得很敏感结果每天告警轰炸真正出问题的时候反而被淹没了。我建议告警分三个级别P0页面打不开、服务宕机立即短信加电话P1延迟升高、错误率增加短信P2磁盘使用率超过80%、证书即将过期只发邮件或企业微信白天处理。同时要写清楚每个告警的处理预案没有预案的告警等于没有。哪怕是笔试场景你也可以加上一句告警必须配套SOP这会让面试官眼前一亮。3.4 安全加固与备份容灾运维笔试里安全相关的常见考点有SSH安全禁止root登录、密钥认证、修改端口、防火墙策略iptables/firewalld最小化开放端口、常见Web攻击SQL注入、XSS、CSRF怎么防、数据备份策略怎么制定。这些不能只会概念要落到实际命令。比如SSH加固我会用sshd_config里配置PermitRootLogin no、PasswordAuthentication no、MaxAuthTries 3。如果还要再加一道防线就装fail2ban。备份策略最好用3-2-1规则来回答数据保留3份副本存放在2种不同介质上其中1份放在异地。MySQL备份常用mysqldump做逻辑备份但大库最好用XtraBackup做物理备份加上binlog做增量恢复。笔试答到这里我会补充一句备份必须定期做恢复演练没有演练过的备份都不能叫备份。这也是血泪教训有一次我们发现某台机器每天备份可真到恢复的时候备份文件损坏只能靠binlog往前追损失了好几个小时的数据。4. 常见的送分题与陷阱题答题技巧与避坑4.1 经典场景题怎么答才有层次感场景题是笔试中区分度最高的题型。它的套路一般是某个服务出问题了你怎么办。我给你的万能思路是影响面评估 - 工单/降级 - 定位 - 恢复 - 复盘。这套思路不仅用于笔试也适用于实际故障处理。先说影响面评估。拿到告警先别急着操作问自己影响多少用户是全部不可用还是一部分有没有涉及资金交易如果情况严重先考虑降级和止损。比如缓存集群挂了可以先切流量到DB的只读副本虽然慢一点但至少能用再或者直接重启服务恢复虽然不优雅但先恢复业务再谈根因这在运维界叫先恢复再定位。然后才是定位用前面说的分层排查法一步步缩小范围。最后一定要写复盘报告至少包含故障时间线、根因、恢复动作、后续改进项。笔试时哪怕没有真正经历故障能用这个框架写出报告结构也能显示你具备专业的故障处理素养。我见过很多候选人答场景题上来就写一连串命令让人觉得缺乏章法。比如网站访问慢你可以这样分层先检查DNS解析是否正常dignslookup再检查链路从客户端到服务器的每一跳mtr然后看负载均衡和后端节点的QPS、响应时间监控面板接着看应用日志和慢SQL最后检查资源层CPU、内存、磁盘。每层用什么工具、可能出现什么结果、下一步怎么走都写出来判卷人会觉得你很靠谱。4.2 脚本题要避免的五个坑运维笔试基本必考Shell或Python脚本而且很多题看着简单实际全是暗坑。我印象最深的一个坑是变量赋值空格。题目让你写脚本统计日志里出现次数最多的IP答案形如awk {print $1} access.log | sort | uniq -c | sort -rn | head -1这倒不难。难的是他们会在题目里挖这种坑写循环的时候for ip in $(cat ip_list.txt)如果某个IP是空行或者包含通配符可能执行出错或者你写if [ $a x ]但$a为空的时候Shell会报unary operator expected。这些都是面试官最喜欢埋的点。我建议脚本题遵循五个原则第一变量使用前必须初始化并用双引号包裹比如if [ $a x ]第二开头加上set -euo pipefail让脚本遇到错误就退出、管道中间出错也能被捕获、未定义变量直接报错第三不要依赖临时的绝对路径尽量用相对目录或者通过$(dirname $0)定位脚本所在目录第四涉及远程执行的命令一定要加timeout比如timeout 10 ssh host command防止SSH卡死导致脚本挂住第五尽量避免使用cat加管道直接用重定向减少无谓的子进程。Python脚本题则要关注异常处理。比如写一个监控端口存活的脚本不要只写socket.connect成功就完事还要考虑连接超时、连接被拒绝、DNS解析失败几种异常情况并分别打印不同的错误信息。这种边界思考能力恰恰是运维在生产环境里最需要的。4.3 用答题模板包装你的系统性知识笔试卷的简答题和场景题答题篇幅有限但你要让判卷人在有限时间里看出你的系统能力。我的建议是采用**结论先行 证据支撑 延伸补充**的写法。结论先行先直接回答这个问题我会从应用层、数据库层、基础设施层依次排查。然后写证据比如我优先查看nginx access log中是否有大量500状态码以及耗时分布因为P99耗时的突刺最能反映问题。最后延伸补充如果确认是数据库慢查询导致我会用mysqldump先做一次一致性快照不这里应该用pt-query-digest分析慢日志——延伸要适度不要离题。另外一个小技巧遇到不会的题不要留白。哪怕不会也要写一个思路比如这个问题我没有实际处理过但按照我的理解我会先从xx方面入手并查阅xx文档验证。这能体现你的学习能力和抗压能力。笔试不只是考知识也是考态度留白在笔试里几乎等于放弃。5. 备考路径与自我提升从笔试到真正的运维5.1 三个月夯实基础的计划参考如果你现在处于备战校招阶段我建议按三个月来准备。第一个月主攻Linux和网络把《鸟哥的Linux私房菜》的基础篇和服务器篇过一遍同时用虚拟机自己搭CentOS或Ubuntu环境把用户、权限、磁盘、计划任务、systemd等服务都亲手配一遍。第二个月主攻Shell/Python脚本和数据库每天至少写一个小脚本比如批量重命名文件、监控磁盘空间、解析日志。数据库方面把MySQL的安装、主从搭建、慢查询优化都练一遍。第三个月进入刷题和模拟故障阶段可以找往年的笔试题练手更重要的是自己搭一个两台机器的小集群故意搞坏它比如拔网线、杀掉某个进程、让磁盘写满再强制自己恢复。这里要提醒一下纸上谈兵是校招生最大的短板。你简历上写熟悉Linux面试官大概率会问你平时用什么发行版你vi用得怎么样系统负载高有什么排查思路。如果你只是在虚拟机里敲过几次命令一紧张就会露馅。所以练的时候一定要脱离教程先给自己出题再动手解决。5.2 用开源项目练出生产感市面上有很多开源项目可以当练手靶场。我推荐两个方向一是搭建一套完整的监控系统用Prometheus监控一台真实的机器再配上Grafana面板和Alertmanager告警二是写一个自动化部署工具用Ansible把一台全新的CentOS初始化成Web服务器包括安装Nginx、配置防火墙、部署一个静态页面。做完这两个项目你对生产环境从零搭建就不再是空泛的概念了。很多人在简历上写熟悉Linux但具体做过什么说不出道道。如果你能把Ansible的playbook传到GitHub把Grafana的截图放在作品集里再写一篇部署笔记说服力会强很多。企业招聘运维最看重的就是你有没有自己动手从0到1把系统跑起来的经历哪怕是从虚拟机开始。5.3 运维工程师需要学什么一张持续进化的地图结合热词运维工程师需要学什么我给一套分类基础层Linux、网络、常见的服务、脚本层Shell、Python、Go可选、数据层MySQL、Redis、消息队列、平台层Docker、Kubernetes、CI/CD、Ansible、监控、安全层等保、入侵检测、漏洞管理、软技能沟通、文档、项目管理、复盘。这几年运维角色正在发生明显变化。传统装系统、重启服务的手工运维逐渐被平台化和自动化替代现在更热门的是开发运维和运维开发工程师。你不仅要会操作kubectl还得能写Controller、扩展CRD不仅要会用Prometheus还得能二次开发Exporter。所以我的建议是脚本语言一定要精通再学一门面向运维的开发语言首选Go。Kubernetes那些核心组件比如kubelet、containerd本身就有大量Go代码学会Go之后你看源码、改bug会顺手很多。另外一个容易被忽略但很重要的能力是业务理解。如果你连系统的业务逻辑都不知道那你做再多的监控也只是黑盒监控。真正值钱的运维能在别人说链接不稳定的时候主动给出这块业务依赖的下游服务有超时重试机制需要检查连接池配置这种建议。这种跨层理解力是需要在做项目、看日志、读代码中反复打磨的。写在最后做完了这份网易2018校招运维笔试卷我有一个很强烈的感受技术永远在迭代但底层思维是连续的。当年考的TTCP、MySQL主从、Shell脚本今天依然是运维的基本功而当年还没有大规模普及的Kubernetes现在已经成为新的基本功了。我个人的体会是备考运维笔试不要追求押题而是要建立一套发现问题 - 定位问题 - 解决问题 - 避免复发的思维闭环。把一个故障当成一次事故去复盘比刷十道题都管用。最后再分享一个小技巧也是我在带新人的时候反复强调的学会写文档尤其是故障记录和操作手册。笔试考的是你如何答题工作中考的是你如何留下可追溯的记录。把每一步操作都写清楚原因、命令、结果这不仅是给自己积累财富也是给团队留下资产。运维这条路很宽也很有挑战祝你准备顺利。