企业官网建设流程全解析

前阵子有学弟问我，游卡2024春招的运维开发笔试该怎么准备。他本身是计算机科班出身，Linux、网络、数据库都学过，但看到往年真题时还是有点没底——不知道游戏公司的运维开发笔试到底考什么、和互联网大厂的运维/后端笔试题有什么差别。这个问题挺有代表性的，因为运维开发这个岗位在校招里属于“看上去谁都能投，实际很挑人”的类型：既要懂系统、网络这些传统运维底盘，又要有写工具、做平台的研发能力，笔试里的每一类题都在筛选这两种素质。这篇文我就结合游卡这个具体方向，把运维开发校招笔试的题型、考点、答题思路和刷题方向完整拆一遍，适合正在准备游戏公司运维开发/DevOps/SRE校招的同学参考，也适合那种“还分不清运维开发和纯运维有什么区别，先来看看适不适合自己”的人。

1. 投递前先想清楚：游戏公司要的运维开发，到底考的是什么

1.1 岗位画像拆解：运维开发不是“会敲命令的运维”

先说个很多人搞混的概念。运维开发，英文对应通常是 DevOps Engineer 或者 SRE（Site Reliability Engineer）偏开发方向的岗位，和传统运维最大的区别在于：传统运维的核心交付是“把系统用好”，而运维开发的核心交付是“把运维能力做成工具和平台”。笔试时这两类岗位的考察重点完全不一样——纯运维岗可能大量考命令、考配置、考排查套路，而运维开发岗会明显偏向脚本编写、代码逻辑、自动化设计，还要看你有没有能力把一个重复性操作固化成可以复用的东西。

做个对比就知道了：

游卡本身的业务特点，决定了它的运维开发岗位会更看重什么。游卡以《三国杀》系列和线上桌游业务为主，这类产品的特点是：玩家在线时长不短、实时交互要求高、运营活动频繁、开服合服操作多，而且区服架构很重。游戏公司对运维开发的诉求通常集中在几件事上：版本发布流程自动化、海量日志处理、监控告警体系搭建、容量评估、故障快速定位。笔试题目看起来零散，实际都是围绕这些业务场景来做文章。

1.2 从业务反推考点：游戏厂商的笔试侧重点

我不建议拿到笔试通知再临时抱佛脚，而是建议在投递之前就做一个“考点预判”。方法不复杂：把这家公司的业务形态列出来，再反推“如果我是运维负责人，我最怕线上出什么事，我最希望校招生会什么”，考点就八九不离十了。

拿游卡这类游戏公司举例：

• 游戏有大量区服，服务器割接、开服合服是日常操作，所以要考 Linux 基础、脚本批量执行、配置管理。
• 玩家会集中在晚上和活动期间登录，流量波峰明显，所以要考负载均衡、系统性能分析、容量评估思路。
• 游戏日志又大又杂，充值日志、战斗日志、登录日志、异常日志混在一起，所以要考文本处理三剑客、日志分析脚本。
• 线上出现故障时影响面大，可能要快速回滚或切流量，所以要考故障排查思路、发布策略。
• 运营活动频繁，每周可能发几次版本，所以要考 CI/CD 概念、打包构建流程、自动化部署的基本原理。

基于这个推演，你就能理解为什么这类笔试总爱考“CPU飙高怎么排查”“日志怎么统计”“写个脚本监控服务”这类题了——不是因为出题人偷懒，而是这些就是游戏运维日常里最高频、最核心的场景。

1.3 备考资料与时间安排

如果你还有两三周准备时间，我建议按下面这个节奏来：

第一周：基础扫盲 + 命令实操。过一遍 Linux 常用命令，重点不是背参数，而是理解每个命令的输出字段是什么意思。比如top里的 load average、free里的 buff/cache、df里的 Use%，这些都可能变成笔试选择题的考点。网络和数据库基础同步进行，《图解HTTP》加一本 MySQL 基础就够。

第二周：脚本强化。每天写一到两个小脚本，覆盖日志统计、文件备份、批量检查、健康检查这几类常见场景。要求自己不用查文档就能写出来，因为笔试现场经常是纯记事本环境，没有补全、没有调试器，写不写得出来很考验熟练度。

第三周：刷题 + 复盘。找各家公司运维开发岗的往年笔试回忆题，按题型分类刷，刷完一定要整理错题，尤其要把“当时没想到的那个点”记下来。同时把常见的故障排查题答案整理成固定模板，考试时直接套框架，比自己边想边写要稳得多。

2. 笔试题型全拆解：基础题、脚本题、架构题各占多少比重

