运维 / DevOps 实习生一面、二面面经

#牛客AI配图神器#

这个是我很早之前的面试了，当时在上一家基本也就干杂活了，面试也是在学校无聊就随便面了也没准备，各位大佬轻喷[尴尬]

顺便吐槽下牛客这个AI配图，估计是文字太长了，不给我生成词云图

观远数据一面面经

时间：2025年12月26日

岗位：运维/DevOps

面试官：同组MT

面试详细记录与复盘

1. Linux 基础：发行版与包管理

Q: 你比较熟悉 Linux 的哪些发行版？Ubuntu 的包管理器是什么？

我的回答：

• 实习时用过 CentOS，后来建设新环境用了 AlmaLinux (基于 RedHat)。
• 自己平时玩 Debian 和 Ubuntu。
• Ubuntu 的包管理器是 apt。

AI 补充/点评：

• 回答得当。可以顺带提一下 RedHat 系 (yum/dnf) 和 Debian 系 (apt/dpkg) 的区别会更完整。

2. Linux 进阶：LVM 分区

Q: Linux 中 LVM (逻辑卷管理) 怎么做分区？创建分区的流程步骤是怎样的？

我的回答：

• 这方面确实不太清楚，没怎么操作过。

AI 补充 (知识点盲区)：LVM 的标准创建流程如下：

1. 物理卷 (PV)：使用 pvcreate /dev/sdb1 将物理硬盘或分区初始化为物理卷。
2. 卷组 (VG)：使用 vgcreate my_vg /dev/sdb1 创建卷组，将 PV 加入其中。
3. 逻辑卷 (LV)：使用 lvcreate -L 10G -n my_lv my_vg 从卷组中划分出逻辑卷。
4. 格式化：使用 mkfs.ext4 /dev/my_vg/my_lv 格式化逻辑卷。
5. 挂载：使用 mount 挂载使用，并写入 /etc/fstab 实现开机自动挂载。

3. Linux 系统管理：内核参数调整

Q: 如果要调整 Linux 的内存参数或系统参数（例如禁用 IPv4），应该修改哪个文件？

我的回答：

• 内存参数可能是 ulimit。
• 禁用 IPv4 应该是在 /etc 目录下调，具体文件不太记得了。
• 网络配置 CentOS 是 NetworkManager。

AI 补充 (回答不准确)：

• 修改系统内核参数：通常修改 /etc/sysctl.conf 文件或 /etc/sysctl.d/ 下的文件。 例如禁用 IPv4：添加 net.ipv4.conf.all.disable_ipv4 = 1。修改后需要执行 sysctl -p 使配置生效。
• ulimit：主要用于限制用户进程的资源（如最大文件打开数），配置文件通常在 /etc/security/limits.conf。

4. Nginx：反向代理与故障排查

Q: Nginx 反向代理怎么配置？如果遇到响应慢或 502 报错，你会怎么排查？

我的回答：

• 配置：把本地端口（如 3000）反代到 443，配置域名和 SSL 证书（证书放 /etc/ssl）。
• 排查： 如果有 CDN，先看前端响应时间，排除 CDN 问题。看后端请求慢不慢，检查 /var/log/nginx 下的日志。检查数据库是否慢查询或死锁。

AI 补充：

• 排查思路补充： 502 Bad Gateway：通常意味着后端服务（如 PHP-FPM, Java 应用, Python 应用）挂了或端口不通。检查后端服务状态 (systemctl status), 端口监听 (netstat -tpln).504 Gateway Timeout：后端处理超时。检查后端逻辑是否耗时过长，或数据库查询慢。系统资源：使用 top, htop, free -m 检查服务器 CPU、内存是否爆满。

5. 数据库：MySQL 与 PostgreSQL

Q: 数据库熟悉程度？MySQL/PG 的主从复制怎么配？备份怎么做？

AI 补充

