devops-面试

有大佬看上请联系我(广州 深圳)
汇丰银行外包 devops面试

Jenkins 发布失败的原因有哪些？

1. 代码拉取失败（SCM问题）
   原因：

• Git 仓库地址错误
• Token / SSH key 失效
• 分支不存在
• 网络不通

表现：

• checkout failed
• fatal: repository not found

---

2. 构建失败（Build阶段）
   原因：

• 代码编译错误
• 依赖下载失败（Maven/npm/go proxy问题）
• 环境缺失（JDK / Node版本不对）

表现：

• compile error
• dependency resolve failed

---

3. 单元测试失败
   原因：

• 测试用例失败
• 测试环境依赖不可用

表现：

• test failure
• build marked as unstable

---

4. Docker 构建失败
   原因：

• Dockerfile 写错
• base image 不存在
• 磁盘空间不足

表现：

• docker build failed

---

5. 镜像推送失败
   原因：

• Harbor / Docker registry 不可用
• 权限不足（push denied）
• 网络问题

---

6. 部署失败（K8s / 服务器）
   原因：

• kubeconfig 权限问题
• namespace 不存在
• image tag 不存在
• yaml 配置错误

表现：

• kubectl apply failed
• image pull backoff

---

7. 镜像拉取失败
   原因：

• image tag 写错
• 私有仓库未登录
• network policy / firewall

---

8. 权限问题（非常常见）
   原因：

• Jenkins credential 过期
• git / docker / k8s 权限不足
• RBAC 配置错误

---

9. 环境变量或配置错误
   原因：

• dev/test/prod 配置混乱
• 配置缺失导致启动失败

---

10. 磁盘 / 资源问题
    原因：

• Jenkins workspace 满
• Docker layer 占满磁盘
• 节点内存不足

---

总结：
Jenkins 发布失败通常分为五类：代码问题、构建问题、镜像问题、部署问题和环境/权限问题，其中最常见的是依赖失败、权限问题和部署阶段配置错误。

你是怎么做 Jenkins 发布的？

1. 整体思路（先讲流程）
   Jenkins 发布一般是一个 CI/CD 流程：

代码提交 → Jenkins 拉取代码 → 构建 → 测试 → 打包 → 制作镜像 → 推送镜像仓库 → 部署到 K8s/服务器 → 验证

面试总结一句话：

我在 Jenkins 中通常通过 Pipeline 实现 CI/CD 流程，包括代码拉取、构建、测试、Docker 镜像构建与推送，最后部署到 Kubernetes 或服务器，并结合滚动发布与健康检查保证发布的稳定性与可回滚性。

Jenkins 中多环境你遇到过什么问题？

1. 环境变量混乱
   问题：不同环境变量串用，容易连错数据库或服务
   解决：Jenkins 参数化构建（dev/test/prod），环境变量按环境单独配置

2. 配置文件难管理
   问题：不同环境配置混在一起，发布需要手动改
   解决：使用 Spring Profile / Nacos / Apollo / Helm values 分环境管理

3. 发布流程不统一
   问题：不同环境用不同脚本，维护成本高
   解决：统一 Jenkinsfile，通过参数控制不同环境部署逻辑

4. 权限控制不严
   问题：开发可能误发布到生产
   解决：生产环境增加权限控制 + 人工审批（input stage）

5. 镜像版本混乱
   问题：使用 latest 或覆盖版本，导致不可追溯
   解决：使用固定版本（git commit / build number），禁止 latest

6. 分支与环境映射混乱
   问题：分支随意发布到不同环境
   解决：制定分支规范（dev/test/master 对应不同环境）

总结：
通过 Jenkins 参数化 + 配置中心 + 权限控制 + 版本规范 + 分支规范，实现多环境隔离、发布标准化和可追溯管理。

一个 Pod 访问不到另一个 Pod 的排查思路？

1. 先确认基础连通性（IP 层）
   步骤：

• ping 对方 Pod IP
• curl / telnet 对方 IP + 端口

判断：

• IP 不通 → 网络/CNI 问题
• IP 通但端口不通 → 服务问题

---

2. 检查 Pod 是否在同一网络模型
   问题点：

• 不同 Node 是否跨节点通信
• CNI 是否正常（Flannel / Calico / Cilium）

排查：
kubectl get pod -o wide
查看 Pod IP 和 Node 分布

---

3. 检查 Service 是否正确
   问题：

• 访问 Pod IP vs Service IP 混淆
• Service selector 不匹配

排查：
kubectl get svc
kubectl describe svc

