1. 岗位定位与笔试全貌：运维&安全双跑道到底在考什么
先交代一下背景。8月底投递了美团运维&安全岗，9月上旬收到第一批笔试通知，线上双机位监考，总时长120分钟。整体感受是：这个岗位并不是简单的“运维题+安全题”拼盘，而是把两者揉进了一整套生产环境视角的考察里。你既要懂Linux、K8s这套基础设施，也要能用安全思维去看待它们。单纯背八股，或者只刷安全题，都会在某个模块上卡壳。
我得先提醒一句：运维&安全岗的笔试和纯后端开发岗的笔试完全是两个物种。后端笔试重算法、重系统设计，而运维笔试重排错链路、重组件原理、重命令落地。安全模块则偏防御性思维，比如“这个配置哪里有风险”“这个请求该怎么校验”，而不是让你去写漏洞利用代码。理解了这层定位，复习方向才不会跑偏。
笔试的题型大致分四块：选择题（覆盖网络、操作系统、数据库基础）、运维场景题（给一段线上故障表现让推断原因）、安全基础题（Web漏洞、认证授权、容器安全）、以及一道综合性主观题（给你一个系统架构图，让你从运维和安全两个角度提出优化方案）。时间看起来有120分钟，但主观题非常耗时间，前面留给选择题的时间一定要控制住，我大概用了50分钟把选择+定项题清完，剩下70分钟全部压在场景题和主观题上，最后勉强写满。
从热搜词里能看出来，现在这类岗位的考察重点已经被网友盘得很明确：Linux常用命令、Kubernetes调用containerd的链路、Web安全、容器安全、NameNode安全模式、API Key安全对接，还有一批运维工具箱、效率工具、AI安全的新词。这些基本就是笔试和面试的高频区间。下面我按考察密度从高到低，逐个模块复盘。
2. Linux与系统基础：笔试里最不能丢的分
2.1 命令考察不是“会敲”而是“会排错”
Linux命令几乎出现在所有大厂的运维笔试里，美团这批也不例外。但它的考察方式很务实：很少直接问“查看端口的命令是什么”，而是给你一个故障现场，让你选出排查命令的合理顺序。
举个例子，一道题大致是：线上服务访问变慢，load average飙高，让你从下面几个命令中选出最合理的排查组合。A选项是uptime→top→free→iostat→netstat，B选项是df -h→du -sh→ls -l，C选项是ping→traceroute→nslookup。很多人会凭感觉选C，因为说到“慢”第一反应是网络，但实际负载高的情况下，第一优先级一定是看系统负载和进程状态，uptime先看load，top看CPU占用最高的进程，free看内存是否吃紧，iostat看磁盘IO是否有瓶颈，最后用netstat或ss确认连接数是否异常。我在写这道题时心里的判断链路是：先看系统资源，再看进程，最后才看网络。网络排查通常是在系统资源正常的情况下去做。
顺带把高频命令的“排错版本”给大家过一遍，笔试选择题里换汤不换药：
uptime：看1/5/15分钟负载，判断负载是瞬时飙高还是持续走高。top：按CPU或内存排序，top -Hp PID看线程级别，定位是哪个线程在空转。free -h：区分buff/cache和实际可用内存，注意available才是真正可用的近似值。iostat -x 1：看%util、await，判断磁盘是吞吐瓶颈还是延迟瓶颈。ss -tnp：比netstat更快，能直接看到进程和连接的关系。dmesg -T：看内核日志，很多OOM、磁盘IO错误、软锁问题都能在这里找到第一现场。journalctl -u service_name：看systemd服务的日志，笔试里配合systemd题出现的频率不低。
2.2 系统启动与服务管理的隐藏考点
另外有一道题让我印象很深，它是把系统启动流程和故障排查结合起来了：服务器重启后SSH连不上，但通过厂商的远程管理卡能看到系统停在某个阶段，让你判断最可能的原因。这里其实隐藏考了systemd的启动顺序以及default.target、multi-user.target这些概念。如果某个服务在network.target之前启动，而这个服务又必须依赖网络，就会导致启动阻塞或启动后反复重启。
考察到systemd时，笔试里的典型考点包括：
systemctl list-unit-files和systemctl list-units的区别，一个看开机自启配置，一个看当前加载状态。systemctl status中的Loaded、Active、Sub三个状态位的含义，尤其是Sub为failed时怎么查原因。- 服务单元文件中
After和Requires的逻辑差异。After只是排序，不保证依赖关系，而Requires是硬依赖。这个点我在选择题里见过不止一次。 - 救援模式和emergency模式的区别：一个会启动基础网络，一个几乎是单用户状态。笔试中给一个忘记root密码的场景，标准答复路径就是进入emergency模式重新设置密码，再重启。
说到底，运维岗笔试的Linux题考的不是“你背了多少命令”，而是“你在故障现场能不能找到正确的命令组合”。所以复习时别只刷命令大全，多想想每条命令在什么场景下用、输出里哪一列才是关键指标。
3. Kubernetes与容器调度：从原理到调用链的深度考察
3.1 K8s调用containerd的完整链路
热搜词里有一条非常扎眼：“想知道kubernetes是如何调用containerd的，从原理到实体调用架构”。这几乎就是运维&安全岗笔试和面试的原题。美团的基础设施早就容器化，这个问题在笔试里确实出现了，而且不是简单地考“kubelet通过CRI调用containerd”这种一句话答案，而是让你把一个请求从创建Pod到容器真正跑起来的完整链路排出来。
从原理上，这条链路大概是这样的：
- kube-apiserver收到创建Pod的请求，写入etcd。
- kube-scheduler监听Pod变化，选择合适节点。
- 节点上的kubeletwatch到Pod被调度到本节点，进入Pod创建流程。
- kubelet 通过CRI（Container Runtime Interface）调用容器运行时。这里要注意，kubelet本身并不知道containerd的存在，它只认CRI。containerd实现了CRI插件，本质上是把CRI的gRPC请求转换成对containerd内部API的调用。
- containerd再调用containerd-shim，shim进程负责拉起runc，由runc基于OCI规范创建容器。
- 容器进程启动，shim进程持续作为容器和containerd之间的桥梁，负责转发信号、收集状态。
这里面有一个容易混淆的地方：containerd不是直接通过runc创建容器的，中间还夹了一个shim层。shim的作用非常关键：它把containerd和容器进程解耦，即使containerd重启，已经跑起来的容器也不会死。笔试里如果考“containerd重启容器会不会受影响”，正确姿势就是围绕shim这个设计来答。
另外高频考点是CRI和OCI的边界。CRI是kubelet和容器运行时之间的接口，本质是K8s定的标准；OCI是容器运行时和操作系统之间的标准，定义了镜像格式、运行时规范。containerd在这两层里都充当了适配者的角色。很多人把CRI和OCI混淆，笔试一旦出现“kubelet通过什么接口调用containerd”这种题，答案是CRI而不是OCI。
3.2 容器安全与镜像安全的题目复盘
容器安全在安全模块里占了很大比重，这也贴合热搜词里的“镜像安全和容器安全”。题目大概有这么几个角度：
镜像安全：基础镜像过旧、包含已知漏洞（比如老版本的OpenSSL）、镜像来源不受信任、镜像没有签名校验。最佳实践是多阶段构建减小攻击面，使用官方或内部私有仓库的基础镜像，接入镜像扫描工具（如Trivy、Clair）做漏洞检测，并用cosign这类工具对镜像签名。
运行时的容器隔离：容器本质是共享内核的，不能当轻量级虚拟机用。如果容器内需要高权限操作，使用--cap-drop=ALL加白名单capability的思路，而不是直接--privileged。这道题白送但很多人丢分，因为背了“容器隔离性好”这句话，却不知道它隔离在哪个层面。
安全配置：以非root用户运行容器、只读根文件系统（readOnlyRootFilesystem: true）、配置Seccomp和AppArmor Profile、限制allowPrivilegeEscalation为false。这些在K8s的Pod Security Standards里有对应分级，笔试通常会给一个Pod YAML让你挑出哪几处配置有安全风险。
我备考时整理过一个很实用的清单，笔试场景题可以直接套用：
- 镜像是否有非官方来源或latest标签？
- 容器是否以root身份运行？
- 是否挂载了宿主机敏感目录（如
/var/run/docker.sock）？ - 是否保留了不必要的capability？
- 是否声明了资源limits？没有limits的容器可能被DoS打爆节点CPU。
- 是否存在
privileged: true？
这套清单不只是应试，实际工作中排查容器安全隐患时也是这么逐项过。
4. 安全方向的题目：从Web漏洞到服务安全配置
4.1 Web安全与安全测试的基础题
安全模块的Web部分没有考偏门漏洞，核心还是围绕OWASP Top 10的常见项展开：SQL注入、XSS、CSRF、SSRF、文件上传、越权、敏感信息泄露。但它的出题方式比较结合业务，比如给一个登录接口，让你判断在传参、鉴权、返回结果哪里存在问题。
SQL注入的考察点偏向预编译和参数化查询。题目会给一段拼接SQL的伪代码，让你指出安全隐患，并选出修复方案。标准答案是使用PreparedStatement或MyBatis的#{}占位符。有个容易忽略的细节：${}和#{}的区别，前者是字符串拼接，后者是预编译占位符，很多人在选择题里混了。
CSRF和越权是笔试里特别喜欢组合考的两类。CSRF核心是“带上凭证的非法请求伪造”，防御手段有CSRF Token、SameSite Cookie、校验Referer/Origin。而越权分水平和垂直，水平越权指A用户访问B用户的数据，垂直越权指普通用户访问管理接口。它们共同的关键点是：服务端是否校验了当前会话的owner与目标资源owner的一致性。如果你在笔试题里看到“通过修改ID就能查看他人订单”这种描述，脑子里要立刻弹出“水平越权”。
SSRF在运维岗笔试里出现的频率也在增加，因为运维日常要配置回调地址、Webhook、健康检查URL，一旦用户可控输入被拼进服务端请求，就可能变成SSRF入口。笔试考法通常是给一个图片加载代理功能的代码，让你判断存在什么漏洞。修复思路是：做URL白名单、解析后校验IP不为内网地址、禁止重定向。
4.2 API Key安全对接与身份认证
热搜词里有一条“java springboot apikey 安全对接”，正巧这类题在安全岗笔试里出了。题目给了一个Spring Boot服务，要求对接外部系统的API Key，问你怎么设计才是安全的。这类题没有标准代码，但考察点非常固定：
- API Key不能硬编码在代码里，要放到环境变量或配置中心，并做权限隔离。
- 传输要加密，使用HTTPS保证Key不暴露在明文流量里。
- 服务端要校验Key的归属和有效期，不能只做存在性校验。
- 日志里不能打印完整API Key，要做脱敏处理。
- 更进一步，给Key绑定IP白名单或调用频率限制，降低泄露后的影响范围。
这里有一个比较深入的考察方向是签名机制。很多开放平台不直接用明文Key请求，而是用Key+Secret对请求参数做HMAC签名，服务端用同样的算法重新计算签名来校验。好处是传输过程中不会出现明文Secret，即使请求被截获，也无法伪造后续请求。笔试里如果给一段“请求头里带了sign"相关的代码，大概率就在考这个思路。
我当时看到这道题的时候，第一反应是联想到实际开发里经常踩的坑：Key存在配置文件里，代码提交到了Git仓库，直接被扫描工具扫出来，导致Key泄漏。所以我在主观题里把“密钥管理”和“泄漏应急”也写进去了，包括如何吊销旧Key、如何轮转新Key、如何通过审计日志定位泄漏源。
4.3 Hadoop生态的安全模式题：NameNode与HDFS
这个考点在运维岗笔试里不算主流，但美团这种有大数据集群规模的公司会考，而且热搜词里“namenode处于安全模式”说明很多人确实被这道题卡过。
NameNode安全模式（Safe Mode）是HDFS的一种只读保护状态。它在NameNode启动时自动进入，此时文件系统只允许读操作，不允许写操作，DataNode会持续上报块报告，NameNode在后台检查数据块的副本率。等到满足条件（默认99.9%的块达到最小副本数）后自动退出安全模式。
笔试的考法通常是两个方向：一是安全模式卡住不退出怎么排查，二是手动进入/退出安全模式的命令。
排查思路是：先执行hdfs dfsadmin -safemode get查看状态，然后hdfs dfsadmin -report检查块信息和存活DataNode数量。常见诱因是DataNode宕机太多、网络分区、磁盘故障，导致块副本数不足。如果块确实有丢失，要先把故障节点恢复或从备份中恢复数据，不能简单用hdfs dfsadmin -safemode leave强制退出，那会让缺失的数据块继续被读写，引发连锁问题。
命令层面需要记住：
hdfs dfsadmin -safemode get：查看当前状态。hdfs dfsadmin -safemode enter：手动进入安全模式。hdfs dfsadmin -safemode leave：手动退出安全模式。hdfs dfsadmin -safemode wait：等待安全模式自动退出，常用于脚本自动化的操作编排。
我在笔试里是把这类题当作**“分布式系统的自我保护机制”**来理解的。安全模式不是故障，而是一种防止系统在数据不完整状态下继续写入的兜底策略，跟MySQL的read-only、Redis的保护模式有相似的思维逻辑。理解了这层，答这类题就不容易慌。
5. 容易被忽视的运维工具与综合素养题
5.1 网络运维与效率工具
网络基础题在选择题里出现频率不低，但它考得比纯网络认证题更贴近运维。比如两道印象比较深的：
一道是DNS解析和CDN回源的排查：给一个用户反馈“部分地区访问慢”的场景，让你判断从客户端到服务端需要依次排查哪些环节。正确的链路是：本机DNS解析→Local DNS缓存→CDN节点命中→源站响应。如果CDN命中率正常但源站响应慢，那问题可能在源站的负载均衡层，而不是客户端网络。
另一道是TCP三次握手和连接状态判断：给一段netstat -an的输出，里面有一堆SYN_RECV状态的连接，问最可能的原因。常见原因有三个：目标端口被防火墙拦了、backlog队列满了、SYN Flood攻击。这道题本质是考ss -lnt里的Send-Q列，也就是accept队列长度。如果队列满了，内核会丢弃SYN包，客户端就会反复重传，表现为大量SYN_RECV。
效率工具这块，热搜词里的“IT运维效率工具”和“网络运维工具箱”在主观题里通常是作为背景出现的。比如问你“日常巡检你会做哪些事”，如果你能答出用脚本批量采集top、free、df、ss等命令输出，并自动生成巡检报告，而不是登录每台服务器手动执行，那这道题的分数档次就完全不一样了。另一个高频点是统一日志平台，比如ELK或Loki，把分散在几十台服务器上的日志聚合起来，再配告警规则，这才算一个完整的运维观测体系。笔试不会要求你手写ELK配置，但会考你对“采集→传输→存储→检索→告警”这个链路的理解是否完整。
5.2 AI运维、数字化运维与新的考察方向
2025年这批笔试里，最明显的新趋势是AI运维和数字孪生进入了考察范围。热搜词里“《信息技术 隧道运维管理数字孪生系统技术要求》”看起来有点冷门，但它代表的是一个方向：运维对象正在从IT系统延伸到物理基础设施，运维手段正在从规则脚本升级为AI辅助决策。
笔试里确实有一道主观题和这个相关，大意是：一个大型数据中心，让你设计一套日常运维与安全基线方案。我在作答时把AI运维的思路也写了进去：用指标异常检测模型来自动识别流量突增或CPU毛刺，而不是等监控阈值触发告警；用日志聚类算法把相似故障归类，减少告警风暴；用知识库沉淀故障处理手册，让后续故障能通过检索历史案例快速定位。这套思路并不复杂，但能体现出你关注到了运维从“被动响应”向“主动发现”转型的趋势。
AI安全也是新热点，模拟CTF赛里包含AI安全题目让很多人措手不及。笔试层面不会考得太深，但你要懂几个基础概念：提示注入（通过构造输入让大模型输出偏离预期）、训练数据投毒、模型窃取、对抗样本。这个方向对运维岗的意义在于：如果公司的AI服务被攻击，运维要能看懂安全团队提的工单，知道问题出在模型层还是基础设施层。哪怕笔试只考一个选择题，具备这个视野也能让你在主观题里多一个答题维度。
6. 复盘与建议：后续批次和下一届可以怎么准备
6.1 我踩过的坑
第一个坑是时间分配失衡。我前面提到选择+定项用了50分钟，其实还是偏长了。有些不定项选择题每个选项都需要琢磨，很容易耗掉大量时间。后来复盘，调整后的策略应该是：一眼能确定的题直接过，模棱两可的题先标记，等主观题写完之后再回来看。运维笔试的主观题分值占比很高，写不完才是最大的损失。
第二个坑是YAML配置题没看清条件。有一道K8s安全配置的题目给了一段Deployment YAML，要求指出风险点并修改。我第一遍看只关注了privileged和root，漏了imagePullPolicy: IfNotPresent这个细节。在镜像tag是latest的情况下，如果用IfNotPresent策略，节点上已有的旧镜像不会被拉取更新，生产环境等于跑了一个“不可变版本”，这也是一个安全隐患。
第三个坑是主观题答得太开发化。题目要求“从运维和安全角度提出优化方案”，我却花了很多篇幅写代码逻辑优化，写到最后才发现没留足够空间写监控和容灾。运维岗主观题的核心关注点是：可观测性、高可用、容灾恢复、安全基线。从这几个维度去答题，方向就不会偏。
6.2 有侧重点的复习路线
如果你还在准备美团后续批次的笔试，或者打算明年再战，我建议按下面的优先级来安排：
第一优先级（必拿分）：Linux常用命令与故障排查思路、systemd基础、网络基础（TCP状态、DNS、负载均衡）、常见Web漏洞原理。这些题覆盖面广，出题稳定，只要刷题量够，基本能拿到大部分分数。
第二优先级（区分度）：K8s的核心链路（CRI/OCI/containerd/shim/runc）、容器安全配置、API Key和身份认证设计、NameNode安全模式这类中间件机制。这些题是区分“背过八股”和“真正理解”的关键，也是美团这种技术栈深度的公司特别爱出的方向。
第三优先级（加分项）：AI运维和AI安全基础、数字孪生、运维成熟度体系这些偏前沿的内容。不需要精通，但至少要能说出它们解决什么问题、和传统运维有什么区别。
最后再分享一个小技巧：笔试前可以去看看美团技术博客里关于容器化、K8s实践、监控体系建设的文章。美团的笔试主观题往往和技术团队近期关注的方向强相关，读几篇能让你在答主观题的时候说出一些有内部视角的术语和思路。我这次就是提前看了容器相关的一些实践文章，在答K8s调用链这道题的时候明显比裸分析顺畅很多。祝后续批次的同学好运，运维&安全这个赛道虽然杂，但正因为杂，沉淀下来的经验才真正值钱。
