我做过几年车的云平台也面过不少“运维开发”岗位。看到“小鹏汽车2019春招互联网中心DevOps运维开发工程师笔试题”这个标题时我第一反应不是去回忆哪道题的具体答案而是想先给准备这类岗位的人泼一盆冷水如果你以为这份卷子考的是“会不会搭Jenkins、会不会敲几条Linux命令”那大概率是过不了的。它不是一张纯工具题而是一张在筛选“能不能在智能汽车这种高复杂度业务里用代码和流程把稳定性做出来”的人。这两年“DevOps”和“运维开发”两个词被各种培训课讲烂了“Jenkins vs DevOps”甚至还上过技术热词榜。很多人把Jenkins当成DevOps的全部这恰恰是所有生产事故的起点。笔试里如果出现“说说你对DevOps的理解”你把这两个词混为一谈基本就告别Offer了。我更愿意把这类笔试题理解成一次能力摸底出题人想知道你有没有在真实业务里打过仗有没有从代码提交到车端OTA全链路去看过问题。这篇文章我不会去编造当年真题而是从岗位能力模型、典型考点、系统设计思路和容易翻车的细节几个维度把这张卷子可能会出现的考察面完整拆一遍。如果你正准备投递智能汽车、车联网或者大型互联网公司的运维开发岗位这套拆解思路可以直接拿去做复习提纲。1. 先把出题人“画个像”互联网中心要的运维开发是什么物种1.1 “互联网中心”四个字决定了题目不考硬件考云端软件链路智能汽车公司里的部门很多但“互联网中心”这个定位很明确车联网云平台、用户App、车辆远程控制、大数据采集、OTA升级、充电服务这些软件业务基本都挂在这里。与之相对的是底盘、三电、自动驾驶等更偏硬件和算法的部门。这意味着笔试题目几乎不会出现汽车电子、CAN总线、Autosar这类传统车载内容而是会围绕一套典型的互联网技术栈展开Linux、云主机、容器、CI/CD、监控、数据库、微服务、中间件。但难点在于这套技术栈服务的对象是“在路上跑的车”不是普通的电商订单。车辆一旦连上云所有请求背后都意味着真实的驾驶场景和用户安全这对稳定性的要求远高于普通Web业务。所以我在面对这类笔试时第一判断就是出题人不会只问“Nginx怎么配置反向代理”这种孤立的题而是会把你放进一个“车辆上报数据-云端服务处理-用户App查询状态-运营后台下发指令”的链路里看你能不能找出整条链路中最容易出问题的点。1.2 “运维开发”不是传统运维笔试里藏着“开发”二字的门槛过去很多公司都叫“运维工程师”主要工作是装系统、配网络、看监控。但“运维开发工程师”多了“开发”两个字含义完全不同你不仅要负责系统的稳定运行还要有能力自己写代码把重复性的运维工作平台化、自动化。笔试考察里Shell脚本只是及格线Python/Go至少要能完成一个小的工具开发比如批量处理日志、调云平台API做资源管理、写一个简单的CI插件。“DevOps”和“运维开发”在岗位描述里经常混着出现但它们其实是两个维度的概念。DevOps是一种文化与协作模式强调开发、测试、运维打破部门墙共同对交付效率和服务稳定性负责运维开发则是这种理念落地时的具体岗位角色负责构建持续交付流水线、监控告警体系、故障应急平台等基础设施。这里就涉及到“Jenkins vs DevOps”这个热词为什么总被讨论。很多新人会觉得“我们上了Jenkins所以我们在做DevOps”这个理解是错的。Jenkins只是一个自动化执行工具它解决的是“任务调度和编排”的问题而DevOps要解决的是“人和流程怎么配合”的问题。笔试如果出对比题你需要明确点出Jenkins是工具DevOps是方法工具可以替换方法论才是核心。如果你能顺便提一句“流水线本身也是代码应该入版本库而不是在网页上手动点按钮配置”这题基本就稳了。2. 我把这类笔试题按能力模型拆成了六个知识块这份卷子里不太可能脱离这六个知识块的范围。把它们拆开看每一块都对应一项真实工作中必须用到的能力。下面这张表是我给候选人做模拟面试时常用的对照表可以直接拿来当复习地图。能力模块典型考点对应真实工作场景Linux与网络进程管理、systemd、TCP状态、Nginx、iptables、软硬链接线上故障排查、服务部署脚本与开发Shell/Python脚本、异常处理、幂等性、调用云API自动化运维、工具开发CI/CDJenkins/GitLab CI、Pipeline、灰度发布、回滚应用持续交付容器与KubernetesDockerfile、镜像分层、Pod、Service、PV/PVC云原生基础设施运维监控与告警Prometheus、日志采集、SLO、告警降噪可观测性建设、值班数据库与中间件MySQL主从、Redis缓存、消息队列、数据一致性车联网数据链路保障2.1 Linux和网络是底盘不能只背命令我见过不少简历上写着“熟悉Linux”的候选人一上来就问“CPU负载高怎么排查”只会答“看top”。这个答案不能说错但离及格还差得远。出题人更想听到的是排查思路先确认是用户态、内核态还是IO等待再看是哪种进程消耗的资源然后用top、vmstat、pidstat、strace一层层缩小范围。网络知识的考点更偏向实际问题比如TCP的TIME_WAIT状态为什么会大量出现对高并发的短连接服务有什么影响怎么通过调整内核参数或改用长连接来优化。再比如一台服务器上起了一个Nginx容器外部死活访问不通你会怎么定位这题不是考你背命令而是考你有没有“容器网络—宿主机端口映射—防火墙—云安全组”四层排查的思维习惯。2.2 脚本开发与自动化能力决定你是不是一个“开发”这个模块通常会出两道题一道是Shell一道是Python。Shell题很喜欢考日志分析类需求比如“从Nginx访问日志中统计出访问量最大的前10个IP”这就是考察awk、sort、uniq的组合用法。Python题更偏工程化比如“用一个Python脚本调用云厂商OpenAPI把指定标签的机器统一打快照”这里要考察鉴权、异常重试、日志输出和幂等设计。幂等性这几个字往往是答题的核心但很多人会漏掉。所谓幂等就是同一个操作重复执行多次结果与执行一次相同。打快照这个场景下脚本如果跑两次不应该产生两份重复快照所以执行前要检查是否已有今天的快照。这类题背后的真实理由是运维脚本一旦交给定时任务你就无法保证它每次执行时的环境状态都完全一样只有写出允许重复执行的脚本才能避免半夜3点被报警电话叫醒。2.3 CI/CD和“Jenkins vs DevOps”的辨析几乎是必考CI/CD这块考的不只是“会不会建一个FreeStyle Job”而是对整条交付链路有没有系统性理解。题目可能会给你一张图上面画着代码提交、代码检查、单元测试、构建镜像、推送仓库、部署测试环境、灰度发布、生产发布这些环节然后让你把这些步骤编排成一条流水线。这就是在考你Jenkins Pipeline的语法、阶段划分和失败策略。一个完整的Jenkins Pipeline脚本不需要多复杂但阶段和步骤要实现以下三个关键点代码提交后自动触发而不靠人肉点击构建产物是不可变的镜像而不是每次从代码重新拉取依赖部署环节要支持指定版本回滚而不是登录服务器手改文件。下面是一个非常简化的参考框架pipeline { agent any stages { stage(checkout) { steps { git url: https://git.example.com/backend.git } } stage(build) { steps { sh docker build -t backend:${BUILD_NUMBER} . sh docker push registry.example.com/backend:${BUILD_NUMBER} } } stage(deploy-test) { steps { sh kubectl set image deployment/backend backendregistry.example.com/backend:${BUILD_NUMBER} } } } }下面再来谈谈“Jenkins vs DevOps”。这个对比题本质上是问你DevOps是不是只要买了Jenkins就实现了正确答案是Jenkins只负责把“构建、测试、部署”这些动作自动化即使你把这些环节全部跑通也只是一个自动化的“工具链”而已。DevOps的更高一层还包含文化变革比如开发人员要对自己写的代码在线上运行的好坏负责运维人员要提前介入需求评审而不是等着接锅。如果笔试问“你们公司要实施DevOps你从哪几方面入手”建议从人、流程、工具三个角度回答只说工具的答题深度明显不够。2.4 容器与Kubernetes像考驾照一样考实操概念容器和Kubernetes在车企云平台里确实是主角因为车联网服务需要频繁迭代弹性扩缩容也很普遍。笔试里Docker部分最爱考的是Dockerfile优化比如“前端构建依赖node_modules后端运行依赖Python环境怎么把镜像做得又小又安全”。这题的考点是多阶段构建先用一个包含编译器的基础镜像完成编译再用一个精简的运行时镜像把编译产物拷进去最终镜像体积会降低很多。Kubernetes的考题会更场景化。比较典型的有一个Pod处于Pending状态该怎么排查首先看调度器有没有找到合适的节点再看PVC能不能成功挂载然后看节点资源是否充足。另一个高频考点是为什么不建议把Pod IP直接写进业务配置文件。因为Pod重建后IP会变化正确做法是通过Service做服务发现让客户端访问ClusterIP或域名而不是依赖变化的Pod IP。2.5 监控、日志、告警是车联网系统的眼睛做车联网和普通网站最大的一个区别是车辆不只在工作时段在线而是24小时在路上跑。服务端一旦出问题可能同时影响成千上万辆车的远程控制、状态上报和OTA升级监控必须能在用户在感知之前先发现问题。所以笔试里监控的权重很高考的不是“Prometheus是什么”而是“你会监控哪些指标、告警阈值怎么定、丢失一条车辆日志和丢失一条交易日志哪个更严重”。我自己整理监控类题目的回答时会分三层讲第一层是节点层包括CPU、内存、磁盘、网络这是最基础但必须先覆盖的第二层是服务层包括请求量、错误率、响应时间、队列积压量用于判断服务是否健康第三层是业务层比如当日在线车辆数、指令下发成功率、OTA升级完成率这些指标才能真正反映用户体验。如果只回答“用Prometheus监控CPU和内存”这道题的分值会非常有限。2.6 数据库和中间件的高可用不是背概念要讲落地方案数据库在车企云平台里非常关键因为车辆上报的轨迹、状态、订单、用户资料都存储在数据库里。MySQL部分的常见考点是主从复制和读写分离主库故障时如何切换、从库延迟怎么处理、为什么binlog要设置成ROW格式。Redis部分的考点则集中在缓存穿透、缓存击穿和缓存雪崩三个问题答题时除了说清楚原因更重要的是给出可落地的方案。我建议把这三个问题打包记忆因为它们都是“大量请求打到数据库”的变种缓存穿透是查了不存在的数据布隆过滤器和缓存空值能解决缓存击穿是热点Key突然失效互斥锁和逻辑过期能挡住缓存雪崩是大量Key同时失效过期时间加随机值可以把压力摊开。能够用自己的话把这三个场景区分清楚并说明在车联网的哪类业务中会出现比默写定义更有说服力。3. 从一道典型的系统设计题看车企DevOps的答题思路3.1 题目场景分钟级更新的车辆状态服务这类笔试的最后往往有一道综合题。题面一般会比较长我把它翻译成一句话现在有一个车辆状态服务车辆每30秒通过MQTT上报一次定位和电量数据经过接入网关写入消息队列再由计算服务处理后存入数据库用户手机App要能实时查看车辆位置和电量。现在要求你设计一条从代码提交到灰度上线的CI/CD流程并说明如何保障发布过程中的可用性。很多人一看到这种题就开始背流程图其实出题人想考察的核心是三件事分支策略、环境管理和灰度回滚。我的答题思路是主干开发每个迭代从主干拉release分支测试环境与生产环境严格隔离构建产物不经过二次加工直接生成带版本号的镜像推到镜像仓库部署生产前先在预发环境跑一遍自动化冒烟测试再通过负载均衡或K8s的滚动更新能力做小流量灰度也就是先让5%的流量切到新版本确认无异常后再逐步放开。3.2 为什么这里必须用“不可变产物”而不是登录服务器改代码很多传统运维习惯在线上一台台机器手动更新代码这在小规模场景下还能将就但在车联网云服务这种动辄几十个节点的系统里手动更新等于给自己埋定时炸弹。笔试设计题里你必须明确说出“不可变产物”这个概念也就是每次部署都使用构建阶段生成的那个镜像任何情况下都不允许在生产服务器上改文件、改配置。这样做的最大好处是可重复和可回滚。因为镜像内容是确定的测试环境验证过的版本与生产环境部署的版本完全一致不会出现“测试环境是好的生产环境因为少打了个补丁就挂了”这种经典事故。回滚时也只需要把镜像版本指回上一个版本还不会丢失历史状态的审计能力。如果让我在笔试里挑一个最能体现“懂运维开发”的词汇“不可变产物”绝对排第一。3.3 回滚方案的细节最难答但也是最值分的部分只说出“部署失败了就回滚上一版”是不够的因为这道题到这里才刚刚进入深水区。真要完整回答回滚方案至少需要覆盖两方面代码回滚和数据库兼容。代码回滚可以简单粗暴把镜像指回上一个版本再滚动更新一次即可但数据库不行。比如新版本在数据库里加了一个字段发布后发出去的消息都写了这个字段回滚到旧版本后旧代码不认这个字段轻则数据读不出来重则直接启动报错。所以正确做法是“先兼容再切换”数据库变更需要向前兼容新版代码发布后旧版代码仍然能正常工作如果必须删除某个旧字段也要等新版本稳定运行几个版本周期后再做清理。这一点在车联网场景下尤其重要特别是OTA升级任务。车辆可能分布在不同的网络环境里ota任务下发到车端后车辆的升级进度完全不可控云端的发布平台必须做到“某一批车辆升级失败时不影响其他车辆继续使用旧版本服务”。答题时能够提到这些兼容性细节说明你是真的处理过线上发布的人。4. 可观测性设计车联网监控最容易被低估的分值4.1 监控体系要分四层搭建而不是只装一个监控软件前面已经提到过监控的重要性这里我想多说一层车联网系统的监控对象不能只盯着服务器还要覆盖“车端到云”的完整链路。做题时如果可以画一张分层的监控拓扑会让答案清晰不少。我通常把车联网监控分成四层。第一层是车辆终端层需要关注设备在线率、消息上报频率、弱网重连次数。车辆不可能像服务器一样装一个完整Agent所以一般通过MQTT/HTTP上报心跳和数据平台侧负责判断离线量是否有异常增长。第二层是接入层也就是API网关和消息网关这里重点看请求量、成功率、连接数以及接入服务是否被某地区网络波动拖垮。第三层是业务服务层关注每个微服务的QPS、错误率、P99延迟。第四层是数据层包括数据库连接数、慢查询数量、消息队列的积压量。能把这四层监控完整说出来说明你已经站在车联网系统全局看问题。4.2 告警不收敛等于没有告警这题考的是设计思维在监控类题目里“你会怎么设计告警规则”是特别能拉开差距的问法。如果只回答“CPU超过80%就报警”说明还停留在单机运维的层面。真正有效的告警设计需要做分级和收敛可以用下面的思路回答。第一是设置告警分级P0级表示核心链路不可用需要立即拉群处理比如用户无法登录、指令下发大面积失败P1级表示重要功能受损比如某一地域网络波动导致部分车辆离线P2级表示资源预警比如磁盘使用率超过阈值但业务暂未受到影响。第二是设置聚合策略避免同一时刻上千台机器同时上报导致告警风暴应该按服务、地域、错误码维度聚合后只发送一条告警。第三是治噪有些告警白天黑夜都响如果把阈值调得过于灵敏轮值同事就会开始“狼来了”最终导致真正的P0告警被人类习惯性忽略。4.3 笔试中常见的“线上故障到恢复”小作文有一种高频题是给你一段故障描述让你写出排查和恢复过程。举个例子用户反馈App上面看不到车辆状态了你作为运维开发工程师怎么处理回答这类题千万不要一上来就说“重启服务”而是展示一套标准化的应急流程。我的回答通常分四步先紧急止血先看监控大盘确认是整个区域故障还是单个服务故障如果是单个服务异常优先摘除异常节点让请求路由到健康实例或者回滚到最近一个稳定版本再定位根因查网关日志、服务日志、数据库慢查询和Redis命中率逐步缩小范围接着恢复所有服务并确认用户侧数据恢复正常车辆最新上报的时间不超过预设阈值最后做复盘改进把“这次为什么会漏监控”“下次如何提前发现”写成文档并把补丁改进排进迭代。这套流程能让批卷人看出你不是只会修单机而是有一个成熟的故障管理体系。日志和链路追踪也是可观测性的大头。回答监控题目时如果提一句“用统一TraceID串起车辆上报到App展示的全链路日志”会是明显的加分点。因为车联网请求可能跨MQTT网关、业务服务、数据库和推送系统没有链路追踪线上排查如同大海捞针。5. 那些容易翻车的细节题是我认为整张卷子的隐藏关卡5.1 Linux和Docker现场排查题答不出过程比答不出答案更致命这部分有很多小题目单拎出来都不难但放到一张卷子里会形成一种“步步惊心”的感觉。比如给你一台服务器CPU持续100%让你说出排查步骤。我看过的回答里有直接说“kill掉进程”的这是典型的错误答案因为没搞清楚根因就操作只会让问题换个形态继续出现。正确思路是先通过top找到CPU占用最高的进程再用pidstat定位是哪个线程判断是用户进程的代码问题还是内核线程异常接着看进程运行日志或链路追踪确认是某段逻辑出现死循环还是外部依赖导致自旋等待。如果问题很紧急可以先重启恢复但之后必须保留现场信息用于根因分析比如保存jstack、dump文件或者核心转储文件。Docker面试题里有一道很经典的坑容器内运行的应用要写超大日志或生成Core文件结果容器会莫名退出或者磁盘被写满。这背后有两个考点一个是你知不知道容器日志驱动默认会限制文件大小另一个是你知不知道容器内进程的PID 1会给僵尸进程带来什么麻烦。答题时能够主动说出“用json-file日志驱动并设置max-size和max-file”或者“使用logrotate和hostPath挂载日志目录”说明你对容器运行边界有真实认知。5.2 Kubernetes高频翻车点资源限制、健康检查、版本升级K8s细节题也是重灾区。我遇到过最典型的翻车场景是服务上线后在页面上一会儿好一会儿坏排查半天才发现是Pod没有设置resources.limits导致多个Pod在同一个节点上争抢CPU互相拖垮。如果你在笔试里遇到“为什么微服务重启后有时候启动很慢”大概率就是在考资源限制的问题。另一个高频考点是存活探针和就绪探针的区别。很多人会把livenessProbe和readinessProbe混着用结果服务还在加载配置文件或预热缓存流量就已经打进来了产生大量5xx错误。正确做法是readinessProbe用来控制流量是否进入Pod失败时从Service后端摘掉livenessProbe用来判断进程是否需要被重启代表应用是否卡死。把它放在车联网场景里理解就是车辆连接服务还在努力加载路由表时不能让它接收新连接一旦进程死锁了又需要有人把它重启。最后是版本升级的滚动更新参数maxSurge和maxUnavailable。这两个参数决定了上线时的可用性风险如果maxUnavailable设置得太高更新过程中可能出现短时无可用副本。答题时如果能说出“线上关键服务我会把maxUnavailable设为0maxSurge设为1”比你空谈“我们用了滚动更新”要具体得多。5.3 MySQL和Redis的细节题总有你想不到的丢分点数据库细节题里MySQL主从复制的延迟原因和处理方法常年霸榜。车联网数据上报频率高如果主库写入压力大从库容易慢于主库。答题时我会从三个角度展开看硬件负载和从库所在机器磁盘性能是否达标看是否有大事务或者DDL操作阻塞了复制线程必要时可以把部分读请求切到独立的只读实例或者对统计类查询走大数据链路避免拖垮在线业务。Redis细节题中“为什么Redis集群某个分片内存暴涨”也是一道好题。原因可能是一个大Key集中在一个分片上也可能是键没有设置过期时间。回答时能提到用bigkeys命令扫描大Key、对热Key做拆分、配合内存淘汰策略限制单分片内存水位就比较完整了。这个部分隐藏的总原则其实是任何答案都不能只停留在概念层必须落到“我能用什么命令、什么参数、什么流程去观测和解决”。这才是运维开发区别于纯开发或纯运维的地方。6. 对准备这类笔试的人我最后的几点建议如果只有一个月的准备时间我的优先级建议是先把CI/CD和容器这两块吃透然后补Prometheus监控和故障排查再花时间把MySQL和Redis的高频题目练一遍。因为从岗位名称来看DevOps和运维开发的笔试重点一定是“持续交付”和“稳定运行”这两块占到一半以上的分值都不奇怪。准备方式上不要只刷题最好自己搭一套最小可用的实验环境一台虚拟机装GitLab或Gitea再装一个Jenkins用Spring Boot或Gin写一个最简单的服务跑一条从提交到构建到部署的完整流水线中途故意制造一些故障比如让容器启动失败、让数据库连接池满然后练习怎么通过日志和监控定位问题。我认识很多成功拿到Offer的人都不是靠背题库而是靠在实验环境里反复踩坑把真实操作感练出来了。另外说一句可能有点绕的话笔试里技术题答得再漂亮也只是证明你有“解决已知问题”的能力。真正让面试官记住你的往往是你在回答“你遇到过最棘手的问题是什么”时展现出的排查链路和复盘意识。如果你为了准备这类笔试连一套自己的故障档案都没有抽空把过去工作中遇到的事故记录整理一下比多刷一百道题有用得多。运维开发这个岗位在智能汽车公司里其实比想象中更有意思。你写的流水线会直接影响一个版本能不能安全到达车主的车机你搭的监控会决定用户反馈故障之前内部是不是已经先行发现了你设计的回滚策略会决定一次发布几十万风险可控还是提心吊胆。做这行最重要的不是背会多少工具而是建立起“对系统全链路负责”的思维方式。Jenkins也好Kubernetes也好都是你手里的工具真正的价值在于你能用它们保障业务又快又稳地向前跑。