# FDE 面试题库：企业软硬件部署与解决方案交付

版本：1.0 · 2026-09-16 · 共 32 题

适用岗位：带着公司的产品进入企业，完成需求澄清、软件与硬件环境部署、系统集成、业务验证、客户培训和运维交接的 FDE（Forward Deployed Engineer）。适用于初中级招聘及独立交付能力评估。

本题库根据项目内四份资料组织，自行编写参考答案。它不是任何公司的官方真题或官方标准答案。资料中的题库分类页未下载全部答案，本文答案不是其答案转载。硬件题主要覆盖服务器、GPU、网络和设备接入；电气施工、PLC 程序修改等专业工作需另设考核。

开放题可以有多种正确方案。评价候选人的假设、决策依据、执行步骤和验证证据，不要求背出本文措辞。历史经历题应回答真实经历；没有相关经历时允许说明，并用场景题验证能力，不鼓励编造。

## 使用方法与来源

每题包含题干、参考答案、评分要点和来源标记。“基础”考察跟随团队交付的能力；“进阶”考察独立承担边界清楚的项目；“综合”考察多约束下的执行与判断。

- **S1 · 面试形式参考**：[Palantir FDSE 个人面经](https://www.reddit.com/r/csMajors/comments/1plags8/palantir_fdse_full_interview_loop_process/)。借鉴问题拆解、现场阅读文档和编程的形式，不声称下列具体题目出现在原面试。
- **S2 · 题意改编**：[Akoum 面试题文章](https://akoum.me/blog/forward-deployed-engineer-interview-questions)。第 05、23、25、26 题参考其提问方向，背景和答案由本题库编写。
- **S3 · 分类参考**：[FDEInterviews 分类汇总](https://www.fdeinterviews.com/fde-interview-questions)。用于选择集成、生产工程、AI 评估和实践能力的覆盖范围，不沿用其公司标签。
- **S4 · 岗位职责参考**：[Palantir Mixed Reality FDE 招聘页](https://jobs.lever.co/palantir/96a0ce26-cf84-4fa8-934b-acc4363620b2)。用于校准软硬件跨层排障、客户沟通及端到端交付职责；不将混合现实专门要求泛化到所有 FDE。
- **原创**：根据你们的企业交付场景编写。技术细节和评分建议为本题库作者的工程建议，不代表上述来源背书。

## 一、需求澄清与解决方案

### 01｜客户说“我们要上一套 AI”，你如何推进？

难度：基础｜建议：5 分钟｜来源：原创，S4 岗位职责参考

**题干**

企业老板希望购买你们的产品“提升效率”，现场有业务主管、IT 和操作人员。第一次会议只有 30 分钟。你会问什么，会后交付什么？

**参考答案**

先选一个具体流程，让业务人员演示一次真实操作，明确输入、输出、工作量、耗时、返工原因和异常处理。向老板确认收益目标和预算边界；向 IT 确认部署位置、网络、数据权限和系统接口；向操作人员了解使用障碍。

会后输出一页需求纪要：目标流程、当前基线、拟改善指标、试点范围、不包含的内容、依赖及责任人。列出尚未验证的假设，例如历史数据是否可取得。安排取样验证，再做排期与方案承诺。若问题主要来自流程或数据缺失，应说明产品能解决的部分及前置条件。

**评分要点**：能将笼统诉求转成可验证目标；同时覆盖业务、IT 和使用者；不在约束不明时承诺效果。

### 02｜业务部门与 IT 提出冲突要求，如何定方案？

难度：进阶｜建议：5 分钟｜来源：原创

**题干**

业务部门希望所有员工随时调用云端模型，IT 要求资料不能出内网。你如何推进决策？

**参考答案**

先澄清禁止外传的数据范围、批准流程和实际业务场景。比较内网部署、合规批准后的脱敏外部调用、仅公开资料使用云服务等可行选项，分别说明效果、容量、成本和运维负担。脱敏方案必须验证重识别风险，不能自行认定可外传。

确定谁有权批准数据流向，记录数据路径与访问主体。若当前条件无法同时满足，提出分阶段试点和明确限制，由有权限的负责人决策。不能擅自通过个人账号、代理或临时隧道绕过客户限制。

**评分要点**：识别决策权限；给出可比较方案；不把约束冲突推给开发人员自行承担。

### 03｜两周上线，怎么划定可交付范围？

难度：进阶｜建议：6 分钟｜来源：原创

**题干**

客户要求两周内完成三个系统集成、历史数据迁移、权限系统和 AI 报告。部分接口文档尚未提供。如何拟定第一版计划？

**参考答案**

识别核心业务闭环和关键路径。第一版可选择一个数据源、一类报告、一组试点用户，复用已有权限能力，先验证真实样本与接口可用性。其他需求列入后续阶段，而不是默默删除。

将接口访问、样本提供、安全评审等列为有责任人和截止时间的依赖。计划中预留测试、培训和回滚演练时间。接口无法按时取得时，可讨论经批准的批量导入方案，但说明其时效和人工成本。基于依赖是否满足给出条件化排期，并设置中途的继续或调整范围决策点。

**评分要点**：范围取舍清楚；依赖可追踪；排期包含验证和交接。

### 04｜如何估算客户需要的服务器与 GPU？

难度：进阶｜建议：7 分钟｜来源：原创，S3 分类参考

**题干**

客户说“我们有 200 个员工，买一台 GPU 服务器够不够？”请说明你如何回答及估算。

**参考答案**

员工数不足以推算容量。需要峰值到达速率、请求持续时间、输入输出长度、模型、上下文长度、同时运行任务、等待时间目标、增长量与可靠性要求。

用真实样本在目标或同类硬件上测试吞吐、首字延迟、完整响应延迟、显存、CPU、内存和磁盘。稳定条件下可用平均在途请求数约等于到达速率乘平均响应时间做粗估；例如 0.5 次/秒、平均 20 秒，平均约 10 个在途请求，但这不能直接证明峰值容量或 p95 延迟合格。

显存估算需要权重、KV cache 和运行开销，不能只看模型文件大小。给出实测配置、排队策略、容量余量、扩容触发指标，以及单机故障时的业务兜底方案，再决定是否一台足够。

**评分要点**：通过工作负载而非员工数估算；有压测验证；区分容量和可用性。

### 05｜部署成功的定义是什么？

难度：基础｜建议：5 分钟｜来源：S2 题意改编，答案原创

**题干**

你们的产品已能打开页面，Demo 也能运行。客户问是否可以签署验收，你会检查哪些条件？

**参考答案**

验收应对照双方预先确认的范围和指标：真实样本的业务效果、目标负载下的性能、访问控制、异常处理、备份恢复、操作培训与支持渠道。检查运行环境、版本和配置记录是否完整，客户指定运维负责人是否能够按手册处理常见问题。

例如报告系统可约定关键字段准确性、人工复核比例、处理时长和异常可追溯性。记录测试样本、实际结果、未解决问题及责任人；仅在接受范围明确后签署。页面可访问只是其中一项技术检查。

**评分要点**：验收可测量；包含业务效果和交接；不将未解决问题隐藏在“已上线”中。

## 二、软硬件部署与环境准备

### 06｜进入现场之前，应该准备什么？

难度：基础｜建议：5 分钟｜来源：原创，S4 职责参考

**题干**

下周去客户工厂部署你们的一体机及软件，你如何减少“到现场才发现装不了”的风险？

**参考答案**

提前确认设备清单、CPU 架构、GPU 型号与显存、操作系统、驱动支持、磁盘空间、供电散热和安装位置。获取网络拓扑、IP 与 DNS 规划、所需端口、账号权限、证书、外网限制和现场联系人。

准备经过验证的版本包、镜像、校验清单、配置模板、部署及回退手册、验收数据；使用接近客户环境的机器预演。确认变更窗口、备份责任和现场支持分工。涉及布线、电气或设备改动时由具备职责和资格的人员执行，FDE 负责接口需求和软件侧验证。

**评分要点**：软硬件和组织依赖齐全；准备可重复安装材料；职责明确。

### 07｜如何完成完全离线的软件部署？

难度：进阶｜建议：6 分钟｜来源：原创

**题干**

客户服务器无法访问互联网，容器和 Python 服务依赖多个软件包，部署当天如何避免临时联网安装？

**参考答案**

在受控联网环境中按目标系统和架构准备固定版本的镜像、依赖包、模型、许可证资料和必要证书，列出哈希值及版本清单。Python 二进制依赖须匹配解释器、系统和架构，不能直接复制另一平台的虚拟环境。

将软件包按客户批准流程导入，验证完整性后加载镜像和离线依赖。提前在禁网环境中测试冷启动、模型加载、初始化和业务路径，识别运行时下载、在线许可证验证等隐性依赖。密钥通过客户认可的方式单独注入。离线条件不满足时明确阻塞，不假装已完成部署。

**评分要点**：识别运行时联网和平台兼容；包可验证；离线预演覆盖业务路径。

### 08｜服务器能打开页面，客户电脑打不开，怎么排查？

难度：基础｜建议：6 分钟｜来源：原创

**题干**

服务在服务器本机访问正常，同网段客户电脑访问超时。请给出检查顺序及每一步验证的假设。

**参考答案**

先确认客户访问的地址、协议和端口。检查服务器监听地址是否仅为回环地址、容器端口是否映射到宿主机；分别在本机用回环和网卡地址验证。再从客户电脑验证 DNS 解析、到目标端口的 TCP 连通性、路由和防火墙策略。

若 TCP 能建立但 HTTP 失败，再检查反向代理、Host、TLS 和应用日志。可以用批准的连通性工具或抓包确认请求到达哪一层。修复后使用原客户电脑重测完整业务路径，不仅在服务器上重测。ICMP 不通不能单独证明应用端口不可达。

**评分要点**：逐层缩小范围；每步有假设；不直接关闭全部防火墙。

### 09｜GPU 在宿主机可见，容器内不可用，怎么办？

难度：进阶｜建议：6 分钟｜来源：原创

**题干**

宿主机 `nvidia-smi` 正常，模型容器提示找不到 CUDA 设备。如何定位？

**参考答案**

确认容器是否申请了 GPU、容器运行时是否配置 GPU 支持、设备权限是否正确。用已验证的最小 GPU 容器在同一机器做对照，区分宿主驱动、容器运行时和业务镜像的问题。

核对驱动与镜像内 CUDA 运行库、深度学习框架的兼容要求，检查框架是否安装了 CPU 版本。最小容器成功而业务容器失败时，聚焦镜像和启动配置；最小容器也失败时先修复底层环境。变更驱动前安排窗口和回退方案，修复后验证模型推理及重启后的可用性。

**评分要点**：会做最小对照；区分驱动与容器运行库；不在生产机盲目升级全部组件。

### 10｜设备数据明显不对，如何定位软硬件边界？

难度：进阶｜建议：6 分钟｜来源：原创，S4 职责参考

**题干**

设备面板显示温度 25.3℃，你们的软件显示 253℃，偶尔数据不更新。你如何调查？

**参考答案**

先保存原始读数、时间戳、设备标识和接口说明，对照已知状态确认单位、缩放系数、字段类型和解析方式。253 与 25.3 的关系可能是缩放问题，但必须用协议和样本验证。

对不更新的问题分别检查设备是否产生新数据、链路是否可达、读取周期与超时、进程是否停止，以及缓存是否保留旧值。界面应显示最后更新时间并区分有效值、无效值和离线状态，不能把旧值当实时值。先只读验证，设备参数修改与物理操作交由授权人员确认。

**评分要点**：不把猜测当根因；能追踪原始数据到展示；识别陈旧数据风险。

### 11｜如何向多个客户复制部署？

难度：进阶｜建议：5 分钟｜来源：原创

**题干**

同一产品已有五家客户，每家都有不同路径、数据库地址和业务规则。如何避免部署依赖某个工程师的电脑和记忆？

**参考答案**

统一版本产物和自动化部署流程，把客户差异放入经过校验的配置、插件或适配层。密钥与普通配置分开管理，记录每个现场的产品版本、配置版本、硬件环境和升级历史。

部署前做环境预检，部署后做健康与业务冒烟检查。升级先在代表性客户环境演练，按批次发布，保留回退能力。将现场发现转成产品修复、自动检查和文档，而不是为每家永久维护一个无升级路径的代码分支。

**评分要点**：产物一致、差异可控、现场状态可追溯；考虑长期升级成本。

## 三、集成、数据与生产排障

### 12｜旧系统没有接口，能直接写数据库吗？

难度：进阶｜建议：6 分钟｜来源：原创

**题干**

客户希望把你们的结果写回 ERP，但没有 API 文档。业务方给了数据库管理员账号，说“直接改表最快”。你会怎么做？

**参考答案**

先联系系统负责人或供应商，确认受支持的导入、扩展或接口方式。直接写表可能绕过业务校验、关联更新和审计，管理员账号也不能替代变更授权。优先采用受支持接口；可将结果生成为经过审核的导入文件作为短期方案。

如必须数据库集成，需要明确授权、表结构与业务约束、最小权限、测试环境验证、备份和回退。读写范围、失败行为及维护责任应形成书面约定。对不可逆业务动作，先建立人工确认流程。

**评分要点**：识别系统边界；提出可执行替代方案；保护业务一致性。

### 13｜接口超时，能否直接重试？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

系统向客户接口创建订单，30 秒后超时，但你不知道对方是否创建成功。如何避免漏单或重复下单？

**参考答案**

将结果标记为“未知”，不能把超时直接当作失败。优先用业务订单号或幂等键查询对方状态；若对方支持幂等写入，以相同键和相同内容重试。记录本地请求意图、业务标识、状态和重试次数。

对方不支持幂等也无法查询时，停止盲目自动重试，进入人工核对或对账流程。明确重试上限、退避和告警，区分读取请求与有副作用的写入。分布式锁本身不能证明远端操作只执行一次。

**评分要点**：处理不确定结果；稳定业务标识；有对账及人工兜底。

### 14｜客户导出的 Excel 每周变化，怎么接入？

难度：基础｜建议：5 分钟｜来源：原创

**题干**

同一份业务 Excel 经常改变列名、日期格式，还包含合并单元格和重复记录。你如何设计导入流程？

**参考答案**

保存原文件及来源批次，建立明确的字段映射和校验规则。日期、金额、单位和空值按约定解析；歧义不静默猜测。先展示预览及错误报告，区分可导入行、需修正行和阻断整批的问题。

使用稳定业务主键与批次标识处理重复和重复导入；规定更新、覆盖及冲突规则。保留原始值、转换值和错误原因，避免人工修正后无法追溯。映射规则版本化，并用历史文件做回归测试。

**评分要点**：数据契约、可追溯和幂等；不会“异常就跳过”。

### 15｜服务变慢时如何区分模型、数据库与网络？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

客户反映报告原来 10 秒完成，现在经常超过一分钟。你只有应用日志和机器监控权限，先怎么做？

**参考答案**

确认变慢的起点、影响用户和请求类型，按同类输入对比，检查最近发布、数据量和流量变化。沿请求标识拆分排队、数据库读取、文件处理、模型调用和写回时间，不用单一总耗时推断根因。

结合 CPU、内存、GPU、连接池、磁盘与外部依赖响应判断资源饱和或等待。例如 GPU 利用率低但队列积压，也可能是上游数据处理阻塞。优先做可回退的小范围缓解，再验证 p95/p99、错误率与业务正确性是否同时改善。

**评分要点**：有时间线和分段证据；结合资源与应用；不先扩机器或随意重启。

### 16｜升级需要修改数据库，如何回滚？

难度：进阶｜建议：6 分钟｜来源：原创

**题干**

新版本要重命名数据库字段。客户只允许短暂停机，且要求出现异常可以恢复旧版本。如何发布？

**参考答案**

优先使用兼容性迁移：先新增字段并保持旧版本可运行，执行可检查、可恢复的历史数据回填，再逐步切换读写。若采用双写，需要明确失败一致性、对账和修复机制。验证完成且旧版本退出后，才清理旧字段。

发布前验证备份恢复及新旧版本兼容性。应用回滚不等于数据回滚；上线后新增数据不能随意用旧备份覆盖。定义触发回退的指标、负责人和窗口，必要时先停写或降级，保护数据后再恢复服务。

**评分要点**：考虑应用和数据兼容；知道恢复备份可能丢新增数据；有分阶段方案。

### 17｜“备份每天成功”是否足够？

难度：基础｜建议：5 分钟｜来源：原创

**题干**

客户要求最多丢失 15 分钟数据，停机最多 2 小时。你发现系统只有每日一次数据库备份，如何处理？

**参考答案**

每日备份不能保证最多丢失 15 分钟数据，需要验证数据库支持的日志归档、时间点恢复或其他满足恢复点目标的机制。2 小时恢复时间还包括发现、决策、取得备份、恢复、校验与应用重新接入。

在隔离环境做恢复演练，测量实际数据缺口和恢复耗时；检查备份加密、访问权限、独立存储和恢复所需密钥。将数据库、文件、配置和必要的版本信息一起纳入方案。主从复制不能替代备份，因为误删或损坏可能被同步。

**评分要点**：理解恢复点和恢复时间；实际演练；覆盖全部关键数据。

### 18｜现场磁盘满了，如何应急？

难度：基础｜建议：5 分钟｜来源：原创

**题干**

客户系统停止写入，日志提示磁盘空间不足。客户催你马上删除文件恢复运行。如何处理？

**参考答案**

确认受影响的文件系统、剩余空间和 inode，找到增长源及占用最大的目录。先暂停可暂停的非关键写入，并通知业务影响。区分日志、缓存、临时文件与数据库文件；不能直接删除数据库数据、未知目录或仍需保留的审计记录。

按批准的保留策略清理或转移可再生文件；必要时扩容。注意删除仍被进程打开的文件未必释放空间。恢复后验证写入、队列和积压任务，设置轮转、配额、空间告警与容量增长检查。

**评分要点**：先辨认数据再操作；恢复业务后验证；补充长期措施。

## 四、AI 产品落地与业务验证

### 19｜什么时候选择规则、RAG、微调或 Agent？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

客户希望自动解析订单备注并生成生产指令。你如何选择技术方案？

**参考答案**

先区分确定规则、知识查询和需要模型理解的部分。格式稳定、约束明确的字段可用规则；频繁更新且需要可追溯引用的知识可用检索；有稳定任务、足量合规标注且基线仍不足时，再评估微调。多步骤且确实需要动态选择工具时才考虑 Agent。

以真实样本比较正确性、成本、延迟和维护难度。模型提取结果通过结构与业务规则校验；生产指令写入需要权限控制、幂等和风险分级，高风险操作保留人工审批。不要只比较演示效果。

**评分要点**：从任务约束选技术；有基线实验；模型输出与业务执行分离。

### 20｜“准确率 95%”能否上线？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

测试 100 份订单，95 份解析完全正确。业务方说可以上线自动生产，你会如何判断？

**参考答案**

先看样本是否代表真实流量、是否独立于训练调试，以及五次错误的严重程度。把数量、单位、尺寸等关键字段与普通描述区分评价，统计关键错误、需人工复核比例、处理时长和不同客户模板下的表现。

100 份样本不足以证明罕见高损失错误已被控制。补充边界和历史失败样本，按时间或客户来源保留独立测试集；先做影子运行或人工确认，设定与业务风险相匹配的放行条件。模型自报信心不能直接当成正确概率。上线后继续抽检和回归。

**评分要点**：识别样本与指标局限；按错误成本决策；有渐进上线措施。

### 21｜多部门知识库如何避免越权？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

公司知识库包含销售资料和仅财务可见的合同。如何保证销售用户无法通过问答读到财务合同？

**参考答案**

服务端从可信登录态取得身份与权限，检索时按文档或片段权限过滤，返回与工具调用时继续执行授权。不能仅在提示词中写“不要透露财务资料”，也不能先把全部资料发送给模型后再依靠输出过滤。

缓存应包含租户和权限上下文，权限变更和文档删除需同步到索引及缓存。引用和下载链接也执行授权。用不同角色、被撤权用户、跨租户请求和诱导式问题做负向测试，并记录不含敏感正文的审计证据。

**评分要点**：权限在服务端强制执行；覆盖缓存、引用和撤权；有越权测试。

### 22｜Agent 执行工具失败，如何避免重复扣费？

难度：进阶｜建议：6 分钟｜来源：原创，S3 分类参考

**题干**

Agent 可以创建付费任务。一次调用超时后，模型再次发起相同操作。你如何设计防护？

**参考答案**

将任务意图和稳定业务标识保存在服务端，由工具层校验权限、预算、参数和状态。一次操作使用持久化幂等键，不能每次模型重试都生成新键。未知结果先查询或对账，不能假设未扣费。

对高成本或不可逆操作设置明确的人类确认与额度边界，确认应绑定具体操作和参数，参数改变后重新确认。工具返回结构化状态，让模型区分成功、明确失败和结果未知。部署后用重复调用、超时后成功、重复确认等场景验证。

**评分要点**：控制不依赖模型自律；幂等贯穿业务动作；确认不能被参数变化绕开。

### 23｜上线后客户不使用，如何处理？

难度：基础｜建议：5 分钟｜来源：S2 题意改编，答案原创

**题干**

系统技术验收通过，但两周后使用量很低。客户主管要求马上增加功能。你如何判断下一步？

**参考答案**

先回到目标用户现场，观察他们完成真实任务，查找系统入口、登录权限、操作步骤、结果可信度和原有工具切换成本。核对“使用量”的统计口径，避免漏记或把后台任务误当未使用。

选择主要障碍做小范围实验，例如把入口嵌入原工作台、缩短输入步骤或增加结果证据。设定任务完成率、节省时间、返工率等指标，验证后再扩大。如果产品没有解决高频痛点，应调整场景而非堆功能。

**评分要点**：先找障碍再开发；观察真实工作；用业务结果验证改进。

## 五、客户沟通、责任与交接

### 24｜销售承诺了目前没有的功能，怎么办？

难度：进阶｜建议：5 分钟｜来源：原创

**题干**

客户要求周五交付一个销售已承诺的功能，而产品团队确认至少还需三周。你今天如何处理？

**参考答案**

当天核对承诺内容、合同范围、客户真正要达成的业务目标和产品交付风险。与销售、产品和交付负责人形成一致事实，再向客户说明差距、影响和可选方案，不把内部争议直接甩给客户。

方案可包括缩小范围、受控人工流程、阶段交付或调整日期；每项说明限制、费用及后续维护责任。由有权限的人确认变更并记录下一次检查时间。不能擅自承诺工程团队无法保证的时间，也不能隐藏问题等到周五。

**评分要点**：及时披露；内部协同；有可选择的补救措施和责任人。

### 25｜客户专属功能如何避免长期维护负担？

难度：进阶｜建议：5 分钟｜来源：S2 题意改编，答案原创

**题干**

大客户要求将自己的审批规则写死进产品主流程，并拒绝等待产品路线图。你如何回应？

**参考答案**

确认审批规则背后的控制目的和必须满足的部分。评估是否通过配置、扩展点或外围适配实现，并明确测试、版本兼容、升级与维护责任。用成本和交付风险向客户解释方案差异。

如果只能定制，建立可审计的例外决策，限定范围、维护期限和退出计划，由相应负责人批准。将通用需求反馈产品团队，但不能用“大客户优先”代替设计论证。

**评分要点**：满足业务目标的替代路径；明确维护责任；控制定制范围。

### 26｜写一份客户进度说明

难度：基础｜建议：5 分钟｜来源：S2 题意改编，答案原创

**题干**

本周完成服务器部署和单系统联调；客户尚未提供 ERP 测试账号，第二个接口未验证；原计划下周试点。请用五句话给客户项目负责人汇报。

**参考答案**

“本周已完成服务器部署及第一套系统联调，既定测试用例已通过。ERP 接口仍未验证，当前阻塞是尚未取得测试账号。若周二中午前取得账号且联调通过，我们按计划推进下周试点，否则需调整试点范围或日期。建议先以已接通系统开展受限试点，ERP 写回暂不开放。请贵方 IT 负责人确认账号提供时间，我们将在周二下午同步验证结果与更新后的计划。”

上述答案是示例，具体角色和日期应与实际约定一致；不能把假设写成已确认事实。

**评分要点**：事实、阻塞、条件、建议和责任明确；表达适合客户阅读。

### 27｜你离场后，客户如何继续运维？

难度：基础｜建议：5 分钟｜来源：原创，S4 职责参考

**题干**

系统目前只有你会部署和恢复。客户计划明天签收，你需要补齐什么？

**参考答案**

提供版本和配置清单、拓扑、启动停止及健康检查方法、备份恢复步骤、常见故障处理、升级回退流程和支持联系人。密钥由客户可控的渠道移交并设置权限，不写进普通操作文档。

让指定运维人员在测试环境独立完成健康检查、一次常见故障处置和恢复演练，记录结果与缺口。明确监控告警接收者、事件响应约定和服务边界。如果关键知识仍依赖个人，应作为未完成交接项处理。

**评分要点**：通过客户实际操作验证交接；有人接告警；资料与权限可持续维护。

### 28｜如何判断候选人真的主导过交付？

难度：进阶｜建议：8 分钟｜来源：原创，S1 项目深挖形式参考

**题干**

请选一个真实项目，讲清从接到需求到客户验收的过程。你亲自决定和执行了什么？最难的问题是什么？如果没有独立交付经历，请说明参与范围。

**参考答案**

本题没有可代背的个人经历。合格回答应包含客户目标、原始环境、个人职责、主要约束、采取的行动、验证证据和最终结果。需要能区分“我做的”“团队做的”和“供应商做的”。

例如讲述网络故障时，应说明请求停在哪一层、使用了什么证据、为什么选择某种修复，以及修复后如何确认业务恢复。面试官可要求画拓扑、还原一段排障过程或展示脱敏交付材料；受保密限制时接受口述结构与可公开证据。没有数据应如实说明，不用项目用户量或 Stars 替代个人贡献。

**评分要点**：责任边界与前后变化清楚；细节前后一致；接受追问并能解释取舍。

## 六、现场学习、编程与综合案例

### 29｜读文档并实现数据转换

难度：基础｜建议：20 分钟｜来源：原创题，S1 Learning 面试形式参考

**题干**

给候选人以下虚构接口契约，允许查 Python 标准库文档：

- 输入是记录列表，每项为字典，字段为 `device_id`、`ts`、`value`。
- `device_id` 为非空字符串；`ts` 为带时区的 ISO 8601 字符串；`value` 为整数或浮点数，排除布尔值、NaN 和无穷值。
- 每个设备只保留时间最新的有效记录；时间相同时保留输入中最后一条。
- 输出按设备 ID 排序，时间统一为 UTC；无效项返回零起始下标及原因，不使整批失败。

输入例子：

```python
[
    {"device_id": "B", "ts": "2026-09-16T08:00:00+08:00", "value": 1},
    {"device_id": "A", "ts": "2026-09-16T00:01:00Z", "value": 2},
    {"device_id": "B", "ts": "2026-09-16T00:00:00Z", "value": 3},
    {"device_id": "A", "ts": "2026-09-16T00:02:00Z", "value": True},
]
```

实现函数，说明复杂度和测试边界。

**参考答案**

按设备 ID 建立最新记录映射，先验证再比较时间，不能按时间字符串直接比较。不符合契约的记录保留错误信息。

```python
from datetime import datetime, timezone
from math import isfinite


def normalize(records):
    latest = {}
    errors = []
    for index, row in enumerate(records):
        try:
            if not isinstance(row, dict):
                raise ValueError("record must be an object")
            device = row.get("device_id")
            if not isinstance(device, str) or not device.strip():
                raise ValueError("invalid device_id")
            raw_ts = row.get("ts")
            if not isinstance(raw_ts, str):
                raise ValueError("invalid ts")
            try:
                ts = datetime.fromisoformat(raw_ts.replace("Z", "+00:00"))
            except ValueError:
                raise ValueError("invalid ts") from None
            if ts.tzinfo is None or ts.utcoffset() is None:
                raise ValueError("ts requires timezone")
            value = row.get("value")
            if type(value) not in (int, float):
                raise ValueError("invalid value")
            if isinstance(value, float) and not isfinite(value):
                raise ValueError("invalid value")
            ts = ts.astimezone(timezone.utc)
            if device not in latest or ts >= latest[device][0]:
                latest[device] = (ts, value)
        except ValueError as error:
            errors.append({"index": index, "reason": str(error)})
    result = [
        {"device_id": device,
         "ts": ts.isoformat().replace("+00:00", "Z"),
         "value": value}
        for device, (ts, value) in sorted(latest.items())
    ]
    return {"records": result, "errors": errors}
```

期望输出：

```json
{"records":[{"device_id":"A","ts":"2026-09-16T00:01:00Z","value":2},{"device_id":"B","ts":"2026-09-16T00:00:00Z","value":3}],"errors":[{"index":3,"reason":"invalid value"}]}
```

共有 n 条记录、k 个设备时，时间复杂度为 O(n + k log k)，额外空间为 O(k + e)，e 为错误记录数。测试空输入、非字典、缺字段、不带时区、不同偏移的等价时间、相同时间覆盖、非法数值。生产使用需固定允许的时间格式，并增加输入大小限制。

**评分要点**：正确理解契约；错误可定位；实际运行边界测试；能吸收面试官反馈。

### 30｜根据配置和日志修复部署故障

难度：基础｜建议：15 分钟｜来源：原创题，S1 现场实践形式参考

**题干**

Docker Compose 中应用服务名为 `app`，数据库服务名为 `db`，两者在同一网络。数据库已就绪，监听 5432；宿主机没有安装数据库。应用配置如下：

```text
DATABASE_HOST=localhost
DATABASE_PORT=5432
日志：connect ECONNREFUSED 127.0.0.1:5432
```

请解释原因、给出修复和验证流程。如果修改后变为认证失败，又说明什么？

**参考答案**

应用容器中的 localhost 指向应用容器自身，不是数据库容器。数据库主机应改为可在 Compose 网络解析的服务名 `db`，端口使用数据库容器内的 5432。

从应用容器验证服务名解析与 TCP 连接，更新配置并重新创建需要加载新配置的应用容器，再运行数据库健康及业务读写检查。不能只改宿主机环境而假定运行中的容器自动生效。

认证失败说明已经连接到一个数据库端点，应进一步确认目标实例、账号、口令、库名及权限，而不是继续修改网络。启动顺序也不保证就绪，应配置健康检查和有上限的连接重试。日志和演示中不得输出真实口令。

**评分要点**：准确理解容器网络；验证配置生效；根据新错误调整假设。

### 31｜SQL：找出每台设备的最新有效读数

难度：进阶｜建议：15 分钟｜来源：原创，S3 SQL 分类参考

**题干**

PostgreSQL 有表 `readings(id BIGINT PRIMARY KEY, device_id TEXT, measured_at TIMESTAMPTZ, value NUMERIC, quality TEXT)`。前三个业务字段均非空，质量 `good` 表示有效；同一时间以更大的 id 为准。返回每台设备最新的有效读数，不返回从未有有效读数的设备。请写 SQL，并讨论数据量增大后的优化。

**参考答案**

```sql
SELECT device_id, measured_at, value
FROM (
    SELECT id, device_id, measured_at, value,
           ROW_NUMBER() OVER (
               PARTITION BY device_id
               ORDER BY measured_at DESC, id DESC
           ) AS rn
    FROM readings
    WHERE quality = 'good'
) AS ranked
WHERE rn = 1
ORDER BY device_id;
```

先过滤有效数据再排名；如果先选最新再判断质量，会漏掉“最新一条无效，但前一条有效”的设备。时间并列时用 id 保证结果确定。

可以评估 `(device_id, measured_at DESC, id DESC)` 且条件为 `quality = 'good'` 的部分索引，结合执行计划和实际负载判断收益。索引不保证避免扫描所有有效历史数据；如果查询频繁且历史巨大，可维护经过事务或可对账更新的最新状态表，同时保留原始历史。必须约定迟到数据处理与状态重建方式。

**评分要点**：过滤和排名顺序正确；并列有规则；优化考虑写入代价与实际执行计划。

### 32｜综合：两周交付一个内网工厂试点

难度：综合｜建议：30 分钟｜来源：原创题，S1 Decomposition 形式与 S4 职责参考

**题干**

客户有一台 24GB 显存 GPU 服务器、三台操作终端，生产网不能访问互联网。你们提供订单解析产品，需要读取 ERP 导出的 Excel，辅助操作员生成生产指令。客户要求两周试点，宣称“准确率至少 99%”。第 5 天发现一部分 Excel 格式与样本不同；第 8 天产品的新模型版本发布。请提出方案、排期、变更处理和验收标准。

允许候选人提问。面试官按需补充：每天约 2,000 单，峰值集中在一小时；现场不允许自动写 ERP；关键字段错误会造成材料损失；客户可安排两名操作员参与试点；IT 可提供测试目录及部署账号。

**参考答案**

1. **澄清与限定目标。** 确认每小时峰值、单据长度、现有人工耗时、字段和异常类型。把 99% 拆成订单级或字段级指标，约定样本范围和关键错误的处理；不能默认“99% 总体正确”就可以无人复核。试点仅生成待人工确认的指令，不自动写回 ERP。
2. **方案。** 内网部署固定版本的软件和模型，建立受控文件导入、字段校验、模型解析、业务规则校验、人工复核和结果导出流程。每条结果关联原文件、订单标识、版本和复核状态。按原单据标识做重复导入处理，权限按角色配置。
3. **硬件验证。** 24GB 显存不是可用性保证；用真实样本测试候选模型、上下文和并发，测量延迟与队列积压。设置队列容量、超时和人工处理兜底。服务器资源不足时减少试点范围或选择经评估合格的较小模型，而不是直接承诺承载能力。
4. **排期。** 第 1—2 天确认范围、样本和验收；第 3—4 天完成离线部署与基础流程；第 5—7 天做集成及代表性测试；第 8—10 天由两名操作员试用、记录错误并修复；最后阶段进行验收、恢复演练和交接。任一前置依赖未满足时调整计划并同步责任人。
5. **第 5 天变化。** 收集新增格式的出现频率及影响，补充独立测试样本，验证是否能通过配置映射支持。不能可靠解析的文件明确转人工；若超出范围，向客户提出范围或时间变更。不能悄悄丢弃异常订单。
6. **第 8 天版本。** 不因“新版本”而直接更新现场。比较修复收益、回归结果和部署兼容性；试点临近验收优先保持已验证基线。必须升级时在测试环境完成同一评估集与回退验证，征得变更负责人同意。
7. **验收与运营。** 明确准确性口径、关键错误、复核比例、目标负载延迟、订单完整性、权限、日志和恢复目标。保留样本及结果证据，培训客户独立操作，约定告警、支持和后续改进责任。失败或低信心结果可见且可接管。

**评分要点**：主动提问；方案与限制一致；AI 效果和工程可靠性一起验证；能处理变化并完成客户交接。

## 面试官评分与组卷

### 单题评分：0—4 分

| 分数 | 可观察表现 |
| --- | --- |
| 0 | 无法给出可执行思路，或在提示后仍坚持明显越权、破坏数据的做法 |
| 1 | 会列术语，但缺少执行顺序、证据或验证方法 |
| 2 | 能完成主要步骤，在提示下补齐关键边界，适合有人指导的交付 |
| 3 | 能独立提出执行与验证方案，并说明失败路径、责任和取舍 |
| 4 | 在 3 分基础上，能量化约束、优先处理关键风险，并沉淀可复用能力 |

记录“候选人说了什么、做了什么、是否经提示”，不要只记录印象。未考察标记 N/A，不能计为 0。合理使用官方文档和 AI 工具可以允许，但候选人必须解释并验证输出；所有人使用相同规则。

### 建议 90 分钟组卷

| 环节 | 选题 | 时间 |
| --- | --- | ---: |
| 真实项目深挖 | 28 | 10 分钟 |
| 需求与验收 | 01、05 | 10 分钟 |
| 现场部署与排障 | 07、08、30 | 25 分钟 |
| 编程或数据集成 | 29 或 31 | 20 分钟 |
| 综合方案 | 32，压缩为核心问题拆解 | 20 分钟 |
| 候选人提问 | 说明岗位现场要求与支持边界 | 5 分钟 |

90 分钟只能完成初筛。若需要独立硬件交付，追加实际设备操作；若涉及 AI 自动执行业务动作，追加 20、21、22；若承担长期生产运维，追加 16、17、18。不要将所有 32 题一次问完。

### 评分使用建议

先明确岗位级别，再看各能力证据。初级重点是基础部署、学习能力、问题报告与安全执行；独立交付要求需求、部署、排障、沟通和验收均有独立执行证据。用总分可辅助比较同一套题的候选人，但不能用其他题的高分抵消关键能力未验证。

本题库不是经过统计验证的招聘测评，不设置看似精确的录用分数线。建议将结果写为“已验证能力／需要带教的部分／尚未验证的部分”，结合实际工作样本和面试官讨论决定岗位范围。不得用年龄、性别、学历标签或 GitHub 分数代替岗位能力证据。
