2018年那个春天我在宿舍里打开网易实习生招聘的在线笔试链接报考的是运维开发实习生。点开第一道题之前我原以为会像普通校招技术岗那样先来一堆Java或C的选择题结果第一题就是关于Linux进程状态和负载均衡的后面还跟着几道需要写Python脚本处理日志的场景题。整场笔试做下来我的感觉是这不是在考你会背多少面试题而是在考你有没有真正在服务器上摸爬滚打过。当时我就有一个很直观的判断运维开发这个岗位笔试筛的不是“会写代码的人”而是“既懂系统、又能用代码解决运维问题的人”。这几年我带过不少准备校招的同学也时不时有人拿着往年的真题来问我我觉得值得把这类笔试的考察逻辑和准备思路完整拆一遍。如果你是准备投运维开发、SRE、DevOps这类岗位的实习生或应届生这篇内容可以当一份备考地图来用先搞清楚出题人要什么再针对性补短板比疯狂刷题有用得多。1. 出题人到底在筛什么拆解网易运维开发笔试的结构先别急着背知识点。你拿到一套“运维开发”的卷子第一件要做的事是读懂这个岗位在业务里承担什么角色。网易这类一线互联网公司的运维开发不是传统意义上管机房、看流量、调硬件的“网管”而是要把运维工作产品化和自动化的人。服务器规模上来了几百上千台机器靠人肉登录执行命令根本不现实运维开发的核心工作就是写系统、写平台、写自动化工具把“重复的人工操作”变成“可复用的代码服务”。这套笔试的题型分布我回忆下来大致是计算机基础知识包括Linux、网络、操作系统占三成左右编程能力Python为主偶尔有Shell占三成左右工具链和技术组件认知占两成左右剩下两成是开放性场景设计题。这和很多纯后端岗位的卷子有明显区别纯后端会偏重数据结构、算法、数据库原理而运维开发更偏重实战性、系统性和“接口思维”——你的代码不是给用户用的是给机器和团队用的。还有一个容易被忽略的信号笔试时间通常给得很紧题量中等偏大留给你反复琢磨的时间很少。这种节奏其实是故意的。真正的运维场景里线上出了故障没有那么多时间让你慢慢查文档你必须在有限信息下快速判断、快速给出可执行的方案。所以备考时不要只看“会不会”要练“在30分钟内能不能答完并且答对”。1.1 从岗位JD反推考点我当时是先看了招聘JD再决定备考方向的这点建议大家一定要做。运维开发实习生的JD里一般会列这么几条熟悉Linux操作系统熟悉Shell/Python了解常用的开源组件Nginx、MySQL、Redis、消息队列等有自动化运维或监控系统开发经验者加分。每一句话对应到试卷上都是有分值的“熟悉Linux操作系统”对应进程管理、文件系统、权限、系统性能分析“熟悉Shell/Python”对应脚本题、日志分析题、简单算法题“了解常用开源组件”对应部署架构题、中间件使用场景题“自动化运维”对应场景设计题比如写一个监控平台的核心逻辑、设计一套发布系统。你把岗位JD拆完再看卷子就会发现没有一道题是白出的全是倒过来基于岗位要求设计的。所以我备考的时候不是按学科刷题而是按“运维开发日常要干的活”来准备看日志、查负载、做发布、写监控、处理故障。1.2 题型分布与答题顺序策略运维开发笔试题的在线系统通常支持自由跳题我建议先做场景设计题再做编程题最后做选择题。为什么呢因为场景设计题分值高、自由度大最考验思维如果你前面在选择题上磨蹭太久后面很可能没时间认真思考设计题只好草草交卷那基本就告别了。我就是先把几道开放题在草稿纸上列出框架确保至少能拿基础分再回头慢慢啃选择题。选择题部分也不要平均用力。Linux命令、网络基础、操作系统概念这类会就会不会就果断标记跳过不要在一道题上卡五分钟。曾经有同学跟我说他笔试时在一道iptables规则匹配题上纠结了十几分钟结果后面Python脚本题没写完这是非常典型的策略失误。iptables那题就算做对了也就是一分而脚本题一道就是十几分时间分配一定要跟着分值走。2. Linux、网络、系统知识基础题是怎么隐藏杀机的这一部分是很多科班同学觉得“稳了”的部分但恰恰是失分重灾区。原因很简单学校教的Linux和网络都是“概念版”而笔试考的是“实战版”。同样是问进程课本会问你进程和线程的区别笔试会给你一段ps -ef的截图问你哪个进程占了最多内存同样是问TCP课本会问你三次握手的过程笔试会给你一个线上服务大量TIME_WAIT的场景问你怎么排查和处理。2.1 选择题里的“送分”与“陷阱”从内容上看Linux基础知识占比最高的是文件权限、用户管理、进程管理和常用的排查命令。常规操作像chmod、chown、ps、top、netstat、lsof这些肯定要熟。但我发现笔试里比较喜欢考的其实是“命令组合”比如找出某个目录下大于100MB的文件并按大小排序应该用什么命令组合。这其实就是find加ls加sort加管道组合单纯背命令是不可能答的你得真的用过。网络部分的陷阱更多。TCP和UDP的区别、HTTP状态码含义这种题是送分但一到HTTP和HTTPS混合部署、Nginx反向代理、DNS解析过程、CDN回源这些内容就开始有明显分层了。还有一类容易被坑的是“软链接和硬链接”“对称加密和非对称加密”“正向代理和反向代理”这种成对概念平时看起来都懂但放到具体场景里很多人一紧张就选反了。应对方法就是自己画一张对比表把成对概念放在一起理解重点看“解决问题的角度有什么不同”。2.2 性能排查类题目的答题套路运维开发笔试里非常经典的一类题是“服务器负载突然升高你用什么思路排查”这类题表面上没有标准答案但阅卷人心里其实有一份踩分点清单。我当时用的答题思路基本是以下四段第一先看全局指标。登录服务器后先跑uptime看负载看top里是CPU占用高还是内存占用高再结合free、iostat、dstat判断是CPU密集、内存不足还是磁盘IO瓶颈。第二找具体进程。通过top按CPU或内存排序定位到具体进程再用ps -ef --sort-%cpu确认进程的启动时间和状态看看是不是出现了异常进程或僵尸进程。第三查关联问题。如果进程是应用服务就看日志Nginx的access.log、应用的异常日志、系统日志/var/log/messages如果怀疑是请求量突增就结合监控图判断是正常流量高峰还是异常攻击。第四给出临时方案和长期方案。临时方案可能是重启服务、切流量、限流长期方案包括优化代码、加缓存、做容量评估、配置自动扩缩容。这套答题框架不管是笔试还是面试都非常好用。我说的是“思路”面试官真正想看到的其实是这种有层次感的排查逻辑。你写的不是答案是你平时有没有真的处理过线上问题。2.3 服务变慢类问题的书写顺序2018年网易的卷子里有一类印象很深的题是“某服务的响应时间突然从50ms变成5s可能的原因有哪些请尽可能全面地列出并说明排查方式”。这种题很多同学只写两三条就停了比如“可能是网络问题”“可能是数据库慢查询”。分数自然就低。我当时给自己定了一个“不重不漏”的排查顺序从外到内、从网络到应用、从硬件到软件。第一层是网络链路客户端到服务器的网络是否抖动、DNS解析是否变慢、防火墙或安全组策略有没有变化第二层是接入层Nginx或网关的负载、连接数是否打满第三层是应用层GC是否频繁、线程池是否耗尽、有没有死锁第四层是数据层数据库连接池、慢查询、Redis缓存是否命中等第五层是资源层CPU、内存、磁盘、带宽。每一层先看监控、看日志再定位具体问题。这么写的好处是阅卷人一眼就能看出你有全局视野。哪怕你的答案里有些地方不够深入但覆盖面广、有条理就已经能拿大部分分了。3. Python与Shell代码题纸面上的动手能力分水岭笔试里的编程题对运维开发岗位来说考察的重点不是LeetCode那套算法而是“用代码解决实际运维问题”的能力。题目往往非常朴素比如日志分析、文本处理、批量操作、简单的任务调度但朴素不等于简单它考察的是你的基本功是否扎实、代码是否简洁健壮、甚至有没有考虑边界情况。3.1 日志分析题的得分点在哪里拿一个非常典型的题目举例给你一份Nginx访问日志里面包含客户端IP、访问时间、请求路径、状态码、响应大小等字段要求统计出访问量最高的前10个IP并且输出每个IP的访问次数。这题用Shell也能做用Python也能做。很多人的第一反应是写个Python脚本打开文件、逐行读取、用字典统计最后排序输出。逻辑确实没错但得分点其实藏在三个细节里第一你有没有用正则把IP准确提取出来而不是简单的split()然后取错字段第二你有没有考虑文件很大时一次性读入内存会爆掉应该改成逐行读取第三你有没有处理多个空格和日志格式变化的情况。我当初的写法是用defaultdict(int)统计re.match提取IP然后sorted排序取前十。虽然代码不难但几个关键的异常处理到位了就比一堆人在那里直接用line.split( )[0]要稳得多。现在回头看这种题真正考察的就是“你在真实处理日志时踩过坑吗”。3.2 手写代码最容易丢分的三个点一是输入输出格式。不少同学写完核心逻辑结果忘了按题目要求的格式输出比如该用空格分隔却用了逗号导致在线判题系统直接判错。这不是能力问题是习惯问题平时刷题就要养成先看输入输出格式和题目约束的习惯。二是边界条件。比如要处理空文件、文件最后一行的换行符、字段缺失、IP为IPv6格式等。大部分真实日志数据都是不干净的如果你写的代码遇到空行就报错这在阅卷人看来就是“没有生产经验”的体现哪怕逻辑正确也会扣分。三是代码风格和注释。在线笔试一般不强制要求简历级代码规范但如果你能用一个合理的函数把功能封装起来并写上一两句注释说明思路阅卷体验会好很多。我见过有人写200行的脚本完成一个20行就能完成的功能这种代码就算跑通了也很难让面试官觉得你是个好的运维开发。3.3 Shell脚本题不只是会写命令Shell题在卷子里出现的形式一般有两种一种是直接写一段脚本完成某个文本处理任务另一种是给你一段脚本问你输出是什么或者哪里有问题。后者更阴险它往往考察的是sed、awk、grep这几个工具的细节和Shell的变量扩展、条件判断、循环这些容易被忽略的语法点。我印象很深的一道题是给一个文件要求用awk把第2列和第3列调换并输出同时忽略以#开头的注释行。很多人直接用awk {print $3, $2, $1}但处理不了带注释的行也处理不了行内字段数不一致的情况。正确写法需要先判断行首是否为#再处理字段用NF动态判断字段数量。这些细节光看《Linux命令行大全》是学不到的必须真的在终端里反复试过才有感觉。所以备考Shell的时候我建议你把常用的文本处理三兄弟练得滚瓜乱熟grep的匹配和排除、sed的打印替换和插入、awk的列处理和内置变量。每个工具至少找几十行真实日志练一遍练到不用查手册就能写出来为止。4. 工程化内容Git、发布流程、监控报警在试卷上的身影2018年那会儿容器编排还没有像现在这么普及但DevOps理念已经深入到一线互联网公司的运维团队了。笔试内容也很明显地向“工程化”倾斜不再是单纯问“这个命令什么意思”而是问“整个发布流程怎么设计”“监控系统怎么做”。这类题目考察的是你有没有参与过真实的研发协作流程。4.1 Git操作题命令背后的分支管理逻辑运维开发跟代码打交道是日常Git是跑不掉的。笔试里常见的有怎么撤销最后一次提交、怎么把多个提交合并成一个、怎么处理冲突、怎么把本地代码强制推送到远端。这些命令本身不复杂难的是你要理解分支管理背后的逻辑发布分支、功能分支、hotfix分支之间怎么流转遇到冲突时应该保留谁的版本。我记得卷子里有一道题提到“某同事提交了一个错误的配置文件到master现在要把代码回滚到上一个版本但不能丢失另一个同事的新功能提交”这其实考察的就是git log、git revert和git reset的区别。很多人第一时间想起git reset --hard但这么做的结果是把之后的提交全部丢掉且会改写历史如果代码已经推到了远端还会影响别人。正确做法是用git revert在历史里新生成一个反向提交既回滚了错误内容又不破坏其他人的提交。这个点考的不是命令背得熟不熟而是你知不知道在协作环境里“不能随便改写历史”。4.2 发布流程设计题工具选型的底层逻辑场景设计题里出现过这样一种请设计一个简单的代码发布流程要求能降低上线风险和回滚成本。这题如果你只是写“用scp拷代码”这种基本就拿不到分。阅卷人想看的是你有没有把发布当成一个系统工程来考虑。我当时答的核心是分阶段发布和自动回滚先把代码从Git拉取到构建机做编译和静态检查产物打包上传到制品库然后在预发环境部署跑一轮冒烟测试通过后进入灰度发布阶段先把新版本推给5%的流量观察核心指标再逐步放大到30%、100%每一步都配有健康检查和自动回滚机制一旦指标异常立即切回旧版本。工具选型上提了Ansible做批量配置管理SaltStack做远程命令执行Jenkins做持续集成用Nginx或负载均衡器做流量切换。这类题考察的不是你会不会某个具体工具而是你有没有“降低风险”和“可回滚”的意识。哪怕你工具用的和你平时习惯的不一样只要能把流程闭环讲清楚就能拿高分。4.3 监控报警题数据闭环思维监控是运维开发的核心工作之一。笔试经常给一个场景现有服务经常半夜挂掉都是用户投诉之后才发现让你设计一套监控系统。很多人会答“用Prometheus采集指标配置Grafana展示”但这样答完基本就没了。出题人真正希望你写的是监控的完整闭环数据采集、指标存储、告警规则、通知渠道、告警处理、复盘归档。数据采集部分要区分系统层指标和应用层指标系统层有CPU、内存、磁盘、网络应用层有QPS、响应时间、错误率、JVM内存。告警规则部分要能写明白阈值怎么定比如CPU连续5分钟大于80%才告警而不是瞬时值避免抖动误报通知渠道要有分级P0级同时联系值班人、技术负责人P2级只在群内通知。最后还要有告警处理记录和复盘流程形成“告警-处理-复盘-改进”的闭环。这套东西你只有当过真实的“背锅人”才会写出一套自己能信服的方案。5. 场景设计题怎么答才不白写从故障排查到系统设计如果说前面的题目是在筛“熟练度”场景设计题就是在筛“成熟度”。运维开发岗位最值钱的不是你会多少个工具而是你在面对一个模糊问题时能不能快速给出结构化的解决方案。这类题没有标准答案但评分的差异可以非常大。5.1 故障处理类题的结构化表达最典型的一道题是“线上服务挂了你是第一发现人请描述从发现到恢复的完整过程。”这种题看起来谁都能写几句但高分的答案是有时间线和行动清单的低分的答案往往是流水账。我给自己的答题框架是“发现-定位-止损-恢复-复盘”五步。发现环节写清楚你怎么感知到监控告警、用户反馈还是巡检发现不同的发现渠道对应不同的响应速度定位环节用我之前说的外到内排查法止损环节要果断先切流量、降级、回滚而不是当场改代码恢复环节写清楚具体操作和验证方式复盘环节要输出结论根因是什么、怎么避免再次发生、下次如何更快发现。写这种题最忌讳的是跳过止损直接去讲怎么定位根因。真实的线上故障处理第一原则永远是先恢复业务再研究原因。如果你能体现这个意识阅卷人基本就能确定你是有实战潜力的。5.2 设计类题目的“三视角”答题法除了故障处理还有一类是“请设计一个XX系统”。我考的那年有一道印象很深的题“请设计一个简单的服务器批量管理平台要求能实现对多台服务器的命令执行和文件分发。”这题如果你直接从“用什么框架、什么数据库”开始答思路就跑偏了。这类设计题建议从三个视角展开用户视角、系统视角、运维视角。用户视角是谁在用这个平台是运维同事他们要能提交批量执行任务、看执行结果系统视角是整个平台的架构一个中心节点加每台服务器上的Agent中心节点负责任务下发和结果收集Agent负责执行命令和上报状态运维视角是安全性和可靠性Agent的认证方式、命令执行的权限管控、失败任务的重试和日志留存。三视角写下来你的答案就非常立体了。哪怕里面很多细节并不深入但至少证明你想问题的方式是成熟的。5.3 场景题的“信息呈现”技巧最后说一个答题之外的技巧。场景设计题通常没有输入输出样例阅卷人看的是你卷面上的结构。如果一上来就是密密麻麻的整段文字阅卷人很难快速抓到你的思路分数自然不会高。我的习惯是在答题区先写一个大纲比如1. 整体架构2. 关键流程3. 容错设计4. 有待补充的点。然后每一点用三五句话展开关键名词加粗或者在行首标注。这比写一篇小作文要有效得多。笔试的阅卷时间是有限的你帮阅卷人省时间阅卷人就给你多打分。更重要的是要把“不确定的地方”也写出来比如“这里如果引入消息队列会更稳但我对它的性能不太确定所以先不展开”。这种话看似示弱实际体现的是你的边界感——你知道什么能确定什么需要进一步验证这比假装全懂却写得模糊强得多。6. 复盘之后的三个认知运维开发这份工作到底需要什么笔试结束后走出考场或者说关掉笔试页面的那一刻我并没有松一口气的感觉而是觉得被一张卷子照出了很多短板。后来我拿到了面试机会也顺利入职实习再从实习到正式参与生产环境的运维开发工作再回看这份笔试我越来越觉得它考的东西和真实工作之间的重合度高得惊人。第一个认知是运维开发首先是一名开发其次才是运维。代码能力是所有工作的基础。你可以不会K8s但你不能不会Python你可以不了解某个监控系统但你不能不会分析数据、写自动化脚本。笔试里代码题权重很高工作里更是如此我写的最多的不是运维脚本而是各种平台的后端接口和数据处理逻辑。第二个认知是运维的核心竞争力是“故障处理能力系统设计能力”的组合。单纯会排查故障、会上手操作服务器的人很多但能把一套故障处理经验沉淀成自动化平台的人很少。我刚入职那会儿天天在处理重复的告警和工单后来才意识到高级的运维开发不是让自己越来越忙而是通过代码和系统让自己越来越“闲”。笔试里的场景设计题考的就是你有没有这种“自动化自己”的思维。第三个认知是校招笔试只是起点真正的分水岭在实习期的第一周。笔试可以突击准备但工作中的系统是复杂的、脏的、充满历史包袱的。提前把网络、操作系统和Linux基本功打牢是应对这些复杂性的最佳姿势。就像我在笔试时复盘出的那套故障排查思路后来真上了生产环境发现每一步都还能用上只不过信息源从考试题目换成了监控面板和日志系统。如果你正在准备运维开发岗的笔试我的建议很直接别只刷算法题去做几件真实的事。在自己的电脑上装一台虚拟机部署一套Nginx加PHP或者Python服务用Ansible同时管理两台节点自己写脚本扫描日志统计异常给自己搭建一个简单的监控看板。做完这些事再回头看笔试题你会发现很多题目根本不用背因为答案就是你每天在干的事情。