FDE 面试题库

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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}

期望输出：

{"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 为错误记录数。测试空输入、非字典、缺字段、不带时区、不同偏移的等价时间、相同时间覆盖、非法数值。生产使用需固定允许的时间格式，并增加输入大小限制。

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

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

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

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' 的部分索引，结合执行计划和实际负载判断收益。索引不保证避免扫描所有有效历史数据；如果查询频繁且历史巨大，可维护经过事务或可对账更新的最新状态表，同时保留原始历史。必须约定迟到数据处理与状态重建方式。

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