企业官网建设流程全解析

从2023年牛客一模运维笔试说起，聊聊运维这份工作到底在考什么

又到了一年最热闹的求职季，不少转行过来的朋友和刚毕业的学弟学妹都在刷题备考。前阵子我完整做了一遍2023牛客模考（一模）的运维笔试卷子，做完之后最大的感受是：这套题出得挺有水平的，不是单纯背命令、背面试八股就能拿高分，它在很认真地考察一个人到底有没有用运维的思维方式去解决问题。

先说下背景，牛客模考的运维试卷面向的人群很明确：想走运维开发、Linux运维、云计算运维方向的求职者，以及刚入行一两年想系统自测一下的初级工程师。整套卷子覆盖了Linux基础命令、网络排障、系统服务管理、Shell脚本编写、数据库基础、监控与安全这几个大块。题型有单选、多选、判断题和两道实操大题，难度分布大致是基础题占四成、进阶题占四成、偏综合的题占两成。整体来看，这套题不是为了难倒你，而是为了筛出那些“真的碰过服务器”的人。

有朋友可能会问：一份线上模考的笔试题目，考完对完答案不就完了吗，有什么好专门写一篇长文来聊的？我自己的看法是，这套题的价值不在题目本身，而在于它非常典型地反映了当前运维岗位的考察逻辑和行业对运维工程师的能力预期。把这份卷子吃透，你基本就能摸清市面上大部分中小型互联网公司和部分国企的运维笔试套路。接下来我按模块做一次完整复盘，把每道题背后想考察的点、常见的坑、以及对应的实操经验都摊开来聊一聊。

1. 整体试卷设计与考察思路拆解

1.1 这套卷子到底在筛什么人

先说个题外话。我见过太多准备运维面试的人，把精力全花在背“Linux常用命令大全”上，什么tar的参数、grep的正则、find的用法背得滚瓜烂熟，结果一到实际场景就懵了。为什么？因为笔试和面试官真正想看的，不是你知道多少条命令，而是你在一个具体问题面前，能不能快速定位、合理选择工具、并且考虑到边界情况。

2023牛客一模这套卷的出题逻辑就很明显——它默认你是一个“已经碰过Linux机器的人”，题目里几乎没有纯默写题，每一道题都带着一个mini场景。比如它不会直接问“如何查看系统负载”，而是给你一段top命令的输出截图，问你哪个字段代表平均负载、哪个进程在消耗CPU。这就是典型的场景化考察，你做没做过真实排障，一眼就能看出来。

这套卷子的考察重点，我总结下来大概覆盖三个层面。第一个层面叫“知道有什么”，对应的是基础广度，比如常用命令、常见端口、常见服务配置文件，这类题占比大概四成。第二个层面叫“知道怎么用”，对应的是工具熟练度，比如给一个日志文件让你用awk提取某个字段，给一个服务让你用systemctl完成重启和开机自启，这类题占比大概四成。第三个层面叫“知道为什么”，对应的是原理理解，比如问为什么数据库连接池要配置最大连接数，为什么Nginx的worker_processes建议设为CPU核数，这类题占比最少但区分度最高，大概两成。

1.2 为什么越来越多的笔试开始重视场景化

我前几年帮公司面试过几轮运维，最大的感受是：传统的八股题已经筛不出人了。什么叫八股题？就是“请简述Linux的启动流程”“请说出TCP三次握手的过程”“请写出rsync和scp的区别”这类。不是说这些知识不重要，而是它们作为笔试题目太过“静态”，只要认真背过几天资料，基本都能答个七七八八。可一旦到了实际工作上，面对一台CPU飙到100%的线上机器，很少有人能靠背过的启动流程解决问题。

所以你会发现，最近两三年的运维笔试题，不管是牛客上的模考，还是企业自己出的校招题、社招题，都往场景化方向走。所谓场景化，就是给你一个具体的“故障现场”或者“业务需求”，让你用运维的手段去解决它。这套卷子里那道关于“网站访问慢，如何排查”的多选题特别典型——它不问你某个单一命令，而是给你一个完整的排查链路，让你按顺序选出最合理的操作。这种题考察的就不再是记忆，而是你脑子里有没有一个成体系的排障SOP。

1.3 一份卷子的时间分配和答题策略

这里插一句我个人的做题经验。这份卷子我拿到手先扫了一遍所有题目，先做有把握的基础题和判断题，再做需要动笔计算的题，最后留足时间做两道实操大题。结果比我第一次拿起卷子就从头做到底的体验好很多。原因很简单，运维笔试的时间通常是够的，但人的状态是波动的。先做会做的题能建立信心，也能保证基础分先落袋，后面遇到难题心态不会崩。