• MySQL 主从复制步骤： Master：开启 Binary Log (log_bin), 配置唯一的 server-id。Master：创建用于复制的用户 (CREATE USER 'repl'@'%' ...).Master：获取当前二进制日志坐标 (SHOW MASTER STATUS).Slave：配置唯一的 server-id。Slave：使用 CHANGE MASTER TO 指向 Master 的 IP、用户、Log File 和 Position。Slave：执行 START SLAVE。
• PostgreSQL 备份： 常用命令：pg_dump dbname > outfile (单库), pg_dumpall > outfile (全库)。

6. Docker：镜像构建

Q: 创建一个 Docker 镜像会用到哪些命令？

我的回答：

• FROM (指定基础镜像，如 Alpine)。
• RUN (执行命令，如 pip install)。
• COPY (复制文件)。
• WORKDIR (指定工作目录)。
• EXPOSE (声明端口)。
• CMD / ENTRYPOINT (启动命令)。

AI 补充：

• 回答非常完整。
• 加分项：可以解释 COPY 和 ADD 的区别 (ADD 支持 URL 和自动解压)，以及 CMD 和 ENTRYPOINT 的区别 (ENTRYPOINT 更像可执行程序，CMD 提供默认参数)。

7. K8s：核心组件

Q: K8s 的核心组件有哪些？

我的回答：

• API Server：核心入口，处理请求。
• etcd：键值数据库。
• Controller Manager：负责控制服务。
• Replication Controller (应为 ReplicaSet/Deployment 控制器)：负责副本。
• Scheduler：负责调度。
• Kubelet：控制节点。
• Kube-proxy：负责网络通信。

AI 补充：

• 回答准确。

8. 脚本语言：Shell vs Python

Q: 处理系统命令输出或复杂逻辑时，选 Shell 还是 Python？

我的回答：

• 选 Python。因为 Python 库多，处理复杂数据（如解析 YAML/JSON）更方便。

AI 补充：

• Shell 适合简单的管道操作和文件管理；Python 适合复杂逻辑、数据结构处理、API 交互。

9. 监控：采集指标

Q: 监控一般采集哪些指标？

我的回答：

• Uptime (运行时间)。
• Load Average (负载)。
• 其他的一时想不起来。

AI 补充 (回答不完整)：

• 常见基础监控指标 (USE 方法)： CPU：使用率 (User/System/IOWait)、负载 (Load Avg)。内存：已用/可用内存、Swap 使用率。磁盘：空间使用率、I/O 读写速度 (IOPS, Throughput)、磁盘延迟。网络：带宽 (In/Out)、包量 (PPS)、丢包率、TCP 连接数 (ESTABLISHED, TIME_WAIT)。
• 应用监控 (RED 方法)： Rate (请求速率/QPS)。Errors (错误率)。Duration (响应时间/Latency)。

10. 故障排查案例 (亮点)

Q: 之前实习中遇到的 K8s 排错经历？

我的回答：

• 现象：新环境 (AlmaLinux) 部署 K8s 时，拉取镜像最后一层特别慢，一直 Pending。
• 排查： 对比测试：Ubuntu KVM 没问题。工具：使用 iostat 发现 IO 延迟高；使用 eBPF 工具 (fireblaze? 可能是 fileslower 或 bcc 工具集) 发现文件系统操作延迟高。
• 根因：AlmaLinux 默认用的 XFS 文件系统，对 OverlayFS (Docker/Containerd 的存储驱动) 的小文件操作优化较差（或配置不当）。
• 解决：重装系统，改用 ext4 文件系统。

二面

面试官：+2（管运维和技术支持两个组的）

1. 实习/项目中比较有挑战的经历

我的回答：介绍了在建设新游道时遇到的 K8s 镜像拉取缓慢的问题。

