金山办公2020校招软件运维开发工程师笔试题二这份题在校招圈子里流传得挺广。我做了多年运维开发也带过应届生、参与过类似的命题和阅卷工作所以看到这份卷子的第一反应不是说背一遍答案而是去想这份卷子到底想筛出什么样的人。软件运维开发工程师这个岗位业内简称运维开发在金山办公这边主要负责 WPS 这类产品的线上服务稳定性、发布流水线、监控告警体系以及自动化运维工具链的建设。笔试二作为整套笔试的第二部分通常比第一部分更侧重综合应用和工程逻辑题量不一定大但每一道题都能把考生差距拉开。下面这篇文章不打算逐题报答案——网上的回忆版本身也不一定准我更想把这份卷子背后的知识点、命题思路、答题套路和备考路线一次讲透。正在准备运维类校招的同学可以把它当复习地图想转岗入行 DevOps 的工程师也能从中找到能力补齐的方向。1. 笔试定位一份运维开发卷子背后的筛选逻辑1.1 从岗位画像反推考察图谱先别急着刷题想明白金山办公为什么这么考比记住十个命令有用得多。软件运维开发工程师的工作内容本质上是三块交叉一是运维的日常包括服务器、网络、数据库、中间件的稳定性保障二是开发的技能包括写脚本、做工具、搭平台把重复人工操作变成自动化流程三是工程化的思维比如持续集成持续部署CI/CD、监控告警设计、容量评估和高可用方案。校招笔试题量有限不可能覆盖所有方向所以命题人只能挑最能反映候选人底层素质的知识点来出题。从岗位画像反推一份靠谱的运维开发笔试题通常围绕几个能力维度展开系统与网络基础、脚本与编程、数据库与中间件、自动化工具链、故障排查思维。这五个维度不是平均用力而是层层递进。第一层是“会不会”考察你对 Linux 基本命令、常用协议、SQL 语法是否熟悉第二层是“熟不熟”比如能不能用一条 awk 命令完成日志统计或者写出一个带异常处理的 Python 脚本第三层是“能不能想明白”比如一个线上接口变慢你按照什么顺序排查为什么先看负载再看慢查询。大部分校招同学挂在第三层因为学校里教的知识点不会自动变成排障时的判断力。1.2 “笔试二”的特殊性与真实难度分层很多同学看到“笔试二”会疑惑是不是意味着有笔试一是不是二更难从我接触过的校招流程来看这种编号一般有两种可能一种是公司把笔试拆成基础卷和综合卷基础卷考通识综合卷考岗位技能另一种是同一批笔试有多套平行卷用来防止泄题和抄袭。无论哪种情况“二”这套卷子的定位都偏向实战和综合。它的难度不是体现在某个偏门命令上而是体现在跨知识点的串联上。比如一道题目可能同时涉及 Linux 定时任务、Shell 脚本和日志切割单独看每个点都不难但只要有一个环节不熟整道题就写不完整。理解了这个定位备考策略就清晰了不要押题不要指望背一套原题就过关。校招笔试的题型再变核心考察的“基础扎实程度 工程理解深度 答题表达能力”这三件事不会变。把这三件事练到位别说金山办公市面上大部分互联网公司的运维开发岗笔试题你都能应付。2. 高频考点逐项拆解这些知识点必须拿下2.1 Linux 基础不只是背命令Linux 是运维开发的看家本领也是这类笔试占比最高的部分。但同样是考 Linux校招题和工程师面试题的风格完全不同。笔试更偏好“可快速判分”的客观题所以考点会集中在进程管理、内存与磁盘、文件权限、软硬链接、常用网络工具、systemd 服务管理、计划任务这些方向。举个例子ps -ef和ps aux的区别、top里 load average 的三个数字代表什么、df和du的差异、find的 exec 用法、grep -E与egrep的等价关系这些都是基础中的基础。但光背命令不够笔试真正想看你是否理解命令背后的原理。比如题目问“服务器 load average 偏高但 CPU 使用率并不高可能是什么原因”懂原理的人会想到可能是有大量 D 状态进程在等待磁盘 I/O而不是 CPU 算不过来。这个判断链就是知识深度的体现。我建议复习时把每个命令分成三层来掌握第一层是作用和常用参数第二层是输出结果中每个字段的含义第三层是它在真实排障中对应什么问题。你自己建一张表把top、free、df、netstat、ss、tcpdump、strace这类高频命令按“命令—关键字段—典型场景”整理一遍记忆效率会高很多。2.2 脚本能力Shell 与 Python 的真实用途运维开发岗位和纯运维最大的区别就是必须会写代码。校招笔试一般不会要求你写一个完整的系统但会通过小脚本考察你的编码基本功。Shell 方向的高频考点包括变量与引号的区别单引号不解析、双引号解析这个细节经常考、条件判断语法[ ]和[[ ]]的差异、循环遍历、awk/sed/grep三件套的配合使用、函数的定义与返回值、脚本的退出码。Python 方向则更偏向“用标准库完成一个小任务”比如读文件、处理字符串、调用系统命令、处理异常、简单的 HTTP 请求。下面这个例子是日志分析里的经典场景也是笔试简答题的常见原型#!/bin/bash # 统计 nginx 访问日志中每个 IP 的请求次数输出前 10 awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10这里其实藏了四个考点awk默认按空格分列并取第一列、sort的排序逻辑、uniq -c的计数去重、sort -rn的数值倒序。缺一个环节就得不到正确结果这就是典型的“流程串联型”题目。Python 方向的常见题目是写一个服务健康检查脚本类似这样import socket import subprocess def check_tcp(host, port, timeout3): try: with socket.create_connection((host, port), timeouttimeout): return True except OSError: return False def check_process(process_name): result subprocess.run( [ps, -ef], capture_outputTrue, textTrue ).stdout return process_name in result if __name__ __main__: print(80 端口:, check_tcp(127.0.0.1, 80)) print(nginx 进程:, check_process(nginx))这道简单的题里考察了 socket 连接超时处理、subprocess 调用系统命令、函数封装和入口函数写法。笔试阅卷时考官不一定会真的运行你的代码但会看你的代码结构是否清晰、有没有处理边界情况、有没有使用异常捕获。即使题目只要求“写出核心逻辑”也建议你写出完整的脚本框架这会给阅卷人留下“这人有工程习惯”的印象。2.3 网络与故障排查最容易被低估的部分网络知识在运维开发笔试里非常有区分度。因为它不像 Linux 命令那样可以突击背诵它考察的是你是否真正理解数据包在网络里怎么流动。高频考点包括TCP 三次握手和四次挥手的过程、TIME_WAIT 大量出现的原因、DNS 解析流程、HTTP 常见状态码含义尤其 301、302、403、502、503、504 的区分、常用端口号SSH 22、HTTP 80、HTTPS 443、MySQL 3306、Redis 6379、curl的常见用法、tcpdump抓包分析的基本思路。我见过很多候选人在简答题里写“接口超时了先看 nginx 日志”但问一句“你怎么区分是网络问题还是应用问题”就答不上来。这里给你一个通用的排查链条笔试和面试都能用先确认客户端到服务器的基础连通性ping 不通看链路通但慢再看应用再确认端口是否在监听ss -lntp然后看接入层nginx 或负载均衡的日志和状态码最后看应用日志和数据库慢查询。每一步都对应明确的命令和判断标准这样答出来考官能看到你的排查有层次。2.4 数据库、缓存与常见中间件数据库这块校招笔试不会考太深但基础必须扎实。MySQL 的考点集中在SQL 增删改查、多表连接、聚合函数与 GROUP BY、索引的基本原理为什么用 B 树、最左前缀原则、事务的 ACID 特性与隔离级别、explain执行计划怎么看、常见的慢查询优化手段、备份恢复的基本思路逻辑备份 vs 物理备份。最容易考到的是一个看起来简单但暗藏陷阱的问题某条 SQL 查询很慢你打算怎么排查优化。标准回答要覆盖三层先看有没有走索引再看数据量是不是太大最后看是否因为查询条件写法导致索引失效比如在索引列上用了函数或隐式类型转换。缓存部分以 Redis 为主考点包括五种基础数据结构、键过期策略、缓存穿透/击穿/雪崩的区别及应对方案、持久化方式 RDB 和 AOF 的对比。这套三兄弟问题几乎是校招必考很多人背了答案但说不出为什么。比如缓存雪崩是大量 key 同时失效导致请求打到数据库应对方式是过期时间加随机值缓存穿透是查询一个不存在的 key 每次都穿透到数据库应对方式是布隆过滤器或缓存空值。你要能把“问题现象—产生原因—解决方案”讲成一条线而不是零散地蹦出几个名词。2.5 容器化、CI/CD 与监控近年来这类笔试明显加重了容器化、流水线和监控的考法因为这些都是运维开发日常工作的核心。Docker 的考点包括镜像和容器的区别、Dockerfile 常用指令及顺序FROM、COPY、RUN、CMD与ENTRYPOINT的区别、数据卷和端口映射、镜像分层与 build 缓存、常用排查命令docker logs、docker exec、docker inspect。这里给一个标准的 Python 应用 Dockerfile 模板笔试里让你补全或改错的时候直接套这个思路FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [python, main.py]注意两个考点第一requirements.txt先拷贝并安装依赖再拷贝项目代码这样才能利用镜像层缓存项目代码变了不用重新装依赖第二CMD用列表形式是 exec 形式直接写字符串是 shell 形式环境变量解析行为不同阅卷时老师看的就是这些细节。CI/CD 部分常考 Jenkins Pipeline 的基本概念和git常用操作。不要以为校招不考 git实际上git rebase和git merge的区别、git reset和git revert的区别是高频辨析题。监控部分比较常考的是监控系统的分层基础监控CPU、内存、磁盘、网络、应用监控接口耗时、错误率、业务监控订单量、注册量以及 Prometheus 的基本架构pull 模型抓取指标配合 Grafana 展示通过 Alertmanager 做告警。笔试如果问你“设计一套监控系统”你就按“采集—存储—展示—告警”四层去答每层选一种技术并说清理由分数基本就到手了。2.6 综合场景题开放性考的是思维笔试二这类卷子最后通常有一两道综合场景题题目会给你一个具体情境比如“某天上午十点线上服务突然出现大量 502作为运维开发工程师你会怎么处理”。这种题没有标准答案但阅卷人心里有一套得分框架暴露问题的处理顺序、有没有可操作的具体命令、是否考虑回滚和降级方案、事后是否闭环复盘、改进监控、更新脚本。答这类题的关键是“先应急止血再定位原因最后长效治理”。应急阶段要能说出具体动作比如“先摘掉故障节点避免影响面扩大”“重启前先残留日志”“看监控面板确认是单机还是全集群问题”。定位阶段要沿着链路逐层排查从负载均衡状态、后端服务健康检查、数据库连接数、依赖的第三方接口这几个方向去假设和验证。治理阶段要说“增加健康检查和自动摘除机制”“补充告警策略”“完善应急预案”。这样答题即便你的技术细节不完全对考官也能看出你具备运维的基本素养有章法、不慌乱、闭环思维。3. 答题逻辑与拿分技巧同样会做为什么别人分高3.1 选择题看数字、看边界、看版本校招笔试的客观题不少很多人以为随便刷刷就能过其实选择题的坑藏在数字和边界条件里。运维方向特别喜欢考“默认值”和“边界条件”crontab 五个时间字段分别表示分时日月周这个必须刻在脑子里sysctl里net.ipv4.tcp_timewait_reuse是 0 还是 1 默认值是多少ulimit -n默认打开文件数是 1024HTTP 请求默认超时时间是 30 秒还是 5 秒。这些数字本身不难记难的是在压力下不混淆。我自己的做法是考前专门整理一张“数字记忆卡”把常见的默认端口、超时时间、协议头字段、内核参数默认值集中列出来每天过一遍。选择题还有一个通用技巧遇到“XX 命令的正确用途”这类题先排除明显错误的选项再针对剩余选项回想命令的实际输出。比如netstat -an和ss -lntp前者多用于看所有连接状态后者更擅长看监听端口的进程归属区分点在于输出格式和是否能显示 pid。3.2 简答题把“为什么”写出来简答题是校招笔试里最看书面表达的题型。很多同学知识点都懂但答题只写一两行白白丢分。比如问“为什么 Redis 使用单线程模型还能保持高性能”只写“因为 Redis 快”是不会得高分的你要写出Redis 基于内存操作、核心是事件循环避免了线程上下文切换的开销、I/O 多路复用机制可以同时处理大量连接、单线程避免了锁竞争问题。每多写一个层面的理由都是踩分点。另一个常见问题是“说说你如何排查线上 CPU 使用率突增”。建议的回答结构是分步骤第一步top找到 CPU 占用高的进程第二步按P排序找到具体线程或用ps -Lp pid -o pid,tid,pcpu定位线程第三步必要时用jstack或perf抓线程栈结合代码定位热点第四步如果是业务代码问题就回滚或优化如果是机器问题就迁移和扩缩容。每一步都有真实命令和判断依据考官能看出你不是背的答案而是真的排过障。3.3 场景设计题分层穷举的答题框架综合场景题最怕两种答法一种是只写结论不写过程另一种是想到哪写到哪。给你一个通用的答题框架四个字分层穷举。不管题目是“设计一个高可用部署架构”还是“排查一个偶发超时问题”先在心里把系统分成几层客户端层、接入层域名解析/负载均衡、应用层服务进程/容器、数据层数据库/缓存、基础设施层网络/系统资源。然后一层一层往过走把所有可能的原因穷举出来再结合题目信息缩小范围。答题时用“首先……其次……最后……”或者“从接入层来看……从数据层来看……”这样的递进表达阅卷人一眼就能捕捉到你的逻辑线这比堆砌术语有用得多。比如设计高可用方案你可以按“架构层冗余 流量层负载均衡 应用层无状态 数据层主从复制与自动切换 监控层自动告警 故障层自动恢复”这条线展开。每一层写清楚“具体怎么做”和“解决什么问题”整道题就立体了。4. 备考路线与实操清单三个月从零到笔试通过4.1 第一阶段系统性打底第 1-3 周如果你的基础比较薄弱别一上来就刷题先花三周时间把操作系统、网络、数据库的底子打好。操作系统部分重点看进程管理、内存寻址和文件系统不用陷入内核源码能理解原理即可。网络部分重点看 TCP/IP 协议族尤其是 TCP 状态转移、DNS、HTTP。数据库部分先掌握 SQL 语法和索引原理。这个阶段的输出物建议是两份笔记一份是命令速查表按“系统、网络、进程、磁盘、日志”分类整理常用命令及参数一份是错误集把自己刷题和实验遇到的报错整理成一个文档记录报错信息、原因和解决方法。养成这个习惯后面冲刺阶段效率会翻倍。4.2 第二阶段脚本与实验第 4-7 周第二阶段是动手的关键期。建议在一台 Linux 虚拟机或 WSL上做五个实操项目第一写一个一键部署脚本可以用 Shell 实现自动安装 nginx 并配置虚拟主机第二写一个日志分析脚本统计访问量 TOP 10 的 IP 和请求路径第三用 Python 写一个多端口健康检查脚本结果输出成 Markdown 报告第四给目录写一个定时备份脚本配合 crontab 每天执行保留最近七天第五用 Docker 部署一个前后端应用熟练编写 Dockerfile 和 docker-compose.yml。这五个项目做完Shell 和 Python 的基本功就稳了。做实验时特别强调一件事不要照抄网上的命令每一个参数都要查明白是什么意思。你可以自己改需求比如“备份脚本要支持增量备份”逼自己去查rsync、tar -g这些工具的用法这个过程积累的全是实战经验。4.3 第三阶段工具链与冲刺第 8-12 周最后一个月进入工具链串讲和刷题冲刺。工具链建议按“监控—流水线—容器编排”三个主题快速过一遍监控搭一套 Prometheus Grafana把虚拟机的 CPU、内存、磁盘指标采进来画成面板流水线用 GitLab CI 或 Jenkins 跑通一个“代码提交→自动测试→构建镜像→部署到测试环境”的最小链路容器编排不需要精通 k8s但要理解 Pod、Deployment、Service 的概念能写一份最简单的 YAML。刷题阶段不要只刷校招真题还可以刷中级运维工程师的笔试题和面试题。刷题的目的是查漏补缺不是为了背题。每道错题都回到笔记里找到对应知识点修正错误集。考前三天别再学新东西只看自己的命令速查表和错误集保持手感和稳定心态。4.4 动手环境与资源建议很多同学问我没有服务器怎么做实验其实一台普通笔记本就够了。Windows 用户可以用 WSL2 跑 Ubuntu体验和原生 Linux 差异不大有条件的装 VirtualBox 跑一台 CentOS 或 Ubuntu Server快照功能可以让你放心折腾。内存 8G 以上体验会好一些16G 就更从容了。数据库和中间件都直接装在本机MySQL、Redis、Docker Desktop 都能跑起来。我个人不推荐一上来就买云服务器本地环境能覆盖 80% 的练习场景等真到需要模拟公网架构时再考虑也不迟。5. 常见问题与避坑实录5.1 考场上最容易翻车的六个细节从阅卷经验来看有些错误非常典型完全可以提前避掉。第一crontab 的格式。Shell 定时任务有五个时间字段如果你背了 Python APScheduler 的六字段多一个秒很容易混淆。写答案时先明确“分 时 日 月 周”别在非周六的问题上丢分。# 每天凌晨 2 点执行备份 0 2 * * * /opt/scripts/backup.sh第二命令路径问题。很多脚本在交互终端能跑一放到 crontab 就报 command not found。原因是 crontab 执行环境不加载 shell 的 PATH解决办法是脚本里用绝对路径或者在脚本开头显式导出 PATH。这个知识点笔试可能不会直接考但场景题里你写出“绝对路径加输出重定向”会很加分。第三脚本执行权限。写了一个脚本却忘了chmod x然后纠结为什么执行不了一直报 Permission denied。笔试如果考“让脚本可直接执行需要什么操作”答案就是加执行权限。第四处理日志的空间问题。一个常见的场景题是“磁盘满了怎么处理”很多人的第一反应是删日志但正确的第一步是先找出占空间的大文件确认误删内容再动手。可以用du -sh *定位目录用lsof | grep deleted找到虽然被删除但仍被进程占用的文件。这个排查顺序比盲目删除专业得多。第五网络工具的新旧版本。netstat被ss替代是个趋势笔试若问“查看端口监听”写ss -lntp会比netstat -tlnp更符合当前工程实践但如果题目版本较老两者都写出来再备注一句更稳妥。第六回答不写理由。简答题只写命令不写意图是新手最常犯的错。考官看的是决策依据不是命令列表。5.2 备考中的典型误区备考运维开发最常见的误区是“觉得运维就是背命令”。如果你只刷选择题不写脚本不搭环境笔试遇到代码题和场景题时一定会露怯。第二个误区是“重基础轻工程”很多同学 Linux 背得滚瓜烂熟但对 Docker、CI/CD 一问三不知这在近年校招里非常吃亏因为运维开发岗的趋势就是和研发流程深度绑定。第三个误区是“只学一门语言”。Shell 虽然重要但 Python 在运维开发中的占比越来越高尤其是涉及数据平台、自动化平台开发时Python 几乎是标配。笔试往往会同时考到两者只准备一门会显能力结构偏科。第四个误区是不重视“写文档能力”。场景题里让“说明你的排查思路”本质是在考表达。有些同学心里都懂落到纸面就一团乱麻。建议平时做完实验后把自己的操作步骤按“问题背景—排查过程—结论”的格式写成小记录练一种能把技术思路讲清楚的能力这一项在职场上长期受用。5.3 阅卷视角的独家心得最后说点阅卷时才会注意到的东西。判卷速度比你想象中快阅卷人通常在几十秒内判断一道简答题的值不值得细看。所以你的答题结构一定要清晰关键命令、关键概念尽量前置。我的习惯是先给结论再展开推理用序号分步骤让阅卷人不用看完整段就能抓住要点。其次卷面上写“我不知道但我会用以下方式查”并不丢分。比如题目问到一个没见过的参数你可以写“我会先用man查看该命令的帮助文档再用实际环境验证其效果”。这比瞎编一个错误答案诚实得多也符合运维工程师面对未知问题时应该有的态度。还有一个小细节代码题如果时间紧张写不完至少写出关键函数和大致思路。留白一定是零分写了框架即使有 bug 也可能拿到一半分。笔试考的不只是你会什么更是你在不完美的情况下如何表达和应对。这几个月如果你能按上面的思路把基础过一遍、脚本练一遍、工具链搭一遍再刷几套真题找感觉到考场上就会发现自己看到题目不再焦虑因为每一道题背后是什么知识点、考官想看什么你都提前想明白了。我这些年带人、命题最深的体会是运维开发这份工作最终拼的不是知识面有多宽而是把复杂问题拆成可执行步骤的能力。笔试只是这种能力的一次提前预演。希望这篇文章能帮你在预演里多拿几分也帮你真正往一个合格运维开发工程师的方向多靠近一步。