2.1 基础题：Linux、网络、数据库的“送分题”和“陷阱题”

基础题一般占三成左右，主要以选择题、判断题、填空题形式出现。这部分题目本身不难，但特别喜欢在细节上挖坑。

Linux 方向常考的点：进程管理（ps、kill、僵尸进程）、文件权限（rwx 数值计算、umask）、系统负载（top、uptime、load average 含义）、磁盘管理（df、du、inode 耗尽）、服务管理（systemd 基本操作）。这里最容易被坑的是那种“看上去很简单，实际考的是概念”的题，比如：

• “系统 load average 升高到 10，但 CPU 使用率很低，可能是什么原因？”正确答案通常和 I/O 等待、进程阻塞有关，而不是 CPU 本身。
• “某文件权限是 644，属主是 root，普通用户能否修改？”这种题考的是权限判断逻辑，不是单纯背数字。
• “du -sh和df -h看到的大小不一致，是什么原因？”涉及到已删除但未释放的文件句柄，这种就属于典型的“平时没遇到就写不出来”的考点。

网络方向常考的点：TCP 三次握手和四次挥手（包括为什么需要 TIME_WAIT）、HTTP 状态码含义、DNS 解析过程、常见端口号。数据库方向常考的点：索引原理、SQL 执行顺序、事务隔离级别、慢查询原因。

基础题是整张卷子的兜底分，正常复习过的同学应该能拿到七成以上。这里我特别想提醒一句：基础题里如果出现那种“哪个命令可以查端口占用”之类的题，优先答netstat和ss，不要只写netstat一个。ss是netstat的替代品，很多公司内部已经把netstat换掉了，笔试里能主动提到ss，会显得你有实际操作经验。

2.2 脚本题：Shell 与 Python，至少要熟练掌握一个

脚本题是运维开发笔试和纯运维笔试最大的分水岭，通常占三到四成，而且往往是拉分关键。出题形式一般是给一个实际场景，让你写脚本或者补全脚本，常见的场景有这么几类：

一是日志处理类。比如给一个 access.log 的样例，让你统计访问量 Top10 的 IP。这种题用 Shell 就是经典的awk + sort + uniq组合，用 Python 就是读文件 + 字典统计 + 排序输出。

二是监控检查类。比如写一个脚本，定时检查某个服务是否存活，如果挂了就重启并发送告警。这种题考察的是进程管理、系统命令调用、异常处理、日志输出这些综合能力。

三是批量操作类。比如有 100 台服务器，需要批量执行某个命令，或者批量分发文件，让你写一个脚本实现。这种题本质上是考察循环、并发、连接复用这些编程基础，用 Shell 的for循环或者 Python 的paramiko库都能做。

四是数据处理类。比如从一个 CSV 文件里提取某个字段做聚合统计，或者把多行日志按时间窗口切分。这种题的核心是字符串处理和数据结构的使用。

笔试环境里写脚本，和平时开发最大的不同是：没有 IDE、不能联网查资料、很多时候甚至没有真实环境可以运行，只能靠“裸写”。所以我强烈建议备考时用纯文本编辑器练，写完再跑到终端里验证。练到一看到题目描述，脑子里就能浮现出大致代码框架的程度，才算过关。

2.3 简答/设计题：故障排查和架构设计的思路比答案重要

简答题或设计题通常占两到三成，这是笔试里最考验经验的部分，也是很多同学最头疼的部分。这类题没有标准答案，但阅卷时会看你有没有一套清晰的排查思路。

常见题型包括：

• “线上某台服务器 CPU 使用率达到 100%，如何排查？”
• “游戏开服当天玩家大量涌入，登录服务响应缓慢，怎么分析？”
• “如何设计一套监控告警系统？”
• “发布新版本后线上出现大量报错，你如何快速定位和处置？”

这类题答题的核心是结构化。我建议所有同学至少准备一套自己的“故障排查模板”：发现问题 → 影响评估 → 定位根因 → 应急止血 → 彻底解决 → 复盘总结。不管什么题，往这个框架里填内容，就能避免答得东一句西一句。

设计类题目除了结构，还要体现“可落地”，不能天天嘴里挂着微服务、容器化、K8s 这些大词，却说不清楚具体怎么监控、怎么发现故障、怎么扩容。校招笔试里能写清楚“一台服务器从接入到上线需要经历哪几步”这种小问题，比空谈架构要实用得多。

2.4 开放题：游戏场景下的“送命题”与“加分题”

不少游戏公司会在笔试最后放一两道开放性题目，可能是商业场景分析题，也可能是价值观 / 场景应对题。比如：

