2023年腾讯音乐春招业务运维开发岗第二批笔试的通知下来时，我其实有点意外。因为第一批笔试刚结束没多久，网上能搜到的信息有限，大家都还在猜这个岗位到底考什么。我也算临时抱佛脚，把Linux命令、Python脚本、网络基础这些翻了一遍，然后硬着头皮上了考场。考完复盘的时候发现，这场笔试跟我之前做过的后端开发笔试完全不是一个风格，它更贴近一个真实运维同学每天会面对的故障场景、排查思路和自动化效率问题。
如果你也是奔着运维开发方向去的，这篇文章值得你花十分钟认真看。我会把这次笔试的题型构成、核心考点、我觉得有价值的答题思路，以及考后总结出的经验教训，完整梳理一遍。不保证题目一字不差，但考察方向和技术边界我是记得比较清楚的，希望能帮你少走点弯路。
1. 这是一场什么样的笔试：运维开发岗位的考察逻辑
先说个很多人容易误解的事儿。运维开发这岗位，名字里带“开发”，但笔试考的绝不只是写代码。它真正想筛的人，是“会用代码解决运维问题”的人。这和后端开发、客户端开发笔试有本质区别。
1.1 运维开发与后端开发的笔试差异
后端笔试喜欢考算法题、数据结构、系统设计，核心是考察你的代码功底和架构思维。运维开发笔试则更“接地气”：它考察的是当你面对一台告警不断的服务器、一个疯狂报错的服务、一份需要定期维护的脚本时，能不能快速反应过来问题在哪、该怎么处理、怎么用脚本把这件重复的事自动化掉。
我印象很深的一点是，这场笔试题里几乎没有那种需要状态压缩的DP题，也没有复杂的图论。取而代之的是大量围绕Linux操作、网络排查、文本处理、脚本逻辑展开的题目。这不是说算法不重要，而是说在这类岗位的筛选逻辑里，“能干活”的优先级高于“会刷题”。
1.2 从岗位JD反推考点：腾讯音乐的业务形态决定了什么
腾讯音乐旗下产品覆盖在线音乐、直播、K歌等场景，用户量级大，服务链路长。业务运维开发同学日常要面对的，大概率是海量服务实例的稳定性保障、监控告警体系的搭建、发布变更的效率提升、成本优化等硬核问题。
这就决定了笔试会特别关注几个方向：
- Linux 基本功：日志排查、进程管理、磁盘网络分析，这是运维的生存技能
- 网络排查能力：TCP状态、连接队列、DNS解析、HTTP排错，在线服务问题大多出在链路上
- 脚本与自动化思维：Shell、Python、文本处理、定时任务，像awk处理日志、sed批量改配置这类内容，直接对应日常重复工作的提效
- 数据库与缓存常识：慢查询优化、索引失效场景、Redis缓存击穿，这些是服务性能问题的重灾区
- 故障应急处理：给你一个故障场景，看你能不能形成完整的排查->定位->止损->复盘链路
1.3 考前准备情况复盘
说实话，我第一批笔试前刷了不少常规的“大厂笔试真题”，主要练的都是后端那套。后来发现笔试通知里写了“业务运维开发方向”，赶紧调整了复习重心，把Linux常用命令、TCP/IP状态机、MySQL慢查询和Shell处理文本的常用方法重点过了一遍。
现在回头看，这个调整很关键。如果我继续按后端开发的标准去准备，大概率会在场景题和命令行题上卡壳。所以如果你也在准备类似岗位，第一件事是先搞清楚岗位笔试的底层逻辑，再去决定复习什么。
2. 线上笔试全流程回顾：从设备调试到交卷
线上笔试和线下笔试体验差别挺大，尤其是双机位监控这类要求，很容易让第一次参加的同学手忙脚乱。这块虽然不算技术考点，但要是没弄好，直接影响心态和答题节奏。
2.1 笔试平台与双机位监控的注意细节
这次用的笔试系统支持在线编程和客观题，整体流程跟大多数大厂的线上笔试类似，需要提前装好对应的浏览器插件。通知里明确要求双机位监控，也就是说除了电脑摄像头，还需要用手机从侧后方拍摄桌面和双手。
有几个细节我提醒大家注意：
- 提前半小时进入房间调试摄像头、麦克风和屏幕共享权限，别等开考了才发现摄像头打不开
- 手机机位要保证能拍到桌面和屏幕，最好用手机支架固定在侧后方45度的位置
- 笔试过程中系统可能会随机切屏检测，开考后一定不要切出去查资料，任何被认为是异常的切屏记录都可能影响成绩
- 环境要安静，光线要充足，不然人脸识别那关可能反复失败
2.2 题型分布与分数占比
从我这场的体验来看，题型大致分为了三块。
| 题型 | 大致题量 | 考察重点 |
|---|---|---|
| 单选题 | 20道左右 | Linux命令、网络协议、数据库基础、监控原理 |
| 编程题 | 2道左右 | 文本处理、数据统计、小规模算法应用 |
| 场景/简答 | 2道左右 | 故障排查思路、脚本设计思路、架构方案设计 |
单选部分覆盖面很宽，考察你对基础知识的掌握是否扎实；编程题则是给一个明确的输入输出要求，用你自己熟悉的语言实现；场景题给的背景通常很贴近真实生产环境，考察核心是你遇到问题时的处理链路是否完整。
2.3 时间分配方案
我记得整场笔试的总时长是120分钟，题量看起来不算大，但实际坐下来会发现时间还是挺紧的。单选如果纠结太久，后面编程题和场景题就很容易没时间写。
我自己的分配方案是：
- 单选和填空题控制在50分钟以内，遇到拿不准的先标记，不恋战
- 编程题留40分钟，先读清楚输入输出约束，再动手写，宁可多写几个边界用例验证
- 场景题留25分钟，这类题不需要写完整代码，但要把流程、命令、关键参数写详细
- 最后留5分钟检查客观题有没有漏选
这个节奏对我来说是合适的。如果你对编程题比较有把握，可以适当压缩单选时间，把精力集中在能充分展示能力的大题上。
3. 核心考点逐题拆解：那些能写进简历的硬技能
接下来这部分是重点，我把笔试中出现的、和运维开发强相关的核心考点分类拆一下。这些内容不只是为了过笔试，实际干这行也天天用得到。
3.1 Linux 命令排查：从输出反推故障原因
单选里有一类题，直接给你一段命令输出截图，问你机器发生了什么问题。这块真的很吃功底，因为它的答案不在字面上，而在于你能不能从输出中反推出系统当前的故障状态。
比如磁盘满的场景，常见的现象是应用日志写不进去、服务频繁重启。考卷可能会给你：
/dev/vda1 40G 39G 1.6G 99% /从这个输出你能得到什么？首先是磁盘使用率已经达到99%，这意味着线上服务可能随时因为无法写日志而异常退出。那么正确的处理顺序应该是：先用df -h确认是哪个分区满了，再用du -sh /var/log/*或du -sh /home/*这样的命令逐层找大文件，最后再决定是清理日志还是扩容。
而如果你的排查路径是直接rm -rf /var/log，那肯定是错的——日志目录被删可能导致正在写日志的进程句柄异常，再叠加磁盘空间不释放的问题，完全是火上浇油。
还有一类是CPU问题的排查：
top - 11:23:01 up 23 days, 2:15, 1 user, load average: 8.30, 7.50, 6.20负载偏高，看完top后下一步应该怎么做？通过top定位到CPU占用最高的进程PID，然后用top -Hp PID或ps -Lp PID看这个进程内部的线程占用，再用jstack或gdb去分析这个线程在干什么。这个排查链路反映的是你懂不懂“先粗粒度定位，再细粒度分析”的排查思路。
这类题考的不是你会不会敲命令，而是你会不会把多条命令串成一套解决问题的动作。这也是我觉得运维开发笔试最值得琢磨的地方。
3.2 计算机网络：不只是八股，要能算能推
网络部分的题目，则围绕TCP状态、HTTP状态码、DNS解析链路这些内容。看起来像八股，但实际是做服务排查的必备基础。
举个印象很深的例子，题目给你一条ss -lntp的输出：
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 511 128 0.0.0.0:8080 0.0.0.0:*它问的是：当这台机器的8080端口出现大量连接堆积时，Recv-Q和Send-Q分别代表什么状态？如果你不理解TCP接收队列和发送队列的意义，就很难答对。
在真实的运维场景里，Recv-Q数值持续增长通常意味着应用层来不及处理请求，这时候要重点看应用线程池是否被打满、GC是否频繁。而Send-Q持续增长则可能是对端处理不过来，需要进一步查下游服务的状态。
另外，HTTP状态码也要会分类去看。5xx是服务端问题，502是网关拿到无效响应，504是网关超时，503是服务不可用，这几种状态码对应的排查方向完全不同。笔试不会直接问你“502是什么含义”，而是会给一个场景让你判断是哪个环节出了问题。
3.3 数据库与缓存：业务场景下的方案设计
数据库部分考得不算深，但对日常运维来说非常实用。它重点考察的是慢查询的定位和优化思路，以及索引失效的常见场景。
慢查询题一般长这样：给你一个慢查询日志片段，或者给你一条带有WHERE status = 1 AND created_at > '2023-03-01'的SQL，让你分析为什么慢，怎么优化。这时候你要能说出：
- 先看
explain的执行计划，确认是type为ALL的全表扫描，还是rows估算过大 - 检查联合索引字段顺序是不是符合最左前缀原则
- 考虑是否因为
created_at字段上有函数操作，导致索引无法生效
场景题里，索引失效的典型例子基本绕不开“在索引列上使用函数”“隐式类型转换”“LIKE左模糊匹配”这几种情况。因为它们在真实业务里发生率最高，也最影响数据库性能。
Redis缓存相关的题目，重点则是围绕缓存击穿、缓存穿透、缓存雪崩这三个概念，以及对应的处理方案。别只背概念，笔试更希望看到的是你给出的处理手段合理、能落地，比如用互斥锁重建缓存、布隆过滤器拦截穿透请求、随机过期时间分散雪崩压力等。
3.4 编程题：面向运维场景的应用题
编程题比我想象中朴实很多，不需要太花哨的算法。它更贴近日常运维开发里最常见的诉求：处理日志、统计数据、批量操作。
比如有一道题，要求你用Python或Shell实现一个函数，读入一个包含时间戳和访问路径的日志文件，输出每分钟的请求量，并找出请求量最大的那一分钟。这种题，用Python实现起来并不复杂，但有几个小细节很考验编码习惯：
- 日志文件可能很大，一次读入所有行可能导致内存压力，要能想到按行读取
- 时间格式的处理要统一，最好用
datetime或者time模块，而不是直接切字符串 - 输出格式要和题目要求完全一致，比如时间格式是
YYYY-MM-DD HH:MM还是别的格式
这道题虽然简单，但它直接对应了日常开发里“统计接口QPS”“分析访问高峰”这类真实需求。如果你平时就写过日志分析脚本，这种题基本是送分题。
还有一道题考的是文本处理，给你一个配置文件的模板，要求写一个Python脚本把模板里的占位符替换成实际值。这类题表面上在考字符串替换，实际考察的是你会不会用str.replace()或re.sub()处理批量配置下发场景。如果你在多个环境（测试、预发、生产）之间同步过配置，对这种需求一定不陌生。
4. 场景题作答思路：把运维事故处理流程写成答案
场景题是这套卷子里最有区分度的一部分。它不要求你写出完整代码，而是考察你在真实故障环境下有没有完整的处理思路。我特别想把这类题的作答心得拉出来单独说，因为不少同学在准备时容易忽略。
4.1 CPU 飙高与流量突刺：如何区分故障与正常波动
题目给了一个业务场景：某服务突然收到大量用户投诉，说APP打开很卡，监控平台显示该服务所在机器的CPU使用率从平时的30%暴涨到95%，且持续了10分钟。问你第一步该做什么。
很多同学的答案从“登录机器，top查看CPU占用进程”开始。这个操作当然没错，但在真实的故障处理里，第一件事应该是“确认当前的影响面，避免故障扩大”。
一个更完善的处理链路是：
- 先看监控大盘，确认影响范围：是个别机器还是整个集群？是否跌宕起伏？是否需要第一时间切流量或者摘除异常节点？
- 登录一台异常机器，用
top和top -Hp定位是哪个进程、哪类线程在消耗CPU - 结合链路追踪或日志，确认是正常流量突刺（比如大促、热点事件），还是代码逻辑问题（比如死循环、频繁GC）
- 先恢复（回滚版本、扩容、限流），再定位根因
写答案时，一定要把“先止损、后定位”这个顺序体现出来。阅卷人最怕看到的就是“先查半天代码，回头发现机器已经撑不住了”的节奏。这种顺序上的差别，能直接拉开答题质量差距。
4.2 慢接口与全链路追踪：从用户端到服务端的定位路径
另一个场景是：线上接口P99延迟明显上涨，但CPU和内存看起来都还行。如果按“服务端负载高”的思路去排查，很可能查不到问题，因为瓶颈可能不在服务本身。
这种情况要考虑的路径有：
- 客户端到边缘层的网络延迟，比如跨地域用户访问就近节点不通，导致路由绕远
- 边缘层到服务端的链路，比如负载均衡连接数打满、连接复用策略不合理
- 服务端依赖的下游，比如数据库连接池打满、Redis大Key阻塞、外部API调用变慢
- 服务端自身的线程模型，比如业务线程池满、阻塞在IO上
答题时，我建议按“端到端分段排查”的思路来写，先说明如何确定慢请求集中在哪些用户或地域，再做链路追踪，逐跳定位。这种分段的思维逻辑，比直接抛出一个解决方案要清晰得多。
4.3 容量规划与降级预案：业务侧视角
还有一道场景题，问的是活动大促前，服务预估流量会翻倍，作为运维开发你需要提前做什么准备。
这道题非常贴合业务运维的日常工作。我当时按这几个维度去答：
- 容量评估：根据历史流量增长趋势和活动预估规模，计算核心服务需要的CPU、内存、带宽资源，以及DB/Redis的连接数上限
- 弹性扩容：确认扩容预案，评估是直接加机器还是走弹性伸缩能力，并预留缓冲余量
- 压测验证：在预发环境模拟峰值流量，看链路的核心瓶颈在哪里，比如网关、数据库、消息队列
- 降级预案：明确哪些非核心功能可以在极端情况下降级，比如关闭个性化推荐、精简登录链路，保证核心播放功能稳定
- 监控告警：提前配置大盘和告警阈值，确保流量上涨时能第一时间发现
这种题目的得分点，不在于你有没有给出标准答案，而在于你的思考全不全面、优先级是否正确。如果你能体现出“业务视角”和“全局观”，阅卷人很容易看出你有实际经验。
5. 考后复盘：丢分点与值得坚持的做法
笔试结束之后，我没有马上放松，而是趁记忆还热乎着，把整场笔试的答题情况、时间分配、知识盲区都复盘了一遍。这个习惯我从第一次面试就开始坚持，收益很大。
5.1 丢分点集中在哪里
我复盘后的结论是，丢分主要集中在两类地方。
一是客观题里的网络细节。TCP连接建立和断开的状态流转，我虽然考前背了，但题目不是直接问你状态名，而是放在一段实际的ss或netstat输出里，结合故障场景让你判断原因。这种“换个形式考八股”的方式，如果只是死记硬背，就很容易翻车。
二是场景题的答案不够细化。我第一版答案写的是“使用全链路追踪工具定位慢接口”，但这太笼统了。后来回想，如果能把排查步骤落到具体操作的粒度，比如“先看cat /proc/net/tcp或者ss -s判断连接状态分布”“再用jstack抓线程栈”，得分会高很多。
5.2 哪些备考点是真正高ROI的
站在现在回头看，有这么几个考点，性价比极高，几乎可以断定运维开发笔试必出：
- Linux 三件套：
grep/awk/sed的常见用法，一定要能立刻写出来，比如用awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -n 10统计访问Top 10的来源IP - 磁盘与文件：
df -h、du -sh、lsof | grep deleted排查磁盘空间不释放的问题 - 进程与线程：
ps aux、top -Hp、jstack抓线程栈分析卡死原因 - TCP/IP状态机：
TIME_WAIT、CLOSE_WAIT、SYN_RECV这些状态背后的故障含义 - Python脚本能力：文件读写、正则匹配、subprocess调用外部命令、日志统计，这些足以覆盖90%的运维开发笔试编程题
- MySQL explain：看懂type、key、rows几个关键字段，能给出慢查询优化建议
5.3 给下一批候选人的建议
如果你正在准备类似方向的笔试，我有几条实操层面的大实话建议。
第一，平时一定要真去排查过问题，而不是只看文档。你在笔试中能写出多少排查细节，取决于你真实处理过多少线上问题。哪怕只是一台虚拟机里的服务故障，只要你完整走了一遍“发现问题->定位->解决->复盘”的流程，笔试场景题的表达会和背答案完全不同。
第二，编程题不要只刷LeetCode。运维开发的编程题极少考察复杂的树和堆，更常见的是“统计日志里某个字段出现频次”“按时间窗口聚合数据”这类文本处理任务。你用Python写，思路一定要靠近真实业务需求。
第三，重视“代价”思维。笔试里有些选择题会包含“操作后果”的选项，看似折腾的选项反而是正确答案。比如删除日志前要不要先确认进程是否持有文件句柄、重启服务前要不要先摘流量，这类思路题靠的就是日常操作习惯的积累。
第四，准备一份自己的排查SOP。把“服务器负载高”“接口延迟大”“磁盘写满”“连接数打满”这四类经典故障的处理步骤，自己写成文档。这既是考前最好的复习资料，也是以后实际工作用得上的武器。
我参加完这场笔试之后最大的感受是：这个岗位考的从来不是某一项顶尖的技能，而是一个人的综合工程素养。你不需要在算法题上碾压别人，但你要对系统运行的方方面面有足够的好奇心和掌控力。笔试只是一个入口，真正拉开差距的，是长期在一线排查、复盘、优化中积累出来的直觉和判断力。这份直觉，没有任何一本八股书能直接教给你，只能靠你亲手去碰那些真实的故障。