还有一个小技巧：多选题是丢分重灾区，选错一个就全错，所以拿不准的选项宁可不选。我见过太多人栽在多选上——明明五个选项里三个是确定的，剩下两个模棱两可，很多人抱着“搏一搏”的心态全选上，结果一分没得。运维工作的特点就是谨慎、稳妥、考虑后果，这个思维其实在做多选题的时候就已经在被考察了。

2. 高频考点深度解析：从Linux命令到网络排障

2.1 Linux命令类题目：不只是“知道”，而是“用过”

先聊这份卷子里占比最高的Linux命令类题目。这类题看着基础，但想拿满分并不容易。我印象比较深的一道题是这样的：给了一个包含Nginx访问日志的文件access.log，日志格式是标准combined格式，问如何统计出访问量最高的前10个IP地址。答案选项里有awk、sort、uniq、head这几个命令的几种组合。

这道题表面上是考命令，实际上考的是你知不知道这几个命令的协作关系。正确答案是awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10。这里有几个隐藏的细节：第一，awk '{print $1}'用来提取IP，前提是你知道combined日志格式里IP是第一列；第二，uniq只能去重连续的行，所以前面必须先sort；第三，uniq -c统计次数后结果是无序的，需要再sort -rn按数字降序排列；最后head -10取前十条。

这道题我在帮人改简历的时候经常拿来举例，因为它太典型了。很多人在简历里写“熟悉Linux常用命令”，但真让他现场写一条统计日志的管道命令，他能卡半天。说到底，这类题没有捷径，唯一的办法就是自己在服务器上多敲、多试。我建议准备笔试的朋友可以自己造一份access.log，用各种姿势去折腾它，今天统计IP，明天统计PV，后天统计某个接口的响应时间分布，把awk、sed、grep、sort、uniq这些命令练成肌肉记忆。

另一个高频考点是文本处理三剑客的对比。卷子里有一道判断题，说“grep只能用于查找文件内容，不能用于过滤管道输出”，这句话是错的，因为grep配合管道使用是再常见不过的操作，比如ps aux | grep nginx。但这里有个更隐蔽的坑：grep过滤进程时经常会把自己那个grep进程也匹配进去，所以老手通常会在关键词上加一个字符类，写成ps aux | grep [n]ginx，或者直接pgrep nginx。这种细节题目里不一定考，但面试官聊到的时候很加分，因为它是真正踩过坑的人才懂的细节。

2.2 网络排障类题目：分层思维是核心

网络相关的题目在整份卷子里占了大概两成，但几乎每一道都有区分度。核心考察的是一个词——分层。说白了就是当网络出问题的时候，你能不能按照OSI模型或者TCP/IP模型一层一层往下排查，而不是像个无头苍蝇一样乱试。

卷子里有一道题我印象特别深刻：描述一个场景，某台服务器A访问另一台服务器B上的Web服务超时，问以下排查思路哪个最合理。选项包括：先ping测试网络连通性、直接看B服务器上的应用日志、先重启B服务器上的Web服务、先检查A的DNS配置。如果你按分层思维去走，正确答案很明显是先ping，因为第一步永远是确认链路通不通。如果ping通了，那就说明底层网络没问题，问题出在端口或应用层；如果ping超时，那就得往交换机、防火墙、路由那边查了。

这道题背后藏着很多新手常犯的错误——动不动就重启服务。我这个观点可能有点得罪人，但真的，我见过太多人一遇到“连不上”就重启服务，结果有时候确实恢复了，但问题根本没定位到根因，过了几天又复发。正确的网络排障流程应该是自上而下或者自下而上，我个人的习惯是自下而上：先看链路层（ping），再看网络层（traceroute + 检查路由），再看传输层（telnet测端口），最后才是应用层（看日志、看配置）。这套流程在笔试里是一个标准的答题框架，在实际工作中更是一个能救命的SOP。

另一个网络高频考点是常见端口号。卷子里有一个多选题，问哪些端口号与协议对应正确，选项里混了22（SSH）、80（HTTP）、3306（MySQL）、6379（Redis）、27017（MongoDB）。这个属于纯记忆题，没什么技术含量，但如果是裸考不去准备，真的很容易混淆。比如6379是Redis、6380是Redis的集群通信端口，这种细节一旦考到就是送命题。我给的建议是把常用端口整理成一张表，每次做题之前过一遍：22 SSH、25 SMTP、53 DNS、80 HTTP、443 HTTPS、3306 MySQL、5432 PostgreSQL、6379 Redis、9200 Elasticsearch、27017 MongoDB。表不在多，在于刻进脑子里。

