金山办公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, timeout=3): try: with socket.create_connection((host, port), timeout=timeout): return True except OSError: return False def check_process(process_name): result = subprocess.run( ["ps", "-ef"], capture_output=True, text=True ).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默认打开文件数是 1024；HTTP 请求默认超时时间是 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 也可能拿到一半分。笔试考的不只是你会什么，更是你在不完美的情况下如何表达和应对。
这几个月如果你能按上面的思路把基础过一遍、脚本练一遍、工具链搭一遍，再刷几套真题找感觉，到考场上就会发现自己看到题目不再焦虑，因为每一道题背后是什么知识点、考官想看什么，你都提前想明白了。我这些年带人、命题最深的体会是：运维开发这份工作，最终拼的不是知识面有多宽，而是把复杂问题拆成可执行步骤的能力。笔试只是这种能力的一次提前预演。希望这篇文章能帮你在预演里多拿几分，也帮你真正往一个合格运维开发工程师的方向多靠近一步。