• 现象：在 K8s 节点上拉取镜像时，最后一层下载特别慢。对比测试发现 AlmaLinux 发行版有问题，而 Ubuntu 没问题。
• 排查过程： 使用 iftop 监测网络，未发现异常。使用 vmstat 发现 IO wait 较高，怀疑进程阻塞。使用 eBPF 工具分析文件系统延迟，定位到文件系统问题。
• 根因：AlmaLinux 默认使用的 XFS 文件系统对 OverlayFS（Docker 镜像分层使用的联合文件系统）的小文件操作优化不佳。
• 解决：将文件系统重新格式化为 ext4，问题解决。
• 思路：基于 Docker 镜像最后一层通常包含大量小文件的经验，结合系统指标逐步排查。

AI 补充：

• OverlayFS 与 Backing Filesystem：OverlayFS 是 Docker/Containerd 常用的联合文件系统。它对底层文件系统（Backing Filesystem）有一定要求。XFS 在某些配置下（如未开启 d_type 支持）可能导致 OverlayFS 无法正常工作或性能下降。虽然现代 XFS 已支持 d_type，但在处理大量小文件的元数据操作（创建、删除、查找）时，ext4 往往表现更稳定且开销较小。
• 排查工具链： 网络：ping, curl, iftop, tcpdump。磁盘IO：iostat, iotop, pidstat -d。内核/系统调用：strace, perf, eBPF (如 BCC tools 中的 fileslower, ext4slower, xfsdist)。

2. AI Review 代码的实现与大模型应用

我的回答：

• 实现方式：调用 GitHub API 获取 Merge Request 的 diff 内容。
• 处理逻辑：编写 Prompt，将 diff 内容发送给大模型进行 Code Review，并生成修改建议。
• 模型选择：使用了 DeepSeek 模型。此前在 AI 客服项目中也接触过 Azure OpenAI (GPT 系列)。

AI 补充：

• 自动化 Code Review 架构：通常通过 GitLab Webhook 或 GitHub Actions 触发。 触发：监听 MR/PR 创建或更新事件。获取上下文：不仅获取 diff，有时还需要获取相关文件的完整上下文以提高准确性。Prompt 工程：设计 Prompt 让 AI 关注代码规范、潜在 Bug、安全性、性能等方面，而非简单的语法检查。反馈：将 AI 的评论通过 API 回写到 MR 的评论区。
• 挑战：Token 限制（大变更如何处理）、幻觉（胡乱建议）、代码隐私安全。

3. 对 AI 在运维中应用的看法及风险控制

我的回答：

• 看法：AI 是提效工具，擅长编写复杂的正则表达式、日志分析脚本。AIOps 领域已有大团队探索利用模型进行故障提前告警和根因分析。
• 风险：直接让 AI 操作高权限系统（如执行 rm -rf）风险极高，可能导致生产事故。
• 风控措施： Agent 规范：使用 skills.md 等方式明确定义 AI Agent 的能力边界和工具使用规范。Human-in-the-loop：关键命令生成后，必须经过人工 Review 才能执行。

AI 补充：

• 运维领域的 AI 落地（AIOps）： 可观测性增强：日志聚类、异常检测（KPI 异常）、调用链根因定位。Copilot 模式：辅助编写脚本（Shell/Python/K8s YAML）、解释报错信息、查询知识库。
• 安全防护： 沙箱环境：AI 生成的代码应在隔离的沙箱中运行。最小权限原则：给 AI 调用的 API Token 仅授予必要的只读或低风险权限。命令过滤：建立高危命令黑名单。

4. K8s 网络原理

我的回答：

• 坦诚了解不深，主要使用 Docker，K8s 更多是通过 CMDB 或 UI 点点点操作。
• 提到 kube-proxy 组件。
• 知道 K8s 会为每个 Pod 分配独立的 IP 地址。
• 提到 Ingress（通常由 Nginx 实现）用于集群外部访问。

AI 补充：