2.3 系统服务与进程管理：别再只知道systemctl start了

系统服务管理这块，卷子里的题不算难，但很有代表性。最基本的考察是systemctl系列的用法——start、stop、restart、enable、disable、status。这些命令我猜大多数人都知道，但卷子里有一道题问的是“如何查看某个服务是否设置为开机自启”，选项里有systemctl is-enabled和systemctl list-unit-files | grep xxx两种做法。说实话两个都能达到目的，但考试通常只认最标准的答案。

这里我想多聊一点，因为这道题暴露了很多运维新人一个思维盲区：只知道“怎么启动服务”，不知道“怎么管理服务的生命周期”。在实际工作中，我们部署一个应用，绝不是systemctl start xxx就完事了，后面还有一堆事：要不要开机自启、日志输出到哪里、日志需不需要轮转、进程挂了systemd会不会自动拉起、资源限制怎么配、依赖关系怎么声明。这些在systemd的unit文件里都有对应的配置项，笔试虽然不会考你写一个完整的unit文件，但你在准备的过程中如果能把unit文件的几个关键段（Unit、Service、Install）弄明白，遇到这类题目就是降维打击。

进程管理方面，卷子里考了ps和top的常用参数，比如怎么查看所有进程（ps aux或ps -ef）、怎么按CPU或内存排序（top进去按P或M）。题目本身不难，但我发现一个普遍痛点：很多人不知道top命令运行时的交互快捷键，导致面对一张top输出截图时不知道第一行的load average是什么意思，也不知道%CPU和%MEM列的单位。其实top第一行的三个load average值分别代表1分钟、5分钟、15分钟的平均负载，这个数值如果持续大于CPU核数的80%，基本可以判定机器负载过高了。

2.4 数据库与缓存基础：运维人躲不开的必修课

说实话，以前很多运维岗位对数据库的要求只是“会重启MySQL”就行，但这两年不行了。云原生、容器化普及之后，运维工程师的工作边界在往外扩展，数据库和缓存的日常运维越来越成为面试和笔试的必考点。2023牛客一模这套卷子也跟上这个趋势了，数据库相关题目大概占了15%左右，主要考MySQL和Redis。

MySQL部分有一道题是问InnoDB和MyISAM的区别，选项里有支持事务、支持外键、支持全文索引支持与否的对比。这个属于数据库基础中的基础了，但它很能看出一个人是真的用过MySQL还是只在网上看过概念。我最常举的例子是，如果你的业务有事务需求，比如转账场景，你基本不用犹豫，直接上InnoDB；MyISAM的全文索引在某些低并发的检索场景下还有一定优势，但整体上已经处于维护模式了。2023年之后MySQL 8.0早就成主流了，默认引擎就是InnoDB，所以这道题如果不了解背景，很容易想当然。

Redis的考察在卷子里偏向于基础数据类型和常见应用场景。有一道题问Redis的String、Hash、List、Set、ZSet分别适合什么场景，这个是送分题，但有一半人会在ZSet上犹豫。ZSet（有序集合）的核心特征就是有序，所以排行榜、延迟队列这类需要排序的场景就是它的主场。我建议准备笔试的朋友不要只背数据类型，尽量理解一下每种类型的底层实现，比如String底层是SDS，ZSet底层是跳表+哈希表，这样一旦遇到“为什么Redis的ZSet插入是O(logn)”这种进阶题，你也能聊上几句。

除了MySQL和Redis，卷子里还出现了一道关于慢查询的题，问的是发现数据库响应慢时第一步应该怎么做。正确答案是开启慢查询日志，找出具体的慢SQL。这个知识点不在常规备考清单里，但恰恰是实际运维中最高频的排查手段之一。我自己的经验是，MySQL的慢查询日志一定要开，哪怕平时在低峰期把阈值设长一点，一旦出了性能问题它就是最直接的线索。

3. 实操环节还原：脚本题与故障排查题的完整解题过程

3.1 场景题：写一个日志清理脚本，你会考虑什么

这套卷子的实操大题有两道，第一道是Shell脚本题，要求是：写一个脚本，实现每天凌晨3点清理/var/log/myapp/目录下超过7天的.log文件，并将清理结果记录到/var/log/cleanup.log。题目还要求脚本具备基本的安全性，不能因为目录不存在或者文件名为空而出错。