• “如果凌晨三点游戏线上出故障，你会怎么处理？”
• “如何评估一次游戏活动的服务器容量？”
• “某个玩家反馈游戏登录不上，你会从哪些角度排查？”

这类题没有标准答案，考察的是你面对真实工作场景时有没有基本的判断力。答题时不要只站在技术角度，要把玩家体验、业务影响、沟通成本都考虑进去。比如凌晨三点故障那道题，你除了说技术排查，还要说“先判断影响范围，影响大就立刻启动应急预案、通知相关同事，不要一个人闷头查”，这种回答会明显更成熟。

3. 几类最容易拉开差距的经典题，手把手拆解

3.1 日志分析题：awk、sort、uniq 的组合拳

日志统计应该是运维开发笔试里出现频率最高的编程题之一，因为它在真实工作中太常用了。我先说最常见的场景：给一个 access.log，里面每行包含 IP、时间、请求路径、状态码等字段，要求统计访问次数最多的前 10 个 IP。

用 Shell 写几乎有固定套路：

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

一行命令就搞定了。但要注意几个细节：

• awk '{print $1}'取的是第一个字段，前提是日志格式里 IP 在第一列，如果不在第一列就要用$NF或按分隔符指定。
• uniq -c统计前必须先sort，因为uniq只能统计相邻的重复行，这是非常经典的丢分点。
• sort -rn是数字排序并且倒序，很多人只写了sort，结果字典序排序导致 10 排在 9 前面，看起来就很不专业。

Python 版本也很容易：

from collections import Counter with open('access.log', 'r', encoding='utf-8') as f: ip_list = [line.split()[0] for line in f] for ip, count in Counter(ip_list).most_common(10): print(f"{count}\t{ip}")

这段代码思路清晰，但笔试时我建议再补一个异常处理，因为文件可能很大，而且某行可能格式不规范：

from collections import Counter counter = Counter() with open('access.log', 'r', encoding='utf-8') as f: for line in f: parts = line.split() if parts: counter[parts[0]] += 1 for ip, count in counter.most_common(10): print(f"{count}\t{ip}")

之所以强调异常处理，是因为笔试阅卷时，代码边界处理往往是区分“会写”和“写得好”的关键。

3.2 健康检查脚本：从零写一个可用的监控工具

另外一个高频编程题是“写一个脚本，定期检查某个 HTTP 服务是否正常，异常时重启服务并告警”。这个题很典型，因为它把一个真实的运维需求压缩到了最小规模。

我用 Python 写一个简化版本：

import subprocess import time import requests SERVICE_URL = "http://127.0.0.1:8080/healthz" RESTART_CMD = ["systemctl", "restart", "mygame-server"] ALERT_CMD = ["python3", "/opt/scripts/send_alert.py", "game-server down"] def check_health(): try: resp = requests.get(SERVICE_URL, timeout=5) return resp.status_code == 200 except Exception: return False def main(): while True: if not check_health(): subprocess.run(RESTART_CMD) subprocess.run(ALERT_CMD) time.sleep(30) time.sleep(5) if __name__ == "__main__": main()

这道题有几个关键点一定要在代码里体现：

• 超时控制。requests.get如果不带timeout，可能一直卡住，这个在真实环境是致命的。
• 异常捕获。服务可能直接连不上，也可能返回 500，两种情况都要算“不健康”。
• 重启后的冷却时间。重启完立刻下一次探测大概率还是失败，要sleep一段时间。
• 告警动作和重启动作分离。很多同学写出来只有重启没有告警，这在笔试里会扣分，因为真实的运维体系要求任何变更必须有通知。

如果要求用 Shell 写，也完全可以：

#!/bin/bash URL="http://127.0.0.1:8080/healthz" if curl -s -m 5 "$URL" | grep -q "ok"; then echo "service is healthy" else systemctl restart mygame-server curl -s -m 10 -X POST http://alert.example.com/send -d 'msg=mygame-server down' fi

这里curl -m 5是设置了 5 秒超时，grep -q "ok"是检查返回内容里是否包含健康关键字。很多真实的健康检查不是只看状态码，而是会约一个约定的响应体，所以要学会这种检查方式。

3.3 故障排查题：从现象到根因的回答模板

简答题里的故障排查，最容易出现的问题就是“想到哪写到哪”。比如问“CPU 飙高怎么排查”，很多人就写“用 top 看看哪个进程占用高，kill 掉”，这显然不够。我整理了一个能拿分的标准作答思路：