• K8s 网络模型核心原则： 任意两个 Pod 之间可以直接通信，无需 NAT。Node 和 Pod 之间可以直接通信。Pod 看到的 IP 和外界看到的 IP 一致。
• 关键组件： CNI 插件（如 Flannel, Calico, Cilium）：负责为 Pod 分配 IP 并打通跨节点网络（Overlay 隧道或 BGP 路由）。kube-proxy：负责 Service 的负载均衡，维护节点上的 iptables 或 IPVS 规则，将 Service IP 的流量转发到后端的 Pod IP。CoreDNS：负责集群内的域名解析（Service Discovery）。Ingress Controller：七层负载均衡，管理外部 HTTP/HTTPS 流量进入集群。

5. 监控体系与故障案例

我的回答：

• 工具：Prometheus + Grafana。
• 理解：监控的核心价值是提前预警（如 CPU 飙升），将事故扼杀在萌芽状态。
• 故障案例：Redis 生产事故。 背景：Redis 所在机器物理内存仅 8G，但配置的水位线（maxmemory）误设为 16G。过程：业务增长导致 Redis 内存超限，触发 OOM 或系统级 Kill，导致服务不可用。恶化：客户端缺乏自动重连机制，导致消息堆积，最终演变成 P0 级事故。反思：虽然部署了 Prometheus，但缺乏有效的巡检和告警配置，导致未能提前发现配置错误。

AI 补充：

• 监控系统的四个黄金指标（Google SRE）：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
• Redis 关键监控指标： used_memory / maxmemory：内存使用率。evicted_keys：因内存满而被驱逐的键数量（反映容量瓶颈）。rejected_connections：被拒绝的连接数。instantaneous_ops_per_sec：QPS。latest_fork_usec：RDB/AOF rewrite 时的 fork 耗时（可能导致阻塞）。
• 告警治理：告警不仅要有，还要准。避免“狼来了”导致的告警疲劳。配置错误（如 8G 机器配 16G 阈值）属于配置管理（CMDB/IaC）的范畴，应在部署阶段通过校验拦截。

6. SRE 与 传统运维的区别

我的回答：

• SRE (Site Reliability Engineering)： 关注 SLA (Service Level Agreement)。云原生和微服务时代的产物。强调控制“爆炸半径”（Blast Radius）。技能栈更偏向 K8s、监控、开发能力。
• 传统运维：更多应对规模较小的场景，手动操作较多。

AI 补充：

• 核心区别：SRE 是“用软件工程的方法解决运维问题”。
• 关键概念： SLI/SLO/SLA：指标、目标、协议。Error Budget（错误预算）：允许系统出错的额度，用完则停止发布新功能，转而修复稳定性。Toil（琐事）：SRE 致力于通过自动化减少重复性、低价值的手工劳动（Toil），通常限制 Toil 时间在 50% 以下。Blameless Postmortem（免责复盘）：关注流程和系统缺陷，而不是指责个人。

7. 数据库（PG vs MySQL）

我的回答：

• 更倾向于使用 PostgreSQL (PG)。
• 原因： 性能较好。对 AI 向量化支持友好（pgvector 插件），相比 MySQL 性能损耗更小。
• 高可用：仅了解主从复制，具体细节不清楚。

AI 补充：

• 架构差异： PG：多进程模型（每个连接一个进程），稳定性高，但高并发下连接消耗大（通常需配合 PgBouncer）。MySQL：多线程模型，上下文切换开销较小。
• 功能差异： PG：支持更丰富的数据类型（JSONB, Array, GIS, Vector），SQL 标准兼容性极好，适合复杂查询和分析型业务。MySQL：互联网大厂使用广泛，生态成熟，InnoDB 引擎在简单的 OLTP 场景下表现优异。
• PG 高可用方案： Patroni：基于 Etcd/Consul/Zookeeper 的高可用模板，目前最主流方案。Repmgr：基于流复制的集群管理工具。Keepalived + VIP：传统的冷备或切换方案。