说实话，这道题难度不大，但它考察的细节非常多，特别适合用来筛掉“只会复制粘贴脚本”的人。我先给一个标准答案的样子：

#!/bin/bash LOG_DIR="/var/log/myapp" RETENTION_DAYS=7 CLEANUP_LOG="/var/log/cleanup.log" if [ ! -d "$LOG_DIR" ]; then echo "$(date '+%Y-%m-%d %H:%M:%S') ERROR: Directory $LOG_DIR does not exist" >> "$CLEANUP_LOG" exit 1 fi deleted_files=$(find "$LOG_DIR" -type f -name "*.log" -mtime +"$RETENTION_DAYS" -print -delete 2>>"$CLEANUP_LOG") if [ -n "$deleted_files" ]; then echo "$(date '+%Y-%m-%d %H:%M:%S') Deleted: " >> "$CLEANUP_LOG" echo "$deleted_files" >> "$CLEANUP_LOG" else echo "$(date '+%Y-%m-%d %H:%M:%S') No files to clean" >> "$CLEANUP_LOG" fi

这道题里藏着几个常见的坑，我挨个说。第一，很多人忘了检查目录是否存在，直接find $LOG_DIR一顿操作，如果目录不存在，find会报错，然后因为脚本里没有set -e，它还是会往下走，导致日志记录混乱。第二，RETENTION_DAYS=7这个参数我在脚本里用了双引号包起来，防止变量值为空时find命令把参数吞掉变成-mtime +直接语法错误。第三，用-print -delete组合可以一边输出删了哪些文件一边执行删除，这样不需要额外拿管道去处理文件列表。

然后是定时任务的配置。这道题如果你只写了脚本本体、没写cron配置，会扣掉一部分分数。正确的cron写法是0 3 * * * /usr/local/bin/cleanup_log.sh >> /var/log/cleanup.log 2>&1，注意脚本路径建议写绝对路径，而且脚本内最好cd到脚本所在目录或者全部使用绝对路径，避免相对路径导致找不到文件。还有一个细节是，cron执行环境默认是不加载用户profile的，PATH很有限，所以脚本内用到find、date这些命令时建议写绝对路径/usr/bin/find、/bin/date，或者至少在脚本开头把PATH导出一份。这些是笔试题目里不太会写出来的隐含要求，但真正在工作里写脚本的人都会注意。

3.2 故障排查题：网站500了，你怎么落地排查

第二道实操题是一个综合故障排查，题干大概是：用户在访问公司官网时偶尔出现500错误，通过运维平台看到后端应用某台服务器节点的CPU在错误发生时会突然飙升，请写出你的排查思路和具体操作命令。这道题是整份卷子里我最喜欢的一道，因为它完全没有标准答案，纯粹考察你脑子里有没有一套完整的排障框架。

我来说说我会怎么答，也给准备笔试的朋友一个参考方向。首先明确一点，500错误说明请求已经到达应用层了，所以的第一步不应是去查网络，而是去确认错误发生的时间窗口和规律。这时候我会先看Nginx的access log和error log，确认500响应码出现的URL和频率，同时利用date时间戳和日志里的时间做对齐，看看500错误是不是集中在某个时间段。然后我去看应用服务器的监控曲线，确认CPU飙升和500错误是否在同一时间点发生，如果是，基本可以断定是应用逻辑或资源竞争导致的。

接着进入第二层，定位到具体的进程和线程。我会用top -Hp <pid>查看该进程内部各线程的CPU占用，找到飙高CPU的那个线程ID，然后用printf "%x\n" <线程ID>转成十六进制，再用jstack <pid> | grep <十六进制线程ID> -A 30看到这个线程当前在执行的代码栈。这个过程在Java应用排障中是标准操作，卷子里虽然不要求你写得这么细，但你能写出top查进程、用jstack抓线程栈，已经能甩开大部分考生了。

如果你是面试聊到这道题，我建议再补充一个压测思路：在测试环境用ab或wrk对同样的接口做压测，复现CPU飙升的场景，然后结合jstack多次抓线程栈，看热点方法是否一致。这样做的好处是可以把“偶发500”变成一个可复现的问题，后面无论是调代码还是扩容都有据可依。在这套卷子的答题里，这个思路可以直接写成第3步。

3.3 实操题里的隐性加分项

