网易易盾 二面 · 打印背诵版
一、自我介绍
"我有 10 年以上云计算与运维经验，其中 6 年在华为担任 HCS 产品技术 TD，服务电力、政务、金融等头部客户。TD 是项目全生命周期的技术责任人，从前期需求调研、方案规划，到中期现场实施，再到试运行转维，技术侧全程由我主导，累计交付了 50 多个政企云项目，沉淀了 33 项运维流程和 50 多份标准交付物。
技术方向上，IaaS 侧做过计算、存储、网络的规划和落地，PaaS 侧做过 CCE 容器平台、中间件、数据库的部署和调优，微服务这块也做过，服务治理、注册发现、链路追踪、灰度发布都有涉及。
代表项目是去年 3 月的衢州政务大模型，DeepSeek-R1 在昇腾 NPU 集群上的多机推理部署，我全程主导架构规划和落地，解决了昇腾驱动兼容性和跨节点 RDMA 通信等关键问题，3 周内完成交付，现已稳定接入 13 个政府部门。
AI 基础设施这块也做过，参与了运营商昇腾 CloudMatrix 384 超节点的交付，384 张昇腾 910C 芯片，灵衢总线全光互联架构，11 周按期完成，是当时国内规模比较大的昇腾算力集群交付项目之一。
我来面试易盾这个岗位，主要是觉得跟我过去做的事情比较接近——在客户环境里把系统部署好、稳定跑起来，出了问题快速响应。希望能在产品化的公司把交付做得更标准一些。"
二、案例 A · 衢州政务大模型
一句话：主导 DeepSeek-R1 671B 在昇腾 910B 集群上多机推理部署，3 周交付，接入 13 个政府部门。
挑战：
- CANN 版本与模型权重格式不兼容，weight shape mismatch，对照版本配套矩阵逐层排查
- 跨节点 RDMA 通信，RoCEv2 无损网络 PFC/ECN 参数调优
- 671B MoE 显存压力大，W8A8 量化分阶段上线，保障业务连续性
结果：推理吞吐提升约 40%，稳定接入 13 个政府部门，国内较早落地的政务大模型工程化案例。
二、案例 B · 昇腾 CloudMatrix 384 超节点
一句话：华为浙江代表处 TD，参与杭州滨江移动 384 张昇腾 910C 芯片超节点交付，负责客户侧协调、现场支持和验收跟进，11 周按期完成。
挑战：
- 灵衢总线（UnifiedBus）全光互联，7 个独立并行通信平面，每卡 7 个 400G 光收发器（单卡 2.8Tbps），光功率和误码率（≤1e-12）逐一验收
- CANN/驱动/固件三者版本严格绑定，任何一层不对导致算子不支持或性能劣化
- 验收标准：AllReduce 带宽 ≥700 GB/s、线性加速比 ≥0.85、72 小时连续运行 0 故障
我的角色：客户侧需求对接、现场协调、进度跟进；参与硬件验收（npu-smi 逐卡健康检查、ib_write_bw 验证 RoCEv2 带宽）；协调 AllReduce 带宽不达标排查。
结果：11 周按期交付，DeepSeek-R1 70B 训练迭代速度较 H100 提升约 1.8 倍，推理侧变长序列吞吐提升约 40%。
追问：为什么每卡 7 个 400G 光收发器
"7 不是随意定的，是灵衢总线 7 平面并行全互联拓扑决定的。灵衢不是传统单总线/树状交换，而是 7 个完全独立、并行的通信平面，做无阻塞全互联（Clos-like），单跳直达、百纳秒低时延。每个平面配 1 个 400G 光收发器，7 平面就是 7×400G=2.8Tbps，匹配昇腾 910 单卡 TB 级片间带宽，带宽匹配、无瓶颈。7 个平面还有冗余价值：任意 1 个平面/光模块故障，剩余 6 个自动接管，训练任务不中断。6 个不够冗余，8 个会增加功耗和成本，7 是性能/成本/冗余的工程最优解。"
三、抗压能力
"压力最大的一次是浙能智云升级引发 EIP 业务中断。生产环境，客户是省级能源集团，EIP 全面中断，客户现场负责人直接打电话过来，语气很急。
我当时的处理方式是：先稳住客户，告诉他我们已经在排查，给他一个 30 分钟的反馈节点；然后立刻开始分层排查，不慌不乱，从业务层往下逐层定位。最终 15 分钟内找到根因，重启 openvswitch 后业务恢复，比承诺的时间提前了一半。
事后复盘：如果升级前做了定制硬件的固件扫描，这个问题可以提前发现。我推动把这一项列入了升级前置检查清单。
高压场景下我习惯先给客户一个明确的时间节点，这样双方都知道下一步是什么，不会陷入干等的状态。"
追问：多任务并行怎么排优先级
"先看影响面，生产故障 > 上线节点 > 日常需求；再看可逆性，不可逆的操作优先确认再动手。遇到多任务并行时会先列出来，按影响面和紧急程度排序，逐一推进，不会同时开多个高风险操作。"
三、协调沟通 · 跨团队协调
"衢州警务云项目里，我需要同时协调华为产品线、客户 IT 部门、奇安信零信任团队三方。当时 ROMA 业务总线和奇安信零信任的 Token 鉴权格式不兼容，两边都说自己的实现是标准的，互相推责。
我的处理方式是：不站任何一边，先把问题拆解清楚——用抓包和日志把问题现象固化下来，让两边都看到同一份证据。然后组了一个三方技术对焦会，把问题定义清楚之后，两边很快找到了解决方案：在 ROMA 的自定义鉴权函数里做适配，绕过默认的 Bearer 解析逻辑。
跨团队协调卡住的时候，通常不是技术问题，是各方对问题的描述不一致。把问题用数据和日志固化下来，让大家看同一份东西，比开会争论有效得多。"
三、协调沟通 · 客户不合理需求
"有一次客户要求在没有测试环境的情况下直接在生产上做版本升级，理由是时间紧。我没有直接拒绝，而是把风险量化给他看——这个版本有几个已知的存储驱动变更，如果不验证直接上生产，一旦出问题回滚窗口只有 2 小时，影响的是 500 台虚机上的核心业务。
客户听完之后同意了先搭一个最小化测试环境验证关键路径。最后证明这个决定是对的，测试环境里确实发现了 IO 调度策略的兼容性问题，提前处理掉了。
不合理的需求不是直接说'不行'，而是把风险和代价说清楚，让客户自己做决定。大多数时候客户不是不讲理，只是信息不对称。"
三、复盘与总结能力
"最有价值的复盘是浙能智云 HCS 升级引发 EIP 业务中断那次。升级脚本把所有网卡的 roce_enable 从 1 写成 0，触发了 HP 定制版 Mellanox 固件的额外初始化流程，OVS-DPDK 的 PMD 没有感知到链路状态变化，LACP 协商卡在 configured 态，bond 没有可用成员，EIP 业务全面中断。
排查路径：先查 br 网元的 IPVS 转发表，发现所有后端 Weight=0；再查 OVS-DPDK bond 状态，lacp_status 是 configured 而不是 negotiated，两个 slave 口 may_enable 都是 false；再用 ethtool 查物理链路，Link detected: no，但 OVS 里端口还显示 enabled——这个矛盾直接锁定了根因。重启 openvswitch，15 分钟内业务恢复。
复盘时我直接承认：是我的升级前检查流程有漏洞——没有扫描现网硬件的固件版本，没有识别出 HP 定制卡和原厂卡的行为差异。
事后推动了三项改进：升级前用 ethtool -i 扫描所有网卡固件版本；升级脚本在 sysfs 写入后增加 ovs-appctl dpdk-bond/show 检查点；升级后建立网络健康检查 SOP，bond 状态、LACP 协商、网关 ping 三项全通才算升级成功。
复盘完了必须有 Action Items，每条要有负责人和 deadline，不然复盘就停在纸面上了。"
追问：怎么让团队受益
"把复盘结论转化成检查清单，放到团队共享的知识库里。这次的硬件固件扫描步骤和 bond 状态检查点，后来都写进了升级变更前置检查清单，后续再没出现类似问题。"
四、职业规划
"我的方向是云原生交付和运维工程化。过去 6 年在华为，积累了一套从方案设计到现场落地的完整方法论。
接下来 3-5 年，我希望在一个产品化的公司，把这套方法论用在更标准化的产品交付上——不是每次都从零开始设计，而是把交付做得更可复制、更高效。易盾的私有化部署场景，客户多、环境复杂，正好是我想深耕的方向。
长期来看，希望能在交付工程化方向上做出沉淀，不管是标准化的交付 SOP、还是自动化的部署工具，都是我感兴趣的事情。"
四、为什么选择易盾
"我对这个机会比较感兴趣。原因有几点：
第一，易盾的私有化交付场景和我过去的核心工作高度重合——在客户环境里把复杂系统跑起来、跑稳，这是我最熟悉的事情。
第二，网易在技术上的口碑一直很好，产品化的交付流程比华为项目制更规范，我觉得在这里能把交付做得更系统一些。
第三，我现在已经离职，状态上可以全身心投入，没有交接的顾虑。
如果双方在薪资上能谈拢，我这边可以优先推进。"
四、对易盾产品的理解
"易盾是网易旗下的安全产品线，核心产品包括内容安全（文本/图片/视频审核）、业务安全（反欺诈、风控）、设备指纹等。私有化部署主要面向对数据合规要求高的客户，比如金融、政务、大型企业。
从交付角度看，这类客户的环境通常比较复杂——网络隔离、定制化需求多、运维团队技术能力参差不齐。这和我在华为服务政企客户的场景非常像，我觉得自己能快速上手。"
五、SaaS 私有化交付全流程
"我参与过类似的私有化交付项目，整个流程分六个阶段：
第一阶段（1–2 周）：需求调研，核心是搞清楚客户的合规要求和网络隔离边界，输出《客户痛点分析》和《技术方案初稿》。私有化项目最容易在这里埋雷——客户说'按标准来'，但实际上每家的网络架构和安全基线都不一样，必须现场调研。
第二阶段（2–4 周）：架构设计评审，重点解决高可用、数据隔离、合规三个问题。用检查清单驱动评审：单点故障消除了吗？多租户隔离方案选对了吗？RPO/RTO 指标定义清楚了吗？
第三阶段（2–3 个月）：开发测试，Scrum 敏捷迭代，每 2 周一个 Sprint。CI/CD 流水线质量门禁：SonarQube 评级 ≥ B、单元测试覆盖率 ≥ 80%、0 高危漏洞，任何一项不达标阻断发布。
第四阶段（2 周）：UAT 验收，功能、性能、安全三轮测试，全部通过才签收。同时做运维人员和业务人员培训，确保客户团队能接手自主运维。
第五阶段（2 周）：灰度发布上线，四步走：内网验证（10%）→ 灰度放量（30%）→ 全量观察 24 小时 → 正式全量。监控三个核心指标：错误率、P99 延迟、业务指标，任何一个超阈值立即回滚。
第六阶段（持续）：运维运营，Prometheus + ELK + SkyWalking 三维可观测，P0 故障 5 分钟响应，定期输出健康度报告。
私有化和公有云 SaaS 最大的区别是：公有云 1–3 天就能接入，私有化要 1–6 个月，多了环境调研、方案定制、数据迁移、定制开发这几个环节，交付物更重，对实施工程师的综合能力要求更高。"
五、多租户隔离方案
"多租户隔离按合规要求分三级：
金融、政务这类高合规客户，用独立数据库，数据完全隔离，代价是成本高、运维复杂，但这类客户对数据主权要求很严，没有商量余地。
中大型企业客户，用共享数据库 + 独立 Schema，成本可控，隔离性也够用，是大多数私有化项目的选择。
小型客户或者 SaaS 标准版，用共享 Schema + 租户 ID，成本最低，但隔离性弱，只适合对数据合规要求不高的场景。
不管哪种模式，API Gateway 统一做租户识别和鉴权，业务链路通过 TenantContext 透传租户上下文，确保数据不串。"
五、Service Mesh 实践
"在华为云项目里做过 Service Mesh 落地，用的是华为云 ASM，底层基于 Istio，数据面是 Envoy Sidecar。
主要解决三个问题：一是多语言服务的统一治理，Java 和 Go 的服务之前各自用不同的 SDK，迁到 Envoy 之后统一了；二是灰度发布，用 VirtualService 做流量切分，按 Header 或权重路由到不同版本；三是可观测性，Sidecar 自动采集链路数据，接入 SkyWalking，不需要业务代码改动。
落地过程中遇到的主要问题是 Sidecar 注入对现有 Pod 的影响——有些服务启动顺序有依赖，Sidecar 初始化比业务容器慢，导致启动时连接失败。解决方法是调整 initContainer 的 holdApplicationUntilProxyStarts 参数，让业务容器等 Envoy 就绪再启动。
网易轻舟是 Dubbo+Istio 双栈并存，Dubbo 负责 Java 服务注册发现，Istio 补多语言和灰度路由，思路类似，只是在 Java 生态里保留了 Dubbo 的注册中心，没有完全切到 Istio 的服务发现。"
五、CI/CD 质量门禁与灰度回滚
CI/CD
"流水线分四层：代码提交触发 PR 检查 → CI 构建（单元测试 + 代码扫描 + 构建镜像）→ 质量门禁 → CD 部署（DEV → TEST → STAGING → PROD 灰度 → PROD 全量）。
质量门禁是硬卡点：SonarQube 评级 ≥ B、JaCoCo 行覆盖率 ≥ 80%、0 高危漏洞、单元测试失败率 0%，任何一项不达标直接阻断，不允许带病上线。
接口响应时间 P99 > 200ms 是警告级别，不阻断但会触发通知，让开发自己决定是否继续。"
灰度回滚
"灰度发布四步走：内网验证 → 灰度放量 30% → 全量观察 24 小时 → 正式全量。
回滚决策看三个指标：错误率超 1%、P99 延迟超 2s、业务指标（比如风控漏检率超 0.1%），任何一个触发就立即回滚。
版本切换用 etcd CAS 原子操作，切换失败自动回滚，整个过程业务无感知。"
五、故障应急响应
"故障分四级：P0 核心业务中断 5 分钟响应，P1 核心功能受损 15 分钟响应，P2 非核心功能异常 1 小时，P3 轻微问题 24 小时。
处理流程：告警触发 → 值班响应 → 问题定位 → 止血处理（回滚/降级/扩容）→ 效果验证 → 输出报告。
止血优先于根因分析——先让业务恢复，再慢慢找根因。我自己早期也犯过这个错，在生产故障时想先把根因搞清楚再动手，结果中断时间拉长了。后来养成习惯，先止血，稳定了再复盘。
复盘必须有 Action Items，每条要有负责人和 deadline，不能只有结论没有改进动作。"
六、一面技术复核速查
| 问题 | 核心口径 |
|---|---|
| K8s PVC 挂载失败 | StorageClass 名称拼写错误 → PV 无法动态创建 → 修复后再看 securityContext.fsGroup 权限问题 |
| NetworkPolicy 间歇超时 | deny-all 拦截跨 namespace 流量，同节点路径不执行 NetworkPolicy 导致间歇性 → namespaceSelector 修复 |
| 生产容器 heap dump | 容器只有 JRE，用 docker inspect --format '{{.State.Pid}}' 拿宿主机 PID，再用宿主机 jmap dump |
| Redis 找大 key | 全量扫描有性能风险，用 --scan --count 100 分批抽样 |
| Kafka 消费积压 | 特定分区消费者处理异常消息反复重试卡死，引入死信队列跳过异常消息 |
| 告警风暴治理 | AlertManager group_by 聚合 + inhibit_rules 根因抑制，告警数量减少约 60% |
| MySQL max_connections | SET GLOBAL 在线改 + 同步更新 my.cnf，防止重启失效 |
七、软性问题速查
离职原因
"家庭原因，我妈身体出了点状况需要手术，我是独子，当时需要频繁就医陪护，就申请离职了。目前家里情况已经稳定，可以全身心投入新工作，随时可以到岗。"
薪资期望
"请问这个岗位的薪资范围大概是什么区间？"（了解范围后再报区间，主动解释：上份是项目制结构，稳定性不如产品公司，现在优先考虑稳定性和长期发展。）
到岗时间
"已经离职了，到岗时间比较灵活，可以结合贵司的节奏来定，双向沟通一下就行。"
优点：系统性思维（分层拆解）、执行力强（50 多个项目按节点交付）、善于沉淀（SOP/检查清单）
缺点：对细节要求比较高，有时在不关键的地方花时间多，在有意识地调整；跨团队沟通表达比较直接，现在更注意先认可对方出发点再提问题。
八、面试注意事项
- 语速放慢，说清楚比说快更重要
- 没听懂先确认："您的意思是问 xxx 吗？"
- 复杂问题先思考："我稍微整理一下思路"
- 先说要点再展开，问面试官是否需要补充
- 真不会就说不了解，补一句"我会主动去研究，跑通流程"
- 案例说自己做了什么，不说"我们团队做了"
个人主页自然带出
被问"平时怎么学习"时：
"我平时有写博客和维护 GitHub 的习惯，云原生这块沉淀了不少，K8s、Service Mesh、昇腾 CANN 都有相关记录，感兴趣可以看一下，GitHub 是 initchu。"
结尾"您还有什么想了解的"环节：
"我的 GitHub 是 initchu，博客是 cnblogs.com/chucz，技术方向和这个岗位比较对口，可以参考一下。"
九、结尾反问面试官
最多问 2–3 个，按场景挑选，不要连续问超过 3 个。
岗位 & 日常工作（首选，体现务实）
- 请问这个岗位日常主要对接哪些类型客户？工作中出差频次、驻场情况大概是怎样的？
- 目前团队里实施项目主要集中在哪些行业（游戏/政企/互联网等）？
- 实施交付流程里，本岗位更侧重现场部署、客户培训，还是售后问题对接？
能力 & 成长（体现上进心）
- 结合这个岗位，您认为新人入职后，最需要快速掌握哪些技能和产品知识？
- 团队会有系统化的培训、老带新机制吗？后续有没有技术深化、项目统筹类的成长路径？
- 公司对于实施工程师，后续横向转售前、方案、运维这类岗位是否有内部通道？
团队 & 协作（了解氛围）
- 目前咱们这个实施团队大概多少人？分工模式是怎样的？
- 实施过程中，和研发、售前、售后团队的协作多吗？常见的协作场景是什么？
业务 & 挑战（二面/终面适用）
- 当前易盾产品在落地实施时，客户反馈最多的难点主要集中在哪方面？团队一般如何应对？
- 现阶段团队的重点项目/目标是什么？新人入职后会参与哪些核心工作？
绩效 & 考核（委婉提问）
- 想了解下这个岗位的绩效考核主要参考哪些维度？会侧重项目交付效率、客户满意度吗？
薪酬 & 福利（终面/HR面再问，一面别问）
- 想了解下岗位的作息、加班情况以及出差补贴相关制度？
- 请问这个岗位的薪酬结构、试用期时长和转正要求是怎样的？
- 公司针对外勤、出差岗位，有没有对应的保障或福利政策？
主动展示型（气氛好时用，二面加分）
"我在华为做交付时沉淀了一套从环境调研到试运行转维的交付 SOP，想了解一下易盾这边现有的交付流程是否已经比较标准化了？还是说新人也有机会参与流程优化？"
收尾万能句
"我这边暂时没有其他问题了，非常感谢您今天的时间，辛苦了！"
二面推荐组合（直接用）
组合A（稳妥）：岗位日常出差情况 + 新人入职后上手节奏
组合B（展现积极性）：实施项目主要服务哪些行业 + 您觉得前期上手最容易卡在哪里
组合C（终面/HR面）：日常加班和出差情况 + 薪酬结构与转正要求