第一步，先确认问题的真实性和影响范围。用uptime看负载，用top看 CPU 使用率，确认是 CPU 型负载高还是 I/O 等待型负载高，同时确认受影响的机器范围是个例还是集群性问题。

第二步，定位到具体进程和线程。top -Hp <pid>查看进程内哪个线程占 CPU，如果用了 Java，还要用jstack看一下线程栈；如果是 Python，可以用py-spy dump之类的工具。这一步的产出是“哪个业务逻辑在消耗 CPU”。

第三步，分析为什么这个逻辑会消耗这么多 CPU。可能是死循环、可能是锁竞争、可能是 GC 频繁、也可能是流量确实涨了。结合代码和最近变更来分析，最近有没有发过版本、有没有调整过配置、有没有活动流量进来。

第四步，止血和恢复。如果是流量涨了，考虑扩容或限流；如果是代码 bug，考虑回滚或者热修复；如果是死循环，可能要先重启进程临时恢复。

第五步，复盘和长期优化。比如加监控、加告警、优化代码、做压测。这一步校招生写到“补充监控指标”其实就很加分了。

写到卷面上时，最好用”1-2-3-4-5“这种分层结构，每个层级下面跟一句具体命令或具体措施。阅卷人一眼就能看到你的条理，比你写一大段话效果好得多。

3.4 安全与配置题：给一段配置找隐患

很多同学容易忽略一个题型：给一段系统配置、脚本或者数据库配置，让你找风险点。这种题本质上是考运维经验和安全意识。

举个例子，给一段 Nginx 配置或者一个数据库账号创建语句，让你指出存在的问题。常见的得分点包括：

• 权限过大的隐患。比如数据库账号用了'root'@'%'这种写法，等于所有主机都能连，还给了所有权限。
• 密码管理问题。比如密码明文写在配置文件里，或者使用弱口令。
• 端口暴露问题。比如监听0.0.0.0而不限制来源 IP。
• 日志缺失。没有打开访问日志或错误日志，给事后排查带来困难。
• 安全协议弱。比如还在用 TLS 1.0 或者没有开启严格加密传输。

这类题考察的不是偏门知识，而是你在实际部署时有没有想过“别人会怎么搞坏我的系统”。平时练习时多问问自己：如果我拿到这台服务器，第一步做什么，这个配置有哪些地方会让我找到漏洞？坚持这种思维方式，写答案就会自然很多。

4. 笔试中的高频失分点与应试技巧

4.1 书写规范：不要在小细节上翻车

我复盘过不少同学的笔试答卷，发现很多丢分不是因为不会，而是因为书写不规范。尤其是代码题，最容易出现这些问题：

• 缩进混乱。Python 的缩进就是语法的一部分，笔试用记事本写，缩进一乱代码直接无法运行。
• 变量命名随便。全篇都是a、b、c，阅卷人看半天不知道你在干嘛。稍微用ip、count、healthy这种有意义的名字，印象分会好很多。
• 没用with打开文件，或者打开了不关闭。在真实代码里是资源泄漏，在笔试里是经验不足的表现。
• Shell 脚本开头没写#!/bin/bash，或者关键命令没有处理可能的失败情况。

这些小问题本身不致命，但多个叠加在一起，会让人觉得“这个人的代码能力还没形成肌肉记忆”。我建议笔试前两周，每天手动敲代码二十分钟，专门练手感和格式。

4.2 时间分配：先抢分，后攻坚

校招笔试题量通常不小，而且经常是选择题、编程题、简答题混在一起。我见过不少同学在选择题上过度纠结，在一道 2 分的选择题上磨十分钟，结果后面的大题没时间写。

我的策略是先花五分钟快速浏览全卷，标记出哪些题一眼就会、哪些题要想一下、哪些题完全没有头绪。做的时候严格按“先会做 → 再想想 → 最后蒙”的顺序来。选择题拿不准的，先选一个并做个标记，不要恋战；编程题只要能写出整体框架，哪怕有小 bug 也比空白强；开放题留十五到二十分钟，保证每条思路都能写几句话。

还有一个小技巧：笔试环境里如果有在线评测，代码题提交前一定要检查输入输出格式。很多人逻辑是对的，但输出格式多了一个空格或者少了换行，评测就判错了，这种失分最冤枉。

4.3 笔试结束后的复盘：把题目变成面试弹药

笔试结束不代表任务完成，我个人认为复盘才是笔试真正的价值所在。校招的笔试题目往往高度相似，你今天在游卡的笔试题里卡住的知识点，很可能是两周后另一家公司的原题。所以考完一定要趁记忆还热，把题目尽量还原出来，然后逐个查漏补缺。

复盘时重点做三件事：

