2023年秋招季运维岗笔试已经明显不是前几年那种“背背命令、写写脚本”就能过的考试了。小满秋招第二批运维岗的笔试题目整体给我的感觉是广度覆盖到位、深度考察务实、场景化题目占比大幅提升。尤其是云原生、监控告警、故障排查链路这几块如果平时只是“用过”而没有“理解过”底层逻辑很容易在笔试环节被筛掉。这篇文章我会结合这批笔试的实际考察方向把运维笔试中最高频、也最容易失分的知识点和答题思路做一个完整复盘。不是简单罗列“考了什么”而是把每一类题目背后的考察意图、答题框架、实操细节都拆开讲清楚给准备运维岗笔试的同学一份可复用的备考路径。1. 先聊聊这场笔试的整体面貌题型分布与考察重心运维笔试和开发笔试的最大区别在于开发笔试考“能不能写出来”运维笔试考“能不能定位、能不能恢复、能不能防住”。所以这套卷子的题型结构也很有代表性值得每个准备运维岗的人都参考一下。1.1 考察范围与前几年相比有什么变化从题目覆盖的知识域来看今年的范围集中在六个大方向Linux基础与操作系统原理不再是单纯的命令默写而是进程调度、文件系统、系统启动流程、故障恢复这类偏原理的题目。网络协议与排障TCP/IP握手、DNS解析链路、HTTP状态码、网络抓包分析以及典型的网络故障排查场景。中间件与数据库MySQL主从同步、慢查询优化、Redis缓存穿透/击穿/雪崩、消息队列的可靠性和顺序性。云原生与容器Kubernetes调度原理、Pod生命周期、容器网络、以及kubelet与容器运行时之间的调用机制这是往年比较少见的深度。监控与可靠性设计监控体系搭建、告警规则设计、容量评估、高可用架构设计这类题目占比明显上升。安全与基线加固系统加固、权限管理、日志审计、常见攻击的应急处置。和前两年对比最大的变化是纯记忆类题目减少场景分析和链路排查类题目显著增加。比如“请描述Kubernetes创建一个Pod的完整流程”“线上MySQL出现主从延迟你怎么排查”这类题目光靠背答案是拿不到分的必须真正理解组件之间的调用关系和排查思路。1.2 笔试题型结构与分值策略这套卷子满分100分题型大致如下题型题量分值占比特点单选题20题20%覆盖面广主要考基础概念和命令参数多选题10题15%容易漏选错选考察知识边界是否清晰判断题10题10%混淆项多专门坑“半懂不懂”的人简答题6题30%核心得分项考察原理理解和表达能力场景分析题3题25%真正的拉分题考察完整排查链路和方案设计从分值结构就能看出简答题和场景分析题加起来占了55%这说明笔试的核心目的是筛选“真正做过运维、理解系统底层”的人而不是能背题库的人。我的建议是单选、判断这类客观题要控制时间把主要精力留给简答和场景题因为后者不仅分值高而且阅卷时非常看重答题的框架完整度和细节可信度。2. Linux与操作系统题答对一半靠基本功另一半靠答题习惯Linux相关的题目在运维笔试里永远是大头但这批笔试的Linux题明显往“原理排查”方向倾斜。单纯问“查看CPU使用率的命令是什么”这种题目基本绝迹了取而代之的是“系统负载飙高你怎么定位是CPU问题、IO问题还是上下文切换问题”这类需要完整思路的题目。2.1 高频命令题从“会用”到“会答”命令题不是没有但考察方式变了。比如有一道题是给出一个场景“某个进程占用了大量内存如何找出这个进程并查看它的内存详细使用情况”。很多人第一反应是写top但标准答案应该是一套组合命令链路# 第一步找出内存占用TOP的进程 top -o %MEM # 第二步查看指定进程的内存映射详情 pmap -x PID # 第三步查看进程的详细状态和上下文 cat /proc/PID/status # 第四步结合系统整体内存情况判断 free -h vmstat 1 5这类题考察的不只是命令记忆而是你是否知道从哪个维度去定位问题。top看到的是全局快照pmap看到的是进程内部的内存分布细节/proc/PID/status能看到进程的特定状态字段这些工具组合起来才能形成完整的判断依据。另一个值得注意的点是系统启动流程。题目里有一个很经典的故障场景“服务器重启后SSH服务无法启动你如何排查”。很多人直接答“检查ssh配置”但一个合格的运维应该从系统启动的完整链路出发来分析先看启动服务状态systemctl status sshd。查看服务日志journalctl -u sshd -n 100。检查端口是否被占用ss -lntp | grep 22。检查防火墙规则iptables -L -n或firewall-cmd --list-all。检查SELinux是否拦截getenforce必要时看/var/log/audit/audit.log。最后才是检查配置文件语法sshd -t。答题的时候把这条链路完整写出来就算最后的根因判断偏了阅卷老师也会认为你有成体系的排查方法论这比只写一个孤立命令得分高得多。2.2 进程与负载分析类题目的实操思路有一道简答题很有代表性“服务器负载load average持续偏高用哪些命令、按什么顺序排查”这道题我觉得是整张卷子里比较考验真实水平的一道因为它没有一个标准答案只有合理的排查链路。我推荐的排查顺序是这样的先确认负载的构成top查看us用户态CPU、sy内核态CPU、waI/O等待、hi/si硬/软中断的占比。负载高不等于CPU忙可能是不可中断睡眠的进程堆积。再查进程状态ps -eo pid,stat,wchan:30,cmd | grep D找出处于D状态不可中断睡眠的进程这类进程通常是等I/O。区分CPU密集型还是I/O密集型用pidstat -u看CPU使用率用pidstat -d看进程的I/O读写速率。如果怀疑上下文切换过多vmstat 1 5看cscontext switch列pidstat -w看具体的进程切换次数。最后结合系统日志确认dmesg -T | tail看内核日志有没有出现hung task、OOM、磁盘I/O error等关键信息。这类题目的答题技巧是一定要把排查动作和判断逻辑绑定在一起说不要只罗列命令。比如“用vmstat查看cs列如果数值巨大说明系统上下文切换频繁下一步通过pidstat -w定位到具体进程再结合进程的业务类型判断是锁竞争、线程池过大还是I/O等待导致”。2.3 系统启动故障这类实操题一定要写出排查链路卷子里有一道场景题特别贴近生产环境“一台Linux服务器重启后无法正常进入系统卡住或直接进入emergency mode你怎么处理”。这道题考察的是对系统启动流程的理解深度。一个完整的答题框架应该是先判断卡在哪个阶段BIOS/UEFI阶段、GRUB引导阶段、内核加载阶段、systemd初始化阶段、还是服务启动阶段。每个阶段有不同的表现特征。如果是GRUB阶段问题可能在启动菜单按e进入编辑模式检查引导参数是否正确或者进入rescue模式用grub2-mkconfig重新生成引导配置。如果进入emergency mode先看/etc/fstab有没有挂载项出错——这是最常见的原因。把出问题的挂载行注释掉或修复然后systemctl daemon-reload并mount -a验证。如果是内核模块或驱动问题用journalctl -b -1查看上一次启动的日志确认是哪个模块初始化失败。修复后一定要验证reboot之前先systemctl status查看关键服务状态。这道题要拿高分关键是把“判断依据”写清楚。比如“挂载失败导致emergency mode”的判断依据是启动时最后几行输出出现了类似Failed to mount /data的报错输入root密码后执行journalctl -xb能看到具体的mount失败原因。这比干巴巴说“检查fstab”要有说服力得多。3. 网络专项协议、排障与安全策略缺一不可网络部分在运维笔试中的分量一直很稳定但考察的角度已经从“背概念”转向“会排障、懂安全”。这套卷子的网络题包含了TCP协议细节、DNS解析流程、HTTP状态码语义以及一个完整的网络故障排查场景题。3.1 网络基础题别只背七层模型有一道多选题问的是“TCP三次握手过程中客户端和服务端各自的状态变化”这题看上去简单但错误率很高。因为很多人只记得“三次握手”这个名词不记得状态机的完整迁移路径。正确的状态迁移是这样的客户端CLOSED → SYN_SENT → ESTABLISHED服务端LISTEN → SYN_RCVD → ESTABLISHED如果题目再深入一点问“在第二次握手时服务端做了什么”那就要答出服务端收到SYN后分配传输控制块TCB向客户端回复SYNACK并进入SYN_RCVD状态同时会把这个连接放入半连接队列。关于半连接队列和全连接队列的细节笔试也考到了。ss -lnt可以查看当前监听端口的队列情况如果出现了Recv-Q溢出说明全连接队列已满这通常会表现为客户端连接超时或被重置。生产环境里常见的SYN flood攻击本质就是通过大量伪造SYN请求占满半连接队列导致正常连接无法建立。3.2 故障排查题的答题框架场景题里有一道关于“用户反馈访问某个Web服务非常慢甚至超时”的排查题。这种题目在真实笔试中几乎必出因为网络故障排查是运维的日常核心工作之一。我的答题思路是这样的先分端定位先确认是客户端问题、网络链路问题、还是服务端问题。在客户端curl -w查看连接时间、TTFB时间、总耗时把“慢”拆解成“连接慢”“响应慢”“传输慢”三个阶段。再查DNS解析dig trace或nslookup确认解析耗时如果DNS解析超过几百毫秒可能就是DNS服务器或本地缓存的问题。然后确认TCP连接质量telnet或nc测试端口连通性ping看丢包率和RTT如果跨机房访问还要用mtr看每一跳的延迟定位是哪个节点慢。最后看服务端瓶颈ss -lnt看连接队列top看CPU和内存nginx或应用日志看响应时间分布。重点是回答里要体现出**“分层排查、逐步缩小范围”**的方法论而不是跳到一个可能的根因上就停住。阅卷老师看的是你遇到问题时会不会慌、有没有章法。3.3 安全加固题从防护到纵深网络安全相关的题目在这套卷子里不是简单的概念题而是结合具体场景问加固方案。比如有一题问“公司内部一台Web服务器对外开放你会做哪些基础安全加固”这类题其实是送分题前提是你有实际经验。合理的加固清单应该包括系统层面禁用root远程登录、配置SSH密钥认证禁密码、修改默认SSH端口或配置fail2ban、设置合理密码策略、定期yum/apt更新安全补丁。网络层面防火墙只放行业务端口Web服务用WAF或安全组前置限制管理口的源IP白名单。应用层面Nginx隐藏版本号、配置请求频率限制、设置上传大小限制、日志开启访问日志和错误日志。监控层面配置关键端口的存活监控、系统登录告警、文件完整性校验如aide。这类题拿分的关键是层次感和可操作性。比如“防火墙只放行业务端口”就要具体到iptables -A INPUT -p tcp --dport 443 -j ACCEPT这类规则而不是停留在“配置防火墙”这种空话上。4. 中间件与存储这些基础组件才是笔试重头中间件和存储相关的题目在运维笔试中占比一直很高因为生产环境的故障很大一部分出在MySQL、Redis、消息队列、NFS这类基础组件上。小满这批笔试在这一块出题相当细尤其是MySQL和Redis几乎每个考点都和生产实际紧密挂钩。4.1 MySQL必考面主从、慢查询、备份恢复MySQL相关的题目覆盖了主从复制、慢查询优化、备份恢复三个核心方向。主从复制问了这样一个问题“MySQL主从延迟可能由哪些原因导致如何排查”。我的答题框架是先观察延迟的规模和趋势Seconds_Behind_Master的值是持续增长还是波动用SHOW SLAVE STATUS\G查看Relay_Log_File和Relay_Log_Pos判断SQL线程是否在正常回放。区分网络延迟、IO线程延迟、SQL线程延迟从库IO线程负责拉取binlogSQL线程负责回放。如果IO线程慢通常是主从之间网络带宽或主库binlog生成量过大如果SQL线程慢通常是从库硬件性能不足、大事务回放、或缺少合适的索引。生产上的常见解法大事务拆小、并行复制slave_parallel_workers、从库硬件升配、避免在从库做分析类大查询。定位到具体SQL开启慢查询日志slow_query_log用pt-query-digest分析慢SQL排行找出导致延迟的大事务。慢查询优化的题目考察的是能否快速定位问题SQL。答题时要能说清楚先EXPLAIN看执行计划再看type类型ALL全表扫描是重点怀疑对象、key是否用到索引、rows扫描行数然后针对性加索引或改写SQL。有一道题特别给了个例子“一个订单表查询WHERE status1 AND create_time 2023-01-01数据量上亿如何优化”能答出“建联合索引(status, create_time)”之外还能说出“考虑按时间分表或归档历史数据”的才是能拿高分的答案。备份恢复考的是思路。有个题目是“误删了一张核心表如何恢复”。一个完整的恢复流程是立即停止对该表的所有写入操作防止二次破坏。确认备份策略有没有全量备份binlog日志。如果是物理备份如XtraBackup恢复全量备份到临时实例。根据误删时间点用mysqlbinlog解析binlog找到误删时刻之前的binlog位点。在临时实例上重放binlog到误删前一刻导出表数据再导入线上库。这道题的关键是知道binlog在恢复链路中的位置很多人只答“用备份恢复”完全忽略了binlog回放这一步这在真实误删场景中是不够的。4.2 Redis与消息队列考点集中在“场景选型”Redis相关的题集中在缓存穿透、缓存击穿、缓存雪崩这三个经典问题上而且会组合起来考。缓存穿透查询一个不存在的key请求直接打到DB。解法布隆过滤器拦截、缓存空值并设置短过期时间。缓存击穿某个热点key过期瞬间大量请求打到DB。解法互斥锁重建缓存、逻辑过期、热点key不过期。缓存雪崩大量key在同一时间过期。解法过期时间加随机值、多级缓存、服务降级和限流。我记得有一道场景题是“秒杀活动开始时Redis中商品库存key过期数据库瞬间被压垮如何解决”答题时要把击穿的解决方案完整写出来尤其是互斥锁方案要注意说明“只有第一个请求能拿到锁并重建缓存其他请求等待或直接返回旧值”这个细节。消息队列考的是可靠性和顺序性。比如“如何保证消息不丢失”要分三端回答生产端要确认发送成功同步发送或事务消息服务端要开启持久化消费端要手动ack并做消费幂等。顺序性问题的核心思路是分区/队列内有序、单生产者或保证同一业务key进入同一队列。4.3 存储与文件系统NFS、RAID、磁盘IO存储相关的题不算多但有一道关于“磁盘空间不足但df -h和du -sh结果不一致”的题很有意思。这个现象在运维日常中很常见原因通常是某个大文件被删除但进程还在持有文件句柄空间没有真正释放。正确的排查链路是# 查看已删除但被占用的文件 lsof | grep deleted # 确认是哪个进程持有 lsof L1 # 确认后重启进程或释放句柄这个知识点考察的是对Linux文件系统工作原理的理解删除文件只是断开目录项和inode的关联只要文件仍被某个进程引用磁盘空间就不会真正释放。答出这一层原理比只写lsof | grep deleted更出彩。RAID相关的题考察了RAID5和RAID10的区别与选型。答题的要点是RAID5兼顾空间利用率和容错允许坏一块盘适合大容量存储、读多写少的场景。RAID10安全性最高允许每组坏一块盘写性能更好适合数据库这类对性能和可靠性都有要求的场景。从CPU和IO开销来说RAID5的写操作有校验计算的开销RAID10没有校验计算这是选型时容易被忽略的点。5. 云原生与容器方向从“会用kubectl”到“懂原理”今年这批笔试的云原生题目明显加深了不再只是问“kubectl get pods怎么用”而是直接问“Kubernetes创建一个Pod的完整流程是怎样的”“kubelet是如何调用containerd的”。这其实就是我之前在“想知道Kubernetes是如何调用containerd的从原理到实体调用架”这个话题里聊过的一条完整调用链路。笔试考到这个深度说明招聘方希望运维不只是“能用命令部署应用”而是“理解系统内部的调用关系能真正排查云原生环境下的复杂故障”。5.1 Kubernetes调度与Pod生命周期有一道简答题是“简述从创建Deployment到Pod运行起来的完整过程”。我建议按这条链路来答客户端通过kubectl向API Server发起创建Deployment的请求经过认证、授权、准入控制三个环节。API Server校验通过后将Deployment对象写入etcd并返回结果给客户端。Deployment Controller监听到新的Deployment对象对比期望状态和当前状态创建对应的ReplicaSet。ReplicaSet Controller监听到新的ReplicaSet对象根据副本数创建Pod对象。对于裸Pod跳过这两步Scheduler通过watch机制发现未调度的Podspec.nodeName为空经过预选Predicates和优选Priorities两个阶段选出最合适的节点将绑定结果写回API Server更新Pod的nodeName字段。目标节点上的kubelet watch到Pod被调度到本节点开始执行Pod创建流程。能答到这一步就已经能超过大部分只懂kubectl操作的考生了。5.2 kubelet如何调用containerd一条完整调用链如果题目追问“kubelet是怎么把Pod跑起来的”那就需要把容器运行时的调用机制说清楚kubelet通过CRIContainer Runtime Interface与容器运行时通信。CRI是Kubernetes定义的一套gRPC接口包含RuntimeService管理沙箱和容器生命周期和ImageService管理镜像。当CRI插件是containerd时kubelet作为gRPC客户端通过Unix Socket默认是/run/containerd/containerd.sock连接containerd的CRI服务端。containerd收到请求后内部处理流程是由CRI服务层将请求转换为containerd的命名空间操作通过containerd的task API调用containerd-shim进程。containerd-shim再调用runcrunc通过Linux内核的namespace、cgroups等接口创建和启动容器进程。笔试如果考到这一步最好能画一条简洁的调用链出来用文字也可以kubelet → CRIgRPC→ containerd → containerd-shim → runc → runc通过clone系统调用创建容器进程。另外有一个容易混淆的点要特别注意Pod和容器的关系。Pod运行前会先创建一个pause容器基础设施容器负责持有Pod的网络命名空间和PID命名空间真正的业务容器通过JoinNamespace加入pause容器的网络和PID空间。这也是为什么说“Pod是Kubernetes最小调度单位但底层网络是pause容器撑起来的”。5.3 容器网络与存储的常见考点容器网络考察了CNI插件的调用流程。kubelet创建Pod时会调用CNI插件完成网络配置大致流程是kubelet先创建pause容器然后调用CNI插件如Calico、Flannel为pause容器配置网络命名空间。CNI插件负责创建veth pair一头接入容器网络命名空间另一头接入宿主机网桥或路由。再配置IP地址、路由规则以及网络策略。这道题考的是对“Pod网络是如何打通”的理解。能说清楚veth pair、cni0网桥、以及Calico的BGP模式或IPIP模式的原理基本就能拿满分。存储方向考的是PV/PVC的Provisioning和Attach流程。答题的核心是PV是集群资源PVC是用户请求StorageClass负责动态创建PV最终通过CSI插件完成卷的创建、挂载和格式化。这里要能区分静态供给和动态供给的区别这是生产环境选型的常见考量点。关于生产环境使用StorageClass我认为动态供给是云原生存储的主流方向因为静态PV需要人工预分配存储空间不够灵活而且在有大量有状态应用时管理成本很高。6. 监控、告警与可靠性设计笔试里的“高薪题”监控和可靠性相关的题在这套卷子里非常抢眼占比接近20%。这也反映了运维岗位的核心价值正在从“维护系统稳定”转向“保障业务连续性、提升系统可观测性”。这类题目没有绝对标准答案但答题框架的完整度直接决定分数高低。6.1 监控体系怎么设计才完整有一道简答“如何设计一套完整的监控体系”。很多人的回答是“用PrometheusGrafana监控CPU、内存、磁盘”这只能算入门级回答。一个完整的监控体系应该分四层来答基础设施监控CPU、内存、磁盘、网络、温度等主机指标用node_exporter采集。中间件/应用监控MySQL的QPS/TPS/连接数/慢查询、Redis的命中率/内存/连接数、Nginx的请求量/5xx比例/响应时间以及应用自身的JVM、GC、接口耗时等指标。业务监控订单量、支付成功率、注册转化率、核心接口的可用性这类指标直接反映用户体验是运维和业务沟通时最有力的数据。日志与链路追踪ELK/EFK收集日志SkyWalking或Jaeger做分布式链路追踪用来做故障根因定位和关联分析。在指标采集上推荐用一个四类黄金信号来组织所有指标延迟Latency、流量Traffic、错误Errors、饱和度Saturation。这四类指标能全面反映一个系统的健康状态面试或笔试时说出来会显得非常专业。6.2 告警治理收得多不等于收得好告警相关的题很有特色问的是“生产环境告警风暴频繁怎么治理”。这其实是运维日常最头疼的问题之一答得好非常加分。我的治理框架是先做告警分级P0立即处理如Redis挂了、支付服务不可用、P115分钟内处理如MySQL连接数过高、P22小时内处理如磁盘使用率超过80%、P3记录跟踪如非核心服务的慢查询。再设告警聚合和抑制Prometheus的group_by参数可以聚合同一类告警inhibit_rules可以抑制衍生告警比如主机宕机时不需要同时收到该主机上所有服务的告警。然后做告警去重同一个根因触发的多条告警应该合并成一条这需要在告警规则里设置合理的keep_firing_for。最后是告警闭环告警必须有确认、处理、恢复、复盘四个环节每次故障后要review告警规则的准确率删除无效告警。这类题的回答核心是体现出你有过“告警疲劳”的真实体验并形成了方法论而不是单纯堆概念。6.3 容量与高可用设计的答题框架场景分析题里有一道容量评估题“线上业务流量预估会翻倍你如何评估现有系统容量并制定扩容方案”。我的答题框架是先摸清当前水位找出现在最忙时段各核心组件的峰值使用率CPU、内存、磁盘IO、网络带宽。再找瓶颈点容量翻倍时先撑不住的一定是短板可能是单台数据库的连接数、Redis的内存上限、Nginx的并发连接数、或某个微服务的线程池大小。做容量估算以“当前峰值*2”为目标算出每个组件需要扩到多少。比如当前单台Nginx峰值并发5000翻倍后需要1万并发那可以加一台同样规格的节点做负载均衡或单机调优调大worker_connections、开启keepalive。最后考虑弹性云环境可以配置HPAHorizontal Pod Autoscaler或云资源的Auto Scaling但要注意HPA扩容有延迟不适合突发流量突发场景要用提前扩容或抢占式实例兜底。高可用方案设计题则是问“设计一个高可用的Web应用架构”这种题要覆盖前端负载均衡SLB/NginxKeepalived、应用层多副本、数据库主从或高可用集群、缓存集群、对象存储、以及故障自动切换机制。能画出架构图当然最好纯文字描述也可以但一定要点出每个单点都有冗余、每个故障都有自动恢复路径。7. 运维规划与项目描述题这类主观题最拉分第二批笔试里有两类主观题特别值得单独拿出来聊一类是“如何从零搭建一套生产系统并做好后续维护”另一类是“在项目总结时如何描述自己的运维工作”。这两道题非常符合“热搜词运维在项目总结时应该如何去描述项目”的关注点也是不少有经验但不会表达的运维容易丢分的地方。7.1 从零搭建一套生产系统怎么答才不空这道题考察的不是“你会装什么软件”而是有没有完整的运维体系思维。高分的答题框架应该包含以下层面需求分析阶段明确业务规模、并发量预估、数据量级、可用性要求是99.9%还是99.99%这会直接决定架构选型和预算。架构设计阶段网络规划VPC/子网/安全组、应用架构单体还是微服务、存储选型关系型/缓存/对象存储、容灾设计同城双活还是异地多活。部署落地阶段标准化操作系统镜像、统一配置管理Ansible/SaltStack、CI/CD流水线、基础设施即代码Terraform。监控与巡检阶段部署PrometheusGrafana、日志采集、核心指标看板、周期性巡检脚本。安全加固阶段系统基线、堡垒机、权限审计、漏洞扫描和修复。演练与迭代阶段故障演练混沌工程、备份恢复演练、容量压测、架构持续优化。这个回答的亮点在于把运维从“交付即结束”提升到了“持续运营”的高度体现出对运维体系化、平台化的理解。如果时间宽裕还可以补充“每个阶段的交付物”和“质量指标”比如部署阶段要输出部署文档、配置基线、回滚方案监控阶段要输出SLO和告警规则。7.2 项目总结怎么说才有亮点项目描述题如果写得很“流水账”比如“负责服务器维护、部署应用、处理故障”那基本就是中低分。我在实际面过很多运维候选人之后发现能把项目讲出价值的人通常都会用“问题-方案-结果”三步法第一步用一句话交代项目的业务背景和规模比如“这是一个日活50万的电商平台核心链路涉及Nginx、Spring Cloud微服务、MySQL集群”。第二步挑1到2个你主导或深度参与的核心事件重点讲你遇到的问题、你的排查过程、你的解决方案。比如“618大促前压测发现网关成为瓶颈我通过调整内核参数、优化Nginx配置、增加限流策略将网关吞吐量提升了40%”。第三步用可量化的结果收尾不要只写“提升了稳定性”要写“将可用性从99.9%提升到99.99%”“将告警数量从每天300条降到30条”这类有数据支撑的成果。在笔试里遇到这种题目我建议用“STAR法则”来组织回答内容同时控制篇幅背景背景简短说任务目标说清楚行动步骤详细写结果结果用数据。这一套模板在面试中同样适用提前练习对后续面试也很有帮助。8. 桌面运维与面试衔接笔试之外的隐形分虽然小满是技术类岗位的笔试但卷子里还有一些考察基础运维素养的题目其中包括桌面运维的常见问题处理以及个人对运维职业的理解。这类题分值不高但答好了能给阅卷人留下“综合素质不错”的印象。8.1 桌面运维常见问题处理思路有一道题问“员工电脑无法上网你怎么远程协助排查”。这道题不算难但需要有一条完整的排查链路先确认影响范围是个别电脑还是整个办公室都无法上网这决定了问题是在终端侧、接入侧还是出口侧。检查物理层和链路层网线是否松动、Wi-Fi是否连接、交换机端口指示灯状态、获取到的IP地址是否正确。检查网络层ping网关测连通性ipconfig或nmcli看IP配置检查是否有静态IP冲突或DHCP分配异常。检查DNS和应用层ping公网IP如223.5.5.5确认基础连通性再nslookup测试域名解析是否正常。最后检查安全软件和代理很多“无法上网”其实是防火墙拦截或代理配置异常。这类题的答题重点是养成从底向上、逐层排查的思维习惯这在任何规模的网络故障排查中都是通用的。8.2 从笔试到面试几个可以提前准备的方向笔试结束后通过初筛的候选人大概率会在面试里被追问如下几类问题我可以提前给点方向手写核心命令和脚本比如“写一个shell脚本监控Nginx进程挂了自动拉起”这需要掌握while循环、if判断、crontab或systemd timer的基本用法。深挖Kubernetes和容器的底层原理我在这篇文章里讲的kubelet→containerd→runc调用链建议能在面试中用自己的话流畅讲出来并且能配合一个实际故障场景说明这个知识怎么用。最近做过的故障复盘强烈建议准备一个结构清晰的故障复盘案例模板包含故障现象、发现方式、排查过程、根因分析、恢复动作、预防措施。这是面试官最看重的“实战证据”。字节跳动的运维面试经常问“讲一个你印象最深的故障案例”如果没有提前准备很容易因为细节混乱而失分。我见过不少候选人技术功底不差但一讲故障就东扯一句西扯一句最后面试官抓不住重点。提前把复盘案例做成结构化文档在面试中就能做到逻辑清晰、言之有物。9. 最后再分享一个备考方法用场景题反向驱动学习复盘完这套笔试我觉得最有价值的不是去背具体的题目和答案而是总结一套**“以场景题为锚点、反向补齐知识体系”**的备考方法。我的具体做法是这样的拿到每一道场景题先不着急看答案而是自己尝试写完整的排查链路和方案设计。写完再跟资料或同事的答案对比看自己漏掉了哪一层、哪一步。比如这次笔试考到的“MySQL主从延迟排查”“Kubernetes创建Pod的完整流程”我在日常工作中其实都遇到过但如果没有刻意把这些经验结构化地写出来临场答题很可能就只有“用过”的印象而写不出体系化的答案。还有一个很实用的技巧每个知识点都要能回答三个层次的问题——是什么概念定义、为什么原理机制、怎么办故障场景下如何排查和解决。比如“Linux负载高”这个知识点三个层次分别是负载是什么运行队列中进程数的平均值、为什么负载会高CPU密集、IO等待、不可中断进程堆积、负载高怎么排查top、vmstat、pidstat、iotop、dmesg的组合排查链路。这个方法论用来备考运维笔试和面试都非常高效因为这恰好就是出题人考察的逻辑。最后说一句肺腑之言运维笔试的题目无论怎么变考察的核心始终是**“在复杂环境下定位问题、在压力下恢复系统、在事后推动改进”**这套能力。这套能力不是靠刷题刷出来的而是靠一次次真实操作积累出来的。如果你还在准备阶段多动手、多复盘、多把经验提炼成方法论这比刷一百套题都管用。
2023运维秋招笔试复盘：云原生、故障排查与监控告警考点解析
2023年秋招季运维岗笔试已经明显不是前几年那种“背背命令、写写脚本”就能过的考试了。小满秋招第二批运维岗的笔试题目整体给我的感觉是广度覆盖到位、深度考察务实、场景化题目占比大幅提升。尤其是云原生、监控告警、故障排查链路这几块如果平时只是“用过”而没有“理解过”底层逻辑很容易在笔试环节被筛掉。这篇文章我会结合这批笔试的实际考察方向把运维笔试中最高频、也最容易失分的知识点和答题思路做一个完整复盘。不是简单罗列“考了什么”而是把每一类题目背后的考察意图、答题框架、实操细节都拆开讲清楚给准备运维岗笔试的同学一份可复用的备考路径。1. 先聊聊这场笔试的整体面貌题型分布与考察重心运维笔试和开发笔试的最大区别在于开发笔试考“能不能写出来”运维笔试考“能不能定位、能不能恢复、能不能防住”。所以这套卷子的题型结构也很有代表性值得每个准备运维岗的人都参考一下。1.1 考察范围与前几年相比有什么变化从题目覆盖的知识域来看今年的范围集中在六个大方向Linux基础与操作系统原理不再是单纯的命令默写而是进程调度、文件系统、系统启动流程、故障恢复这类偏原理的题目。网络协议与排障TCP/IP握手、DNS解析链路、HTTP状态码、网络抓包分析以及典型的网络故障排查场景。中间件与数据库MySQL主从同步、慢查询优化、Redis缓存穿透/击穿/雪崩、消息队列的可靠性和顺序性。云原生与容器Kubernetes调度原理、Pod生命周期、容器网络、以及kubelet与容器运行时之间的调用机制这是往年比较少见的深度。监控与可靠性设计监控体系搭建、告警规则设计、容量评估、高可用架构设计这类题目占比明显上升。安全与基线加固系统加固、权限管理、日志审计、常见攻击的应急处置。和前两年对比最大的变化是纯记忆类题目减少场景分析和链路排查类题目显著增加。比如“请描述Kubernetes创建一个Pod的完整流程”“线上MySQL出现主从延迟你怎么排查”这类题目光靠背答案是拿不到分的必须真正理解组件之间的调用关系和排查思路。1.2 笔试题型结构与分值策略这套卷子满分100分题型大致如下题型题量分值占比特点单选题20题20%覆盖面广主要考基础概念和命令参数多选题10题15%容易漏选错选考察知识边界是否清晰判断题10题10%混淆项多专门坑“半懂不懂”的人简答题6题30%核心得分项考察原理理解和表达能力场景分析题3题25%真正的拉分题考察完整排查链路和方案设计从分值结构就能看出简答题和场景分析题加起来占了55%这说明笔试的核心目的是筛选“真正做过运维、理解系统底层”的人而不是能背题库的人。我的建议是单选、判断这类客观题要控制时间把主要精力留给简答和场景题因为后者不仅分值高而且阅卷时非常看重答题的框架完整度和细节可信度。2. Linux与操作系统题答对一半靠基本功另一半靠答题习惯Linux相关的题目在运维笔试里永远是大头但这批笔试的Linux题明显往“原理排查”方向倾斜。单纯问“查看CPU使用率的命令是什么”这种题目基本绝迹了取而代之的是“系统负载飙高你怎么定位是CPU问题、IO问题还是上下文切换问题”这类需要完整思路的题目。2.1 高频命令题从“会用”到“会答”命令题不是没有但考察方式变了。比如有一道题是给出一个场景“某个进程占用了大量内存如何找出这个进程并查看它的内存详细使用情况”。很多人第一反应是写top但标准答案应该是一套组合命令链路# 第一步找出内存占用TOP的进程 top -o %MEM # 第二步查看指定进程的内存映射详情 pmap -x PID # 第三步查看进程的详细状态和上下文 cat /proc/PID/status # 第四步结合系统整体内存情况判断 free -h vmstat 1 5这类题考察的不只是命令记忆而是你是否知道从哪个维度去定位问题。top看到的是全局快照pmap看到的是进程内部的内存分布细节/proc/PID/status能看到进程的特定状态字段这些工具组合起来才能形成完整的判断依据。另一个值得注意的点是系统启动流程。题目里有一个很经典的故障场景“服务器重启后SSH服务无法启动你如何排查”。很多人直接答“检查ssh配置”但一个合格的运维应该从系统启动的完整链路出发来分析先看启动服务状态systemctl status sshd。查看服务日志journalctl -u sshd -n 100。检查端口是否被占用ss -lntp | grep 22。检查防火墙规则iptables -L -n或firewall-cmd --list-all。检查SELinux是否拦截getenforce必要时看/var/log/audit/audit.log。最后才是检查配置文件语法sshd -t。答题的时候把这条链路完整写出来就算最后的根因判断偏了阅卷老师也会认为你有成体系的排查方法论这比只写一个孤立命令得分高得多。2.2 进程与负载分析类题目的实操思路有一道简答题很有代表性“服务器负载load average持续偏高用哪些命令、按什么顺序排查”这道题我觉得是整张卷子里比较考验真实水平的一道因为它没有一个标准答案只有合理的排查链路。我推荐的排查顺序是这样的先确认负载的构成top查看us用户态CPU、sy内核态CPU、waI/O等待、hi/si硬/软中断的占比。负载高不等于CPU忙可能是不可中断睡眠的进程堆积。再查进程状态ps -eo pid,stat,wchan:30,cmd | grep D找出处于D状态不可中断睡眠的进程这类进程通常是等I/O。区分CPU密集型还是I/O密集型用pidstat -u看CPU使用率用pidstat -d看进程的I/O读写速率。如果怀疑上下文切换过多vmstat 1 5看cscontext switch列pidstat -w看具体的进程切换次数。最后结合系统日志确认dmesg -T | tail看内核日志有没有出现hung task、OOM、磁盘I/O error等关键信息。这类题目的答题技巧是一定要把排查动作和判断逻辑绑定在一起说不要只罗列命令。比如“用vmstat查看cs列如果数值巨大说明系统上下文切换频繁下一步通过pidstat -w定位到具体进程再结合进程的业务类型判断是锁竞争、线程池过大还是I/O等待导致”。2.3 系统启动故障这类实操题一定要写出排查链路卷子里有一道场景题特别贴近生产环境“一台Linux服务器重启后无法正常进入系统卡住或直接进入emergency mode你怎么处理”。这道题考察的是对系统启动流程的理解深度。一个完整的答题框架应该是先判断卡在哪个阶段BIOS/UEFI阶段、GRUB引导阶段、内核加载阶段、systemd初始化阶段、还是服务启动阶段。每个阶段有不同的表现特征。如果是GRUB阶段问题可能在启动菜单按e进入编辑模式检查引导参数是否正确或者进入rescue模式用grub2-mkconfig重新生成引导配置。如果进入emergency mode先看/etc/fstab有没有挂载项出错——这是最常见的原因。把出问题的挂载行注释掉或修复然后systemctl daemon-reload并mount -a验证。如果是内核模块或驱动问题用journalctl -b -1查看上一次启动的日志确认是哪个模块初始化失败。修复后一定要验证reboot之前先systemctl status查看关键服务状态。这道题要拿高分关键是把“判断依据”写清楚。比如“挂载失败导致emergency mode”的判断依据是启动时最后几行输出出现了类似Failed to mount /data的报错输入root密码后执行journalctl -xb能看到具体的mount失败原因。这比干巴巴说“检查fstab”要有说服力得多。3. 网络专项协议、排障与安全策略缺一不可网络部分在运维笔试中的分量一直很稳定但考察的角度已经从“背概念”转向“会排障、懂安全”。这套卷子的网络题包含了TCP协议细节、DNS解析流程、HTTP状态码语义以及一个完整的网络故障排查场景题。3.1 网络基础题别只背七层模型有一道多选题问的是“TCP三次握手过程中客户端和服务端各自的状态变化”这题看上去简单但错误率很高。因为很多人只记得“三次握手”这个名词不记得状态机的完整迁移路径。正确的状态迁移是这样的客户端CLOSED → SYN_SENT → ESTABLISHED服务端LISTEN → SYN_RCVD → ESTABLISHED如果题目再深入一点问“在第二次握手时服务端做了什么”那就要答出服务端收到SYN后分配传输控制块TCB向客户端回复SYNACK并进入SYN_RCVD状态同时会把这个连接放入半连接队列。关于半连接队列和全连接队列的细节笔试也考到了。ss -lnt可以查看当前监听端口的队列情况如果出现了Recv-Q溢出说明全连接队列已满这通常会表现为客户端连接超时或被重置。生产环境里常见的SYN flood攻击本质就是通过大量伪造SYN请求占满半连接队列导致正常连接无法建立。3.2 故障排查题的答题框架场景题里有一道关于“用户反馈访问某个Web服务非常慢甚至超时”的排查题。这种题目在真实笔试中几乎必出因为网络故障排查是运维的日常核心工作之一。我的答题思路是这样的先分端定位先确认是客户端问题、网络链路问题、还是服务端问题。在客户端curl -w查看连接时间、TTFB时间、总耗时把“慢”拆解成“连接慢”“响应慢”“传输慢”三个阶段。再查DNS解析dig trace或nslookup确认解析耗时如果DNS解析超过几百毫秒可能就是DNS服务器或本地缓存的问题。然后确认TCP连接质量telnet或nc测试端口连通性ping看丢包率和RTT如果跨机房访问还要用mtr看每一跳的延迟定位是哪个节点慢。最后看服务端瓶颈ss -lnt看连接队列top看CPU和内存nginx或应用日志看响应时间分布。重点是回答里要体现出**“分层排查、逐步缩小范围”**的方法论而不是跳到一个可能的根因上就停住。阅卷老师看的是你遇到问题时会不会慌、有没有章法。3.3 安全加固题从防护到纵深网络安全相关的题目在这套卷子里不是简单的概念题而是结合具体场景问加固方案。比如有一题问“公司内部一台Web服务器对外开放你会做哪些基础安全加固”这类题其实是送分题前提是你有实际经验。合理的加固清单应该包括系统层面禁用root远程登录、配置SSH密钥认证禁密码、修改默认SSH端口或配置fail2ban、设置合理密码策略、定期yum/apt更新安全补丁。网络层面防火墙只放行业务端口Web服务用WAF或安全组前置限制管理口的源IP白名单。应用层面Nginx隐藏版本号、配置请求频率限制、设置上传大小限制、日志开启访问日志和错误日志。监控层面配置关键端口的存活监控、系统登录告警、文件完整性校验如aide。这类题拿分的关键是层次感和可操作性。比如“防火墙只放行业务端口”就要具体到iptables -A INPUT -p tcp --dport 443 -j ACCEPT这类规则而不是停留在“配置防火墙”这种空话上。4. 中间件与存储这些基础组件才是笔试重头中间件和存储相关的题目在运维笔试中占比一直很高因为生产环境的故障很大一部分出在MySQL、Redis、消息队列、NFS这类基础组件上。小满这批笔试在这一块出题相当细尤其是MySQL和Redis几乎每个考点都和生产实际紧密挂钩。4.1 MySQL必考面主从、慢查询、备份恢复MySQL相关的题目覆盖了主从复制、慢查询优化、备份恢复三个核心方向。主从复制问了这样一个问题“MySQL主从延迟可能由哪些原因导致如何排查”。我的答题框架是先观察延迟的规模和趋势Seconds_Behind_Master的值是持续增长还是波动用SHOW SLAVE STATUS\G查看Relay_Log_File和Relay_Log_Pos判断SQL线程是否在正常回放。区分网络延迟、IO线程延迟、SQL线程延迟从库IO线程负责拉取binlogSQL线程负责回放。如果IO线程慢通常是主从之间网络带宽或主库binlog生成量过大如果SQL线程慢通常是从库硬件性能不足、大事务回放、或缺少合适的索引。生产上的常见解法大事务拆小、并行复制slave_parallel_workers、从库硬件升配、避免在从库做分析类大查询。定位到具体SQL开启慢查询日志slow_query_log用pt-query-digest分析慢SQL排行找出导致延迟的大事务。慢查询优化的题目考察的是能否快速定位问题SQL。答题时要能说清楚先EXPLAIN看执行计划再看type类型ALL全表扫描是重点怀疑对象、key是否用到索引、rows扫描行数然后针对性加索引或改写SQL。有一道题特别给了个例子“一个订单表查询WHERE status1 AND create_time 2023-01-01数据量上亿如何优化”能答出“建联合索引(status, create_time)”之外还能说出“考虑按时间分表或归档历史数据”的才是能拿高分的答案。备份恢复考的是思路。有个题目是“误删了一张核心表如何恢复”。一个完整的恢复流程是立即停止对该表的所有写入操作防止二次破坏。确认备份策略有没有全量备份binlog日志。如果是物理备份如XtraBackup恢复全量备份到临时实例。根据误删时间点用mysqlbinlog解析binlog找到误删时刻之前的binlog位点。在临时实例上重放binlog到误删前一刻导出表数据再导入线上库。这道题的关键是知道binlog在恢复链路中的位置很多人只答“用备份恢复”完全忽略了binlog回放这一步这在真实误删场景中是不够的。4.2 Redis与消息队列考点集中在“场景选型”Redis相关的题集中在缓存穿透、缓存击穿、缓存雪崩这三个经典问题上而且会组合起来考。缓存穿透查询一个不存在的key请求直接打到DB。解法布隆过滤器拦截、缓存空值并设置短过期时间。缓存击穿某个热点key过期瞬间大量请求打到DB。解法互斥锁重建缓存、逻辑过期、热点key不过期。缓存雪崩大量key在同一时间过期。解法过期时间加随机值、多级缓存、服务降级和限流。我记得有一道场景题是“秒杀活动开始时Redis中商品库存key过期数据库瞬间被压垮如何解决”答题时要把击穿的解决方案完整写出来尤其是互斥锁方案要注意说明“只有第一个请求能拿到锁并重建缓存其他请求等待或直接返回旧值”这个细节。消息队列考的是可靠性和顺序性。比如“如何保证消息不丢失”要分三端回答生产端要确认发送成功同步发送或事务消息服务端要开启持久化消费端要手动ack并做消费幂等。顺序性问题的核心思路是分区/队列内有序、单生产者或保证同一业务key进入同一队列。4.3 存储与文件系统NFS、RAID、磁盘IO存储相关的题不算多但有一道关于“磁盘空间不足但df -h和du -sh结果不一致”的题很有意思。这个现象在运维日常中很常见原因通常是某个大文件被删除但进程还在持有文件句柄空间没有真正释放。正确的排查链路是# 查看已删除但被占用的文件 lsof | grep deleted # 确认是哪个进程持有 lsof L1 # 确认后重启进程或释放句柄这个知识点考察的是对Linux文件系统工作原理的理解删除文件只是断开目录项和inode的关联只要文件仍被某个进程引用磁盘空间就不会真正释放。答出这一层原理比只写lsof | grep deleted更出彩。RAID相关的题考察了RAID5和RAID10的区别与选型。答题的要点是RAID5兼顾空间利用率和容错允许坏一块盘适合大容量存储、读多写少的场景。RAID10安全性最高允许每组坏一块盘写性能更好适合数据库这类对性能和可靠性都有要求的场景。从CPU和IO开销来说RAID5的写操作有校验计算的开销RAID10没有校验计算这是选型时容易被忽略的点。5. 云原生与容器方向从“会用kubectl”到“懂原理”今年这批笔试的云原生题目明显加深了不再只是问“kubectl get pods怎么用”而是直接问“Kubernetes创建一个Pod的完整流程是怎样的”“kubelet是如何调用containerd的”。这其实就是我之前在“想知道Kubernetes是如何调用containerd的从原理到实体调用架”这个话题里聊过的一条完整调用链路。笔试考到这个深度说明招聘方希望运维不只是“能用命令部署应用”而是“理解系统内部的调用关系能真正排查云原生环境下的复杂故障”。5.1 Kubernetes调度与Pod生命周期有一道简答题是“简述从创建Deployment到Pod运行起来的完整过程”。我建议按这条链路来答客户端通过kubectl向API Server发起创建Deployment的请求经过认证、授权、准入控制三个环节。API Server校验通过后将Deployment对象写入etcd并返回结果给客户端。Deployment Controller监听到新的Deployment对象对比期望状态和当前状态创建对应的ReplicaSet。ReplicaSet Controller监听到新的ReplicaSet对象根据副本数创建Pod对象。对于裸Pod跳过这两步Scheduler通过watch机制发现未调度的Podspec.nodeName为空经过预选Predicates和优选Priorities两个阶段选出最合适的节点将绑定结果写回API Server更新Pod的nodeName字段。目标节点上的kubelet watch到Pod被调度到本节点开始执行Pod创建流程。能答到这一步就已经能超过大部分只懂kubectl操作的考生了。5.2 kubelet如何调用containerd一条完整调用链如果题目追问“kubelet是怎么把Pod跑起来的”那就需要把容器运行时的调用机制说清楚kubelet通过CRIContainer Runtime Interface与容器运行时通信。CRI是Kubernetes定义的一套gRPC接口包含RuntimeService管理沙箱和容器生命周期和ImageService管理镜像。当CRI插件是containerd时kubelet作为gRPC客户端通过Unix Socket默认是/run/containerd/containerd.sock连接containerd的CRI服务端。containerd收到请求后内部处理流程是由CRI服务层将请求转换为containerd的命名空间操作通过containerd的task API调用containerd-shim进程。containerd-shim再调用runcrunc通过Linux内核的namespace、cgroups等接口创建和启动容器进程。笔试如果考到这一步最好能画一条简洁的调用链出来用文字也可以kubelet → CRIgRPC→ containerd → containerd-shim → runc → runc通过clone系统调用创建容器进程。另外有一个容易混淆的点要特别注意Pod和容器的关系。Pod运行前会先创建一个pause容器基础设施容器负责持有Pod的网络命名空间和PID命名空间真正的业务容器通过JoinNamespace加入pause容器的网络和PID空间。这也是为什么说“Pod是Kubernetes最小调度单位但底层网络是pause容器撑起来的”。5.3 容器网络与存储的常见考点容器网络考察了CNI插件的调用流程。kubelet创建Pod时会调用CNI插件完成网络配置大致流程是kubelet先创建pause容器然后调用CNI插件如Calico、Flannel为pause容器配置网络命名空间。CNI插件负责创建veth pair一头接入容器网络命名空间另一头接入宿主机网桥或路由。再配置IP地址、路由规则以及网络策略。这道题考的是对“Pod网络是如何打通”的理解。能说清楚veth pair、cni0网桥、以及Calico的BGP模式或IPIP模式的原理基本就能拿满分。存储方向考的是PV/PVC的Provisioning和Attach流程。答题的核心是PV是集群资源PVC是用户请求StorageClass负责动态创建PV最终通过CSI插件完成卷的创建、挂载和格式化。这里要能区分静态供给和动态供给的区别这是生产环境选型的常见考量点。关于生产环境使用StorageClass我认为动态供给是云原生存储的主流方向因为静态PV需要人工预分配存储空间不够灵活而且在有大量有状态应用时管理成本很高。6. 监控、告警与可靠性设计笔试里的“高薪题”监控和可靠性相关的题在这套卷子里非常抢眼占比接近20%。这也反映了运维岗位的核心价值正在从“维护系统稳定”转向“保障业务连续性、提升系统可观测性”。这类题目没有绝对标准答案但答题框架的完整度直接决定分数高低。6.1 监控体系怎么设计才完整有一道简答“如何设计一套完整的监控体系”。很多人的回答是“用PrometheusGrafana监控CPU、内存、磁盘”这只能算入门级回答。一个完整的监控体系应该分四层来答基础设施监控CPU、内存、磁盘、网络、温度等主机指标用node_exporter采集。中间件/应用监控MySQL的QPS/TPS/连接数/慢查询、Redis的命中率/内存/连接数、Nginx的请求量/5xx比例/响应时间以及应用自身的JVM、GC、接口耗时等指标。业务监控订单量、支付成功率、注册转化率、核心接口的可用性这类指标直接反映用户体验是运维和业务沟通时最有力的数据。日志与链路追踪ELK/EFK收集日志SkyWalking或Jaeger做分布式链路追踪用来做故障根因定位和关联分析。在指标采集上推荐用一个四类黄金信号来组织所有指标延迟Latency、流量Traffic、错误Errors、饱和度Saturation。这四类指标能全面反映一个系统的健康状态面试或笔试时说出来会显得非常专业。6.2 告警治理收得多不等于收得好告警相关的题很有特色问的是“生产环境告警风暴频繁怎么治理”。这其实是运维日常最头疼的问题之一答得好非常加分。我的治理框架是先做告警分级P0立即处理如Redis挂了、支付服务不可用、P115分钟内处理如MySQL连接数过高、P22小时内处理如磁盘使用率超过80%、P3记录跟踪如非核心服务的慢查询。再设告警聚合和抑制Prometheus的group_by参数可以聚合同一类告警inhibit_rules可以抑制衍生告警比如主机宕机时不需要同时收到该主机上所有服务的告警。然后做告警去重同一个根因触发的多条告警应该合并成一条这需要在告警规则里设置合理的keep_firing_for。最后是告警闭环告警必须有确认、处理、恢复、复盘四个环节每次故障后要review告警规则的准确率删除无效告警。这类题的回答核心是体现出你有过“告警疲劳”的真实体验并形成了方法论而不是单纯堆概念。6.3 容量与高可用设计的答题框架场景分析题里有一道容量评估题“线上业务流量预估会翻倍你如何评估现有系统容量并制定扩容方案”。我的答题框架是先摸清当前水位找出现在最忙时段各核心组件的峰值使用率CPU、内存、磁盘IO、网络带宽。再找瓶颈点容量翻倍时先撑不住的一定是短板可能是单台数据库的连接数、Redis的内存上限、Nginx的并发连接数、或某个微服务的线程池大小。做容量估算以“当前峰值*2”为目标算出每个组件需要扩到多少。比如当前单台Nginx峰值并发5000翻倍后需要1万并发那可以加一台同样规格的节点做负载均衡或单机调优调大worker_connections、开启keepalive。最后考虑弹性云环境可以配置HPAHorizontal Pod Autoscaler或云资源的Auto Scaling但要注意HPA扩容有延迟不适合突发流量突发场景要用提前扩容或抢占式实例兜底。高可用方案设计题则是问“设计一个高可用的Web应用架构”这种题要覆盖前端负载均衡SLB/NginxKeepalived、应用层多副本、数据库主从或高可用集群、缓存集群、对象存储、以及故障自动切换机制。能画出架构图当然最好纯文字描述也可以但一定要点出每个单点都有冗余、每个故障都有自动恢复路径。7. 运维规划与项目描述题这类主观题最拉分第二批笔试里有两类主观题特别值得单独拿出来聊一类是“如何从零搭建一套生产系统并做好后续维护”另一类是“在项目总结时如何描述自己的运维工作”。这两道题非常符合“热搜词运维在项目总结时应该如何去描述项目”的关注点也是不少有经验但不会表达的运维容易丢分的地方。7.1 从零搭建一套生产系统怎么答才不空这道题考察的不是“你会装什么软件”而是有没有完整的运维体系思维。高分的答题框架应该包含以下层面需求分析阶段明确业务规模、并发量预估、数据量级、可用性要求是99.9%还是99.99%这会直接决定架构选型和预算。架构设计阶段网络规划VPC/子网/安全组、应用架构单体还是微服务、存储选型关系型/缓存/对象存储、容灾设计同城双活还是异地多活。部署落地阶段标准化操作系统镜像、统一配置管理Ansible/SaltStack、CI/CD流水线、基础设施即代码Terraform。监控与巡检阶段部署PrometheusGrafana、日志采集、核心指标看板、周期性巡检脚本。安全加固阶段系统基线、堡垒机、权限审计、漏洞扫描和修复。演练与迭代阶段故障演练混沌工程、备份恢复演练、容量压测、架构持续优化。这个回答的亮点在于把运维从“交付即结束”提升到了“持续运营”的高度体现出对运维体系化、平台化的理解。如果时间宽裕还可以补充“每个阶段的交付物”和“质量指标”比如部署阶段要输出部署文档、配置基线、回滚方案监控阶段要输出SLO和告警规则。7.2 项目总结怎么说才有亮点项目描述题如果写得很“流水账”比如“负责服务器维护、部署应用、处理故障”那基本就是中低分。我在实际面过很多运维候选人之后发现能把项目讲出价值的人通常都会用“问题-方案-结果”三步法第一步用一句话交代项目的业务背景和规模比如“这是一个日活50万的电商平台核心链路涉及Nginx、Spring Cloud微服务、MySQL集群”。第二步挑1到2个你主导或深度参与的核心事件重点讲你遇到的问题、你的排查过程、你的解决方案。比如“618大促前压测发现网关成为瓶颈我通过调整内核参数、优化Nginx配置、增加限流策略将网关吞吐量提升了40%”。第三步用可量化的结果收尾不要只写“提升了稳定性”要写“将可用性从99.9%提升到99.99%”“将告警数量从每天300条降到30条”这类有数据支撑的成果。在笔试里遇到这种题目我建议用“STAR法则”来组织回答内容同时控制篇幅背景背景简短说任务目标说清楚行动步骤详细写结果结果用数据。这一套模板在面试中同样适用提前练习对后续面试也很有帮助。8. 桌面运维与面试衔接笔试之外的隐形分虽然小满是技术类岗位的笔试但卷子里还有一些考察基础运维素养的题目其中包括桌面运维的常见问题处理以及个人对运维职业的理解。这类题分值不高但答好了能给阅卷人留下“综合素质不错”的印象。8.1 桌面运维常见问题处理思路有一道题问“员工电脑无法上网你怎么远程协助排查”。这道题不算难但需要有一条完整的排查链路先确认影响范围是个别电脑还是整个办公室都无法上网这决定了问题是在终端侧、接入侧还是出口侧。检查物理层和链路层网线是否松动、Wi-Fi是否连接、交换机端口指示灯状态、获取到的IP地址是否正确。检查网络层ping网关测连通性ipconfig或nmcli看IP配置检查是否有静态IP冲突或DHCP分配异常。检查DNS和应用层ping公网IP如223.5.5.5确认基础连通性再nslookup测试域名解析是否正常。最后检查安全软件和代理很多“无法上网”其实是防火墙拦截或代理配置异常。这类题的答题重点是养成从底向上、逐层排查的思维习惯这在任何规模的网络故障排查中都是通用的。8.2 从笔试到面试几个可以提前准备的方向笔试结束后通过初筛的候选人大概率会在面试里被追问如下几类问题我可以提前给点方向手写核心命令和脚本比如“写一个shell脚本监控Nginx进程挂了自动拉起”这需要掌握while循环、if判断、crontab或systemd timer的基本用法。深挖Kubernetes和容器的底层原理我在这篇文章里讲的kubelet→containerd→runc调用链建议能在面试中用自己的话流畅讲出来并且能配合一个实际故障场景说明这个知识怎么用。最近做过的故障复盘强烈建议准备一个结构清晰的故障复盘案例模板包含故障现象、发现方式、排查过程、根因分析、恢复动作、预防措施。这是面试官最看重的“实战证据”。字节跳动的运维面试经常问“讲一个你印象最深的故障案例”如果没有提前准备很容易因为细节混乱而失分。我见过不少候选人技术功底不差但一讲故障就东扯一句西扯一句最后面试官抓不住重点。提前把复盘案例做成结构化文档在面试中就能做到逻辑清晰、言之有物。9. 最后再分享一个备考方法用场景题反向驱动学习复盘完这套笔试我觉得最有价值的不是去背具体的题目和答案而是总结一套**“以场景题为锚点、反向补齐知识体系”**的备考方法。我的具体做法是这样的拿到每一道场景题先不着急看答案而是自己尝试写完整的排查链路和方案设计。写完再跟资料或同事的答案对比看自己漏掉了哪一层、哪一步。比如这次笔试考到的“MySQL主从延迟排查”“Kubernetes创建Pod的完整流程”我在日常工作中其实都遇到过但如果没有刻意把这些经验结构化地写出来临场答题很可能就只有“用过”的印象而写不出体系化的答案。还有一个很实用的技巧每个知识点都要能回答三个层次的问题——是什么概念定义、为什么原理机制、怎么办故障场景下如何排查和解决。比如“Linux负载高”这个知识点三个层次分别是负载是什么运行队列中进程数的平均值、为什么负载会高CPU密集、IO等待、不可中断进程堆积、负载高怎么排查top、vmstat、pidstat、iotop、dmesg的组合排查链路。这个方法论用来备考运维笔试和面试都非常高效因为这恰好就是出题人考察的逻辑。最后说一句肺腑之言运维笔试的题目无论怎么变考察的核心始终是**“在复杂环境下定位问题、在压力下恢复系统、在事后推动改进”**这套能力。这套能力不是靠刷题刷出来的而是靠一次次真实操作积累出来的。如果你还在准备阶段多动手、多复盘、多把经验提炼成方法论这比刷一百套题都管用。