---

4. 检查 DNS 是否正常（如果用服务名访问）
   问题：

• CoreDNS 异常
• DNS 解析失败

排查：
nslookup service-name
kubectl get pods -n kube-system

---

5. 检查 NetworkPolicy（最常见隐藏问题）
   问题：

• Pod 被策略限制访问

排查：
kubectl get networkpolicy
kubectl describe networkpolicy

---

6. 检查防火墙 / 安全组
   问题：

• Node 安全组未放通
• iptables 拦截

排查：
iptables -L
云厂商安全组规则

---

7. 检查目标 Pod 状态
   问题：

• Pod 未 Ready
• 应用未启动成功

排查：
kubectl get pod
kubectl describe pod
kubectl logs

---

8. 检查端口是否监听
   问题：

• 容器未监听对应端口

排查：
kubectl exec -it pod -- netstat -tlnp

---

9. 检查 kube-proxy / Service 转发
   问题：

• iptables/ipvs 规则异常

排查：
kubectl get pods -n kube-system

---

总结：
Pod 访问失败通常从四层排查：

1. IP是否通（网络/CNI）
2. Service是否正确
3. DNS是否正常
4. 是否被 NetworkPolicy / 防火墙拦截

面试一句话：
Pod 访问异常一般先排查网络连通性（CNI），再查 Service 与 DNS 解析，最后排查 NetworkPolicy、安全组及应用自身监听状态。

RAG 幻觉问题你用什么方式解决？

1. 提升检索质量（核心）
   问题：检索不到相关内容 → 模型只能“编”
   解决：

• 优化向量模型（embedding）
• 调整 chunk 切分策略（按语义而不是固定长度）
• 增加 topK + rerank（重排序模型）

---

2. 引入 rerank（关键手段）
   问题：召回结果不准
   解决：

• 使用 cross-encoder / bge-reranker
• 对初步召回结果重新打分排序
• 只保留最相关的内容给 LLM

---

3. 控制上下文（Context control）
   问题：上下文太多/太杂导致模型乱生成
   解决：

• 限制 token 长度
• 去重
• 只取最相关片段
• chunk 质量过滤

---

4. 强制“基于资料回答”
   问题：模型自由发挥
   解决：

• Prompt 约束：只允许基于 context 回答
• 无相关内容时返回“不知道”

---

5. 引入引用机制（grounding）
   问题：回答没有依据
   解决：

• 每个回答附带 source
• 输出 chunk 来源
• 可追溯性（document id）

---

6. 提升知识库质量
   问题：垃圾数据导致幻觉
   解决：

• 清洗文档
• 去重复
• 去过期内容
• 标准化结构化数据

---

7. 混合检索（Hybrid Search）
   问题：纯向量检索召回不全
   解决：

• BM25（关键词）+ 向量检索结合
• 提高召回率

---

8. 置信度控制（拒答机制）
   问题：模型“硬编”
   解决：

• 设置 similarity threshold
• 低于阈值直接拒答
• 或 fallback 到搜索

---

9. 多轮验证（可选高级）
   问题：一次回答不可靠
   解决：

• 先检索 → 再生成 → 再验证
• self-check / critic model

---

总结：
RAG 幻觉主要通过提升检索质量（embedding + rerank）、控制上下文、强制引用来源、设置拒答机制以及优化知识库质量来解决，本质是减少“模型自由发挥”，增强“基于证据生成”。

查询改写（Query Rewriting）是什么？

1. 基本概念
   查询改写是指：将用户的原始问题，转换成更适合检索系统（如RAG、搜索引擎）理解和召回的查询表达。

目标：
提高召回质量、减少歧义、提升命中率。

---

2. 为什么需要查询改写
   问题：

• 用户表达不规范
• 口语化 / 简写 / 模糊
• 信息缺失（时间、范围、对象）

例如：
“Pod挂了怎么办”
→ 检索系统可能匹配不到准确文档

---

3. 常见改写方式

（1）扩展型改写
把短问题扩展成完整语义

示例：
原始：pod 访问不了
改写：Kubernetes 中 Pod 之间无法通信的排查方法

---

（2）关键词提取
提取核心检索词

示例：
原始：jenkins 发布失败怎么办
改写关键词：Jenkins + pipeline + deploy + failure

---

（3）同义词扩展
增加语义覆盖

示例：

• pod = 容器实例
• crash = 崩溃 / 重启 / 异常退出

---

（4）结构化改写
把自然语言转成结构化查询

