又到一年校招季不少学弟学妹来问我网易运维岗的笔试怎么准备。翻出我当年参加网易2020校招运维工程师正式批笔试的记录结合这些年在生产环境摸爬滚打的经验把这场笔试背后的考点逻辑和运维工程师真正需要掌握的能力体系完整拆一遍。这篇文章不光是帮你对答案更想让你明白笔试只是入口面试和实际工作才是真正检验运维功力的地方。1. 网易这场笔试到底在考什么从真题反推考点结构先还原一下2020年网易运维工程师正式批笔试的题型分布。整张卷子大约120分钟题型包括单选题、多选题、编程题和简答题覆盖范围非常广基本是把“运维工程师需要学什么”这个问题用考题的方式问了一遍。1.1 网络与系统基础占比最大的拿分项网络部分几乎是必考重头戏。TCP三次握手、四次挥手的状态迁移背得滚瓜烂熟还不够真题会给你一个具体的tcpdump抓包结果让你判断当前连接处于什么状态或者给出一组ss -tnp的输出让你分析哪条连接处于TIME_WAIT。系统基础方面Linux进程内存布局是高频考点。栈、堆、BSS段、数据段、代码段分别在什么地址范围ulimit -s修改的是哪一块的大小这些都要能画出图来。我记得有一道题是给出一个C程序的内存访问模式让你判断它访问的是栈还是堆本质上就是考malloc和局部变量的区别。文件系统也是必考项。inode耗尽导致No space left on device但df -h显示还有空间的经典坑在笔试里直接以场景题出现。XFS和ext4的差异、软链接和硬链接的区别几乎每年都换着花样考。1.2 数据库与中间件拉开差距的地方MySQL的索引原理、B树结构、聚簇索引与非聚簇索引的区别是高频考点。网易笔试喜欢给一条SQL让你分析它能不能用到索引以及EXPLAIN输出里type字段从const到range再到ALL分别代表什么。事务隔离级别、MVCC机制、RR隔离级别下幻读怎么解决这些不是背概念就能过关的——真题会给一个实际并发场景问你两个事务分别执行了哪些语句后最终的数据库状态是什么。Redis部分五种基础数据类型的底层实现、持久化RDB和AOF的取舍、过期键删除策略、内存淘汰机制是核心考点。有一道印象很深的题问一个zset在元素数量少和数量多时分别用什么编码存储这就是考ziplist到skiplist的转换条件。Kafka部分分区副本机制、ISR收缩与扩张、消息丢失和重复消费的场景判断属于稍微进阶的内容。如果准备过腾讯或阿里的运维笔试再看网易的题会感觉节奏差不多。1.3 编程题与脚本能力不只是LeetCode运维笔试的编程题通常不是纯算法题而是偏向实际场景的代码实现。2020年这道题印象很深——给定一批服务器日志每行包含时间戳、错误级别、服务名和错误信息要求统计每个服务在每分钟内错误数超过阈值的时间段。这类题考的是字符串处理、时间窗口统计、数据结构的选择能力。用Python写的话核心是defaultdict加滑动窗口用C写也行但处理时间戳时要特别注意格式化和比较的效率。建议复习时多练这类“业务逻辑型”编程题而不是只刷纯算法题。脚本能力方面Shell文本处理的组合拳是基本盘grep、awk、sed、sort、uniq、xargs要能不看文档直接写出管道命令。笔试里有一道题是给了Nginx的access.log要求统计IP访问次数Top10这种题用awk {print $1} access.log | sort | uniq -c | sort -rn | head -10一行搞定绝对比写Python快得多。2. Kubernetes调用containerd的原理链路从kubelet到容器启动的完整路径热搜词里提到了一个很核心的运维技能点想知道Kubernetes是如何调用containerd的。这不仅仅是笔试题更是生产环境排查问题的基本功。网易的笔试有一道简答题是画出Pod从创建到Running的完整时序图本质上就是考这条调用链。2.1 CRI与shimKubernetes和容器运行时之间的翻译层Kubernetes设计之初并没有和具体的容器运行时绑定。早期直接调用Docker的API后来为了支持更多的运行时抽象出了CRIContainer Runtime Interface。CRI是一组gRPC接口定义了RuntimeService管理Pod和容器的生命周期和ImageService管理镜像。kubelet作为CRI的客户端通过Unix Socket通常是/run/containerd/containerd.sock和容器运行时通信。但问题是containerd自身并不直接实现CRI。containerd内部有一个cri-plugin插件这个插件把CRI请求转换成containerd原生API调用。你可以这样理解kubelet说英文containerd说中文cri-plugin就是那个翻译官负责把kubelet的“给我创建一个容器”翻译成containerd能听懂的“给我创建一个task”。containerd通过containerd-shim进程来管理每个容器的生命周期。shim是containerd和容器进程之间的中间层它负责将containerd的RPC调用转换成对runc的调用并在containerd崩溃时保证容器进程不退出。这就是为什么你用ps -ef查看进程时能看到一个containerd-shim进程对应一个容器。2.2 从kubelet到runc一次Pod创建请求的完整旅程一条kubectl apply命令发出去之后完整的调用链是这样的API Server存储请求首先打到API Server经过认证、授权、准入控制后Pod对象被写入etcd。kubelet监听运行在节点上的kubelet通过ListWatch机制监听到新的Pod对象进入NextPod调度流程开始对Pod做初始化。CRI调用kubelet通过gRPC调用CRI的RunPodSandbox接口创建Pod沙箱即Infra容器通常叫pause容器。这个容器的作用是持有Pod的网络命名空间其他业务容器通过加入这个网络命名空间来实现网络共享。containerd处理cri-plugin收到请求后通过containerd的namespace服务和container服务创建沙箱容器然后调用StartContainer接口创建业务容器。shim与runccontainerd把容器配置通过containerd-shim传给runc。runc基于Linux内核的namespace和cgroup特性完成进程隔离和资源限制。runc create创建容器进程runc start启动容器进程。CNI网络配置沙箱网络命名空间创建完成后kubelet调用CNI插件如calico或flannel为Pod配置网络。CNI插件通过veth设备对把容器网络命名空间接入宿主机网络并配置IP和路由。2.3 生产环境排查这条链路上常见的问题点理解了调用链排查容器故障就有了明确方向。我用一条kubectl describe pod的输出来对应每个环节可能出问题的地方Pod一直Pending事件信息里如果显示Failed to create pod sandbox大概率是CRI调用失败。先检查containerd服务状态再用crictl ps -a看沙箱容器是否创建成功。Pod创建成功但容器一直ContainerCreating可能是镜像拉取失败crictl images可以确认也可能是CNI网络没有配置完成journalctl -u kubelet -f或者tail /var/log/containerd/containerd.log查看具体报错。容器创建后立即退出的CrashLoopBackOff这通常是应用本身的问题但有一种情况容易被忽略——containerd-shim异常导致容器被杀掉此时需要查看shim进程是否存在以及/var/log/containerd下的容器日志。排查容器问题我个人的习惯是先看kubectl describe再看kubelet日志最后才看containerd日志。因为describe给出的是API层面的状态kubelet日志反映的是CRI调用过程containerd日志则能看到容器运行时的具体操作。从外到内逐层排查定位问题的效率最高。3. 生产环境从零搭建一个系统并做好后续维护这个是热搜词里的另一个核心命题也是运维面试中高频的综合题。2020年那场笔试虽然没有要求完整答题但面试环节基本都会追问。这套方法论不是靠背能解决的必须真正动手做过才能理解每一步的价值。3.1 从裸机到可用系统拆解最小化搭建步骤假设给你一台裸机要求从零搭建一个高可用的Web系统。先梳理出完整步骤硬件与固件配置BIOS中虚拟化选项开启Intel VT-x或AMD-V设置磁盘RAID策略安装操作系统。这一步在工作区常见本地可以直接在VMware里演练。系统初始化安装操作系统后第一件事是配置yum/apt源、安装基础工具vim、curl、tcpdump、sysstat等、配置NTP时间同步、优化内核参数。时间同步经常被忽略但生产环境的日志分析和分布式系统协调都依赖统一时间。内核参数方面至少需要调整net.ipv4.ip_local_port_range、net.core.somaxconn、vm.swappiness等。安全加固关闭不需要的系统服务配置防火墙规则仅放行必要端口修改SSH默认端口并配置密钥登录禁止root直接登录。这一步容易被赶进度的人省掉但安全运维的底线就在这里。基础组件部署按照架构规划安装JDK/Python/Node.js运行时、MySQL/Redis等存储组件、Nginx/OpenResty等接入层组件。每个组件都要独立运行账号不要都用root跑。应用发布构建产物上传到指定路径配置Nginx反向代理和健康检查逐一启动应用节点并验证接口。3.2 系统监控与日志采集从零搭建一套可感知系统状态的方案系统搭建完成只是开始后续维护的核心是让系统状态可感知。没有监控的系统就是睁眼瞎出问题时只能靠用户反馈这是运维工程师不可接受的。监控体系通常按四个层次搭建层次工具选型监控内容告警方式基础监控Node Exporter PrometheusCPU、内存、磁盘、网络Alertmanager 钉钉/邮件应用监控Java Metrics / Custom ExporterQPS、延迟、错误率、JVMAlertmanager Webhook日志监控ELK / Loki Promtail业务日志关键字段、Error追踪ElastAlert / 告警规则拨测监控Blackbox Exporter / 自研脚本从外部视角探测接口可用性AlertmanagerPrometheus的告警规则我踩过一次很深的坑一开始把CPU使用率告警阈值设在80%结果业务高峰期频繁误告警。后来改成基于rate(node_cpu_seconds_total{modeidle}[5m])算使用率同时增加连续持续5分钟才触发告警的条件误报率大幅下降。告警规则不是越灵敏越好而是要在“不漏报”和“不轰炸”之间找到平衡点。日志采集方面Java应用主流的方案是Filebeat采集日志文件推到Kafka或者直接进Elasticsearch。日志切分建议按天滚动保留30天。log rotate配置要注意Nginx、Tomcat、自定义应用都有各自的日志切割机制统一用logrotate管理最省心。3.3 备份恢复与容灾演练关键时刻决定运维价值备份是运维工作中“平时看不出价值出事才知道多重要”的部分。真正的备份不是“备份了”而是“能在故障时恢复”。数据库备份MySQL采用全量增量策略每天凌晨全量备份实时同步binlog到备份服务器。mysqldump做逻辑备份XtraBackup做物理备份。备份文件要定期做恢复演练——我见过太多备份文件存在但恢复失败的案例。配置文件备份Nginx、应用配置文件、Kubernetes资源清单建议纳入Git仓库管理变更记录可回溯。容灾演练半年做一次机房级别的容灾演练模拟主数据库宕机验证从库提升的RTO是否达标。这项经验在面试时讲出来比任何理论都更有说服力。3.4 变更管理与应急响应运维日常工作的核心范式生产环境维护的重头戏是变更管理。一次未经充分评估的变更可能引发大面积故障。我会坚持一个原则任何变更必须有回退方案。规范的变更流程包括变更申请、风险评估、方案评审、变更窗口执行、变更验证、回退预案六步。特别是数据库结构变更必须在预发环境先验证。磁盘空间不足再扩容时要搞清楚是数据增长还是日志膨胀如果是日志光扩容解决不了根因必须同时处理日志归档策略。应急响应的标准动作是“先恢复、后定位”。服务挂了第一件事不是查日志而是先把流量摘掉或者回滚版本让服务恢复然后再从容排查根因。这个习惯我在经历过多次大故障后验证了无数次冷静处理永远是第一位的。4. 运维工程师笔试中那些容易翻车的细节复盘与避坑4.1 多选题的“少选多选都不得分”谨慎策略比知识储备更重要网易运维笔试的多选题规则很严格多选、少选、错选都不得分。这意味着不能靠“多选几个提高命中率”的赌徒心态。我的策略是确定项选上不确定项宁可不选。比如考TCP状态迁移时题目问“哪些状态可能出现在主动关闭连接的一方”确定项是FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT但对CLOSE_WAIT是否出现在主动方存在争议。按严格定义CLOSE_WAIT是被动方收到FIN后的状态。如果你对CLOSE_WAIT的归属不够确定不选它至少保住确定的分数。多选题本质上考的是知识掌握的精确度模糊的记忆在单选里可能蒙对在多选里就是丢分项。4.2 编程题的时间复杂度别让“能用”挡住“通过”笔试编程题通常有多组测试数据如果代码时间复杂度太高会在后台超时。2020年那道日志统计题用双层循环遍历所有日志条目的时间复杂度是O(n²)一旦数据量到几十万条就会超时。正确的做法是用哈希表加时间窗口扫描先按时间戳排序再用双指针或滑动窗口统计每分钟内的错误数。这样时间复杂度降到O(n log n)主要是排序开销。复习时一定要对手写常用数据结构和算法保持熟练哈希表、堆、滑动窗口、双指针、前缀和。运维工程师不要觉得自己不搞纯开发就不重视算法现代运维不是只会敲命令就够的。写脚本处理大量数据时如何让脚本在合理时间内跑完考察的就是这部分能力。4.3 简答题的答题结构从“点的堆积”到“逻辑链条”简答题最忌讳只回答零散的点。比如“MySQL主从复制延迟怎么处理”如果只写“改进主库配置”“升级硬件”得分一定很低。应该按逻辑链条回答先从架构层面分析主从延迟的根源在于从库单线程回放binlog5.7版本之后引入了并行复制MTS开启slave_parallel_workers4以上能将回放速度提升数倍。再从SQL层面优化主库的大事务是延迟的主要诱因一次删掉百万行数据会产生大量binlog从库回放耗时很长。优化方向是拆分大批量操作分批提交。从监控与报警层面兜底配置seconds_behind_master监控告警超过阈值及时介入。简答题的阅卷是按逻辑层次采分的。你给出的方案越成体系说明你对问题的理解越全面得分自然更高。4.4 时间分配策略先拿稳分再攻坚120分钟做完整张卷子时间是很紧的。我的策略是拿到卷子先花2分钟通览全部题目按“秒杀题-计算题-编程题-简答题”的顺序做题。秒杀题概念题、状态迁移题、Shell命令结果题不犹豫直接选。计算题子网划分、CIDR计算这类题只要细心就有分不要跳。编程题留足30-40分钟先写框架再补细节确保核心逻辑正确。简答题留20-30分钟用“问题分析-解决思路-方案对比-效果验证”结构作答。5. 面试环节比笔试更考验实战功底的博弈网易运维岗的面试一般有两到三轮技术面一面问基础二面问项目三面可能会涉及场景设计和综合能力。笔试只是门槛面试展现的是你的工程思维和解决问题的能力。5.1 常见面试题背后的考察意图面试官问“你处理过最复杂的故障是什么”不是真的想听你炫耀技术而是考察你的逻辑分析能力和故障处理流程。这类问题采用STAR结构回答Situation某天线上支付接口成功率突然下跌20%报错集中在Connection timed out。Task需要在10分钟内恢复服务并找到根因。Action先通过监控确认是单机房问题还是全网问题发现某一可用区的机器健康检查全部失败。立即把流量切到其他可用区服务恢复。然后逐一排查该可用区的网络设备、负载均衡、宿主机状态最终定位是网络设备路由漂移导致。Result服务5分钟内恢复网络设备厂商介入确认为硬件故障。这个回答展示了应急处理、问题定位、架构容灾三个层面的能力。面试官要的不是你一个人解决了多大的bug而是你如何系统性地控制风险和快速恢复。再比如“Kubernetes中Pod驱逐机制是什么”这类问题考察的是对集群稳定性机制的理解。要能回答具体参数节点资源不足时kubelet如何根据QoS等级驱逐Podeviction-hard和eviction-soft的区别是什么nodefs.inodesFree触发的是什么级别的驱逐。这些细节在笔试中可能就是一道选择题面试中就变成考察你生产经验深度的试金石。5.2 加分项如何展示自己的全栈运维能力运维工程师的竞争力体现在对系统全貌的掌控力上。面试时不要只讲你会装什么工具而是要讲你如何把一个需求拆解成完整的架构方案。举个例子面试官问“如果让你设计一个日活千万的资讯类应用的运维架构你怎么做”。有经验的回答不是堆砌组件名称而是从容量评估、高可用设计、监控告警、容量扩展、成本控制几个层面逐步展开容量评估根据日活预估峰值QPS再按单机Nginx连接数、应用单实例QPS、数据库瓶颈推算出所需的机器规模。高可用设计接入层部署多活NginxKeepalived应用层无状态化部署多节点数据层MySQL主从Redis集群每个环节消除单点。监控告警从基础设施、应用指标、业务指标三个层面监控。基础设施关注CPU/内存/磁盘/网络应用指标关注QPS/RT/错误率/JVM业务指标关注注册成功率/订单转化率。容量扩展提前规划好应用扩容和数据库瓶颈的应对方案明确哪一层先扩容、哪些操作可以弹性伸缩。这种回答展示的是整体架构思维而不是零散的技术点。5.3 新趋势具身智能应用运维带来了什么变化延伸热点词里的“具身智能应用运维工程师”属于运维领域的新方向也可以了解下。具身智能系统涉及大量边缘设备、AI推理模型、实时控制链路运维复杂度和传统互联网应用差异很大。核心变化是模型版本更新频率更高需要专门的模型仓库和模型版本管理边缘设备分布广泛需要远程批量管理能力实时推理任务要求低延迟网络抖动监控变得极为敏感。这些新方向如果面试时能主动提出来并讲出一些自己的理解会给人留下关注技术前沿的好印象。6. 从校招笔试到合格运维一条真实可行的自我提升路径作为过来人我认为运维工程师的成长路径可以这样划分每个阶段的重点不同。6.1 基础期0-1年先把“会用”练成“熟练”刚入职场的运维新人最重要的不是搞什么高深技术而是把命令敲利索。Linux基础命令要形成条件反射看到进程异常能快速用top、ps、strace判断看到网络不通能快速用ping、tcpdump、route定位。这个阶段的学习方法就是多用多练。自己搭一套实验环境把Nginx配置、MySQL主从复制、Redis高可用这些基础服务反复搭几遍直到闭着眼都能写配置。然后再把Kubernetes集群建起来亲手跑一遍Pod调度、服务暴露、滚动更新。6.2 成长期1-3年从“会操作”到“懂原理”这个阶段的关键是理解原理。为什么Kubernetes要设计CRI接口为什么要用containerd而不是直接用runc为什么MySQL用B树而Redis用跳表这些问题看似理论但在生产环境排查问题时有原理支撑和没有原理支撑效率差距是数量级的。系统排查能力是这个阶段的标志。遇到故障时能根据现象快速圈定排查范围从硬件到操作系统、从网络到应用、从代码到配置。平时多积累排障案例建立自己的知识库和排查手册。6.3 专业期3年以上从“运维”到“架构”到了这个阶段核心竞争力已经从“解决问题”升级为“预防问题”和“架构设计”。你需要能提前发现系统的瓶颈能设计出高可用、易扩展的架构方案能在成本、稳定性和效率之间做出合理取舍。同时要具备自动化平台建设能力。与其手动执行命令不如写脚本、搭平台把重复性工作自动化。一个成熟的运维团队一定沉淀了发布系统、监控平台、日志平台、配置中心等内部工具链。个人学习路径上推荐关注SRESite Reliability Engineering的理念。SRE不只是运维的一种说法而是一套完整的方法论用软件工程的方式解决运维问题强调自动化、可观测性、容量规划、故障演练。这套方法论对任何规模的企业都有价值——它不依赖具体技术栈而是提供一种思维方式。最后给正在准备校招的同学一句实在的建议运维岗位考的不是死记硬背而是你是否真正理解一个系统从开发到上线再到稳定运行的完整生命周期。多动手、多总结、多复盘你走过的每条弯路最后都会变成面试时能讲出的宝贵经验。