第一，整理题目类型分布。看看自己哪类题耗时最多、错误率最高，如果发现网络题老是丢分，那就集中突击网络；如果发现 Shell 题写不顺，就专门练脚本。

第二，把每一道做错的题重新写一遍完整答案。不要只看解析，一定要自己重新写一遍，写到能默写的程度。

第三，把印象深刻的题记录下来作为“面试素材”。笔试中出现的基础概念和场景，很可能在面试里被追问，这时候你如果在复盘时已经深入研究过，面试时就等于开了挂。

4.4 心态与临场：把笔试当一次正常的故障演练

最后聊点临场的东西。运维开发笔试有一个特点，就是很多题目没有绝对的标准答案，特别是设计题和开放题，写出来的内容是否贴合真实运维场景，阅卷人是能看出来的。所以心态上不要追求“每道题都完美”，而是追求“把我会的都展示出来”。

遇到完全不会的题，不要直接放弃，尽量写一点与之相关的理解。比如不会写完整的 K8s 部署流程，但你知道 deployment、service、pod 这些概念，就把这些概念写上去，至少体现你知道这个领域里有哪些东西。校招笔试的容错率其实不低，你要做的是尽可能多地让阅卷人看到你的“可培养空间”，而不是证明自己已经无所不知。

5. 笔试之外的长期主义：这场考试只是运维开发路上的第一关

5.1 简历上的运维开发项目，怎么包装才不虚

如果笔试通过了，下一步一定是面试。面试里最常问的就是“你做过什么项目”。很多同学的简历上写的是“搭建了个人博客”或者“写了一个校园二手交易系统”，不是说这些项目不好，而是和运维开发的岗位匹配度太低。招运维开发的人想看到什么？想看到你在“让系统更稳定、更自动化”这件事上有过思考和实践。哪怕项目很小，比如你给宿舍的同学搭了一个共享 NAS，你写了脚本每天自动备份，还能监控磁盘剩余空间，超过阈值就发邮件提醒——这个项目虽然简单，但它完整地体现了一个运维开发者的工作方式：发现问题、写工具、自动化、监控告警。面试官完全可以通过这个小项目问出很多东西，比如备份策略怎么设计、磁盘监控怎么做、脚本异常怎么处理，而这些你只要真的做过，就肯定答得出来。

5.2 工具链清单：每样东西熟练到什么程度才算够

我见过一份比较靠谱的校招运维开发工具清单，分享给你参考：

• Linux 系统操作：熟练，能不看文档完成日常运维命令操作。
• Shell / Python 脚本：熟练，能独立编写 50 行以上的工具脚本。
• 常用服务：Nginx、MySQL、Redis，至少知道它们的核心配置项和常见故障。
• CI/CD：了解 GitLab CI 或者 GitHub Actions 的基本流程。
• 监控：了解 Prometheus + Grafana 的基本概念，会写简单的告警规则。
• 容器：了解 Docker 基本操作，Dockerfile怎么写，镜像和容器的关系是什么。
• 云平台：如果用过云服务器，知道安全组、弹性 IP 的概念。

不需要样样精通，但你得在笔试和面试里让人相信：给你一台服务器和一个需求，你能自己想办法搞定。

5.3 从校招视角看运维开发的成长路径

很多人担心运维开发这个岗位天花板低。说说我自己的看法：运维开发成长路径其实很清晰，前期是“工具人”，写脚本、搭监控、处理故障，核心是把自己的手工作业自动化；中期是“平台建设者”，开始做 CI/CD 平台、日志平台、监控平台、配置中心，让整个研发团队的交付效率提升；后期是“稳定性负责人”，关注 SLO、容量规划、成本控制、风险治理，这时候已经不只是技术问题，而是业务和管理的交叉了。游戏公司里这个岗位的成长尤其快，因为业务场景复杂、故障刺激、对实时性要求高，你会在一次次活动高峰和上线发布中快速积累经验。

笔试只是这一整个链路的第一关而已。备考时把基础打扎实、把脚本练熟、把排查思路理清楚，剩下的就是心态和临场发挥了。

最后说点个人体会。我准备这类笔试时最担心的其实是开放题，总怕自己“没经历过大规模线上故障”写不出深度。后来发现，阅卷人根本不会期待一个校招生有十年经验，他们看的是你有没有成熟的思考框架。你能把自己知道的有限经验组织得有条有理，就已经赢了大多数人。把每一道题当成一次真实的故障演练来回答，别怕写得朴素，怕的是没有逻辑。这套思路我自己用了很久，考场上也非常管用，希望能给你也带来一点帮助。