示例：
原始：查 mysql 索引失效原因
改写：
{
topic: mysql
keyword: index failure
}

---

4. 在 RAG 中的作用

流程：
用户问题 → Query Rewrite → 向量检索 / BM25 → rerank → LLM生成

作用：

• 提升召回率
• 降低幻觉
• 提高命中率

---

5. 常见实现方式

（1）规则改写

• 关键词扩展
• 同义词库

（2）LLM改写（主流）
让大模型优化 query：

Prompt：
“将用户问题改写为适合知识库检索的查询语句”

（3）多查询扩展（Multi-Query）
一次生成多个 query：

• 原问题
• 扩展版
• 关键词版

---

6. 面试总结一句话
   查询改写是 RAG 中的重要环节，通过对用户原始问题进行语义扩展、关键词提取和结构化处理，提高检索系统的召回质量，从而减少幻觉并提升回答准确率。

SSH 连接很慢是什么原因？

1. DNS 解析慢（最常见）
   原因：
   SSH 默认会做反向解析（reverse DNS）

表现：
输入 SSH 后卡住几秒甚至几十秒

解决：

• /etc/ssh/sshd_config 设置：
  UseDNS no
• 或修复 DNS 服务器

---

2. GSSAPI 认证慢
   原因：
   SSH 默认尝试 Kerberos / GSSAPI 认证

表现：
连接卡顿但最终成功

解决：

• ssh 客户端禁用：
  GSSAPIAuthentication no

---

3. SSH 密钥 / 认证方式问题
   原因：

• 尝试多个 key
• SSH agent 过多 key

表现：
认证阶段很慢

解决：

• 指定 key：
  ssh -i key.pem
• 清理 ssh-agent key

---

4. 网络延迟 / 丢包
   原因：

• 跨地域网络
• VPN / 专线不稳定

表现：
TCP 建连慢

排查：
ping / traceroute

---

5. 服务器负载高
   原因：

• CPU / 内存打满
• load average 高

表现：
SSH 登录后卡住

排查：
top / uptime

---

6. 磁盘 IO 慢
   原因：

• /home / /var 盘满或 IO 高

影响：
认证后 shell 初始化慢

---

7. PAM / 登录脚本慢
   原因：

• /etc/profile
• .bashrc 执行慢命令
• nfs home 目录挂载慢

表现：
登录成功但卡在 shell

---

8. SSH 配置问题
   原因：

• PrintMotd
• Banner
• MOTD 脚本慢

解决：
关闭不必要的登录信息

---

总结：
SSH 变慢一般是 DNS 解析（UseDNS）、GSSAPI 认证、网络延迟、服务器负载或登录脚本导致的，其中最常见的是 DNS 反向解析问题。

Pod 连不上有哪些原因？

1. 网络不通（最常见）
   原因：

• CNI 插件异常（Flannel / Calico / Cilium）
• 跨节点网络不通
• Pod IP 不可达

表现：

• ping 不通 Pod IP
• 跨 Node 访问失败

---

2. Service 配置问题
   原因：

• selector 写错
• Endpoint 为空
• Service 没有正确绑定 Pod

排查：
kubectl get endpoints

---

3. DNS 问题
   原因：

• CoreDNS 异常
• DNS 解析失败
• service name 写错

表现：

• 用 IP 能通，用域名不通

---

4. NetworkPolicy 限制
   原因：

• 策略禁止 ingress/egress 流量
• namespace 级隔离

排查：
kubectl get networkpolicy

---

5. Pod 未正常运行
   原因：

• CrashLoopBackOff
• 没有 Ready
• 容器未启动成功

排查：
kubectl get pod
kubectl logs

---

6. 端口未监听
   原因：

• 应用没启动
• 监听地址错误（只监听 127.0.0.1）

表现：

• IP 通但端口不通

---

7. 防火墙 / 安全组问题
   原因：

• Node 安全组未放通
• iptables 拦截流量

排查：
iptables -L

---

8. kube-proxy 异常
   原因：

• iptables / ipvs 规则不正常
• Service 转发失败

---

9. CNI / IP 分配问题
   原因：

• Pod IP 冲突
• IPAM 异常
• Node CIDR 配置错误

---

10. Ingress / 网关问题（如果走入口）
    原因：

• Ingress 规则错误
• upstream 配置错误

---

总结：
Pod 连不上通常从四个方向排查：

1. 网络（CNI / 跨节点）
2. Service / DNS
3. Pod 自身状态
4. 安全策略（NetworkPolicy / 防火墙）