网易2018实习生招聘笔试题-运维开发实习生这个话题放在今天看依然有不少值得嚼的东西。当年这批题目流传出来后很多准备面试的朋友把它当成“网易运维开发岗到底考什么”的风向标也有人把它当作一套系统的运维开发自测题来刷。我接触过不少参加过那场笔试的同学也反复看过网上流传的版本客观说一句这套题不偏不怪但覆盖面相当广从Linux基础到Shell/Python脚本从网络协议到数据库、Web服务再到监控和CI/CD几乎把运维开发日常要碰的东西都扫了一遍。这篇博文就围绕这套题目做一次完整复盘。我不会只给“答案”而是把每类题背后的考察意图、答题思路、常见失分点以及现在的备考建议都讲清楚。无论你是准备运维开发岗位的应届生还是想系统梳理运维开发知识体系的在职新人这篇文章都可以当作一份比较实在的参考。1. 运维开发笔试到底在考什么2018年网易真题的整体结构复盘1.1 从真题看网易对运维开发实习生的能力预期先聊一个很多人没想明白的问题运维开发和传统运维、纯开发之间的区别到底是什么。2018年网易这套笔试题其实已经给了答案——它既不考纯Linux命令背诵也不考算法题而是把重心放在“用代码和工程化手段解决运维问题”这件事上。从题目结构来看大致可以分成这么几块Linux操作系统与基础命令、Shell和Python脚本编写、网络协议基础、数据库和缓存MySQL、Redis、Web服务器与反向代理Nginx、监控与日志、以及一两道比较开放的场景设计题。这个结构在当年算是很有代表性的放到现在依然是运维开发岗位笔试的“标准模板”。我当时拿到这套题的第一感觉是网易对实习生的定位不是“来了就能独立负责xx系统”的熟手而是“基础扎实、有工程思维、能快速上手”的苗子。所以题目难度整体不算高但非常考验知识面的广度。举个例子题目里会出现“查看系统负载的命令有哪些”“如何查看端口占用”“如何统计日志中某个关键词出现次数”这类基础题但也会出现“写一个脚本监控Nginx进程状态异常时自动拉起”这种需要综合能力的题。前者考的是你有没有基本操作功底后者考的是你能不能把命令、脚本、定时任务、异常处理串成一条完整的自动化链路。1.2 整套题的难度曲线与出题逻辑仔细看这套题难度并不是均匀分布的而是有明显的梯度。前面是单选题和多选题覆盖Linux、网络、数据库的基础知识点中间是简答题需要解释概念或者写出关键命令后面是编程题和场景题需要完整地写出脚本或给出设计方案。这种出题逻辑其实暗合了招聘筛选的漏斗模型先用客观题快速过滤掉基础不牢的人再用主观题筛选出有实战思维的人。对考生来说最大的坑往往不是后面的编程题没写出来而是前面的选择题错得太多——毕竟选择题对就是对错就是错没有“部分得分”的说法。我记得当时有同学复盘时说错得最多的居然是Linux基础题比如crontab的格式、df和du的区别这种。原因是平时用Linux更多是“点鼠标式”操作或者复制粘贴命令很少真正理解命令的参数和原理。面试官想看到的显然不是这种“用过但不懂”的状态。1.3 2018版真题对现在备考的参考价值可能有人会说2018年的题都过去这么多年了还有参考价值吗我的看法是有价值而且要重视。运维开发这个岗位的核心知识栈这几年并没有发生颠覆性变化Linux、网络、数据库、脚本、监控、CI/CD依然是日常工作的主旋律。变的只是工具链的丰富程度比如容器化、K8s、云原生但底层的“内功”没有变。所以这套题完全可以作为一份“运维开发知识体检清单”来用。你不需要纠结“这是2018年的题是不是过时了”而是应该问自己这些知识点我现在是不是真的掌握了如果让我现在去做这套题我能拿多少分另外再补充一点我见过很多人在准备运维开发笔试时陷入一个误区疯狂刷算法题。不是说算法不重要而是运维开发岗位的笔试题通常不会出太深的算法更看重的是你对系统、网络、业务的综合理解能力。把时间花在Linux排查、脚本编写、数据库原理这些更贴合岗位需求的点上性价比要高得多。2. Linux与系统基础题看似送分实则最容易翻车2.1 命令类题目的高频考点与易错点Linux基础在2018年网易运维开发笔试题里占了相当大的比重而且考得非常细。列举几个我在复盘时看到的典型考点查看系统负载的命令uptime、top、w以及cat /proc/loadavg。查看端口占用netstat -tlnp、ss -tlnp需要注意ss是netstat的替代方案性能更好。查看磁盘空间df -h和du -sh很多人搞不清这两个命令的区别df看的是文件系统级别的使用情况du看的是目录/文件实际占用的磁盘块大小。日志统计grep、awk、sort、uniq -c的组合使用比如统计Nginx日志中IP访问次数Top10。定时任务crontab -e的格式五个时间字段分别是分、时、日、月、周这个格式几乎年年考。这些命令看着基础但真正能在笔试中准确写出来的人并不多。原因在于很多人平时用Linux都是“查到什么用什么”没有刻意记忆命令的标准输出格式和参数含义。比如netstat -tlnp中每个参数分别代表什么t: TCP, l: listening, n: 数字显示, p: 进程信息如果只是背了命令而不知道参数含义换一个需求就抓瞎了。我个人的建议是复习Linux命令时不要只背命令本身要把“命令-参数-输出-使用场景”串成一条线。比如top命令你不仅要会敲top还要知道top输出里的load average三个值分别代表1分钟、5分钟、15分钟的平均负载以及如何判断系统是否过载一般经验值是超过CPU核数的70%-80%需要关注。2.2 系统概念题的答题框架从“是什么”到“为什么”除了命令题Linux部分还会考一些系统概念题比如进程和线程的区别、用户态和内核态、软链接和硬链接、僵尸进程和孤儿进程等。这些概念题最大的特点是看起来都背过但用文字准确表达出来并不容易。以“软链接和硬链接”为例网上有无数篇教程但很多人一上考场就写不清楚。我建议用“文件系统的inode机制”来组织答案硬链接本质上是多个目录项指向同一个inode删除其中一个链接不影响其他链接访问数据软链接符号链接则是一个独立的文件里面存储的是目标文件的路径如果目标文件被删除软链接就失效了。这种答法的好处是它体现的不是“背过定义”而是“理解原理”。面试官看主观题时最在意的就是你有没有把底层机制讲清楚而不是堆了多少专业名词。还有一类常考题是系统排查思路比如“服务器负载突然升高如何排查”。这种题没有统一答案但有一个比较标准的排查路径先用top或htop看CPU和内存占用靠前的进程再用vmstat看系统整体的运行队列和上下文切换情况接着用iostat看磁盘I/O是否瓶颈最后结合dmesg看有没有OOM或硬件报错。把这条路径写清楚比写一堆零散的命令要有说服力得多。2.3 结合真题场景如何用“监工思维”解Linux题我在复盘Linux部分时发现网易的题目特别喜欢把命令考法和“监控/排查”场景结合起来。比如它不会直接问free -m的输出怎么解读而是问“系统内存不足时如何定位是哪个进程占用最多内存”这就把命令考察升级成了场景分析。这种出题方式对考生提出的要求是不仅要懂单个命令还要具备“监工思维”——拿到一台出问题的机器我能用什么命令、按什么顺序、多长时间内定位到问题根因。这其实是运维开发日常工作的核心能力。对备考者来说与其把命令列表背得滚瓜烂熟不如在本地虚拟机或云服务器上多做几次故障演练。比如故意把一个服务停掉、把磁盘写满、把CPU占满然后现察自己的处理过程看看能不能用最快的速度定位并恢复。这种训练对笔试和面试都极有帮助因为它把你的知识从“记忆层面”拉到了“应用层面”。3. Shell与Python运维开发的“手”和“脑”3.1 脚本题的考察权重与评分逻辑2018年网易运维开发笔试题里脚本题属于压轴级别的存在。这类题分值高、区分度大也是最容易拉开差距的部分。从题目风格来看Shell和Python都有涉及Shell更偏向系统管理和文本处理Python则偏向逻辑处理和简单的小工具实现。我记得有一道比较有代表性的题是写一个脚本每5分钟检查一次Nginx进程是否存在如果不存在就尝试启动并记录日志。这题看起来简单但实际上考察了好几个点进程检查的方式pgrep、ps -ef | grep、pidof、条件判断语法、启动命令的调用、日志的记录方式、定时任务的配置crontab或脚本内循环等。很多人在这种题上失分不是因为不会写而是因为细节不完整。比如只写了ps -ef | grep nginx却没用grep -v grep过滤掉grep自身进程比如判断语句里没加 logfile 21导致日志信息丢失比如没有考虑到脚本需要设置PATH环境变量。这些细节恰恰是面试官最看重的部分因为运维开发的脚本是要在生产环境里跑的一个细节失误就可能导致脚本失效。3.2 Shell脚本的“高分写法”从能跑到跑得稳在笔试中写Shell脚本我强烈建议遵循一个原则即使没有要求也要把脚本写得像一个可以上线使用的生产脚本而不是一个演示用的玩具。具体来说可以注意这么几点脚本开头加上#!/bin/bash和必要的注释。使用变量时加上set -u防止未定义变量报错或至少声明变量时注意命名。检查关键命令是否存在比如command -v nginx。启动服务后要确认是否真的启动成功而不是盲目相信命令执行完就没事了。日志要带时间戳方便回溯。如果脚本可能被重复执行要考虑幂等性比如先判断进程已存在就直接退出。举个例子一个简化的Nginx守护脚本可以写成这样#!/bin/bash # desc: check nginx process and restart if down NGINX_BIN/usr/local/nginx/sbin/nginx LOG_FILE/var/log/nginx_monitor.log if ! pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx is down, restarting... $LOG_FILE $NGINX_BIN $LOG_FILE 21 sleep 2 if pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx restarted successfully $LOG_FILE else echo $(date %Y-%m-%d %H:%M:%S) nginx restart failed, please check manually $LOG_FILE fi fi这段代码里用了pgrep -x做精确匹配避免匹配到无关进程启动后再次检查确认启动结果日志做了分类记录。这些都是面试官眼中的“加分细节”。不要担心写得“啰嗦”在运维场景里这种冗余是为了可靠性和可维护性付出的必要成本。3.3 Python在运维笔试中的角色解决Shell搞不定的问题Shell很强大但在文本复杂处理、API调用、多线程、数据解析等场景下Python通常更顺手。2018年的笔试题里Python的比重没有Shell高但仍然会出现而且通常会考察一些实际场景比如读取一个日志文件统计错误码出现的次数输出Top10。这类题目的核心考点是文件操作、字典/集合的使用、字符串处理、排序。思路其实很直接from collections import Counter error_counts Counter() with open(app.log, r, encodingutf-8) as f: for line in f: if ERROR in line: # 假设日志格式为: 2024-01-01 10:00:00 ERROR 500 /api/user parts line.split() if len(parts) 4: error_counts[parts[3]] 1 for code, count in error_counts.most_common(10): print(f{code} {count})这种题说难不难但很考验考场上的代码熟练度。如果平时没有写过类似的脚本很容易在split的索引、字典的更新方式上卡壳。我建议备考时多写几类“脚本练习题”日志统计、文件批量重命名、API接口调用与结果解析、简单的小型监控脚本基本就能覆盖笔试的大多数场景。另外想提醒一点Python笔试中如果允许选择语言优先选自己最熟的。见过不少同学在考场上临时纠结“用Python还是Go”结果时间白白浪费在语法回忆上。运维开发岗位笔试对候选人的要求是“能用代码解决问题”而不是“展示你掌握了多少门语言”与其写得花哨不如写得完整。3.4 题目之外的隐藏考点代码风格与注释习惯脚本题的主观性很强面试官看代码时除了判断功能是否实现还会下意识关注代码风格和注释习惯。这个隐形评分项很多考生会忽略。什么样的代码在运维面试官眼里是“加分项”我的总结是变量命名能表达意图、关键步骤有注释、对异常分支有处理、代码不是一长串堆到底而是有合理的函数或段落划分。再直白一点要让面试官觉得“这个人写的代码拿给同事review不会被骂”而不是“这是临时搓出来应付题目的”。这个习惯培养起来不难平时写脚本时多花两分钟整理一下变成肌肉记忆。到了考场上即使时间紧张写出来的代码也会自然带着那种“工程感”。4. 网络、数据库与Web服务基础运维开发的“硬通货”4.1 网络协议题的常客TCP三次握手与HTTP状态码网络基础在运维开发笔试里从来不会缺席。2018年网易这套题中网络相关的考点主要集中在TCP/IP基础、HTTP协议、DNS解析过程这些方面。TCP三次握手几乎是必考题很多同学能背出SYN、SYNACK、ACK这三次交互但一被追问“为什么需要三次而不是两次”就卡壳了。这里我提供一个好记的解释角度三次握手的核心目标是让通信双方都确认“自己能发数据对方能收数据”。第一次握手客户端确认了自己能发、服务端能收第二次握手服务端确认了自己能发、客户端能收第三次握手客户端告知服务端“我收到了你的确认”至此双方都对收发能力有了确定认知。两次握手无法让服务端确认客户端的接收能力四次挥手则没必要。HTTP状态码也是高频考点不只是背数字而是要理解分类逻辑2xx表示成功3xx表示重定向4xx表示客户端错误5xx表示服务端错误。其中404和502、504的区别在运维场景里尤其重要——404说明资源不存在可能是路由配置问题502通常说明网关或代理拿不到上游服务的有效响应504则是网关在规定时间内没等到上游响应大概率是上游服务超时了。能把这个区别讲清楚比单纯背出状态码列表要有用得多。还有一个容易被忽略的点是DNS。笔试中可能会问“在浏览器输入一个域名到页面展示中间经历了哪些过程”这是一个非常经典的网络综合题。答题时可以从DNS解析开始依次经过TCP连接、HTTP请求发送、服务端处理、响应返回、浏览器渲染这几个阶段。把每个阶段的协议DNS、TCP、HTTP和涉及的网络设备本地DNS缓存、权威DNS服务器、Web服务器说清楚基本就能拿满分。4.2 数据库题目MySQL索引与查询优化数据库在运维开发的工作中通常不是“设计数据库表”这种开发向内容而是更偏向“维护数据库、排查慢查询、备份恢复”。2018年网易笔试题的数据库部分也体现了这个倾向重点放在了MySQL的索引机制、慢查询分析、常见SQL优化手段上。索引相关的经典题目包括什么是聚簇索引什么情况下索引会失效为什么要避免SELECT *这些题目的本质是考察候选人对“索引为什么能加快查询”这一底层原理的理解。B树的结构、回表、覆盖索引这几个概念建议一定要搞清楚因为运维开发工作中排查慢SQL时这些知识会直接派上用场。举一个实际的例子一条SQL查询很慢你通过EXPLAIN看到type是ALL全表扫描rows显示扫描了几十万行。这时候你要能判断出“需要加索引”并且能根据WHERE条件中的字段选择合适的联合索引同时要注意区分字段顺序对索引生效的影响。这种分析能力不是靠背题能练出来的需要平时多接触真实或模拟的慢查询场景。另外MySQL的备份与恢复在笔试中偶尔也会出现比如mysqldump的参数含义、如何恢复到指定时间点基于binlog。如果你有精力建议把这两种操作在本地环境跑一遍会有更深的体感。4.3 Redis缓存场景与常见问题2018年那会儿Redis在互联网公司已经非常普及运维开发笔试题里考Redis也很自然。考点通常集中在Redis支持哪些数据结构、缓存穿透/缓存击穿/缓存雪崩的区别与应对、Redis持久化的两种方式RDB和AOF对比、Redis的过期策略。这里我想重点说一下“缓存三大问题”因为它是笔试和面试都绕不开的高频题。简单解释一下缓存穿透查询一个不存在的数据导致请求直接打到数据库可以布隆过滤器拦截或者缓存空值。缓存击穿某个热点key过期的一瞬间大量请求同时打到数据库可以用互斥锁或者“逻辑过期”的方式解决。缓存雪崩大量key同时过期或者Redis实例挂掉导致数据库压力骤增解决思路包括过期时间加随机值、Redis高可用主从哨兵/集群、限流降级。这三个概念经常被搞混尤其是穿透和击穿。我个人的记忆技巧是穿透说的是“数据根本不存在”击穿说的是“数据存在但刚好过期”一个是“没有”一个是“刚好没了”这样就好区分了。4.4 Nginx反向代理、负载均衡与常见配置Web服务器这块Nginx几乎是运维开发笔试的默认主角2018年网易的题目也不例外。考点包括Nginx的反向代理和正向代理的区别、负载均衡的几种策略轮询、权重、IP hash、location匹配规则、如何配置HTTPS、如何配置静态文件缓存等。关于location匹配规则很多人觉得难记。其实只要抓住优先级就行精确匹配 前缀匹配^~ 正则匹配~/~* 普通前缀匹配。这个优先级顺序是Nginx官网明确规定的笔试时如果考到直接按优先级答题即可同时可以补充说明“匹配顺序是先检查前缀匹配记住最长的匹配项再检查正则正则不看长度只按顺序”。写一个简单的Nginx负载均衡配置示例upstream backend { server 10.0.1.1:8080 weight3; server 10.0.1.2:8080 weight1; server 10.0.1.3:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这个配置里weight3表示权重更高backup表示备用节点。面试时如果能再补充一句“proxy_set_header用于把客户端的真实信息传给后端否则后端拿到的一律是Nginx的IP”会让面试官觉得你理解到位的程度超出预期。5. 监控、日志与CI/CD拉开差距的场景题和开放式问题5.1 监控系统设计题从指标采集到告警通知的完整链路如果说前面的题目是“知识点测试”那么监控系统设计题就是“能力测试”。这类题在2018年网易运维开发笔试中占了不少分值而且通常是主观题需要你画架构、列组件、写思路。我当时看到监控类题目的第一反应是它考察的不只是”知道哪些监控工具“而是“你是否理解一条完整的监控链路”。所谓完整链路至少包含四个环节数据采集、数据存储、告警规则、通知渠道。数据采集常见方案是node_exporterPrometheus或者传统的Zabbix Agent、Telegraf。考察点在于你知道多少种采集方式以及不同方式适用的场景。数据存储时序数据库比如Prometheus自带的TSDB、InfluxDB、VictoriaMetrics。这里如果能提到“时序数据的特点是高写入、低更新、按时间维度聚合”会显得很有深度。告警规则PromQL或Zabbix表达式怎么写比如CPU使用率超过90%持续5分钟就触发告警。通知渠道一般会接入邮件、企业微信、钉钉、短信等需要考虑到告警的“分级”P0/P1/P2和“去重/聚合”避免告警风暴。如果能把这四个环节串起来画一张完整的监控链路图再说明每个环节的工具选型理由这道题基本就稳了。哪怕有些工具没用过也可以从原理上分析它适合什么场景。我在复盘时发现很多同学写监控题只写“我会用Zabbix添加主机”没有全局视角。这其实暴露了对监控理解的局限监控不是“装个工具看图表”而是“建立一套能提前发现问题、快速定位问题、辅助止损的机制”。5.2 日志收集与处理ELK和三板斧日志处理在运维开发工作中是重头戏笔试中也经常出现2018年网易题目的日志相关考点主要集中在日志采集的方式、日志分析的基本思路、常见日志格式的解析。如果问“线上服务有大量日志如何做统一收集和分析”经典的答案是ELKElasticsearch Logstash Kibana或EFKFluentd替换Logstash。要写出这个答案不难但要拿到高分需要补充每个组件的职责和理由Filebeat/Logstash负责采集和清洗Elasticsearch负责存储和检索Kibana负责可视化和搜索。如果能再提一句“Kafka可以作为日志采集的缓冲层应对高峰期大流量”那就更好了。另外日志分析的基础操作也是常见考点。比如用awk从Nginx日志中提取$status字段并统计各状态码的占比用grepsortuniq -c统计某个时间窗口内的请求量变化。这些命令看起来简单但很考验熟练度建议考前多练几道。5.3 CI/CD从手动发布到自动化流水线虽然2018年那会儿DevOps理念在国内还没像现在这么“卷”但笔试题里已经开始出现CI/CD相关的题目了。主要考察点包括持续集成和持续交付的区别、常见CI工具Jenkins、GitLab CI、一条完整的发布流程应该包含哪些环节。最经典的题目是“从代码提交到上线一个完整的CI/CD流程是什么样的”答题时建议分层来写代码提交触发构建构建阶段做单元测试和静态检查然后是构建镜像或打包产物接着进行自动化测试环境部署冒烟测试最后是发布到预发环境和生产环境发布方式可以是蓝绿部署或金丝雀发布。这里有个细节很加分谈到发布策略时如果能区分蓝绿部署和金丝雀发布的适用场景会让面试官觉得你有实战判断力。蓝绿部署适合“全部切换、快速回滚”的场景但需要两套完整环境成本高金丝雀发布适合“先让一部分流量验证新版本”的场景回滚粒度更细但对监控和流量治理要求更高。5.4 开放式场景题如何有条理地回答“假如”类问题除了上述具体考点2018年网易运维开发笔试还有一个让很多人头疼的部分开放式场景题。比如“如果线上服务出现大规模报警你会如何应对”“如何设计一个高可用的架构”这类问题。这种题没有标准答案但面试官会从你的回答中判断“有没有处理过线上故障的经验”和“思考问题是否系统化”。我建议的回答框架是发现问题通过监控和告警感知异常→ 定位问题查看日志、链路追踪、系统指标→ 止血恢复切流量、回滚、扩容→ 根因分析深挖代码、配置、依赖→ 后续改进补充监控、优化代码、完善预案。把这种处理流程写出来比一上来就说“我会把服务重启一下”要专业得多。尤其是在“止血”环节要强调“先恢复服务再追究根因”的原则——生产环境的第一优先级永远是把损失降到最低而不是当场写一份完美的事故报告。6. 备考路线从2018年真题到一套可复用的运维开发知识体系6.1 分阶段复习路线基础、专项、实战如果你正在准备运维开发岗位的笔试或面试我不建议直接拿着一套真题反复刷而是建议按“基础-专项-实战”三个阶段递进式复习。第一阶段是基础夯实期。把Linux常用命令、Shell脚本基础、Python基础语法、网络协议基础TCP/IP、HTTP、DNS、MySQL和Redis基础过一遍。这个阶段不需要做太难的题重点是“看到题目能想到对应的知识点”。第二阶段是专项突破期。根据目标公司的岗位JD和往年笔试风格挑出最常考的几个方向重点加深。比如网易这套题明显侧重Linux和脚本那就把Shell和Python的练习题多写一些如果目标岗位侧重容器化那就要在Docker和K8s上多下功夫。第三阶段是实战模拟期。严格按照笔试的时间和题型分布做模拟练习练完对照答案复盘找出“哪些是知识盲区哪些是表达不到位”。这个阶段也是培养“手感”的关键期尤其是编程题考场上的时间分配和代码书写速度都需要提前适应。6.2 推荐的学习资源与日常练习方式对于运维开发的准备书籍方面有几本比较经典的《鸟哥的Linux私房菜》用来打Linux基础《Shell脚本学习指南》用来补脚本短板《Python编程从入门到实践》适合快速上手Python《高性能MySQL》作为数据库进阶参考。这些书不用从头到尾啃按需查阅即可。除了看书我更推荐“带着问题去学习”。比如你看到一条线上告警“磁盘使用率超过85%”就去查一下df和du的区别了解一下inode的概念学一下logrotate怎么配置日志轮转。这种从具体问题出发的学习方式知识和场景是绑定的记忆会更牢靠考场上提取起来也更顺畅。再有就是坚持做技术笔记。不用写得多精美关键是把自己的理解写出来。写笔记的过程其实就是一种“输出式学习”比单纯看十篇文章有效得多。我之前带过的备考同学里凡是认真写笔记、做故障复盘的笔试成绩普遍比只刷题的要好。6.3 笔试时的答题顺序与时间管理技巧最后聊点实战技巧。运维开发笔试的题量通常不小时间分配不合理很容易导致后面的大题来不及写。我的建议是先快速浏览全卷标注出题目的难易度优先做选择题和填空题这类题“拿到就是拿到”不存在后续补分的机会然后做简答题尽量答得结构化分点描述最后留出充足时间给脚本题和场景题。在脚本题上即使时间不足也要把整体思路写出来哪怕只写关键的几行伪代码也比空着强。面试官看的主观题通常是“按点给分”你的思路如果清晰就算代码有小bug也能拿到大部分分数。还有一个建议不要在一道选择题上纠结超过2分钟。笔试题量大个别题目卡住很正常先跳过做完后面的再回来纠结。很多同学在考场上因为一道争议题浪费了十几分钟导致最后的大题没写完整这是非常可惜的。运维开发笔试真正拉分的永远是大题和编程题不要在客观题上过度恋战。7. 常见问题与避坑经验考完复盘时才明白的事7.1 复习中容易踩的四个“隐形坑”我在和很多备考同学交流后总结了几个比较普遍的复习误区这里一并说一下。第一个坑是“重理论轻实操”。很多同学复习Linux和脚本时只看不练觉得自己都懂真到考场上写命令时才发现各种细节模糊。运维开发是一个动手属性极强的岗位所有知识都要以“能写出来”为最终检验标准。第二个坑是“只刷题不总结”。刷题本身不是目的通过刷题发现自己的薄弱点并精准补强才是目的。建议每做完一套真题都建一个错误记录文档把错题对应的知识点、错误原因、正确思路都写下来考前集中过一遍。第三个坑是“忽略业务场景的理解”。笔试中很多题目不是单纯考技术点而是考你在具体业务场景下的判断力。比如监控告警阈值怎么定、缓存和数据库的一致性怎么保证、发布时怎么控制风险。这些能力需要在真实项目或模拟项目中积累纯看书学不到。第四个坑是“心态焦虑导致时间浪费”。运维开发的知识体系确实比较庞杂想全部学完再上考场几乎不可能。正确的方式是抓住核心模块Linux、网络、数据库、脚本、监控把每个模块的“最小必要知识集”掌握扎实再根据精力适当扩展不要试图面面俱到。7.2 这些问题面试官一眼就能看穿笔试环节之后能进入面试的话面试官通常会拿着你的笔试卷子发问。这时候如果你的答案是临时背的很容易露馅。比如卷子上写了“用Zabbix做监控”面试官可能追问“Zabbix的主动模式和被动模式有什么区别”“你实际配置过哪些监控项”之类的问题没做过就是答不上来。所以我有一个很郑重的建议简历上写的、笔试卷上写的每一个技术点都要保证自己“真的做过”或者“至少完整实践过一两次”。技术面试最忌“知道名词但没上过手”这种状态比“承认不会但愿意学”还要危险。7.3 从笔试到offer最后的临门一脚笔试只是第一关后面的面试通常还会包含一轮技术面、一轮综合面有时还会有HR面。但我发现一个规律笔试成绩好的同学面试时底气明显更足因为笔试本身也是对自己知识体系的一次全面检验。如果你在笔试中暴露出了一些薄弱点不要灰心反而要庆幸——这比入职后再暴露要强得多。把这些问题整理成清单逐一攻克本身就是一套很高效的备考方法论。最后分享一个个人体会运维开发这个岗位考察的从来不只是知识点本身而是“面对不确定性时你能否系统化地分析问题、设计方案、推进落地”。2018年网易的这套笔试题表面上是考技术实际上是在筛选具备这种工程思维的人。你把这套题吃透了收获的不仅仅是一份笔试答案更是一套应对运维开发各类挑战的底层框架。嗯今天的复盘就到这里。如果正在准备运维开发笔试希望你不仅能刷题更能把刷题当作一次知识体系的升级。祝顺利。
网易运维开发笔试真题复盘：Linux、脚本、监控与CI/CD考点全解析
网易2018实习生招聘笔试题-运维开发实习生这个话题放在今天看依然有不少值得嚼的东西。当年这批题目流传出来后很多准备面试的朋友把它当成“网易运维开发岗到底考什么”的风向标也有人把它当作一套系统的运维开发自测题来刷。我接触过不少参加过那场笔试的同学也反复看过网上流传的版本客观说一句这套题不偏不怪但覆盖面相当广从Linux基础到Shell/Python脚本从网络协议到数据库、Web服务再到监控和CI/CD几乎把运维开发日常要碰的东西都扫了一遍。这篇博文就围绕这套题目做一次完整复盘。我不会只给“答案”而是把每类题背后的考察意图、答题思路、常见失分点以及现在的备考建议都讲清楚。无论你是准备运维开发岗位的应届生还是想系统梳理运维开发知识体系的在职新人这篇文章都可以当作一份比较实在的参考。1. 运维开发笔试到底在考什么2018年网易真题的整体结构复盘1.1 从真题看网易对运维开发实习生的能力预期先聊一个很多人没想明白的问题运维开发和传统运维、纯开发之间的区别到底是什么。2018年网易这套笔试题其实已经给了答案——它既不考纯Linux命令背诵也不考算法题而是把重心放在“用代码和工程化手段解决运维问题”这件事上。从题目结构来看大致可以分成这么几块Linux操作系统与基础命令、Shell和Python脚本编写、网络协议基础、数据库和缓存MySQL、Redis、Web服务器与反向代理Nginx、监控与日志、以及一两道比较开放的场景设计题。这个结构在当年算是很有代表性的放到现在依然是运维开发岗位笔试的“标准模板”。我当时拿到这套题的第一感觉是网易对实习生的定位不是“来了就能独立负责xx系统”的熟手而是“基础扎实、有工程思维、能快速上手”的苗子。所以题目难度整体不算高但非常考验知识面的广度。举个例子题目里会出现“查看系统负载的命令有哪些”“如何查看端口占用”“如何统计日志中某个关键词出现次数”这类基础题但也会出现“写一个脚本监控Nginx进程状态异常时自动拉起”这种需要综合能力的题。前者考的是你有没有基本操作功底后者考的是你能不能把命令、脚本、定时任务、异常处理串成一条完整的自动化链路。1.2 整套题的难度曲线与出题逻辑仔细看这套题难度并不是均匀分布的而是有明显的梯度。前面是单选题和多选题覆盖Linux、网络、数据库的基础知识点中间是简答题需要解释概念或者写出关键命令后面是编程题和场景题需要完整地写出脚本或给出设计方案。这种出题逻辑其实暗合了招聘筛选的漏斗模型先用客观题快速过滤掉基础不牢的人再用主观题筛选出有实战思维的人。对考生来说最大的坑往往不是后面的编程题没写出来而是前面的选择题错得太多——毕竟选择题对就是对错就是错没有“部分得分”的说法。我记得当时有同学复盘时说错得最多的居然是Linux基础题比如crontab的格式、df和du的区别这种。原因是平时用Linux更多是“点鼠标式”操作或者复制粘贴命令很少真正理解命令的参数和原理。面试官想看到的显然不是这种“用过但不懂”的状态。1.3 2018版真题对现在备考的参考价值可能有人会说2018年的题都过去这么多年了还有参考价值吗我的看法是有价值而且要重视。运维开发这个岗位的核心知识栈这几年并没有发生颠覆性变化Linux、网络、数据库、脚本、监控、CI/CD依然是日常工作的主旋律。变的只是工具链的丰富程度比如容器化、K8s、云原生但底层的“内功”没有变。所以这套题完全可以作为一份“运维开发知识体检清单”来用。你不需要纠结“这是2018年的题是不是过时了”而是应该问自己这些知识点我现在是不是真的掌握了如果让我现在去做这套题我能拿多少分另外再补充一点我见过很多人在准备运维开发笔试时陷入一个误区疯狂刷算法题。不是说算法不重要而是运维开发岗位的笔试题通常不会出太深的算法更看重的是你对系统、网络、业务的综合理解能力。把时间花在Linux排查、脚本编写、数据库原理这些更贴合岗位需求的点上性价比要高得多。2. Linux与系统基础题看似送分实则最容易翻车2.1 命令类题目的高频考点与易错点Linux基础在2018年网易运维开发笔试题里占了相当大的比重而且考得非常细。列举几个我在复盘时看到的典型考点查看系统负载的命令uptime、top、w以及cat /proc/loadavg。查看端口占用netstat -tlnp、ss -tlnp需要注意ss是netstat的替代方案性能更好。查看磁盘空间df -h和du -sh很多人搞不清这两个命令的区别df看的是文件系统级别的使用情况du看的是目录/文件实际占用的磁盘块大小。日志统计grep、awk、sort、uniq -c的组合使用比如统计Nginx日志中IP访问次数Top10。定时任务crontab -e的格式五个时间字段分别是分、时、日、月、周这个格式几乎年年考。这些命令看着基础但真正能在笔试中准确写出来的人并不多。原因在于很多人平时用Linux都是“查到什么用什么”没有刻意记忆命令的标准输出格式和参数含义。比如netstat -tlnp中每个参数分别代表什么t: TCP, l: listening, n: 数字显示, p: 进程信息如果只是背了命令而不知道参数含义换一个需求就抓瞎了。我个人的建议是复习Linux命令时不要只背命令本身要把“命令-参数-输出-使用场景”串成一条线。比如top命令你不仅要会敲top还要知道top输出里的load average三个值分别代表1分钟、5分钟、15分钟的平均负载以及如何判断系统是否过载一般经验值是超过CPU核数的70%-80%需要关注。2.2 系统概念题的答题框架从“是什么”到“为什么”除了命令题Linux部分还会考一些系统概念题比如进程和线程的区别、用户态和内核态、软链接和硬链接、僵尸进程和孤儿进程等。这些概念题最大的特点是看起来都背过但用文字准确表达出来并不容易。以“软链接和硬链接”为例网上有无数篇教程但很多人一上考场就写不清楚。我建议用“文件系统的inode机制”来组织答案硬链接本质上是多个目录项指向同一个inode删除其中一个链接不影响其他链接访问数据软链接符号链接则是一个独立的文件里面存储的是目标文件的路径如果目标文件被删除软链接就失效了。这种答法的好处是它体现的不是“背过定义”而是“理解原理”。面试官看主观题时最在意的就是你有没有把底层机制讲清楚而不是堆了多少专业名词。还有一类常考题是系统排查思路比如“服务器负载突然升高如何排查”。这种题没有统一答案但有一个比较标准的排查路径先用top或htop看CPU和内存占用靠前的进程再用vmstat看系统整体的运行队列和上下文切换情况接着用iostat看磁盘I/O是否瓶颈最后结合dmesg看有没有OOM或硬件报错。把这条路径写清楚比写一堆零散的命令要有说服力得多。2.3 结合真题场景如何用“监工思维”解Linux题我在复盘Linux部分时发现网易的题目特别喜欢把命令考法和“监控/排查”场景结合起来。比如它不会直接问free -m的输出怎么解读而是问“系统内存不足时如何定位是哪个进程占用最多内存”这就把命令考察升级成了场景分析。这种出题方式对考生提出的要求是不仅要懂单个命令还要具备“监工思维”——拿到一台出问题的机器我能用什么命令、按什么顺序、多长时间内定位到问题根因。这其实是运维开发日常工作的核心能力。对备考者来说与其把命令列表背得滚瓜烂熟不如在本地虚拟机或云服务器上多做几次故障演练。比如故意把一个服务停掉、把磁盘写满、把CPU占满然后现察自己的处理过程看看能不能用最快的速度定位并恢复。这种训练对笔试和面试都极有帮助因为它把你的知识从“记忆层面”拉到了“应用层面”。3. Shell与Python运维开发的“手”和“脑”3.1 脚本题的考察权重与评分逻辑2018年网易运维开发笔试题里脚本题属于压轴级别的存在。这类题分值高、区分度大也是最容易拉开差距的部分。从题目风格来看Shell和Python都有涉及Shell更偏向系统管理和文本处理Python则偏向逻辑处理和简单的小工具实现。我记得有一道比较有代表性的题是写一个脚本每5分钟检查一次Nginx进程是否存在如果不存在就尝试启动并记录日志。这题看起来简单但实际上考察了好几个点进程检查的方式pgrep、ps -ef | grep、pidof、条件判断语法、启动命令的调用、日志的记录方式、定时任务的配置crontab或脚本内循环等。很多人在这种题上失分不是因为不会写而是因为细节不完整。比如只写了ps -ef | grep nginx却没用grep -v grep过滤掉grep自身进程比如判断语句里没加 logfile 21导致日志信息丢失比如没有考虑到脚本需要设置PATH环境变量。这些细节恰恰是面试官最看重的部分因为运维开发的脚本是要在生产环境里跑的一个细节失误就可能导致脚本失效。3.2 Shell脚本的“高分写法”从能跑到跑得稳在笔试中写Shell脚本我强烈建议遵循一个原则即使没有要求也要把脚本写得像一个可以上线使用的生产脚本而不是一个演示用的玩具。具体来说可以注意这么几点脚本开头加上#!/bin/bash和必要的注释。使用变量时加上set -u防止未定义变量报错或至少声明变量时注意命名。检查关键命令是否存在比如command -v nginx。启动服务后要确认是否真的启动成功而不是盲目相信命令执行完就没事了。日志要带时间戳方便回溯。如果脚本可能被重复执行要考虑幂等性比如先判断进程已存在就直接退出。举个例子一个简化的Nginx守护脚本可以写成这样#!/bin/bash # desc: check nginx process and restart if down NGINX_BIN/usr/local/nginx/sbin/nginx LOG_FILE/var/log/nginx_monitor.log if ! pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx is down, restarting... $LOG_FILE $NGINX_BIN $LOG_FILE 21 sleep 2 if pgrep -x nginx /dev/null 21; then echo $(date %Y-%m-%d %H:%M:%S) nginx restarted successfully $LOG_FILE else echo $(date %Y-%m-%d %H:%M:%S) nginx restart failed, please check manually $LOG_FILE fi fi这段代码里用了pgrep -x做精确匹配避免匹配到无关进程启动后再次检查确认启动结果日志做了分类记录。这些都是面试官眼中的“加分细节”。不要担心写得“啰嗦”在运维场景里这种冗余是为了可靠性和可维护性付出的必要成本。3.3 Python在运维笔试中的角色解决Shell搞不定的问题Shell很强大但在文本复杂处理、API调用、多线程、数据解析等场景下Python通常更顺手。2018年的笔试题里Python的比重没有Shell高但仍然会出现而且通常会考察一些实际场景比如读取一个日志文件统计错误码出现的次数输出Top10。这类题目的核心考点是文件操作、字典/集合的使用、字符串处理、排序。思路其实很直接from collections import Counter error_counts Counter() with open(app.log, r, encodingutf-8) as f: for line in f: if ERROR in line: # 假设日志格式为: 2024-01-01 10:00:00 ERROR 500 /api/user parts line.split() if len(parts) 4: error_counts[parts[3]] 1 for code, count in error_counts.most_common(10): print(f{code} {count})这种题说难不难但很考验考场上的代码熟练度。如果平时没有写过类似的脚本很容易在split的索引、字典的更新方式上卡壳。我建议备考时多写几类“脚本练习题”日志统计、文件批量重命名、API接口调用与结果解析、简单的小型监控脚本基本就能覆盖笔试的大多数场景。另外想提醒一点Python笔试中如果允许选择语言优先选自己最熟的。见过不少同学在考场上临时纠结“用Python还是Go”结果时间白白浪费在语法回忆上。运维开发岗位笔试对候选人的要求是“能用代码解决问题”而不是“展示你掌握了多少门语言”与其写得花哨不如写得完整。3.4 题目之外的隐藏考点代码风格与注释习惯脚本题的主观性很强面试官看代码时除了判断功能是否实现还会下意识关注代码风格和注释习惯。这个隐形评分项很多考生会忽略。什么样的代码在运维面试官眼里是“加分项”我的总结是变量命名能表达意图、关键步骤有注释、对异常分支有处理、代码不是一长串堆到底而是有合理的函数或段落划分。再直白一点要让面试官觉得“这个人写的代码拿给同事review不会被骂”而不是“这是临时搓出来应付题目的”。这个习惯培养起来不难平时写脚本时多花两分钟整理一下变成肌肉记忆。到了考场上即使时间紧张写出来的代码也会自然带着那种“工程感”。4. 网络、数据库与Web服务基础运维开发的“硬通货”4.1 网络协议题的常客TCP三次握手与HTTP状态码网络基础在运维开发笔试里从来不会缺席。2018年网易这套题中网络相关的考点主要集中在TCP/IP基础、HTTP协议、DNS解析过程这些方面。TCP三次握手几乎是必考题很多同学能背出SYN、SYNACK、ACK这三次交互但一被追问“为什么需要三次而不是两次”就卡壳了。这里我提供一个好记的解释角度三次握手的核心目标是让通信双方都确认“自己能发数据对方能收数据”。第一次握手客户端确认了自己能发、服务端能收第二次握手服务端确认了自己能发、客户端能收第三次握手客户端告知服务端“我收到了你的确认”至此双方都对收发能力有了确定认知。两次握手无法让服务端确认客户端的接收能力四次挥手则没必要。HTTP状态码也是高频考点不只是背数字而是要理解分类逻辑2xx表示成功3xx表示重定向4xx表示客户端错误5xx表示服务端错误。其中404和502、504的区别在运维场景里尤其重要——404说明资源不存在可能是路由配置问题502通常说明网关或代理拿不到上游服务的有效响应504则是网关在规定时间内没等到上游响应大概率是上游服务超时了。能把这个区别讲清楚比单纯背出状态码列表要有用得多。还有一个容易被忽略的点是DNS。笔试中可能会问“在浏览器输入一个域名到页面展示中间经历了哪些过程”这是一个非常经典的网络综合题。答题时可以从DNS解析开始依次经过TCP连接、HTTP请求发送、服务端处理、响应返回、浏览器渲染这几个阶段。把每个阶段的协议DNS、TCP、HTTP和涉及的网络设备本地DNS缓存、权威DNS服务器、Web服务器说清楚基本就能拿满分。4.2 数据库题目MySQL索引与查询优化数据库在运维开发的工作中通常不是“设计数据库表”这种开发向内容而是更偏向“维护数据库、排查慢查询、备份恢复”。2018年网易笔试题的数据库部分也体现了这个倾向重点放在了MySQL的索引机制、慢查询分析、常见SQL优化手段上。索引相关的经典题目包括什么是聚簇索引什么情况下索引会失效为什么要避免SELECT *这些题目的本质是考察候选人对“索引为什么能加快查询”这一底层原理的理解。B树的结构、回表、覆盖索引这几个概念建议一定要搞清楚因为运维开发工作中排查慢SQL时这些知识会直接派上用场。举一个实际的例子一条SQL查询很慢你通过EXPLAIN看到type是ALL全表扫描rows显示扫描了几十万行。这时候你要能判断出“需要加索引”并且能根据WHERE条件中的字段选择合适的联合索引同时要注意区分字段顺序对索引生效的影响。这种分析能力不是靠背题能练出来的需要平时多接触真实或模拟的慢查询场景。另外MySQL的备份与恢复在笔试中偶尔也会出现比如mysqldump的参数含义、如何恢复到指定时间点基于binlog。如果你有精力建议把这两种操作在本地环境跑一遍会有更深的体感。4.3 Redis缓存场景与常见问题2018年那会儿Redis在互联网公司已经非常普及运维开发笔试题里考Redis也很自然。考点通常集中在Redis支持哪些数据结构、缓存穿透/缓存击穿/缓存雪崩的区别与应对、Redis持久化的两种方式RDB和AOF对比、Redis的过期策略。这里我想重点说一下“缓存三大问题”因为它是笔试和面试都绕不开的高频题。简单解释一下缓存穿透查询一个不存在的数据导致请求直接打到数据库可以布隆过滤器拦截或者缓存空值。缓存击穿某个热点key过期的一瞬间大量请求同时打到数据库可以用互斥锁或者“逻辑过期”的方式解决。缓存雪崩大量key同时过期或者Redis实例挂掉导致数据库压力骤增解决思路包括过期时间加随机值、Redis高可用主从哨兵/集群、限流降级。这三个概念经常被搞混尤其是穿透和击穿。我个人的记忆技巧是穿透说的是“数据根本不存在”击穿说的是“数据存在但刚好过期”一个是“没有”一个是“刚好没了”这样就好区分了。4.4 Nginx反向代理、负载均衡与常见配置Web服务器这块Nginx几乎是运维开发笔试的默认主角2018年网易的题目也不例外。考点包括Nginx的反向代理和正向代理的区别、负载均衡的几种策略轮询、权重、IP hash、location匹配规则、如何配置HTTPS、如何配置静态文件缓存等。关于location匹配规则很多人觉得难记。其实只要抓住优先级就行精确匹配 前缀匹配^~ 正则匹配~/~* 普通前缀匹配。这个优先级顺序是Nginx官网明确规定的笔试时如果考到直接按优先级答题即可同时可以补充说明“匹配顺序是先检查前缀匹配记住最长的匹配项再检查正则正则不看长度只按顺序”。写一个简单的Nginx负载均衡配置示例upstream backend { server 10.0.1.1:8080 weight3; server 10.0.1.2:8080 weight1; server 10.0.1.3:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这个配置里weight3表示权重更高backup表示备用节点。面试时如果能再补充一句“proxy_set_header用于把客户端的真实信息传给后端否则后端拿到的一律是Nginx的IP”会让面试官觉得你理解到位的程度超出预期。5. 监控、日志与CI/CD拉开差距的场景题和开放式问题5.1 监控系统设计题从指标采集到告警通知的完整链路如果说前面的题目是“知识点测试”那么监控系统设计题就是“能力测试”。这类题在2018年网易运维开发笔试中占了不少分值而且通常是主观题需要你画架构、列组件、写思路。我当时看到监控类题目的第一反应是它考察的不只是”知道哪些监控工具“而是“你是否理解一条完整的监控链路”。所谓完整链路至少包含四个环节数据采集、数据存储、告警规则、通知渠道。数据采集常见方案是node_exporterPrometheus或者传统的Zabbix Agent、Telegraf。考察点在于你知道多少种采集方式以及不同方式适用的场景。数据存储时序数据库比如Prometheus自带的TSDB、InfluxDB、VictoriaMetrics。这里如果能提到“时序数据的特点是高写入、低更新、按时间维度聚合”会显得很有深度。告警规则PromQL或Zabbix表达式怎么写比如CPU使用率超过90%持续5分钟就触发告警。通知渠道一般会接入邮件、企业微信、钉钉、短信等需要考虑到告警的“分级”P0/P1/P2和“去重/聚合”避免告警风暴。如果能把这四个环节串起来画一张完整的监控链路图再说明每个环节的工具选型理由这道题基本就稳了。哪怕有些工具没用过也可以从原理上分析它适合什么场景。我在复盘时发现很多同学写监控题只写“我会用Zabbix添加主机”没有全局视角。这其实暴露了对监控理解的局限监控不是“装个工具看图表”而是“建立一套能提前发现问题、快速定位问题、辅助止损的机制”。5.2 日志收集与处理ELK和三板斧日志处理在运维开发工作中是重头戏笔试中也经常出现2018年网易题目的日志相关考点主要集中在日志采集的方式、日志分析的基本思路、常见日志格式的解析。如果问“线上服务有大量日志如何做统一收集和分析”经典的答案是ELKElasticsearch Logstash Kibana或EFKFluentd替换Logstash。要写出这个答案不难但要拿到高分需要补充每个组件的职责和理由Filebeat/Logstash负责采集和清洗Elasticsearch负责存储和检索Kibana负责可视化和搜索。如果能再提一句“Kafka可以作为日志采集的缓冲层应对高峰期大流量”那就更好了。另外日志分析的基础操作也是常见考点。比如用awk从Nginx日志中提取$status字段并统计各状态码的占比用grepsortuniq -c统计某个时间窗口内的请求量变化。这些命令看起来简单但很考验熟练度建议考前多练几道。5.3 CI/CD从手动发布到自动化流水线虽然2018年那会儿DevOps理念在国内还没像现在这么“卷”但笔试题里已经开始出现CI/CD相关的题目了。主要考察点包括持续集成和持续交付的区别、常见CI工具Jenkins、GitLab CI、一条完整的发布流程应该包含哪些环节。最经典的题目是“从代码提交到上线一个完整的CI/CD流程是什么样的”答题时建议分层来写代码提交触发构建构建阶段做单元测试和静态检查然后是构建镜像或打包产物接着进行自动化测试环境部署冒烟测试最后是发布到预发环境和生产环境发布方式可以是蓝绿部署或金丝雀发布。这里有个细节很加分谈到发布策略时如果能区分蓝绿部署和金丝雀发布的适用场景会让面试官觉得你有实战判断力。蓝绿部署适合“全部切换、快速回滚”的场景但需要两套完整环境成本高金丝雀发布适合“先让一部分流量验证新版本”的场景回滚粒度更细但对监控和流量治理要求更高。5.4 开放式场景题如何有条理地回答“假如”类问题除了上述具体考点2018年网易运维开发笔试还有一个让很多人头疼的部分开放式场景题。比如“如果线上服务出现大规模报警你会如何应对”“如何设计一个高可用的架构”这类问题。这种题没有标准答案但面试官会从你的回答中判断“有没有处理过线上故障的经验”和“思考问题是否系统化”。我建议的回答框架是发现问题通过监控和告警感知异常→ 定位问题查看日志、链路追踪、系统指标→ 止血恢复切流量、回滚、扩容→ 根因分析深挖代码、配置、依赖→ 后续改进补充监控、优化代码、完善预案。把这种处理流程写出来比一上来就说“我会把服务重启一下”要专业得多。尤其是在“止血”环节要强调“先恢复服务再追究根因”的原则——生产环境的第一优先级永远是把损失降到最低而不是当场写一份完美的事故报告。6. 备考路线从2018年真题到一套可复用的运维开发知识体系6.1 分阶段复习路线基础、专项、实战如果你正在准备运维开发岗位的笔试或面试我不建议直接拿着一套真题反复刷而是建议按“基础-专项-实战”三个阶段递进式复习。第一阶段是基础夯实期。把Linux常用命令、Shell脚本基础、Python基础语法、网络协议基础TCP/IP、HTTP、DNS、MySQL和Redis基础过一遍。这个阶段不需要做太难的题重点是“看到题目能想到对应的知识点”。第二阶段是专项突破期。根据目标公司的岗位JD和往年笔试风格挑出最常考的几个方向重点加深。比如网易这套题明显侧重Linux和脚本那就把Shell和Python的练习题多写一些如果目标岗位侧重容器化那就要在Docker和K8s上多下功夫。第三阶段是实战模拟期。严格按照笔试的时间和题型分布做模拟练习练完对照答案复盘找出“哪些是知识盲区哪些是表达不到位”。这个阶段也是培养“手感”的关键期尤其是编程题考场上的时间分配和代码书写速度都需要提前适应。6.2 推荐的学习资源与日常练习方式对于运维开发的准备书籍方面有几本比较经典的《鸟哥的Linux私房菜》用来打Linux基础《Shell脚本学习指南》用来补脚本短板《Python编程从入门到实践》适合快速上手Python《高性能MySQL》作为数据库进阶参考。这些书不用从头到尾啃按需查阅即可。除了看书我更推荐“带着问题去学习”。比如你看到一条线上告警“磁盘使用率超过85%”就去查一下df和du的区别了解一下inode的概念学一下logrotate怎么配置日志轮转。这种从具体问题出发的学习方式知识和场景是绑定的记忆会更牢靠考场上提取起来也更顺畅。再有就是坚持做技术笔记。不用写得多精美关键是把自己的理解写出来。写笔记的过程其实就是一种“输出式学习”比单纯看十篇文章有效得多。我之前带过的备考同学里凡是认真写笔记、做故障复盘的笔试成绩普遍比只刷题的要好。6.3 笔试时的答题顺序与时间管理技巧最后聊点实战技巧。运维开发笔试的题量通常不小时间分配不合理很容易导致后面的大题来不及写。我的建议是先快速浏览全卷标注出题目的难易度优先做选择题和填空题这类题“拿到就是拿到”不存在后续补分的机会然后做简答题尽量答得结构化分点描述最后留出充足时间给脚本题和场景题。在脚本题上即使时间不足也要把整体思路写出来哪怕只写关键的几行伪代码也比空着强。面试官看的主观题通常是“按点给分”你的思路如果清晰就算代码有小bug也能拿到大部分分数。还有一个建议不要在一道选择题上纠结超过2分钟。笔试题量大个别题目卡住很正常先跳过做完后面的再回来纠结。很多同学在考场上因为一道争议题浪费了十几分钟导致最后的大题没写完整这是非常可惜的。运维开发笔试真正拉分的永远是大题和编程题不要在客观题上过度恋战。7. 常见问题与避坑经验考完复盘时才明白的事7.1 复习中容易踩的四个“隐形坑”我在和很多备考同学交流后总结了几个比较普遍的复习误区这里一并说一下。第一个坑是“重理论轻实操”。很多同学复习Linux和脚本时只看不练觉得自己都懂真到考场上写命令时才发现各种细节模糊。运维开发是一个动手属性极强的岗位所有知识都要以“能写出来”为最终检验标准。第二个坑是“只刷题不总结”。刷题本身不是目的通过刷题发现自己的薄弱点并精准补强才是目的。建议每做完一套真题都建一个错误记录文档把错题对应的知识点、错误原因、正确思路都写下来考前集中过一遍。第三个坑是“忽略业务场景的理解”。笔试中很多题目不是单纯考技术点而是考你在具体业务场景下的判断力。比如监控告警阈值怎么定、缓存和数据库的一致性怎么保证、发布时怎么控制风险。这些能力需要在真实项目或模拟项目中积累纯看书学不到。第四个坑是“心态焦虑导致时间浪费”。运维开发的知识体系确实比较庞杂想全部学完再上考场几乎不可能。正确的方式是抓住核心模块Linux、网络、数据库、脚本、监控把每个模块的“最小必要知识集”掌握扎实再根据精力适当扩展不要试图面面俱到。7.2 这些问题面试官一眼就能看穿笔试环节之后能进入面试的话面试官通常会拿着你的笔试卷子发问。这时候如果你的答案是临时背的很容易露馅。比如卷子上写了“用Zabbix做监控”面试官可能追问“Zabbix的主动模式和被动模式有什么区别”“你实际配置过哪些监控项”之类的问题没做过就是答不上来。所以我有一个很郑重的建议简历上写的、笔试卷上写的每一个技术点都要保证自己“真的做过”或者“至少完整实践过一两次”。技术面试最忌“知道名词但没上过手”这种状态比“承认不会但愿意学”还要危险。7.3 从笔试到offer最后的临门一脚笔试只是第一关后面的面试通常还会包含一轮技术面、一轮综合面有时还会有HR面。但我发现一个规律笔试成绩好的同学面试时底气明显更足因为笔试本身也是对自己知识体系的一次全面检验。如果你在笔试中暴露出了一些薄弱点不要灰心反而要庆幸——这比入职后再暴露要强得多。把这些问题整理成清单逐一攻克本身就是一套很高效的备考方法论。最后分享一个个人体会运维开发这个岗位考察的从来不只是知识点本身而是“面对不确定性时你能否系统化地分析问题、设计方案、推进落地”。2018年网易的这套笔试题表面上是考技术实际上是在筛选具备这种工程思维的人。你把这套题吃透了收获的不仅仅是一份笔试答案更是一套应对运维开发各类挑战的底层框架。嗯今天的复盘就到这里。如果正在准备运维开发笔试希望你不仅能刷题更能把刷题当作一次知识体系的升级。祝顺利。