# AI 运维岗位面试准备指南（2026） > 面向想转岗、入门或准备面试 AI 运维 / MLOps / AI 基础设施 / AIOps 岗位的学习资料。 > > 调研时间：2026 年 9 月 > > 先说结论：**AI 运维不是只会部署一个大模型，而是要让 AI 系统稳定、可观测、可扩展、可回滚、成本可控。** --- ## 一、先用一句话理解这个岗位 普通运维关注： ```text 服务器、网络、数据库、网站服务能不能稳定运行？ ``` AI 运维还要额外关注： ```text 模型能不能稳定训练和推理？GPU 有没有被正确使用？ 模型变更会不会让回答质量下降？延迟和 Token 成本是否超标？ ``` 可以把 AI 系统想成一家餐厅： | 餐厅 | AI 系统 | 运维要做的事 | |---|---|---| | 厨房、水、电、煤气 | Linux、网络、存储、GPU | 保证基础设施可用 | | 厨房的工作台和流程 | Docker、Kubernetes、CI/CD | 让服务可以快速、标准地部署 | | 菜谱和厨师 | 模型、推理服务、训练任务 | 管理模型版本和服务质量 | | 订单系统 | API、网关、队列、数据库 | 处理请求、限流、排队、鉴权 | | 监控摄像头 | Prometheus、Grafana、日志、链路追踪 | 发现问题并定位原因 | | 店长的应急预案 | 告警、回滚、容灾、自动修复 | 出问题时快速恢复 | --- ## 二、招聘市场调研结论 ### 1. 我参考了哪些招聘平台 本次主要对比了 **BOSS 直聘、猎聘、智联招聘** 上公开展示的岗位描述。招聘信息会变化，下面是多个职位样本中反复出现的共同要求，不代表所有岗位的统一硬性标准。 ### 2. 岗位大致分成四条路线 ```text AI 运维岗位 | +----------------------+----------------------+----------------------+ | | | | AI 平台运维 MLOps / LLMOps AI Infra / GPU 集群 AIOps 智能运维 | | | | 部署、监控、故障 训练、模型注册、发布 GPU、CUDA、调度、推理 告警、RAG、Agent、 客户交付 漂移监控 性能 根因分析 ``` | 方向 | 主要工作 | 入门难度 | 常见关键词 | |---|---|---:|---| | AI 平台运维 | 部署平台、巡检、监控、故障处理、私有化交付 | 中 | Linux、Docker、K8s、Nginx、Redis、Prometheus | | MLOps / LLMOps | 管理训练、实验、模型版本、上线和监控 | 中高 | MLflow、Kubeflow、Airflow、KServe、CI/CD | | AI Infra / GPU | 管理 GPU 服务器、算力集群和高性能推理 | 高 | CUDA、GPU Operator、vLLM、Triton、NCCL、RDMA | | AIOps | 用 AI 提升传统运维效率 | 高 | 告警降噪、根因分析、RAG、Agent、时序预测 | ### 3. 招聘要求中出现频率最高的能力 | 能力 | 出现频率判断 | 你要达到的面试水平 | |---|---|---| | Linux、网络、Shell | 几乎所有岗位 | 能独立排查 CPU、内存、磁盘、端口、进程、DNS、HTTP 问题 | | Python | 很高 | 能写自动化脚本、调用 API、处理日志、做简单后端服务 | | Docker、Kubernetes | 很高 | 能部署、扩缩容、看日志、排查 Pod、理解 Service/Ingress | | 监控与日志 | 很高 | 能用 Prometheus/Grafana/ELK 建立指标、日志和告警闭环 | | 云平台 | 高 | 至少熟悉一家云平台的计算、网络、存储、K8s 和权限 | | CI/CD、Ansible/Terraform | 高 | 能把代码或模型从提交自动发布到测试、生产 | | 模型服务 | 高 | 理解 vLLM/Triton/KServe 等推理服务以及延迟、吞吐、显存 | | GPU 基础 | 中高 | 理解显存、CUDA、GPU 利用率、驱动和资源调度 | | MLflow/Kubeflow | 中高 | 理解模型生命周期，不一定一开始就精通全部组件 | | RAG、Agent、MCP | 中高，偏高级 | 能解释原理、权限风险和适合的运维场景 | | Spark/Flink/Kafka | 加分项 | 面向大数据、实时特征和数据管道岗位时重点准备 | ### 4. 不同招聘平台观察到的侧重点 | 平台 | 岗位样本体现的侧重点 | |---|---| | BOSS 直聘 | 岗位类型多，从初级平台运维到 GPU 调度、智能运维都有；实际动手和快速交付很重要 | | 猎聘 | 中高级岗位较多，重视生产级 MLOps、架构设计、GPU 资源利用率、成本和治理 | | 智联招聘 | AI 产品部署、客户交付、Linux/K8s、网络、中间件和脚本能力较常见 | ### 5. 你应该如何解读招聘 JD 不要看到一长串技术名词就全部同时学习。先把 JD 拆成三类： 1. **硬门槛**：Linux、Python/Shell、Docker、K8s、监控、故障排查。 2. **岗位专项**：MLOps 关注 MLflow/Kubeflow；GPU 岗位关注 CUDA/vLLM；AIOps 关注告警、RAG、Agent。 3. **加分项**：Terraform、Go、Spark/Flink、英文文档、云认证、GPU 成本优化。 --- ## 三、AI 运维全景图：一层一层看 ```text 业务层：聊天、推荐、视觉、Agent | v 模型服务层：vLLM、Triton、KServe、API 网关 | v MLOps 层：训练流水线、实验管理、模型仓库、评测 | v 平台层：Kubernetes、Docker、CI/CD、服务发现 | v 基础设施层：Linux、CPU、GPU、存储、网络、云平台 横向能力：监控、日志、告警、安全、成本、备份、应急 （横向覆盖上面所有层） ``` ### 用一个问题检查你是否真的理解 假设用户访问一个聊天机器人，发生了一次请求： ```text 用户请求 -> API 网关鉴权、限流 -> Kubernetes 找到推理服务 -> vLLM 把请求放进队列 -> GPU 加载模型并生成 Token -> 返回结果 -> Prometheus 记录延迟、错误率、Token 数 -> 日志系统记录请求链路和错误 ``` 如果请求变慢，AI 运维不能只说“服务器有问题”，而要逐层定位： ```text 是网络慢？网关排队？Pod 重启？CPU 满？GPU 显存不足？ 模型太大？并发太高？KV Cache 不够？下游数据库慢？ ``` --- ## 四、必须掌握的技术知识 ### 4.1 Linux：AI 运维的地基 **通俗理解：** Linux 就像一栋楼的物业系统。你必须知道电梯、供水、门禁和消防分别出了什么问题。 #### 必学内容 | 主题 | 要会什么 | 常见命令 | |---|---|---| | 进程 | 查进程、杀进程、找父子关系、看启动参数 | `ps`、`top`、`htop`、`kill`、`systemctl` | | CPU | 看负载、单核是否满、进程是否消耗过高 | `uptime`、`top`、`mpstat` | | 内存 | 区分物理内存、缓存、Swap、OOM | `free`、`vmstat`、`dmesg` | | 磁盘 | 看空间和 inode，找大文件，观察 IO | `df`、`du`、`iostat`、`find` | | 网络 | 看端口、连接、路由、DNS、HTTP 状态 | `ss`、`curl`、`ping`、`traceroute`、`dig` | | 日志 | 定位时间点、关键词、异常堆栈 | `journalctl`、`grep`、`awk`、`tail` | | 权限 | 用户、组、文件权限、sudo、密钥 | `chmod`、`chown`、`id`、`ssh` | #### 面试要能说出的排查顺序 ```text 确认影响范围 -> 确认发生时间 -> 看服务是否存活 -> 看 CPU / 内存 / 磁盘 / 网络 -> 看应用日志和系统日志 -> 对比最近变更 -> 临时恢复 -> 找根因并复盘 ``` #### 最小练习 下面以 Ubuntu 为例给出一套参考答案。CentOS/RHEL 可以把 `apt` 命令替换为对应的 `dnf` 命令。 **1. 部署 Nginx 并验证访问：** ```bash sudo apt update sudo apt install -y nginx sudo systemctl enable --now nginx curl -I http://127.0.0.1 ss -lntp | grep ':80' ``` **预期结果：** `curl` 返回 `HTTP/1.1 200 OK` 或 `HTTP/2 200`，`ss` 能看到 Nginx 监听 `0.0.0.0:80` 或 `[::]:80`。 **2. 停止服务并从日志定位故障：** ```bash sudo systemctl stop nginx curl -I --max-time 3 http://127.0.0.1 sudo systemctl status nginx --no-pager sudo journalctl -u nginx -n 30 --no-pager ``` **预期结果：** `curl` 连接失败，`systemctl status` 显示服务已停止；排查时先确认服务状态，再查看对应服务日志，而不是直接重启服务器。恢复命令是 `sudo systemctl start nginx`。 **3. 编写磁盘使用率告警脚本：** ```bash #!/usr/bin/env bash set -euo pipefail threshold=80 usage=$(df -P / | awk 'NR == 2 {gsub("%", "", $5); print $5}') if [ "$usage" -ge "$threshold" ]; then echo "告警：根目录使用率为 ${usage}%" else echo "正常：根目录使用率为 ${usage}%" fi ``` 保存为 `check_disk.sh` 后执行： ```bash chmod +x check_disk.sh ./check_disk.sh ``` **预期结果：** 使用率低于 80% 时输出“正常”，达到或超过 80% 时输出“告警”。面试时要说明：真实生产脚本还应接入监控系统，而不是只打印到终端。 --- ### 4.2 网络：先学会“请求为什么到不了” **通俗理解：** 网络像快递系统：DNS 是查地址，IP 是门牌号，端口是房间号，HTTP 是快递单格式，防火墙是门卫。 ```text 域名 -> DNS 解析 -> IP 地址 -> 路由 -> 防火墙 -> 端口 -> 服务 -> HTTP 响应 ``` #### 必须理解 - TCP 三次握手和连接建立失败的表现。 - DNS 解析失败、解析到错误 IP、缓存未更新。 - HTTP 常见状态码：`200` 成功、`301/302` 跳转、`400` 请求错误、`401/403` 鉴权或权限、`404` 资源不存在、`429` 限流、`500/502/503/504` 服务端或网关问题。 - Nginx 反向代理、负载均衡、超时和连接数。 - 防火墙、安全组、VPC、内网和公网的区别。 #### 常见排查例子 ```bash curl -v http://example.com/health ss -lntp dig example.com ping ``` 注意：`ping` 通不代表 HTTP 一定正常，很多环境会禁 ICMP；`curl` 能返回也不代表业务一定健康，最好设计 `/healthz` 和 `/readyz`。 --- ### 4.3 Python、Shell 和 Go：运维要“能写工具” 入门阶段不要求你成为算法专家，但要能把重复工作自动化。 #### Python 重点 - 文件、JSON、YAML、CSV 处理。 - `requests` 或 `httpx` 调 API。 - 日志解析、正则、异常处理。 - `subprocess` 调用系统命令，但要避免拼接不可信输入。 - FastAPI 基础：写健康检查、接收任务、返回结果。 - 虚拟环境、依赖锁定、测试和打包。 #### 一个合格的自动化脚本应当有 ```text 参数校验 + 超时 + 重试上限 + 结构化日志 + 明确退出码 + 幂等性 ``` **幂等性是什么意思？** 同一个发布命令执行一次和执行三次，最终结果应该一致，而不是重复创建三套资源。 #### Shell 重点 脚本要注意： ```bash set -euo pipefail ``` 并为关键操作添加日志、确认和回滚，不要直接写“删除所有文件”之类的高风险命令。 #### Go 是否必须 多数入门岗位不是必须，但云原生、Kubernetes 控制器、基础设施平台岗位经常偏好 Go。先把 Python 学扎实，再根据目标岗位补 Go。 --- ### 4.4 Docker：把应用装进标准集装箱 **通俗理解：** Docker 镜像像一份标准化集装箱，里面放应用、依赖和启动方式；容器是这个集装箱正在运行的实例。 ```text 代码、依赖、配置 | v Dockerfile | v 镜像 Image | v 容器 Container | v 端口、日志、存储、网络 ``` #### 面试重点与参考答案 **1. 什么是镜像层、容器生命周期和镜像仓库？** **参考答案：** Docker 镜像由多层只读文件层组成，每一层通常对应一次构建变化；容器启动后会在镜像上增加一个可写层。容器常见生命周期是创建、启动、运行、停止、删除。镜像仓库用于保存和分发镜像，例如拉取、推送和管理版本。生产环境不应只依赖 `latest` 标签，最好使用明确版本号或镜像摘要，保证发布可追溯。 **2. `CMD` 和 `ENTRYPOINT` 有什么区别？** **参考答案：** 两者都用于定义容器启动时执行的内容。`ENTRYPOINT` 更像固定的主程序，`CMD` 更像默认命令或默认参数；运行容器时传入的新参数通常会覆盖 `CMD`，而不会直接替换 `ENTRYPOINT`。例如可以用 `ENTRYPOINT ["python"]` 固定解释器，再用 `CMD ["app.py"]` 提供默认脚本。生产环境推荐使用 JSON 数组形式，避免额外的 Shell 进程和信号处理问题。 **3. 环境变量、Secret、Volume 和端口映射分别解决什么问题？** **参考答案：** 环境变量用于传入普通配置，例如运行环境和服务地址；Secret 用于保存密码、令牌等敏感信息，但仍应配合权限控制和密钥轮换；Volume 把数据放到容器外部，避免容器删除后数据丢失；端口映射把宿主机端口转发到容器端口，例如 `-p 8080:80` 表示访问宿主机 8080 端口时转到容器 80 端口。 **4. 为什么容器内的主进程最好以前台方式运行？** **参考答案：** 容器通常把主进程作为 PID 1。以前台方式运行时，Docker 能直接观察它的退出状态、采集标准输出日志，并在进程退出后按策略重启；如果程序在后台运行，容器的前台进程可能很快结束，导致容器退出，而且信号转发和优雅停止也更难处理。 **5. 为什么镜像要尽量小？** **参考答案：** 镜像越小，构建、上传、下载和启动越快，部署失败时的影响范围也越小；同时可以减少不必要的软件包和漏洞，降低攻击面。常见做法是使用多阶段构建、精简基础镜像、删除缓存和临时文件，并配置 `.dockerignore`。但不能为了体积盲目删掉运行时依赖，必须在构建后启动并做健康检查验证。 **6. GPU 容器为什么需要 NVIDIA Container Toolkit 和正确的驱动？** **参考答案：** GPU 驱动通常安装在宿主机上，负责和硬件通信；容器内的 AI 程序需要通过 NVIDIA Container Toolkit 访问宿主机 GPU，并获得所需的设备和运行库。驱动、CUDA、框架和模型环境之间还要版本兼容。Toolkit 只能解决容器访问 GPU 的问题，不能替代宿主机驱动；排查时可检查 `nvidia-smi`、容器运行参数和框架是否识别到 GPU。 #### 最小实践 下面给出完整参考实现。先在同一个目录创建 `app.py`、`requirements.txt` 和 `Dockerfile`。 `app.py`： ```python from fastapi import FastAPI app = FastAPI() @app.get("/healthz") def healthz(): return {"status": "ok"} ``` `requirements.txt`： ```text fastapi uvicorn[standard] ``` `Dockerfile`： ```dockerfile FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 8000 CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"] ``` 构建、启动和验证： ```bash docker build -t fastapi-health:1.0 . docker run --rm --name fastapi-health -p 8080:8000 fastapi-health:1.0 ``` 另开一个终端执行： ```text curl http://127.0.0.1:8080/healthz 返回：{"status":"ok"} ``` **面试答案：** 这个练习验证了四件事：Dockerfile 能构建镜像，容器能以前台方式启动，宿主机端口 8080 能映射到容器 8000，健康检查接口能返回 200 和 JSON。排查时可以依次执行 `docker ps`、`docker logs fastapi-health` 和 `docker inspect fastapi-health`。 --- ### 4.5 Kubernetes：让很多容器自动运行 **通俗理解：** Docker 是一辆车，Kubernetes 是车队调度中心。它会决定哪辆车去哪、坏了补哪辆、流量怎么分。 ```text Deployment：要运行几个副本、用哪个镜像 Pod：最小运行单元 Service：给一组 Pod 一个稳定的访问入口 Ingress：把外部 HTTP 请求路由进来 ConfigMap/Secret：配置和敏感信息 PVC：持久化存储 Job/CronJob：一次性任务/定时任务 ``` #### 必须能做的操作 ```bash kubectl get pods -A kubectl describe pod kubectl logs --previous kubectl get events --sort-by=.lastTimestamp kubectl rollout status deployment/ kubectl rollout undo deployment/ kubectl top pod ``` #### Pod 启动失败的排查图 ```text Pod 不正常 | +-- Pending ------------> 看资源、节点、污点、调度事件 +-- ImagePullBackOff ---> 看镜像名、仓库权限、网络 +-- CrashLoopBackOff ---> 看日志、环境变量、启动命令 +-- OOMKilled ----------> 看内存限制、内存泄漏、请求峰值 +-- Running 但访问失败 -> 看 Service、端口、探针、Ingress ``` #### AI 场景新增的 Kubernetes 知识 - GPU 节点标签、污点和容忍度。 - `nvidia.com/gpu` 资源请求。 - GPU Operator 的作用。 - 节点亲和性、拓扑分布和多副本。 - 训练任务和推理服务对资源的不同需求。 - HPA、队列和扩缩容不能只看 CPU，还要看请求数、队列长度、GPU 利用率和延迟。 --- ### 4.6 监控、日志和可观测性：让系统“可解释” **监控不是装一个 Grafana 就结束。** 关键是发生故障时，你能回答：哪里坏了、影响多少、为什么坏、是否恢复。 ```text 应用、K8s、GPU、数据库 | +--> 指标 Metrics ------> Prometheus -----+ | | +--> 日志 Logs ----------> ELK / Loki -----+--> Grafana / Alertmanager | | | +--> 链路 Traces --------> Jaeger / Tempo-+ v 值班、工单、自动化处理 ``` #### AI 服务至少监控这些指标 | 类别 | 典型指标 | 说明 | |---|---|---| | 可用性 | 请求成功率、5xx、健康检查 | 服务能不能用 | | 性能 | P50/P95/P99 延迟、吞吐量 | 不能只看平均值 | | 模型 | Token 输入/输出、上下文长度、生成速度 | 判断体验和成本 | | 资源 | CPU、内存、GPU 利用率、显存、温度 | 判断资源瓶颈 | | 队列 | 等待请求数、排队时间、任务失败数 | 判断拥塞 | | 质量 | 评测分数、拒答率、幻觉率、数据漂移 | 判断模型是否变差 | | 成本 | 每请求成本、每用户成本、GPU 空闲时间 | 判断是否值得扩容 | #### 告警的好坏 坏告警：每次 CPU 80% 都报警，结果一天几百条消息。 好告警： ```text 推理 P95 延迟连续 5 分钟超过目标值，且错误率上升； 附带服务、版本、节点、最近变更和排查链接。 ``` 告警必须有负责人、等级、响应时间和处理手册，否则只是噪声。 --- ### 4.7 CI/CD 和 IaC：把发布变成流水线 **通俗理解：** 不要每次发布都登录服务器手工复制文件。流水线像工厂传送带，自动完成检查、打包、测试、发布和回滚。 ```text 提交代码、配置、模型 | v 静态检查 -> 单元测试与镜像构建 -> 安全扫描 | v 测试环境部署 -> 接口 / 模型评测 -> 灰度或金丝雀 | v 生产发布 -> 监控 -> 必要时自动回滚 ``` #### 要理解的工具分工 | 工具 | 解决什么问题 | |---|---| | Jenkins / GitLab CI / GitHub Actions | 触发和执行流水线 | | Ansible | 批量配置服务器、执行相对简单的操作 | | Terraform | 用代码声明云资源和基础设施 | | Argo CD | 常见的 Kubernetes GitOps 持续交付工具 | | MLflow | 实验、模型版本和模型生命周期管理 | | Kubeflow / Airflow | 训练或数据工作流编排 | #### AI 发布为什么比普通服务复杂 普通服务主要发布代码；AI 服务还要同时管理： ```text 代码版本 + 数据版本 + 模型版本 + Prompt 版本 + 配置版本 + 评测结果 ``` 只记录“模型 v3”是不够的，还要知道它用什么数据、什么代码、什么参数训练，以及为什么允许上线。 --- ### 4.8 MLOps：管理模型的完整生命周期 ```text 数据准备 -> 训练实验 -> 评测与审核 -> 模型注册 -> 部署服务 -> 线上监控 | +--------------------+--------------------+ | | 质量和数据正常 质量或数据发生变化 | | +----------继续监控----------> 回滚、重训或调整 ``` #### 你至少要讲清楚四个概念 1. **实验追踪**：记录参数、指标、代码和产物，方便复现。 2. **模型注册**：统一管理模型版本、来源、标签和审批状态。 3. **模型部署**：把模型包装成在线服务或批处理任务。 4. **模型监控**：看服务指标，也看模型质量、输入分布和数据漂移。 MLflow 官方文档将模型注册表定位为集中管理模型生命周期的存储、API 和 UI，强调版本、血缘、别名和标签。面试时可以说：生产环境不应只保存一个模型文件，而应能追溯“哪个训练任务生成了它、当前线上使用哪一版、怎样回滚”。 --- ### 4.9 大模型推理和 GPU：AI 运维的专项核心 **训练**像培养厨师：成本高、时间长、批处理明显。 **推理**像餐厅接单：请求不断到来，更关注延迟、并发、吞吐、显存和稳定性。 #### 必须理解的词 | 词 | 通俗解释 | |---|---| | 显存 | GPU 的工作台，模型和中间数据要放进去 | | CUDA | 让程序使用 NVIDIA GPU 的软件平台 | | GPU 利用率 | GPU 计算单元忙不忙，不等于显存是否够 | | KV Cache | 保存对话中间结果，减少重复计算，但会占显存 | | Batch | 把多个请求一起处理，提高吞吐，但可能增加等待时间 | | 量化 | 用更少的位数表示参数，节省显存，可能影响质量 | | vLLM | 常用的大模型推理服务框架，支持 OpenAI 兼容接口 | | Triton | NVIDIA 推理服务平台，适合多种模型和高性能服务 | | GPU Operator | 在 Kubernetes 中帮助管理 GPU 驱动、插件和运行环境 | | DCGM | NVIDIA 数据中心 GPU 的监控能力，常与 Prometheus 配合 | #### vLLM 服务的基本链路 ```text 客户端 -> OpenAI 兼容 API -> vLLM 调度请求 -> KV Cache -> GPU 计算 -> 流式返回 Token ``` vLLM 官方文档说明它可以提供兼容 OpenAI Completions、Chat Completions 等接口。因此面试时可以强调：客户端不一定需要改造，只要把 `base_url` 指向内部 vLLM 服务，同时补好鉴权、限流、监控和版本管理。 #### 推理变慢时的排查思路 ```text 先区分：首 Token 慢，还是后续 Token 慢？ -> 看请求是否排队 -> 看输入上下文是否变长 -> 看 GPU 显存和 KV Cache -> 看 GPU 利用率是否低或被其他任务争抢 -> 看副本数、批处理、并发和限流 -> 对比模型版本、量化方式和最近配置变更 ``` 不要只盯着 GPU 利用率：GPU 100% 不一定是坏事，GPU 10% 也不一定正常，关键要和延迟、吞吐、队列、显存一起看。 --- ### 4.10 AIOps：用 AI 帮运维，而不是把所有东西都叫 AI AIOps 常见场景： - 告警去重和降噪。 - 多指标、日志、拓扑关联。 - 异常检测和动态阈值。 - 故障根因分析。 - 运维知识库问答（RAG）。 - 低风险动作自动执行（Agent）。 - 容量预测和资源规划。 #### RAG 运维知识库图解 ```text 故障手册、日志、变更记录 | v 清洗和分片 -> 向量化 -> 向量库、关键词索引 ^ | 工程师问题 ----------------> 混合检索 | v 重排和权限过滤 | v 大模型生成答案 | v 引用来源、风险提示、处理建议 ``` **RAG 不是把文档丢给大模型。** 生产环境还要处理文档版本、权限、过期内容、检索质量、引用证据和敏感信息。 #### Agent 自动执行的安全边界 ```text 只读查询 -> 低风险动作 -> 需要审批的动作 -> 禁止自动执行的动作 ``` 例如： - 允许自动执行：查询 Pod、查看磁盘、生成诊断报告。 - 需要审批：重启服务、扩容、切换流量。 - 禁止大模型直接执行：删除生产库、批量删文件、关闭安全策略。 --- ## 五、学习优先级：不要一开始同时学 30 个工具 ### 目标 A：争取初级 AI 平台运维 / AI 产品运维 ```text Linux + 网络 + Shell/Python -> Docker -> Kubernetes 基础 -> Prometheus/Grafana/日志 -> 一个云平台 -> 部署一个 AI 应用 ``` ### 目标 B：争取 MLOps 岗位 ```text 目标 A 全部内容 -> GitLab CI/Jenkins -> MLflow -> 训练/推理流水线 -> 模型注册、灰度、回滚 -> 数据质量和模型漂移 ``` ### 目标 C：争取 AI Infra / GPU 岗位 ```text 目标 A 全部内容 -> GPU、CUDA、显存、驱动 -> vLLM/Triton -> Kubernetes GPU 调度 -> DCGM/Prometheus -> 多机通信、NCCL、RDMA ``` ### 目标 D：争取 AIOps / 智能运维岗位 ```text 传统运维故障排查能力 -> 指标、日志、拓扑数据 -> 异常检测和告警治理 -> RAG 知识库 -> Agent 工具调用和权限控制 ``` ### 12 周建议计划 | 周数 | 学习目标 | 可交付成果 | |---:|---|---| | 1-2 | Linux、网络、Shell | 故障排查笔记 + 磁盘告警脚本 | | 3 | Python 自动化 | 日志分析脚本 + API 调用脚本 | | 4 | Docker | 容器化一个 FastAPI 服务 | | 5-6 | Kubernetes | 部署、扩容、滚动更新、回滚 | | 7 | Prometheus/Grafana/日志 | 服务仪表盘和三条有效告警 | | 8 | CI/CD | 提交代码自动构建镜像并部署测试环境 | | 9 | 云平台 | 完成一套云服务器、网络和权限实践 | | 10 | AI 部署 | 部署 Ollama 或 vLLM，提供聊天接口 | | 11 | GPU/模型服务 | 记录延迟、吞吐、显存、错误率 | | 12 | 面试项目 | 写项目 README、架构图、故障复盘和演示视频 | --- ## 六、最值得准备的实战项目 ### 项目：小型大模型服务平台 #### 项目目标 在一台 Linux 机器或云服务器上完成： ```text 模型服务 + API 网关 + Docker + Kubernetes + 监控 + 日志 + 自动发布 ``` #### 建议组件 | 模块 | 入门选型 | |---|---| | 模型 | 小型开源模型或 Ollama | | 推理 | vLLM（有 GPU 时）或 Ollama | | API | FastAPI | | 容器 | Docker | | 编排 | Kubernetes / Minikube / kind | | 监控 | Prometheus + Grafana | | 日志 | Loki 或 ELK，先选一个 | | 发布 | GitLab CI 或 GitHub Actions | | 配置 | ConfigMap + Secret | #### 必须能演示的故障 1. 修改镜像版本，滚动发布。 2. 故意发布错误版本，使用回滚恢复。 3. 让一个 Pod 退出，展示 Kubernetes 自愈。 4. 修改资源限制，观察 OOMKilled 如何定位。 5. 让请求变多，观察延迟和队列。 6. 关闭依赖服务，展示告警和排查路径。 #### 故障演示参考答案 | 演示 | 操作示例 | 预期现象和答案 | |---|---|---| | 滚动发布 | 修改 Deployment 的镜像标签，执行 `kubectl apply -f deployment.yaml` | 新旧 Pod 短时间并存，`kubectl rollout status` 显示逐步完成，服务不中断 | | 错误版本回滚 | 发布不存在的镜像标签，执行 `kubectl rollout status` | 新 Pod 进入 `ImagePullBackOff`，执行 `kubectl rollout undo deployment/` 恢复上一版本 | | Pod 自愈 | 执行 `kubectl delete pod ` | Deployment 发现实际副本数少于期望值，自动创建新的 Pod | | OOM 排查 | 把容器内存限制调得过小，再发送较大请求 | Pod 显示 `OOMKilled`，通过 `kubectl describe pod` 和 `kubectl logs --previous` 确认原因，再调整限制或降低并发 | | 延迟上升 | 使用压测工具增加并发请求 | 队列、P95 延迟或错误率上升；结合 CPU、内存、GPU 和副本数判断是资源不足还是应用瓶颈 | | 依赖故障 | 暂停 Redis、数据库或下游 API | 应用出现超时或错误告警；通过应用日志和链路追踪定位依赖，再恢复依赖或启用降级方案 | **面试回答模板：** 我不会只展示“故障发生了”，还会说明告警证据、影响范围、临时恢复动作、根因和预防措施。例如错误镜像导致新 Pod 拉取失败，我会先停止继续发布，再回滚到上一版本，确认服务恢复后修正镜像地址，并在流水线中加入镜像存在性检查。 #### 面试时的项目描述模板 ```text 我做了一个容器化的大模型服务平台，目标是把手工部署变成可重复发布。 我用 Docker 封装推理服务，用 Kubernetes 管理副本和滚动更新， 用 Prometheus 采集请求量、错误率、P95 延迟和资源指标， 用 Grafana 做看板，并通过 CI 流水线完成镜像构建和测试环境发布。 我还模拟了 OOM、错误版本和 Pod 异常退出，验证了告警、回滚和自愈流程。 ``` 讲项目时一定补充真实结果，例如：发布从 30 分钟缩短到 5 分钟、故障定位从 1 小时缩短到 15 分钟。没有真实数据时不要编造，可以说“在实验环境测得”。 --- ## 七、面试题与参考答案 ### A. 基础运维题 #### 1. Linux 服务器负载很高，你怎么排查？ **参考答案：** 先确认影响范围和开始时间，再用 `uptime`、`top` 或 `htop` 区分 CPU、内存和 IO。查看进程、线程和最近变更；内存问题检查 `free`、Swap 和 `dmesg` 是否 OOM；磁盘问题检查 `df`、`du`、`iostat`；如果是服务变慢，再看应用日志、数据库和网络。临时恢复后要保留现场，最后输出根因、影响、修复和预防措施。 **面试加分点：** 不要只回答“重启服务器”，要先判断并保留证据。 #### 2. `502`、`503`、`504` 有什么区别？ **参考答案：** - `502 Bad Gateway`：网关从上游收到无效响应，常见于上游服务挂了、协议或连接异常。 - `503 Service Unavailable`：服务当前不可用，可能是没有健康实例、过载或主动维护。 - `504 Gateway Timeout`：网关等待上游超时，可能是上游处理太慢、网络不通或超时时间配置不合理。 我会结合 Nginx 日志、上游服务日志、连接数、响应时间和 Kubernetes Endpoints 一起判断。 #### 3. 为什么 `ping` 通，但服务访问不了？ **参考答案：** `ping` 主要验证 ICMP，不验证目标端口和应用协议。可能是服务没有监听、监听在错误地址、端口被防火墙拦截、TLS 或 HTTP 配置错误，也可能应用本身返回 4xx/5xx。我会使用 `ss`、`curl -v`、安全组和 Nginx 日志逐层确认。 #### 4. 什么是幂等？运维为什么需要幂等？ **参考答案：** 同一个操作执行一次或多次，最终结果一致，就叫幂等。例如“确保某个 Deployment 副本数为 3”通常是幂等的，而“每次执行都创建一个新资源”不是。自动化发布、重试和故障恢复都可能重复执行，所以脚本必须设计幂等，否则会重复创建资源或重复执行危险动作。 --- ### B. Docker 和 Kubernetes 题 #### 5. Docker 容器和虚拟机有什么区别？ **参考答案：** 虚拟机通常包含完整的客户机操作系统，隔离更强但开销更大；容器共享宿主机内核，把应用和依赖打包在一起，启动更快、密度更高，但隔离边界与虚拟机不同。生产环境中常用容器快速交付应用，但仍然要关注权限、镜像漏洞和运行时安全。 #### 6. Pod 处于 `CrashLoopBackOff` 怎么办？ **参考答案：** 先看 `kubectl get pod`、`kubectl describe pod` 和 `kubectl logs --previous`，确认容器上一次为什么退出。重点检查启动命令、环境变量、Secret、配置文件、依赖服务、端口和探针。如果是 OOMKilled，检查资源限制和内存使用；如果是应用启动太慢，调整探针而不是盲目增加重启次数。修复后做滚动发布并验证恢复。 #### 7. Deployment、Service、Ingress 分别做什么？ **参考答案：** Deployment 管理 Pod 的期望状态、版本和副本；Service 为一组 Pod 提供稳定的虚拟访问地址和负载分发；Ingress 根据域名和路径把外部 HTTP/HTTPS 请求路由到 Service。它们分别解决“怎么运行、怎么找到、怎么从外部访问”。 #### 8. Kubernetes 中如何让 Pod 使用 GPU？ **参考答案：** 节点先安装匹配的 GPU 驱动和容器运行时，再通过 NVIDIA 相关插件或 GPU Operator 把 GPU 资源暴露给 Kubernetes。工作负载在资源请求中声明类似 `nvidia.com/gpu: 1`，并结合节点标签、污点和容忍度把任务调度到合适节点。还要监控显存、利用率、温度、掉卡和任务失败情况。 --- ### C. 监控与故障排查题 #### 9. 你会给大模型推理服务监控什么？ **参考答案：** 我会分四层： 1. 可用性：成功率、错误率、健康检查、Pod 重启。 2. 性能：P50/P95/P99 延迟、首 Token 延迟、生成速度、吞吐量、排队时间。 3. 资源：GPU 利用率、显存、温度、CPU、内存、网络和磁盘。 4. 业务与成本：输入输出 Token、模型版本、调用方、每请求成本、限流次数。 同时采集日志和 trace，确保指标能跳转到具体请求和版本。 #### 10. 平均延迟正常，但用户仍说偶尔很慢，怎么办？ **参考答案：** 平均值会掩盖长尾，所以先看 P95/P99 和首 Token 延迟，再按模型、节点、用户、输入长度、时间段和版本切分。检查是否有突发排队、GPU 显存不足、冷启动、下游依赖超时或单个坏节点。最后用 trace 关联网关、调度、推理和依赖服务的耗时。 #### 11. 怎样避免告警风暴？ **参考答案：** 先按服务、集群、拓扑和时间窗口聚合，再做去重、抑制、分级和维护窗口；为告警增加版本、节点、负责人和处理手册。根因告警优先，派生告警降级。上线后用告警数量、有效告警率、平均响应时间和重复告警率评估效果。 --- ### D. MLOps 和模型题 #### 12. DevOps 和 MLOps 的主要区别是什么？ **参考答案：** DevOps 主要管理代码到服务的交付；MLOps 除了代码，还要管理数据、特征、模型、评测和线上漂移。模型可能“服务正常但效果变差”，因此 MLOps 需要版本血缘、模型质量监控、数据质量检查和重新训练流程。 #### 13. 为什么模型上线必须做版本管理？ **参考答案：** 因为模型文件、训练代码、数据、参数和配置都会影响结果。版本管理可以回答“线上正在运行哪一版、它由什么数据训练、谁批准的、如何回滚”。生产发布应采用不可变版本或明确别名，不能直接覆盖一个名为 `latest` 的文件。 #### 14. 什么是模型漂移？如何处理？ **参考答案：** 模型漂移通常指线上输入数据分布、特征关系或目标规律发生变化，使模型效果下降。可以监控输入分布、缺失率、特征统计和业务效果指标；达到阈值后先确认是否数据管道或埋点异常，再决定回滚、重新训练、调整阈值或人工审核。 #### 15. 灰度发布和蓝绿发布有什么区别？ **参考答案：** 蓝绿发布准备两套环境，在新环境验证后切换全部流量，回滚快但资源成本高；灰度发布让少量流量逐步进入新版本，根据错误率、延迟和质量指标扩大或停止流量，更适合模型服务，但需要可靠的流量分配和对比评测。 --- ### E. 大模型、RAG 和 Agent 题 #### 16. vLLM、Triton 是做什么的？ **参考答案：** 它们都可以帮助把模型做成高性能推理服务。vLLM 常用于大语言模型在线服务，提供兼容 OpenAI 风格的 HTTP 接口并优化请求调度和 KV Cache；Triton 是更通用的推理服务平台，可服务多种模型类型并提供并发、批处理和模型管理能力。选择时要结合模型类型、硬件、吞吐、延迟和团队维护成本。 #### 17. RAG 仍然答错，运维角度怎么排查？ **参考答案：** 按链路拆分：文档是否过期或权限错误；切分是否破坏上下文；向量模型是否合适；召回数量和混合检索是否合理；重排是否有效；Prompt 是否要求引用证据；模型是否把不确定内容当成事实。建立离线评测集，分别记录召回命中率、答案正确性、引用完整性和延迟，不要只凭主观感觉调参数。 #### 18. 为什么不能让 Agent 直接执行任意 Shell？ **参考答案：** 大模型输出不稳定，可能理解错上下文或被提示注入；任意 Shell 还可能导致数据删除、权限提升和横向移动。应该采用工具白名单、参数校验、最小权限、只读优先、审批确认、超时、审计和回滚。高风险动作必须由人确认，模型只负责提出建议或生成待执行计划。 --- ### F. 场景设计题 #### 19. 设计一个高可用的大模型推理服务 **参考答案结构：** ```text 入口：API 网关，负责鉴权、限流、配额和请求日志 服务：多个推理副本，按模型版本和 GPU 节点分组 调度：Kubernetes，配置探针、反亲和、自动扩缩容 模型：模型仓库和不可变版本，支持灰度和回滚 依赖：对象存储、Redis/队列、配置和密钥管理 观测：指标、日志、trace、GPU 监控、业务质量监控 容灾：跨节点部署、备份、降级模型、故障转移 安全：网络隔离、最小权限、密钥轮换、敏感数据脱敏 ``` 重点不是把组件说得越多越好，而是说明每个组件解决什么风险，以及怎么验证它真的生效。 #### 20. 线上推理服务突然错误率升高，你怎么处理？ **参考答案：** 先确认监控是否真实、影响范围和开始时间；按版本、节点、模型和调用方切分错误。查看最近发布、配置和流量变化，检查 Pod、GPU、显存、网关、依赖服务和日志。若是新版本导致，暂停灰度或回滚；若是资源不足，限流、扩容或切换降级模型；恢复后补充根因分析和预防措施。整个过程要持续同步影响范围、当前措施和下一步。 --- ## 八、面试回答方法：不要只背定义 推荐使用 **STAR + 技术闭环**： ```text S：当时是什么系统、什么背景 T：你的目标和约束是什么 A：你具体做了哪些排查、设计和操作 R：结果是什么，有什么数据证明 复盘：如果再做一次，你会怎么改进 ``` 例如不要说： > 我会使用 Kubernetes 和 Prometheus。 改成： > 我在测试环境把推理服务部署为 3 个 Pod，使用 Service 暴露内部访问，Prometheus 采集请求成功率、P95 延迟、Pod 重启和 GPU 利用率。一次故意把内存限制调小，触发 OOMKilled，再通过事件和上一次容器日志定位并回滚。这个练习让我验证了从告警到恢复的闭环。 --- ## 九、面试前检查清单 ### 技术检查 - [ ] 能独立解释 Linux CPU、内存、磁盘、网络排查流程。 - [ ] 能用 Docker 启动、查看、停止和排查容器。 - [ ] 能解释 Pod、Deployment、Service、Ingress、ConfigMap、Secret。 - [ ] 能排查 `Pending`、`ImagePullBackOff`、`CrashLoopBackOff`、`OOMKilled`。 - [ ] 能说出推理服务的 P95 延迟、首 Token 延迟、吞吐、显存和队列指标。 - [ ] 理解模型版本、数据版本、灰度、回滚和漂移。 - [ ] 能解释 RAG 的检索链路和 Agent 的安全边界。 - [ ] 有一个能展示的项目，包含架构图、部署文件、监控截图和故障复盘。 ### 表达检查 - [ ] 每个项目都能在 1 分钟讲清楚目标、架构、你的工作和结果。 - [ ] 不会的工具能诚实区分“用过、看过、理解原理、没有生产经验”。 - [ ] 遇到故障题先说影响范围、证据和恢复，再说优化。 - [ ] 不把“重启”当成完整解决方案。 - [ ] 能说明安全、成本、可观测性和回滚，而不只谈功能。 --- ## 十、招聘信息与学习资料来源 ### 招聘平台样本 1. [BOSS 直聘：人工智能运维工程师招聘信息页](https://www.zhipin.com/zhaopin/658fa1b567e50f900HN_3t2_/) 2. [BOSS 直聘：人工智能平台运维招聘信息页](https://m.zhipin.com/zhaopin/bc799cf7dada9d091n1_3di_GA~~/) 3. [猎聘：云运维工程师 MLOps Engineer](https://www.liepin.com/job/1984603423.shtml) 4. [猎聘：AI 运维工程师（AI Infra / 大模型方向）](https://www.liepin.com/job/1984515097.shtml) 5. [猎聘：MLOps 运维工程师](https://www.liepin.com/job/1983651823.shtml) 6. [智联招聘：AI 开发运维工程师](https://www.zhaopin.com/jobdetail/CC157334420J40776084006.htm) 7. [智联招聘：大模型产品运维工程师](https://www.zhaopin.com/jobdetail/CC000544460J40795065516.htm) ### 官方技术文档 1. [Kubernetes 官方文档：Overview](https://kubernetes.io/docs/concepts/overview/) 2. [MLflow 官方文档：Model Registry](https://mlflow.org/docs/latest/ml/model-registry/) 3. [vLLM 官方文档：OpenAI-Compatible Server](https://docs.vllm.ai/en/latest/serving/online_serving/openai_compatible_server/) > 来源说明：招聘平台信息用于观察岗位关键词和职责趋势，不等于完整统计报告；职位内容、薪资、地点和要求可能随时间变化。学习时应以目标公司的具体 JD 和官方技术文档为准。 --- ## 最后给你的建议 如果你现在基础一般，不要先追求“会所有 AI 名词”。最稳的路线是： ```text Linux + 网络 -> Python/Shell 自动化 -> Docker + Kubernetes -> 监控、日志、告警 -> 部署一个 AI 服务 -> 练习故障、回滚和成本分析 -> 再补 MLOps、GPU 或 AIOps 专项 ``` 面试官最想确认的不是你能背多少工具，而是：**系统出问题时，你能不能冷静地找到证据、控制影响、恢复服务，并让同类问题不再发生。**