每年秋招季总有一批想做运维的同学盯着大厂的业务运维岗。腾讯音乐的秋招笔试尤其“第一批”这个节点往往最能反映岗位的真实技术要求——它不会跟你客气也不存在“试试水”的侥幸空间。我当年带团队招人时看过不少份运维笔试答卷也和参与出题的同事聊过“什么答案能拿高分”。一个很扎心的结论是笔试淘汰的人绝大多数不是栽在“不会做难题”而是栽在“基础不牢却自以为牢”。腾讯音乐的业务运维岗笔试核心套路不是考偏题怪题而是把日常工作中的高频场景浓缩成题看你有没有真正动手解决过问题。这篇文章我以腾讯音乐秋招业务运维岗第一批笔试为引子把这几年运维岗笔试里高度重合的考点、容易踩的坑、以及备考思路都拆开讲清楚。不管你目标是腾讯音乐还是其他大厂只要你投的是业务运维/SRE方向这篇内容应该能帮你少走几周弯路。1. 业务运维笔试到底在考什么1.1 业务运维与传统运维的分界很多同学对运维的认知还停留在“服务器坏了去修、系统慢了去重启”的阶段。但业务运维有时也叫应用运维、SRE方向完全不是这个定位。它更接近“系统的最终负责人”——从代码上线前的容量预估到发布过程中的灰度策略再到上线后持续的性能观测和故障止损整条链路里运维的身影无处不在。这种定位直接反映在笔试题型选择上。你会看到大量题目围绕“某个业务服务出现接口超时”“数据库连接数被打满”“线上流量突增”这类具体场景展开。出题人并非想为难你而是想通过这些问题筛选出真正有“生产环境体感”的人。所谓体感就是你踩过线上故障的坑知道排查思路是什么知道哪些命令应急时最优先敲。没有这种体感背再多面试题遇到换了壳的场景题一样会露馅。所以准备笔试前先在心里完成一个角色转变你不再是“会修电脑的人”而是“能对业务连续性负责的人”。这个心态决定了你后续所有复习的优先级。1.2 笔试考察的四层能力模型从历年各家大厂运维笔试的题目分布看可以把考点整理成四个递进层次业务运维岗尤其吃这套模型第一层基础技术能力。包括Linux系统原理与常用命令、网络协议基础TCP/IP、HTTP、DNS、Shell/Python脚本编写能力。这一层是地基占笔试分值通常超过40%。第二层中间件与存储。高频对象包括Nginx、MySQL、Redis、Kafka/RabbitMQ。考察点不只是“会不会配置”而是“知不知道它们在生产环境里的常见故障和应对手段”。第三层容器与云原生。Docker基础操作、Kubernetes核心概念Pod、Deployment、Service、Prometheus监控体系。现在业务运维如果完全不懂容器基本等于半个文盲。第四层稳定性与业务思维。容量规划、故障复盘、SLO制定、成本优化。这一层不会单独出题但经常融进场景题和压轴大题里。这四层不是并列关系而是递进关系。你如果第一层不扎实后面三层会连题都读不懂。反过来说如果你前面三层都能稳扎稳打那最后一道综合场景题即使不能拿满分也能通过清晰的答题框架拿到大部分分数。2. Linux与网络基础笔试的基本盘2.1 Linux高频考点与易错细节Linux相关题目在运维笔试里占比最大但也是最容易失分的地方。失分原因往往不是题目难而是审题不细、命令记混、忽略边界条件。高频考点集中在几块一是文件系统与磁盘管理比如inode耗尽是否会导致磁盘无法写入、df和du的区别及各自适用场景二是进程与性能排查比如怎么找到CPU占用最高的线程、load average怎么解读、上下文切换过高说明什么三是权限与安全比如SUID/SGID位的作用、sudo配置的语法规则、防火墙规则对业务的影响。我给你们几个最值得深挖的命令场景笔试和面试都反复出现处理文本。awk、sed、grep这三件套是必考内容尤其awk的常用内建变量NR、NF、FS和常见动作print、sum、if判断。别只背语法要能现场写出“统计nginx日志中每个IP的访问次数并排序”这类题。定位问题。排查CPU高占用时正确的链路是top找到高CPU的PID再用ps -Lp观察线程之后用gdb或jstackJava业务或perf进一步定位。如果只会top就只答了一半。应急处理。磁盘写满但空间没满大概率是inode耗尽服务端口起不来先看端口是不是被占用、再看防火墙规则、再看listen backlog。这类排障思路比单个命令更重要。提示笔试中写命令时务必把参数写准确。比如“查看系统负载”应该是uptime而不是toptop也可以但不是最优解。出题人阅卷时会看你是不是“懂行的运维”。2.2 网络协议与排障思路网络是业务运维笔试的重灾区因为很多同学对网络的理解停留在八股层面——三次握手四次挥手背得滚瓜烂熟但一遇到“线上接口偶尔超时”就不知道从哪查起。笔试中高频出现的网络题目包括TCP三次握手和四次挥手的状态迁移尤其TIME_WAIT和CLOSE_WAIT的区别及产生原因、HTTP状态码语义502和504分别代表什么、和网关的关系、DNS解析的完整流程浏览器缓存、系统缓存、hosts、LDNS、根服务器迭代查询、负载均衡的常见算法轮询、加权轮询、最少连接、一致性哈希。这里我要特别强调TIME_WAIT和CLOSE_WAIT。这两个状态是运维笔试的“钉子户”几乎每次都能碰到。TIME_WAIT过多通常出现在高并发短连接场景解决办法是开启tcp_tw_reuse注意Linux 4.12之后内核已移除tcp_tw_recycle、调整MSL时间或改用长连接。CLOSE_WAIT过多则往往说明应用代码里没有正确关闭连接是程序侧问题改内核参数治标不治本。能分清这两者的区别就已经比百分之六七十的考生强了。还有一个实战排障思路值得专门准备当服务出现“偶发超时”时排查顺序一般是从客户端视角出发先确认是DNS解析慢还是TCP建连慢再确认是后端处理慢还是网络丢包重传最后再判断是应用线程阻塞还是DB慢查询拖累。这种链路式排查思维笔试的场景题特别爱考。3. 脚本、中间件与数据库的核心考点3.1 Shell与Python脚本能力怎么练脚本题在各家运维笔试里几乎占15%到20%的分值。出题形式通常是“用你熟悉的语言实现某个日志分析或自动化操作的逻辑”。腾讯音乐这类业务运维岗对脚本能力的要求是“拿来就能用”不是“懂一点语法”。Shell脚本的备考重点建议放在三块变量与参数传递$?、$#、$这些特殊变量必须烂熟、条件判断与循环文件判断、字符串比较、for循环处理批量任务、文本处理三件套的灵活组合。不需要背很偏的语法但常用场景必须能手写。比如“写一个脚本监控某个进程是否存在不存在则拉起并记录日志”这种题几乎逢考必出。Python的备考重点是字符串处理与正则表达式、文件读写、subprocess调用系统命令、requests做HTTP接口测试、以及基本的异常处理。我建议准备一个自己写过的完整脚本作为“武器库”比如一个日志清洗脚本或一个批量巡检脚本。笔试真出到编程题时能快速复用自己熟悉的结构比现场从零想快得多。另外提醒一句脚本题里千万别犯低级错误比如变量名拼错、忘记给脚本加可执行权限、逻辑里漏掉“文件不存在”的边界判断。笔试虽然没有真实环境让你执行但阅卷人一眼就能看出你写的东西有没有跑过生产环境。3.2 MySQL与Redis的实战考察数据库相关的题目业务运维岗考察的重点和DBA不同。DBA看重参数调优和底层原理业务运维更看重“业务出问题时怎么快速定位数据库相关的瓶颈”。所以你会发现笔试里的MySQL题目集中在以下几类索引失效场景。哪些写法会导致索引失效对索引列使用函数、隐式类型转换、前导模糊匹配以及explain输出里type和key字段怎么解读。慢查询排查。怎么开启慢查询日志怎么看慢SQL的执行计划常见的优化手段加索引、改写SQL、分页优化、避免select *。主从同步延迟。主从延迟产生的原因从库单线程回放、大事务、DDL锁表常见的缓解手段并行复制、拆分大事务、读写分离策略调整。连接数异常。连接数被打满时怎么快速处理是先kill掉空闲连接还是直接重启数据库以及如何通过连接池配置避免雪崩。Redis在笔试中的出现频率同样很高。核心考点包括缓存穿透、缓存击穿、缓存雪崩的区别和解决方案这组概念一定要分清很多人背了答案还是混淆、Redis的持久化机制RDB和AOF的优缺点及适用场景、内存淘汰策略、分布式锁的实现方式。特别提示一个高频坑缓存穿透是指请求一个不存在的数据导致每次都要查数据库缓存击穿是指某个热点key在过期瞬间大量请求直接打到数据库缓存雪崩是指大量key同时过期导致数据库压力陡增。三个概念听起来很像但解决方案完全不同——穿透常用布隆过滤器或缓存空值击穿常用互斥锁或逻辑过期雪崩常用过期时间加随机值或热点数据不过期。3.3 消息队列与Nginx的关键知识点中间件部分消息队列和Nginx基本是笔试的常客。消息队列的考察方向集中在Kafka的架构组成Producer、Broker、Consumer Group、Topic、Partition之间的关系、消息不丢失的保证机制生产者acks机制、broker端副本机制、消费者手动提交offset、消息重复消费的处理思路幂等性设计、消息积压的排查思路consumer是否挂掉、消费逻辑是否太慢、分区分配是否均匀。Nginx更偏实战配置。高频题目包括Nginx的反向代理和负载均衡配置upstream里的server指令、weight参数、keepalive配置、location匹配规则的优先级 精确匹配 ^~ 前缀匹配 正则匹配 普通前缀匹配、动静分离的配置方式、以及常见的Nginx报错排查502 Bad Gateway、504 Gateway Timeout分别怎么查。Nginx的502和504排查是我建议每个人都提前整理的。502通常是后端服务挂了或FastCGI进程异常重点排查后端进程健康状态和连接数504通常是后端处理超时重点排查proxy_read_timeout配置和后端响应时间。答题时能给出“先看什么、再看什么”的阶梯式排查思路比只背一个答案得分高得多。4. 容器、云原生与监控体系的考查趋势4.1 Docker与Kubernetes笔试的“新宠”近两年运维笔试最大的变化就是容器和Kubernetes的题目占比明显提升。以前只是加分项现在基本成为必考项。腾讯音乐业务运维岗的JD里容器相关经验也写得很明确。Docker部分的考点相对基础镜像与容器的关系、Dockerfile常用指令FROM、RUN、CMD、ENTRYPOINT的区别和坑、数据卷volume与bind mount的使用场景、容器网络模式bridge、host、none的区别。高频面试题“CMD和ENTRYPOINT有什么区别”在笔试里也常出务必把“CMD可以被docker run参数覆盖ENTRYPOINT默认不会被覆盖”这个核心区别答清楚。Kubernetes的考点就深很多了。先说高频概念题Pod的生命周期Pending、Running、Succeeded、Failed、Unknown、Deployment的滚动更新策略maxUnavailable和maxSurge参数含义、Service的ClusterIP和NodePort的区别、ConfigMap和Secret的使用场景。再说场景题。我见过一道很有代表性的题目一个Pod一直处于ContainerCreating状态你怎么排查标准思路是先describe pod看事件通常能看到镜像拉取失败、存储卷挂载失败或网络插件异常然后根据具体事件挨个处理。能把排查链路写出来的人说明真的在测试环境或生产环境里碰过类似问题。还有一道高频题如何实现金丝雀发布或蓝绿发布。这两个概念不仅是运维知识更是业务稳定性建设的核心手段。金丝雀发布的核心是“先让少量流量验证新版本确认无问题再全量”蓝绿发布的核心是“准备两套环境一次性切换流量”。笔试中要求说出实现思路和优缺点踩分点就在“你能否说出它们解决的业务问题”。4.2 监控与告警Prometheus的统治地位监控体系是业务运维的安身立命之本。笔试里监控相关的题目已经从“Zabbix怎么配”全面转向“Prometheus怎么用”“告警怎么设计”。Prometheus的核心考点数据模型metric名称、label标签、时间序列、四种指标类型Counter、Gauge、Histogram、Summary以及它们各自的适用场景、PromQL的基础查询语法rate、increase、sum by、topk、以及和Grafana配合展示的基本逻辑。告警设计的考点更有意思。题目可能会问“线上某个接口的P99延迟突然升高你会设置什么告警规则”。有些同学只会说“设置一个阈值告警”这是不够的。高分答案应该是分层的先设置基础的延迟阈值告警比如P99大于500ms告警还要加上趋势告警比如相比过去15分钟上涨50%告警以及多维度聚合告警按接口、按集群、按机房维度分别观测同时要考虑告警降噪避免一大波同质告警把值班人淹没。监控部分我额外提醒一个容易忽略的点除了系统和业务的监控指标日志监控同样是大厂笔试会涉及的内容。ELK/EFK技术栈的概念Elasticsearch、Logstash/Fluentd、Kibana、以及基于日志的异常检测思路比如日志中出现大量5xx错误时如何通过关键字聚合告警都建议提前准备一些。5. 笔试真题风格分析与答题技巧5.1 场景题的答题框架大厂运维笔试中最能让考生拉开差距的就是场景题。这类题目通常没有标准答案考察的是系统性思维和排查经验。我给你们一套百试百灵的答题框架第一步定位问题边界。先弄清楚问题发生在哪个层次是客户端/网络层/接入层/应用层/数据层。把问题缩小到具体层次后续排查才有方向。比如“用户反馈页面打开很慢”先通过浏览器的Network面板判断是等待响应时间长还是下载资源慢。第二步从最可能的原因入手。根据经验先排查概率最高的因素。服务刚发布过的优先看变更流量突增的优先看扩容和限流数据库压力大的优先看慢查询和连接数。第三步分层排查并用数据佐证。给出每个层次的具体排查命令和指标网络层看ping和traceroute接入层看Nginx访问日志和错误码应用层看线程栈和GC日志数据层看慢查询和连接数。第四步给出临时止损和根治方案。面试官最爱看的不是你会不会修而是你有没有“先止损再根治”的意识。比如数据库被打满先杀掉问题SQL或切读流量到从库止损再分析慢SQL并优化索引。这个顺序至关重要。这套框架不仅能用于笔试你入职后处理真实故障也是这么干的。现在把它固定在答题思路上一举两得。5.2 选择题与判断题的避坑要点笔试前半部分通常是选择和判断题很多同学觉得“简单就随便选”结果在这部分丢了不少分。根据我看到的答卷情况我总结几个高频失分点一是命令和参数混淆。比如统计监听端口用什么命令最准确ss比netstat更推荐查进程用什么参数ps -ef和ps aux的区别这些细节虽然不影响结果但能体现专业度。二是“最优解”选择问题。有些题目的选项里有两个都是“可行方案”但只有一个是最优解。比如“查看某个端口是否被占用”用telnet、nc、ss都能测但如果题目限定场景是高性能服务器ss是最优选择因为netstat遍历/proc文件系统在高fd数时较慢。三是概念细节的混淆。比如“同步”和“异步”在消息队列里的准确含义、“阻塞”和“非阻塞”的区别、软链接和硬链接的核心差异inode层面等。这些概念题不需要死记硬背理解之后自然能选对。我建议大家做题时养成一个习惯对拿不准的选项先在草稿纸上画出该技术的工作原理图再用图去验证选项是否正确。这比凭感觉猜要稳定得多。5.3 简答题踩分点答得“像运维”而不是“像学生”简答题是笔试的另一个拉分项。很多同学在简答题上犯的一个通病是答得像教科书不像运维。比如“什么是反向代理”学生式回答是“反向代理是指代理服务器接受客户端的请求然后转发给内部网络上的服务器”运维式回答应该是“反向代理对客户端暴露统一入口隐藏后端服务器细节同时承担负载均衡、SSL卸载、缓存、限流等职责Nginx就是最常用的反向代理组件之一”。看出区别了吗运维式回答会带上“解决什么问题”“生产环境里怎么用”“和哪些组件配合”。出题人希望看到的是你在实际工作场景中理解技术而不是在书本里理解技术。简答题如果遇到不会的也尽量不要留白。把自己理解的部分写出来就算答案不完全正确踩到部分知识点也能拿分。运维这行最忌讳的就是“什么都不干等着别人处理”笔试也是——哪怕不确定答案也要写出自己的分析和判断。6. 备考路线与项目经验准备6.1 三个月高效备考计划聊了这么多考点最后落到实操如果离笔试还有两三个月怎么安排时间最合理第一个月打地基。把Linux系统管理、网络基础、Shell/Python脚本这三块过一遍。不是看书是动手。建议搭一台虚拟机或买个便宜的云服务器每天做一些系统配置和排障练习。比如今天模拟inode耗尽明天模拟端口冲突后天写一个自动化部署脚本。这一阶段的目标是“常用命令不查文档就能写”。第二个月攻中间件。集中精力把Nginx、MySQL、Redis、Kafka各过一遍。每个组件都要装一遍、配一遍、压一遍、造故障修一遍。比如把MySQL装好用sysbench压测再人为干掉一个节点看主从怎么切换把Redis部署好测试RDB和AOF的恢复流程。中间件只有亲手折腾过笔试里的场景题才有画面感。第三个月上难度、刷真题。重点转向容器、Kubernetes、监控体系以及综合场景题的答题训练。同时开始收集各家大厂的运维笔试真题定时模拟练习。这一阶段尤其要注意总结自己的“答题模板”——比如场景题的四步框架、故障排查的标准链路、告警设计的规范思路。有模板在手考场上答题速度和完整性都会强很多。6.2 项目经验怎么转换成笔试优势大厂笔试虽然不看简历但你在准备项目经验时积累的深度理解会直接转化为笔试答题的高度。运维相关的项目经验不一定非得是“公司线上项目”。我自己见过不少应届生没有实习经历但自己搭了一套完整的环境GitLab Jenkins Docker Kubernetes Prometheus Grafana把一套应用从代码提交、自动构建、镜像打包、滚动发布、监控告警整个链路跑通了。这就是一个非常有说服力的项目因为里面涉及的所有组件恰恰都是笔试的高频考点。你在梳理项目经验时建议按“业务背景、系统架构、自己负责的模块、踩过的坑、优化成果”这个结构来准备。尤其要深挖“踩过的坑”。笔试里所有场景题的原型本质上都是真实环境里有人踩过坑。你如果自己真的踩过答题时就能写出那种“经历过才会有”的从容感。6.3 从笔试到面试的衔接点最后说一句容易被忽略的话笔试不是独立关卡笔试考察的知识点几乎都会被面试官拿着追问。你笔试里写的每一个答案面试都可能被要求“展开讲讲”或“现场演示一下”。所以笔试过程中那些“蒙对的题”“猜对的题”考完一定要立刻复盘把它彻底变成自己的知识。我见过太多候选人笔试成绩不错面试聊到某个考点却支支吾吾——这种情况比笔试没过还可惜因为面试官会觉得“你的笔试有水分”印象分直接拉低。我自己的经验是每次笔试结束后趁记忆还热把全部题目按“完全掌握、部分掌握、完全不会”三类复盘一遍。完全不会的部分立刻查资料补课并做一次实际操作验证。这样每参加一次笔试你的技术深度就会实实在在地往上走一截而不是永远在原地打转。