腾讯音乐的秋招笔试业务运维岗第一批。这个岗位方向在互联网大厂面试里一直比较有代表性——既不是纯开发也不是纯DBA而是要求一个人能撑起从网络、系统到应用层的全套保障。我去年完整走完了这批笔试从投简历到收到笔试通知大概隔了一周整体感觉是题型不算偏但广度覆盖很大深度也有几处卡人的地方如果只靠临时刷题去考很吃亏。这篇文章把笔试内容做一个完整复盘并且把每道题背后想考察的运维基本功、常见的答题思路和容易踩的坑一并说清楚。1. 笔试整体结构与时间分配先看清楚这场考试在筛什么人腾讯音乐的笔试时间一般是90分钟到120分钟我当时这场是90分钟题量在45道左右题型分布为单选25题、多选10题、判断5题、简答/案例分析5题。整体看下来它并不是腾讯其他事业群那种特别偏算法的笔试而是更侧重网络原理、Linux系统、监控告警、数据库基础、CDN/直播场景预案、容器化与K8s基础。换句话讲这场笔试实际上在筛两类人一类是基础扎实、能处理突发故障的运维工程师另一类是具备一定开发能力、能写脚本做自动化的进阶候选者。两类能力在题目里是并行的只靠背命令并不能拿高分。从时间分配上我的建议是单选和多选控制在40分钟以内判断5分钟剩下至少35分钟给简答题。很多人容易在选择题上死磕尤其多个选项看起来都对的时候一犹豫就耗掉大量时间。实际上腾讯音乐的笔试计分里简答题的主观分占比不低而且案例分析写得完整、有逻辑比选择题多蒙对两道的收益大得多。我的策略是选择题里凡是一眼不会的先标记跳过最后有时间再回来看优先保证把简答题答完。最后我选择题里有两道多选是猜的但简答题写得很充分最后进入了面试轮。题型结构可以大致拆成这样模块题量考察要点难度Linux基础约8题常用命令、权限、systemd、进程管理中等网络基础约10题TCP/IP、DNS、HTTP、负载均衡中等偏上监控与告警约4题Zabbix/Prometheus、告警规则设计中等数据库约5题MySQL索引、事务、慢查询中等容器与K8s约4题镜像、Pod、Service、容器编排中等偏上业务场景案例分析5题大促保障、故障排查、降级预案偏难考完感受很明显题目本身不算偏但它考察的“运维思维”比“记忆量”更多。比如后面会详细说的那几道案例题没有标准答案考官是想看你的排查链路是否清晰、是否考虑了监控、告警、应急、复盘全流程。2. 考点模块拆解网络与Linux始终是拉分主力2.1 Linux命令与系统管理不是背命令而是看理解Linux相关题目大概有8道左右考点非常集中在几个方面文件权限、进程管理、systemd单元文件、软硬链接、文本处理命令。其中有一道题让人印象很深是给了一段find /var/log -name *.log -mtime 7 -exec rm {} \;的问答题表面是问这个命令的作用实际上想让你指出两个坑一是-mtime 7指的是7天以前的文件找的是真实时间边界二是-exec rm {} \;的写法如果文件数量大可能会遇到参数过长的问题更稳妥的是配合xargs。这题就是很典型的“让你看命令但实际考你生产经验”的题型。还有一道题是给了个systemd的service文件里面只有ExecStart、Restarton-failure、RestartSec3这几行问你服务挂了之后多久会被拉起。这里要掌握的其实是systemd的重启策略on-failure表示只有非正常退出才重启退出码0不会重启RestartSec是从服务停止到下次启动的间隔。这类题如果没在真实环境里写过unit文件很容易选错。我当时备考的时候把systemd的常用配置项都过了一遍包括Restart的几种取值、StartLimitBurst和StartLimitIntervalSec的配合关系后面证明这些基础在面试里也会反复问到。Linux题里还有一个多选问“以下哪些命令可以查看进程的网络连接状态”给了netstat、ss、lsof、ps四个选项。很多人会漏选lsof因为习惯上觉得lsof是看文件句柄的但实际上lsof -i就是看网络连接的经典用法。这类题考的是你对命令功能边界的理解而不是单一记忆。2.2 网络基础TCP握手、HTTP状态码、负载均衡策略网络模块是这次笔试里占比最高的大概10题左右。考察方向可以分成三个层次第一层是TCP协议基础比如三次握手和四次挥手的过程、TIME_WAIT状态的意义、TCP拥塞控制的几个阶段。有一道题问“主动关闭连接的一方最后进入什么状态”正确答案是TIME_WAIT选项里混了CLOSE_WAIT、FIN_WAIT_1、LAST_ACK。这题本身不难但很多人容易把主动方和被动方的状态记混我建议你用一个口诀去记谁先发FIN谁进TIME_WAIT被动方收到FIN后先回ACK进CLOSE_WAIT再回FIN进LAST_ACK。第二层是HTTP和DNS有一道题问“DNS解析用到的传输层协议是什么”这个要分情况常规查询走UDP 53区域传送走TCP 53。题干如果没说具体场景默认答UDP但你把TCP的情况也写上去会显得理解更全面。腾讯音乐的业务里有大量静态资源分发所以CDN回源、HTTP缓存相关的题也出现了。第三层是负载均衡有一道多选问“常见的负载均衡算法有哪些”选项有轮询、加权轮询、最少连接数、IP哈希。这四个都选基本没有悬念。但后面有一道简答问“假如有一个音乐播放接口用户请求量突然暴涨作为运维你会怎么做”这实际上考的就是负载均衡与限流降级的综合方案单纯的算法背诵解决不了。网络模块还出现了一道比较刁钻的题给了一段tcpdump抓包输出让你判断这个包是TCP握手过程中的哪一个报文。抓包里显示Flags [S]和seq0这个一眼就能认出是SYN包。但如果抓包输出里带上了win64240、mss1460这些TCP选项字段正常能靠选项字段确认这是SYN包。这类题真实工作里经常遇到毕竟排查问题的时候tcpdump是最常用的工具。2.3 监控与告警设计一个告警规则比背诵指标更有区分度监控部分的题量不大大概4题左右但有一道简答题非常有区分度题目大概是“某一业务接口成功率下降请你设计一套监控和告警方案包括监控指标、告警阈值、告警级别和处理流程。”如果只是回答“用Zabbix监控接口状态码”那基本只能拿一半分。这道题要拆成四个层次来答指标层核心指标包括接口成功率、接口平均响应时间、错误码分布、上游依赖接口状态。另外要补充一个容易被忽略的指标——机器负载和网络连接数因为接口成功率下降很多时候不是应用代码问题而是底层资源到达瓶颈。告警阈值层不能只给一个固定值要同时考虑基线。比如成功率低于99.5%告警但更合理的是先看这个接口过去7天的平均成功率如果基线是99.9%那降到99.5%就是重大异常如果基线本来就是99%那降到99.5%反而是好转。所以阈值要分绝对值阈值和相对基线偏移两种。告警级别层P0/P1/P2对应不同的响应时限。P0是核心接口失败直接影响用户体验和收入必须5分钟内响应P1是业务受损但可降级15分钟内响应P2是监控发现异常但暂时无用户影响24小时内处理。腾讯音乐的业务场景里会员支付接口、播放接口就是典型的P0像歌单推荐、评论接口可以定P1。处理流程层要写清楚告警触发后的排查链路——先检查告警是否误报然后看应用日志、依赖服务状态、数据库慢查询、网络丢包。这套流程其实就是把生产环境故障排查的步骤固化下来。这道题我后来在面试里也被问到过所以强烈建议各位把监控方案类题目的答题结构固定下来用“指标-阈值-级别-流程”的框架去答不管题目怎么变都能稳住。2.4 MySQL与缓存事务隔离级别、索引失效、缓存穿透数据库相关题目大概5题MySQL是绝对主力。选择题里有个很经典的坑问“InnoDB默认的事务隔离级别是什么”正确答案是REPEATABLE READ但是要注意这个隔离级别其实是通过MVCC实现的不是靠锁表。紧接着有一道多选问“哪些操作会导致索引失效”选项包含“对索引列使用函数”“隐式类型转换”“LIKE以通配符开头”“使用OR连接非索引列”这四个都要选。我在做题的时候就在想如果这道题出现在面试里一定还会追问一句“为什么隐式类型转换会导致索引失效”因为MySQL优化器会把字段类型转换成参数的类型一旦对字段本身做了函数操作索引就失效了。还有一道题跟业务直接挂钩问“用户听歌排行榜场景下用什么Redis数据结构”。答案是Sorted Set因为ZSet天然支持按score排序和TopN查询。但题目问的不是数据结构本身而是“当用户量很大的时候这个方案有什么问题”这里需要你答出Redis的热Key问题和大Key问题——排行榜往往是全局热Key单节点压力大如果score相同导致member数量很多也可能出现大Key。优化方向是分片排行或者近似排行。缓存方面还有一道简答场景是“当数据库压力突然变大可能是哪些原因如何排查和解决”。我当时答题的核心思路是先看是不是缓存失效导致的流量直接打到数据库也就是缓存穿透、缓存击穿、缓存雪崩这三个现象。具体区分缓存穿透是查一个不存在的key每次都会打到数据库缓存击穿是一个热点key过期瞬间大量请求打到数据库缓存雪崩是大量key在同一时间过期数据库压力骤然上升。然后回答对应方案穿透用布隆过滤器击穿用互斥锁或逻辑过期时间雪崩用随机过期时间加上多级缓存。最后再补充一句“同时要确认数据库本身没有慢SQL”因为如果SQL本身慢缓存只能缓解读压力不能根治。2.5 容器化与K8s从镜像原理到Pod调度容器与K8s相关题目大约4题本次笔试里出现了一道跟热搜词库吻合度很高的题问的是“Kubernetes是如何调用containerd的从原理到实体调用架构”。说实话这个题如果在笔试题里出现已经不算是基础题了属于进阶题因为很多人熟悉Docker、却不太理解K8s和容器运行时之间的完整链路。这里要表达清楚的关键链路是kubelet通过CRIContainer Runtime Interface调用containerdcontainerd内部通过containerd-shim来启动和管理容器进程最终由runc负责真正创建和运行容器。一条完整的调用链可以写成kubelet - CRI - containerd - containerd-shim - runc。如果你只答到“kubelet调用containerd”那只是皮毛。要拿分必须把CRI这个抽象层的意义讲清楚CRI就是Kubernetes定义的一整套接口规范只要容器运行时实现了这些接口K8s就能对接不管底层是containerd、CRI-O还是其他的运行时。这就像你电脑上的USB接口一样K8s定义了统一的插口containerd就是其中一种实现了这个插口的设备。再往下说一层containerd本身已经不直接管理单个容器进程了它会为每个Pod创建一个containerd-shim进程这个shim进程的作用是保持容器的标准输入输出和退出状态即使containerd主进程重启容器本身也不会受影响。这也是为什么生产环境里用containerd替代旧版Docker之后Pod的稳定性反而更好的原因。至于runc它是一个符合OCI规范的低层运行时真正负责利用Linux内核的namespace、cgroup、chroot等机制把容器跑起来。答题时如果能把这四层架构讲清楚并且补充一句“containerd相比于Docker少了一层Docker daemon和dockershim”就基本能拿到满分的评价。我当时在这道题后面还延伸答了一段关于镜像结构的内容因为镜像拉取和容器启动是相关联的。镜像可以理解为多层只读文件系统的叠加每一层对应Dockerfile里的一条指令容器启动时会在镜像层之上加一个可写层。这解释了为什么镜像分层能节省存储和网络带宽也解释了为什么构建镜像时要把变化最频繁的指令放在最后面。2.6 场景案例题核心大促保障、故障排查、降级预案案例分析题总共5道其中两道非常贴合腾讯音乐的业务场景也是整张卷子的重头戏。第一道是“QQ音乐年度听歌报告活动中用户量预计翻3倍作为业务运维请你写出完整的保障方案。”这道题我在复盘时觉得它考的其实是运维对“容量评估→压测→限流降级→监控→预案”这个闭环的理解答的时候要按时间线拆成三个阶段活动前两周评估容量包括带宽、机器资源、数据库连接池、下游依赖系统。具体方法拉取历史峰值数据按预估流量模型放大三倍计算出需要扩容的机器数量对核心链路做全链路压测找出瓶颈点。比如用户报告生成接口如果是CPU密集型压测时CPU达到80%就要考虑加机器或优化逻辑。活动前一周准备好降级预案包括静态化页面降级、非核心接口熔断、消息队列削峰。比如用户年度报告这种业务核心数据是听歌记录这部分不能降级但好友互动、评论分享这类非核心链路在流量高峰时可以降级把资源让给核心链路。同时把告警阈值调低比如平时成功率99%才告警大促时降到98%就要告警因为越早发现越容易处理。活动中/后安排人员盯屏每30分钟同步一次核心指标活动后要把压测数据和实际数据做对比记录问题和优化点输出复盘报告。第二道场景题是故障排查类的“某天晚间8点大量用户反馈无法播放歌曲可能的原因有哪些请写出你的排查思路。”这道题没有标准答案但答题时要体现出“从现象到定位从定位到解决”的完整链路。我的答题思路是先确认影响范围是所有用户都播放失败还是部分用户是所有歌曲都失败还是特定歌曲失败这个可以通过监控平台和用户反馈维度快速判断。如果影响所有用户优先看CDN和核心接口服务如果只影响部分用户看是不是地域性的网络问题或者客户端版本问题。接着逐层排查CDN节点是否异常→播放接口是否过载→服务日志有没有大量报错→依赖的音乐资源库是否可用→数据库是否有慢查询。如果问题定位到CDN先做节点切换和流量调度如果定位到服务看是否需要扩容、重启或者回滚版本。反馈和解决要同步进行不要等完全定位了才动手。这种故障排查题写答案的时候一定要有先后顺序体现出“先恢复后定位”的原则。生产环境里的故障处理永远是先止损再查因最后复盘。谁先做安全止损、把影响范围控制住谁才是合格的业务运维。3. 那些你没准备到但考到的题统信运维工具、直播场景、桌面运维腾讯音乐笔试的题目并不完全限定在互联网后端运维范畴有几道题如果平时只盯着云原生和大流量架构反而容易漏掉。这批笔试里出现了跟“统信运维工具”和“桌面运维”相关的考察点虽然题量不大但确实让不少人愣了一下。有一道选择题问的是“统信操作系统的运维工具LiveCD主要用来做什么”。这个知识点得稍微了解一下国产操作系统的运维生态。统信UOS的LiveCD本质上是一个可启动的应急修复环境类似Windows PE或者CentOS的rescue模式。当系统无法正常启动、root密码遗忘、引导损坏、分区表异常时可以用LiveCD启动到内存系统然后挂载原硬盘分区进行修复。选项里有一个干扰项是“通过LiveCD进行系统日常性能监控”这明显是错的因为LiveCD是应急环境不会用于日常运维。如果有做教育和政企运维背景的同学这道题几乎是送分题但对于一直在互联网公司做后端运维的人可能平时完全没接触过。桌面运维的考点是另一道案例分析题“企业办公电脑频繁出现卡顿、蓝屏、软件冲突问题作为运维工程师请制定一套桌面运维标准流程。”很多人一看这题就懵觉得互联网运维和桌面运维完全是两个工种但其实这道题考察的是流程规范化的能力跟具体技术栈无关。我的答题思路是分成三个阶段接入阶段统一资产登记给每台电脑建立唯一标识记录硬件配置、安装软件清单、入职离职时间。这样可以快速定位问题设备的型号和软件环境避免每次排查都让人重新报一遍电脑配置。处理阶段建立问题分级机制按影响程度分为“无法开机”“影响正常办公”“不影响业务的软件问题”三个级别不同级别对应不同响应时间。同时沉淀常见问题解决方案库比如蓝屏时先查dump文件和最近安装的驱动软件冲突时优先用进程隔离和版本回滚来处理。预防阶段统一系统镜像用标准化安装配合软件分发工具减少因环境差异导致的问题定期推送驱动更新和安全补丁降低蓝屏概率。这道题如果你真的没有桌面运维经验也不用慌核心逻辑是通用的流程标准化、问题分级处理、沉淀知识库、主动预防。把这个逻辑讲清楚阅卷人不会在意你有没有实际修过电脑。跟直播相关的题目也出现了这跟腾讯音乐近年主推的TME live业务是直接挂钩的。有一道单选问“直播推流超时无法开播优先排查哪个环节”选项有推流端网络、CDN上行节点、转码服务、播放端。正确答案是推流端网络和CDN上行节点因为推流超时的本质是上行链路问题播放端这时候还没参与进来。这种题考的就是对直播链路的基本认知业务运维至少要知道推流端→CDN上行→转码服务→CDN分发→播放端这条链路的每一个环节分别负责什么。4. 笔试答题的实战策略哪些误区会让你无意识丢分经历过这次笔试之后我对大厂运维岗笔试题的出题逻辑有了更清晰的认识。大部分题目并不是考背得多熟而是考你在真实运维场景里的判断力但很多人在答题方式上有几个常见误区导致失分很可惜。4.1 多选题选错策略少选和错选是大坑多选题目一共10道腾讯音乐的多选题规则是少选不得分、错选不得分。这个规则在部分考试里是“少选得一半分”但腾讯音乐笔试明确不是所以做多选题的策略切忌贪多。我的建议是一道多选题如果能把两个选项确定是对的剩下的选项不确定那我们宁可只选两个确定的。虽然不能拿满分但也别因为多选一个错的直接归零。这背后其实也反映了一个真实的运维工作习惯在生产环境里做变更时应该是“能少动就少动能不动就不动”而不是追求面面俱到。你太贪心想把所有依赖都升级一遍结果往往就是引入一个不兼容的坑。做多选题也是一样拿不准的就不选。4.2 简答题别写“关键字”而要写“链路”简答题是最能拉开差距的模块但也是最容易被误解的模块。很多人以为简答题只要把关键点写出来就行比如问“排查CPU飙高的步骤”就写“top、vmstat、strace”三个命令。这在阅卷人眼里只能拿基础分因为他不只想知道你会用什么命令更想知道你看到命令输出之后是怎么判断的。举个例子一道简答是“服务器CPU负载突然升高请写出排查思路”。正确答案的思路应该是分层的先用top查看进程维度的CPU使用率确认是用户态高还是内核态高。如果是用户态高用top -Hp pid找到具体线程再用jstack或者pstack把线程栈打出来看是不是代码死循环、GC线程还是业务逻辑问题。如果是内核态高可能是系统调用频繁用strace -c -p pid统计系统调用次数重点看futex、epoll_wait这些异常高的调用。同时查看负载均值uptime配合vmstat看runnable进程数和阻塞进程数判断是CPU瓶颈还是IO等待导致的假性高负载。简答题一定要把“命令判断逻辑结果处理”写完整才能体现出你的实战经验。命令拼错了不会直接零分整个排查链路不完整反而才是拿不到分的关键原因。4.3 尽量给出数值和参数而不是只说“调大一点”阅卷人特别看重的一个点是你给的方案里有没有具体数值。如果问“连接数满了怎么处理”你只写“调大连接数上限”这等于没答。你要写出具体的参数和命令比如修改/etc/security/limits.conf中的nofile或者调整内核参数net.ipv4.ip_local_port_range把端口范围从默认的32768-60999扩展到1024-65535。再比如面试里经常问的“TIME_WAIT过多怎么办”除了改net.ipv4.tcp_tw_reuse还要同时说明开启的前提条件——必须确保TCP时间戳选项是开启的否则会引发序列号混乱。这些细节才能体现你真的在生产环境里处理过问题。4.4 时间不够时案例题优先级最高整套卷子如果做到最后发现时间不够了优先把案例题补充完整哪怕选择题空着不猜。因为案例题分值高、主观空间大写了一个完整的排查链路至少能拿60%的分数而选择题猜了也不一定对多选还容易倒扣。我记得当时做最后一道案例题时只剩下大概10分钟我快速把“排查思路”分成了5个步骤每步用一行概括没有详细展开最终也拿到了不错的案例分。5. 笔试后的延伸准备同一套题目面试还会从这几个角度追问笔试结束之后不要以为就完事了。腾讯音乐的面试官手里是有你的笔试答案的面试时很可能从笔试题目里挑几道做深度追问。我后来在面试环节就被问到了笔试中的两个点一个是K8s调用containerd的整条链路另一个是大促保障方案中压测的具体操作方式。这里把延伸准备的方向也一并整理出来方便大家提前打底。5.1 K8s与容器运行时的深入追问方向如果笔试考了K8s调用containerd那面试环节十有八九会问这几个延伸问题为什么Kubernetes从1.24版本开始移除了dockershim答案核心是dockershim只是K8s为了兼容Docker而做的一层胶水代码维护成本高而且Docker本身提供的很多能力在K8s场景下根本用不到直接通过CRI对接containerd更轻量、更稳定。这个问题的深层逻辑是理解“抽象层越少故障点越少”。如何排查Pod一直ContainerCreating的问题这个就是纯实战题了。先kubectl describe pod看事件常见原因包括镜像拉取失败、存储卷挂载失败、CNI网络插件未就绪。如果事件信息不明显再用journalctl -u kubelet查看kubelet日志因为CRI调用containerd失败的信息往往会记录在kubelet日志里。5.2 大促保障与容量压测的深入追问方向笔试写了大促保障方案面试时面试官直接追问“你压测的时候主要看哪些指标”。这个问题需要答出业务指标和系统指标两个层次。业务指标包括接口成功率、响应时间的P95/P99、错误率系统指标包括CPU使用率、内存使用率、磁盘IO、网络带宽、TCP连接数、数据库连接池使用率。还要能说出“性能拐点”这个概念也就是随着并发量增加响应时间出现急剧上升的那个点这个点往往就是系统能承载的极限流量。压测的过程中要同时观察这些指标才能准确判断扩容的时机和规模。还会追问“如果压测时发现数据库连接池满了你怎么处理”。这个问题考察的不只是加大连接池而是从根因上做判断连接池满往往意味着有慢SQL或者连接泄漏需要先查show processlist看是哪些SQL在占用连接有没有长时间不释放的事务然后在代码层面检查连接是否正常归还。直接把max_connections翻倍是治标不治本可能还会把数据库拖垮。以上这些延伸点是建议从笔试到面试的过渡阶段至少准备好的内容。大厂的运维面试本质上考察的从来都是同一套基本功基础是否扎实、排查链路是否清晰、有没有真实的生产经验。笔试只是在第一道关口把基本功不够扎实的人筛掉真正的较量从面试才开始。整轮笔试做下来我最深的一个感受是运维岗的考察方向这几年变化确实不小。如果你只准备Linux命令和网络基础勉强能过选择题但在案例题和简答题上会非常吃亏。现在的业务运维要求的是能够从架构层面理解系统的人而不是只会执行命令的操作手。把K8s的调用链、MySQL的索引原理、Redis的数据结构、CDN的调度逻辑都串起来才能在这场考试里真正拿到高分。准备的过程也不要只刷题最好能在自己的测试环境里把每个知识点实际操作一遍比如用kubeadm搭一套K8s集群然后用crictl去查看容器运行时状态再手动拉一次containerd的调用链路。实际动手跑过一遍和看十篇解析文章的效果完全不一样。 腾讯音乐业务运维岗笔试复盘：从网络到K8s全栈考察要点
腾讯音乐的秋招笔试业务运维岗第一批。这个岗位方向在互联网大厂面试里一直比较有代表性——既不是纯开发也不是纯DBA而是要求一个人能撑起从网络、系统到应用层的全套保障。我去年完整走完了这批笔试从投简历到收到笔试通知大概隔了一周整体感觉是题型不算偏但广度覆盖很大深度也有几处卡人的地方如果只靠临时刷题去考很吃亏。这篇文章把笔试内容做一个完整复盘并且把每道题背后想考察的运维基本功、常见的答题思路和容易踩的坑一并说清楚。1. 笔试整体结构与时间分配先看清楚这场考试在筛什么人腾讯音乐的笔试时间一般是90分钟到120分钟我当时这场是90分钟题量在45道左右题型分布为单选25题、多选10题、判断5题、简答/案例分析5题。整体看下来它并不是腾讯其他事业群那种特别偏算法的笔试而是更侧重网络原理、Linux系统、监控告警、数据库基础、CDN/直播场景预案、容器化与K8s基础。换句话讲这场笔试实际上在筛两类人一类是基础扎实、能处理突发故障的运维工程师另一类是具备一定开发能力、能写脚本做自动化的进阶候选者。两类能力在题目里是并行的只靠背命令并不能拿高分。从时间分配上我的建议是单选和多选控制在40分钟以内判断5分钟剩下至少35分钟给简答题。很多人容易在选择题上死磕尤其多个选项看起来都对的时候一犹豫就耗掉大量时间。实际上腾讯音乐的笔试计分里简答题的主观分占比不低而且案例分析写得完整、有逻辑比选择题多蒙对两道的收益大得多。我的策略是选择题里凡是一眼不会的先标记跳过最后有时间再回来看优先保证把简答题答完。最后我选择题里有两道多选是猜的但简答题写得很充分最后进入了面试轮。题型结构可以大致拆成这样模块题量考察要点难度Linux基础约8题常用命令、权限、systemd、进程管理中等网络基础约10题TCP/IP、DNS、HTTP、负载均衡中等偏上监控与告警约4题Zabbix/Prometheus、告警规则设计中等数据库约5题MySQL索引、事务、慢查询中等容器与K8s约4题镜像、Pod、Service、容器编排中等偏上业务场景案例分析5题大促保障、故障排查、降级预案偏难考完感受很明显题目本身不算偏但它考察的“运维思维”比“记忆量”更多。比如后面会详细说的那几道案例题没有标准答案考官是想看你的排查链路是否清晰、是否考虑了监控、告警、应急、复盘全流程。2. 考点模块拆解网络与Linux始终是拉分主力2.1 Linux命令与系统管理不是背命令而是看理解Linux相关题目大概有8道左右考点非常集中在几个方面文件权限、进程管理、systemd单元文件、软硬链接、文本处理命令。其中有一道题让人印象很深是给了一段find /var/log -name *.log -mtime 7 -exec rm {} \;的问答题表面是问这个命令的作用实际上想让你指出两个坑一是-mtime 7指的是7天以前的文件找的是真实时间边界二是-exec rm {} \;的写法如果文件数量大可能会遇到参数过长的问题更稳妥的是配合xargs。这题就是很典型的“让你看命令但实际考你生产经验”的题型。还有一道题是给了个systemd的service文件里面只有ExecStart、Restarton-failure、RestartSec3这几行问你服务挂了之后多久会被拉起。这里要掌握的其实是systemd的重启策略on-failure表示只有非正常退出才重启退出码0不会重启RestartSec是从服务停止到下次启动的间隔。这类题如果没在真实环境里写过unit文件很容易选错。我当时备考的时候把systemd的常用配置项都过了一遍包括Restart的几种取值、StartLimitBurst和StartLimitIntervalSec的配合关系后面证明这些基础在面试里也会反复问到。Linux题里还有一个多选问“以下哪些命令可以查看进程的网络连接状态”给了netstat、ss、lsof、ps四个选项。很多人会漏选lsof因为习惯上觉得lsof是看文件句柄的但实际上lsof -i就是看网络连接的经典用法。这类题考的是你对命令功能边界的理解而不是单一记忆。2.2 网络基础TCP握手、HTTP状态码、负载均衡策略网络模块是这次笔试里占比最高的大概10题左右。考察方向可以分成三个层次第一层是TCP协议基础比如三次握手和四次挥手的过程、TIME_WAIT状态的意义、TCP拥塞控制的几个阶段。有一道题问“主动关闭连接的一方最后进入什么状态”正确答案是TIME_WAIT选项里混了CLOSE_WAIT、FIN_WAIT_1、LAST_ACK。这题本身不难但很多人容易把主动方和被动方的状态记混我建议你用一个口诀去记谁先发FIN谁进TIME_WAIT被动方收到FIN后先回ACK进CLOSE_WAIT再回FIN进LAST_ACK。第二层是HTTP和DNS有一道题问“DNS解析用到的传输层协议是什么”这个要分情况常规查询走UDP 53区域传送走TCP 53。题干如果没说具体场景默认答UDP但你把TCP的情况也写上去会显得理解更全面。腾讯音乐的业务里有大量静态资源分发所以CDN回源、HTTP缓存相关的题也出现了。第三层是负载均衡有一道多选问“常见的负载均衡算法有哪些”选项有轮询、加权轮询、最少连接数、IP哈希。这四个都选基本没有悬念。但后面有一道简答问“假如有一个音乐播放接口用户请求量突然暴涨作为运维你会怎么做”这实际上考的就是负载均衡与限流降级的综合方案单纯的算法背诵解决不了。网络模块还出现了一道比较刁钻的题给了一段tcpdump抓包输出让你判断这个包是TCP握手过程中的哪一个报文。抓包里显示Flags [S]和seq0这个一眼就能认出是SYN包。但如果抓包输出里带上了win64240、mss1460这些TCP选项字段正常能靠选项字段确认这是SYN包。这类题真实工作里经常遇到毕竟排查问题的时候tcpdump是最常用的工具。2.3 监控与告警设计一个告警规则比背诵指标更有区分度监控部分的题量不大大概4题左右但有一道简答题非常有区分度题目大概是“某一业务接口成功率下降请你设计一套监控和告警方案包括监控指标、告警阈值、告警级别和处理流程。”如果只是回答“用Zabbix监控接口状态码”那基本只能拿一半分。这道题要拆成四个层次来答指标层核心指标包括接口成功率、接口平均响应时间、错误码分布、上游依赖接口状态。另外要补充一个容易被忽略的指标——机器负载和网络连接数因为接口成功率下降很多时候不是应用代码问题而是底层资源到达瓶颈。告警阈值层不能只给一个固定值要同时考虑基线。比如成功率低于99.5%告警但更合理的是先看这个接口过去7天的平均成功率如果基线是99.9%那降到99.5%就是重大异常如果基线本来就是99%那降到99.5%反而是好转。所以阈值要分绝对值阈值和相对基线偏移两种。告警级别层P0/P1/P2对应不同的响应时限。P0是核心接口失败直接影响用户体验和收入必须5分钟内响应P1是业务受损但可降级15分钟内响应P2是监控发现异常但暂时无用户影响24小时内处理。腾讯音乐的业务场景里会员支付接口、播放接口就是典型的P0像歌单推荐、评论接口可以定P1。处理流程层要写清楚告警触发后的排查链路——先检查告警是否误报然后看应用日志、依赖服务状态、数据库慢查询、网络丢包。这套流程其实就是把生产环境故障排查的步骤固化下来。这道题我后来在面试里也被问到过所以强烈建议各位把监控方案类题目的答题结构固定下来用“指标-阈值-级别-流程”的框架去答不管题目怎么变都能稳住。2.4 MySQL与缓存事务隔离级别、索引失效、缓存穿透数据库相关题目大概5题MySQL是绝对主力。选择题里有个很经典的坑问“InnoDB默认的事务隔离级别是什么”正确答案是REPEATABLE READ但是要注意这个隔离级别其实是通过MVCC实现的不是靠锁表。紧接着有一道多选问“哪些操作会导致索引失效”选项包含“对索引列使用函数”“隐式类型转换”“LIKE以通配符开头”“使用OR连接非索引列”这四个都要选。我在做题的时候就在想如果这道题出现在面试里一定还会追问一句“为什么隐式类型转换会导致索引失效”因为MySQL优化器会把字段类型转换成参数的类型一旦对字段本身做了函数操作索引就失效了。还有一道题跟业务直接挂钩问“用户听歌排行榜场景下用什么Redis数据结构”。答案是Sorted Set因为ZSet天然支持按score排序和TopN查询。但题目问的不是数据结构本身而是“当用户量很大的时候这个方案有什么问题”这里需要你答出Redis的热Key问题和大Key问题——排行榜往往是全局热Key单节点压力大如果score相同导致member数量很多也可能出现大Key。优化方向是分片排行或者近似排行。缓存方面还有一道简答场景是“当数据库压力突然变大可能是哪些原因如何排查和解决”。我当时答题的核心思路是先看是不是缓存失效导致的流量直接打到数据库也就是缓存穿透、缓存击穿、缓存雪崩这三个现象。具体区分缓存穿透是查一个不存在的key每次都会打到数据库缓存击穿是一个热点key过期瞬间大量请求打到数据库缓存雪崩是大量key在同一时间过期数据库压力骤然上升。然后回答对应方案穿透用布隆过滤器击穿用互斥锁或逻辑过期时间雪崩用随机过期时间加上多级缓存。最后再补充一句“同时要确认数据库本身没有慢SQL”因为如果SQL本身慢缓存只能缓解读压力不能根治。2.5 容器化与K8s从镜像原理到Pod调度容器与K8s相关题目大约4题本次笔试里出现了一道跟热搜词库吻合度很高的题问的是“Kubernetes是如何调用containerd的从原理到实体调用架构”。说实话这个题如果在笔试题里出现已经不算是基础题了属于进阶题因为很多人熟悉Docker、却不太理解K8s和容器运行时之间的完整链路。这里要表达清楚的关键链路是kubelet通过CRIContainer Runtime Interface调用containerdcontainerd内部通过containerd-shim来启动和管理容器进程最终由runc负责真正创建和运行容器。一条完整的调用链可以写成kubelet - CRI - containerd - containerd-shim - runc。如果你只答到“kubelet调用containerd”那只是皮毛。要拿分必须把CRI这个抽象层的意义讲清楚CRI就是Kubernetes定义的一整套接口规范只要容器运行时实现了这些接口K8s就能对接不管底层是containerd、CRI-O还是其他的运行时。这就像你电脑上的USB接口一样K8s定义了统一的插口containerd就是其中一种实现了这个插口的设备。再往下说一层containerd本身已经不直接管理单个容器进程了它会为每个Pod创建一个containerd-shim进程这个shim进程的作用是保持容器的标准输入输出和退出状态即使containerd主进程重启容器本身也不会受影响。这也是为什么生产环境里用containerd替代旧版Docker之后Pod的稳定性反而更好的原因。至于runc它是一个符合OCI规范的低层运行时真正负责利用Linux内核的namespace、cgroup、chroot等机制把容器跑起来。答题时如果能把这四层架构讲清楚并且补充一句“containerd相比于Docker少了一层Docker daemon和dockershim”就基本能拿到满分的评价。我当时在这道题后面还延伸答了一段关于镜像结构的内容因为镜像拉取和容器启动是相关联的。镜像可以理解为多层只读文件系统的叠加每一层对应Dockerfile里的一条指令容器启动时会在镜像层之上加一个可写层。这解释了为什么镜像分层能节省存储和网络带宽也解释了为什么构建镜像时要把变化最频繁的指令放在最后面。2.6 场景案例题核心大促保障、故障排查、降级预案案例分析题总共5道其中两道非常贴合腾讯音乐的业务场景也是整张卷子的重头戏。第一道是“QQ音乐年度听歌报告活动中用户量预计翻3倍作为业务运维请你写出完整的保障方案。”这道题我在复盘时觉得它考的其实是运维对“容量评估→压测→限流降级→监控→预案”这个闭环的理解答的时候要按时间线拆成三个阶段活动前两周评估容量包括带宽、机器资源、数据库连接池、下游依赖系统。具体方法拉取历史峰值数据按预估流量模型放大三倍计算出需要扩容的机器数量对核心链路做全链路压测找出瓶颈点。比如用户报告生成接口如果是CPU密集型压测时CPU达到80%就要考虑加机器或优化逻辑。活动前一周准备好降级预案包括静态化页面降级、非核心接口熔断、消息队列削峰。比如用户年度报告这种业务核心数据是听歌记录这部分不能降级但好友互动、评论分享这类非核心链路在流量高峰时可以降级把资源让给核心链路。同时把告警阈值调低比如平时成功率99%才告警大促时降到98%就要告警因为越早发现越容易处理。活动中/后安排人员盯屏每30分钟同步一次核心指标活动后要把压测数据和实际数据做对比记录问题和优化点输出复盘报告。第二道场景题是故障排查类的“某天晚间8点大量用户反馈无法播放歌曲可能的原因有哪些请写出你的排查思路。”这道题没有标准答案但答题时要体现出“从现象到定位从定位到解决”的完整链路。我的答题思路是先确认影响范围是所有用户都播放失败还是部分用户是所有歌曲都失败还是特定歌曲失败这个可以通过监控平台和用户反馈维度快速判断。如果影响所有用户优先看CDN和核心接口服务如果只影响部分用户看是不是地域性的网络问题或者客户端版本问题。接着逐层排查CDN节点是否异常→播放接口是否过载→服务日志有没有大量报错→依赖的音乐资源库是否可用→数据库是否有慢查询。如果问题定位到CDN先做节点切换和流量调度如果定位到服务看是否需要扩容、重启或者回滚版本。反馈和解决要同步进行不要等完全定位了才动手。这种故障排查题写答案的时候一定要有先后顺序体现出“先恢复后定位”的原则。生产环境里的故障处理永远是先止损再查因最后复盘。谁先做安全止损、把影响范围控制住谁才是合格的业务运维。3. 那些你没准备到但考到的题统信运维工具、直播场景、桌面运维腾讯音乐笔试的题目并不完全限定在互联网后端运维范畴有几道题如果平时只盯着云原生和大流量架构反而容易漏掉。这批笔试里出现了跟“统信运维工具”和“桌面运维”相关的考察点虽然题量不大但确实让不少人愣了一下。有一道选择题问的是“统信操作系统的运维工具LiveCD主要用来做什么”。这个知识点得稍微了解一下国产操作系统的运维生态。统信UOS的LiveCD本质上是一个可启动的应急修复环境类似Windows PE或者CentOS的rescue模式。当系统无法正常启动、root密码遗忘、引导损坏、分区表异常时可以用LiveCD启动到内存系统然后挂载原硬盘分区进行修复。选项里有一个干扰项是“通过LiveCD进行系统日常性能监控”这明显是错的因为LiveCD是应急环境不会用于日常运维。如果有做教育和政企运维背景的同学这道题几乎是送分题但对于一直在互联网公司做后端运维的人可能平时完全没接触过。桌面运维的考点是另一道案例分析题“企业办公电脑频繁出现卡顿、蓝屏、软件冲突问题作为运维工程师请制定一套桌面运维标准流程。”很多人一看这题就懵觉得互联网运维和桌面运维完全是两个工种但其实这道题考察的是流程规范化的能力跟具体技术栈无关。我的答题思路是分成三个阶段接入阶段统一资产登记给每台电脑建立唯一标识记录硬件配置、安装软件清单、入职离职时间。这样可以快速定位问题设备的型号和软件环境避免每次排查都让人重新报一遍电脑配置。处理阶段建立问题分级机制按影响程度分为“无法开机”“影响正常办公”“不影响业务的软件问题”三个级别不同级别对应不同响应时间。同时沉淀常见问题解决方案库比如蓝屏时先查dump文件和最近安装的驱动软件冲突时优先用进程隔离和版本回滚来处理。预防阶段统一系统镜像用标准化安装配合软件分发工具减少因环境差异导致的问题定期推送驱动更新和安全补丁降低蓝屏概率。这道题如果你真的没有桌面运维经验也不用慌核心逻辑是通用的流程标准化、问题分级处理、沉淀知识库、主动预防。把这个逻辑讲清楚阅卷人不会在意你有没有实际修过电脑。跟直播相关的题目也出现了这跟腾讯音乐近年主推的TME live业务是直接挂钩的。有一道单选问“直播推流超时无法开播优先排查哪个环节”选项有推流端网络、CDN上行节点、转码服务、播放端。正确答案是推流端网络和CDN上行节点因为推流超时的本质是上行链路问题播放端这时候还没参与进来。这种题考的就是对直播链路的基本认知业务运维至少要知道推流端→CDN上行→转码服务→CDN分发→播放端这条链路的每一个环节分别负责什么。4. 笔试答题的实战策略哪些误区会让你无意识丢分经历过这次笔试之后我对大厂运维岗笔试题的出题逻辑有了更清晰的认识。大部分题目并不是考背得多熟而是考你在真实运维场景里的判断力但很多人在答题方式上有几个常见误区导致失分很可惜。4.1 多选题选错策略少选和错选是大坑多选题目一共10道腾讯音乐的多选题规则是少选不得分、错选不得分。这个规则在部分考试里是“少选得一半分”但腾讯音乐笔试明确不是所以做多选题的策略切忌贪多。我的建议是一道多选题如果能把两个选项确定是对的剩下的选项不确定那我们宁可只选两个确定的。虽然不能拿满分但也别因为多选一个错的直接归零。这背后其实也反映了一个真实的运维工作习惯在生产环境里做变更时应该是“能少动就少动能不动就不动”而不是追求面面俱到。你太贪心想把所有依赖都升级一遍结果往往就是引入一个不兼容的坑。做多选题也是一样拿不准的就不选。4.2 简答题别写“关键字”而要写“链路”简答题是最能拉开差距的模块但也是最容易被误解的模块。很多人以为简答题只要把关键点写出来就行比如问“排查CPU飙高的步骤”就写“top、vmstat、strace”三个命令。这在阅卷人眼里只能拿基础分因为他不只想知道你会用什么命令更想知道你看到命令输出之后是怎么判断的。举个例子一道简答是“服务器CPU负载突然升高请写出排查思路”。正确答案的思路应该是分层的先用top查看进程维度的CPU使用率确认是用户态高还是内核态高。如果是用户态高用top -Hp pid找到具体线程再用jstack或者pstack把线程栈打出来看是不是代码死循环、GC线程还是业务逻辑问题。如果是内核态高可能是系统调用频繁用strace -c -p pid统计系统调用次数重点看futex、epoll_wait这些异常高的调用。同时查看负载均值uptime配合vmstat看runnable进程数和阻塞进程数判断是CPU瓶颈还是IO等待导致的假性高负载。简答题一定要把“命令判断逻辑结果处理”写完整才能体现出你的实战经验。命令拼错了不会直接零分整个排查链路不完整反而才是拿不到分的关键原因。4.3 尽量给出数值和参数而不是只说“调大一点”阅卷人特别看重的一个点是你给的方案里有没有具体数值。如果问“连接数满了怎么处理”你只写“调大连接数上限”这等于没答。你要写出具体的参数和命令比如修改/etc/security/limits.conf中的nofile或者调整内核参数net.ipv4.ip_local_port_range把端口范围从默认的32768-60999扩展到1024-65535。再比如面试里经常问的“TIME_WAIT过多怎么办”除了改net.ipv4.tcp_tw_reuse还要同时说明开启的前提条件——必须确保TCP时间戳选项是开启的否则会引发序列号混乱。这些细节才能体现你真的在生产环境里处理过问题。4.4 时间不够时案例题优先级最高整套卷子如果做到最后发现时间不够了优先把案例题补充完整哪怕选择题空着不猜。因为案例题分值高、主观空间大写了一个完整的排查链路至少能拿60%的分数而选择题猜了也不一定对多选还容易倒扣。我记得当时做最后一道案例题时只剩下大概10分钟我快速把“排查思路”分成了5个步骤每步用一行概括没有详细展开最终也拿到了不错的案例分。5. 笔试后的延伸准备同一套题目面试还会从这几个角度追问笔试结束之后不要以为就完事了。腾讯音乐的面试官手里是有你的笔试答案的面试时很可能从笔试题目里挑几道做深度追问。我后来在面试环节就被问到了笔试中的两个点一个是K8s调用containerd的整条链路另一个是大促保障方案中压测的具体操作方式。这里把延伸准备的方向也一并整理出来方便大家提前打底。5.1 K8s与容器运行时的深入追问方向如果笔试考了K8s调用containerd那面试环节十有八九会问这几个延伸问题为什么Kubernetes从1.24版本开始移除了dockershim答案核心是dockershim只是K8s为了兼容Docker而做的一层胶水代码维护成本高而且Docker本身提供的很多能力在K8s场景下根本用不到直接通过CRI对接containerd更轻量、更稳定。这个问题的深层逻辑是理解“抽象层越少故障点越少”。如何排查Pod一直ContainerCreating的问题这个就是纯实战题了。先kubectl describe pod看事件常见原因包括镜像拉取失败、存储卷挂载失败、CNI网络插件未就绪。如果事件信息不明显再用journalctl -u kubelet查看kubelet日志因为CRI调用containerd失败的信息往往会记录在kubelet日志里。5.2 大促保障与容量压测的深入追问方向笔试写了大促保障方案面试时面试官直接追问“你压测的时候主要看哪些指标”。这个问题需要答出业务指标和系统指标两个层次。业务指标包括接口成功率、响应时间的P95/P99、错误率系统指标包括CPU使用率、内存使用率、磁盘IO、网络带宽、TCP连接数、数据库连接池使用率。还要能说出“性能拐点”这个概念也就是随着并发量增加响应时间出现急剧上升的那个点这个点往往就是系统能承载的极限流量。压测的过程中要同时观察这些指标才能准确判断扩容的时机和规模。还会追问“如果压测时发现数据库连接池满了你怎么处理”。这个问题考察的不只是加大连接池而是从根因上做判断连接池满往往意味着有慢SQL或者连接泄漏需要先查show processlist看是哪些SQL在占用连接有没有长时间不释放的事务然后在代码层面检查连接是否正常归还。直接把max_connections翻倍是治标不治本可能还会把数据库拖垮。以上这些延伸点是建议从笔试到面试的过渡阶段至少准备好的内容。大厂的运维面试本质上考察的从来都是同一套基本功基础是否扎实、排查链路是否清晰、有没有真实的生产经验。笔试只是在第一道关口把基本功不够扎实的人筛掉真正的较量从面试才开始。整轮笔试做下来我最深的一个感受是运维岗的考察方向这几年变化确实不小。如果你只准备Linux命令和网络基础勉强能过选择题但在案例题和简答题上会非常吃亏。现在的业务运维要求的是能够从架构层面理解系统的人而不是只会执行命令的操作手。把K8s的调用链、MySQL的索引原理、Redis的数据结构、CDN的调度逻辑都串起来才能在这场考试里真正拿到高分。准备的过程也不要只刷题最好能在自己的测试环境里把每个知识点实际操作一遍比如用kubeadm搭一套K8s集群然后用crictl去查看容器运行时状态再手动拉一次containerd的调用链路。实际动手跑过一遍和看十篇解析文章的效果完全不一样。