1. 一份模考卷先摸清它到底在筛选什么人每年到了招聘季牛客网上的模考卷就会火一阵子。2023年这套运维笔试的一模卷我完整刷了一遍感受挺复杂的。它不像LeetCode那样纯粹考算法也不像技术认证考试那样死扣某一个产品的配置命令而是把Linux基础、网络原理、容器化、系统服务管理、脚本能力全部揉在一起试图用一张卷子判断一个人能不能直接上手干活。先说结论这套卷子的风格很接近一线互联网公司和二线大厂的运维笔试出题方向。它不是靠偏题怪题来难为人而是靠基础知识的深度理解和排错思维的连贯性来拉开差距。很多人觉得运维笔试就是在背Linux常用命令大全实际上现在的出题人要的是在网络故障、服务异常、系统卡顿的场景下你能不能给出可执行的排查路径。适用人群很明确准备校招或社招转岗的运维新人、想从桌面运维向服务器运维或云计算运维进阶的工程师、以及在企业里做私有化运维但没系统梳理过知识体系的人。对于纯开发背景但想了解运维工作边界的读者这套卷也有参考价值。从热搜词里也能看出行业现状——运维已经无岗了这种说法和具身智能应用运维工程师同时存在说明运维岗位不是消失了而是在分化。传统意义上的跑机房、装系统、管账号确实在萎缩但云原生、智能运维、数字孪生系统运维这类方向的人才缺口很大。笔试题目恰恰反映了这种转型它考的不只是你会不会敲命令而是你有没有把系统当作一个整体来理解的习惯。我把整张卷子的考点做了归类大致分成四个模块Linux与Shell基础、网络原理与排查、容器与Kubernetes调用链、系统管理与服务治理。每个模块的题都不算超纲但从正确率来看恰恰是那些自我感觉良好的考生丢分最多。2. 高频考点逐题拆解从命令记忆到系统思维2.1 Linux命令题出题人想看到的不是背诵是理解模考卷里Linux相关的题占了很大比例但几乎没有直接考ls -l 的输出中第三列代表什么这类一眼见底的题。更多是给你一个故障场景问你应该用哪条命令定位问题。这种出题方式本质上是把Linux常用命令大全运维这个热搜词背后的真实需求挖了出来——命令不是拿来背的是拿来定位问题的。举个例子一道典型的题是某台服务器负载升高用户反馈接口响应变慢你登录服务器后会按什么顺序排查下列命令中哪条最合适我见过太多人第一反应就是top或者uptime。这两条没错但不完整。完整的排查链路应该是uptime确认负载均值看是瞬时升高还是持续走高top按CPU占用排序确认是用户态进程还是内核态进程消耗资源vmstat 1 5看CPU、内存、swap、io等待队列判断瓶颈在CPU、内存还是磁盘IOiostat -x 1看磁盘使用率%util和IO等待时间await确认是不是磁盘拖后腿pidstat或者top里拿到具体进程PID后再决定是调整配置、重启服务还是扩容。这道题的正确率并不高原因是很多人把top当成了终点而不是起点。top只告诉你谁在消耗资源不告诉你为什么消耗资源。想回答这个问题你得继续追。另外一道高频题是文件查找和内容处理。题目会给一段日志路径要求你找出某类异常最多的IP。最快的解法是组合命令grep ERROR /var/log/app/error.log | awk {print $NF} | sort | uniq -c | sort -rn这个链路的考点很密集grep做过滤、awk取字段、sort让相同项相邻、uniq -c统计次数、最后的sort -rn按次数倒序。每一步都是基本功但串起来就能解决一个真实的数据筛选问题。如果你的脚本习惯还停留在打开日志文件然后肉眼找这套笔试会帮你认清差距。2.2 网络原理题TCP状态机比配置命令更重要网络部分的题目出题人非常克制没有搞一堆复杂的BGP、OSPF路由协议而是聚焦在TCP/IP基础、HTTP状态码、DNS解析、常用网络排查工具上。但正因为考点基础反而更能区分干过活和看过书的人。卷子里有这样一个场景题客户端访问服务端接口超时curl返回connection timed out你如何排查普通答案是ping一下服务器通不通。懂得多一点的会做全链路逐层排查。这道题想要看到的答案暗含了TCP三次握手和连接超时的语义差异如果ping不通多半是网络层不通可能是防火墙拦了ICMP也可能是路由有问题如果ping通但端口连不上可能是服务没监听或者防火墙只放行了特定协议如果端口通但请求超时可能是服务端应用程序处理不过来也可能是负载均衡后端节点异常。对应到命令层面# 检查本地到目标的路由跳数 traceroute -n -T -p 80 目标IP # 确认端口监听状态 ss -lntp | grep 8080 # 抓包看TCP握手是否完成 tcpdump -i eth0 host 客户端IP and port 8080 -ntcpdump抓包在笔试和面试里都是加分项。它能直接告诉你SYN包有没有发出去、SYN-ACK有没有回来、RST是谁发的。有一次我在线上环境排查一个偶发性连接超时问题应用日志和系统日志都没异常最后就是靠tcpdump抓到客户端在凌晨两点到三点之间频繁发起TCP重连才发现是中间网络设备的空闲会话超时时间设置得太短。网络部分的另一类经典题是HTTP状态码判断。出题人给一个场景服务器返回502让你判断可能原因。这里需要区分状态码含义常见原因502 Bad Gateway网关或代理收到上游无效响应后端服务挂了、FastCGI进程崩溃、负载均衡配置错误503 Service Unavailable服务暂时不可用服务过载、正在重启、限流策略生效504 Gateway Timeout网关等待上游响应超时后端处理过慢、数据库连接池耗尽、死锁很多考生会把502和504搞混实际排查起来这两个问题的方向差别很大。502优先看后端进程是否存活504优先看后端接口的响应耗时和数据库状态。2.3 容器与Kubernetes调用链从containerd这个关键词展开2023年的运维笔试如果完全不涉及容器化那这份卷子就过时了。牛客这套模考卷确实考了容器相关内容而且有一道题直接问到了kubernetes是如何调用containerd的。这道题的出题背景很明确Docker作为容器运行时在Kubernetes中的默认地位被削弱之后containerd和CRI-O成了主流选择。理解Kubernetes与containerd的调用关系不仅是为了应付笔试更是生产环境排错的基础能力。完整的调用链路是这样的用户通过kubectl下发指令比如创建Pod请求首先到达API ServerAPI Server将资源对象写入etcd并通知kubeletkubelet通过CRIContainer Runtime Interface接口调用运行时如果运行时是containerd则kubelet通过CRI插件containerd内置的cri插件与containerd通信containerd负责管理镜像、容器生命周期、网络和存储最终由containerd调用runc来真正创建和运行容器进程。这个链路里有一个容易被忽略的细节kubelet和containerd之间的通信走的是Unix Socket而不是TCP。默认路径通常是/run/containerd/containerd.sock。你在配置kubelet的时候--container-runtime-endpoint参数必须指向这个socket不然kubelet根本找不到运行时。排查问题时有个经典手段# 查看kubelet配置中的运行时端点 kubelet --print-runtime-config # 通过crictl直接查看节点上的容器列表 crictl ps # 查看containerd运行状态 systemctl status containerd我在实际维护Kubernetes集群时经常碰到Pod一直处于ContainerCreating状态的情况。这个时候第一反应就应该是crictl ps -a看容器是否创建成功而不是直接去kubelet日志里大海捞针。容器运行时是基础设施层的基础设施它出问题会让所有上层故障现象变得千奇百怪。2.4 系统管理题systemd和日志排查是运维日常的缩影系统服务管理这块模考卷考了systemd unit文件的配置和日志排查。题目不算难但非常贴近日常。有一道题是给了错误输出Failed to start xxx.service: Unit not found.问你可能是什么原因。常见的三个原因unit文件不存在或路径错误unit文件存在但没有执行systemctl daemon-reloadunit文件的Enable符号链接失效。这道题让我想起刚做运维那会儿第一次把一个service文件从别的机器拷过来直接systemctl start就报Unit not found。当时还以为是文件拷贝少了后来才反应过来systemd加载unit文件需要重载配置。所以现在我的习惯是凡是手动新装或修改了unit文件先跑一遍systemctl daemon-reload再执行systemctl status看是否能正确识别。日志排查题也很典型。题目会给一段journalctl输出杂夹着服务启动失败的信息让你分析根因。这类题考的是对日志格式的敏感度以及从日志根因倒推解决手段的能力。我个人的建议是日常维护服务器时养成用journalctl -u 服务名 -f -n 100看日志的习惯而不是一上来就tail -f /var/log/messages。后者信息太杂很难快速定位到具体服务。3. 从题目追问到生产环境笔试背后的实战逻辑3.1 网络排查的完整链路ping不通只是一个起点很多笔试答案在纸面上看是对的但放到生产环境里执行你会发现少了关键一步。比如ping不通这个问题新手给出的方案几乎都是检查网线/检查IP配置/关防火墙听着没问题但实际排障时你会发现步骤之间没有逻辑关系。我给自己定的排查链路是这样的确认本机网络配置没问题ip addr、ip route确认网关通不通ping 网关IP确认跨网段通不通traceroute看路径确认目标主机通不通ping 目标IP确认目标端口通不通telnet 目标IP 端口或者nc -vz 目标IP 端口还不行就抓包看协议层交互tcpdump。这套链路每次只验证一件事一旦哪一步失败问题范围就被缩小了。笔试里考ping不通其实是在考你有没有形成这种分层排查的思维模式而不是真的让你去修一台物理服务器。有些环境比较特殊比如用云主机时需要注意安全组和网络ACL的区别。安全组是实例级别的防火墙网络ACL是子网级别的防火墙两者叠加时规则取交集。你在云上排查ping不通如果忽略了安全组配置跑到物理网络层面去找问题那就会陷入死胡同。这个问题在云计算运维相关热搜词里排得也很靠前。3.2 容器排障从kubectl到crictl到底层的三层递进Kubernetes排障是一个典型的分层定位过程。笔试题目里如果考到Pod异常你需要具备三层递进的排查意识。第一层API层。用kubectl describe pod看事件确认是不是镜像拉取失败、资源不足、探针失败。第二层容器运行时层。用crictl系列命令直接查看容器状态。# 查看容器列表包括退出的容器 crictl ps -a # 查看容器日志 crictl logs 容器ID # 查看容器详情 crictl inspect 容器ID第三层底层进程和系统层。ctr命令直接操作containerd的命名空间或者runc list查看实际的运行时容器进程。这三层的关系你可以理解为打车出行kubectl是打车软件它告诉你司机正在赶来crictl是司机师傅的手机记录着他的实时位置系统层的进程信息则是车本身的状态——发动机有没有启动、轮胎有没有气。大多数时候你在第一层就能定位问题但如果kubectl describe显示容器已创建但退出你就得下探到第二层甚至第三层看退出码和日志。我遇到过一次Pod反复CrashLoopBackOff的情况。kubectl describe pod提示Back-off restarting failed container看着像探针问题但改了很多次配置都没用。后来用crictl logs看发现是应用启动时读取环境变量失败报的是panic: environment variable not set。应用层的问题容器层只能告诉你它崩了不会告诉你为什么崩。这也是为什么懂容器原理的运维在排查问题时效率会高很多——你知道去哪一层找答案。3.3 运维笔试中那些看起来考工具实际考思路的题这类题最典型的代表是围绕网络运维工具箱展开的。题目不会直接问tcpdump的-w参数是什么意思而是给你一个场景生产环境出现CPU飙高要求你抓取相关数据。正确思路是CPU飙高先确认是哪种类型的CPU占用用户态/内核态/软中断/硬中断用户态CPU高用top -Hp PID看线程级别再用perf top看热点函数内核态CPU高看看是不是系统调用太过频繁用strace -p PID -c统计软中断高si列数值高多半是网络包处理太多用mpstat -I CPU确认是哪个CPU在扛中断。这些工具每个单独拿出来都不是冷门命令但能按照现象 - 定位 - 细查的顺序把它们串起来用的人才算真正具备排查能力。笔试就是通过这种场景题来试探你的思路链是否完整。这种思路能力在智能运维和AI运维时代反而越来越重要。因为自动化监控工具能解决的是那些规则明确的场景。真正诡异的故障比如某台机器偶发性延迟比其他机器高10倍但各项指标都正常还是得靠工程师脑子里那套逻辑链路去推演。工具可以帮你缩小范围但不会替你思考。4. 试卷之外运维工程师的知识地图与长期积累4.1 从笔试反推知识边界给新人的查漏清单刷完这套模考卷之后我给自己带的新人整理了一份查漏清单。你可以对照着看看自己哪些地方还是空白。Linux基础层文件系统结构、常见目录用途进程管理ps、top、htop、pidstat内存管理free、vmstat、/proc/meminfo磁盘管理df、du、iostat、fdisk、LVM文本处理grep、awk、sed、sort、uniq、xargs权限体系rwx、setuid、setgid、ACL、SELinux网络层TCP/IP协议栈、三次握手、四次挥手、状态转换HTTP协议、常见状态码、HTTPS握手流程DNS解析过程这里注意纯技术DNS机制可以正常讨论网络排查工具ping、traceroute、telnet、nc、tcpdump、ss、netstat防火墙iptables、firewalld、安全组规则服务治理层systemd单位文件编写与维护日志体系syslog、journalctl、日志轮转定时任务crontab、systemd timerNginx配置和维护数据库基础MySQL常用命令、慢查询排查、主从复制原理容器与云原生层Docker基础镜像、容器、网络、数据卷containerd和CRI的基本原理Kubernetes核心对象Pod、Deployment、Service、ConfigMapHelm包管理监控体系Prometheus、Grafana、Alertmanager脚本化能力层Shell脚本变量、循环、条件判断、函数Python基础用于自动化运维的常见场景文件处理、API调用、定时脚本这不是一个必须全部掌握才能面试的清单而是用来定位短板的。运维这个岗位的特点就是知识面特别宽没有人能做到样样精通但你得保证每个基础模块都有足够深的理解以便在遇到问题时知道该去翻哪本手册。4.2 运维手册应该怎么写从笔试中的排查题说起运维手册包含哪些这个热搜词出现在这次模考相关搜索里说明很多人已经开始意识到运维工作不光是处理故障还要把处理故障的知识沉淀下来。笔试里的排查题本质上是让你口头复述一套排障流程。而运维手册就是把这套流程固化下来的载体。我在实际工作中沉淀下来的手册模板大概长这样系统架构总览环境拓扑图这里可以画图、服务依赖关系、关键节点IP日常巡检清单每天/每周/每月需要检查的指标和命令标准操作流程SOP发布上线流程、回滚预案、扩缩容步骤故障处理手册按系统分类记录历史故障的现象、排查过程、根因、解决方案备份和恢复方案备份策略、恢复演练记录应急联系人列表各系统的负责人、架构师、数据库管理员这里有一个很关键的理念运维手册不是文档仓库而是灾难恢复的路线图。如果手册写出来没人看、遇到问题时没人用那它只是废纸。我的习惯是每次处理完一个比较典型的故障都会把排查过程补进手册里包括那些试了没用的方法。这样下次遇到类似问题时可以少走很多弯路。4.3 项目总结的工作流运维如何证明自己的价值热搜词里有一条特别扎眼运维在项目总结时应该如何去描述项目。这个问题在笔试里不会直接考但在简历关和面试官提问时一定会遇到。很多运维工程师项目描述是这样的负责公司生产环境的运维工作保障系统稳定运行。这句话写了等于没写。面试官想知道的是你负责的系统规模多大业务怎么部署你处理过哪些有价值的问题你做了哪些优化带来什么收益我提供一个可参考的模板负责某电商平台生产集群约200台云主机日常运维和发布支持。主导将应用容器化改造通过Kubernetes部署将新版本发布耗时从40分钟缩短至15分钟。设计并落地基于Prometheus的监控告警体系覆盖主机、容器、中间件3层指标平均故障发现时间从30分钟降低到5分钟。处理过多次数据库连接池耗尽、缓存穿透和网络分区故障沉淀故障处理手册10余篇。这个描述的要点在于有规模200台、有改造动作容器化、有量化结果40分钟到15分钟、30分钟到5分钟、有知识沉淀手册。笔试考的是你脑子里有多少知识项目描述考的是你把这些知识用到了什么程度。这两个层面缺一不可。4.4 国企运维与互联网公司运维的差异笔试背后折射的两种环境从这套模考卷来看它的出题风格更偏向互联网公司。但结合热搜词里同时出现的国企it运维笔试和互联网系统运维和国企系统运维的区别这里面有一个值得展开的问题。互联网公司的运维更强调效率和自动化接受试错成本追求快速迭代。笔试考察的重点是Linux深入程度、容器技术、脚本能力、故障快速响应能力。而国企或传统行业的运维更看重稳定和规范往往有严格的变更窗口和审批流程对操作系统、网络设备的认证要求高有时还涉及信创环境如统信UOS、麒麟等国产化系统。统信运维工具-livecd这个热搜词其实点出了一个方向国产化运维是一个正在增长但人才稀少的领域。livecd是统信UOS提供的一个应急维护工具用于系统无法正常启动时进入最小化环境进行修复。这类工具的掌握在信创项目中几乎是必备能力但在互联网运维的知识体系里基本不会出现。如果你正在求职建议先想清楚目标行业再有针对性地准备。互联网公司看速度和灵活国企看规范和体系。没有哪条路绝对好坏关键是你自己的性格和职业规划偏向哪一边。5. 笔试答卷之外几个容易被忽略但值得注意的细节5.1 主观题部分考察的是沟通和预案能力牛客这套模考卷如果只做客观题容易给人一种运维就是做选择题的错觉。其实高价值的题目往往是主观题比如请描述一次你印象最深的线上故障处理过程。这种题没有标准答案但阅卷人能从你的描述里看出三四件事你是否有独立处理问题的经验、你的排查链路是否清晰、你在故障中承担什么角色、你有没有复盘和沉淀文档的习惯。我建议回答这类问题时采用STAR原则Situation背景是什么业务、什么时间、影响多大Task任务你接到什么问题、需要达成什么目标Action行动你按什么顺序执行了哪些操作Result结果问题多久解决、影响范围多广、后续做了哪些改进。照着这个逻辑写面试官能快速抓住重点也显得你有结构化思维。这套答题框架本身不是空话它就是运维工作里的复盘模板不管故障多大最后都要回答从这次事件里带出了什么改进项。5.2 不是所有故障都要立即解决这个观点可能和笔试里的场景题有冲突但到了真实生产环境你最先要考虑的不是解决而是止损和恢复。比如某个服务出现内存泄漏你花三个小时去定位泄漏点不如先重启服务把影响降到最低再找时间深入分析。我的原则是先恢复再诊断。具体来说分三种情况影响核心业务的高优先级故障优先通过切换流量、重启服务、回滚版本等方式恢复一切其他动作靠后影响面较小的中优先级故障可以在尽量不影响业务的前提下调试诊断但也要设定时间上限低优先级问题比如某台机器磁盘空间缓慢增长记录并规划维护窗口处理不占用核心故障的响应时间。这个原则在笔试里不一定能直接“得分”但它是招聘方在背景调查环节特别关注的隐性能力。纸上写的是分析能力实际干活靠的是决策优先级。5.3 用知识和工具代替用爱发电最后想聊一个心态问题。做运维这行总是被调侃在吗、帮我看看、是不是没重启。其实这种调侃背后有一个核心矛盾运维的日常付出和可见收益天然不成正比。系统稳定运行时没人觉得运维做了什么一出故障全公司都来找你。所以运维工程师必须有一种防御性思维宁可自己平时多花时间做自动化和监控也不要在半夜被报警电话拖起来处理本可避免的问题。写好监控脚本、把告警规则配置好、把操作文档留好这些前期投入看起来枯燥但长期收益极高。我在自己负责的集群上逐步配齐了主机存活、容器重启、磁盘使用率、证书过期时间、备份任务状态等10多类告警之后真正需要半夜爬起来处理的次数大大减少。回到这份2023牛客模考卷我的整体判断是它是一份不错的自我检视工具但不必把分数看太重。笔试考的是你的知识存量工作中更看重的却是把知识转化为动作的速度。刷完卷子把错题对应的知识点补齐再用你自己的环境去真正操作一遍这才是模考的价值所在。 运维笔试模考卷拆解：从Linux命令到Kubernetes排障
1. 一份模考卷先摸清它到底在筛选什么人每年到了招聘季牛客网上的模考卷就会火一阵子。2023年这套运维笔试的一模卷我完整刷了一遍感受挺复杂的。它不像LeetCode那样纯粹考算法也不像技术认证考试那样死扣某一个产品的配置命令而是把Linux基础、网络原理、容器化、系统服务管理、脚本能力全部揉在一起试图用一张卷子判断一个人能不能直接上手干活。先说结论这套卷子的风格很接近一线互联网公司和二线大厂的运维笔试出题方向。它不是靠偏题怪题来难为人而是靠基础知识的深度理解和排错思维的连贯性来拉开差距。很多人觉得运维笔试就是在背Linux常用命令大全实际上现在的出题人要的是在网络故障、服务异常、系统卡顿的场景下你能不能给出可执行的排查路径。适用人群很明确准备校招或社招转岗的运维新人、想从桌面运维向服务器运维或云计算运维进阶的工程师、以及在企业里做私有化运维但没系统梳理过知识体系的人。对于纯开发背景但想了解运维工作边界的读者这套卷也有参考价值。从热搜词里也能看出行业现状——运维已经无岗了这种说法和具身智能应用运维工程师同时存在说明运维岗位不是消失了而是在分化。传统意义上的跑机房、装系统、管账号确实在萎缩但云原生、智能运维、数字孪生系统运维这类方向的人才缺口很大。笔试题目恰恰反映了这种转型它考的不只是你会不会敲命令而是你有没有把系统当作一个整体来理解的习惯。我把整张卷子的考点做了归类大致分成四个模块Linux与Shell基础、网络原理与排查、容器与Kubernetes调用链、系统管理与服务治理。每个模块的题都不算超纲但从正确率来看恰恰是那些自我感觉良好的考生丢分最多。2. 高频考点逐题拆解从命令记忆到系统思维2.1 Linux命令题出题人想看到的不是背诵是理解模考卷里Linux相关的题占了很大比例但几乎没有直接考ls -l 的输出中第三列代表什么这类一眼见底的题。更多是给你一个故障场景问你应该用哪条命令定位问题。这种出题方式本质上是把Linux常用命令大全运维这个热搜词背后的真实需求挖了出来——命令不是拿来背的是拿来定位问题的。举个例子一道典型的题是某台服务器负载升高用户反馈接口响应变慢你登录服务器后会按什么顺序排查下列命令中哪条最合适我见过太多人第一反应就是top或者uptime。这两条没错但不完整。完整的排查链路应该是uptime确认负载均值看是瞬时升高还是持续走高top按CPU占用排序确认是用户态进程还是内核态进程消耗资源vmstat 1 5看CPU、内存、swap、io等待队列判断瓶颈在CPU、内存还是磁盘IOiostat -x 1看磁盘使用率%util和IO等待时间await确认是不是磁盘拖后腿pidstat或者top里拿到具体进程PID后再决定是调整配置、重启服务还是扩容。这道题的正确率并不高原因是很多人把top当成了终点而不是起点。top只告诉你谁在消耗资源不告诉你为什么消耗资源。想回答这个问题你得继续追。另外一道高频题是文件查找和内容处理。题目会给一段日志路径要求你找出某类异常最多的IP。最快的解法是组合命令grep ERROR /var/log/app/error.log | awk {print $NF} | sort | uniq -c | sort -rn这个链路的考点很密集grep做过滤、awk取字段、sort让相同项相邻、uniq -c统计次数、最后的sort -rn按次数倒序。每一步都是基本功但串起来就能解决一个真实的数据筛选问题。如果你的脚本习惯还停留在打开日志文件然后肉眼找这套笔试会帮你认清差距。2.2 网络原理题TCP状态机比配置命令更重要网络部分的题目出题人非常克制没有搞一堆复杂的BGP、OSPF路由协议而是聚焦在TCP/IP基础、HTTP状态码、DNS解析、常用网络排查工具上。但正因为考点基础反而更能区分干过活和看过书的人。卷子里有这样一个场景题客户端访问服务端接口超时curl返回connection timed out你如何排查普通答案是ping一下服务器通不通。懂得多一点的会做全链路逐层排查。这道题想要看到的答案暗含了TCP三次握手和连接超时的语义差异如果ping不通多半是网络层不通可能是防火墙拦了ICMP也可能是路由有问题如果ping通但端口连不上可能是服务没监听或者防火墙只放行了特定协议如果端口通但请求超时可能是服务端应用程序处理不过来也可能是负载均衡后端节点异常。对应到命令层面# 检查本地到目标的路由跳数 traceroute -n -T -p 80 目标IP # 确认端口监听状态 ss -lntp | grep 8080 # 抓包看TCP握手是否完成 tcpdump -i eth0 host 客户端IP and port 8080 -ntcpdump抓包在笔试和面试里都是加分项。它能直接告诉你SYN包有没有发出去、SYN-ACK有没有回来、RST是谁发的。有一次我在线上环境排查一个偶发性连接超时问题应用日志和系统日志都没异常最后就是靠tcpdump抓到客户端在凌晨两点到三点之间频繁发起TCP重连才发现是中间网络设备的空闲会话超时时间设置得太短。网络部分的另一类经典题是HTTP状态码判断。出题人给一个场景服务器返回502让你判断可能原因。这里需要区分状态码含义常见原因502 Bad Gateway网关或代理收到上游无效响应后端服务挂了、FastCGI进程崩溃、负载均衡配置错误503 Service Unavailable服务暂时不可用服务过载、正在重启、限流策略生效504 Gateway Timeout网关等待上游响应超时后端处理过慢、数据库连接池耗尽、死锁很多考生会把502和504搞混实际排查起来这两个问题的方向差别很大。502优先看后端进程是否存活504优先看后端接口的响应耗时和数据库状态。2.3 容器与Kubernetes调用链从containerd这个关键词展开2023年的运维笔试如果完全不涉及容器化那这份卷子就过时了。牛客这套模考卷确实考了容器相关内容而且有一道题直接问到了kubernetes是如何调用containerd的。这道题的出题背景很明确Docker作为容器运行时在Kubernetes中的默认地位被削弱之后containerd和CRI-O成了主流选择。理解Kubernetes与containerd的调用关系不仅是为了应付笔试更是生产环境排错的基础能力。完整的调用链路是这样的用户通过kubectl下发指令比如创建Pod请求首先到达API ServerAPI Server将资源对象写入etcd并通知kubeletkubelet通过CRIContainer Runtime Interface接口调用运行时如果运行时是containerd则kubelet通过CRI插件containerd内置的cri插件与containerd通信containerd负责管理镜像、容器生命周期、网络和存储最终由containerd调用runc来真正创建和运行容器进程。这个链路里有一个容易被忽略的细节kubelet和containerd之间的通信走的是Unix Socket而不是TCP。默认路径通常是/run/containerd/containerd.sock。你在配置kubelet的时候--container-runtime-endpoint参数必须指向这个socket不然kubelet根本找不到运行时。排查问题时有个经典手段# 查看kubelet配置中的运行时端点 kubelet --print-runtime-config # 通过crictl直接查看节点上的容器列表 crictl ps # 查看containerd运行状态 systemctl status containerd我在实际维护Kubernetes集群时经常碰到Pod一直处于ContainerCreating状态的情况。这个时候第一反应就应该是crictl ps -a看容器是否创建成功而不是直接去kubelet日志里大海捞针。容器运行时是基础设施层的基础设施它出问题会让所有上层故障现象变得千奇百怪。2.4 系统管理题systemd和日志排查是运维日常的缩影系统服务管理这块模考卷考了systemd unit文件的配置和日志排查。题目不算难但非常贴近日常。有一道题是给了错误输出Failed to start xxx.service: Unit not found.问你可能是什么原因。常见的三个原因unit文件不存在或路径错误unit文件存在但没有执行systemctl daemon-reloadunit文件的Enable符号链接失效。这道题让我想起刚做运维那会儿第一次把一个service文件从别的机器拷过来直接systemctl start就报Unit not found。当时还以为是文件拷贝少了后来才反应过来systemd加载unit文件需要重载配置。所以现在我的习惯是凡是手动新装或修改了unit文件先跑一遍systemctl daemon-reload再执行systemctl status看是否能正确识别。日志排查题也很典型。题目会给一段journalctl输出杂夹着服务启动失败的信息让你分析根因。这类题考的是对日志格式的敏感度以及从日志根因倒推解决手段的能力。我个人的建议是日常维护服务器时养成用journalctl -u 服务名 -f -n 100看日志的习惯而不是一上来就tail -f /var/log/messages。后者信息太杂很难快速定位到具体服务。3. 从题目追问到生产环境笔试背后的实战逻辑3.1 网络排查的完整链路ping不通只是一个起点很多笔试答案在纸面上看是对的但放到生产环境里执行你会发现少了关键一步。比如ping不通这个问题新手给出的方案几乎都是检查网线/检查IP配置/关防火墙听着没问题但实际排障时你会发现步骤之间没有逻辑关系。我给自己定的排查链路是这样的确认本机网络配置没问题ip addr、ip route确认网关通不通ping 网关IP确认跨网段通不通traceroute看路径确认目标主机通不通ping 目标IP确认目标端口通不通telnet 目标IP 端口或者nc -vz 目标IP 端口还不行就抓包看协议层交互tcpdump。这套链路每次只验证一件事一旦哪一步失败问题范围就被缩小了。笔试里考ping不通其实是在考你有没有形成这种分层排查的思维模式而不是真的让你去修一台物理服务器。有些环境比较特殊比如用云主机时需要注意安全组和网络ACL的区别。安全组是实例级别的防火墙网络ACL是子网级别的防火墙两者叠加时规则取交集。你在云上排查ping不通如果忽略了安全组配置跑到物理网络层面去找问题那就会陷入死胡同。这个问题在云计算运维相关热搜词里排得也很靠前。3.2 容器排障从kubectl到crictl到底层的三层递进Kubernetes排障是一个典型的分层定位过程。笔试题目里如果考到Pod异常你需要具备三层递进的排查意识。第一层API层。用kubectl describe pod看事件确认是不是镜像拉取失败、资源不足、探针失败。第二层容器运行时层。用crictl系列命令直接查看容器状态。# 查看容器列表包括退出的容器 crictl ps -a # 查看容器日志 crictl logs 容器ID # 查看容器详情 crictl inspect 容器ID第三层底层进程和系统层。ctr命令直接操作containerd的命名空间或者runc list查看实际的运行时容器进程。这三层的关系你可以理解为打车出行kubectl是打车软件它告诉你司机正在赶来crictl是司机师傅的手机记录着他的实时位置系统层的进程信息则是车本身的状态——发动机有没有启动、轮胎有没有气。大多数时候你在第一层就能定位问题但如果kubectl describe显示容器已创建但退出你就得下探到第二层甚至第三层看退出码和日志。我遇到过一次Pod反复CrashLoopBackOff的情况。kubectl describe pod提示Back-off restarting failed container看着像探针问题但改了很多次配置都没用。后来用crictl logs看发现是应用启动时读取环境变量失败报的是panic: environment variable not set。应用层的问题容器层只能告诉你它崩了不会告诉你为什么崩。这也是为什么懂容器原理的运维在排查问题时效率会高很多——你知道去哪一层找答案。3.3 运维笔试中那些看起来考工具实际考思路的题这类题最典型的代表是围绕网络运维工具箱展开的。题目不会直接问tcpdump的-w参数是什么意思而是给你一个场景生产环境出现CPU飙高要求你抓取相关数据。正确思路是CPU飙高先确认是哪种类型的CPU占用用户态/内核态/软中断/硬中断用户态CPU高用top -Hp PID看线程级别再用perf top看热点函数内核态CPU高看看是不是系统调用太过频繁用strace -p PID -c统计软中断高si列数值高多半是网络包处理太多用mpstat -I CPU确认是哪个CPU在扛中断。这些工具每个单独拿出来都不是冷门命令但能按照现象 - 定位 - 细查的顺序把它们串起来用的人才算真正具备排查能力。笔试就是通过这种场景题来试探你的思路链是否完整。这种思路能力在智能运维和AI运维时代反而越来越重要。因为自动化监控工具能解决的是那些规则明确的场景。真正诡异的故障比如某台机器偶发性延迟比其他机器高10倍但各项指标都正常还是得靠工程师脑子里那套逻辑链路去推演。工具可以帮你缩小范围但不会替你思考。4. 试卷之外运维工程师的知识地图与长期积累4.1 从笔试反推知识边界给新人的查漏清单刷完这套模考卷之后我给自己带的新人整理了一份查漏清单。你可以对照着看看自己哪些地方还是空白。Linux基础层文件系统结构、常见目录用途进程管理ps、top、htop、pidstat内存管理free、vmstat、/proc/meminfo磁盘管理df、du、iostat、fdisk、LVM文本处理grep、awk、sed、sort、uniq、xargs权限体系rwx、setuid、setgid、ACL、SELinux网络层TCP/IP协议栈、三次握手、四次挥手、状态转换HTTP协议、常见状态码、HTTPS握手流程DNS解析过程这里注意纯技术DNS机制可以正常讨论网络排查工具ping、traceroute、telnet、nc、tcpdump、ss、netstat防火墙iptables、firewalld、安全组规则服务治理层systemd单位文件编写与维护日志体系syslog、journalctl、日志轮转定时任务crontab、systemd timerNginx配置和维护数据库基础MySQL常用命令、慢查询排查、主从复制原理容器与云原生层Docker基础镜像、容器、网络、数据卷containerd和CRI的基本原理Kubernetes核心对象Pod、Deployment、Service、ConfigMapHelm包管理监控体系Prometheus、Grafana、Alertmanager脚本化能力层Shell脚本变量、循环、条件判断、函数Python基础用于自动化运维的常见场景文件处理、API调用、定时脚本这不是一个必须全部掌握才能面试的清单而是用来定位短板的。运维这个岗位的特点就是知识面特别宽没有人能做到样样精通但你得保证每个基础模块都有足够深的理解以便在遇到问题时知道该去翻哪本手册。4.2 运维手册应该怎么写从笔试中的排查题说起运维手册包含哪些这个热搜词出现在这次模考相关搜索里说明很多人已经开始意识到运维工作不光是处理故障还要把处理故障的知识沉淀下来。笔试里的排查题本质上是让你口头复述一套排障流程。而运维手册就是把这套流程固化下来的载体。我在实际工作中沉淀下来的手册模板大概长这样系统架构总览环境拓扑图这里可以画图、服务依赖关系、关键节点IP日常巡检清单每天/每周/每月需要检查的指标和命令标准操作流程SOP发布上线流程、回滚预案、扩缩容步骤故障处理手册按系统分类记录历史故障的现象、排查过程、根因、解决方案备份和恢复方案备份策略、恢复演练记录应急联系人列表各系统的负责人、架构师、数据库管理员这里有一个很关键的理念运维手册不是文档仓库而是灾难恢复的路线图。如果手册写出来没人看、遇到问题时没人用那它只是废纸。我的习惯是每次处理完一个比较典型的故障都会把排查过程补进手册里包括那些试了没用的方法。这样下次遇到类似问题时可以少走很多弯路。4.3 项目总结的工作流运维如何证明自己的价值热搜词里有一条特别扎眼运维在项目总结时应该如何去描述项目。这个问题在笔试里不会直接考但在简历关和面试官提问时一定会遇到。很多运维工程师项目描述是这样的负责公司生产环境的运维工作保障系统稳定运行。这句话写了等于没写。面试官想知道的是你负责的系统规模多大业务怎么部署你处理过哪些有价值的问题你做了哪些优化带来什么收益我提供一个可参考的模板负责某电商平台生产集群约200台云主机日常运维和发布支持。主导将应用容器化改造通过Kubernetes部署将新版本发布耗时从40分钟缩短至15分钟。设计并落地基于Prometheus的监控告警体系覆盖主机、容器、中间件3层指标平均故障发现时间从30分钟降低到5分钟。处理过多次数据库连接池耗尽、缓存穿透和网络分区故障沉淀故障处理手册10余篇。这个描述的要点在于有规模200台、有改造动作容器化、有量化结果40分钟到15分钟、30分钟到5分钟、有知识沉淀手册。笔试考的是你脑子里有多少知识项目描述考的是你把这些知识用到了什么程度。这两个层面缺一不可。4.4 国企运维与互联网公司运维的差异笔试背后折射的两种环境从这套模考卷来看它的出题风格更偏向互联网公司。但结合热搜词里同时出现的国企it运维笔试和互联网系统运维和国企系统运维的区别这里面有一个值得展开的问题。互联网公司的运维更强调效率和自动化接受试错成本追求快速迭代。笔试考察的重点是Linux深入程度、容器技术、脚本能力、故障快速响应能力。而国企或传统行业的运维更看重稳定和规范往往有严格的变更窗口和审批流程对操作系统、网络设备的认证要求高有时还涉及信创环境如统信UOS、麒麟等国产化系统。统信运维工具-livecd这个热搜词其实点出了一个方向国产化运维是一个正在增长但人才稀少的领域。livecd是统信UOS提供的一个应急维护工具用于系统无法正常启动时进入最小化环境进行修复。这类工具的掌握在信创项目中几乎是必备能力但在互联网运维的知识体系里基本不会出现。如果你正在求职建议先想清楚目标行业再有针对性地准备。互联网公司看速度和灵活国企看规范和体系。没有哪条路绝对好坏关键是你自己的性格和职业规划偏向哪一边。5. 笔试答卷之外几个容易被忽略但值得注意的细节5.1 主观题部分考察的是沟通和预案能力牛客这套模考卷如果只做客观题容易给人一种运维就是做选择题的错觉。其实高价值的题目往往是主观题比如请描述一次你印象最深的线上故障处理过程。这种题没有标准答案但阅卷人能从你的描述里看出三四件事你是否有独立处理问题的经验、你的排查链路是否清晰、你在故障中承担什么角色、你有没有复盘和沉淀文档的习惯。我建议回答这类问题时采用STAR原则Situation背景是什么业务、什么时间、影响多大Task任务你接到什么问题、需要达成什么目标Action行动你按什么顺序执行了哪些操作Result结果问题多久解决、影响范围多广、后续做了哪些改进。照着这个逻辑写面试官能快速抓住重点也显得你有结构化思维。这套答题框架本身不是空话它就是运维工作里的复盘模板不管故障多大最后都要回答从这次事件里带出了什么改进项。5.2 不是所有故障都要立即解决这个观点可能和笔试里的场景题有冲突但到了真实生产环境你最先要考虑的不是解决而是止损和恢复。比如某个服务出现内存泄漏你花三个小时去定位泄漏点不如先重启服务把影响降到最低再找时间深入分析。我的原则是先恢复再诊断。具体来说分三种情况影响核心业务的高优先级故障优先通过切换流量、重启服务、回滚版本等方式恢复一切其他动作靠后影响面较小的中优先级故障可以在尽量不影响业务的前提下调试诊断但也要设定时间上限低优先级问题比如某台机器磁盘空间缓慢增长记录并规划维护窗口处理不占用核心故障的响应时间。这个原则在笔试里不一定能直接“得分”但它是招聘方在背景调查环节特别关注的隐性能力。纸上写的是分析能力实际干活靠的是决策优先级。5.3 用知识和工具代替用爱发电最后想聊一个心态问题。做运维这行总是被调侃在吗、帮我看看、是不是没重启。其实这种调侃背后有一个核心矛盾运维的日常付出和可见收益天然不成正比。系统稳定运行时没人觉得运维做了什么一出故障全公司都来找你。所以运维工程师必须有一种防御性思维宁可自己平时多花时间做自动化和监控也不要在半夜被报警电话拖起来处理本可避免的问题。写好监控脚本、把告警规则配置好、把操作文档留好这些前期投入看起来枯燥但长期收益极高。我在自己负责的集群上逐步配齐了主机存活、容器重启、磁盘使用率、证书过期时间、备份任务状态等10多类告警之后真正需要半夜爬起来处理的次数大大减少。回到这份2023牛客模考卷我的整体判断是它是一份不错的自我检视工具但不必把分数看太重。笔试考的是你的知识存量工作中更看重的却是把知识转化为动作的速度。刷完卷子把错题对应的知识点补齐再用你自己的环境去真正操作一遍这才是模考的价值所在。