看到“2024年春招-小红书-测试运维岗-第一批笔试”这个题目我的第一反应是终于有人把这场笔试的完整复盘写出来了。作为一个去年秋招和今年春招都投了小红书、并且在测试和运维两个方向都摸爬滚打过的过来人我可以负责任地说小红书的笔试题型在互联网大厂里属于“看着不难、做起来扎心”的那一类——它不考你背了多少八股文而是考你有没有真正在Linux服务器上处理过问题、有没有见过线上告警、有没有写过能跑的自动化脚本。这篇复盘我尽量把还记得住的题目方向、踩坑细节和备考逻辑都写清楚给后面要参加笔试的同学一份真实可参考的路线图而不是那种“建议多刷题”的废话。先说下这场笔试的基本盘考试时间120分钟题型分为四块——单选、多选、判断题、编程题有的批次还有简答题/场景题整体难度中等偏上。和纯后端开发岗不同测试运维岗的笔试题特别“杂”它既有Linux命令和网络协议的基础题又有CI/CD、容器化、自动化测试框架的实战题还会穿插几道让你现场写脚本的小题。很多科班出身的同学容易在Linux常用命令和网络排障上翻车而半路转行的同学又往往挂在编程题上。所以这篇文章我会按我实际答题的顺序和记忆把这次笔试的核心考点、解题思路、以及我当时是怎么绕开那些坑的全部拆开来讲。1. 笔试开场的题型布局与答题节奏先保基础分再攻编程题1.1 选择题占比最大题目分布有明显倾向进入笔试系统后第一屏是单选和多选混在一起大概40道左右占分比接近50%。这里的题目分布有一个很明显的倾向Linux命令和网络基础占了将近一半然后是数据库和中间件最后才是测试理论。以我印象比较深的几道题为例grep、awk、sed三者的适用场景区分给你一段日志让你选出能提取出IP地址的命令组合。tcpdump抓包后如何过滤出特定端口的流量选项里夹杂着-i、-nn、-c这些参数的含义。kill -9和kill -15的区别以及哪些信号不能被捕获。数据库隔离级别中REPEATABLE READ和READ COMMITTED在MySQL默认配置下的区别。Kubernetes中Pod和Deployment的关系以及Service的ClusterIP和NodePort的适用场景。说实话这些题单独拿出来都不难但放在同一场考试里就考验你的知识广度了。我当时的策略是遇到拿不准的多选题宁少选不错选因为多选错选是倒扣分的具体扣分规则以当年公告为准但保险起见别贪多。尤其要注意的是小红书的题目里会出现“反套路”选项——比如问awk默认分隔符它给你一个-F:的参数题选项里会混着cut -d的用法如果你没实际在终端里跑过这两个命令很容易选错。1.2 判断题里藏着易混淆的边界知识判断题大概10道左右分值不高但却是整张卷子里最“阴”的部分。为什么说阴因为它专门挑那些“好像对、其实错”的知识点考。我记得比较清楚的两道“在Linux中chmod 777可以修改文件的所有者。” 这显然是错的chmod只改权限位改所有者要用chown。但如果你平时只记住chmod能改权限没有深究过文件属主这个概念这一题很容易凭感觉选对——虽然简单但这就是在检验你基础扎不扎实。“使用ping命令可以判断目标主机的某个端口是否开放。” 这也是错的。ping走的是ICMP协议和TCP/UDP端口没有直接关系。判断端口通不通你得用telnet、nc或者ss -tlnp。这道题对于做过实际网络排障的人是小菜一碟但对只在模拟环境里敲过命令的同学来说就是个陷阱。判断题的备考思路很简单你不需要背大量冷门知识只需要把Linux文件权限、进程管理、网络协议、数据库事务这几个高频考点的“边界条件”弄清楚尤其是那些“能做什么”和“不能做什么”的边界。我建议你在刷题时专门建一个“易混清单”把这类成对出现的知识点放一起对比记忆。1.3 时间分配前60分钟必须结束客观题整个考试是120分钟我个人的节奏是客观题单选、多选、判断控制在60分钟内完成留20分钟给简答/场景题最后40分钟写编程题。编程题看起来分值高但如果前面的基础题错太多编程题再完美也拉不回来。我见过不少同学在选择题上抠一道多选题抠了10分钟结果后面编程题没时间写这是最大的失策。客观题的每一分都相对好拿而编程题是按测试用例给分的哪怕你只写对一部分逻辑也能拿一半分。所以我的建议是客观题遇到卡壳超过1分钟的先标记跳过等所有会做的做完了再回头想。这一条看似老生常谈但在真实考场上能严格执行的人并不多。2. Linux与网络排障运维岗笔试题的“送分题”和“送命题”2.1 Linux常用命令不只考命令本身还考组合用法小红书测试运维岗的笔试对Linux命令的考察特别“实操向”。它很少直接问“ls命令的作用是什么”而是给一个运维场景让你选出合适的命令组合。比如线上服务器的磁盘空间告警需要找出/var/log目录下占用空间最大的前5个文件并清理掉3天前的日志。请选出正确的命令组合。这种题其实就是把du、sort、head、find、rm这几个命令串起来。我当时选的是du -ah /var/log | sort -rh | head -5 find /var/log -type f -mtime 3 -exec rm -f {} \;这里有几个细节要注意du -ah中的-a表示显示文件而不仅仅是目录-h是人性化显示sort -rh中的-r是倒序-h是配合人性化单位排序。如果你只看过命令参数表但没有实际操作过很可能会漏掉sort -h这个关键点导致排序结果不对。类似这种“组合拳”式的题目在整张卷子里至少有五道以上。另一个高频考点是grep和正则表达式的组合。比如题目给出一段Nginx访问日志让你统计出所有状态码为502的请求IP。这个题既可以用grep直接过滤也可以用awk加条件判断grep 502 access.log | awk {print $1} | sort | uniq -c要注意的是awk默认按空格分隔$1就是客户端IP。如果你对awk的字段概念不熟这道题就会变成一道“看着简单但无从下手”的题。我的建议是grep、awk、sed这三个文本处理工具一定要能默写出常用参数并且至少在实际日志文件上练过10遍以上。2.2 网络基础与排障工具从“背概念”到“看场景”网络部分的题目和你在学校里学的《计算机网络》考试完全是两码事。它不问你“TCP三次握手是哪三次”而是给你一个线上故障场景让你判断问题出在哪一层。举个例子有一道我记得很清楚用户反馈网页加载很慢开发排查后认为不是应用代码问题。作为运维你应该按什么顺序排查请选择最合理的排查路径。选项里有A. 先查DNS解析再查TCP连接再查HTTP响应时间B. 先重启应用再看日志C. 直接看数据库慢查询D. 先检查服务器负载再检查网络带宽这题答案其实没这么死。合理的思路是先用dig或nslookup确认DNS解析是否正常再用curl -w查看TCP连接时间和TTFB最后用tcpdump确认是否有丢包重传。这是一条自下而上的排查链。如果你没有真实处理过“页面加载慢”的问题很容易被选项C带偏因为一提到“慢”很多人的第一反应是数据库慢查询。但事实上在没有确认基础网络没问题之前直接跳到底层组件去排查很可能会绕一大圈弯路。还有一个高频考点是tcpdump和ss。笔试里会给你一个抓包文件的描述问你如何确认是否存在TCP重传。我当时遇到的题目是tcpdump -i eth0 tcp port 8080抓到包之后如何确认哪些包是重传包选项里有tcp.analysis.retransmission——如果你用过Wireshark就会知道这是Wireshark的显示过滤器不是tcpdump的语法。但如果你只听说过tcpdump能抓包没有实际打开过Wireshark分析过包这道题很容易凭感觉选错。所以我的建议是运维方向的笔试准备不仅要会跑命令还要会用图形化工具去验证命令行抓到的结果把“命令输出”和“图形展示”对应起来。2.3 系统服务与进程管理你的“运维直觉”在这里被检验进程管理这块考得最多的是systemd。判断题和单选题里频繁出现systemctl status、journalctl -u、systemctl daemon-reload这些命令的适用场景。有一道比较典型的题修改了某个service的unit文件后需要执行什么命令才能让配置生效答案是systemctl daemon-reload。这个命令的作用是重新加载systemd的unit文件而不是重启服务。很多同学会选成systemctl restart xxx这就是对systemd工作机制理解不深导致的。restart是让服务进程重新启动但如果你改了unit文件里的启动参数不先daemon-reload的话重启后用的可能还是旧配置。我记得还有一道关于kill信号的题kill -9和kill -15的区别。这里的关键点是-15SIGTERM是通知进程“请你退出”进程可以捕获这个信号做清理工作而-9(SIGKILL是强制杀死进程没有机会做任何清理。在笔试场景里它会给你一个场景某个Java进程内存溢出但你又希望它能输出堆转储文件后再退出应该用哪个命令答案是kill -15因为你得让JVM有机会执行shutdown hook。这道题会做的同学说明是真的处理过线上JVM问题不会的同学也能通过这道题知道自己缺什么。3. 容器化与CI/CD测试运维岗绕不开的“现代基础设施”3.1 Kubernetes知识点从Pod到Service的一整条链路小红书的笔试里Kubernetes相关的题目比例相当高这和他们的技术栈有关系。题目不是直接考你“Pod是什么”而是给你一个具体的部署需求让你选择正确的资源配置方式。我印象最深的一道题一个无状态服务需要部署3个副本并且希望流量能自动负载均衡到这3个副本上。应该创建什么资源答案显然是DeploymentService。但选项里会有StatefulSet、DaemonSet、Job来干扰你。如果你只是背过“Deployment用于无状态应用”这句话而没有真正部署过可能分不清StatefulSet和Deployment的区别。我的理解是StatefulSet适合有唯一网络标识和稳定存储的状态ful应用比如数据库Deployment则适合可以随意替换副本的普通Web服务。更有意思的是有一道题通过kubectl命令来考察你对Pod生命周期的理解kubectl get pods显示某个Pod一直处于ContainerCreating状态可能的原因是什么选项里包括镜像拉取失败、资源不足导致调度失败、探针配置错误、Pod正在正常启动。答案是前两者都有可能但探针配置错误通常会导致Pod变成Running但NotReady而不是停在ContainerCreating。这道题如果你没有实际用kubectl describe pod排查过问题很容易把“探针失败”也选进去。我当时做这道题时心里想的就是这不就是我在测试环境里天天看到的现象吗所以对于想走运维方向的同学我特别建议你本地装一个minikube或者kind亲手把Pod卡在ContainerCreating、ImagePullBackOff、CrashLoopBackOff这几个常见状态都复现一遍比背十遍概念都管用。3.2 CI/CD流水线不是考Jenkins配置而是考流程设计在CI/CD这个方向上小红书的笔试没有直接让你写Jenkinsfile那是面试环节可能会聊的而是用选择题来考你对“持续集成”和“持续交付”的理解。有一道题是在代码提交后CI流水线中应该最先执行哪一步选项A. 单元测试B. 构建镜像C. 代码静态检查LintD. 部署到生产环境答案是C。因为静态检查是成本最低、速度最快的校验手段它能在几秒内发现代码风格问题、潜在的空指针引用等低级错误。如果代码连静态检查都过不了就没有必要进入下一步的单元测试和构建流程。这道题的逻辑其实就是一个“质量左移”的原则把能尽早发现的问题尽量往前放。很多没接触过CI/CD的同学会选A觉得“测试当然要最先跑”。但从流水线设计者的角度看Lint比单元测试更快更便宜先跑Lint可以减少后面阶段的无效消耗。另一道和镜像构建相关的题也比较典型Docker镜像构建时如何减少镜像体积并提高构建速度正确答案是多阶段构建multi-stage build。比如用第一个阶段编译源码第二个阶段只拷贝编译产物FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o myapp FROM alpine:latest COPY --frombuilder /app/myapp /usr/local/bin/myapp CMD [myapp]这样最终镜像里只有可执行文件和运行环境没有编译器、没有源码。如果笔试问你“以下哪个命令可以查看镜像分层信息”答案是docker history而不是docker inspect虽然inspect也能看到一些元数据但分层历史是用history看的。这些细节你只在文档里看过但没有亲手构建过镜像真的很容易选错。3.3 Jenkins与自动化测试的集成测试岗的必答题测试方向的同学笔试里会有不少和Jenkins集成相关的题。比如在Jenkins流水线中如何确保自动化测试失败时流水线停止并且发送通知这里涉及post阶段的使用pipeline { agent any stages { stage(Test) { steps { sh pytest tests/ } } } post { failure { emailext( subject: Pipeline Failed: ${env.JOB_NAME}, to: teamexample.com, body: Tests failed. ) } } }笔试不要求你默写整段代码但会问你post块中的failure条件和always条件有什么区别我的理解是always无论前序阶段成功与否都会执行failure只在失败时执行。这个概念如果没真正配置过邮件通知、企业微信通知这些场景很容易搞混。另外Appium作为移动端自动化测试的框架在测试岗笔试里也是高频词。笔试通常会问的是Appium基于什么协议驱动iOS和Android应用答案是WebDriver协议W3C。如果你只是用过Appium Desktop录制脚本没有看过它的架构图这题也能蒙对。但真正拉开差距的是这种题在使用Appium进行Android自动化测试时desired capabilities中appPackage和appActivity的作用是什么这题就是考你“知不知道启动一个App需要先告诉Appium要启动哪个包的哪个界面”。我见过不少同学一看到appPackage就懵了因为他们平时跑脚本都是复制网上的模板从没理解过这两个参数的意义。所以备考测试岗时我强烈建议不要只会跑现成脚本至少亲手用Appium连接一次模拟器指定一个App的包名和Activity启动起来这样笔试里遇到related配置的变种题才不会慌。4. 编程题与场景题笔试里真正拉开差距的部分4.1 编程题的常见类型日志处理与字符串操作小红书测试运维岗的编程题整体难度不低但很偏向实际工作。它不太会考“给你一棵二叉树让你翻转”这种纯算法题而是倾向于让你写“处理线上日志”“解析配置文件”这类有现实背景的小程序。我当时遇到的编程题大意是给定一个Nginx访问日志文件字段包括IP、时间、请求方法、URL、状态码、响应大小统计出每个IP的请求次数并输出前10个访问量最高的IP按降序排列。这是一道典型的文本处理题。你可以用Python写from collections import Counter with open(access.log, r) as f: ip_list [line.split()[0] for line in f if line.strip()] counter Counter(ip_list) for ip, count in counter.most_common(10): print(f{ip} {count})如果你熟练,更可以用Linux命令一行搞定awk {print $1} access.log | sort | uniq -c | sort -rn | head -10笔试系统通常支持Python和Shell两种语言。我的建议是如果你Python更熟就用Python如果你Shell更6就用Shell。重点是思路清晰、有注释、边界条件考虑完整。比如上面的Python版本里if line.strip()就排除了空行这种细节虽然不影响主流程但阅卷官是会看的。还有一道和字符串相关的编程题给定一个字符串输出它反转后的结果同时要求去掉其中的数字字符。这道题有多简单呢Python里两行s abc123def456 result .join(ch for ch in s[::-1] if not ch.isdigit()) print(result)但就是这种简单的题在笔试里最容易翻车的一点是Python的[::-1]切片表示反转而不是reverse方法。reverse是列表的方法字符串没有reverse()。如果你复习时只看API文档但没动手写过很容易在字符串反转这里卡壳。4.2 场景题如何回答“线上服务突然变慢”运维岗的笔试除了编程题通常还有一两道场景题/简答题要求你用文字描述排查思路。小红书在这方面特别爱考“综合排障”类题目。我记得有一道题是某天晚上8点你收到线上告警某核心服务的响应时间从50ms飙升至5s。请描述你的排查思路。这种题没有唯一标准答案但阅卷时看的是你的思路是否“有层次”。我当时是分四步写的先看监控定范围打开Grafana先确认是所有接口都变慢还是只有某个接口变慢。如果是单接口变慢大概率是依赖的下游服务或数据库出了问题如果全站变慢优先怀疑服务器资源CPU、内存、磁盘IO、带宽。登录服务器看基础指标用top看CPU负载用free -h看内存用iostat看磁盘IO用iftop看带宽占用。如果CPU使用率不高但响应慢很可能是锁竞争、IO等待或线程池耗尽。看日志和链路追踪用journalctl -u xxx查最近的应用日志输出错误堆栈再配合链路追踪系统比如SkyWalking、Jaeger看具体是哪个上游调用耗时增加了。回滚或降级如果确认是最近一次发布导致的问题执行回滚如果是下游依赖抖动评估是否需要降级到本地缓存。这道题我不确定自己答得有多好但我后来复盘时意识到这种题的重点不是“你答了什么”而是“你有没有一套自己的排障SOP”。如果你在答题时能写出“先看监控、再查资源、再看日志、最后回滚”这条清晰的链路哪怕细节不够丰富阅卷官也能看出你是有实战经验的。怕的是那种想到哪写到哪、想到一个命令就写一个命令的答案没有逻辑主线。4.3 编程题的时间预算40分钟两道题如何分配编程题通常有两道分值是2020或者1525。我当时的做法是先花5分钟把两道题都读一遍判断哪道更简单先写简单的保底再攻难的。第一道日志统计大概15分钟就能写完第二道题如果思路卡住先写一个能处理常规用例的版本哪怕不能覆盖所有边界情况。笔试的判分系统是按测试用例通过的百分比来给分的你写一个“半成品”可能通过60%的用例拿到12分但如果你什么都不写就是0分。所以我的建议是哪怕思路不完整也要把主流程写出来然后注释里说明“这里还有XX边界情况没处理”这比空着强太多了。还有一个小细节笔试编程题的输入输出通常是标准输入输出stdin/stdout而不是从文件读取。很多人练习时习惯用open(file.txt)读文件结果笔试时完全没有文件可读导致整个程序跑不起来。所以备考时一定要适应“从sys.stdin读入”的写法。5. 那些笔试前没人告诉你的“应试潜规则”5.1 这份岗位的笔试到底在筛选什么人考完这一场我最大的感受是小红书的测试运维笔试本质上是在筛选“动手做过事”的人。它的大多数题目都是从真实工作场景里摘出来的片段比如“线上服务变慢”“磁盘空间告警”“自动化测试失败后如何通知”——这些不是光靠背面试题就能答好的。回头看我的备考过程最有用的不是刷了几百道牛客网的题而是我真的在本地搭过一套环境装过Linux虚拟机、部署过Nginx、用Python写过自动化测试脚本、用Docker跑过MySQL、在Jenkins上跑过一次完整的流水线。这些经历让我看到笔试题目时脑子里能浮现出“我当时是怎么操作的”而不只是“我背过这个选项”。5.2 笔试中的时间管理比多对一道题更重要我有个很难忘的教训在这次笔试之前我参加的另一家公司的笔试在一道多选题上纠结了7分钟结果后面编程题因为时间紧第一道题都没写完。从那之后我就给自己立了规矩选择题超过90秒做不出来先蒙一个标记跳过编程题先读题5分钟然后严格遵守“先易后难”的原则。这场考试我用同样的策略提前10分钟做完了全部题目还有时间回头把之前跳过的3道选择题重新思考了一遍。最终改对了2道。所以我觉得备考时练习“按时间做题”和练习“做对题”同样重要。5.3 笔试结束后的复盘才是拉开差距的开始出考场后我做的第一件事不是对答案而是把还记着的题目写到一个文档里按“不会的”“蒙对的”“确定答对的”三个维度分类。然后针对“不会的”和“蒙对的”去查资料、补知识。比如我发现自己对sort -h这个参数不熟就专门去查了它的实现原理发现自己分不清StatefulSet和Deployment就动手在kind集群里各部署了一个应用看区别。我的经验是笔试本来就是一次特别好的“知识体检”它把你不会的东西明明白白地暴露出来。如果你只是考完就完了那这些坑你下次还会踩但如果你认真复盘把每个不确定的选项都搞懂那这场笔试哪怕没过也等于帮你省了20小时的盲目复习时间。6. 写在最后测试运维岗笔试的长期打法6.1 给未来考生的一份“最小可行动清单”根据这次笔试的经验我整理了一份针对小红书测试运维岗笔试的备考清单不一定面面俱到但覆盖了高频考点Linuxgrep、awk、sed、find、du/df、ss/netstat、tcpdump、systemctl/journalctl每个命令至少要在真实文件上练过不能只看文档。网络OSI模型/TCP/IP基础、DNS解析流程、HTTP状态码含义、用curl和tcpdump排查“页面加载慢”的完整过程。容器化与编排Dockerfile编写、镜像构建与分层、docker compose基本使用、Kubernetes的Pod/Deployment/Service/ConfigMap概念以及kubectl常用命令。CI/CD与自动化Jenkins流水线的基本结构pipeline/stage/post、pytest/Appium的基本使用、接口测试的断言逻辑。编程Python标准库的文件操作、字符串处理、Counter统计、标准输入输出Shell的管道、循环、变量处理。6.2 长时间备考曲线而不是突击刷题最后说点掏心窝子的话吧。如果你现在离笔试还有两个星期以上我真心建议不要把所有时间都用来刷笔试题。至少留出一半时间亲手“玩一玩”那些技术自己装一个Ubuntu虚拟机在上面部署一个Web服务然后用tcpdump抓包看三次握手自己写一个Python脚本跑一遍自动化测试然后挂到Jenkins上定时执行自己把一个容器化应用部署到Kubernetes里观察Pod调度的整个过程。这些操作看起来“慢”但它带给你的理解深度是刷500道题都换不来的。笔试题目会变但“会不会动手”这个问题在一道道场景题和编程题里暴露得清清楚楚。希望这篇复盘能帮你在备考路上少走一点我走过的弯路。