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加uniqawk {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, encodingutf-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, encodingutf-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里一般怎么组织多个StageDocker镜像构建过吗多阶段构建用过吗K8s了解多少Pod的调度策略知道哪些这几个问题不需要你全部精通但至少要有一个方向是能深入聊下去的。我当时对Docker和Jenkins比较熟就从镜像瘦身、多阶段构建、Pipeline里并行任务这几个点展开聊面试官也顺着我的思路继续问了一些技术细节。这里我个人的经验是选择一个你最常用的工具把它从原理到使用到踩坑全过程研究透比各个工具都了解皮毛有用得多。面试官通常不会指望一个应届生什么都会但你至少得证明你有“遇到问题能自我驱动去深入研究”的能力。6.3 提前准备几个“安全公司特色问题”投奇安信这种安全公司最好提前想想安全相关的平台和工具。面试官可能会问你了解奇安信的产品吗你对安全行业的运维开发有什么理解如果让你维护一批客户现场的安全探针你会设计怎样的监控方案这种问题不需要你背产品手册但你得表现出对安全业务场景的基本认知。我当时在回答里提到了一点安全探针部署在客户复杂网络环境中比普通运维更需要考虑资源占用和网络隔离这个点面试官是比较认可的。6.4 一个容易被忽视的环节反问环节准备面试最后一般会让你反问很多人会问薪资或者加班这倒不是不能问但建议你预留一两个技术问题。比如你可以问团队目前用的监控系统是什么或者问当前这个岗位负责的业务模块有哪些。这些问题既解决自己的信息盲区也能让对方觉得你是真心在做选择而不是海投试水。我记得当时问的是“团队目前的发布流程里人工操作还有哪些”面试官明显愣了一下然后认真跟我聊了很多那个瞬间我能感觉到沟通的质感完全不一样了。写在最后这场笔试给我留下的几个具体教训考完复盘的时候我最深的感受是这场笔试没有偏题怪题但它用最基础的题目筛掉了基本功不扎实的人。你要是平时习惯在服务器上边查文档边敲命令笔试时会觉得很多题都见过但如果你只是背了命令参数真正写的时候就会犹豫。几个实在建议准备阶段多动手敲指令。可以在自己电脑上搭个虚拟机或者买个便宜的云主机把日志分析、进程排查、脚本编写这些操作多练几遍。Python题目一定要自己写一遍再优化一遍。连编译都不确定能过的代码笔试里大概率有语法错。流程设计题别嫌烦多写几句把“备份”“回滚”“监控”这些词用进去你的答案会立起来。简历里的项目要能经得起追问哪怕再小的工具把设计和实现吃透了。这一期先写到这吧如果后面有精力我再把当时记忆里的几道具体题目和参考答题写出来做成一个系列里的第二篇。备考这种事信息差往往是最大的成本希望这篇能帮后面准备的朋友省点时间。
奇安信运维开发工程师笔试经验：从Linux基础到流程设计全拆解
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加uniqawk {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, encodingutf-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, encodingutf-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里一般怎么组织多个StageDocker镜像构建过吗多阶段构建用过吗K8s了解多少Pod的调度策略知道哪些这几个问题不需要你全部精通但至少要有一个方向是能深入聊下去的。我当时对Docker和Jenkins比较熟就从镜像瘦身、多阶段构建、Pipeline里并行任务这几个点展开聊面试官也顺着我的思路继续问了一些技术细节。这里我个人的经验是选择一个你最常用的工具把它从原理到使用到踩坑全过程研究透比各个工具都了解皮毛有用得多。面试官通常不会指望一个应届生什么都会但你至少得证明你有“遇到问题能自我驱动去深入研究”的能力。6.3 提前准备几个“安全公司特色问题”投奇安信这种安全公司最好提前想想安全相关的平台和工具。面试官可能会问你了解奇安信的产品吗你对安全行业的运维开发有什么理解如果让你维护一批客户现场的安全探针你会设计怎样的监控方案这种问题不需要你背产品手册但你得表现出对安全业务场景的基本认知。我当时在回答里提到了一点安全探针部署在客户复杂网络环境中比普通运维更需要考虑资源占用和网络隔离这个点面试官是比较认可的。6.4 一个容易被忽视的环节反问环节准备面试最后一般会让你反问很多人会问薪资或者加班这倒不是不能问但建议你预留一两个技术问题。比如你可以问团队目前用的监控系统是什么或者问当前这个岗位负责的业务模块有哪些。这些问题既解决自己的信息盲区也能让对方觉得你是真心在做选择而不是海投试水。我记得当时问的是“团队目前的发布流程里人工操作还有哪些”面试官明显愣了一下然后认真跟我聊了很多那个瞬间我能感觉到沟通的质感完全不一样了。写在最后这场笔试给我留下的几个具体教训考完复盘的时候我最深的感受是这场笔试没有偏题怪题但它用最基础的题目筛掉了基本功不扎实的人。你要是平时习惯在服务器上边查文档边敲命令笔试时会觉得很多题都见过但如果你只是背了命令参数真正写的时候就会犹豫。几个实在建议准备阶段多动手敲指令。可以在自己电脑上搭个虚拟机或者买个便宜的云主机把日志分析、进程排查、脚本编写这些操作多练几遍。Python题目一定要自己写一遍再优化一遍。连编译都不确定能过的代码笔试里大概率有语法错。流程设计题别嫌烦多写几句把“备份”“回滚”“监控”这些词用进去你的答案会立起来。简历里的项目要能经得起追问哪怕再小的工具把设计和实现吃透了。这一期先写到这吧如果后面有精力我再把当时记忆里的几道具体题目和参考答题写出来做成一个系列里的第二篇。备考这种事信息差往往是最大的成本希望这篇能帮后面准备的朋友省点时间。