网易易盾 二面准备稿
面试性质：业务复试，面试官是业务线负责人，有录用决定权和定薪权 重点：软性能力考察（抗压、协调沟通、复盘总结）+ 一面技术问题复核 + 意向度确认
一、自我介绍（二面版，略有调整）
二面面试官更关注你的全局视角和做事方式，自我介绍要比一面更突出"主导"和"结果"，少说技术细节。
"我有 10 年以上云计算与运维经验，其中 6 年在华为担任 HCS 产品技术 TD，服务电力、政务、金融等头部客户。TD 是项目全生命周期的技术责任人，从前期需求调研、方案规划，到中期现场实施，再到试运行转维，技术侧全程由我主导，累计交付了 50 多个政企云项目，沉淀了 33 项运维流程和 50 多份标准交付物。
技术方向上，华为云生态覆盖面比较广，IaaS 侧做过计算、存储、网络的规划和落地，PaaS 侧做过 CCE 容器平台、中间件、数据库的部署和调优，微服务这块也做过，服务治理、注册发现、链路追踪、灰度发布都有涉及。
代表项目是去年 3 月的衢州政务大模型，DeepSeek-R1 在昇腾 NPU 集群上的多机推理部署，我全程主导架构规划和落地，解决了昇腾驱动兼容性和跨节点 RDMA 通信等关键问题，3 周内完成交付，现已稳定接入 13 个政府部门，是国内较早落地的政务大模型工程化案例。
AI 基础设施这块也做过，参与了运营商昇腾 CloudMatrix 384 超节点的交付，384 张昇腾 910C 芯片，灵衢总线全光互联架构，11 周按期完成，是当时国内规模比较大的昇腾算力集群交付项目之一。
除了 AI 交付，我也有端到端的信创云交付经验，主导过政务云国产化改造、警务云、电力云等多个大型项目，从硬件选型、操作系统适配到云平台部署，全流程都做过。
我来面试易盾这个岗位，主要是觉得跟我过去做的事情比较接近——在客户环境里把系统部署好、稳定跑起来，出了问题快速响应。希望能在产品化的公司把交付做得更标准一些。"
二、成功案例（骄傲/有挑战）
案例 A：衢州政务大模型 DeepSeek-R1 部署
一句话定位：主导 DeepSeek-R1 671B 在昇腾 910B 集群上的多机推理部署，全程负责架构规划和落地，3 周交付，现已接入 13 个政府部门。
挑战在哪：
- CANN 版本与模型权重格式不兼容，出现 weight shape mismatch，需要对照版本配套矩阵逐层排查
- 跨节点 RDMA 通信配置，RoCEv2 无损网络的 PFC/ECN 参数调优
- 671B MoE 模型显存压力大，采用 W8A8 量化分阶段上线，保障业务连续性
结果：推理吞吐提升约 40%，稳定接入 13 个政府部门，是国内较早落地的政务大模型工程化案例。
案例 B：昇腾 CloudMatrix 384 超节点交付
一句话定位：以华为浙江代表处 TD 身份参与杭州滨江移动昇腾 CloudMatrix 384 超节点交付，48 台 Atlas 800T A3 服务器、每台 8 卡，共 384 张昇腾 910C 芯片，产品线研发团队主导，我负责客户侧协调、现场支持和验收跟进。项目涉及机柜上架走线、光模块逐一验收、CANN/驱动/固件版本调试（产品未 GA，软件栈需反复适配）、72 小时稳定性测试，加上移动运营商机房准入和安全审批流程，11 周按期完成。
挑战在哪：
- 规模大、精度要求高：灵衢总线（UnifiedBus）全光互联架构，7 个独立并行通信平面，每卡 7 个 400G 光收发器（单卡总带宽 2.8Tbps），光模块数量庞大，光功率和误码率（≤1e-12）逐一验收，不达标不能签收
- 软件栈是昇腾专有生态，CANN/驱动/固件三者版本严格绑定，任何一层不对都会导致算子不支持或性能劣化
- 验收标准严格：AllReduce 带宽 ≥700 GB/s、线性加速比 ≥0.85、72 小时连续运行 0 故障
我的角色：
- 作为代表处 TD，负责客户侧需求对接、现场协调和进度跟进
- 参与硬件验收过程，协助用
npu-smi info -t health/temp/power/version逐卡健康检查，ib_write_bw验证 RoCEv2 带宽 - 跟进软件栈部署，了解版本配套矩阵（驱动 → 固件 → CANN 6.0 → MindSpore 3.0）和 Volcano Gang Scheduling 容器化部署方案
- 协调验收阶段问题处理，AllReduce 带宽不达标时参与排查：单链路
ib_write_bw→ RoCEv2 QoS 策略 → 光模块误码率
结果：11 周按期交付，DeepSeek-R1 70B 训练迭代速度较 H100 集群提升约 1.8 倍，推理侧动态 CP/DP 使变长序列吞吐提升约 40%，沉淀为可复用交付模板。
如果被追问"为什么每卡 7 个 400G 光收发器"：
"7 不是随意定的，是灵衢总线 7 平面并行全互联拓扑决定的。灵衢不是传统单总线/树状交换，而是 7 个完全独立、并行的通信平面，做无阻塞全互联（Clos-like），单跳直达、百纳秒低时延。每个平面配 1 个 400G 光收发器，7 平面就是 7×400G=2.8Tbps，匹配昇腾 910 单卡 TB 级片间带宽，带宽匹配、无瓶颈。7 个平面还有冗余价值：任意 1 个平面/光模块故障，剩余 6 个自动接管，训练任务不中断。6 个不够冗余，8 个会增加功耗和成本，7 是性能/成本/冗余的工程最优解。"
三、软性能力问题准备
3.1 抗压能力
高频问法：
- "你遇到过压力最大的一次是什么情况？"
- "客户非常不满意，你怎么处理？"
- "同时有多个紧急任务，你怎么排优先级？"
口径：
"压力最大的一次是浙能智云升级引发 EIP 业务中断。生产环境，客户是省级能源集团，EIP 全面中断，客户现场负责人直接打电话过来，语气很急。
我当时的处理方式是：先稳住客户，告诉他我们已经在排查，给他一个 30 分钟的反馈节点；然后立刻开始分层排查，不慌不乱，从业务层往下逐层定位。最终 15 分钟内找到根因，重启 openvswitch 后业务恢复，比承诺的时间提前了一半。
事后我复盘了一点：当时如果升级前做了定制硬件的固件扫描，这个问题是可以提前发现的。所以我推动把这一项列入了升级前置检查清单。
高压场景下我习惯先给客户一个明确的时间节点，这样双方都知道下一步是什么，不会陷入干等的状态。"
如果追问"多任务并行怎么排优先级"：
"我的原则是：先看影响面，生产故障 > 上线节点 > 日常需求；再看可逆性，不可逆的操作优先确认再动手。华为内部有一套变更管控流程，我在这个框架下养成了习惯，遇到多任务并行时会先列出来，按影响面和紧急程度排序，然后逐一推进，不会同时开多个高风险操作。"
3.2 协调沟通能力
高频问法：
- "你在项目里遇到过跨团队协调困难的情况吗？"
- "客户提了一个不合理的需求，你怎么处理？"
- "和技术能力比你强的人合作，你怎么定位自己的角色？"
口径 A：跨团队协调
"衢州警务云项目里，我需要同时协调华为产品线、客户 IT 部门、奇安信零信任团队三方。当时遇到一个问题：ROMA 业务总线和奇安信零信任的 Token 鉴权格式不兼容，两边都说自己的实现是标准的，互相推责。
我的处理方式是：不站任何一边，先把问题拆解清楚——到底是哪个环节的格式不匹配，用抓包和日志把问题现象固化下来，让两边都看到同一份证据。然后组了一个三方技术对焦会，把问题定义清楚之后，两边很快就找到了解决方案：在 ROMA 的自定义鉴权函数里做适配，绕过默认的 Bearer 解析逻辑。
我后来总结了一点：跨团队协调卡住的时候，通常不是技术问题，是各方对问题的描述不一致。把问题用数据和日志固化下来，让大家看同一份东西，比开会争论有效得多。"
口径 B：客户不合理需求
"有一次客户要求在没有测试环境的情况下直接在生产上做版本升级，理由是时间紧。我没有直接拒绝，而是把风险量化给他看——这个版本有几个已知的存储驱动变更，如果不验证直接上生产，一旦出问题回滚窗口只有 2 小时，影响的是 500 台虚机上的核心业务。
客户听完之后同意了先搭一个最小化测试环境验证关键路径。最后证明这个决定是对的，测试环境里确实发现了 IO 调度策略的兼容性问题，提前处理掉了。
我的原则是：不合理的需求不是直接说'不行'，而是把风险和代价说清楚，让客户自己做决定。大多数时候客户不是不讲理，只是信息不对称。"
3.3 复盘与总结能力
高频问法：
- "你做过最有价值的一次复盘是什么？"
- "你有没有因为自己的判断失误导致问题？怎么处理的？"
- "你怎么沉淀经验，让团队也能受益？"
口径：
"最有价值的复盘是浙能智云 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 检查点，may_enable 全为 false 时自动暂停；升级后建立网络健康检查 SOP，bond 状态、LACP 协商、网关 ping 三项全通才算升级成功。
复盘完了必须有 Action Items，每条要有负责人和 deadline，不然复盘就停在纸面上了。"
如果追问"怎么让团队受益"：
"我的做法是把复盘结论转化成检查清单，放到团队共享的知识库里。这次的硬件固件扫描步骤和 bond 状态检查点，后来都写进了升级变更前置检查清单，后续再没出现类似问题。"
四、宏观/战略性问题准备
4.1 职业规划
高频问法：
- "你 3-5 年的职业规划是什么？"
- "你为什么选择交付实施方向，而不是纯研发或售前？"
口径：
"我的方向是云原生交付和运维工程化。过去 6 年在华为，我做的是偏重架构规划和项目交付，积累了一套从方案设计到现场落地的完整方法论。
接下来 3-5 年，我希望在一个产品化的公司，把这套方法论用在更标准化的产品交付上——不是每次都从零开始设计，而是把交付做得更可复制、更高效。易盾的私有化部署场景，客户多、环境复杂，正好是我想深耕的方向。
长期来看，我希望能在交付工程化方向上做出沉淀，不管是标准化的交付 SOP、还是自动化的部署工具，都是我感兴趣的事情。"
4.2 为什么选择易盾 / 意向度表达
二面面试官有定薪权，主动表达意向度有助于后续薪资谈判。
口径：
"我对这个机会比较感兴趣。原因有几点：
第一，易盾的私有化交付场景和我过去的核心工作高度重合——在客户环境里把复杂系统跑起来、跑稳，这是我最熟悉的事情。
第二，网易在技术上的口碑一直很好，产品化的交付流程比华为项目制更规范，我觉得在这里能把交付做得更系统一些。
第三，我现在已经离职，状态上可以全身心投入，没有交接的顾虑。
如果双方在薪资上能谈拢，我这边可以优先推进。"
4.3 对易盾产品的理解（如被问到）
提前准备，体现主动性。
口径：
"我在面试前做了一些了解。易盾是网易旗下的安全产品线，核心产品包括内容安全（文本/图片/视频审核）、业务安全（反欺诈、风控）、设备指纹等。私有化部署的场景主要面向对数据合规要求高的客户，比如金融、政务、大型企业。
从交付角度看，这类客户的环境通常比较复杂——网络隔离、定制化需求多、运维团队技术能力参差不齐。这和我在华为服务政企客户的场景非常像，我觉得自己能快速上手。"
五、微服务项目交付实施经验（重点模块）
二面面试官可能重点考察交付实施的全流程经验和方法论沉淀，以下是针对易盾私有化交付场景的专项准备。
5.1 SaaS 私有化交付全流程（核心话术）
高频问法：
- "你做过完整的 SaaS 项目交付吗？能描述一下流程？"
- "私有化部署和公有云 SaaS 交付有什么区别？"
- "你在交付过程中遇到过哪些典型问题？"
口径（以易盾海淀融媒体项目为参考，5 个月周期）：
"我参与过类似的私有化交付项目，整个流程分六个阶段：
第一阶段（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 个月，多了环境调研、方案定制、数据迁移、定制开发这几个环节，交付物更重，对实施工程师的综合能力要求更高。"
5.2 多租户隔离方案选型
高频问法：
- "你们的多租户隔离是怎么做的？"
- "金融客户和普通客户的隔离方案有什么区别？"
口径：
"多租户隔离我们按合规要求分三级：
金融、政务这类高合规客户，用独立数据库，数据完全隔离，代价是成本高、运维复杂，但这类客户对数据主权要求很严，没有商量余地。
中大型企业客户，用共享数据库 + 独立 Schema，成本可控，隔离性也够用，是大多数私有化项目的选择。
小型客户或者 SaaS 标准版，用共享 Schema + 租户 ID，成本最低，但隔离性弱，只适合对数据合规要求不高的场景。
不管哪种模式，API Gateway 统一做租户识别和鉴权，业务链路通过 TenantContext 透传租户上下文，确保数据不串。"
5.3 微服务治理：华为云 Service Mesh 实践
高频问法：
- "你做过微服务治理吗？用的什么方案？"
- "Service Mesh 落地遇到过什么问题？"
- "Istio 和 Dubbo 有什么区别，你怎么选？"
口径：
"在华为云项目里做过 Service Mesh 落地，用的是华为云 ASM，底层基于 Istio，数据面是 Envoy Sidecar。
具体做的事情是：客户的微服务从传统 SDK 注册发现迁移到 Service Mesh，主要解决三个问题：一是多语言服务的统一治理，Java 和 Go 的服务之前各自用不同的 SDK，迁到 Envoy 之后统一了；二是灰度发布，用 VirtualService 做流量切分，按 Header 或权重路由到不同版本；三是可观测性，Sidecar 自动采集链路数据，接入 SkyWalking，不需要业务代码改动。
落地过程中遇到的主要问题是 Sidecar 注入对现有 Pod 的影响——有些服务启动顺序有依赖，Sidecar 初始化比业务容器慢，导致启动时连接失败。解决方法是调整 initContainer 的 holdApplicationUntilProxyStarts 参数，让业务容器等 Envoy 就绪再启动。
网易轻舟的方案我也了解过，他们是 Dubbo+Istio 双栈并存，Dubbo 负责 Java 服务注册发现，Istio 补多语言和灰度路由，思路和华为 ASM 类似，只是在 Java 生态里保留了 Dubbo 的注册中心，没有完全切到 Istio 的服务发现。"
5.4 CI/CD 质量门禁与灰度发布
高频问法：
- "你们的 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 原子操作，切换失败自动回滚，整个过程业务无感知。这个设计的好处是：不需要人工判断，指标触发就自动处理，减少了人为决策的延迟。"
5.5 故障应急响应与复盘机制
高频问法：
- "你们的故障响应流程是怎么样的？"
- "P0 故障你是怎么处理的？"
- "故障复盘怎么做才有价值？"
口径：
"故障分四级：P0 核心业务中断 5 分钟响应，P1 核心功能受损 15 分钟响应，P2 非核心功能异常 1 小时，P3 轻微问题 24 小时。
处理流程：告警触发 → 值班响应 → 问题定位 → 止血处理（回滚/降级/扩容）→ 效果验证 → 输出报告。
止血优先于根因分析——先让业务恢复，再慢慢找根因。我自己早期也犯过这个错，在生产故障时想先把根因搞清楚再动手，结果中断时间拉长了。后来养成习惯，先止血，稳定了再复盘。
复盘我的原则是：复盘完了必须有 Action Items，每条 Action Item 要有负责人和 deadline，不能只有结论没有改进动作。我在华为做过一次升级变更事故的复盘，最终推动了三项改进落地：升级前固件版本扫描、升级脚本增加检查点、建立网络健康检查 SOP，后续再没出现类似问题。"
六、一面技术问题复核准备
二面可能重复问一面的技术问题做真实性核查，以下是高频复核点，确保口径一致。
| 问题 | 核心口径（简版） |
|---|---|
| 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 为什么不用 --bigkeys | 全量扫描有性能风险，用 --scan --count 100 分批抽样 |
| Kafka 消费积压根因 | 特定分区消费者处理异常消息反复重试卡死，引入死信队列跳过异常消息 |
| 告警风暴怎么治理 | AlertManager group_by 聚合 + inhibit_rules 根因抑制，告警数量减少约 60% |
| MySQL max_connections 怎么改 | SET GLOBAL 在线改 + 同步更新 my.cnf，防止重启失效 |
七、软性问题标准口径
离职原因
"家庭原因，母亲身体出了点状况需要手术，我是独子，当时需要频繁就医陪护，就申请离职了。目前家里情况已经稳定，可以全身心投入新工作，随时可以到岗。"
薪资期望
先反问："请问这个岗位的薪资范围大概是什么区间？" 了解范围后再报区间，主动解释：上份是项目制结构，稳定性不如产品公司，现在优先考虑稳定性和长期发展。
到岗时间
"已经离职了，到岗时间比较灵活，可以结合贵司的节奏来定，双向沟通一下就行。"
优缺点
优点（三点）：
- 系统性思维：遇到问题习惯分层拆解，不会被表象带跑，这在故障排查和方案设计上都有体现。
- 执行力强：从方案到落地全程主导，不依赖别人推动，50 多个项目基本都按节点交付。
- 善于沉淀：每次遇到新问题都会整理成 SOP 或检查清单，让经验可复用，不只是自己受益。
缺点（两点）：
- "有时候对细节要求比较高，在一些不那么关键的地方会花比预期更多的时间，这点我在有意识地调整，学会区分哪些细节值得深究、哪些可以先过。"
- "跨团队沟通时，有时候会直接说问题，表达方式比较直接，偶尔会让对方感受到压力。我现在会更注意先认可对方的出发点，再提问题。"
八、面试注意事项
- 语速放慢，说清楚比说快更重要
- 没听懂先确认："您的意思是问 xxx 吗？"
- 复杂问题先思考："我稍微整理一下思路"
- 先说要点再展开，问面试官是否需要补充
- 真不会就说不了解，补一句"我会主动去研究，跑通流程"
- 案例说自己做了什么，不说"我们团队做了"
关于个人主页的提法
面试官大概率会搜你，GitHub 第一条就是你，技术方向清晰，是加分项。不要主动说"你可以去搜我"，用以下三种场景自然带出：
被问"平时怎么学习/技术积累"时：
"我平时有写博客和维护 GitHub 的习惯，云原生这块沉淀了不少，K8s、Service Mesh、昇腾 CANN 都有相关记录，感兴趣可以看一下，GitHub 是 initchu。"
被问到某个具体技术点时：
"这块我在 GitHub 上有个相关的 repo，当时做 K8s 初始化时整理的，有具体配置和踩坑记录。"
结尾"您还有什么想了解的"环节：
"我的 GitHub 是 initchu，博客是 cnblogs.com/chucz，技术方向和这个岗位比较对口，可以参考一下。"