实操题往往是阅卷最主观的部分，因为它没有唯一答案。我参加过几次笔试阅卷，发现真正能拿高分的卷子，通常都有几个共同特征：第一，命令写得全，关键选项没有落下；第二，思路是有顺序的，不是把知道的所有命令罗列一遍；第三，会提到“查看”、“确认”这类验证动作，而不是只写排查动作不写结论。

所以我给准备笔试的读者的建议是，遇到实操题，别急着堆命令，先在草稿纸上列一个三层结构：第一层是定位问题（看什么指标、看什么日志），第二层是分析原因（用什么命令、对比什么数据），第三层是验证修复（怎么确认问题解决了、怎么防止复发）。答题的时候按这个逻辑走一遍，哪怕某些命令记不全写法，整体骨架在那里，分数就不会低。

4. 失分点复盘与错题避坑指南

4.1 高频失分点：不是不会，是想当然

我做完这份卷子之后对照答案分析了一下，发现我的失分点主要集中在一类题目上——“想当然”的题。什么叫想当然？就是你看到题目第一眼觉得见过，凭印象选了一个答案，但没仔细审题，结果选项里藏着文字陷阱。

举一个非常典型的例子。卷子里有一道判断题问：rm -rf /和rm -rf /*是否等价。很多人一看，觉得一个是删除根目录，一个是删除根目录下所有文件，差不多，就选了“等价”。这个题其实有个隐藏知识点：在部分Linux发行版上，rm -rf /是会提示“rm: it is dangerous to operate recursively on '/'”并拒绝执行的，而rm -rf /*则会删掉根目录下所有可见的目录和文件（除非有额外保护）。严格来说，两者不完全等价。这种题纯粹考你有没有真正在服务器上敲过、有没有仔细看过命令的输出和提示。说句题外话，这种命令千万别拿生产机器测试，最好在虚拟机里试，试完你会对命令行有更深的敬畏心。

另一个高频失分点是用“Windows的思维”去答Linux的问题。卷子里有一道题问，Linux系统中如何查看某个端口的占用情况，选项里有netstat -tlnp和lsof -i:端口。很多新手会想到去任务管理器或者资源监视器，但Linux下最标准的就是这两个命令。netstat比较通用，lsof更强大，可以查到是哪个进程占用的。这里有个小坑：netstat -tlnp中的-p参数需要root权限，否则看不到PID和进程名，所以实际答题时如果场景是普通用户，ss -tlnp也是常用替代方案。这类命令在笔试里反复出现，建议直接记成固定组合。

4.2 争议题与偏题：遇到了也别慌

任何一份运维笔试卷子都会有几道让人想吐槽的题，这套一模卷也不例外。我记得有一道题问“你如何看待运维自动化”，选项里给了一堆听起来很玄的概念——AIOps、DevOps、SRE、ChatOps。说实话这种题没有标准答案，更多是考察你对行业趋势的了解程度。我的建议是，这类题别空着，尽量把概念跟实际工作场景结合起来答，哪怕只写一两句话，也比交白卷强。

还有一道偏题让我记忆犹新，考的是crontab中每5分钟执行的时间格式。大家通常背的是*/5 * * * *，但卷子把选项设计成了5 * * * *和*/5 * * * *，一眼看上去非常像。如果没有实际配置过cron，真的很容易选错。这个知识点虽然小，但在真实运维中太常用了，定时清理日志、定时同步数据、定时发报表，全都要用cron。为了彻底搞懂，我专门在服务器上做过实验：5 * * * *是每小时的第5分钟执行一次，*/5 * * * *是每5分钟执行一次，两者完全不同。这种题目一旦遇到，就是送分题和送命题的一念之差。

说真的，这种争议题和偏题在模考里很常见，它们的价值不在于让你拿分，而在于帮你发现自己知识体系里的盲区。准备笔试的过程本质上就是一个补盲的过程。我有个习惯，每次做完一套题，会把错题知识点整理成一张“知识盲区清单”，比如某个命令的参数记混了、某个服务的默认端口记错了、某个配置文件的路径不熟悉，然后花一周时间挨个在实验环境里实操一遍。这个方法看起来笨，但效果极好，因为笔试里重复考察的知识点就那么多，你补一个盲区就少一个失分点。

4.3 错题里的高阶思维：从“改答案”到“建立SOP”

