Appearance
第12章 工作与项目问答地图（支持版简历逐条展开）
对应简历：工作经历两阶段 4+3 条 + 项目一 4 条 + 项目二 4 条 + 项目三 3 条，共 18 条，逐条展开为问答单元。 用法：面试官的问题 80% 落在简历某一行上——本章把每一行变成"知识点地图 + 高频问 + 可直接说的完整段落答法 + 真实数字"。支持版项目顺序红线：项目一=银行驻场支持、项目二=AI 知识库、项目三=K8s 技术底座（与运维版不同，背混是口径漂移头号事故）。被问任何一条，先反应出对应章号去展开技术细节。术语：Kubernetes（下文简写 K8s）。
12.0 口径总原则（先背这六条再往下看）
- 脱敏红线：不报内网 IP、账号、仓库域名、VPC 网段——一律"某银行内网环境""内网私有仓库"；被追问就说"客户内网信息，签了保密协议"——金融背景的保密纪律本身就是加分项。
- 角色口径：项目一平台选型归华为（公司是渠道商），我负责落地交付，上线后一线支持归我、二线转华为原厂；项目二我主导（懂场景+会治理）；项目三体系是通用最佳实践，方案编制/部署/验证是我。不越位、不虚揽，被问"为什么这么选型"就答"配套体系定的，但配套原因我能讲清楚"。
- 数字口径：驻场近两年、4 台 TaiShan、15+ 台虚拟机、3 master、K8s v1.17.3 / v1.28.2、月成本 5000 元以内、99.99% 是设计目标——全部有据可查，大胆说；规划数字不说成实测结果。
- 支持版人设：每条职责的讲法落点是"服务闭环"——接得住（技术定位）、说得清（沟通表达）、闭环快（工单流程），讲技术永远带一句"我怎么跟客户交代"。
- 动词口径：简历"负责/主导"= 亲手做、随便深挖；"熟悉/具备"= 答到标准回答层，深挖用兜底话术："这块我生产上按 XX 处理过，原理理解到 XX，更深的会后补。"
- 每条职责的标准讲法：一句话概括做了什么 → 规模/版本数字 → 一个最熟的细节或坑 → 结果（客户认可/沉淀标准/闭环数据）。
第一部分 工作经历·实施与支持阶段（2023.08–2025.06，驻场某大型银行）
实-1 「驻场某大型银行近两年，负责数字人民币智能合约引擎平台的实施交付与一线技术支持」
- 涉及知识点 → 第 08 章（虚拟化交付）、第 06 章（K8s）、第 03 章（Vastbase）、第 09 章（工单流程）；项目逐字稿见本章第六部分。
问①这个项目是什么样的？你的角色是什么？（约 250 字，可直接说）： 这是某大型银行的数字人民币试点项目，平台由华为规划选型：TaiShan 国产服务器加 FusionCompute 虚拟化、Kubernetes、Vastbase 数据库、华为 BCS 区块链加智能合约管理平台，我们公司作为华为渠道商负责部署交付。我驻场近两年，角色分两段：前期是实施交付——虚拟化底座、K8s 集群（含单 master 升三 master 高可用改造）、Vastbase 一主一备数据库的部署与验收都是我做的；上线后转一线技术支持——日常答疑、告警响应、疑难问题按流程协同华为原厂处理，直到平台通过客户验收、稳定支撑数币试点业务。说清楚一点：选型决策在华为，我的价值是"把它在银行生产环境一次装通、装稳、装到能交付，并且长期守得住"——这个既做过交付又做过长期支持的双重视角，是我和纯实施或纯支持候选人的差别。
问②为什么全套国产化？（约 220 字）： 核心原因是数字人民币的性质决定的：它是央行发行的数字形式法定货币，金融基础设施叠加信创合规要求，所以从芯片、服务器、操作系统、数据库到区块链平台必须全链路国产——鲲鹏芯片加 TaiShan 服务器、统信 UOS 和麒麟 V10 操作系统、Vastbase（openGauss 生态的国产数据库）、华为 BCS。我的角色边界我会主动说清：这套选型是华为和银行按配套体系定的，我负责按版本配套表落地——FC 8.3.0、DME 22.0、BCS 1.2.6、K8s v1.17.3 是一张配套表上的，生产环境严格按配套执行、绝不擅自升级。但为什么这么配套我能讲清楚：Vastbase 对鲲鹏 ARM 原生适配（安装包就是 aarch64_kunpeng 专用包）、BCS 对纳管的 K8s 版本有严格兼容矩阵。这段经历给我最大的训练是"版本配套意识"——生产选型先查配套关系再谈技术新旧，这个习惯在我后来的移动云项目（自主选型 v1.28.2）里正好形成对照。
问③ARM 环境和 x86 有什么不同？（约 200 字）： 最大的差异是软件生态要全部换一遍：操作系统必须装 ARM 版统信麒麟、软件源要配 aarch64 专用源、Docker 用 aarch64 静态二进制包装、所有容器镜像必须是 arm64 版本——海外镜像内网拉不到就离线导入，我写了批量加载脚本给 9 个 BCS 数据面节点铺镜像，还固化了"镜像架构清单"检查项，因为踩过 x86 镜像混入报 exec format error 的坑。不变的层面也说得出：内核参数、防火墙、systemd 这些系统层操作和 x86 完全一致，差异集中在"二进制和镜像的架构"这一层。对支持岗的意义：客户环境不管什么架构，我第一件事先确认架构再动手——"选任何软件先看架构标签"已经成了我的肌肉记忆，这是 ARM 项目两年刻出来的条件反射。
- 真实数字锚点：驻场近两年、4 台 TaiShan（96 核/384G/3.84T SSD）、15+ 台国产 VM、3 master + 10 worker、平台通过客户验收支撑数币试点运行。
实-2 「承担平台日常技术答疑与问题处理（环境异常、登录失败、使用咨询等），按'记录—处理—转派—跟踪—闭环'流程协同华为原厂解决疑难问题」
- 涉及知识点 → 第 09 章（工单五步）、第 06 章（分级转判）、第 04 章（登录异常排查链）、第 14 章（支持场景案例）。这是支持岗简历的最核心一条，必须讲透。
问①你一天的工作是什么样的？（约 260 字）： 我的日常分四块。第一块工单处理：银行用户报环境异常、登录失败、使用咨询，我按"记录—处理—转派—跟踪—闭环"五步走——接到报障先记录四要素（现象、时间、范围、最近变更），能一线处理的直接处理（多数是环境类、账号类、配置类），处理不了按分级转判转二线或华为原厂，转出去的单子我持续跟踪直到闭环；第二块主动巡检：每日固定动作查系统资源、服务状态、告警，主动发现问题比被动等报障体验好得多；第三块监控值守：Prometheus 告警响应，磁盘、CPU、服务异常按分级流程处置；第四块协同与文档：和华为原厂对疑难单、和客户运维对接人对日常事项，处理完的问题沉淀进 FAQ 和部署文档。时间分布上，工单类大概占一半，巡检和协同占三成，文档和培训类占两成——一年下来工单有几百单，闭环率和响应时效都是客户认可的。
问②工单五步流程具体怎么走的？举一单说说。（约 280 字，背熟，这题就是支持岗的"自我介绍级"问题）： 五步我每步都有实标准。记录：接到报障先记现象、时间、影响范围、最近变更——比如用户报"登录不上"，我先确认是个人还是所有人、从几点开始、平台最近有没有发布；处理：一线清单内的直接处理——登录失败我按固定链路排查：用户侧网络通不通到平台入口、Nginx 和证书状态、后端进程和端口、后端日志里数据库 Redis 连接报错、数据库主备有没有切换——从入口往里五分钟能定位到层；转派：定位到超出我边界的（平台组件内部、数据库内核），打包证据转二线——现象、时间线、日志截图、已做尝试、我的初步判断；跟踪：转出去不撒手，按优先级定时跟进，同步客户进展；闭环：验证业务恢复、客户确认、记录归档，高频问题写进 FAQ。印象深的一单：一次批量用户登录失败，排查发现是 Vastbase 主备切换后应用连接串没跟着更新，我协调应用侧更新配置恢复，随后把"主备切换后的检查项"写进了巡检清单——这单五步全走了一遍，也是"闭环后防复发"的标准示范。
问③问题怎么分级？什么转华为原厂？（约 250 字）： 我的分级按四条边界：层级、权限、影响面、时间盒。一线处理的是"现象清晰、可复现、有 SOP、改动可回退"的问题——环境配置、账号权限、应用参数、常规故障定位，这类我直接处理；转二线的是"需要进节点系统层、改集群组件配置、查运行时与内核"的问题；协同原厂的是"产品组件内部机制"的疑难——华为 BCS 平台组件异常、FusionCompute 平台告警这类，需要原厂工具或内部知识。影响面大的问题无论难度高低立即升级并同步客户——分级看的不只是难度更是风险。转原厂我固定打一份七件套证据包：问题概述、环境版本配套信息、原始日志、告警记录、已做尝试、复现条件、期望与约束——原厂拿到就能直接查，我打包质量的口碑就是这两年攒出来的。时间盒纪律：一线尝试 30 分钟没有收敛就升级，宁可转早不转晚——拖大问题才是真正的失职。
问④驻场支持最难的是什么？你怎么应对？（约 220 字）： 最难的不是技术，是三件事的组合：金融生产环境不容出错、多方协同（客户、我们公司、华为原厂、开发团队）责任链复杂、以及客户的情绪和预期管理。我的应对有三个习惯：一是影响面先行——任何故障先说清"影响什么、不影响什么"，客户焦虑的大半来自未知；二是证据说话——排查结论、变更动作、责任归属全部留痕，工单时间线完整，两年里没有出过一起扯皮；三是预期管理——给客户的时间承诺都带具体时间点，"稍后回复"这种话我从来不说，"两小时内给您阶段结论"才是我的表达方式。技术难点反而好办：按第 6 章的排查树和第 9 章的命令树一层层收敛，总有路径。这两年最大的收获就是：在高压环境下把"稳"字练成了本能。
- 真实数字锚点：工单数百单/年、五步流程、七件套证据包、30 分钟时间盒、登录失败五层排查链。
实-3 「负责平台日常巡检、监控告警响应与版本升级配合，保障试点业务稳定运行」
- 涉及知识点 → 第 07 章（告警响应）、第 01 章（巡检）、第 02 章（巡检脚本）。
问①日常巡检都巡什么？（约 240 字）： 我分三层巡。第一层系统层：用固定命令组过一遍——top 看 CPU 负载、free 看内存、df 看磁盘、systemctl --failed 看失败服务、journalctl 拉当天错误级日志，这套在统信麒麟上和 CentOS 完全一致；第二层平台层：K8s 组件 Pod 状态是不是 Running、节点有没有 NotReady、Vastbase 主备复制状态、BCS 管理平台页面能不能正常访问、FusionCompute 平台有没有告警——五分钟一组命令出全貌；第三层业务层：对平台关键功能做冒烟验证——登录、核心页面、一个代表性交易动作。巡检结果记进固定表格留趋势，异常项当天闭环或者升级，每月出一份巡检小结给客户（告警量、处置情况、容量趋势和建议）。这套三层巡检让"平台稳定"从感觉变成有记录的事实——银行客户验收和审计时，巡检记录就是硬材料，这也是我把巡检做扎实的现实动力。
问②告警响了你的处理流程？（约 230 字）： 七步：确认收到（先在群里回"收到"让相关方知道有人动了）→ 定级和影响面（打开大盘确认是真告警还是误报、影响哪些业务）→ 快速定位（按告警名查处置手册第一步，磁盘类查日志和镜像层、服务类查进程和端口，五到二十分钟收敛到层）→ 决策处置（有预案按预案执行，能自愈的盯结果，不能修的先降级保业务）→ 通报协同（影响业务的按模板通报：现象、影响、当前动作、预计恢复时间，需要二线原厂的立即转）→ 恢复验证（指标回归加业务实际验证，不只看监控变绿）→ 闭环复盘（补工单时间线、写复盘、沉淀改进）。半夜收到告警的原则是保守：夜里做止损和保底，不做激进动作，按升级路径叫人——这套纪律是金融环境教我的，宁可保守不可炫技。
问③版本升级怎么配合的？（约 220 字）： 银行环境的升级纪律非常严格，我总结四条：第一，严格按华为版本配套表走——FC、DME、BCS、K8s 是一张表上的，任何组件升级先核对配套关系，绝不单独动；第二，变更窗口制：升级安排在业务低峰的约定窗口，提前向客户报备变更计划，写清影响面、步骤和回退方案，客户确认才动；第三，先备份后升级：数据库和关键配置动手前必须有备份或快照，这是变更纪律的一部分；第四，升级后按验收清单逐项验证，和原厂联调确认，向客户出升级报告。我的角色是执行和验证：准备环境、执行操作、验证业务、记录归档。这套流程说到底是金融环境教我的：升级不是技术问题，是变更管理问题——技术动作只占三成，七成是流程和留痕。
- 真实数字锚点：三层巡检、每日固定命令组、七步告警响应、变更窗口+配套表纪律、巡检记录成为审计材料。
实-4 「输出《智能合约引擎安装部署指南》、常见问题 FAQ 等文档，完成客户方使用培训与知识转移」
- 涉及知识点 → 第 12 章（讲法本身）、第 11 章（知识库）、第 13 章（培训组织）。
问①文档都写了什么？标准是什么？（约 230 字）： 最有代表性的是《智能合约引擎安装部署指南》v2.1，覆盖从零到装通的全要素：IP 与主机名规划表、RAID 方案、网络与 VLAN 配置、每个组件的版本和配套关系、分步部署命令和参数说明、验收检查清单，还有专门一节"注意事项"记录我踩过的坑——比如 iBMC 虚拟控制台要切日语键盘布局这种细节。我给自己定的标准一句话：一个新的实施同事拿到文档，不问我、照着做就能装通。这个标准逼着我把"手上知道但没写下来"的隐性经验全部显性化，比写文档本身更有价值。此外还有常见问题 FAQ（登录失败、环境异常的高频问答）、巡检手册、告警处置 SOP。这份部署指南后来沉淀为公司同类项目的标准实施文档，后续项目直接复用底稿——文档被复用，才算真文档。
问②客户培训怎么做的？（约 240 字）： 两层转移。第一层使用培训：对象是客户的运维对接人，内容是平台使用、日常巡检要点、告警怎么看怎么处理——我的培训原则是分场景实操、不讲概念课：每次只讲一个场景、带一次实操，比如"告警处置"这场就现场走一遍从告警到定位到通报的全流程，讲完有演练环节而不是念 PPT；培训材料标准化成讲义沉淀下来，后续重复使用。第二层知识交付：部署文档、巡检手册、常见问题处理手册作为交付物正式移交给客户，验收报告里逐项列明。做完转移的标志很实际：客户自己能处理日常巡检和一般告警、需要我们的频率明显下降——知识转移做得好，后续支持成本就低，这是我作为交付方很实际的动力。这个培训经验也是我后来做全员 AI 工具培训（项目二）的方法论底子：分场景、模板化、看使用数据。
问③为什么文档能力对支持岗这么重要？（约 200 字）： 三个层面。第一，服务可见性：支持工作天然是"问题消失了"的隐性工作，文档和工单记录是唯一让客户和组织看见价值的东西——我的部署指南成为公司标准、FAQ 被反复使用，这就是支持岗的"产品"；第二，可复制性：文档让任何同事接手我的环境都能照着做，人不休假服务才不休假——我所有 SOP 的出发点都是"写给下一个看的人"；第三，知识资产的复利：单点经验写成文档后可以进知识库、被 RAG 检索（项目二）、被新员工学习——一份文档的价值会滚雪球。所以我简历上"文档能力强"那条不是软技能描述，是实打实的产出清单：实施方案、部署手册、验收报告、故障处理 SOP、FAQ、知识库，六类文档我都成体系地写过。
- 真实数字锚点：部署指南 v2.1 成公司标准、FAQ/巡检手册/SOP 成套、客户培训两层转移、"不问我就能装通"标准。
第二部分 工作经历·运维与支持阶段（2025.07–2026.10，公司云平台与内部 IT）
运-1 「负责移动云生产 Kubernetes 集群与可视化运维管控体系的部署实施与日常运维支持」
- 涉及知识点 → 第 06 章（K8s）、第 07 章（监控/Kuboard）、第 09 章（CLB/VPC）。
问①为什么要建这套体系？（约 230 字）： 直接背景是公司 2025 年起拓展多行业软件外包业务，新项目要上线，传统虚拟机交付方式有三个痛点：资源交付慢——开环境装依赖以天计；环境不一致——每个项目装的版本配置各不相同，出了问题难排查；命令行运维门槛高——不是人人都会 kubectl，日常操作压在少数人身上。所以需要一套"交付快、环境一致、门槛低"的通用基础设施。方案是云原生体系：K8s 做底座保证环境一致和分钟级交付，Prometheus 加 Grafana 做监控告警，Kuboard 做可视化运维降低使用门槛。我负责从资源评估、方案编制到部署实施和验证的全流程，这套底座后来成为公司所有外包项目的标准基础设施——新项目照着方案重放就能开环境。对我个人的意义：这是我从"使用别人建好的环境"到"从零建环境并长期支持"的升级。
问②集群架构讲一下？（约 250 字）： 一句话：7 台 ECS、三个可用区、三层角色。3 台 2C4G 的 master 组三副本控制平面（etcd 用 Raft 多数派，3 副本容忍 1 台故障，偶数副本是纯浪费），3 台 8C16G 计算增强型的 worker 是业务负载池，1 台 4C8G 独立监控节点跑 Prometheus 和 Grafana——监控独立部署不占集群资源、故障隔离，"观察者不能和被观察者一起死"。入口层用移动云 CLB 四层负载做 apiserver 统一接入：所有 kubectl 都连 CLB 的 VIP:6443，健康检查对三个 master 秒级摘除故障节点——我在银行项目做过自建 Nginx+Keepalived 方案，云上选托管 CLB 是因为无单点免运维，两个方案我都实操过，这个对比是我的发言权。软件栈 K8s v1.28.2 加 containerd 1.7.8 加 Flannel VXLAN。控制平面按 99.99% 可用性目标设计——强调这是设计目标，靠三副本加 CLB 秒级摘除这些机制保障，我做过的实测是停一台 master 的 kubelet，kubectl 经 VIP 完全无感。
问③日常运维支持做什么？（约 220 字）： 建成后转入日常支持，我的固定动作：每日巡检五分钟清单——kubectl get nodes 全 Ready、非 Running Pod 过滤、事件流、kubectl top 资源水位，加每周深度项（etcd 健康、证书有效期）；告警响应按第 7 章的分级流程走——磁盘、Pod 重启、节点异常这些高频告警都有处置手册；日常操作 80% 在 Kuboard 页面完成——工作负载编排、日志终端排障、RBAC 权限和操作审计，页面化让团队里不熟 kubectl 的同事也能安全自助；变更管理：节点维护走 cordon/drain 三步，发布配合开发做滚动更新和回滚。还有一条规范线：我把证书提前 30 天续期、etcd 快照备份、故障切换演练这些写成了运维规范——建成后"守"的体系是我搭的，这套"建设+守护"的完整链路是这条简历的含金量。
- 真实数字锚点：7 台 ECS（3+3+1）、三可用区、CLB 四层 6443、v1.28.2/containerd 1.7.8/Flannel、99.99% 设计目标口径、日常 80% 页面操作。
运-2 「主导企业知识库与 RAG 智能问答建设，支撑售前、研发的快速问答与新员工方案学习，组织 AI 工具培训」
- 涉及知识点 → 第 11 章全部（本章只给 60 秒版，深挖去 11 章）。
问①这个项目解决什么问题、怎么做的？（约 250 字）： 解决两个真实痛点：新员工学方案要翻几十份文档、售前被同类问题反复打扰——重复答疑吃时间，经验散在个人脑子里。方案是三层支持体系：知识沉淀层，用阿里云百炼 API 加 Cherry Studio 搭企业知识库和 RAG 问答，把公司全部《解决方案》和技术文档入库，做成可检索可问答的知识资产；自动化层，用 Coze 搭工作流处理方案要点提取、通知推送这类重复事务；人工支持层，知识库覆盖不了的走正常支持流程，处理完再沉淀回库——正循环。治理侧我统一管 API 密钥、账号权限和成本（月 5000 元以内），重要新模型上线就测评出报告，全员分场景培训，沉淀提示词模板库。效果：RAG 问答成了售前研发的日常工具，新员工学习周期和重复答疑成本明显下降。我的定位一句话：把支持经验变成组织里人人可自助取用的服务——这是我支持方法论的 AI 化。
问②RAG 是什么原理？60 秒版。（约 200 字，深挖去 11.2）： RAG 就是检索增强生成，一句话：让大模型开卷考试而不是闭卷瞎猜。五步：文档切分成几百 token 的片段（相邻留重叠），用 embedding 模型把每个片段向量化存进向量库；用户提问时问题也被向量化，按语义相似度召回最相关的片段；再经过重排模型精选；最后把问题、片段、"仅根据资料回答"的指令拼给大模型，生成带出处的回答。适合企业知识四个理由：文档更新重新入库就行不用训模型、回答能溯源、能按权限控制召回范围、成本比微调低一个量级。我们的知识库就是这么建的，我自己维护更新流程——新方案发布重新入库、评测集验证，检索质量问题基本都是切分参数的事，我有第一手踩坑体感（表格切分那单最典型）。
问③知识库怎么运营的？（支持版必问）（约 220 字）： 运营是这个项目的灵魂，我做四件事：一是事件驱动的更新流程——新方案发布、文档改版、故障复盘完成，触发"更新→重新入库→评测复测"的标准清单；二是"谁产生谁入库"的责任约定——支持工单沉淀的 FAQ 由处理人自己入库，知识库不做我一个人的体力活；三是内容保鲜——旧版本方案统一清理只留最新、每篇文档标注更新日期责任人，防止过时内容冒充答案；四是效果度量——月活用户、问答次数、评测集准确率和幻觉率、高频问题节省的答疑工时，四个指标一张面板，对上汇报用规模和收益、日常运营盯质量和健康度。死库是知识库项目的常态结局，我能讲清楚"怎么让它一直活着"——这是我比"搭过知识库"的人多出来的一层。
- 真实数字锚点：全部《解决方案》入库、月成本 5000 元以内、评测集 20-50 题、三-四指标运营面板、全员分场景培训。
运-3 「负责公司内部桌面运维与 IT 支持（Windows/macOS、办公软件、打印机、门禁等），建设并维护 IT 知识库、SOP 与故障处理手册」
- 涉及知识点 → 第 15 章（桌面运维王牌章）、第 11 章（知识库）。
问①桌面运维占你多少精力？你怎么看这份工作？（约 240 字）： 大概两成精力，而且随知识库完善在下降。怎么看这个问题我答得很坦然：小公司的一线岗位本来就一专多能，桌面支持是我的职责现实，我不觉得它低端也不刻意拔高。具体做的工作：Windows 和 macOS 系统与办公软件的日常维护（系统故障、软件报错、账号权限）、打印机门禁等办公设施的排查（打印机驱动和网络打印是绝对高频）、IT 资产与账号权限管理（入离职的账号开通回收、设备台账）。这段经历给我两样东西：一是直接面对同事的服务训练——把"电脑坏了"这种模糊描述收敛成具体问题，和把"服务不通"收敛到某一层是同一个能力；二是我做出的增量：把高频问题全部写成 SOP 沉淀进 IT 知识库，同样的问题第二次出现我发个链接就解决——遇到重复劳动就想办法自助化，这个方法论最后长成了项目二的 RAG 知识库。所以这条经历和 AI 项目是连续的故事：从传统知识管理到智能知识管理。
问②IT 知识库怎么建的？（约 220 字）： 三步。第一步选题：从工单和被问频率里挑高频问题——软件安装报错、网络连接、打印机配置、账号权限这些 TOP 问题；第二步标准化：每个问题按"现象、原因、解决步骤、截图"的固定格式写成 SOP，保证不懂技术的同事也能照着自助——写的时候我会念给非技术同事听一遍，听不懂就重写；第三步运营：知识库持续维护，新问题处理完必须沉淀进去，定期清理过时内容——让它成为活文档而不是死档案。效果：事务性支持的时间明显下降，同事能自助的就自助了，剩下找到我的都是新问题，处理完又进库——正循环。后来项目三的 AI 知识库就是在这个基础上升级的：先有 SOP 数字化打底，接上 RAG 之后检索问答水到渠成。这条经历是 AI 项目的前史，两个串起来讲是一个完整的成长故事——这也是我面试支持岗最喜欢讲的一段。
问③入离职的账号和资产管理怎么做？（约 200 字）： 标准流程加清单。入职：按岗位模板开通账号（域账号、邮箱、业务系统权限按最小权限给）、发放设备并登记台账（型号、序列号、使用人、时间）、安全基线设置（密码策略、杀毒软件）；离职：回收清单化执行——账号停用、权限回收、设备回收入库、数据交接确认，特别是密钥类（我的 AI API 密钥管理是"离职即回收"）——权限残留是安全审计的常见扣分项，清单化执行就不会漏。资产台账我维护成表格加定期盘点：每季度对一次账，账实不符的查明原因。这些工作看起来琐碎，但它是企业 IT 治理的地基——账号权限和资产是安全合规检查的必查项，我做这套的时候顺手把台账对齐了合规要求。支持岗讲"资产与权限管理"，能讲到清单化、最小权限、闭环回收这三点，就是有体系的做法。
- 真实数字锚点：约两成精力且随知识库下降、SOP"现象-原因-步骤-截图"四段式、季度盘点、离职回收清单化。
第三部分 项目一：银行数字人民币智能合约引擎实施与驻场技术支持（2023.08–2025.06）
P1-1 「负责 FusionCompute 虚拟化底座、Kubernetes 集群（含多 master 高可用改造）、Vastbase 一主一备数据库集群的部署与验收」
- 涉及知识点 → 第 08 章（虚拟化）、第 06 章（K8s 高可用）、第 03 章（Vastbase）；深挖见华为篇 02/04 与项目一笔记。
问①部署和验收你具体做了什么？（约 260 字）： 三大块。虚拟化底座：通过 iBMC 远程控制台完成 CNA 三台加 VRM 一台的安装（镜像挂载、RAID 规划——系统盘 SAS 组 RAID1、数据盘 SSD 组 RAID5、Disk Cache Policy 按 Vastbase 规范设 Disabled），配置集群、分布式交换机和各 VLAN 端口组，批量发放 15 台以上统信 UOS 和麒麟 V10 虚拟机，逐台过基线；K8s 集群：在统信 ARM 环境装 Docker 18.09（aarch64 静态包）和 kubeadm，先搭单 master，业务要求高可用后升级成三 master——负载均衡监听 16443 避开 6443 冲突、补证书 SAN、Keepalived VIP 漂移加健康检查脚本，主节点关机实测 VIP 秒级漂移才算验收通过；Vastbase：两节点同时执行安装脚本（误差不能超过 10 秒）、HAS 高可用加 DCS、license 配置，验收四步——查 DCS、查 HAS、查集群主备状态、vsql 加 DataStudio 远程连接实测。三块的验收清单都是我出的，整体一次通过银行客户验收。
问②单 master 升多 master 的关键点？（约 220 字，深挖六步见项目一笔记）： 支持岗讲这个题我抓三个关键点加一个教训。关键点一：负载均衡监听 16443——负载均衡和 master 复用一台机器，6443 已被本地 apiserver 占用，端口规划要避冲突；关键点二：证书必须重签——kubeadm 的 apiserver 证书只包含初始化时 certSANs 里的名字，新增 VIP 和 master02/03 必须补进 certSANs、移走旧证书重新签发；关键点三：验证要实测——Keepalived 的 priority 主备拉开 100 比 90，健康检查脚本盯 16443 真实端口监听，上线前主节点直接关机实测 VIP 漂移加集群正常。教训就是证书那单：升级后用 VIP 连集群报 x509，openssl 查证书 SAN 发现没有新地址——"改集群入口地址必须先想证书"成了我的规则级教训，后来移动云项目初始化就把 CLB VIP 写进了 certSANs，这个坑再没出现。
问③Vastbase 为什么用它、怎么验收的？（约 200 字）： 为什么用是三个硬约束：信创目录要求（金融场景必须国产数据库）、华为 BCS 的配套认证体系、对鲲鹏 ARM 原生适配——安装包就是 aarch64_kunpeng 专用包。它是 openGauss 生态的商业发行版、PostgreSQL 系，vsql 和 DataStudio 工具链与 PG 兼容。部署用海量侧的自动化脚本，两节点同时执行、时间误差不能超过 10 秒——保证集群初始化状态一致；装完 systemctl enable has dcs。验收四步：查 DCS 分布式一致性服务状态、查 HAS 高可用组件状态、查数据库集群主备角色和复制链路、vsql 建用户建库后用 DataStudio 做真连接测试。我们还调过两个参数：max_connections 从 100 到 10000 加开线程池——按业务侧连接规模评估的，不是拍脑袋。踩过的坑是 license 替换要先重启一个节点就绪后再重启另一个，避免双主——"集群操作分批加观察"的习惯就是那单养成的。
- 真实数字锚点：CNA×3+VRM×1、RAID1+RAID5、15+ VM、16443 端口、priority 100/90、Vastbase 一主一备、max_connections 100→10000、两节点安装误差 ≤10 秒。
P1-2 「驻场承担平台一线技术支持：处理环境异常、登录失败、服务不可用等问题，定位问题层级，疑难问题记录并协同华为原厂二线处理，跟踪闭环」
- 涉及知识点 → 第 09 章（工单五步）、第 06 章（分级转判）、第 04 章（登录异常）、第 14 章（案例）。支持岗最核心的项目职责，五个问题。
问①驻场支持具体处理哪类问题？占比如何？（约 230 字）： 三类问题为主。环境异常类：服务器资源异常、磁盘告警、服务进程挂掉、网络不通——大概占四成，靠巡检和告警主动发现加用户报障；登录与使用类：用户报登录失败、页面报错、功能异常——占三成多，高频且单量最大，我沉淀了固定排查链（后面细讲）；使用咨询类：功能怎么用、数据怎么看、权限怎么申请——占两成，这类问题后来大多进了 FAQ 和知识库自助化。剩下的一成是变更配合类：版本升级、割接保障、数据订阅这些计划性工作。总量上一年的工单量在几百单量级，一线闭环率大概八成，剩下两成转二线和原厂——转出去的也全部由我跟踪到闭环。这个结构对支持岗很有代表性：高频问题自助化、疑难问题流程化，是我从那时候就形成的打法。
问②"用户报无法登录"你怎么排查？（必考题，约 280 字）： 我的排查顺序从入口往里、从网络到应用，六层五分钟内定位到层。第一层用户侧：这个用户还是所有用户、用户的网络能不能通到平台 VIP——ping 加 telnet 443，一个人的问题和所有人的问题是两种方向；第二层入口层：Nginx 是否存活、443 证书有没有过期——证书到期这种"慢故障"专坑登录；第三层应用层：后端 Java 进程在不在（jps）、8080 端口监听正常吗；第四层依赖层：后端日志里数据库和 Redis 连接有没有报错——这是最高频根因；第五层数据库层：Vastbase 主备是否发生过切换、连接串指向的 VIP 是否正常——我处理过主备切换后连接串没更新的批量登录失败；第六层中间件层：BCS 证书是否到期（p12 证书有有效期）。每层排除一层，剩下的就是答案。处理完的闭环动作：告诉用户根因（用他能懂的话）、恢复验证、高频根因进 FAQ——登录类问题我在知识库里积累了一个完整的决策树。
问③定位问题层级是什么意思？怎么练的？（约 220 字）： "定位问题层级"就是把模糊的报障收敛到明确的责任层——网络层、系统层、容器层、应用层、数据库层还是产品层，层级定了，处理人就定了（我处理、转二线、转原厂）、动作就定了。我的方法三层：第一层问对问题——现象、时间、范围、最近变更四要素，"最近改了什么"命中率最高；第二层分层验证——每层用该层的证据排除：网络用 ping/telnet/traceroute、系统用 top/df/journalctl、容器用 kubectl get/describe/logs、应用看日志、数据库看连接和主备状态，从外到内每层拿到事实再往下；第三层对照验证——故障时刻监控曲线、变更记录、日志时间戳三方对齐。这套能力是几百单工单喂出来的：早期我也要层层试，后来每类问题形成了"第一嫌疑层"的条件反射——比如发布后故障先看应用层、无变更突发先看资源层。面试官问这个问题，听到"条件反射"三个字基本就知道是真干过的。
问④和华为原厂怎么协同的？举一单完整的。（约 260 字，完整 STAR 见第 14 章 S3）： 我的协同模式是"证据包+跟踪闭环"。定位到产品层后，我打七件套证据包：问题概述、环境版本配套（FC 8.3.0、BCS 1.2.6 这类配套表信息原厂第一个就要）、原始日志（按时间窗截取、标时间戳来源）、告警记录、已做尝试、复现条件、期望与约束——一次给全，原厂最烦挤牙膏式补充。举一单：BCS 平台某组件认证间歇性失败，我把应用层和配置层排完都正常，命中"产品层+反复复发"的转判标准；证据包里我特意做了两件事——把组件日志时间戳和 NTP 校准后的标准时间对齐（后来证明这正是破案关键：组件间时钟偏差导致证书校验间歇失败）、给出稳定复现的规律。转案后我每半天跟进一次、每阶段同步客户一次，原厂定位后给出补丁方案，我在变更窗口配合实施、验证、归档。沉淀两条：时间同步检查进了所有环境的初始化基线；"复现条件"从可选项变成证据包必填。这单让我明白：跨组织协同里，证据质量就是话语权。
问⑤怎么跟踪闭环？闭环标准是什么？（约 220 字）： 跟踪的纪律三条：转派后我仍是第一责任人——每单有唯一的跟进人（我）、有下次跟进时间点（紧急的每小时、一般的每天，"我会再联系你"必须带具体时间）；每次跟进记进工单时间线——谁接的、什么进展、什么时候回来，客户侧的同步不间断，不让任何一单在我手里失联；主动要进展而不是等通知——催要带着新信息去催，空喊"快点"没有用。闭环标准是三层验证：技术层（Pod Ready、日志无错、指标回归）、业务层（客户实际功能验证——登录一次、下一单，"系统看起来好了"不算数）、记录层（工单补全、客户确认关单）。闭环后还有增值动作：自问会不会复发——会就写 FAQ 或加告警。两年下来我的闭环口碑是客户验收时被点名称赞的："问题在我手里不会丢"这句话，是用几百单的跟踪记录换来的。
- 真实数字锚点：年工单数百单、一线闭环约八成、登录六层排查链、七件套证据包、三层闭环验证、NTP 时间线破案案例。
P1-3 「负责日常巡检与 Prometheus 监控告警响应，配合版本升级与割接保障」
- 涉及知识点 → 第 07 章（告警响应）、第 01/02 章（巡检与脚本）。
问①监控体系是什么样、你负责哪部分？（约 220 字）： 按 BCS 平台的监控规范部署 Prometheus 2.33.5 加 Node Exporter 1.3.1，部署在 monitor 命名空间——Node Exporter 以 DaemonSet 跑在每个节点采 CPU 内存磁盘网络，Prometheus 抓取后出资源看板。ARM 内网环境有个特殊处理：所有镜像走离线导入，我复用了批量加载脚本。我的职责是部署、日常值守和告警响应：每天看大盘扫异常、告警按分级流程处置（第 7 章七步）、磁盘和证书这类慢故障纳入周巡检。这个项目的监控是"基础够用"的定位——节点层和平台层有数可看有警可报；到移动云项目我把它升级成了自选型的完整体系（独立监控节点加集群内混合部署、三层指标、告警分级降噪）——从"配套部署监控"到"设计监控体系"，这条演进线是我面试监控话题的叙事主线，两个项目正好是台阶的两级。
问②割接保障你做过什么？（约 220 字）： 割接就是业务切换类的大变更，我的保障动作按时间轴分三段。割接前：参与方案评审确认回退方案——金融环境没有回退方案的割接不启动；准备验证清单（割接后逐项验证的功能和指标）、把监控告警的阈值和静默提前配好（割接窗口的变更类告警静默、真故障通道保持畅通）。割接中：现场值守盯监控大盘，按验证清单逐项确认，异常立即按预案处理或触发回退决策——我的角色是"技术值守+第一响应"。割接后：观察期盯指标（通常是当天加第二天），出割接报告（时间线、验证结果、遗留事项）。这套流程的价值在"清单化"：割接这类高压场景下人容易漏步骤，清单是唯一可靠的——这个习惯一直延续到我后来所有变更操作：先清单、再执行、后验证。
- 真实数字锚点：Prometheus 2.33.5 + Node Exporter 1.3.1、monitor 命名空间、ARM 离线导入、割接三段保障（前清单/中值守/后观察）。
P1-4 「输出部署指南与常见问题文档，组织客户使用培训与验收知识转移」
- 涉及知识点 → 第 12 章实-4（同一职责的项目版）、第 11 章、第 13 章。
问①验收交付你做了什么、流程是什么？（约 230 字）： 四段式交付。环境验收：K8s 全组件 Running、etcd 健康、Vastbase 主备正常、平台功能冒烟——按我出的验收清单逐项打勾，双方同一张表；文档交付：部署指南、IP 规划表、巡检手册、FAQ 正式移交，验收报告里逐项列明；客户培训：平台使用、日常巡检要点、告警处置的实操培训——分场景带演练，对象是客户运维对接人；驻场保障：上线初期现场值守，稳定后转日常支持。整个验收一次通过。我的角色特别之处是"实施者即文档作者"：部署过程踩的每个坑都当场记下来进文档——iBMC 键盘布局、license 分批重启、双节点安装时序，这些文档里别处查不到的内容恰恰是最值钱的部分。这套"边做边沉淀"的习惯后来贯穿我所有项目：移动云的 9 项避坑清单、AI 项目的提示词模板库，都是同一个方法论的不同载体。
问②培训冷场或客户不参与怎么办？（约 200 字，行为题预演）： 我遇到过培训现场客户对接人被动听讲的场面，处理办法三招。第一招改变形式：把"我讲你听"改成"你操作我纠偏"——发一个真实的巡检任务让对接人现场做一遍，做过的东西忘不掉；第二招绑定他的利益：明确告诉他"学会这三项，日常八成的告警您自己就能处理，不用每次等我们响应"——培训的价值感是参与者自己的时间；第三招小步多次：一次讲透一个场景，每周一次比一次三小时有效得多。后来那期培训结束时，客户对接人已经能独立处理日常巡检和一般告警，我们的重复支持量明显下降——客户领导在验收会上专门提了这个。培训的本质不是输出知识，是帮对方建立"自己能行"的路径——这个认知对支持岗特别重要。
- 真实数字锚点：验收一次通过、四段式交付、文档里全是现场踩坑实录、客户对接人独立处理日常告警。
第四部分 项目二：企业知识库与 AI 智能问答支持体系建设（2025.07–2026.10）
项目二定位是支持版差异化王牌：面试官不一定懂 AI，但一定好奇"支持岗的人为什么做成了一件 AI 项目"。所有回答收在"知识运营、降本增效、治理合规"这些支持关键词上，技术原理按第 11 章展开。
P2-1 「基于阿里云百炼 API + Cherry Studio 搭建知识库与 RAG 问答：导入公司全部《解决方案》与技术文档，支撑售前快速问答与新员工入职方案学习」
- 涉及知识点 → 第 11 章全部。
问①为什么做这个项目？需求从哪来？（约 220 字）： 需求是我自己岗位上的真实痛点：作为内部 IT 支持和知识管理承担者，我每天被两类重复问题包围——新员工入职学方案要翻几十份文档、售前被"方案能不能支持 XX"这类问题反复打扰；更结构性的问题是经验散在个人脑子里，人一走经验就没了。我做过传统的 IT 知识库和 SOP（运-3 那条），但文档多了检索又成了新问题——RAG 恰好补的就是"快而准的检索层"。所以立项逻辑是：痛点真实、我有选题权、我有治理能力（密钥、权限、成本），并且我做过知识管理的前置工作——四条件齐了就做了。面试讲这个立项故事的价值：它证明我不是跟风做 AI，是从支持工作里长出来的需求——"从业务痛点出发"这六个字比任何技术名词都有说服力。
问②知识库怎么搭的、导入什么内容？（约 240 字）： 搭建链路七步（详见 11.6）：数据准备（剔过期、敏感脱敏——报价和客户名单绝不进全员库、格式统一转 Markdown）→ Cherry Studio 加百炼 API → 配中文 embedding 和切分参数（几百 token 加 10%-20% 重叠）→ 分批导入并检查切分预览 → 建问答应用写系统提示词（仅依据资料回答、不知道就答不知道、给出处）→ 评测集验证调优 → 上线治理。导入的内容是公司全部《解决方案》和技术文档——包括我这些年写的部署指南、SOP、FAQ，形成"方案库+技术库"两个库。两个核心场景：售前快速问答（方案要点、案例、规格秒级自查、带出处可核对）和新员工方案学习（知识库当随身师傅、配两周学习路径清单）。调试期最有代表性的坑是表格类文档被切分打散导致答案破碎，改成按章节切分后解决——这个案例我每场面试都讲，因为它证明我运营过而不是搭完就走。
问③效果怎么衡量？（约 220 字）： 四个指标（详见 11.8）：使用规模——月活用户和问答次数，验收底线是"售前和研发当日常工具用"，数据上核心用户每周多次；问答质量——评测集准确率和幻觉率，20-50 题定期跑，参数调整前后对比；效率收益——高频 TOP20 问题的月提问次数乘以人工答疑平均耗时，估算每月节省的支持工时，汇报时如实说明这是估算口径；内容健康度——条目总数、月新增、超期未更新数。对上汇报用规模和收益（管理层语言），日常运营盯质量和健康（运营语言）。一个如实的话：我没有做过严格的对照组实验来量化"效率提升百分之多少"，我的数字是"重复答疑量明显下降 + 新员工学习周期从一个月级到两三周"这种有观测依据的表述——支持岗讲效果，诚实的数据比漂亮的数字更可信。
- 真实数字锚点：全部《解决方案》入库、七步建设流程、表格切分坑、四指标面板、月成本 5000 元以内。
P2-2 「使用 Coze 搭建自动化工作流，覆盖信息收集、内容生成与通知推送等重复性事务」
- 涉及知识点 → 第 11 章（11.12 工作流与 Agent）。
问①举一个具体的工作流例子？（约 230 字）： 最有代表性的是"方案要点提取"流程：输入一份新方案文档，自动输出三样东西——结构化摘要（背景/架构/亮点/报价模式四段）、适用客户画像、售前三句话卖点，格式化后发到指定群，售前出新方案当天就能拿到可用的速览卡。节点编排五步：文档读取节点解析正文 → 大模型节点一做摘要（方案分析师角色）→ 大模型节点二做售前话术（资深售前角色，吃节点一的输出）→ 格式化节点拼固定模板 → 通知节点发群；每个节点配失败重试和异常提醒。三个设计点我必讲：主流程用固定工作流不用自由 Agent——可靠性优先，每步确定可控；两个大模型节点各司其职，提示词短而专，比一个大提示词效果好还省 token（成本控制的落点）；输出格式固定，下游好消费、好审计。这个工作流的价值是把"新方案发布后的传播"从人工整理半天变成自动十分钟——重复事务流程化的典型样板。
问②工作流和 Agent 的区别？你为什么主流程用工作流？（约 210 字）： 工作流是人预先画好的固定流程图，每一步干什么、怎么分支都是人定义的，确定性执行，可靠但死板；Agent 是给目标让它自己拆任务、调工具、看结果、循环直到完成，自主灵活但结果有不确定性。我的实践是混合：主流程用 Coze 工作流保证每步可靠，个别需要弹性判断的环节嵌 Agent 节点。多 Agent 协作（deepagents 那类框架）我了解思路，但我们的业务单 Agent 加固定工作流就够——不上多 Agent 是刻意的复杂度控制：token 消耗成倍、链路长、不可控点多，企业场景可靠性优先。Function Calling 和 MCP 我也有实操认知：Function Calling 是模型输出调用决策、执行在应用侧（权限白名单握在人手里），MCP 是工具接入的统一协议，我在 Cherry Studio 里接过 MCP Server 扩展能力。我的 AI 观：能落地的才是能力，激进的概念只做跟踪——信息宽松、引入严格。
- 真实数字锚点：方案要点提取五节点工作流、双模型节点分职、失败重试分支、"自动十分钟替代人工半天"。
P2-3 「每逢重要新模型上线即测评并输出选型报告全员分享；统一管理 API 密钥、账号权限与成本（月 5000 元以内）」
- 涉及知识点 → 第 11 章（11.8 测评与成本、密钥治理）。
问①测评怎么做的？评什么？（约 230 字）： 原则是"用自己的业务题测，不看发布会"。四步：建评测集——从公司方案文档和售前真实提问里整理 20 到 50 道标准问答，覆盖高频场景，专门留一部分"文档里没有"的陷阱题考它会不会承认不知道（防过拟合的第二个抓手）；同条件实测——同题、同提示词、同温度参数跑新旧模型，控制变量；人工评分——答对、答错、编造三类打标，编造单独统计就是幻觉率，同时按 token 用量算单次问答成本；出报告决策——综合准确率、幻觉率、成本三项给结论，报告全员分享。有一次的结论很代表性：新旗舰质量确实提升但单次成本接近翻倍，最终"仅在核心问答场景切换、日常任务维持原模型"——没有数据就做不出这种精细决策，要么全换浪费钱、要么不换浪费效果。这套方法把"模型好不好"从感觉变成数字，也是我"持续跟踪 AI"的实际形态：事件触发式测评，信息宽松、引入严格。
问②成本和密钥怎么管的？（约 230 字）： 成本三板斧加一个复盘：模型分级——简单任务用便宜模型、旗舰只给复杂任务，这一项贡献最大（不同档位单价差几倍到几十倍）；提示词瘦身——系统提示和召回片段控制长度，每个 token 都是钱；分密钥监控——按应用分 API Key，谁在调、调多少、花多少一目了然，配预算告警异常暴涨当天发现；加每月复盘账单持续调优。结果是月成本稳定在 5000 元以内——简历上唯一量化的成本数字，有账可查。密钥三条纪律完全是运维账号管理的平移：密钥不外发——统一由我在平台侧配置，应用引用配置，绝不硬编码明文，跟数据库密码不进代码是同一条规矩；按应用分密钥——账目隔离、权限隔离，泄露了一眼定位；定期轮换加离职即回收。我把 API Key 当一类密钥资产管理，纳入和服务器账号同级的安全纪律——"运维人做 AI 治理是降维"这句话就是从这来的。
- 真实数字锚点：评测集 20-50 题含陷阱题、三类评分+成本核算、"核心场景切换"精细决策、月 5000 元以内、密钥三纪律。
P2-4 「面向全员组织 AI 工具培训，沉淀提示词模板与实践案例库」
- 涉及知识点 → 第 11 章（11.11 培训组织）、第 13 章（培训表达）。
问①培训怎么组织的？（约 230 字）： 四条原则。分场景不讲概念：按受众分组——售前组教"怎么问知识库"（提问模板、核对出处）、研发组教"AI 编程提效"（提示词写法、生成代码怎么审）、全员组教办公模板（周报、纪要、润色）；每次只讲一个场景练一个模板。模板先行：培训配套的提示词模板当场发放归档进公司模板库（方案摘要、周报生成、招标应答初稿等十几个场景），学员回去复制粘贴就能用——培训的交付物是模板不是课件。效果看使用数据：培训后盯应用调用量和用户真实产出案例，数据不涨就分析原因再改进，不办完就散。培养种子用户：每个部门找一两个活跃用户深度培养，让他们成为身边人的第一求助点——推广靠种子不靠我一个人的嗓子。结果：AI 工具和知识库成为公司日常工具，模板库和案例库沉淀成组织资产。我的培训观：工具再好没人用等于零——推广能力是支持岗的硬技能。
问②遇到抵触或不感冒怎么办？（约 210 字）： 真实处理过，策略是"降低门槛+展示利己"。不谈趋势谈痛点：先不劝"你们要用 AI"，拿对方自己的痛点开刀——"您上周整理那批方案要点花了两天，我用模板十分钟出了初稿给您看看"，演示利己比讲道理有效十倍；降到零门槛：给对方配好模板、教到复制粘贴就能用的程度——抵触大多来自"又要学新东西"的疲惫；借力样板：同部门先行者的真实案例由同事口述传播，比行政强推自然。底线是不强迫不考核羞辱——工具推广是服务不是行政，留足体验期，大多数人用过会自己留下。我的体会：推广新工具的难度和技术无关，和"改变别人的习惯"有关，所以方法必须服务型——这本身就是支持思维的迁移，也是我简历"沟通表达与培训能力强"的实底。
- 真实数字锚点：分场景分组培训、十余个场景模板库、"模板即交付物"、种子用户扩散机制。
第五部分 项目三：移动云 Kubernetes 集群与可视化运维管控体系建设（技术底座，2025.07–2026.10）
项目三支持版口径：按"技术底座"讲——它是公司外包业务的基础设施，我的角色是建设者加日常支持者。面试支持岗时这个项目证明"我有生产 K8s 背景能撑住平台类支持"；深挖到命令级去两份项目笔记和第 6/14 章。
P3-1 「负责方案编制与部署实施，完成全量健康验证与故障切换演练」
- 涉及知识点 → 第 06 章（K8s 部署与验证）、第 09 章（CLB/VPC）。
问①方案编制和部署你做了什么？（约 250 字）： 方案四件事：资源评估——按业务规模测算节点数量规格，定下 7 台 ECS 的配置清单（master 2C4G、worker 8C16G、监控 4C8G）；架构选型——3 master 跨三可用区、CLB 统一接入、Flannel 网络插件，每个决策写清理由（etcd 奇数副本是多数派数学、云上选托管 CLB 是因为无单点免运维且我在银行做过自建方案有对比）；部署顺序设计——初始化→控制平面→CNI→worker→健康验证→监控的完整步骤；风险清单——把可能踩的坑提前列出。部署按方案执行：全节点标准化初始化（关 swap、内核参数、chrony 时间同步、containerd 三件套配置）、kubeadm 起 v1.28.2 三副本控制平面、Flannel 先于 worker 部署、worker 批量加入。过程踩的 9 个坑全部解决并沉淀成生产避坑清单——NotReady 镜像、crictl socket、etcd 命名这些每条都是"现象→根因→解法→预防"的完整故事。方案后来成为公司外包项目的标准底座——"照着重放就能开环境"就是标准化的意义。
问②健康验证和故障切换演练怎么做的？（约 230 字）： 全量健康验证三层：集群层——get nodes 全 Ready、kube-system 全部 Pod Running、etcd 三副本 endpoint health（带三证书连 127.0.0.1:2379）；功能层——kubectl 经 CLB VIP 的增删改查全通过、Service 转发正常；配套层——监控大盘数据到位、云数据库和 Redis 连通。故障切换演练四步完整做过：停掉一台 master 的 kubelet 模拟节点故障 → CLB 健康检查秒级把该后端摘除 → 经 VIP 执行 kubectl get nodes 正常返回（客户端无感）→ 恢复 kubelet，控制面组件自动重启、etcd 自动同步重新加入。演练结论八个字：秒级摘除、无感切换——这是实测结论不是宣传语。我的口径纪律：99.99% 是设计目标，讲保障机制不讲实测 SLA；Worker 层的保障另算——业务多副本加反亲和，节点故障 Pod 分钟级迁移。"高可用是设计出来的，更是演练出来的"是我从这次演练得到的信条。
- 真实数字锚点：7 台 ECS、v1.28.2、9 项避坑清单、演练四步"秒级摘除无感切换"、99.99% 设计目标口径。
P3-2 「部署监控告警体系与 Kuboard 可视化平台，日常通过告警与平台快速定位处理异常」
- 涉及知识点 → 第 07 章（监控）、第 06 章（K8s 排查）。
问①监控为什么这么部署？（约 230 字）： 混合部署是按"每个组件放哪最合适"分别决策的。Prometheus 和 Grafana 放独立监控节点二进制部署：不占集群资源，且故障隔离——集群出问题时监控还活着，"观察者不能和被观察者一起死"；kube-state-metrics 必须在集群内：它的职责就是监听 K8s API 暴露对象状态指标，离开集群无从工作；node-exporter 是 apt 装的二进制版：内网仓库没有它的镜像，二进制版默认 9100 端口和容器版指标完全兼容——"容器不可得时二进制等价替代"。采集发现用 static_configs 静态配置：六台节点加 kube-state-metrics 加经 CLB VIP 的 apiserver，规模小变更少，静态最直观可控，规模上去再换服务发现——取舍理由能讲清。告警规则第一条永远是 up==0（监控自己先兜底），然后资源类、对象状态类逐层铺，全部经过停 exporter 的全链路演练。这套设计的每个选择我都能讲"为什么"——这是我从"配套部署监控"到"设计监控体系"的台阶证明。
问②Kuboard 起什么作用、怎么部署的？（约 220 字）： 作用是可视化运维操作台：工作负载编排、发布回滚、实时日志、进容器终端、RBAC 多级权限、操作审计——日常 80% 的运维操作在页面完成，给不熟 kubectl 的同事降低了门槛，权限审计保证了"能点"不等于"乱点"。部署五步我亲手做的：公网节点拉取 kuboard 镜像 → tag 后推到内网私有仓库（镜像双轨体系的一环）→ 建命名空间和 docker-registry 认证 Secret → Deployment 四个关键配置——nodeSelector 固定调度到 master-01（管控链路最短）、tolerations 容忍 control-plane 污点、imagePullSecrets 挂认证、hostPath 用 DirectoryOrCreate 做持久化 → NodePort 30088 暴露。持久化我实测验证过：手动删 Pod 触发重建，重新登录配置和审计记录都在——数据确实落在节点本地。这套部署细节是"真做过"的铁证，被深挖时每一步都答得上来。
- 真实数字锚点：独立监控节点 4C8G、kube-state-metrics NodePort 30080、up==0 第一条告警、Kuboard v3.5.2.2 固定调度+hostPath、日常 80% 页面操作。
P3-3 「配套云数据库、消息队列与云安全服务的配置管理」
- 涉及知识点 → 第 09 章（云服务与安全）、第 03 章（MySQL/Redis）。
问①配了哪些云服务、为什么用托管的？（约 230 字）： 配套四类：云数据库 MySQL 8.0 主备高可用（8C16G/300G SSD）、Redis 双机热备、RocketMQ 消息队列两节点、Nacos 注册配置中心；安全配套 WAF、DDoS 原生防护、主机安全、数据库审计——后四件是等保和客户合规的硬性要求。为什么用托管不用自建：业务要快速上线，托管服务自带主备切换、自动备份、监控告警，运维成本远低于自建；同时我坚持一个架构原则——有状态的重服务不进 K8s：数据库跟容器滚动更新模型天然冲突（数据一致性难保证）、伸缩粒度不匹配、故障域耦合，所以数据库用云托管、应用进集群，两层各得其所。我的职责链是：评估业务需求定规格版本、配安全组和访问控制（最小权限只对应用子网放行）、把连接信息标准化交付给应用团队。值得一提的是自建能力我也有——银行项目 Vastbase 一主一备就是我手工搭的——正因为会自建，才知道什么时候不值得自建，这个对比是我的选型发言权。
问②云安全服务分别防什么？（约 220 字）： 按攻击层次说：WAF 部署在 HTTP 入口，防应用层攻击——SQL 注入、XSS、WebShell 上传这类 OWASP Top 10，加 CC 高频恶意请求；DDoS 原生防护防流量型攻击——SYN Flood、UDP Flood 打带宽时在云侧牵引清洗，我们配的是 5G 基础防护；主机安全装 Agent 干两件事——基线核查（弱口令、高危端口、配置合规）和入侵检测（异常登录、WebShell、挖矿进程告警）；数据库审计做全量 SQL 访问留痕，谁在什么时间执行了什么语句可追溯。这四件套是等保测评和客户上线评审的检查项，缺了业务上不了线——合规是硬约束不是可选项。我的角色是配置管理者：策略怎么配、告警级别怎么定、业务发布时怎么放行、审计日志怎么留存。支持岗讲安全的价值在"讲得清每件东西防什么"——客户的安全检查人员问起来，我能对得上专业语言，这在银行项目经历过验证。
- 真实数字锚点：MySQL 主备 8C16G/300G SSD、Redis 双机热备、RocketMQ 两节点、WAF/DDoS 5G/主机安全/数据库审计、"有状态不进集群"原则。
第六部分 三个项目 1 分钟 / 3 分钟逐字稿（支持版口吻）
项目一 1 分钟版（支持视角）
我在银行驻场了近两年，做数字人民币智能合约引擎平台的交付和一线技术支持。平台是华为规划的全国产化架构：TaiShan 鲲鹏服务器、FusionCompute 虚拟化、Kubernetes、Vastbase 数据库加区块链，我负责虚拟化底座、K8s 集群（含三 master 高可用改造）和数据库的部署验收。上线后我转一线支持：日常答疑、巡检、告警响应，疑难问题按"记录—处理—转派—跟踪—闭环"的流程协同华为原厂处理，两年几百单工单，客户问题响应获得认可。我还输出了部署指南和 FAQ，做了客户培训和知识转移——这份指南后来成了公司同类项目的标准文档。这段经历给我最核心的能力是：把一个生产平台的"建设"和"长期守护"都完整做过一遍。
项目一 3 分钟版（支持视角，在 1 分钟版基础上展开三处）
①交付部分：4 台 TaiShan 2280、CNA×3+VRM×1 的虚拟化底座、15 台以上国产化虚拟机批量发放；K8s 从单 master 升级三 master——负载均衡监听 16443、证书补 SAN 重签、Keepalived VIP 漂移实测；Vastbase 一主一备四步验收。ARM 环境踩的坑（镜像架构、离线导入）都沉淀进了部署指南。②支持部分（重点）：驻场支持三类问题——环境异常、登录失败、使用咨询，按工单五步走；分级转判口径清晰：一线处理"现象清晰、可复现、有 SOP"的问题，疑难转二线打七件套证据包，产品级协同华为原厂；举"BCS 组件认证间歇失败"一单——NTP 时间线对齐帮原厂破案，半天跟进一次直到闭环。登录失败的六层排查链（用户侧→入口→应用→依赖→数据库→中间件）能脱稿讲。③收尾：平台通过银行客户验收稳定支撑数币试点，我的文档成了公司标准；角色口径——选型归华为，落地和守护归我，"把它装通装稳装到能交付，并且长期守得住"。
项目二 1 分钟版（支持视角）
2025 年起我主导公司知识库与 AI 智能问答体系的建设，起因是我自己岗位上的痛点：新员工学方案要翻几十份文档、售前被同类问题反复打扰。我基于阿里云百炼 API 加 Cherry Studio 搭了企业知识库和 RAG 问答，把公司全部解决方案和技术文档入库，售前答疑和新员工学习都靠它；用 Coze 搭自动化工作流处理方案要点提取这类重复事务；治理上统一管理密钥、权限和成本，月成本控制在 5000 元以内，重要新模型上线就测评出报告全员分享，还做了全员分场景培训、沉淀提示词模板库。现在知识库是售前研发的日常工具，重复答疑和新人学习成本明显下降——本质是把我做支持的经验，变成了组织里人人可自助取用的服务。
项目二 3 分钟版（支持视角，在 1 分钟版基础上展开四处）
①RAG 原理（被追问概率最高）：切分→向量化→检索→重排→带出处生成，让模型开卷考试；为什么适合我们：文档频繁更新、要引用溯源、要控权限、不用训模型。②怎么建的：数据先脱敏分级（报价客户名单绝不进全员库）、切分几百 token 带重叠、评测集 20-50 题含陷阱题验证；表格被切碎的坑改成按章节切分——这个案例讲"我运营过"。③运营视角（支持版差异化）：事件驱动的更新清单、"谁产生谁入库"、版本保鲜规则、四指标面板（使用规模/命中率/节省工时/内容健康）——我能讲清楚"怎么让知识库不死"。④治理与培训：模型分级加提示词瘦身加分密钥监控把成本压在 5000 内；密钥不外发、按应用分、离职回收；分场景培训加模板库加种子用户。收尾：这个项目证明我做支持不止于"处理工单"——我把支持体系本身升级了一代。
项目三 1 分钟版（技术底座口径）
公司外包业务需要一套标准基础设施底座，我负责在移动云落地：7 台 ECS 跨三个可用区——3 master 三副本控制平面、CLB 四层负载统一入口和健康检查摘除、3 台 8C16G worker 业务池、独立监控节点；K8s v1.28.2 加 containerd 加 Flannel。我完成方案编制、部署实施、全量健康验证和故障切换演练——实测停一台 master，CLB 秒级摘除、kubectl 无感；配套 Prometheus 告警体系和 Kuboard 可视化平台，日常告警响应和快速定位是我负责；部署过程沉淀了 9 项生产避坑清单，这套底座成了公司外包项目的标准基础设施。对我支持岗的意义：平台类支持需要的技术判断力，是这个项目练出来的。
项目三 3 分钟版（在 1 分钟版基础上展开三处）
①为什么这么设计：etcd Raft 多数派所以 3 副本（4 台不划算）；云上选托管 CLB 不自建 Nginx+Keepalived——无单点免运维，而且银行项目我做过自建方案，两个都有实操发言权；跨可用区做机房级隔离。②部署与避坑：全节点标准化初始化（关 swap、内核参数、chrony、containerd 三件套）；部署顺序铁律"先 CNI 后 worker"；挑 1-2 个坑讲透——NotReady 九成是镜像拉取（三层镜像策略解决）、crictl 显式绑定 socket（初始化脚本预置）。③监控与日常支持：混合部署的分工理由（独立节点故障隔离、kube-state-metrics 必须在集群内、node-exporter 二进制等价替代）；第一条告警永远是 up==0；日常通过告警分级加处置手册加 Kuboard 页面快速定位。收尾口径：架构是通用最佳实践，方案编制、部署、验证、运维支持都是我做的——99.99% 是设计目标，保障机制我能讲清楚。
第七部分 衔接问答（支持岗的"为什么是我"）
Q1 你为什么适合做技术支持？（约 280 字）
三个证据链。第一，我验证过：驻场银行近两年就是完整的技术支持岗位——答疑、工单、分级转派、客户培训全流程跑过，客户问题响应获得认可（简历项目成果原话），这不是"我觉得我适合"，是客户用两年验证过的结论。第二，我的能力结构对位：技术上接得住——Linux、网络、容器、数据库的排查能力让我能"定位问题层级"而不是当传话筒；表达上说得清——我能把技术问题翻译成客户听得懂的语言，文档和培训能力让经验可复制；流程上闭环快——"记录—处理—转派—跟踪—闭环"是刻进我工作习惯的五步。第三，我有增量：知识库和 RAG 自助化是我把支持工作升级过的证明——我不只处理问题，我让一部分问题不再需要被处理。一句话总结：支持岗需要的技术、沟通、流程、沉淀四样，我都有真实经历背书。
Q2 驻场两年带给你什么？（约 250 字）
四样东西，每样都有具体载体。第一，流程纪律：工单五步、变更窗口、告警分级、30 分钟时间盒——金融生产环境把"规矩"刻进了我的工作习惯，我到任何新环境都自动执行这套。第二，多方协同能力：客户、我们公司、华为原厂、开发团队四方协同，我是统一接口人——证据包质量、跟进节奏、客户预期管理，这些是跨组织协作的真功夫。第三，技术纵深：从虚拟化到 K8s 到数据库到网络，生产环境的排障能力全是现场喂出来的——登录失败六层排查链这种条件反射，只能在真实工单里练成。第四，服务观：我理解了支持岗的本质是"让客户对系统的信任可持续"——影响面先行、证据说话、承诺带时间点，这三条是我两年服务观的地基。所以驻场对我不是"熬了两年"，是浓缩的训练营。
Q3 你的能力主线是什么？（"接得住、说得清、闭环快"版，约 260 字）
六个字：接得住、说得清、闭环快。接得住是技术底盘：Linux 排障、网络命令树、容器状态检查、数据库路径排查、K8s 分级定位——客户报障到我手里能收敛到层级，不当二传手；三个项目从虚拟化到云原生到 AI 的完整经历是它的底气。说得清是表达层：给客户的告警通报四段模板、给原厂的七件套证据包、给用户的 FAQ、给团队的培训课件——同一件事对四种人说四种话，这是我练出来的翻译能力。闭环快是流程层：工单五步、分级转判、跟踪机制、闭环三层验证——每一单有主、有痕、有结果；而且我闭环后必做沉淀：FAQ、SOP、知识库，让闭环产生复利。三者的关系是递进的：接得住是入场券，说得清是放大器，闭环快是护城河——我的简历和三个项目，都是这六个字的证据。
Q4 你做过实施、运维、支持、AI，你到底是什么定位？（约 240 字）
我的定位一句话：以技术支持为主业、以体系化提能为方法的复合型支持工程师。拆开说：主业明确——我想长期做的是技术支持（答疑、排障、客户服务、知识转移），这是我在银行验证过、也最有积累的方向；"复合"是手段不是漂移——实施交付让我懂环境怎么建（给客户讲架构有底气）、运维让我懂平台怎么稳（告警和巡检是支持的地基）、AI 让我懂怎么把支持体系升级（知识库、自助化、自动化）。四段经历共享一条主线：让用户的问题更快被解决、让同样的坑不再踩第二遍。所以岗位怎么变我不慌：JD 写客户支持、平台支持、IT 支持、知识库运营，我的经历都能对上——因为我卖的不是某个岗位的经验，是一套"支持方法论+技术底盘+提效工具"的组合。
Q5 三个项目时间重叠、角色不同，你怎么平衡和分工的？（约 220 字）
如实拆解：项目一是 2023 到 2025 的主线，驻场全程；项目二和项目三并行在 2025 年 7 月之后。节奏上项目三是主责——建设期约三个月密集投入（方案、部署、验证），建成后转日常运维，占用趋稳；项目二是持续投入型——测评事件触发、知识库维护每周几小时、培训周期性。两者的协同关系大于冲突：项目三把运维标准化可视化之后（Kuboard 覆盖 80% 日常操作），恰好省出了我做项目二的时间——自动化解放的人力去做增量的事，这是运维提效的直接回报，也顺便展示了我的多任务管理方式：主责线保交付、持续线做积累、用工具省出来的时间做下一件事。
第八部分 行为面与开放题（支持版 STAR）
行为题公式：情境（S）→ 任务/难点（T）→ 行动（A，占 60%，必须是"我"的决策与动作）→ 结果（R，带数字或对比）。完整支持场景案例见第 14 章，这里放简历映射题。
Q1 印象最深的一次客户报障处理？（约 280 字）
讲批量登录失败那单（完整 STAR 见 14 章 S1）。情境：工作日早上突然接到多个部门用户报平台登录失败，影响面在扩大。任务：尽快恢复并定位根因。行动：我先按登录六层排查链走——用户侧网络正常、Nginx 和证书正常、后端进程和端口正常；到依赖层抓到了证据：后端日志大量数据库连接失败；查 Vastbase 发现主备在凌晨发生过切换，应用连接串指向的旧主节点没有跟着更新——根因锁定。恢复动作分两步：协调应用侧更新连接配置重启服务，恢复期间我同步通报受影响部门（现象、原因、预计恢复时间）；恢复后逐部门确认登录正常。结果：从报障到全面恢复约 40 分钟，客户方对响应和通报给出了正面反馈。沉淀：把"主备切换后检查应用连接串"写进巡检清单和 FAQ——同类问题再没发生过，这单后来也成了我培训客户运维的教材案例。
Q2 和华为原厂/客户协同推进一件事的例子？（约 260 字）
BCS 组件认证间歇失败那单（完整版见 14 章 S3）。情境：平台组件间认证间歇性失败，应用层配置层排查全部正常，问题反复复发影响业务稳定性。任务：定位并推动解决。行动：我命中"产品层+反复复发"转判标准后，打了七件套证据包转华为原厂——关键动作有两个：把组件日志时间戳和 NTP 校准后的标准时间对齐（主动消除了"日志对不上"这个排查噪音），给出稳定复现的规律（后来确认正是破案关键——组件间时钟偏差）；转案后我每半天跟进一次、每阶段向客户同步一次，原厂定位后我在变更窗口配合实施补丁并验证。结果：问题闭环，"时间同步检查"进了所有环境的初始化基线，证据包模板沉淀为团队标准。这个案例我讲的时候强调方法论：跨组织协同里，证据质量就是话语权、跟进节奏就是信任。
Q3 项目里最大的失误或挫折？（约 260 字）
讲 Vastbase license 替换那次（保留运维版真实素材）。情境：平台上线后数据库三个月免费 license 到期，要替换成正式 license，替换需要重启 HAS 高可用服务。挫折点：我第一次操作时按惯性把两个节点同时重启，集群短暂出现双主风险预警——虽然没有造成数据问题、及时稳住了，但金融生产环境里这是可能出大事的操作，那一刻的后怕我到现在记得。行动：先稳住集群状态，然后复盘——问题出在操作序列，我把流程改造成"先重启一个节点、等它完全就绪并确认主备角色正确后，再重启另一个"的分批规范，写进部署指南的注意事项。结果：后续 license 操作零风险完成，分批规范成了公司标准文档的一部分。教训一句话：凡涉及集群状态的操作，先设计"分批加观察"的步骤再动手——这条后来被我推广到所有重启类变更。这个案例的价值在于主动担责加改进闭环，支持岗面试官最认这种自我修正能力。
Q4 如果重来，项目二你会怎么改进？（约 240 字）
三点，都指向同一个认知。第一，度量先行：知识库上线时我只有简单的使用统计，评测集和运营面板是后来逐步补的——重来我会在上线第一天就建好四指标面板和评测集，让效果从第一天可见，推广说服力会强很多。第二，场景嵌入更深：初期用户要主动打开知识库，入口流失了一批人——重来我会一开始就把知识库嵌入高频工作场景（工单系统入口、群机器人、新人文档），让使用发生在本来就要动作的地方。第三，内容生产更分散：早期 FAQ 主要我自己写，产能受限——重来我会从第一天就定好"谁产生谁入库"的责任约定和十分钟写一条的轻量标准。共同认知：运营和度量不是上线后的补充，是设计的一部分——这个复盘认知本身，就是我到新公司建知识库时的第一版方案。
Q5 你最有成就感的一件事？（约 250 字）
讲知识库成为公司日常工具那一刻。情境：项目二上线几个月后。具体场景：某天我注意到知识库的月问答量稳定过了某个台阶，同时我的重复答疑工单量明显下降——两条曲线一升一降，说明自助分层真的跑通了；更触动我的是售前同事跟我说"现在写标书先问知识库，快太多了"，以及新员工第一周就通过知识库把方案学习路径走完了。结果层面：知识库成了售前研发的日常工具（简历成果原话），提示词模板库和案例库沉淀成组织资产，"选型—使用—成本—合规"的机制留了下来。为什么这件事成就感最高：技术故障解决的是"这一次"，而支持体系的升级解决的是"每一类"——我个人的经验变成了组织的资产，这个杠杆效应比任何单点技术都让我有成就感。它也确认了我的方向：做"让支持更高效"的人，而不只是"处理支持工单"的人。
章末自测清单
- 支持版项目顺序？ → 项目一银行驻场支持、项目二 AI 知识库、项目三 K8s 技术底座——背混是口径漂移头号事故。
- 工作经历两阶段各几条？ → 实施与支持阶段 4 条（实施交付/答疑工单/巡检告警/文档培训）+ 运维与支持阶段 3 条（K8s 底座/知识库/桌面 IT）。
- 工单五步？ → 记录—处理—转派—跟踪—闭环，每步能举真实例子（第 9 章主线）。
- 实-2 的四个必问？ → 一天的工作、工单五步举例、问题分级、驻场最难——全部要求脱稿。
- 登录失败排查链六层？ → 用户侧网络→入口 Nginx/证书→后端进程→依赖（DB/Redis）→数据库主备→中间件证书。
- 分级四条边界？ → 层级、权限、影响面、时间盒（30 分钟）——宁可转早不转晚。
- 原厂证据包七件套？ → 概述、版本配套、原始日志、告警、已做尝试、复现条件、期望约束。
- 闭环三层验证？ → 技术层、业务层（客户实际验证）、记录层。
- 项目一数字包？ → 驻场近两年、4 台 TaiShan、15+ VM、3 master、v1.17.3、Vastbase 一主一备、验收一次通过。
- 项目二数字包？ → 全部《解决方案》入库、月 5000 元以内、评测集 20-50 题、模板库。
- 项目三数字包？ → 7 台 ECS（3+3+1）、v1.28.2、9 项避坑、99.99% 设计目标、日常 80% 页面操作。
- 能力主线六个字？ → 接得住（技术）、说得清（表达）、闭环快（流程）。
- "为什么适合支持岗"三个证据链？ → 验证过（驻场两年客户认可）、能力结构对位（技术/表达/流程）、有增量（知识库自助化）。
- 三个项目 1 分钟稿的共同结构？ → 背景一句话 → 做了什么（数字）→ 支持视角的成果 → 一句能力总结。
- 挫折题用什么素材？ → Vastbase license 双主风险——主动担责+分批规范改进闭环。
- 项目二改进复盘三点？ → 度量先行、场景嵌入更深、内容生产更分散——共同指向"运营是设计的一部分"。
- 培训类问题的通用答法？ → 分场景实操、模板即交付物、效果看使用数据、种子用户扩散。
- 桌面运维被问"低端"怎么答？ → 坦然：职责现实+服务训练+知识库增量——和 AI 项目是连续故事。
- 行为题主语纪律？ → 所有行动描述以"我"为主语，不说"我们"。
- 本章与各章的配合？ → 本章是索引层：被问到哪条 → 按知识点指向去 06/07/08/09/11/14/15 章拿弹药；数字口径以本章为准。