2020年春招，我投了奇安信的运维开发工程师岗位。那时候奇安信刚从集团独立出来没多久，安全圈里讨论度很高，网上搜“奇安信”出来的内容大多集中在天擎这类终端安全产品上，真正说清楚这家公司运维开发岗笔试考什么的文章很少。我投完之后专门把Linux常用命令、Python基础、网络协议这些内容重新过了一遍，笔试链接发过来才发现，实际考察的维度和我想的还不是完全一样。
这篇文章想把我还能回忆起来的内容、以及题面背后真正想筛的能力拆开讲清楚。如果你也在准备安全公司或者中大型企业的运维开发、SRE、DevOps类岗位，这篇应该能帮你少走点弯路。
1. 先搞清楚：运维开发工程师的笔试到底在筛什么
1.1 安全公司的运维开发，和平常理解的不太一样
很多同学以为运维开发就是“会写脚本的运维”，这个理解不能说错，但放在奇安信这种以安全产品为核心的公司里，岗位画像会再复杂一层。
普通互联网公司的运维开发，主要服务对象是业务的稳定性，核心工作是监控告警、CI/CD、容量规划、故障应急。但安全公司的运维开发天然要面对两个额外的复杂度：第一，你维护的机器和系统本身可能是安全产品的一部分，比如漏洞扫描平台、日志分析集群、威胁情报系统，这些系统的可用性直接关系到安全业务的交付，宕机不是“业务受影响”那么简单，而是可能让整个安全防护失效。第二，安全产品的部署环境非常杂，客户现场可能是物理机、VMware、OpenStack、公有云，甚至某些特定系统环境，你写的自动化脚本、部署工具必须在各种奇怪的网络隔离条件下跑得通。
所以笔试环节虽然不会直接考“你懂不懂安全”，但出题人心里很清楚：他们要招的是能在安全业务场景下把自动化、稳定性、效率这套东西落地的人。这个底色决定了题目风格——基础题占大头，但会刻意加一些考察工程习惯和边界意识的题目。
1.2 我印象里的笔试整体结构
时间过去比较久，具体原题记不全了，但题型的分布我印象还挺深。整套题大概是三个部分：
第一部分是Linux基础操作和网络概念，选择题加上手写命令，比重最大。这部分只要平时真在服务器上干过活，基本都能答。第二部分是Python编程题，不是特别难的算法，更像是工作里会遇到的字符串处理、日志统计、批量操作的简化版。第三部分是数据库、缓存、监控相关的概念题和场景设计题，会给你一个具体场景让你描述思路。
整体感觉是：不考偏题怪题，不要求你背八股文，但如果你只在培训机构刷过题、没有真实操作经验，很多题目你会在“好像会但又说不准”的状态里卡住。这其实是出题人故意的，基础题考察的是一个运维开发工程师每天都在用的基本功，不是一个突击一周就能补上的东西。
1.3 一个关键认知：笔试筛选的是“干活的人”，不是“背书的人”
我后来复盘的时候想明白一件事，这套笔试真正在筛选的能力可以总结成三条：
- 常用工具是不是真的用得熟，而不是只知道命令名。
- 遇到不确定的情况有没有排查思路，而不是只会背答案。
- 写代码有没有工程意识，比如考虑异常、考虑性能、考虑可读性。
所以你在准备的时候，不要把精力花在啃那些一年都用不上一次的命令参数上，而要把重点放在高频操作是否足够扎实。比如文件处理三件套、进程管理、权限管理、网络状态查看、日志排查，这些如果你能不看文档直接写出来，笔试里的基础题基本不会丢分。
2. Linux命令与网络基础：最常考，也最容易在细节上翻车
2.1 Linux题目到底考什么层级
运维开发笔试里的Linux题一般不会直接问你“tar命令怎么解压”，那太没区分度了。常见考法是给你一个具体的运维场景，让你写出对应的命令或者排查思路。
我遇到的高频考点大致包括：
- 文件查找与处理：
find、grep、awk、sed的组合使用，尤其是从日志里提取信息。 - 进程与系统状态：
ps、top、free、df、iostat这几个命令的字段含义，以及怎么判断系统负载异常。 - 网络排查：
netstat、ss、telnet、curl、tcpdump的基础用法。 - 权限与用户：
chmod、chown、sudo的机制，特殊权限位。 - 定时任务：crontab的写法，还有systemd timer这种新一点的方案。
单独看每个知识点都不难，但笔试里会故意出一些“组合题”。比如给一个场景，要同时用到tail、grep、awk才能解决，就看你写命令的时候是不是真的熟练。
2.2 一道典型的文本处理题：从日志里统计状态码
笔试里有一类题我印象很深，就是日志分析。题目大概意思是：一个Nginx访问日志文件，每一行的格式是IP 时间 请求方法 请求路径 状态码 响应大小，要求统计出现次数最多的5个状态码，并输出状态码和次数。
这类题看着简单，但答案能直接看出你的水平。初级一点的写法是纯用grep加sort加uniq：
awk '{print $9}' access.log | sort | uniq -c | sort -rn | head -5如果不知道日志字段分隔符是什么，或者不清楚$9对应哪个字段，说明你对awk的基础还不够熟。这道题更合理的考法是让你说明这个命令每一步在干什么，为什么用uniq -c而不是直接uniq，为什么排序要用sort -rn。
我当时写完之后还补了一句：如果日志量很大，用awk直接做数组统计会更高效，不会产生排序的额外开销。这其实是我在实际工作中处理过大量日志后的习惯，笔试时顺手写上去，算是加分项。类似这种“常规解法写出来，再补一个更工程化的思路”的做法，在笔试里很吃香，因为它直接体现你真的处理过类似问题。
2.3 网络知识：不考抓包，考你能不能说清一次请求的完整过程
网络部分的题目整体不算深，但覆盖面挺广。印象里有这样几类：
- TCP三次握手和四次挥手的过程，以及
TIME_WAIT状态产生的原因。 - HTTP和HTTPS的区别，HTTPS握手过程中证书的作用。
- DNS解析的完整流程，包括本地缓存、递归查询、迭代查询。
- 常见的HTTP状态码含义，比如301、302、403、404、500、502、504。
- 负载均衡和反向代理的基本概念，Nginx和LVS这类工具在架构里的位置。
其中TIME_WAIT几乎是必考，而且出题人往往会换个场景问你，比如“服务器上出现大量CLOSE_WAIT连接，可能是什么原因、怎么排查”，这比直接问“TIME_WAIT是什么”要难一截。
这种题目表面考网络协议，实际考的是你有没有真实排障经验。因为只有真遇到过连接数被打满、服务响应变慢的情况，才会去查netstat和ss的输出，才会知道CLOSE_WAIT和TIME_WAIT对服务的影响是完全不同的。
2.4 怎么让基础题答案显得“有实战经验”
我自己的体会是，笔试答题尤其是命令题和排查题，不要只写结论，要把你的“思考动作”写出来。比如问你怎么排查服务器负载过高，很多人直接写“用top看”，这太单薄了。
更完整的思路是：
- 先用
top看整体负载和CPU占用，确定是CPU密集还是IO密集。 - 如果是CPU高，用
top -Hp找具体线程，再用jstack或者perf定位到代码层。 - 如果是IO高，用
iostat -x 1看磁盘利用率，再用iotop定位进程。 - 同时检查系统平均负载
uptime，结合CPU核数判断负载是否真的过高。
这套思路一写出来，阅卷人就知道你是真排过障的。笔试不要求你一字不差背出所有命令参数，但要求你展示清晰的排查逻辑，这个逻辑本身就是运维开发的核心能力。
3. Python题目：笔试的区分度，藏在这些“小坑”里
3.1 Python在运维开发笔试中的角色
运维开发岗位的代码考察不是LeetCode那种算法题，更偏向工作场景里的脚本能力和代码规范。我当时遇到的Python题目大概分这几类：
- 字符串与文件处理：数据清洗、格式转换、日志提取。
- 系统信息采集：遍历目录、读取文件、获取进程信息、生成报告。
- 简单数据处理：统计词频、按条件过滤、排序去重。
- 面向对象或者模块化设计：要求把功能封装成函数或类。
难度不算高，但有一类同学会吃亏：平时用Python写脚本很熟练，但没注意工程规范，比如命名随意、不写异常处理、不考虑文件过大时的内存占用。笔试里如果你代码写得很漂亮但没处理文件不存在的情况，可能会被扣分。
3.2 字符串处理题：别在简单题上翻车
有一类题看起来很简单，就是给你一段包含多行信息的文本，让你提取特定字段。比如给出一批服务器信息，格式是hostname:IP:port:status，要求把status为online的服务器IP和port打印出来。
我当时的思路是：
with open('servers.txt', 'r', encoding='utf-8') as f: for line in f: line = line.strip() if not line: continue parts = line.split(':') if len(parts) != 4: continue hostname, ip, port, status = parts if status == 'online': print(f'{ip}:{port}')这段代码看上去简单，但包含了几个关键点：用strip()去空白、跳过空行、切分后校验字段数量、解包赋值。如果你只写print(line.split(':')[1])这种不考虑异常的方式，虽然也能跑通，但在工程上是不够严谨的。
这类题的隐藏考点其实是“你写脚本时会不会考虑脏数据”。真实日志、真实配置文件里总会混入空行、缺失字段、格式异常，一名有经验的工程师写代码时会天然把这些情况纳入处理范围。
3.3 数据统计类题目：考察的是效率和可读性
如果笔试里出现“统计一批文件里所有单词的出现次数”这类题，就已经算稍微进阶一点的了。简单写法是用字典遍历：
from collections import Counter word_count = Counter() with open('data.txt', 'r', encoding='utf-8') as f: for line in f: words = line.split() word_count.update(words) for word, count in word_count.most_common(10): print(f'{word}: {count}')用Counter而不是自己维护字典，在可读性上会好很多。如果文件特别大，单机内存装不下，可以进一步考虑用多进程分片处理或者引入外部排序思路。但笔试一般不要求优化到那个程度，你如果能提出“文件大时我会按行流式读取而不是一次性read()”，就已经足够体现工程意识了。
3.4 写代码的三个习惯，笔试里能救命
我后来面试的时候问过面试官，运维开发笔试里他们最看重代码的什么。得到的回答大致可以总结成这样几点：
- 代码能跑通是第一位的，思路可以简单但别写得晦涩。
- 变量命名要有意义，
a、b、c这种在评审里很吃亏。 - 异常处理要到位，文件读取、网络请求、数据处理都可能有异常。
还有一个容易被忽略的是：笔试写代码时要把自己的思路用注释写出来。因为有时候阅卷人不一定能仔细跑代码，注释能让你的思路清晰呈现，方便判断你的能力。
4. 数据库、缓存与监控：运维开发绕不开的三大件
4.1 SQL题目考到什么程度
运维开发岗位的SQL考察不会太难，但也不会只是简单select。我遇到的SQL考点主要有：
- 多表关联查询，特别是inner join和left join的区别与使用场景。
- 分组聚合，group by加having的配合。
- 子查询和临时表。
- 索引的基本概念，什么时候索引会失效。
- 慢查询的排查思路。
印象比较深的一道题是让写SQL统计每个部门的平均薪资，并且只输出平均薪资大于某个阈值的部门。
SELECT dept_id, AVG(salary) AS avg_salary FROM employee GROUP BY dept_id HAVING AVG(salary) > 8000;这道题本身不难，但它后面还跟着两个小问：如果员工表有10万行数据，这个查询会很慢，你会怎么优化；如果加了索引还是慢，你会从哪里入手排查。这时候就不光是SQL语法了，而是看你懂不懂执行计划、懂不懂索引原理。
我在回答优化思路的时候提到了“先用EXPLAIN查看是否走了索引，如果数据量实在大就考虑按部门分表或者用汇总表”，这种偏工程的解法才是这类题真正想看到的。
4.2 缓存和消息队列：概念题会被包装成场景题
奇安信这种公司内部会有大量的数据采集任务、扫描任务、告警任务，这些场景天然会用到缓存和消息队列。笔试里不会直接问“Redis有哪些数据结构”，而是给一个场景让你选型。
比如题目大概是：一个日志采集系统，白天高峰期每分钟会有几十万条日志进来，需要先写入一个中间层，再由后端的消费者异步处理，问你会用什么组件、为什么。
我当时的回答是：用消息队列做削峰填谷，比如Kafka或者RocketMQ，日志采集端只管往队列里写，消费者按自己的节奏拉取处理。同时用Redis做热点数据的缓存，比如去重判断、统计计数，这些高频读写如果直接打到数据库很容易被打爆。
这类题目没有唯一标准答案，但你的回答里一定要体现“为什么”。只说“用Kafka”是不行的，要说清楚Kafka的分区机制、吞吐优势、消息堆积能力为什么适合日志这种海量写入场景。
4.3 监控与告警：笔试里最容易忽略的送分题
监控在运维开发的工作里占比很高，但笔试复习时很多人会忽略，因为网上八股文很少系统性地讲监控。
实际上这个岗位的职责描述里，“负责监控系统的开发与维护”几乎是标配。所以笔试会考一些监控相关概念，包括：
- 监控数据采集方式：agent方式还是pull方式。
- 时序数据库的基本概念，比如数据点、标签、采样间隔。
- 告警规则的设计，怎么避免告警风暴。
- 可视化展示，比如grafana的基础用法。
我记得有一道题是让你设计一个告警系统，要求：某个接口的响应时间P99超过2秒时发出告警，连续3个采集周期都超时才告警，恢复后自动恢复。
这个题考察的就是你对告警规则和阈值设计的理解。我答的时候专门提到了“连续3个周期再告警”是为了避免偶发抖动触发一堆无意义通知，这种细节面试官会很喜欢，因为它说明你真的干过监控值班。
4.4 这类基础题最容易忽略的复习盲区
如果你也是准备运维开发岗位，我建议不要只刷Linux和Python，把数据库索引、Redis数据结构、Kafka的消费模型、监控告警的基本设计都过一遍。安全公司对系统的稳定性要求往往比普通业务更高，所以这些方向几乎必考。
5. 流程设计题：“给一个服务上线，你会怎么安排”这类题的答法
5.1 一道发布流程设计题
笔试后半段会出现流程设计类的简答题，没有标准代码，纯粹看你的思路。我印象里有一道题大概是：一个后端服务需要从测试环境发布到生产环境，现在手里有代码仓库、构建服务、测试环境、生产环境、监控系统，请你描述完整的发布流程，并说明每一步需要注意什么。
这类题千万不要只写“先构建再发布”，那样等于没答。你需要把发布流程拆成可执行的多个阶段：
- 代码合并到主干后触发构建，构建产物打好版本号。
- 在测试环境部署，跑自动化测试和接口冒烟测试。
- 测试通过后进入生产发布前的准备工作：备份数据库、确认配置项变更、准备回滚方案。
- 生产环境分批发布，比如先一台验证，再逐步扩大。
- 发布后立刻检查监控、日志、核心接口的返回状态。
- 如果出现异常，按照预案回滚。
我回答了基本流程之后又补了一点：发布窗口的选择。如果不是紧急修复，尽量选在业务低峰期发布，尽量减少对线上用户的影响。这个细节是我在实际发布中踩过坑后总结出来的，写上去会显得实操经验更丰富。
5.2 故障排查思路题：把“看起来手忙脚乱”变成结构化表达
还有一类题是给你一个故障场景让你排查。比如：线上某个服务最近响应变慢，从监控看CPU使用率很高，请问你会怎么定位。
这道题我当时的回答结构是：
- 先用
top确认是不是真的CPU高，以及是用户态高还是内核态高。 - 再用
top -Hp找到具体线程ID，把线程ID转成十六进制。 - 如果是Java应用，用
jstack导出线程快照，搜索对应线程号，看它在执行什么方法。 - 结合代码分析是业务逻辑性能问题还是GC频繁问题，必要时配合
jstat看GC情况。 - 如果定位到是某个接口慢，可能还需要结合APM工具看调用链，确认是不是下游依赖导致的。
这种题本质是考察排查思路是否结构化。哪怕你对某个工具不熟，只要步骤清晰，说明你知道“从现象到定位”的完整链路，就比只写一两个命令要强得多。
5.3 能体现“老手感”的三种回答习惯
流程题和排查题想拿高分，不靠背模板，靠展示习惯。我总结出三个特别加分的小习惯：
- 回答里带上“先确认”“再验证”“最后收尾”这种步骤词，让过程清晰可见。
- 提到回滚、备份、灰度、告警抑制这类不上台面但很重要的细节。
- 遇到没有把握的方向，主动说“我会先看xxx，如果xxx再换方向”，体现灵活应变。
这些习惯装是装不出来的，最好是在实际工作或者自己的实验环境里真的操作几遍。哪怕没有生产环境，自己在虚拟机里搭一套服务、写个脚本、手动制造一次故障再排查，也能帮你把思路理顺。
5.4 关于这类“没标准答案”的题，为什么反而要重视
很多人一看这类题字数多、没有代码，就觉得随便写写就行，这恰恰是最大的误区。阅卷人看前面的选择题，只能知道你“知不知道”，而看你的流程描述、排查思路，才能判断你“会不会干活”。运维开发招进去是要直接面对线上系统的，一道流程设计题答得好不好，比十道选择题都有区分度。
6. 走到面试环节：面试官会更在意什么
6.1 简历上的项目，会被问到什么程度
笔试通过之后一般会进入面试。奇安信的技术面试风格比较务实，面试官不会问你特别偏门的算法，而是围绕你的简历项目深挖。
我当时简历里写过自己做过的一个日志分析小工具，面试官就顺着这个项目问了一连串：
- 数据量多大，处理耗时多少？
- 用的什么架构，单机还是多机？
- 有没有考虑过日志格式变化的情况？
- 如果有新的日志格式要支持，需要改多少代码？
这些问题说穿了就是在验证你到底有没有亲手做过。如果你简历里的项目是自己搭过、跑过、踩过坑的，这种追问很容易应对；如果你只是把别人的开源项目抄了一遍，很容易被问穿。
我当时的建议是：简历里的项目宁可少写，也要写自己真正动手做过的。哪怕项目很小，只要你把细节都吃透了，面试表现会远比丢一个“高并发xx系统”但是一问三不知要好得多。
6.2 工具链的深度比广度更重要
面试官也会问你对CI/CD工具链的掌握情况。常见的问题包括：
- Jenkins的Pipeline和自由风格任务有什么区别？
- 你在Pipeline里一般怎么组织多个Stage？
- Docker镜像构建过吗，多阶段构建用过吗？
- K8s了解多少，Pod的调度策略知道哪些？
这几个问题不需要你全部精通，但至少要有一个方向是能深入聊下去的。我当时对Docker和Jenkins比较熟，就从镜像瘦身、多阶段构建、Pipeline里并行任务这几个点展开聊，面试官也顺着我的思路继续问了一些技术细节。
这里我个人的经验是：选择一个你最常用的工具，把它从原理到使用到踩坑全过程研究透，比各个工具都了解皮毛有用得多。面试官通常不会指望一个应届生什么都会，但你至少得证明你有“遇到问题能自我驱动去深入研究”的能力。
6.3 提前准备几个“安全公司特色问题”
投奇安信这种安全公司，最好提前想想安全相关的平台和工具。面试官可能会问：
- 你了解奇安信的产品吗？
- 你对安全行业的运维开发有什么理解？
- 如果让你维护一批客户现场的安全探针，你会设计怎样的监控方案？
这种问题不需要你背产品手册，但你得表现出对安全业务场景的基本认知。我当时在回答里提到了一点：安全探针部署在客户复杂网络环境中，比普通运维更需要考虑资源占用和网络隔离，这个点面试官是比较认可的。
6.4 一个容易被忽视的环节：反问环节准备
面试最后一般会让你反问，很多人会问薪资或者加班，这倒不是不能问，但建议你预留一两个技术问题。比如你可以问团队目前用的监控系统是什么，或者问当前这个岗位负责的业务模块有哪些。
这些问题既解决自己的信息盲区，也能让对方觉得你是真心在做选择，而不是海投试水。我记得当时问的是“团队目前的发布流程里人工操作还有哪些”，面试官明显愣了一下，然后认真跟我聊了很多，那个瞬间我能感觉到沟通的质感完全不一样了。
写在最后：这场笔试给我留下的几个具体教训
考完复盘的时候，我最深的感受是：这场笔试没有偏题怪题，但它用最基础的题目筛掉了基本功不扎实的人。你要是平时习惯在服务器上边查文档边敲命令，笔试时会觉得很多题都见过；但如果你只是背了命令参数，真正写的时候就会犹豫。
几个实在建议：
- 准备阶段多动手敲指令。可以在自己电脑上搭个虚拟机或者买个便宜的云主机，把日志分析、进程排查、脚本编写这些操作多练几遍。
- Python题目一定要自己写一遍再优化一遍。连编译都不确定能过的代码，笔试里大概率有语法错。
- 流程设计题别嫌烦，多写几句，把“备份”“回滚”“监控”这些词用进去，你的答案会立起来。
- 简历里的项目要能经得起追问，哪怕再小的工具，把设计和实现吃透了。
这一期先写到这吧，如果后面有精力，我再把当时记忆里的几道具体题目和参考答题写出来，做成一个系列里的第二篇。备考这种事，信息差往往是最大的成本，希望这篇能帮后面准备的朋友省点时间。