如果你只把复盘停留在“哦，这里错了，正确答案是B”的层面，那这套题的价值只发挥了不到两成。我个人的习惯是，把每一道错题都映射到一个“如果我在生产环境遇到这个问题，我应该怎么做”的SOP里。比如那道关于网络排查顺序的题，我不光记住了“先ping”，而是借这个机会给自己建了一套完整的网络排障SOP：第一步检查本机网卡和IP配置（ip a），第二步ping网关确认二层和三层连通性，第三步ping目标IP确认跨网段路由是否可达，第四步telnet或nc测端口，第五步抓包看应用层交互。这套SOP一旦建好，不仅这道错题以后不会再错，整个网络排障的答题框架也顺带搭起来了。

错题复盘还有一个容易忽略的点：要关注干扰项背后的知识。出题人设置干扰项时，通常会在真实常见的错误认知里挑选项。你如果只记住了正确选项，很容易忽略干扰项本身也包含了不少值得记住的知识。比如多选题里那个“端口与协议对应”的干扰项，把Redis的6379写成了6380，你如果只是把正确项记住，下次考到6379和6380的区别可能还是会错。正确的复盘姿势是，把所有选项都过一遍，搞清楚为什么对、为什么错，这样一道题的价值就顶五道题。

5. 综合面试题与笔试之外的能力模型

5.1 从笔试看行业：运维工程师的能力要求正在变化

做完这套卷子之后，我最大的感触是我们这个行业对运维的要求真的变了。以前大家开玩笑说，运维就是“背锅侠+网管”，装个系统、配个网络、重启个服务就完事了。但你看2023年这套卷子的出题方向，很明显在往“SRE”“DevOps”“云原生运维”这个角度靠。它考的不再是零散的知识点，而是一个完整的运维闭环：发现问题（监控与日志）、定位问题（排障思路）、解决问题（脚本自动化）、防止复发（定时任务与规范流程）。

这个变化和行业背景是分不开的。随着容器、Kubernetes等技术的普及，很多传统意义上的“运维手工活”正在被平台能力替代。你不需要再一台一台手工装环境了，但你需要知道怎么用自动化工具把环境批量拉起；你不需要半夜爬起来重启数据库了，但你需要知道怎么写健康检查脚本让系统自动完成故障转移。这套卷子虽然还没有直接考Kubernetes的细节，但它考的分层排查思维、脚本自动化能力、数据库基础，正是进阶到云原生运维的基本功。

5.2 给备考者的复习路线建议

如果你是在准备运维方向的校招或社招笔试，我建议你从这三个方向入手，这套模考的复习思路也同样适用。第一个方向是“夯地基”，把Linux系统管理的基础打牢，包括但不限于：文件系统与磁盘管理、权限与用户管理、进程与服务管理、网络配置与防火墙、日志系统、systemd、cron等。这些是任何一份运维笔试卷子的基本盘，占分通常在五成以上。第二个方向是“懂脚本”，Shell脚本不要求写得多炫酷，但至少会写for循环、条件判断、函数、变量处理，能独立完成日志分析、数据提取、定时任务这类基础自动化需求。第三个方向是“知原理”，网络分层、HTTP协议、数据库事务与索引、Redis的数据结构与过期策略、Nginx的进程模型和负载均衡策略，这些原理不需要背得多深，但要能结合场景说出“为什么”。

在这三个方向的基础上，我特别推荐做一件事：在自己电脑上装一台Linux虚拟机，按照这套卷子的考点，把每个知识点都“演”一遍。比如学了cron就真的去配一个每分钟执行的任务，学了find就真的去找一次7天前的文件并删除，学了网络排查就真的把VMware的网络模式从桥接改成NAT再改回来，然后观察网络行为的变化。你亲手操作过的东西，在笔试里遇到是“送分题”，你只看过没操作过的东西，遇到就是“猜答案”。

5.3 笔试之后：真正的考验在线下

最后说点可能有点打击人、但很真实的话：笔试只是第一关，而且是最容易准备的一关。因为试卷的考点是有限的，题目是有规律可循的，你花时间去刷题、去总结，一定能看到分数的提升。但笔试之后的技术面、HR面，以及入职之后的工作，才是真正考验人的地方。面试官会在半小时的聊天里迅速判断出你到底有没有真实做过运维——你简历里写的那句“熟悉Linux”，对上几句实际操作就能验证真伪。

所以我一直觉得，准备笔试最好的方式不是刷题本身，而是以准备笔试为契机，把该实操的知识点真刀真枪地练一遍。你因为一道cron的错题去虚拟机里配了一次定时任务，你因为一道网络排查的错题去研究了一下traceroute的用法——这些看似绕远路的动作，才是笔试和面试之间真正重合的部分。如果你能做到这一步，2023牛客一模这份卷子对你的价值，就已经远远超过一场模拟考试了。