1. 项目概述前阵子有学弟找我聊网易2023校招提前批说投了运维开发工程师有道结果笔试直接给他整不会了。我听完他的反馈又翻了翻手头留存的一些面经和笔试题回忆版感觉这个岗位的笔试确实很有代表性它不只是考Linux命令和八股文而是真正在筛选“有工程素养、能写代码、懂业务系统稳定性”的人。这篇文章就把运维开发这个岗位笔试背后的逻辑、备考思路、实操要点全部拆开讲透哪怕你现在刚投简历看完也能知道该往哪个方向使劲。运维开发工程师这个岗位在不同公司叫法不一样有的叫SRE站点可靠性工程师有的叫DevOps工程师还有的叫“平台工程师”。但在网易这种体量的互联网公司里运维开发绝对不是“跑机房、插网线、重启服务器”那种传统运维它本质上是“用软件开发的手段解决运维场景的问题”。这个岗位笔试考察的底层能力包括Linux系统与网络基础、脚本和编程能力、云计算和容器相关知识的掌握程度以及面对线上故障时能不能快速定位、给出合理的解决方案。这篇文章适合三类人看正在准备2023届及以后校招的应届生、工作一两年想从传统运维转向运维开发的同行以及单纯好奇互联网大厂笔试怎么筛人的同学。看完你至少能摸清网易这道运维开发笔试题的出题逻辑更关键的是你可以把同类的知识框架迁移到其他任何一家公司的运维开发笔面试中。2. 岗位需求与出题逻辑拆解2.1 为什么运维开发岗位笔试要“考代码”一个很常见的误解是运维岗笔试应该多考命令、多考操作少考编程。但实际企业笔试里运维开发的技术考察会明显向代码倾斜。原因很简单到了2023年这个时间节点业务系统基本都跑在云上很多机器已经不再是“宠物”而是“牲畜”——挂了就换重点不在单机维护而在自动化管理一大批机器。而自动化靠什么靠脚本靠平台靠代码。所以笔试考代码不是为了难为你是为了筛出那些只会点鼠标、背命令的人。网易有道这条业务线本身做在线教育产品承载着大量直播、题库、点播等业务场景对服务可用性和稳定性要求极高。一旦上课高峰期出现大面积服务抖动几十万人受影响问题必须由运维开发工程师通过监控、告警、自动扩容、兜底方案等手段提前兜住。这就要求你不是“能跑通脚本就行”而是要写出健壮、可维护、能协同的代码——笔试里出现编程题和代码改错题就是在这个前提下设计的。另外也建议大家不要把“运维开发”和“后端开发”对立起来。在这个岗位的日常工作中你既要做 CI/CD 流水线设计也要写告警聚合平台的后端接口偶尔还要调试一下数据同步 Job 的代码。所以真正高效的做法是把运维开发当成“懂业务的稳定性工程师”代码能力不能拖后腿。2.2 不同题型的考察目标一场笔试往往包含多种题型。从实际回忆的信息看网易这个岗位的笔试题型通常包括计算机基础客观题、编程题和场景设计题。客观题覆盖操作系统、网络、数据库、Linux常见命令编程题一般有两道左右难度贴近校招常规水平比如字符串处理、简单算法、手写脚本实现某个小工具场景设计题则往往给一个具体的故障现象或者系统架构让你写出排查思路、解决方案。各题型的考察目标差异很大。客观题考的是“基线是否牢固”比如你知不知道 TCP 三次握手的本质、进程和线程的区别、写时复制是什么这些东西不是靠背而是靠是否真正用过。编程题考的是“能不能用代码表达思路”常见典型题目是“写一个监控脚本检查某个进程是否存活异常时告警并自动拉起”或“解析 Nginx 访问日志统计 Top 10 IP”。场景设计题最硬核它考察的是你平时有没有从全局思考一个系统“万一出问题怎么办”比如“如果机房断网你的服务如何切换”“如果数据库 CPU 飙高你从哪些维度排查”。2.3 提前批的差异化特点提前批跟正式批有一个显著差别提前批不设笔试的情况其实也有但网易这类大厂可能会把笔试放在简历筛选后作为快速分流的手段。提前批笔试的难度经常会略高于正式批因为提前批本身就是为了提前锁定优质候选人出题方不会拿特别基础、看一眼就会的题来筛人。比如正式批可能问“Linux查看端口用什么命令”提前批可能直接给你一段脚本让你分析里面有什么问题、怎么改进。这意味着备考提前批时不能只刷“校招题”还得朝“优质候选人”的标准靠近。哪怕你目前还没法手写一个大项目至少在核心知识点上要做到“能够展开讲出原理”。你在笔试里哪怕遇到不会的题把思路写完整也比留白强很多。阅卷人不是机器人他们会去判断你的思维链路是否可达、方法是否合理。3. 核心知识与考点复习指南3.1 Linux 系统必考重点运维开发笔试基本绕不开 Linux。准备这部分内容时不要只背命令的英文全称要理解命令的应用场景。高频考点方面进程管理会用ps、top、htop查 CPU/内存占用知道kill -9和kill -15的区别。这个经常考比如“某进程无法正常停止怎么办”“为什么kill之后进程还在”。文件系统inode是什么磁盘写满了但df显示有空间是怎么回事du和df有什么区别。这类题出现频率很高因为它真的会在日常排查里遇到。权限体系rwx 权限位、粘滞位、suid 和 sgid 的作用。不要只记 chmod 755 代表什么要能判断“为什么某个文件有s权限”。服务管理systemd 的常用操作systemctl enable和systemctl start的区别、unit 文件的写法。网络排查ping、telnet、nc、curl、traceroute分别解决什么问题什么情况下用哪个工具。尤其注意telnet和nc在排查端口连通性时的差异。备考时可以做一个很小但非常有用的实验用一台云服务器随便启动一个 Python 写的 HTTP 服务然后从另一台机器依次用curl -v、telnet、nc、traceroute去访问观察输出差异。用不了一小时但远比纯背命令印象深刻。因为笔试里客观题很容易出“输出是什么”这种题型你只背过而不亲自敲过看到真实输出很容易发懵。3.2 网络与协议考点网络部分主要围绕 TCP/IP 协议栈展开。高频考点如下TCP 三次握手与四次挥手状态迁移分别是什么TIME_WAIT为什么存在CLOSE_WAIT大量出现说明什么。HTTP 协议HTTP/1.0、HTTP/1.1、HTTP/2 的核心差异常见状态码含义尤其 301/302/304/401/403/502/503/504请求头和响应头常见字段的作用。负载均衡与反向代理四层负载和七层负载的区别Nginx 常见配置转发、超时、重试、健康检查。DNS 解析流程从浏览器输入网址到拿到 IP中间经历了哪些环节DNS 缓存层级。HTTPS 握手简单原理证书、非对称加密、对称加密分别在哪个阶段起作用。这一部分复习时建议画一张请求链路图用户输入网址经 DNS 解析到达 CDN回源到 Nginx再转发到后端服务后端查缓存、查数据库最终返回响应。你不需要画得多精细但要能对着链路把每一步涉及的网络协议和技术组件讲清楚。笔试场景题经常给一条“访问慢”或“访问失败”的链路让你从网络层面逐段排查这张图就是你的排查地图。3.3 数据库与缓存基础数据库在运维开发笔试中不会考得特别深但基本知识必须过关。常见考察方向MySQL 索引原理B 树结构、聚簇索引与非聚簇索引区别、索引失效的常见场景。事务与隔离级别ACID、脏读/不可重复读/幻读、四种隔离级别分别解决什么问题。慢查询排查EXPLAIN看什么type字段的访问类型好坏判断key和rows的含义。Redis 基础常用数据结构及应用场景、缓存穿透/击穿/雪崩的区别与应对方案、持久化 RDB 和 AOF 的区别。数据库这块很容易被备考的人忽略觉得“我是运维开发不是 DBA不考这个”。但实际业务中运维岗位要处理很多和存储相关的问题。举个真实例子某服务发版后接口突然变慢排查发现是新增查询条件导致索引失效全表扫描DBA 不在的时候就得你来定位问题并推动解决。笔试出数据库题就是在考察你有没有这样的敏感度。3.4 容器、云原生与自动化相关2023年这个时间点Kubernetes 基本已经成为后端服务部署的事实标准运维开发笔试基本绕不开容器和云原生话题。重点准备这些Docker镜像和容器的关系、Dockerfile 编写要点层缓存机制、尽量少用apt-get install且合并 RUN 命令、CMD与ENTRYPOINT的区别、进程在容器里的 PID 1 问题。KubernetesPod 是调度最小单位、Deployment 做无状态服务部署、StatefulSet 做有状态服务、Service 的 ClusterIP/NodePort/LoadBalancer 类型区别、ConfigMap 与 Secret 的用途、探针livenessProbe/readinessProbe/startupProbe的作用。CI/CDJenkins/GitLab CI/GitHub Actions 流水线基本概念构建、测试、部署三个阶段分别干什么镜像仓库在流水线里的作用。监控体系Prometheus 拉取模型与 Zabbix 推模型的区别Metrics/Logging/Tracing 三者关系告警规则要怎么设计。这一部分内容多但如果时间有限优先看 Deployment 的滚动更新机制和探针部分。因为网易这类互联网公司在业务发布时非常看重这一点怎么做到发布不中断、出问题时怎么快速回滚。笔试场景题很容易围绕“发布上线流程”展开。4. 实操流程备战笔试的具体操作4.1 第一步用两个星期摸底与扫盲备考笔试题前提是知道自己的薄弱点在哪。不要上来就闷头刷题建议先给自己安排一次摸底找一套其他互联网公司类似的运维开发笔试题限时90分钟做一遍。做完之后把错题和不会的题按知识点归类统计一下哪些板块失分最多然后优先补短板。摸底之后进入扫盲阶段。扫盲不是从头到尾看书而是针对“失分点”查漏补缺。比如你发现自己对 TCP 状态迁移不熟那就集中找关于 TCP 状态的文章、视频然后配合netstat、ss在本地模拟连接状态变化直到能不看图画出状态迁移图。再比如你对 Kubernetes 没实战经验那就用 Kind 或 K3s 在本地起一个单节点集群亲手部署一个 Nginx 服务和配套 Service。扫盲阶段要控制时间尽量控制在两周内。不用追求每个知识点都会写论文而是做到“笔试时看到这道题不陌生能选出正确答案或写出合理思路”。这种投入产出比最高。4.2 第二步围绕高频题型做针对性练习摸底和扫盲之后进入针对练习阶段。这个阶段不要平均用力要围绕最高频的三类题型展开。第一类Linux/网络客观题。这类题突击效果最明显每天花一小时刷题连续刷一周正确率能提升一大截。推荐方式是利用在线刷题平台刷“Linux运维工程师”“系统架构师”分类下的题目做错了就回到对应知识点查漏。第二类编程脚本题。运维开发笔试的编程题通常不考特别复杂的算法但经常考“用代码解决运维实际问题”。你可以自己给自己出题写一个 Python 脚本监听指定端口不可用则重启服务并记录日志写一个 Shell 脚本统计 Nginx 日志中状态码为 5xx 的请求按 IP 聚合输出 Top 10写一个 Python 脚本给一批服务器批量执行命令并收集结果。这些题看起来很朴素但笔试真会考。准备时注意代码风格变量命名清晰、函数拆分合理、异常处理完整不要只写能跑通的“一次性脚本”。第三类场景设计题。这类题没有标准答案但考察的是排查思维。建议用“现象 → 假设 → 验证 → 结论”的结构来组织答案。比如题目给“某个 Web 服务响应越来越慢”你应该先考虑从哪几个层面逐步排查先看服务自身指标CPU、内存、GC 频率再看中间件指标MySQL 慢查询、Redis 延迟再看网络指标丢包率、TCP 重传率同时检查最近是否有发布变更。回答时要有层次不要一上来就说“重启大法”。4.3 第三步完整做两轮模拟笔试建议在正式笔试前至少完整模拟两轮。模拟时严格按正式考试的时间限制来提前把摄像头、键盘、网络环境都调好。第一轮模拟重点在看“答不答得完”第二轮重点在看“能不能稳定输出”。第一轮模拟后你可能发现时间不够用。可能的原因是客观题上花太久某些不会的题还反复纠结。这时候要调整策略客观题一般单题分值有限如果卡住超过两分钟先标记跳过优先保证编程题和场景题答完。编程题即使不能全部通过测试用例也要写上思路和部分正确代码交给阅卷人判断。第二轮模拟时就要踩着这个调整后的节奏来。另外建议模拟时录屏或开一个文档随手记录自己在哪道题上卡住、当时的心情和判断模拟结束后看看自己在时间压力下容易犯什么错误。很多人在笔试时不是不会而是读题太快没理解清楚需求就跑偏了。这种问题通过模拟完全可以提前暴露。4.4 编程题实操范例监控脚本这里用一道典型的笔试编程题练手题目是这样写一个脚本每 30 秒检查一次指定进程是否存在如果进程不存在就尝试拉起连续 3 次拉起失败则发送告警消息。要求说明实现思路并写出代码。这道题表面上考的是“进程监控”实际考点有三层一是对 Linux 进程管理的理解二是脚本代码的健壮性三是对“告警和自动化”业务逻辑的把握。先看思路通过pgrep或读取/proc文件系统来判断进程是否存在。注意ps aux | grep xxx这种写法容易把 grep 自身进程也匹配进去更稳妥的办法是使用pgrep -f精确匹配进程名或者直接用os.kill(pid, 0)探测进程是否存活。如果进程不存在调用启动命令。启动时可以结合nohup把进程放到后台避免脚本退出导致子进程被杀。记录拉起次数如果连续 3 次仍失败则触发告警。告警方式可以根据实际环境选择调用 Webhook 发送到群机器人、写日志文件、调短信接口。脚本内部要设置合理的重试间隔和超时时间避免进程还没拉起完成就重复判断。Python 示例代码如下#!/usr/bin/env python3 import os import subprocess import time PROCESS_NAME nginx START_CMD [/usr/sbin/nginx] MAX_RETRY 3 CHECK_INTERVAL 30 def is_running(process_name): try: result subprocess.run( [pgrep, -f, process_name], capture_outputTrue, textTrue, timeout5 ) return result.returncode 0 except subprocess.TimeoutExpired: return True # 超时情况保守处理避免误杀 def start_process(cmd): try: with open(os.devnull, w) as devnull: subprocess.Popen( cmd, stdoutdevnull, stderrdevnull, start_new_sessionTrue ) return True except Exception as e: print(fstart failed: {e}) return False def send_alert(message): # 实际场景可换成调用企业微信/钉钉/Slack Webhook print(fALERT: {message}) def main(): fail_count 0 while True: if is_running(PROCESS_NAME): fail_count 0 else: ok start_process(START_CMD) if ok: print(process restarted) fail_count 1 else: fail_count 1 if fail_count MAX_RETRY: send_alert(f{PROCESS_NAME} down, restart failed {MAX_RETRY} times) # 连续失败后通常需要人工介入可以重置计数避免一直刷屏 fail_count 0 time.sleep(CHECK_INTERVAL) if __name__ __main__: main()这段代码里要特别注意几个细节start_new_sessionTrue让启动的进程脱离当前进程组防止脚本退出后把业务进程一并带走。这是真实环境里最容易踩的坑。pgrep -f按完整命令行匹配如果进程名太短容易误匹配其他进程。稳妥做法是在模式串里包含更完整的路径或特征。连续失败计数清零的时机很重要。进程恢复时清零是正确的但连续失败 3 次后如果还继续失败到底是继续每 30 秒尝试还是停止尝试真实场景里应该停止自动拉起并人工介入否则可能导致“进程刚起就被打崩”的循环。上面代码里先重置计数避免无限刷告警但你也可以改成停止自动拉起、只发告警。这道题如果是笔试卷里的编程题写到这里基本能拿一个不错的分数。如果时间允许还可以进一步扩展增加日志记录功能把每次拉起的时间和结果写入文件增加 PID 文件校验支持从配置文件读取进程名和启动命令。扩展功能能展示工程思维但别过度扩展导致主流程出错。4.5 场景设计题实操范例数据库 CPU 100%再举一道典型的场景设计题线上 MySQL 实例 CPU 使用率持续 100%业务接口响应缓慢你作为运维开发工程师如何处理答题策略不要一上来就写“重启数据库”这基本是送命题。要按“保护现场 → 快速止血 → 定位原因 → 长期优化”的结构分步回答。第一步保护现场。如果要把当前实例的库做逻辑备份但这个动作本身也会增加 CPU 负载所以要谨慎。在确认不发生数据丢失的前提下先收集快照信息包括当前活跃会话、SHOW PROCESSLIST输出、慢查询日志、SHOW GLOBAL STATUS关键计数器。哪怕后面问题解决了这些现场数据也能用于复盘。第二步快速止血。CPU 100% 意味着数据库已经没有多余计算能力优先要“减压”而不是“加机器”。常见的止血手段包括把非核心业务的读流量切走利用只读实例分担读压力对核心大查询进行限流通过前端的接口熔断或网关层限制并发防止更多查询涌入如果有明显“罪魁”SQL比如某个笛卡尔连接或SELECT *大查询先从 processlist 里把它 KILL 掉。这个操作要果断但要确认 kill 的 SQL 不是关键业务写入。第三步定位原因。数据库 CPU 飙高通常有三个方向慢 SQL 导致的大量排序/临时表操作、并发连接过多导致的上下文切换、以及索引失效导致的扫描行数暴涨。你可以通过EXPLAIN拆解有问题的 SQL看type是不是 ALLrows估算的行数是否异常大Extra是否出现Using filesort或Using temporary。如果是这种问题优化方向就是加索引、改写 SQL 或拆分大事务。第四步长期优化。不能事件结束后就不管了。建议做三件事把该实例的慢查询阈值调低持续记录 1 秒以上的 SQL给数据库配置关键告警比如 CPU 超过 80% 持续 5 分钟就推送复盘本次故障看能否通过缓存层Redis进一步扛住热点读流量。这种答案写出来笔试阅卷人能看到你是真处理过问题的而不是靠背模板。场景题最好的备考方式是积累自己的“故障复盘笔记”把自己做实验时遇到的各种问题都记录在案回头学习时也更有感知。5. 笔试中的常见问题与避坑实录5.1 客观题部分别在“基础题”上翻车根据我接触过的不少考生反馈真正导致笔试失败的往往不是难题而是基础题丢分。比如这道经典题“Linux 系统里如何查看某个端口是否被占用”正确答案不是ps aux | grep 8080而是ss -lntp | grep 8080或lsof -i:8080。很多人会用netstat其实ss才是现代系统的主流工具。这种题丢了就太可惜。另一个高频翻车点是“TCP 和 UDP 的区别”。不要只说“TCP 可靠UDP 不可靠”要能具体说清楚TCP 有连接管理、滑动窗口流量控制、拥塞控制、超时重传UDP 是无连接、尽最大努力交付、头部开销更小。在笔试客观题里经常给你一组描述让你选出“正确/不正确”的选项表述不严谨就容易中招。还有“HTTP 状态码”也是重灾区。很多人只知道 200、404、500但 301 和 302 的区别、“304 Not Modified”在缓存中的作用、502 和 504 的定位差异这些是必须掌握的。建议做成卡片每天花十分钟过一遍考前再快速扫一眼。5.2 编程题部分代码能力不强的应对策略如果你代码功底一般刷题时很容易慌。我的建议是不要把目标定在“碾压算法题”而是“把能拿的分全拿到”。具体来说做到以下几点先保证代码能编译运行哪怕效率不高。再保证处理边界情况输入为空、进程不存在、目录没有权限等。最后才优化性能比如用集合代替列表判断、避免重复 I/O。笔试编程题和面试手写代码不太一样笔试环境一般能让你跑测试用例。时间允许的话不要只测正常用例要故意测几个边界用例比如端口被占用、配置文件不存在、超时等情况。这样能暴露很多隐藏 bug。另外注意很多候选人拿到编程题后直接开始写代码结果写到一半发现理解错了需求又要重写。更稳的做法是先花 3 分钟把题目要求拆解成 2-3 个明确的小步骤写在草稿纸上。一句话概括如果你的需求理解错误代码写得再漂亮也是零分。5.3 场景设计题部分别答成“操作手册”场景设计题最怕两种答法一是答得太抽象全是“考虑一下网络排查”“检查一下系统资源”这种话没有落地手段二是答得太琐碎变成“先敲top再敲free再敲df -h”的操作流水账没有优先级和逻辑。正确答法是“结论先行 分步验证”。比如“服务响应慢”可以先说“我怀疑最可能是最近发布变更导致的连接池不够或者下游出现慢调用。我会按以下顺序验证查看发布记录与变更内容看服务最近 GC 是否异常查看下游依赖接口的 P99 延迟再看系统自身的 CPU 和内存指标”。这种回答体现了你对问题有排序能力、能识别“最大嫌疑”的能力。5.4 考前如何调整状态笔试当天要保证网络稳定、设备正常。提前检查外接键盘、电量、网络代理如有等所有环境因素。如果不确定笔试平台是否兼容自己的浏览器提前一天用同一浏览器登录测试页面试试。时间分配方面有一个建议客观题如果 90 分钟考试建议最多花 35-40 分钟编程题留 25-30 分钟场景题留 15-20 分钟最后 5 分钟检查是否有漏题。这不是一个严格比例但提醒大家别在客观题上恋战。提前批笔试分数要过线每一分都算数。心态方面运维开发笔试题量通常不小遇到不会的题是正常的。你的目标不是满分而是通过。所以遇到不会的题直接标注、跳过绝不让它影响后面的思路。6. 经验总结与后续建议结合我对运维开发岗位的理解以及历年校招笔试的情况最后给大家一些实用建议。第一个建议建议大家尽早准备自己的“运维工具箱”。运维开发核心能力不只是背知识点而是能快速搭建一套实用工具链。比如你可以在本地用 Docker Compose 一键拉起 Nginx MySQL Redis Prometheus Grafana做各种实验。有了这套环境你不用再去找大量八股文自己动手就能验证各种问题比如 MySQL CPU 飙高、Nginx 502、Redis 缓存穿透都能在本地复现并排查。这个过程积累的故障排查经验比刷一百道题都有用。第二个建议关注有道和其他互联网公司运维团队的实际技术栈。网易云音乐、有道词典这类产品背后的服务规模很大运维开发的核心工作是发布系统、监控平台、容器平台。笔试虽然不会直接问你们的平台是怎么做的但如果你能在场景题里提到“通过监控平台和发布系统联动做自动回滚”“通过容器平台做自动扩容”会显得你对业界主流方案有了解不是停留在“只会登录服务器敲命令”的层次。第三个建议笔试结束不等于学习结束。如果你顺利通过笔试进入面试面试官大概率会拿笔试里的场景题继续往下问追问你“为什么这么排查”“还有没有其他可能性”“当时有没有考虑成本因素”。所以笔试结束后把每道题都认真复盘一遍尤其是场景题可以找同学互相追问来模拟面试压力。把一道场景题从“能写出来”练到“能讲清楚”你离 offer 就又近了一步。第四个建议如果这次笔试没通过千万别气馁。校招不是一锤子买卖网易有正式批其他公司也有大量运维开发岗位。把一次笔试的失败当成查漏补缺的机会总结自己在哪类题上失分最多针对性练习一个月之后往往会有质变。我在实际带新人的过程里发现运维开发这个岗位真正能走得远的人通常不是那些一开始就懂很多的人而是遇到问题愿意往下挖、能写出工具让大家一起用的人。笔试只是第一道门槛你愿意花一个晚上把一道场景题彻底搞明白这种态度比天赋更值钱。最后再分享一个实用建议从现在开始给自己建一份“运维知识库”笔记不要停在收藏夹里。不管是 Linux 命令的注意事项、MySQL 优化案例还是笔试遇到的错题都用自己的话整理进去。长期坚持下来这份笔记就是你最宝贵的技术资产也是面试前最高效的复习资料。祝准备投递网易运维开发岗位的同学都顺利拿到笔试通关卡。 网易运维开发笔试全解析：考点拆解、避坑指南与高效备考路线
1. 项目概述前阵子有学弟找我聊网易2023校招提前批说投了运维开发工程师有道结果笔试直接给他整不会了。我听完他的反馈又翻了翻手头留存的一些面经和笔试题回忆版感觉这个岗位的笔试确实很有代表性它不只是考Linux命令和八股文而是真正在筛选“有工程素养、能写代码、懂业务系统稳定性”的人。这篇文章就把运维开发这个岗位笔试背后的逻辑、备考思路、实操要点全部拆开讲透哪怕你现在刚投简历看完也能知道该往哪个方向使劲。运维开发工程师这个岗位在不同公司叫法不一样有的叫SRE站点可靠性工程师有的叫DevOps工程师还有的叫“平台工程师”。但在网易这种体量的互联网公司里运维开发绝对不是“跑机房、插网线、重启服务器”那种传统运维它本质上是“用软件开发的手段解决运维场景的问题”。这个岗位笔试考察的底层能力包括Linux系统与网络基础、脚本和编程能力、云计算和容器相关知识的掌握程度以及面对线上故障时能不能快速定位、给出合理的解决方案。这篇文章适合三类人看正在准备2023届及以后校招的应届生、工作一两年想从传统运维转向运维开发的同行以及单纯好奇互联网大厂笔试怎么筛人的同学。看完你至少能摸清网易这道运维开发笔试题的出题逻辑更关键的是你可以把同类的知识框架迁移到其他任何一家公司的运维开发笔面试中。2. 岗位需求与出题逻辑拆解2.1 为什么运维开发岗位笔试要“考代码”一个很常见的误解是运维岗笔试应该多考命令、多考操作少考编程。但实际企业笔试里运维开发的技术考察会明显向代码倾斜。原因很简单到了2023年这个时间节点业务系统基本都跑在云上很多机器已经不再是“宠物”而是“牲畜”——挂了就换重点不在单机维护而在自动化管理一大批机器。而自动化靠什么靠脚本靠平台靠代码。所以笔试考代码不是为了难为你是为了筛出那些只会点鼠标、背命令的人。网易有道这条业务线本身做在线教育产品承载着大量直播、题库、点播等业务场景对服务可用性和稳定性要求极高。一旦上课高峰期出现大面积服务抖动几十万人受影响问题必须由运维开发工程师通过监控、告警、自动扩容、兜底方案等手段提前兜住。这就要求你不是“能跑通脚本就行”而是要写出健壮、可维护、能协同的代码——笔试里出现编程题和代码改错题就是在这个前提下设计的。另外也建议大家不要把“运维开发”和“后端开发”对立起来。在这个岗位的日常工作中你既要做 CI/CD 流水线设计也要写告警聚合平台的后端接口偶尔还要调试一下数据同步 Job 的代码。所以真正高效的做法是把运维开发当成“懂业务的稳定性工程师”代码能力不能拖后腿。2.2 不同题型的考察目标一场笔试往往包含多种题型。从实际回忆的信息看网易这个岗位的笔试题型通常包括计算机基础客观题、编程题和场景设计题。客观题覆盖操作系统、网络、数据库、Linux常见命令编程题一般有两道左右难度贴近校招常规水平比如字符串处理、简单算法、手写脚本实现某个小工具场景设计题则往往给一个具体的故障现象或者系统架构让你写出排查思路、解决方案。各题型的考察目标差异很大。客观题考的是“基线是否牢固”比如你知不知道 TCP 三次握手的本质、进程和线程的区别、写时复制是什么这些东西不是靠背而是靠是否真正用过。编程题考的是“能不能用代码表达思路”常见典型题目是“写一个监控脚本检查某个进程是否存活异常时告警并自动拉起”或“解析 Nginx 访问日志统计 Top 10 IP”。场景设计题最硬核它考察的是你平时有没有从全局思考一个系统“万一出问题怎么办”比如“如果机房断网你的服务如何切换”“如果数据库 CPU 飙高你从哪些维度排查”。2.3 提前批的差异化特点提前批跟正式批有一个显著差别提前批不设笔试的情况其实也有但网易这类大厂可能会把笔试放在简历筛选后作为快速分流的手段。提前批笔试的难度经常会略高于正式批因为提前批本身就是为了提前锁定优质候选人出题方不会拿特别基础、看一眼就会的题来筛人。比如正式批可能问“Linux查看端口用什么命令”提前批可能直接给你一段脚本让你分析里面有什么问题、怎么改进。这意味着备考提前批时不能只刷“校招题”还得朝“优质候选人”的标准靠近。哪怕你目前还没法手写一个大项目至少在核心知识点上要做到“能够展开讲出原理”。你在笔试里哪怕遇到不会的题把思路写完整也比留白强很多。阅卷人不是机器人他们会去判断你的思维链路是否可达、方法是否合理。3. 核心知识与考点复习指南3.1 Linux 系统必考重点运维开发笔试基本绕不开 Linux。准备这部分内容时不要只背命令的英文全称要理解命令的应用场景。高频考点方面进程管理会用ps、top、htop查 CPU/内存占用知道kill -9和kill -15的区别。这个经常考比如“某进程无法正常停止怎么办”“为什么kill之后进程还在”。文件系统inode是什么磁盘写满了但df显示有空间是怎么回事du和df有什么区别。这类题出现频率很高因为它真的会在日常排查里遇到。权限体系rwx 权限位、粘滞位、suid 和 sgid 的作用。不要只记 chmod 755 代表什么要能判断“为什么某个文件有s权限”。服务管理systemd 的常用操作systemctl enable和systemctl start的区别、unit 文件的写法。网络排查ping、telnet、nc、curl、traceroute分别解决什么问题什么情况下用哪个工具。尤其注意telnet和nc在排查端口连通性时的差异。备考时可以做一个很小但非常有用的实验用一台云服务器随便启动一个 Python 写的 HTTP 服务然后从另一台机器依次用curl -v、telnet、nc、traceroute去访问观察输出差异。用不了一小时但远比纯背命令印象深刻。因为笔试里客观题很容易出“输出是什么”这种题型你只背过而不亲自敲过看到真实输出很容易发懵。3.2 网络与协议考点网络部分主要围绕 TCP/IP 协议栈展开。高频考点如下TCP 三次握手与四次挥手状态迁移分别是什么TIME_WAIT为什么存在CLOSE_WAIT大量出现说明什么。HTTP 协议HTTP/1.0、HTTP/1.1、HTTP/2 的核心差异常见状态码含义尤其 301/302/304/401/403/502/503/504请求头和响应头常见字段的作用。负载均衡与反向代理四层负载和七层负载的区别Nginx 常见配置转发、超时、重试、健康检查。DNS 解析流程从浏览器输入网址到拿到 IP中间经历了哪些环节DNS 缓存层级。HTTPS 握手简单原理证书、非对称加密、对称加密分别在哪个阶段起作用。这一部分复习时建议画一张请求链路图用户输入网址经 DNS 解析到达 CDN回源到 Nginx再转发到后端服务后端查缓存、查数据库最终返回响应。你不需要画得多精细但要能对着链路把每一步涉及的网络协议和技术组件讲清楚。笔试场景题经常给一条“访问慢”或“访问失败”的链路让你从网络层面逐段排查这张图就是你的排查地图。3.3 数据库与缓存基础数据库在运维开发笔试中不会考得特别深但基本知识必须过关。常见考察方向MySQL 索引原理B 树结构、聚簇索引与非聚簇索引区别、索引失效的常见场景。事务与隔离级别ACID、脏读/不可重复读/幻读、四种隔离级别分别解决什么问题。慢查询排查EXPLAIN看什么type字段的访问类型好坏判断key和rows的含义。Redis 基础常用数据结构及应用场景、缓存穿透/击穿/雪崩的区别与应对方案、持久化 RDB 和 AOF 的区别。数据库这块很容易被备考的人忽略觉得“我是运维开发不是 DBA不考这个”。但实际业务中运维岗位要处理很多和存储相关的问题。举个真实例子某服务发版后接口突然变慢排查发现是新增查询条件导致索引失效全表扫描DBA 不在的时候就得你来定位问题并推动解决。笔试出数据库题就是在考察你有没有这样的敏感度。3.4 容器、云原生与自动化相关2023年这个时间点Kubernetes 基本已经成为后端服务部署的事实标准运维开发笔试基本绕不开容器和云原生话题。重点准备这些Docker镜像和容器的关系、Dockerfile 编写要点层缓存机制、尽量少用apt-get install且合并 RUN 命令、CMD与ENTRYPOINT的区别、进程在容器里的 PID 1 问题。KubernetesPod 是调度最小单位、Deployment 做无状态服务部署、StatefulSet 做有状态服务、Service 的 ClusterIP/NodePort/LoadBalancer 类型区别、ConfigMap 与 Secret 的用途、探针livenessProbe/readinessProbe/startupProbe的作用。CI/CDJenkins/GitLab CI/GitHub Actions 流水线基本概念构建、测试、部署三个阶段分别干什么镜像仓库在流水线里的作用。监控体系Prometheus 拉取模型与 Zabbix 推模型的区别Metrics/Logging/Tracing 三者关系告警规则要怎么设计。这一部分内容多但如果时间有限优先看 Deployment 的滚动更新机制和探针部分。因为网易这类互联网公司在业务发布时非常看重这一点怎么做到发布不中断、出问题时怎么快速回滚。笔试场景题很容易围绕“发布上线流程”展开。4. 实操流程备战笔试的具体操作4.1 第一步用两个星期摸底与扫盲备考笔试题前提是知道自己的薄弱点在哪。不要上来就闷头刷题建议先给自己安排一次摸底找一套其他互联网公司类似的运维开发笔试题限时90分钟做一遍。做完之后把错题和不会的题按知识点归类统计一下哪些板块失分最多然后优先补短板。摸底之后进入扫盲阶段。扫盲不是从头到尾看书而是针对“失分点”查漏补缺。比如你发现自己对 TCP 状态迁移不熟那就集中找关于 TCP 状态的文章、视频然后配合netstat、ss在本地模拟连接状态变化直到能不看图画出状态迁移图。再比如你对 Kubernetes 没实战经验那就用 Kind 或 K3s 在本地起一个单节点集群亲手部署一个 Nginx 服务和配套 Service。扫盲阶段要控制时间尽量控制在两周内。不用追求每个知识点都会写论文而是做到“笔试时看到这道题不陌生能选出正确答案或写出合理思路”。这种投入产出比最高。4.2 第二步围绕高频题型做针对性练习摸底和扫盲之后进入针对练习阶段。这个阶段不要平均用力要围绕最高频的三类题型展开。第一类Linux/网络客观题。这类题突击效果最明显每天花一小时刷题连续刷一周正确率能提升一大截。推荐方式是利用在线刷题平台刷“Linux运维工程师”“系统架构师”分类下的题目做错了就回到对应知识点查漏。第二类编程脚本题。运维开发笔试的编程题通常不考特别复杂的算法但经常考“用代码解决运维实际问题”。你可以自己给自己出题写一个 Python 脚本监听指定端口不可用则重启服务并记录日志写一个 Shell 脚本统计 Nginx 日志中状态码为 5xx 的请求按 IP 聚合输出 Top 10写一个 Python 脚本给一批服务器批量执行命令并收集结果。这些题看起来很朴素但笔试真会考。准备时注意代码风格变量命名清晰、函数拆分合理、异常处理完整不要只写能跑通的“一次性脚本”。第三类场景设计题。这类题没有标准答案但考察的是排查思维。建议用“现象 → 假设 → 验证 → 结论”的结构来组织答案。比如题目给“某个 Web 服务响应越来越慢”你应该先考虑从哪几个层面逐步排查先看服务自身指标CPU、内存、GC 频率再看中间件指标MySQL 慢查询、Redis 延迟再看网络指标丢包率、TCP 重传率同时检查最近是否有发布变更。回答时要有层次不要一上来就说“重启大法”。4.3 第三步完整做两轮模拟笔试建议在正式笔试前至少完整模拟两轮。模拟时严格按正式考试的时间限制来提前把摄像头、键盘、网络环境都调好。第一轮模拟重点在看“答不答得完”第二轮重点在看“能不能稳定输出”。第一轮模拟后你可能发现时间不够用。可能的原因是客观题上花太久某些不会的题还反复纠结。这时候要调整策略客观题一般单题分值有限如果卡住超过两分钟先标记跳过优先保证编程题和场景题答完。编程题即使不能全部通过测试用例也要写上思路和部分正确代码交给阅卷人判断。第二轮模拟时就要踩着这个调整后的节奏来。另外建议模拟时录屏或开一个文档随手记录自己在哪道题上卡住、当时的心情和判断模拟结束后看看自己在时间压力下容易犯什么错误。很多人在笔试时不是不会而是读题太快没理解清楚需求就跑偏了。这种问题通过模拟完全可以提前暴露。4.4 编程题实操范例监控脚本这里用一道典型的笔试编程题练手题目是这样写一个脚本每 30 秒检查一次指定进程是否存在如果进程不存在就尝试拉起连续 3 次拉起失败则发送告警消息。要求说明实现思路并写出代码。这道题表面上考的是“进程监控”实际考点有三层一是对 Linux 进程管理的理解二是脚本代码的健壮性三是对“告警和自动化”业务逻辑的把握。先看思路通过pgrep或读取/proc文件系统来判断进程是否存在。注意ps aux | grep xxx这种写法容易把 grep 自身进程也匹配进去更稳妥的办法是使用pgrep -f精确匹配进程名或者直接用os.kill(pid, 0)探测进程是否存活。如果进程不存在调用启动命令。启动时可以结合nohup把进程放到后台避免脚本退出导致子进程被杀。记录拉起次数如果连续 3 次仍失败则触发告警。告警方式可以根据实际环境选择调用 Webhook 发送到群机器人、写日志文件、调短信接口。脚本内部要设置合理的重试间隔和超时时间避免进程还没拉起完成就重复判断。Python 示例代码如下#!/usr/bin/env python3 import os import subprocess import time PROCESS_NAME nginx START_CMD [/usr/sbin/nginx] MAX_RETRY 3 CHECK_INTERVAL 30 def is_running(process_name): try: result subprocess.run( [pgrep, -f, process_name], capture_outputTrue, textTrue, timeout5 ) return result.returncode 0 except subprocess.TimeoutExpired: return True # 超时情况保守处理避免误杀 def start_process(cmd): try: with open(os.devnull, w) as devnull: subprocess.Popen( cmd, stdoutdevnull, stderrdevnull, start_new_sessionTrue ) return True except Exception as e: print(fstart failed: {e}) return False def send_alert(message): # 实际场景可换成调用企业微信/钉钉/Slack Webhook print(fALERT: {message}) def main(): fail_count 0 while True: if is_running(PROCESS_NAME): fail_count 0 else: ok start_process(START_CMD) if ok: print(process restarted) fail_count 1 else: fail_count 1 if fail_count MAX_RETRY: send_alert(f{PROCESS_NAME} down, restart failed {MAX_RETRY} times) # 连续失败后通常需要人工介入可以重置计数避免一直刷屏 fail_count 0 time.sleep(CHECK_INTERVAL) if __name__ __main__: main()这段代码里要特别注意几个细节start_new_sessionTrue让启动的进程脱离当前进程组防止脚本退出后把业务进程一并带走。这是真实环境里最容易踩的坑。pgrep -f按完整命令行匹配如果进程名太短容易误匹配其他进程。稳妥做法是在模式串里包含更完整的路径或特征。连续失败计数清零的时机很重要。进程恢复时清零是正确的但连续失败 3 次后如果还继续失败到底是继续每 30 秒尝试还是停止尝试真实场景里应该停止自动拉起并人工介入否则可能导致“进程刚起就被打崩”的循环。上面代码里先重置计数避免无限刷告警但你也可以改成停止自动拉起、只发告警。这道题如果是笔试卷里的编程题写到这里基本能拿一个不错的分数。如果时间允许还可以进一步扩展增加日志记录功能把每次拉起的时间和结果写入文件增加 PID 文件校验支持从配置文件读取进程名和启动命令。扩展功能能展示工程思维但别过度扩展导致主流程出错。4.5 场景设计题实操范例数据库 CPU 100%再举一道典型的场景设计题线上 MySQL 实例 CPU 使用率持续 100%业务接口响应缓慢你作为运维开发工程师如何处理答题策略不要一上来就写“重启数据库”这基本是送命题。要按“保护现场 → 快速止血 → 定位原因 → 长期优化”的结构分步回答。第一步保护现场。如果要把当前实例的库做逻辑备份但这个动作本身也会增加 CPU 负载所以要谨慎。在确认不发生数据丢失的前提下先收集快照信息包括当前活跃会话、SHOW PROCESSLIST输出、慢查询日志、SHOW GLOBAL STATUS关键计数器。哪怕后面问题解决了这些现场数据也能用于复盘。第二步快速止血。CPU 100% 意味着数据库已经没有多余计算能力优先要“减压”而不是“加机器”。常见的止血手段包括把非核心业务的读流量切走利用只读实例分担读压力对核心大查询进行限流通过前端的接口熔断或网关层限制并发防止更多查询涌入如果有明显“罪魁”SQL比如某个笛卡尔连接或SELECT *大查询先从 processlist 里把它 KILL 掉。这个操作要果断但要确认 kill 的 SQL 不是关键业务写入。第三步定位原因。数据库 CPU 飙高通常有三个方向慢 SQL 导致的大量排序/临时表操作、并发连接过多导致的上下文切换、以及索引失效导致的扫描行数暴涨。你可以通过EXPLAIN拆解有问题的 SQL看type是不是 ALLrows估算的行数是否异常大Extra是否出现Using filesort或Using temporary。如果是这种问题优化方向就是加索引、改写 SQL 或拆分大事务。第四步长期优化。不能事件结束后就不管了。建议做三件事把该实例的慢查询阈值调低持续记录 1 秒以上的 SQL给数据库配置关键告警比如 CPU 超过 80% 持续 5 分钟就推送复盘本次故障看能否通过缓存层Redis进一步扛住热点读流量。这种答案写出来笔试阅卷人能看到你是真处理过问题的而不是靠背模板。场景题最好的备考方式是积累自己的“故障复盘笔记”把自己做实验时遇到的各种问题都记录在案回头学习时也更有感知。5. 笔试中的常见问题与避坑实录5.1 客观题部分别在“基础题”上翻车根据我接触过的不少考生反馈真正导致笔试失败的往往不是难题而是基础题丢分。比如这道经典题“Linux 系统里如何查看某个端口是否被占用”正确答案不是ps aux | grep 8080而是ss -lntp | grep 8080或lsof -i:8080。很多人会用netstat其实ss才是现代系统的主流工具。这种题丢了就太可惜。另一个高频翻车点是“TCP 和 UDP 的区别”。不要只说“TCP 可靠UDP 不可靠”要能具体说清楚TCP 有连接管理、滑动窗口流量控制、拥塞控制、超时重传UDP 是无连接、尽最大努力交付、头部开销更小。在笔试客观题里经常给你一组描述让你选出“正确/不正确”的选项表述不严谨就容易中招。还有“HTTP 状态码”也是重灾区。很多人只知道 200、404、500但 301 和 302 的区别、“304 Not Modified”在缓存中的作用、502 和 504 的定位差异这些是必须掌握的。建议做成卡片每天花十分钟过一遍考前再快速扫一眼。5.2 编程题部分代码能力不强的应对策略如果你代码功底一般刷题时很容易慌。我的建议是不要把目标定在“碾压算法题”而是“把能拿的分全拿到”。具体来说做到以下几点先保证代码能编译运行哪怕效率不高。再保证处理边界情况输入为空、进程不存在、目录没有权限等。最后才优化性能比如用集合代替列表判断、避免重复 I/O。笔试编程题和面试手写代码不太一样笔试环境一般能让你跑测试用例。时间允许的话不要只测正常用例要故意测几个边界用例比如端口被占用、配置文件不存在、超时等情况。这样能暴露很多隐藏 bug。另外注意很多候选人拿到编程题后直接开始写代码结果写到一半发现理解错了需求又要重写。更稳的做法是先花 3 分钟把题目要求拆解成 2-3 个明确的小步骤写在草稿纸上。一句话概括如果你的需求理解错误代码写得再漂亮也是零分。5.3 场景设计题部分别答成“操作手册”场景设计题最怕两种答法一是答得太抽象全是“考虑一下网络排查”“检查一下系统资源”这种话没有落地手段二是答得太琐碎变成“先敲top再敲free再敲df -h”的操作流水账没有优先级和逻辑。正确答法是“结论先行 分步验证”。比如“服务响应慢”可以先说“我怀疑最可能是最近发布变更导致的连接池不够或者下游出现慢调用。我会按以下顺序验证查看发布记录与变更内容看服务最近 GC 是否异常查看下游依赖接口的 P99 延迟再看系统自身的 CPU 和内存指标”。这种回答体现了你对问题有排序能力、能识别“最大嫌疑”的能力。5.4 考前如何调整状态笔试当天要保证网络稳定、设备正常。提前检查外接键盘、电量、网络代理如有等所有环境因素。如果不确定笔试平台是否兼容自己的浏览器提前一天用同一浏览器登录测试页面试试。时间分配方面有一个建议客观题如果 90 分钟考试建议最多花 35-40 分钟编程题留 25-30 分钟场景题留 15-20 分钟最后 5 分钟检查是否有漏题。这不是一个严格比例但提醒大家别在客观题上恋战。提前批笔试分数要过线每一分都算数。心态方面运维开发笔试题量通常不小遇到不会的题是正常的。你的目标不是满分而是通过。所以遇到不会的题直接标注、跳过绝不让它影响后面的思路。6. 经验总结与后续建议结合我对运维开发岗位的理解以及历年校招笔试的情况最后给大家一些实用建议。第一个建议建议大家尽早准备自己的“运维工具箱”。运维开发核心能力不只是背知识点而是能快速搭建一套实用工具链。比如你可以在本地用 Docker Compose 一键拉起 Nginx MySQL Redis Prometheus Grafana做各种实验。有了这套环境你不用再去找大量八股文自己动手就能验证各种问题比如 MySQL CPU 飙高、Nginx 502、Redis 缓存穿透都能在本地复现并排查。这个过程积累的故障排查经验比刷一百道题都有用。第二个建议关注有道和其他互联网公司运维团队的实际技术栈。网易云音乐、有道词典这类产品背后的服务规模很大运维开发的核心工作是发布系统、监控平台、容器平台。笔试虽然不会直接问你们的平台是怎么做的但如果你能在场景题里提到“通过监控平台和发布系统联动做自动回滚”“通过容器平台做自动扩容”会显得你对业界主流方案有了解不是停留在“只会登录服务器敲命令”的层次。第三个建议笔试结束不等于学习结束。如果你顺利通过笔试进入面试面试官大概率会拿笔试里的场景题继续往下问追问你“为什么这么排查”“还有没有其他可能性”“当时有没有考虑成本因素”。所以笔试结束后把每道题都认真复盘一遍尤其是场景题可以找同学互相追问来模拟面试压力。把一道场景题从“能写出来”练到“能讲清楚”你离 offer 就又近了一步。第四个建议如果这次笔试没通过千万别气馁。校招不是一锤子买卖网易有正式批其他公司也有大量运维开发岗位。把一次笔试的失败当成查漏补缺的机会总结自己在哪类题上失分最多针对性练习一个月之后往往会有质变。我在实际带新人的过程里发现运维开发这个岗位真正能走得远的人通常不是那些一开始就懂很多的人而是遇到问题愿意往下挖、能写出工具让大家一起用的人。笔试只是第一道门槛你愿意花一个晚上把一道场景题彻底搞明白这种态度比天赋更值钱。最后再分享一个实用建议从现在开始给自己建一份“运维知识库”笔记不要停在收藏夹里。不管是 Linux 命令的注意事项、MySQL 优化案例还是笔试遇到的错题都用自己的话整理进去。长期坚持下来这份笔记就是你最宝贵的技术资产也是面试前最高效的复习资料。祝准备投递网易运维开发岗位的同学都顺利拿到笔试通关卡。