网易易盾·交付实施工程师 面试准备稿
面试时间：2026/05/25 19:00 | 腾讯会议：775-820-951 面试官：直属领导，关注经验真实性 + 技术基本功
一、自我介绍（2 分钟版）
口语化，有层次：是谁 → 做什么 → 怎么做 → 代表项目 → 为什么来
"我在华为担任HCS产品技术TD，累计 6 年原厂交付经验。TD 是项目全生命周期的技术责任人，从前期需求调研、方案规划，到中期现场实施，再到试运行转维，技术侧全程由我主导，累计交付了 50 多个政企云项目，覆盖政务、电力、金融等行业。
技术方向上，我交付的是华为私有云全栈，IaaS 到 PaaS 全覆盖——底层是 KVM 虚拟化加 OpenStack，容器平台是 K8s，中间件、大数据平台也在交付范围内。监控告警体系构建、故障定位排查、自动化运维脚本开发，在多个项目中均有实际落地。
代表项目是去年 3 月的衢州市政务大模型，基于 DeepSeek-R1，在昇腾 NPU 集群上完成多机推理部署，我从方案规划到现场交付全程主导，完成 W8A8 量化、动态批处理和 RDMA 通信优化，推理性能达到政务并发场景要求，现已稳定接入 13 个政府部门，是国内较早落地的政务大模型工程化案例。
我来面试这个岗位，是因为易盾的交付实施工作与我过去的核心职责高度吻合——在客户私有云环境中完成复杂系统的部署交付、稳定运行保障和故障快速响应。产品形态不同，但这套交付方法论和运维能力可以直接复用。"
二、必备技能逐条准备
技能 1：Kubernetes 集群管理及故障排查
一句话定位：交付过多套 CCE 集群，在交付阶段和驻场支持期间处理过 Pod 调度、网络策略、存储、日志等各类故障。
案例 A：PVC 挂载失败导致服务无法启动（衢州政务云，2023/12）
S：政务云某应用上线后，Pod 反复重启，日志显示启动时读取配置文件失败。 T：定位根因，当天恢复，否则影响政务应用上线节点。 A：先看 Pod 事件，发现
MountVolume.SetUp failed，PVC 处于 Pending 状态。检查 PVC 的 StorageClass，发现引用的 StorageClass 名称拼写错误（csi-disk写成了csi-disk-s），导致找不到对应的 provisioner，PV 一直无法动态创建。修正 StorageClass 名称后，PV 自动创建，PVC 绑定成功。但服务还是起不来——再看容器日志，发现挂载路径下的配置文件读取报Permission denied。容器用的是非 root 用户（uid=1000）运行，但挂载进来的文件属主是 root。在 Pod 的securityContext里加了fsGroup: 1000，K8s 会在挂载后自动把卷的属组改为该 GID，容器就能读到了。重新部署后正常。 R：服务正常启动。事后把 StorageClass 名称校验和 securityContext 配置列入了应用上云检查清单的必检项。
案例 B：容器网络策略冲突（衢州政务云，2023/12）
S：某政务应用上云后，服务间调用偶发超时，但单独测试每个服务都正常，重启 Pod 后短暂恢复，过一会儿又超时。 T：定位跨命名空间调用失败的根因，现象是间歇性的，难以复现。 A：先用
kubectl exec进容器，直接 curl 对端服务的 Pod IP（不是 ClusterIP，NetworkPolicy 作用在 Pod IP 层面），发现不通，排除了应用层问题，确认是网络层拦截。检查两个 namespace 的 NetworkPolicy，发现默认策略是 deny-all，只给同 namespace 开了 ingress，跨 namespace 的流量被拦截。但奇怪的是为什么间歇性——进一步排查发现，部分 Pod 有时会被调度到同一个节点，而这套 CCE 集群的 CNI 配置下，同节点 Pod 通信走节点内部转发路径，NetworkPolicy 的 ingress 规则在这条路径上没有生效，所以偶尔能通。修改 NetworkPolicy，在 ingress 规则里增加对调用方 namespace 的 namespaceSelector，确保无论同节点还是跨节点都走统一的策略，问题彻底解决。 R：调用稳定，整理成故障排查指南的典型案例，后续 ISV 上云前必须提交 NetworkPolicy 配置审核。
常见追问准备：
kubectl get events --sort-by=.lastTimestamp -A看全集群事件- 存储问题排查顺序：PVC 状态 → StorageClass 是否存在 → provisioner Pod 日志 → 节点上
mount命令验证 - 日志采集不到：先确认 Filebeat DaemonSet 是否在该节点运行，再看
/var/log/containers下是否有对应软链接
技能 2：Java 微服务架构排查
一句话定位：在政务云和警务云项目中，负责 ISV Java 应用容器化上云的运维支持，处理过启动失败、调用异常、内存泄漏等问题。
案例：服务调用超时 + 内存持续增长（衢州政务云）
S：政务云某 Java 微服务上线一周后，开始出现接口偶发超时，同时监控显示该服务的内存使用量每天稳定增长，重启后恢复，但过几天又涨上来。 T：定位根因，不能靠重启掩盖问题，需要彻底解决。 A：分两条线排查。 超时线：用 SkyWalking 看链路，发现超时集中在调用下游数据库的 Span，耗时从正常的 20ms 涨到 3s 以上。看数据库慢查询日志，发现一条没有走索引的全表扫描 SQL，在数据量增长后越来越慢。加索引后超时消失。 内存线：通过 Prometheus 的 JVM 指标（
jvm_memory_used_bytes，应用侧暴露了 actuator/metrics）观察 heap 使用趋势，发现 Old 区持续增长，Full GC 频率越来越高但回收效果越来越差，典型的内存泄漏特征。生产容器只有 JRE，jmap/jstat 这些 JDK 工具用不了——用docker inspect --format '{{.State.Pid}}' <container_id>拿到容器在宿主机上的 PID，再用宿主机的jmap -dump:format=b,file=/tmp/heap.hprof <PID>导出堆快照，kubectl cp拷出来。用 MAT 分析，发现是一个本地缓存 Map 没有设置容量上限，业务数据一直往里塞，从不清理。修改代码改用 LRU Cache 并设置最大容量，问题解决。 R：接口超时消除，内存稳定在合理水位不再增长。事后把"慢 SQL 检查"和"JVM 堆分析"列入了上线前的性能验收标准。
常见追问：
- 服务启动失败：先看
kubectl logs --previous看上次退出日志，再看 liveness probe 的initialDelaySeconds是否给够启动时间 - 调用 4xx：看请求参数是否符合接口契约；调用 5xx：看服务端异常堆栈
- 线程池打满：
jstack看线程状态，找 BLOCKED 的线程在等什么锁
技能 3：中间件部署调优与故障排查
一句话定位：在多个项目中负责 MySQL、Redis、Elasticsearch、Kafka、ZooKeeper 的部署和故障处理。
案例 A：MySQL 慢查询导致业务超时（衢州政务云，2023/12）
S：政务云某业务系统上线后，高峰期接口响应时间从正常的 200ms 涨到 5s 以上，数据库服务器 CPU 飙到 90%。 T：定位慢查询根因，恢复正常响应，不能重启数据库影响业务。 A：先开启慢查询日志（
slow_query_log=ON，long_query_time=1），收集 10 分钟后用mysqldumpslow分析，找出执行次数最多的几条慢 SQL。其中一条是带LIKE '%keyword%'的模糊查询，前缀通配符导致索引失效，全表扫描；另一条是多表 JOIN 没有走索引，用EXPLAIN看执行计划，发现 type 是ALL。处理方式：模糊查询场景，如果是英文内容改用全文索引（FULLTEXT INDEX），中文场景需要配置 ngram 分词器（ft_min_word_len=2），或者从业务侧改造，把高频搜索词提前建立倒排索引表；JOIN 查询在关联字段上加复合索引，EXPLAIN验证 type 变为ref。同时检查连接池配置，发现max_connections设的是默认值 151，高峰期连接数打满，用SET GLOBAL max_connections = 500在线修改（同时更新 my.cnf 防止重启失效），并配置连接超时回收（wait_timeout和interactive_timeout从默认 8 小时改为 600 秒）。 R：接口响应时间恢复正常，CPU 降回 30% 以下。事后把慢查询监控和 EXPLAIN 分析列入了上线前的 SQL 审查流程。
案例 B：Elasticsearch 跨版本兼容问题（衢州警务云）
S：警务云迁移时，原有 ES 6.x 的索引数据需要迁移到新环境 ES 7.x，迁移后查询报错。 T：保证数据可用，不能丢失历史数据。 A：报错是
mapper_parsing_exception，原因是 ES 7.x 移除了_type字段，6.x 的索引 mapping 里有 type 定义，直接导入不兼容。分两步处理：存量历史数据用elasticdump导出成 JSON 文件，用 Python 脚本批量处理每条记录，把_type字段从 JSON 里删掉，再重新导入；新索引用index template提前定义好不含 type 的 mapping，用reindexAPI 从旧索引重建。两条路并行，历史数据不丢，新数据结构也对齐了。 R：数据完整迁移，查询恢复正常。
案例 C：Redis 内存告警处理
S：政务云监控告警，Redis 内存使用率达到 85%，接近 maxmemory 上限。 T：防止触发 OOM 导致服务不可用。 A：先用
redis-cli info memory查看内存分布，确认used_memory接近maxmemory。找大 key 时没有直接用--bigkeys（生产环境全量扫描有性能风险），而是用redis-cli --scan --count 100分批抽样，配合object encoding和debug object估算 key 大小，定位到几个 session 缓存 key 没有设置 TTL，一直累积。同时检查maxmemory-policy，发现设的是noeviction（不淘汰），改为allkeys-lru；对没有 TTL 的 key 用 Lua 脚本批量扫描并设置过期时间，避免一次性操作阻塞。 R：内存使用率降到 60% 以下，告警消除。
Kafka 常见问题准备：
案例：Kafka 消费积压排查（电力云项目）
S：电力云大数据平台监控告警，某 Kafka topic 的消费 lag 持续增长，已经积压了几十万条消息，下游数据处理延迟越来越大。 T：定位积压原因，恢复正常消费速度。 A：先用
kafka-consumer-groups.sh --describe查看各分区的 lag 分布，发现 lag 集中在几个特定分区，其他分区正常。说明不是消费者整体能力不足，而是这几个分区的消费者出了问题。查消费者日志，发现这几个分区对应的消费者线程在处理某类特殊格式的消息时抛了异常，但异常被 catch 住了没有退出，导致这条消息反复重试、卡住，后续消息全部积压。修复方式：对无法解析的消息记录日志后跳过，发到死信队列，不阻塞主流程。同时增加了消费 lag 的告警规则，超过阈值立即通知。 R：积压消息在 2 小时内消化完毕，后续再没出现类似积压。
ZooKeeper 常见问题：
- 客户端连接超时：先看 ZK 节点的
zk_avg_latency，再看 JVM GC 是否有 Stop-the-World 停顿导致心跳超时 - 连接数打满：
echo stat | nc zk-host 2181看当前连接数，排查客户端是否有连接泄漏
HBase / MinIO 基本认知（JD 必备项，如被问到）：
- HBase：列式存储，适合海量稀疏数据的随机读写。常见问题：Region 热点（rowkey 设计不合理导致写入集中在单个 Region Server），排查用 HBase Web UI 看各 Region Server 的请求分布；Region 分裂频繁说明数据增长快，可以预分区。部署依赖 ZooKeeper 做协调，ZK 不稳定会直接影响 HBase。
- MinIO：对象存储，兼容 S3 API。常见问题：大文件上传超时，需要开启分片上传（multipart upload）；磁盘使用不均衡，检查各节点的
mc admin info看存储分布；纠删码配置（EC）决定容错能力，4+2 表示 4 个数据块 + 2 个校验块，允许 2 个节点同时故障。
技能 4：容器网络 / Linux 网络排查
一句话定位：处理过 K8s 跨节点通信、iptables 规则冲突、DNS 解析失败等问题。
案例：跨节点 Pod 通信不通（电力云项目）
S：电力云新扩容了 3 个 K8s 工作节点，扩容后新节点上的 Pod 无法访问其他节点的 Pod，但同节点 Pod 之间通信正常。 T：定位网络不通原因，恢复跨节点通信，不能影响存量业务。 A：分层排查。 第一层：在新节点上 ping 其他节点的宿主机 IP，通；ping 其他节点上 Pod 的 IP，不通。说明物理网络没问题，是 overlay 网络的问题。 第二层：检查新节点上的路由表
ip route，发现没有 Pod 网段（10.244.x.x/24）的路由条目，其他老节点上有。说明新节点没有加入 overlay 网络的路由同步。 第三层：查 CNI（Calico）的 Pod 日志，发现新节点上的 calico-node Pod 处于 CrashLoopBackOff。看日志报错：bird: Unable to open configuration file，原因是扩容时新节点的 hostname 格式和集群其他节点不一致（其他节点是node-001格式，新节点是完整 FQDN），Calico 的 BGP 配置模板里用 hostname 做了节点标识，格式不匹配导致 bird 进程启动失败，路由无法建立。修正新节点的 hostname 格式与集群保持一致，calico-node 重启后正常，路由自动同步。 R：跨节点通信恢复正常。事后把"扩容节点后验证 CNI Pod 状态"列入了扩容操作 SOP 的必检步骤。
iptables 排查思路：
- Service 不通先确认 Endpoints 是否正常：
kubectl get endpoints <svc-name>，如果 Endpoints 为空说明 selector 没匹配到 Pod - 再看 iptables：
iptables -t nat -L KUBE-SERVICES -n确认 ClusterIP 的 DNAT 规则是否存在 - 如果规则存在但还是不通，看 kube-proxy 日志是否有报错
DNS 排查：
- Pod 内
nslookup kubernetes.default验证 CoreDNS 是否正常 - CoreDNS 解析失败先看 Pod 的
/etc/resolv.conf里 nameserver 是否指向 CoreDNS 的 ClusterIP kubectl logs -n kube-system -l k8s-app=kube-dns看 CoreDNS 是否有 upstream 解析失败
技能 5：Ansible 批量部署与配置管理
一句话定位：在政务云项目中，针对客户自建的业务虚机，用 Ansible 做批量配置核查、合规巡检和变更下发。华为云服务组件有官方巡检工具覆盖，Ansible 主要用在客户自建业务系统层面。
案例：客户业务虚机合规巡检（衢州政务云，2023/12）
S：政务云上跑着几十台客户自建的业务虚机，等保审计前需要对这些虚机做合规检查，包括内核参数基线、时钟同步状态、磁盘水位、关键业务进程存活等。这些虚机不在华为官方巡检工具的覆盖范围内，之前全靠人工逐台 SSH 检查，一次要花大半天，而且容易遗漏。 T：把这部分巡检自动化，输出标准化报告，支撑等保审计。 A：用 Ansible 写了一套巡检 Playbook，对所有业务虚机并发执行：用
sysctl模块检查内核参数是否符合基线（net.ipv4.tcp_syncookies、vm.swappiness等），用systemd模块检查关键业务服务运行状态，用shell检查磁盘水位和 NTP 同步状态。结果通过register收集后，用 Jinja2 模板渲染成 HTML 报告，不合规项高亮标红，自动发给运维负责人。 R：巡检时间从大半天压到 10 分钟，覆盖率 100%。等保审计前直接拿报告，审计人员反馈规范性明显提升。这套 Playbook 后来作为交付物留给客户，他们自己维护基线配置项。
常见追问：
- Playbook 幂等性：用声明式模块（
sysctl、service、file）而不是直接 shell，重复执行结果一致 - 敏感变量：用
ansible-vault encrypt_string加密后存入变量文件，运行时解密，不明文存密码 - 执行失败处理：关键变更步骤用
block/rescue结构，block 里做操作，rescue 里把备份还原回去
技能 6：监控方案（ELK + SkyWalking + Prometheus + Grafana）
一句话定位：主导构建过统一监控告警体系，设置 200+ 项告警阈值，覆盖 ELK 日志、Prometheus 指标、SkyWalking 链路三个维度。
案例：监控体系从零构建 + 告警风暴治理（衢州政务云，2023/12）
S：政务云上线前没有统一监控，出了问题靠人工发现，平均故障发现时间超过 30 分钟。搭完监控之后又出现了新问题——一旦某个核心服务挂掉，几十条告警同时触发，运维人员根本看不过来，反而更乱。 T：构建统一可观测体系，同时解决告警风暴问题，让告警真正有用。 A：分两阶段做。 第一阶段搭体系：Prometheus + node-exporter 采主机指标，kube-state-metrics 采 K8s 对象状态，Filebeat → Kafka → Logstash → ES 做日志链路，设了 200 多条告警规则覆盖基础设施和应用层。 第二阶段治告警：发现告警风暴的根因是没有做告警抑制。在 AlertManager 里配置了两个关键规则：一是
group_by按服务名聚合，同一服务的告警合并成一条；二是inhibit_rules做根因抑制，比如数据库连接池打满这条根因告警触发后，自动压制下游的接口超时、业务失败等衍生告警，运维人员只看到一条根因，不被几十条衍生告警淹没。 R：故障发现时间从 30 分钟降到 3 分钟，告警数量减少约 60%，运维团队反馈"终于能看懂告警了"。
SkyWalking 使用经验：
- Java 应用加
-javaagent:skywalking-agent.jar启动，无需改代码 - 链路追踪主要用于定位跨服务调用慢的问题，看哪个 Span 耗时最长
- 生产环境建议采样率设 20-30%，不要全量采样，否则 OAP Server 压力大
技能 7：Python 和 Shell 脚本
一句话定位：编写过巡检脚本、日志分析脚本、自动化部署脚本，在多个项目中实际落地使用。
案例：Python 日志异常分析脚本（衢州政务云）
S：政务云运维期间，ES 里每天有大量日志，运维团队需要人工翻日志找 ERROR，效率很低，而且容易漏掉低频但重要的异常。 T：自动化识别日志中的异常模式，主动推送给运维团队。 A：写了一个 Python 脚本，每小时通过 ES 的 REST API 用
terms aggregation查询最近一小时内level=ERROR的日志，按error_code和service字段分组统计各类异常的出现次数。把这次的统计结果和上一小时的结果做对比，如果某个 error_code 的数量增长超过设定倍数（比如 3 倍），或者是首次出现的新异常类型，就触发推送。通过企业微信 Webhook 发送告警，消息里附上异常摘要和 Kibana 的跳转链接，运维人员点链接直接看原始日志上下文。 R：运维团队不再需要每天手动翻日志，低频但重要的异常也能被捕捉到。有一次就是靠这个脚本提前发现了某服务的数据库连接异常，在影响用户之前就处理掉了。
Shell 脚本典型场景：
- 部署脚本：拉取新版本镜像 → 备份当前配置 → 滚动重启 → 健康检查，失败自动回滚
- 日志定期清理，配合 crontab，防止磁盘打满触发告警
- 批量远程巡检，循环读取主机列表 ssh 执行检查命令，汇总输出
技能 8：公有云平台（华为云 / 阿里云 / 移动云）
一句话定位：6 年华为云原厂经验，深度使用华为云 Stack IaaS/PaaS 全栈；也接触过阿里云基础服务。
如果被问"用过哪个印象最深"：
"华为云用得最深。私有云场景下，从底层 OpenStack 的 Nova/Neutron/Cinder，到上层的 CCE、RDS、DMS、ROMA，基本都用过。印象最深的是 ROMA Connect，在警务云项目里用它做业务总线，把本地的计算、服务、数据资源统一管理，同时对接奇安信零信任做自定义鉴权。踩过一个坑：ROMA 的 API 网关在做 Token 鉴权时，零信任侧返回的 Token 格式和 ROMA 默认期望的 Bearer Token 格式不一致，导致鉴权一直失败。排查了很久，最后发现需要在 ROMA 的自定义鉴权函数里手动解析 Token Header，提取出零信任的 session_id 再去验证，绕过了默认的 Bearer 解析逻辑，才跑通。阿里云相对用得少，主要是 ECS、RDS、OSS 这些基础服务，在对接外部系统时接触过。"
三、加分项准备
GPU 虚拟化方案
直接经验是昇腾 NPU 侧：DeepSeek 项目里配置过 K8s 的 NPU 资源调度，在 Pod 的
resources.limits里声明huawei.com/Ascend910，通过华为的 device plugin 实现 NPU 资源的分配和隔离。昇腾也支持 vNPU 切分，把一张物理 NPU 切成多个虚拟实例，每个实例有独立的算力和显存配额，适合多租户推理场景，原理和 NVIDIA MIG 类似。NVIDIA 方案了解 MIG（Multi-Instance GPU）：A100/H100 支持，最多切 7 个实例，每个实例有独立的 SM、显存、缓存，互相隔离，故障不互相影响。GPU Operator 是 K8s 上管理 GPU 资源的 Operator，自动安装驱动、配置 device plugin、管理 MIG 切分策略，不需要手动在每个节点上操作。如果被问到 vGPU 和 MIG 的区别：MIG 是硬件级隔离，性能确定性强；vGPU 是软件虚拟化，灵活但有调度开销。
LLM 推理服务部署经验
这是核心加分项，直接引用 DeepSeek 项目： "我在 2025 年 3 月主导了衢州市政务大模型项目，DeepSeek-R1 671B 参数，基于 K8s 管理推理容器，做了 W8A8 量化、动态批处理、RDMA 通信优化，推理吞吐量提升约 40%，首 Token 延迟降低约 30%。这是国内较早落地的政务大模型工程化案例。"
四、STAR 案例库
✅ 成功的案例 / 骄傲的项目
昇腾超节点 CloudMatrix 384 交付
S：2025 年，我主导了一个昇腾 CloudMatrix 384 超节点的全流程交付项目。规模是 384 张昇腾 910C 芯片，12 个计算机柜加 4 个 Scale-Up 交换柜，总共 19 个机柜，总算力 307 PFLOPS。这是当时国内规模最大的昇腾超节点交付之一，客户要用它跑大模型训练和推理，验收标准参照华为 384 超节点验收白皮书，指标非常严格。 T：11 周完成全部交付，性能指标全部达标才能签收。核心压力有两块：一是 6912 个 400G 光模块的部署和验收，光功率和误码率要求严苛；二是软件栈的版本配套，CANN、驱动、固件三者必须严格绑定，任何一个版本不对都会导致模型加载失败。 A：我把整个交付分成五个阶段推进。 硬件阶段，最关键的是光模块验收。6912 个模块不可能逐一全测，我们按批次抽样，用
ethtool -m检查每个端口的光功率，发送端要在 -1~+3dBm 之间，接收端要高于 -10dBm，误码率要求 ≤1e-12。同时用npu-smi info -t health逐卡做健康检查，ib_write_bw和ib_read_lat测 RoCEv2 的带宽和时延，确认 Scale-Up 全光互联链路没有问题。 软件栈阶段，我们严格按版本配套矩阵来：驱动 V23.0.rc1 → 固件 ≥6.4.0.5.220 → CANN 6.0.RC1 → MindSpore 3.0，顺序不能乱，版本不能混。中间遇到一个问题：某台节点的 CANN 安装后npu-smi info报算子不支持，排查发现是固件版本比要求的低了一个小版本，升级固件后恢复正常。这让我们意识到版本矩阵必须逐节点核查，不能只看批量部署脚本的返回码。 容器化推理部署用的是 MindIE Motor，Prefill 和 Decode 分离部署，通过 Volcano 调度器的 Gang Scheduling 做原子调度，确保多卡任务要么全部分配到位要么全部等待，避免部分卡分配导致死锁。AscendJob 的 CRD 里声明huawei.com/Ascend910资源，由 Ascend Device Plugin 负责实际的 NPU 分配和隔离。 性能验收阶段，用ascend-dmi -f -i 0测单卡算力，FP16/BF16 要达到 ≥32 TFLOPS；集合通信用 HCCL 测试工具，AllReduce 带宽要 ≥700 GB/s，时延 ≤200 ns；模型训练跑 DeepSeek-V3 671B，128 节点规模，线性加速比要 ≥0.75；最后是 72 小时连续运行稳定性测试，0 故障才算通过。 R：11 周按期交付，全部性能指标达标。DeepSeek-R1 70B 的训练迭代速度比 H100 集群提升约 1.8 倍，推理侧开启动态 CP/DP 技术后，变长序列场景吞吐提升约 40%。这个项目让我对昇腾超节点的全链路交付有了完整的经验积累，从硬件验收到软件栈到性能调优，每个环节都踩过坑、沉淀了 SOP。
衢州政务大模型（DeepSeek-R1）
S：2025 年 3 月，衢州市数据局要上线政务 AI 助手，基于 DeepSeek-R1 671B 模型，硬件是昇腾 910B NPU 集群，是国内较早做政务大模型工程化的项目。 T：在 3 周内完成多机推理部署，并达到政务场景的并发要求。 A：我负责整体交付规划。硬件分批到货，先用 W8A8 量化跑通服务保障业务连续性；满配后切回 BF16 满血部署。期间遇到一个关键问题：推理服务启动后模型加载报错，提示 weight shape mismatch。排查发现是 CANN 版本和模型权重格式不匹配——模型权重是用新版 CANN 导出的，但环境里装的是旧版 CANN，两个版本对某些算子的权重排布格式定义不一样。解决方式：联系华为产品团队确认兼容矩阵，升级环境 CANN 版本并打对应补丁，重新加载权重后正常。同时部署 Prometheus+Grafana 监控推理吞吐量、首 Token 延迟、NPU 利用率，作为验收基线。 R：推理吞吐量提升约 40%，首 Token 延迟降低约 30%。"衢州 AI"政务助手上线后接入 13 个政府部门，覆盖公文写作、知识库问答等核心场景。这是我做过最有成就感的项目，因为它是真正落地的 AI 工程化实践。
❌ 失败的案例
浙能智云升级引发 EIP 业务中断
S：2025 年 3 月，浙江省能源集团私有云平台执行 HCS 803 → 810 管理面升级，升级过程中客户反馈 EIP 业务全面中断。 T：生产环境，客户压力大，需要在不影响其他业务的前提下分钟级恢复，同时找到根因。 A：我从业务层往下逐层排查。先查 br 网元的 IPVS 转发表（
egf-ipvsadm -Ln），发现所有后端 Weight=0，说明问题在更底层。再查网络节点的 OVS-DPDK bond 状态（ovs-appctl dpdk-bond/show），发现lacp_status: active configured（正常应为 negotiated），两个 slave 口may_enable: false，LACP 协商失败，bond 没有可用成员。用ethtool eth8查物理链路，显示Link detected: no，但 OVS 里 eth8 仍显示enabled——物理状态和 OVS 感知不一致，说明 DPDK PMD 没有捕获到链路变化。确认 OVS 服务本身正常后，执行systemctl restart openvswitch，PMD 重新初始化，bond 状态立即刷新，LACP 恢复 negotiated，业务恢复。事后查 osConfig 日志，发现升级脚本在故障时间点通过 sysfs 将网卡roce_enable从 1 写为 0，触发了 HP 定制版 Mellanox 固件（ethtool -i可见 firmware 带 HP_ 前缀）的重新初始化，这是原厂卡没有的行为，实验室未覆盖该场景。 R：业务分钟级恢复，0% 丢包验证通过。事后推动升级脚本在 sysfs 配置变更后增加 bond 状态检查点，并将定制硬件固件扫描列入升级前置检查项。这次让我意识到：定制硬件的"隐性行为差异"比功能 bug 更难防，必须在升级前主动识别非标准硬件。
电力云版本升级变更事故
S：2023 年底，国网电力云需要从 HCS 8.0.2 升级到 8.3.1，跨大版本升级，涉及计算、存储、网络全栈组件。 T：要求在一个维护窗口（周末 8 小时）内完成升级，业务不中断。 A：升级过程中，存储组件升级完成后，发现部分虚拟机的磁盘 IO 出现异常，原因是新版本的存储驱动默认开启了一个新的 IO 调度策略，和旧版本行为不一致。当时没有在测试环境充分验证这个参数变化，直接在生产环境升级。发现问题后紧急回滚了存储驱动配置，但回滚过程中有几台虚拟机出现了短暂的 IO 中断，影响了部分业务。 R：最终恢复正常。这次让我认识到：跨大版本升级必须在完全一致的测试环境做充分验证，特别是默认参数变化这种"隐性"变更最容易被忽略。事后我制定了"版本升级变更检查清单"，把新旧版本参数对比列为必检项，后续再没出现类似问题。
🔍 有趣的项目
Ansible 自动化改造（政务云运维提效）
S：2024 年初，政务云运维团队每次变更都要手动登录每台机器操作，一次批量配置变更要花半天时间，而且容易出错，客户对运维效率很不满意。 T：用自动化工具把重复性运维工作降下来，同时帮客户建立自主运维能力。 A：我花了 2 周时间，把最常用的运维操作写成 Ansible Playbook，针对的是客户自建的业务虚机，包括批量配置变更下发、业务服务重启、日志收集、合规巡检报告生成。做了简单封装让运维人员一条命令就能完成批量操作，同时把所有 Playbook 放到 GitLab 管理，每次变更都有记录可追溯。然后给客户运维团队做了培训，让他们自己能看懂、能改。 R：批量变更时间从半天压缩到 30 分钟，出错率接近零。更有意思的是，客户团队学会之后开始自己扩展 Playbook，逐渐从依赖原厂驻场转向自主运维，这正是我们交付的目标。
五、软性问题准备
职业发展方向
"我的方向是云原生交付和运维工程化。过去 6 年在华为做的是偏重架构规划和项目交付，接下来我希望在一个产品化的公司，把交付做得更标准、更可复制。网易易盾的私有云交付场景，客户多、环境复杂，正好是我想深耕的方向。"
为什么离职
"家庭原因，母亲身体出现状况需要手术，我是独子，需要在旁照顾处理，所以主动申请离职。目前家里情况已经稳定，可以全身心投入新工作，随时可以到岗。"
薪资期望
先反问："请问这个岗位的薪资范围大概是什么区间？" 了解对方预算后，再报区间，主动解释：上份是项目制结构，稳定性不如产品公司，现在优先考虑稳定性和长期发展。