Appearance
第12章 工作与项目问答地图（实施版简历逐条展开）
对应简历：工作经历实施阶段 4 条 + 云平台阶段 3 条 + 项目一 6 条 + 项目二 4 条 + 项目三 3 条，共 20 个问答单元。
用法：面试官的问题 80% 会落在简历某一行上——本章把每一行变成"知识点指向 + 高频问 + 可直接说的完整段落答法（每问 ≥150 字）+ 真实数字"。面试前把本章当索引过一遍：被问任何一条，先反应出对应章号去展开技术细节；流程类问题（割接/验收/培训/八阶段）去第 15 章。术语：Kubernetes（下文简写 K8s）。
12.0 口径总原则（先背这五条再往下看）
- 脱敏红线：不报内网 IP、账号、仓库域名、VPC 网段——一律"某银行内网环境""内网私有仓库"；被追问就说"客户内网信息，签了保密协议"（金融行业这反而是加分项）。
- 角色口径：项目一选型归华为（公司是渠道商），我负责落地交付与验收，上线后一线支持归我、二线转华为原厂；项目二体系是通用最佳实践，方案编制/部署/验证是我；项目三是我主导。
- 数字口径：4 台 TaiShan、15+ 台虚拟机、3 master+10 worker（项目一）/3+3+1（项目二）、Vastbase 一主一备、v1.17.3/v1.28.2、月成本 5000 内、一次通过客户验收——全部有据可查，大胆说；99.99% 是设计目标，不说成实测 SLA。
- 诚实口径：Git/Jenkins/Ansible（技能第14条）是"课程项目实操 + 生产配套"；AI 框架是"自学原型级"；CI/CD 流水线零条生产日常运维，生产做过分发与回滚两端。
- 每条职责的标准讲法：一句话概括做了什么 → 规模/版本数字 → 一个最熟的细节或坑 → 结果（尽量落在"验收/交付/沉淀"上——实施版的结尾词永远是交付物）。
第一部分 工作经历·实施阶段（2023.08–2025.06，驻场某大型银行）
实-1 「驻场某大型银行近两年，作为实施工程师负责数字人民币智能合约引擎平台的全流程交付，与华为原厂协同推进」
- 涉及知识点 → 第15章（交付八阶段）、第08章（虚拟化/硬件）、第12章项目一各条、第13章（驻场意愿话术）。
问①"全流程交付"具体指什么？从哪到哪？： 全流程就是从硬件上架到客户签字验收的完整链条，我的讲法是按交付八阶段走一遍：需求调研（和华为原厂、银行客户对齐版本配套和资源需求）→ 环境规划（IP 规划表、RAID 方案、VLAN 与双平面网络设计）→ 部署（4 台 TaiShan 上架，FusionCompute 虚拟化底座、15+ 台国产化虚拟机、K8s 集群、Vastbase 数据库、BCS 与自研平台逐层部署）→ 联调（前后端联调、平台间接口联通）→ 割接（上线窗口的切换与验证）→ 验收（五组验收清单逐项过、客户签字）→ 培训（客户运维的部署培训与知识转移）→ 质保（上线后驻场支持）。近两年里这套流程我完整走了不止一轮——初建是一轮，后续版本升级、扩容每次都是缩小版的八阶段。"全流程"三个字的底气是：每个阶段我都能讲出产出物和踩过的坑，不是把流程背下来，是每个环节都上手做过。
问②和华为原厂怎么协同的？： 分层协作模型：华为原厂负责产品选型、版本配套和二线疑难支持；我们公司作为渠道商负责现场交付；我在现场是唯一接口人——对银行客户，我是统一对接窗口，巡检报告我出、告警我第一响应；对华为原厂，一线能处理的我自己处理，需要二线的疑难问题，我转案前把现象描述、时间线、日志和告警截图、已做过的尝试全部整理成完整材料，原厂拿到手直接往下查，不用来回要信息。这个模式跑了近两年，客户验收一次通过，没有出过互相推诿的情况。我的心得一句话：接口人的价值不是传话，是让链条上每个人都拿到他需要的东西——客户要"有人管到底"，原厂要"信息完整"，我把两端都喂饱，自己就是那个不可替代的节点。
问③驻场近两年，你是怎么坚持下来的？： 如实答：驻场确实辛苦，但这个项目值得。支撑我的是三个获得感：一是技术成长密度高——国产化全栈从硬件到应用完整走一遍，这种经历跳到哪家公司都是稀缺的；二是被需要的感觉——客户和原厂都依赖我这个接口人，每天的工作有明确的闭环；三是看得见的成果——平台通过验收支撑数币试点运行，我写的文档成了公司标准，这些是留在行业里的东西。从职业角度说，驻场近两年也证明了我的适应能力：独立处理现场问题、多方协调、没有后援也能闭环——这也是我适应新岗位驻场和出差要求的最好证明（这句话顺势把话题引向我的驻场经验优势）。
- 真实数字锚点：驻场近两年；4 台 TaiShan；一次通过客户验收；零推诿记录。
实-2 「负责 FusionCompute 虚拟化底座、DME 管理平台、Kubernetes 集群、Vastbase 数据库集群及国产化软件栈的部署、升级与联调」
- 涉及知识点 → 第08章（FC/DME）、第06章（K8s）、第03章（Vastbase）、第01章（国产 OS）、华为篇 02/03/04。
问①这套国产化软件栈的整体架构？： 我自底向上分四层讲。最底层硬件：4 台华为 TaiShan 2280 鲲鹏服务器，ARM 架构，每台 96 核、384G 内存，双平面组网接 CE 系列交换机；往上一层虚拟化：FusionCompute 8.3.0 做底座，CNA 三台加 VRM 一台，DME 22.0 三节点做统一纳管和集中监控；虚拟化之上发放 15+ 台统信 UOS 和麒麟 V10 虚拟机，里面部署 Kubernetes 集群（3 master + 10 worker）、华为 BCS 区块链边缘自治系统、Vastbase G100 一主一备数据库集群；最上层是公司自研的数币智能合约管理平台，中间件有毕昇 JDK、Redis、Nginx。一句话总结：这是从芯片到应用全链路国产化的金融生产环境，我在里面负责从虚拟化底座到应用联调的实施交付——每层的部署动作和版本配套关系我都能讲清楚。
问②部署顺序怎么安排的？为什么？： 按依赖关系从下往上：先硬件上架和 RAID（底座的底座）→ 装 CNA/VRM 建虚拟化集群 → 配分布式交换机和端口组（网络先行，不然虚拟机发出来也不通）→ 批量发放虚拟机装国产 OS → 数据库集群先于应用部署（Vastbase 先验收，应用联调才有库可用）→ K8s 集群和 BCS → 最后自研平台部署联调。这个顺序的核心逻辑是"下层的可用性是上层的交付条件"——比如数据库没验收就联调应用，出了问题分不清是应用错还是库错，排查成本翻倍。我把这个依赖顺序画成了部署手册里的流程图，新同事一看就知道先干什么后干什么——实施经验最值钱的形态就是这种"被验证过的顺序"。
问③升级怎么做的？银行环境升级有什么特别？： 银行环境的升级是变更管理问题，不只是技术问题。我的四条纪律：第一，严格按华为版本配套表走——FC 8.3.0、DME 22.0、BCS 1.2.6、K8s 1.17.3 是一张表上的，任何组件升级先核对配套关系，绝不单独升级某个组件；第二，变更窗口制——升级安排在业务低峰的约定窗口，提前向客户报备变更计划（影响面、步骤、回退方案）；第三，先备份后升级——数据库和关键配置动手前必须有备份或快照；第四，升级后按验收清单逐项验证，和原厂联调确认。这套流程是金融环境教我的：生产升级出事，多数不是不会升，是没按纪律升——所以我把"升级四条纪律"原样写进了部署手册的升级章节。
- 真实数字锚点：CNA×3+VRM×1、DME 三节点、K8s 3 master+10 worker、Vastbase 一主一备、15+ 台国产 VM。
实-3 「负责平台上线割接、环境验收与客户方培训交付，输出《智能合约引擎安装部署指南》等标准化文档」
- 涉及知识点 → 第15章（核心：割接 15.12、培训 15.13、文档 15.10/15.11）、第09章（割接网络验证）、第13章（汇报话术）。
问①上线割接怎么组织的？： 我按"三段式"讲：准备段做三件事——网络基线快照（IP 规划表、路由、VLAN 对应关系全部导出留档）、连通性基线（关键链路 ping/telnet 结果记录在案作为割接后对照）、回退方案（触发条件、命令级回退动作、窗口和责任人）；执行段守三条纪律——业务低峰窗口并向客户报备、动作按清单逐步执行每步即验、双人操作一人执行一人核对；验证段按"由底层到业务"——先网络层（traceroute 路径、端口放行核对），再服务层（集群全 Ready、数据库主备正常、各组件端口通），最后业务层（登录、核心交易冒烟），加一个观察期盯监控大盘确认无异常才算割接成功。割接的本质是把不可逆变成可逆、把意外变成清单——这套方法论第 15 章 15.12 有完整展开，我在银行上线和移动云入口切换都用它。
问②环境验收验什么？怎么算"一次通过"？： 我的验收清单五组：节点与虚拟化层（服务器健康、虚拟机规格与规划表一致）、平台层（K8s 全组件 Running、etcd 健康、数据库主备复制正常、BCS 管理面可访问）、网络层（双平面隔离验证、关键链路连通）、业务层（核心功能冒烟）、文档层（交付物齐全：部署指南、IP 规划表、验收报告）。"一次通过"的含义是：客户和监理按这五组清单逐项核验，没有一项打回重做——这背后是验收前我先自查一轮，把自查发现的问题在正式验收前消化掉。银行那次验收就是这样：正式验收前一周我按清单自验，发现两处文档里的命令笔误提前改掉，正式验收当天半天走完全部项目。验收一次通过的秘诀就是"先自己当一遍客户"。
问③客户培训怎么讲的？客户听不懂怎么办？： 我的培训分两场：管理层的验收汇报讲价值和结论（平台跑通了什么、验收结果、遗留事项）， 15 分钟；运维层的实操培训讲操作（平台日常巡检怎么看、告警怎么响应、常见问题怎么处理），带实操环节——我讲一遍、客户操作一遍、我再检查一遍。客户听不懂的应对我有个真实方法论：先降维——把"etcd 多数派"讲成"三台管理节点坏一台集群还能决策"；再用类比——把负载均衡讲成"银行柜台的叫号机"；最后落到对方熟悉的动作——不讲原理讲"你每天上班要点的三个页面"。培训冷场我也遇到过：应对是提问式互动（"你们现在遇到告警第一件事做什么？"）加现场演示故障处置——实操和演示永远比 PPT 有吸引力。培训成功的标志是客户自己能处理日常巡检和一般告警——需要我们的频率明显下降，这是知识转移做实的证据。
- 真实数字锚点：验收一次通过；培训两场（汇报版/实操版）；《智能合约引擎安装部署指南》v2.1 成为公司标准。
实-4 「上线后驻场提供运维支持，与华为原厂协同处理巡检、告警与疑难故障」
- 涉及知识点 → 第14章（故障案例集）、第07章（监控）、第01章（巡检命令）。
问①日常巡检怎么做的？： 我分三层巡。第一层系统层，固定命令组过一遍：top 看 CPU 和负载、free 看内存、df 看磁盘、systemctl --failed 看失败服务、journalctl 拉当天错误级日志——这套在统信和麒麟上跟 CentOS 完全一致；第二层平台层，看 K8s 组件 Pod 状态、节点有没有 NotReady、Vastbase 主备复制状态、BCS 管理面页面可访问、虚拟化平台告警；第三层业务层，关键功能冒烟验证。巡检结果整理成日报留档，异常项当天闭环或者升级。这套三层巡检让"平台稳定"从感觉变成有记录的事实——客户认的也是这个：每次巡检有报告，出了问题有据可查。
问②印象最深的故障？： 我首推证书 SAN 那次：单 master 升三 master 后用 VIP 连 apiserver 报 x509。两句话定位——curl -k 能通说明网络和负载均衡全好，kubectl 报错说明是证书校验；openssl x509 -text 一看 SAN 列表里没有新 VIP 和新 master。解法是六步重签证书（改 certSANs、移走旧证书、init phase certs apiserver 重签、杀容器拉起、验证、回写配置）。教训一句话：改集群入口地址必须先想证书。这个案例好在：真实踩过、定位快、有规则级沉淀——后来移动云项目初始化就把 VIP 写进 certSANs，这个坑再没出现过。把踩过的坑变成团队的前置设计，是故障复盘最大的价值（完整 STAR 在第 14 章 14.7）。
问③夜间告警怎么处理的？： 按"先止损再定位"的框架：先判断影响面——影响业务的先做保守动作（有备切换、可扩先扩、摘流量），不做超出权限的激进变更；同步通报干系人拉人；过程记录时间线和动作。半夜的原则是"宁可保守不可炫技"——大动作留给白天和人多的时刻。我有完整的夜间处理案例（比如 Vastbase license 到期替换那次的双主风险预警，第 14 章展开），这类经历也是我"适应 7×24 上线保障"这个简历条目的实底。
- 真实数字锚点：驻场近两年；巡检日报留档；7×24 响应。
第二部分 工作经历·云平台阶段（2025.07–2026.10）
云-1 「负责移动云生产 Kubernetes 集群与可视化运维管控体系的方案编制与部署实施，形成公司外包项目的标准基础设施底座」
- 涉及知识点 → 第06章（K8s 部署交付）、第07章（监控）、第15章（方案编制）、第09章（云资源）。
问①为什么要建这套体系？： 直接背景是公司 2025 年起拓展多行业软件外包，新项目上线在即，传统虚拟机交付有三个突出问题：资源交付慢——开环境、装依赖、调配置以天计；环境不一致——每个项目装的版本配置各有各的样子，出问题难排查；运维门槛高——不是人人都会 kubectl，日常操作压在少数人身上。所以需要一套"交付快、环境一致、门槛低"的通用基础设施。我的答案是云原生体系：K8s 做底座保证环境一致和快速交付，可视化平台降低使用门槛。交付快的量化结果：资源交付从天级缩短到分钟级——新项目要一套环境，按标准底座复制，而不是从装虚机开始。
问②"标准基础设施底座"体现在哪？： 三个标准化：一是方案标准化——建设方案含架构选型、部署顺序、验证清单，后续外包项目直接套用改参数；二是初始化标准化——全节点统一初始化清单（关 swap、内核参数、时间同步、containerd 配置），新环境照清单重放即复制，这就是 IaC 思想的落地；三是避坑标准化——9 项生产避坑清单，每条都是"现象→根因→解决→预防"，第二个项目照着方案走，九个坑一个不用再踩。"标准底座"的本质是把我一个人的经验变成组织的可复制资产——这也是我对自己这段工作最满意的定位：不只是建了一套集群，是建了一套"建集群的方法"。
问③方案编制你具体做了什么？： 四件事：一是资源评估——按业务规模测算节点数量和规格，规划 7 台 ECS 清单（3 台 2C4G master、3 台 8C16G worker、1 台 4C8G 监控节点）；二是架构选型——确定三副本控制平面、CLB 统一入口、跨可用区、Flannel 网络，每个决策写清理由（比如 etcd 为什么奇数、CLB 为什么不用自建——这些我都能现场推导）；三是部署顺序设计——初始化→控制面→CNI→worker→验证→监控的完整步骤和依赖关系；四是风险清单——把可能踩的坑提前列出。方案编制、部署实施、验证三件事都是我做的——这也是我跟"只执行方案"的岗位的区别：我从纸面到生产全程负责，方案里的每句话都被我亲手验证过。
- 真实数字锚点：7 台 ECS、3 可用区、v1.28.2、资源交付天级→分钟级、9 项避坑、成为公司标准底座。
云-2 「主导公司 AI 工具评估与内部落地（RAG 知识库 / 自动化工作流 / 全员培训），支撑售前与研发提效」
- 涉及知识点 → 第11章（AI 提效）、支持版第 11 章（深度）。
问①为什么公司让你来做这件事？： 两个原因：一是需求在我这——我的岗位本来就负责公司的 IT 支撑和知识管理，新员工学方案、售前答疑这些重复性问题天天从我手上过，我最清楚痛点在哪；二是能力匹配——我是团队里同时懂技术选型、又有运维治理习惯的人：密钥管理、账号权限、成本监控这些事，本质就是运维的资产管理和变更管理思维，我只是把管服务器账号的那套纪律平移到了 AI 平台上。所以这个项目落在我头上不是偶然，是"懂场景加会治理"的组合正好长在我身上，我也就从评估选型一路做到全员推广——月成本控制在 5000 元以内这个数字，就是治理能力的直接证明。
问②RAG 知识库一句话讲清？： 让大模型开卷考试。链路五步：文档切分成片段 → embedding 向量化存进向量库 → 用户提问先按语义相似度召回最相关片段 → 重排精选 → 问题加片段交给模型生成带出处的回答。它适合企业知识的四个原因：文档更新了重新入库就行、不用训模型；回答带出处可溯源；能按权限控制召回范围；成本比微调低一个量级。我们公司全部《解决方案》和技术文档就是这么入库的，新员工学方案、售前答疑都在用——这段的深度展开在支持版第 11 章，实施版我按"是什么、我用来干什么"两层讲。
问③这和实施工作有什么关系？： 三层关系。第一层当下就相关：我的部署文档、SOP、避坑清单都入了知识库——实施知识数字化，新人培训和客户交接直接受益；我在银行养成的文档习惯，升级成了"文档既给人看也给 AI 用"。第二层能力同构：AI 落地的"选型—使用—成本—合规"闭环，和实施项目的"方案—部署—验收—质保"闭环是一个思维模型——先立规矩后放量。第三层提效直接：第 11 章讲的 AI 写文档、写脚本、辅助方案三个用法，就是我的日常——同样的交付任务，我用 AI 把文档和脚本的产能提上去，省下的时间花在客户现场。一句话：我是带着 AI 弹药的实施工程师。
- 真实数字锚点：月 5000 元以内；全部《解决方案》入库；全员培训加模板库。
云-3 「同时负责公司内部桌面运维与 IT 支持，建设 IT 知识库、SOP 与故障处理手册」
- 涉及知识点 → 第11章（知识库）、第15章（知识转移方法论）。
问①桌面运维不是低端活吗，你怎么看？： 我不觉得它低端，也不刻意拔高，如实讲三层。第一层职责现实：小公司实施本来就该一专多能，桌面支持占我的精力大约两成，主责是云平台和交付，这个配比我主动说清。第二层它给我的训练：桌面支持直接面对同事，锻炼的是沟通和服务意识——把"电脑坏了"这种模糊描述收敛成具体问题，跟把"服务不通"收敛到某一层是同一个能力；这个能力我在客户现场天天用。第三层我做出的增量：我把重复出现的问题沉淀成 IT 知识库和 SOP——打印机驱动安装步骤、常见软件报错处理——同样的问题第二次出现我发一个链接就解决。这是我的方法论：遇到重复劳动就想自动化。所以这段经历我答得坦然：它真实、不可伪造，而且和 AI 知识库项目连成了"传统知识管理到智能知识管理"的演进故事。
问②IT 知识库怎么建的？： 三步：第一步选题——从工单和被问频率里挑高频问题（软件安装报错、网络连接、打印机配置）；第二步标准化——每个问题按"现象、原因、解决步骤、截图"的固定格式写 SOP，保证不懂技术的人照做能成；第三步运营——新问题处理完必须沉淀进去，让它成为活文档。后来项目三的 AI 知识库就是在这个基础上升级的：先有 SOP 的数字化打底，接上 RAG 检索问答就水到渠成。这段经历其实是 AI 项目的前史——两个串起来讲是一个完整的成长故事，也证明我做知识管理不是临时起意，是一贯的工作方式。
- 真实数字锚点：约占两成精力；知识库与 SOP 持续维护；与项目三形成"传统→智能"知识管理演进线。
第三部分 项目一：某大型银行数字人民币智能合约引擎国产化部署交付（2023.08–2025.06）
P1-1 「负责 FusionCompute 虚拟化底座交付：iBMC 远程安装 CNA / VRM（RAID 规划、网络与时区配置），完成集群、分布式交换机与端口组配置及 15+ 台虚拟机批量发放，DME 22.0 统一纳管」
- 涉及知识点 → 第08章（核心）、华为篇 02/03/07。
问①CNA 和 VRM 是什么关系？怎么装的？： CNA 是计算节点代理，装在每台物理服务器上，虚拟机实际运行在 CNA 上；VRM 是虚拟化管理节点，负责集群管理、资源调度、HA 热迁移这些高级特性，Web 管理入口 8443 端口。银行项目我装的是 CNA 三台加 VRM 一台，物理机部署。安装走 iBMC 远程控制台：先做 RAID，然后挂 ISO 虚拟光驱——CNA 和 VRM 各一个镜像、都是 ARM_64 版本，走安装向导选逻辑盘、配管理 IP、主机名、时区、root 和 grub 密码，装完 root 登录执行 cnaInit/vrmInit 初始化，等回显初始化成功，再浏览器登 8443 做 License、MAC 段、NTP 初始化，最后建集群加主机。中间踩过一个很典型的坑：iBMC 虚拟控制台默认英文键盘布局，方向键失灵菜单选不了，要切日语键盘布局才正常——这个坑我写进了部署指南的注意事项。
问②RAID 怎么规划的？： TaiShan 2280 不带 RAID 卡，安装过程中组软 RAID。方案是：系统盘两块 600G SAS 组 RAID1——系统盘要求"坏不掉"，两盘互为镜像允许坏一块，容量损失一半无所谓；数据盘 3.84T SSD 组 RAID5——条带加分布式奇偶校验，容量和冗余平衡，允许坏一块，SSD 性能把校验的写惩罚弥补掉。还有一个关键参数是从 Vastbase 部署规范学来的：Disk Cache Policy 必须设 Disabled，防止掉电时磁盘写缓存数据丢失——对数据库场景这是致命项，我把它列进了验收检查项。RAID 规划的思路一句话：按数据的"可用性要求"分盘配级别，不搞一刀切。
问③虚拟机批量发放怎么保证一次到位？： 前提是集群、数据存储、端口组三样就绪。流程：VRM 界面创建虚拟机，选集群不绑定主机（保留 HA 能力）、按 IP 规划表选规格和端口组，挂 ARM 版 ISO 启动，VNC 控制台里装统信或麒麟；第一台标准机装好后装 Guest Tools、改主机名、配 IP 和时间同步、过安全基线，后面的机器按统一规格逐台发放。15+ 台都是这么交付的，规格和 IP 严格按部署规划表执行。我的心得是：批量交付的质量取决于规划表的细度——表做细了发放就是体力活，表不细每一台都是坑。这也让我养成了"发放前先对表"的习惯，后来这个习惯平移到了所有批量操作上。
- 真实数字锚点：4 台 TaiShan（96 核/384G/3.84T SSD）、CNA×3+VRM×1、DME 22.0 三节点、15+ 台国产 VM、iBMC 日语键盘坑。
P1-2 「负责 Kubernetes 集群部署与高可用改造：统信 UOS（ARM）环境完成 Docker 与 kubeadm 部署，通过 Nginx + Keepalived（VIP 漂移 + 健康检查）升级为多 master 高可用并完成故障转移测试」
- 涉及知识点 → 第06章（核心：6.1/6.2/6.3/6.4/6.5）、第04章（Nginx stream）、第05章。
问①单 master 升多 master 的完整步骤？（必背题）： 六步：第一步入口层——所有 master 装 Nginx stream 四层代理监听 16443（避开本地 apiserver 的 6443，因为负载均衡和 master 复用一台机器），upstream 挂三台 master 加健康检查；第二步导出 kubeadm-config；第三步最关键——补 certSANs，把新 VIP 和三台 master 的主机名 IP 加进去，不补后面必踩 x509 的坑；第四步移走旧 apiserver 证书再 kubeadm init phase certs apiserver 重签，杀 apiserver 容器让 kubelet 拉起新证书实例，配置回写；第五步从 master01 scp 证书（ca、sa、front-proxy-ca、etcd 的 CA 和 admin.conf）到 02/03，join 命令带 --control-plane 加入；第六步配 Keepalived（priority 100/90、检测脚本盯 16443 端口）并整体验证——三 master Ready、主节点关机实测 VIP 漂移、curl -k https://VIP:16443/version 正常返回。这六步我在生产完整做过，顺序错了就会卡住——比如证书没重签就去 join，新节点连 apiserver 直接报证书错误。
问②ARM 环境部署和 x86 有什么不同？： 四点全是我实测的：一软件源——必须 aarch64 专用源（kubernetes-el7-aarch64）；二 Docker——当时没有 ARM 仓库版，用 docker-18.09.8.tgz 的 aarch64 静态二进制包解压安装；三镜像——全部要 arm64 版本，内网拉不到就写批量加载脚本离线导入，交付前做"镜像架构清单"逐项核对 Architecture 字段；四编译类软件——源码装 Redis、Nginx 先确认 ARM 依赖库齐全。不变的也说清：内核参数、防火墙、systemd 这些系统层操作与 x86 完全一致。差异集中在"二进制和镜像的架构"这一层——这个总结让新同事接手 ARM 项目少走很多弯路，它写在部署指南的环境准备一节。
问③高可用改造的业务价值怎么跟客户讲的？： 我给客户讲三层：第一层风险量化——单 master 意味着 apiserver 单点，那台机器一故障整个集群"失联"，虽然业务 Pod 短期还在跑，但没法调度、没法自愈、没法发布，故障窗口被拉长；第二层方案价值——三 master 加 VIP 入口后，任何一台 master 故障，入口秒级漂移，管理面无感；第三层证据——故障转移测试报告：主节点关机，VIP 秒级漂移，kubectl 经 VIP 正常返回，全程无失败请求。给客户讲技术要用"故障场景加实测数据"的语言，不是堆组件名词——这也是我培训汇报时的一贯打法：先讲会出什么事，再讲怎么防的，最后拿出测过的证据。
- 真实数字锚点：K8s v1.17.3 + Docker 18.09（BCS 1.2.6 配套约束）、3 master + 10 worker、16443 端口、Keepalived priority 100/90、haproxy 与 Nginx 双方案验证。
P1-3 「负责 Vastbase G100 一主一备集群部署、license 导入与参数调优（最大连接数 / 线程池），完成数据库环境验收」
- 涉及知识点 → 第03章（核心）、华为篇 04。
问①一主一备怎么部署和验收的？： 部署用海量侧提供的自动化安装脚本：两个节点同时执行安装，中间时间误差不能超过 10 秒——这是脚本对集群初始化状态一致性的要求。装完配 license，然后四步验收：一查 DCS——Vastbase 底层分布式一致性服务状态正常；二查 HAS——高可用服务组件状态正常；三查数据库集群状态——主备角色正确、复制链路正常；四做功能验证——vsql 建用户建库，再用 DataStudio 从管理机远程连上去做真连接测试。四步全过数据库才算验收完成。中间处理过 license 到期替换的操作，那次踩了"双节点同时重启带来双主风险"的坑，之后我把操作改成"先重启一个节点、确认就绪和主备角色正确后再重启另一个"的分批规范，写进了部署指南——这个案例我在行为题里也常讲（第 14 章）。
问②调过什么参数？为什么？： 两个：max_connections 从默认 100 调到 10000——银行业务系统的连接需求大，配套的自研平台连接池打满时默认值远远不够；同时打开线程池 enable_thread_pool——openGauss 系的线程池模式让高连接数下的调度开销可控，避免一万连接把资源耗在上下文切换上。这两个参数是按业务侧评估的连接规模定的，不是拍脑袋调大。我的原则是：生产数据库的参数变更都要有依据、有记录——调了什么、为什么调、谁确认的，这三问在金融环境是要留痕的。
问③为什么用 Vastbase 不用 MySQL？： 三个硬约束决定的：一是信创要求——数币项目全链路国产化，数据库必须在国产目录里，Vastbase 是 openGauss 的商业发行版、PostgreSQL 系，在信创目录内；二是配套认证——它是华为 BCS 方案的配套数据库，跟鲲鹏平台做过兼容认证，版本配套表里就是这么配的；三是架构原生适配——对鲲鹏 ARM 原生支持，安装包直接是 aarch64_kunpeng 专用版本。所以这不是技术对比能决定的选型，是金融信创环境的标准答案——我的价值是理解配套关系并把它一次装通装稳：两节点时序、license 流程、参数调优、验收四步，这些细节都过过手。
- 真实数字锚点：Vastbase G100 2.2、HAS+DCS、max_connections 100→10000、license 3 个月免费期、两节点安装误差 ≤10 秒。
P1-4 「参与 BCS 边缘自治系统与数币智能合约管理平台部署联调（毕昇 JDK、Redis、Nginx 编译部署与前后端联调），部署 Prometheus + Node Exporter 基础监控」
- 涉及知识点 → 第04章（中间件）、第05章（镜像）、第07章（监控）、华为篇 05/06。
问①自研平台的部署链路完整讲一遍？： 这是公司自研 Java 平台，链路我做过多次：①装毕昇 JDK 8u362（ARM 版）配环境变量——毕昇是华为对 OpenJDK 的优化发行版，对鲲鹏有性能优化；②Vastbase 建库执行初始化 SQL 导数；③编译安装 Redis 5.0.3——源码 make，bind 0.0.0.0、daemonize yes，ARM 上要先补依赖库；④部署后端 jar 包，改 application yml 里的数据库和 Redis 连接，导入 BCS 管理员证书并用 openssl 把 crt/key 转成 p12（BCS 的 TLS 证书给 Java 服务用要转格式），jps -l 验证进程；⑤Nginx 1.25.1 源码编译（--with-http_ssl_module --with-http_stub_status_module），80 端口 301 重定向到 443，443 挂证书服务前端静态页，/prod-api/ 反向代理到本地 8080 后端。
联调时处理的经典前端问题：登录后刷新 404——前端路由应用，要用 try_files $uri $uri/ /index.html 兜底。这条链路的每一步我都踩过细节，是"中间件部署加前后端联调"这条简历技能的实底。
问②BCS 怎么纳管数据面节点的？内网镜像怎么解决的？： BCS 边缘自治版分管理面和数据面：管理面三节点是华为侧平台，数据面节点承载业务。纳管用 Token 认证：用 edgetool 工具在数据面集群创建 edge-admin 的 ServiceAccount，从关联 secret 里把 token 解出来填到 BCS 管理平台的接入配置——本质就是 K8s 的 RBAC 服务账号机制做跨集群认证。镜像问题是我解决的：内网拉不了任何海外镜像，我写了批量加载脚本——遍历镜像目录所有 tar.gz、条件排除 edge-manager 开头的管理面镜像、其余全部 cat 进 docker load，加载完 docker images 核对。十几类镜像一个脚本铺满全部数据面节点，BCS 纳管一次通过——脚本原样进了部署指南（第 5 章 5.5 有完整版）。
问③基础监控搭了什么？： 按 BCS 监控规范部署了 Prometheus 2.33.5 加 Node Exporter 1.3.1 到 monitor 命名空间：Node Exporter 以 DaemonSet 跑在每个节点，采集 CPU、内存、磁盘、网络指标；Prometheus 抓取后配合管理面监控看资源状态。定位是基础监控——节点层和平台层关键指标有数可看、有告警可报。更完整的一套是我在移动云项目建的（第 7 章）：独立节点加集群内混合部署、三层指标、告警全链路演练——两个项目放一起讲正好是监控能力的演进线：从"够用的配套监控"到"自己设计的完整体系"。
- 真实数字锚点：BCS 1.2.6（管理面 3 + 数据面 6 节点）、毕昇 JDK 8u362、Redis 5.0.3、Nginx 1.25.1、Prometheus 2.33.5、Node Exporter 1.3.1。
P1-5 「负责上线割接与环境验收，组织客户方部署培训与知识转移」
- 涉及知识点 → 第15章（核心：15.12 割接、15.13 培训、15.15 验收）、第09章（网络验证）、第13章（汇报）。
问①割接当天的时间线能复述一遍吗？： 能，我按窗口讲：窗口开始前半小时，团队到位、回退方案桌面备好、客户值班和华为接口人在线确认；T0 开始执行——按割接清单逐步操作，每步完成即验证（网络切换一步、验证连通性一步，不攒批）；中段服务验证——集群、数据库、平台组件逐层起来，各层健康检查过；后段业务验证——登录、核心功能冒烟，客户业务方确认；观察期——盯监控大盘一个周期确认无异常；宣布割接成功，输出割接报告（时间线、结果、遗留事项）归档。全程双人操作一人执行一人核对，任何一步验证不过走回退评估。这份时间线本身就是交付物——它证明割接是"被组织的"，不是"碰运气过的"。
问②知识转移具体交了什么？怎么验证转移成功？： 两层交付：一层培训——平台使用（虚拟化管理、日常巡检、告警响应）带实操；一层文档——部署指南、巡检手册、常见问题处理手册作为交付物移交，验收报告里逐项列明。验证转移成功的方式很实在：培训后让客户运维独立完成一轮日常巡检和一次模拟告警处置，我在旁边只看不插手——能独立走完就算转移到位。做完转移的标志是客户自己能处理日常事务、需要我们的频率明显下降。知识转移做得好，后续支持成本就低——这是交付方很实际的动力，也是"负责"两个字的完整含义：不是装完就走，是交到客户能自己用。
- 真实数字锚点：割接窗口一次成功；培训两场；文档交付物清单进验收报告。
P1-6 「编写《智能合约引擎安装部署指南》《IP 规划表》等交付文档，沉淀为公司同类项目标准实施文档」
- 涉及知识点 → 第15章（15.10/15.11 文档清单与标准）、第11章（AI 辅助写文档）。
问①部署指南写了什么？为什么能成为公司标准？： 《智能合约引擎安装部署指南》v2.1 覆盖从零到装通的全要素：IP 与主机名规划表、RAID 方案、网络与 VLAN 配置、每个组件的版本和配套关系、分步部署命令和参数说明、验收检查清单，还有专门的"注意事项"一节记录我踩过的坑——iBMC 日语键盘、双节点装库的时序、镜像架构核对这些。能成为标准靠三个特征：可复制——同类项目直接复用底稿改规划参数就能开工；可验收——验收清单直接作为客户验收依据，双方按同一张表打勾；可传承——新同事的培训教材就是这份文档。写法上我坚持一个标准：新的实施同事拿到文档，不需要来问我，照着做就能装通——这个标准逼着我把"手上知道但没写下来"的隐性经验显性化，这比写文档本身更有价值。
问②写文档占用交付时间，你怎么平衡？： 我的观点是文档不是交付的附属品，是交付物本身——尤其实施岗。我的做法三条：边做边记——每个操作当天记录关键参数和坑，不靠事后回忆（回忆会失真）；模板化——章节结构固定，同类项目复用骨架只换内容，写一份新文档的边际成本越来越低；AI 辅助——结构初稿和重复性文字交给 AI，我填真实命令和现场细节（第 11 章 11.1 的用法）。结果上讲，文档投入的时间在第二次交付时全部赚回来——第二个项目照文档走，九成的坑不用再踩。一次投入、多次复用，这是我对"文档值不值"的量化回答。
- 真实数字锚点：部署指南 v2.1；成为公司同类项目标准；新同事照文档可独立装通。
第四部分 项目二：移动云生产级 Kubernetes 集群与可视化运维管控体系落地（2025.07–2026.10）
P2-1 「完成资源评估与建设方案编制，负责部署实施与全量健康验证（含控制平面故障切换演练）」
- 涉及知识点 → 第06章（6.1/6.4/6.10）、第09章（云资源）、第15章（方案编制）。
问①演练具体怎么做的？（现场讲操作的标准答案）： 四步：第一步制造故障——停掉 master-02 的 kubelet 模拟控制平面节点故障（停 kubelet 不关机，风险可控可恢复）；第二步观察摘除——CLB 对三个 master 配了 6443 健康检查，kubelet 停了节点异常，CLB 秒级把 master-02 从后端摘除；第三步验证无感——通过 CLB 的 VIP 执行 kubectl get nodes 正常返回，说明剩余两台 master 承载了全部控制面请求，客户端无感；第四步恢复验证——重启 kubelet，控制面组件自动拉起，etcd 自动同步追平数据，节点重新回到集群。结论八个字：秒级摘除、无感切换——这是实测结论不是设计文档上的话。演练记录和故障切换操作手册写进运维规范交了出去——"高可用是设计出来的，更是演练出来的"是我从这次得到的信条。
问②全量健康验证验了哪些？： 五组：节点层——get nodes 全 Ready、时间同步毫秒级；控制面——kube-system Pod 全 Running、etcd 三副本 healthy（etcdctl 带三证书查 endpoint health）、apiserver 经 VIP 可访问；网络层——跨节点 Pod 互通（两个节点各起 Pod 互 ping）、Service 与 DNS 解析正常；业务层——示例应用部署、滚动更新与回滚演练、探针行为验证；高可用——控制面故障切换演练（上面四步）。每组验收结果记录进验证报告。我的观点：验证清单和部署方案是配套的——方案里每个设计点都要有对应的验证动作，设计才算被证明，这也是"方案编制到验证全流程"这句话的实底（第 6 章 6.10）。
问③为什么 3 个 master、跨可用区？： 3 个 master 的根源是 etcd 的 Raft 多数派：写请求要过半节点确认，3 副本容忍 1 台故障，4 副本同样只容忍 1 台却多花一台机器——所以 etcd 副本永远取奇数，3 或 5；我们按业务规模评估 3 副本够用。跨可用区是为了机房级故障隔离：可用区是同地域内电力网络独立的机房，任何一个可用区整体故障，其他区的 master 仍构成多数派、集群照常决策——用很小的延迟代价换机房级容灾，这笔账非常划算。这两个决策加上 CLB 统一入口，就是控制平面按 99.99% 可用性目标设计的三根支柱——口径上我强调这是设计目标，靠机制保障，我不说成实测 SLA。
- 真实数字锚点：7 台 ECS（3+3+1）、3 可用区、秒级摘除实测、99.99% 设计目标、资源交付天级→分钟级。
P2-2 「完成 containerd 运行时标准化、kubeadm 三副本控制平面与 Flannel 网络部署，沉淀 9 项生产避坑清单」
- 涉及知识点 → 第06章（6.1/6.9）、第05章（5.7）、第01章（初始化）、第14章（避坑案例）。
问①containerd 标准化指什么？： 三个关键配置，全是坑换来的：SystemdCgroup=true 并与 kubelet 的 cgroupDriver 对齐——不一致是节点 NotReady 的经典原因，资源统计会漂移；sandbox_image 换国内源——默认 registry.k8s.io 的 pause 镜像内网拉不到，kubelet 起不来任何 Pod；/etc/crictl.yaml 显式绑定 containerd socket——crictl 默认按 docker/containerd/crio 顺序遍历端点会报错。这三项加 Docker/containerd 的关系背景（1.24 移除 dockershim、CRI 直连 containerd、Docker 镜像 OCI 兼容照跑）就是运行时标准化的全部——把它们预置进初始化脚本，全节点行为一致，这就是"标准化"三个字的落点。
问②9 项避坑挑两个详细讲？： 讲最有代表性的两个。第一个节点 NotReady：三台 worker join 完全部 NotReady，get pods -n kube-flannel 一看 Flannel Pod ImagePullBackOff——海外镜像内网拉不到，CNI 起不来节点自然 NotReady，九成 NotReady 到这一步见分晓；解决是 kubectl edit daemonset 把 init 和主容器镜像全部替换成内网仓库地址，几分钟全 Ready；沉淀成"先 CNI 后 worker"的部署顺序和镜像清单预导入动作。
第二个 ClusterRoleBinding 的 roleRef 不可变：给 kube-state-metrics 配权限时 apply 报字段不可更新——roleRef 在 API 层就是 immutable 的，防止权限被悄悄调包；解决是 delete --ignore-not-found 删除重建，并直接复用内置 view 只读角色满足最小权限。一个关于"装得起来"，一个关于"K8s API 的设计约束"，都很典型。
问③部署顺序为什么强调"先 CNI 后 worker"？： 因为 kubelet 判断节点 Ready 依赖 CNI 就绪——网络插件没起来，节点 Pod 网络没配置，kubelet 上报 NotReady；而 CNI 是 DaemonSet Pod，它的镜像在内网拉不到就永远起不来，形成死锁。我先踩过"节点都加完了才装 CNI"的弯路——一批 Pod 起不来，排查半天。从此把部署顺序固化为"初始化→控制面→CNI→worker→验证→监控"，写进方案。顺序错误在 K8s 交付里不是效率问题是能不能装通的问题——这是我教新同事的第一课。
- 真实数字锚点：containerd 1.7.8、kubeadm v1.28.2、Flannel v0.22.0、9 项避坑全部实际踩过验证过。
P2-3 「部署 Prometheus + Grafana + kube-state-metrics 监控体系与 Kuboard 可视化管控平台」
- 涉及知识点 → 第07章（核心）、第06章（6.7 调度用例）。
问①监控为什么用混合部署？： 按"每个组件放哪最合适"分别决策：Prometheus 和 Grafana 放独立监控节点二进制部署——一不占集群资源，二故障隔离，"观察者不能和被观察者一起死"，集群挂了你正需要看数据的时候监控不能也没了；kube-state-metrics 必须在集群内——它的工作就是监听 K8s API 把对象状态转指标，离开集群无从工作；node-exporter 用 apt 二进制版装全节点——内网仓库没有镜像，二进制版默认 9100 与容器版指标完全兼容，Prometheus 配置不用改。这套取舍的完整讲法在第 7 章 7.1——工具形态服从目标，不为了统一而统一。
问②Kuboard 怎么部署的？为什么选它？： 选型看需求：我们要一个低门槛可视化运维入口，让不熟 kubectl 的同事也能做日常操作——Kuboard 轻量（一个 Deployment 起来）、中文界面、功能覆盖工作负载编排、日志终端、RBAC 权限、操作审计。部署五步：公网节点 pull 镜像 → tag 成内网仓库格式 push → 建命名空间加 docker-registry Secret → Deployment 四要点（nodeSelector 固定 master-01、tolerations 容忍 control-plane 污点、imagePullSecrets 认证、hostPath DirectoryOrCreate 持久化）→ NodePort 30088 暴露。持久化实测过：手动删 Pod 重建，配置和审计日志还在。日常运维 80% 操作在页面完成，kubectl 留给深度排查——"可视化覆盖日常"这个结果就是这么来的。
问③监控体系怎么交付给团队的？： 四件套交接：交接文档（架构图、访问信息、指标口径表、变更方法如加 target 和热加载）；告警响应手册（每条告警一页：含义、第一步动作、常见原因、升级路径）；带实操的培训（看盘、响应告警、简单变更，客户/同事当场独立操作）；验收记录（Targets 全 UP 截图、告警演练时间线）。核心思想：监控交付的完整性不在装了多少组件，在接手的人能不能自己用起来——完整讲法在第 7 章 7.3。
- 真实数字锚点：kube-state-metrics 2.7.0（NodePort 30080）、Kuboard v3.5.2.2（30088）、日常 80% 操作页面完成、监控部署三坑（GPG 404/promtool/node-exporter）。
P2-4 「配套云数据库、消息队列及 WAF / DDoS / 主机安全等云服务的开通配置与业务发布支持」
- 涉及知识点 → 第09章（9.3/9.4 云服务与安全组）、第03章（数据库）、第10章（发布支持）。
问①这些配套服务怎么规划和开通的？： 按"一张规划表加一份验收清单"交付（第 9 章 9.4）：规划表定网络拓扑（VPC 跨三可用区、7 台 ECS 固定 IP）、出入口（入口 CLB、出口 NAT+EIP、管理跳板机）、配套服务规格——MySQL 8.0 主备 8C16G/300G SSD、Redis 双机热备、RocketMQ 两节点、Nacos；安全四件套 WAF、DDoS 原生防护 5G、主机安全企业版、数据库审计——等保和客户合规的硬性要求。开通顺序先网络再计算再配套。验收逐项过：数据库可连接且主备切换验证过（控制台切一次确认角色互换、应用连接串指向可切换地址）、安全组矩阵核对无误。这套清单沉淀在建设方案里，成为公司云资源开通的标准动作。
问②业务发布支持你做到哪一步？： 三段：发布前——规划云资源规格和安全组矩阵、按最小权限放行，把数据库、Redis、MQ、注册中心的连接信息标准化交付给应用团队；发布中——集群侧配合 K8s 滚动更新，rollout status 等新版本就绪；发布后——验证服务连通性和监控指标，出问题配合回滚，一条 rollout undo 切回旧版本。所以虽然 CI 流水线的日常运维不是我的主责，发布链路上云服务侧和集群侧的支持是实打实我做的——"云服务配套加集群运维"两条线在我简历里是并列的，这条就是证据。
问③安全类服务是必须的吗？你怎么定位自己的角色？： 是硬性要求不是可选项——业务系统对外服务，等保测评和客户上线评审要检查这四件套，缺了上不了线。实际价值也真实：主机安全的基线核查提前发现过弱口令和高危端口，数据库审计让所有 SQL 访问可追溯。我的角色定位是"配置管理者"：规划选型建议、策略配置（基线检查项、告警级别、审计规则、WAF 白名单）、业务发布时做放行配合、账号权限最小化规范——不是安全攻防专家，这个边界我主动讲清，反而稳：知道每样东西为什么配、怎么配、配错了什么后果，这是实施工程师对安全服务的正确掌握深度。
- 真实数字锚点：MySQL 8.0 主备 8C16G/300G、Redis 双机热备、RocketMQ 两节点、DDoS 原生防护 5G、安全组矩阵成标准。
第五部分 项目三：企业 AI 工具评估落地与智能知识库建设（2025.07–2026.10）
P3-1 「基于阿里云百炼 API + Cherry Studio 搭建企业知识库与 RAG 问答（导入全部《解决方案》与技术文档），使用 Coze 建设自动化工作流」
- 涉及知识点 → 第11章、支持版第11章（深度展开）。
问①知识库建起来的完整流程？： 七步：数据准备——收集文档做三类清理（过期版本剔除、敏感信息脱敏、格式统一）；工具准备——Cherry Studio 加百炼 API，开通 embedding 和对话模型；建库——选 embedding 模型、配切分参数（块几百 token、重叠 10%–20%）；导入——分批入库，重点检查切分预览里表格代码有没有被切碎；建应用——助手绑知识库、系统提示词写死"仅根据资料回答、不知道就答不知道、给出处"、temperature 调低；验证调优——20 到 50 题评测集实测，答不上的按检索段/生成段/数据段三段定位；上线治理——按部门授权、建更新流程、密钥用量统一管理。RAG 原理一句话：让模型开卷考试——切分向量化入库、提问召回相关片段、生成带出处的回答。这套流程我完整走过两轮以上，是标准作业程序。
问②Coze 工作流举个具体例子？： 讲"方案要点提取"工作流：输入一份新方案文档，自动输出结构化摘要、适用客户画像、售前三句话卖点，发到指定群。节点编排五步：文档读取 → 大模型节点一做摘要（方案分析师角色，输出背景/架构/亮点/报价模式四段）→ 大模型节点二做售前话术（输入是节点一的输出）→ 格式化拼装固定模板 → 通知发群。两个设计点：主流程用固定工作流不用自由 Agent——可靠性优先，每步确定可控；两个大模型节点各司其职，提示词短而专，比一个大提示词效果好还省 token。每个节点配失败重试和异常提醒。
- 真实数字锚点：全部《解决方案》入库；评测集 20–50 题；工作流五节点。
P3-2 「每逢重要新模型上线即测评并输出选型报告全员分享，统一管理 API 密钥、账号权限与使用成本（月 5000 元以内）」
- 涉及知识点 → 第11章（治理）、支持版第11章。
问①测评怎么做、成本怎么控的？： 测评原则"用自己的业务题测，不看发布会"：从方案文档和售前真实提问里整理 20–50 道标准问答（含"文档里没有"的陷阱题考幻觉），同条件（同题同提示词同温度）跑新旧模型，人工按答对/答错/编造三类评分，同时按 token 用量算单次成本，综合准确率、幻觉率、成本出报告决策——有一次结论是"新旗舰质量确实提升但成本翻倍，只给核心问答场景升级"，没有数据做不出这种精细决策。成本三板斧：模型分级（简单任务便宜模型，这项省最多）、提示词瘦身（token 都是钱）、分密钥监控（一个应用一个 Key，配预算告警）——结果月成本 5000 元以内，有账可查。
问②密钥怎么管理的？： 三条纪律，完全是运维账号管理的平移：密钥不外发——统一平台侧配置、应用引用配置，绝不硬编码明文，跟数据库密码不进代码同一条规矩；按应用分密钥——账目隔离、权限隔离，泄露了一眼定位；定期轮换加离职即回收。我把 API Key 当一类密钥资产管理，纳入和服务器账号同级的安全纪律——这也是"运维人做 AI 治理"的优势：这些纪律本来就是我的肌肉记忆。
- 真实数字锚点：月 5000 元以内（简历唯一量化成本数字）；多份评估报告；密钥三纪律。
P3-3 「面向全员开展 AI 工具培训，沉淀提示词模板与实践案例库」
- 涉及知识点 → 第11章、第15章（培训方法论可迁移到客户培训）。
问①培训怎么做的？效果怎么衡量？： 分场景实操、不讲概念课：按受众分组——售前教怎么问知识库（怎么提问召回准、怎么核对出处）、开发教 AI 编程（提示词写法、生成代码怎么审）、全员教办公模板（周报纪要直接套）。每次只讲一个场景、练一个模板，培训完模板归档进提示词库。效果看两个数：调用量（哪些部门在涨——真在用）和用户反馈（有没有人真拿它干活）。这套方法论我后来在第 15 章的客户培训里又用了一遍——AI 培训和客户培训的底层逻辑一样：分场景、带实操、用数据验证，不讲概念课。
问②沉淀了什么资产？： 三类：提示词模板库——方案摘要、周报、招标应答、代码解释等十几个场景化模板，全员直接套用；实践案例库——知识库建设、工作流搭建、测评方法的实操记录，新人照着能复刻；选型评估报告——每次模型测评的结论和成本分析，后续选型直接引用。工具会过时，方法和模板沉淀下来是组织的——这也是我做这个项目最有成就感的部分：把个人经验变成公司资产。
- 真实数字锚点：模板十余个场景；培训分场景分组；调用量验证效果。
第六部分 三个项目 1 分钟 / 3 分钟逐字稿（实施版口吻）
项目一 1 分钟版
我在银行驻场近两年，做数字人民币智能合约引擎平台的国产化实施交付。4 台华为 TaiShan 鲲鹏服务器上架，我用 iBMC 远程装 CNA 和 VRM、做 RAID 规划，搭起 FusionCompute 8.3.0 虚拟化底座，DME 22.0 统一纳管，批量发放 15 台以上统信 UOS 和麒麟 V10 虚拟机；往上部署 Kubernetes 集群（含单 master 升三 master 的 Nginx+Keepalived VIP 漂移高可用改造）、Vastbase 一主一备数据库、华为 BCS 和自研合约平台，全部联调打通。最后由我组织上线割接和环境验收、给客户做部署培训——平台一次通过银行客户验收，支撑数币试点运行，我写的部署指南成了公司同类项目的标准文档。
项目一 3 分钟版（交付流程讲法）
（在 1 分钟版基础上按交付阶段展开三处）①环境规划：每台服务器双平面组网（管理 IP+业务 IP 分接管理/业务交换机，另有 BMC 带外网），RAID 按可用性分级——系统盘 RAID1、数据盘 RAID5 且 Disk Cache Policy 关闭（数据库场景防掉电丢数据）；IP 规划表做到"发放前先对表"，批量交付的质量取决于表的细度。②高可用改造六步（被追问概率最高处，按 6.2 完整背）：负载均衡监听 16443 避开 6443 → 导出 kubeadm-config → 补 certSANs（新 VIP+三台 master，不补必踩 x509）→ 移走旧证书重签 apiserver 证书 → scp 证书后 02/03 带 --control-plane 加入 → Keepalived（priority 100/90、检测脚本盯 16443 端口）+ 主节点关机实测漂移。
中间的证书 SAN 坑我主动讲：curl -k 通而 kubectl 报 x509，openssl 查 SAN 缺新地址——教训"改集群入口必须先想证书"。③割接验收培训：三段式割接（基线快照+连通性基线+回退方案；窗口内一步一验双人核对；网络层→服务层→业务层验证加观察期）；验收五组清单先自验一轮——正式验收一次通过；培训两场（管理层汇报讲结论、运维层实操讲到能独立巡检）。结尾口径：选型是华为配套体系定的，我负责一次装通、装稳、装到能交付——"会装会修还能讲明白为什么"。
项目二 1 分钟版
2025 年公司拓展外包业务，新项目上线需要标准基础设施。我完成资源评估和建设方案编制，在移动云落地生产级 Kubernetes 集群：7 台 ECS 跨三个可用区——3 master 三副本控制平面、CLB 四层负载统一入口加健康检查自动摘除、3 台 worker 业务池、1 台独立监控节点；containerd 加 kubeadm v1.28.2 加 Flannel。配套 Prometheus+Grafana 监控和 Kuboard 可视化平台，日常 80% 运维操作在页面完成。控制平面按 99.99% 可用性目标设计，停 master 的 kubelet 实测 CLB 秒级摘除、kubectl 无感；部署踩的坑沉淀成 9 项生产避坑清单，整套方案成为公司外包项目的标准底座，资源交付从天级缩短到分钟级。
项目二 3 分钟版
（在 1 分钟版基础上展开四处）①方案编制四件事：资源评估（7 台规格清单）、架构选型（每个决策写理由——etcd 为什么奇数、CLB 为什么不自建、为什么跨可用区）、部署顺序设计（初始化→控制面→CNI→worker→验证→监控，"先 CNI 后 worker"是踩坑换的铁律）、风险清单。②标准化初始化（IaC）：全节点统一关 swap、内核模块、sysctl、chrony、containerd 三配置（SystemdCgroup 对齐、pause 镜像国内源、crictl 显式 socket）——期望状态统一定义、所有节点收敛一致，新环境按文档重放即复制。
③避坑清单挑两个展开：NotReady 九成是 CNI 镜像拉取（daemonset 镜像全局替换内网地址解决）；ClusterRoleBinding roleRef 不可变（删了重建，复用 view 只读角色）。④验证与交付：五组健康验证加控制面故障切换演练四步（停 kubelet→CLB 摘除→VIP 验证无感→恢复自动加入）；监控混合部署的理由（观察者不能和被观察者一起死）；Kuboard 固定节点+hostPath 持久化。结尾口径：体系是通用最佳实践，方案编制、部署、验证是我做的；99.99% 是设计目标；这套方案的价值在"可复制"——第二个项目照方案走，九个坑一个不用再踩。
项目三 1 分钟版
2025 年起我主导公司 AI 工具的评估和落地：基于阿里云百炼 API 接入主流大模型，用 Cherry Studio 搭了企业知识库和 RAG 问答，导入公司全部解决方案和技术文档，新员工学方案、售前答疑都靠它；用 Coze 搭自动化工作流处理方案要点提取这类重复劳动。治理上每逢重要新模型上线就测评、输出选型报告全员分享，统一管理密钥和成本，月成本控制在 5000 元以内；面向全员分场景培训，沉淀了提示词模板库。这套"选型—使用—成本—合规"的闭环机制，加上我用 AI 写文档写脚本提效的日常，是我作为实施工程师的差异化能力。
项目三 3 分钟版
（在 1 分钟版基础上展开三处）①RAG 一句话加建库七步：开卷考试——切分、向量化、检索、重排、带出处生成；七步流程（数据清理脱敏、建库配参、导入检查切分、建应用写死"不知道条款"、评测集验证、上线治理）；表格类文档被切碎的优化案例（按章节切+调大 top-K，写进建库规范）。②治理三板斧：模型分级、提示词瘦身、分密钥监控加月度复盘——月 5000 元以内有账可查；密钥当资产管（不外发、按应用分、离职回收）。③和实施的关系（主动讲）：部署文档 SOP 避坑清单都入了知识库——实施知识数字化，交接培训直接受益；AI 写文档写脚本三个用法是我的日常提效；边界如实——LangChain 系是自学原型级，落地走低代码是选型结论不是短板。结尾：我是带着 AI 弹药的实施工程师——同样的交付任务，我把文档和脚本的产能提上去，省下的时间花在客户现场。
第七部分 衔接问答（过渡题，答好显逻辑）
Q1：为什么从实施转到云平台？（也被问"你到底是实施还是运维"）
两层原因，一层被动一层主动。被动层是公司业务结构变了：2025 年起公司从银行产品交付转向多行业软件外包，驻场需求减少，同时公司自建云平台的需求出现，我转回来负责云平台建设顺理成章。主动层是能力延续：银行项目后期我本来就承担着上线后的运维支持——巡检、告警、故障处理、和原厂协同，K8s、监控、数据库这些能力已经攒在手上，转到云平台等于把在客户生产环境练出来的能力用到自己公司的生产环境，还是升级版——从"按方案执行交付"变成"从方案编制到落地验证全流程负责"。所以我的画像是"实施为体、运维为用"：会从零建设（交付视角），也会长期保障运行（运维视角）——实施岗要的"装得快装得稳"，我有；交付后"交得出、接得住"，我也有。
Q2：项目一和项目二的交付差异？（两朵云/两种环境怎么比）
我总结成"四个不同、一条相同"。环境不同：一是银行内网加 ARM 国产化，什么都拉不到、什么都按配套表；一是移动云加 x86，有托管服务可用、自主选型。约束不同：项目一版本锁死在华为配套矩阵（K8s 1.17.3、Docker 18.09），项目二自主选稳定版（v1.28.2、containerd）——一个约束一个自主，正好证明我在两种决策模式下都能干活。入口不同：内网自建 Nginx+Keepalived 管 VIP 漂移，云上托管 CLB 免运维——两个方案都实操过，选型靠经验不靠习惯。交付物不同：项目一交的是"一套平台加客户验收"，项目二交的是"一套可复制的底座加标准文档"。相同的是方法论：环境规划、版本配套意识、初始化基线、避坑沉淀、验证清单——这套在银行练出来的打法，到移动云直接复用并升级成标准。差异讲得清，说明我不是只在一种环境待过。
Q3：三个项目连起来，你的能力主线是什么？
一句话：装得快、装得稳、交得出。装得快——从硬件上架到全栈部署的流程化和脚本化：批量加载脚本、标准化初始化清单、AI 辅助文档，把交付周期压下来（资源交付天级到分钟级就是量化）。装得稳——高可用设计和验证：多 master 改造、证书管理、故障切换演练、9 项避坑，每个"稳"都有实测证据。交得出——交付的完整闭环：割接三段式、验收五组清单一次通过、培训知识转移、文档沉淀成公司标准。项目一是这条主线的完整首秀（银行全流程），项目二是主线在云上的标准化复刻（标准底座），项目三是给主线装上 AI 加速器（提效工具链）。下一步我想把这条主线带到一个更大的交付体系里——项目更多、环境更复杂、交付团队更强的平台，把"个人装得快装得稳交得出"升级成"团队的交付能力"。
第八部分 "实施交付八阶段"总览问答（与第 15 章呼应，必背）
Q1：你理解的完整实施交付流程是什么？（报菜名 + 每阶段一句话）
八个阶段一口气报完：需求调研 → 环境规划 → 部署实施 → 联调测试 → 割接上线 → 验收交付 → 培训转移 → 质保支持。每阶段一句话：需求调研——和客户、原厂对齐目标、版本配套和资源需求，产出需求确认单；环境规划——IP/RAID/网络/VLAN/规格的规划表，这是后面一切的地基；部署实施——按依赖顺序从下往上装，边装边验；联调测试——前后端、平台间接口打通，问题定位闭环；割接上线——窗口内按清单切换，一步一验带回退预案；验收交付——五组验收清单逐项过，客户签字；培训转移——客户能独立操作才算完成；质保支持——驻场或响应式支持，问题分级闭环。这八阶段的完整展开（每阶段产出文档模板）在第 15 章——面试被问"你怎么组织一个交付项目"，先报菜名再挑面试官关心的阶段展开。
Q2：八个阶段里哪个最容易出问题？你怎么防？
我的答案是割接上线和验收之间——因为前面所有阶段的问题都会在割接窗口集中暴露，而窗口是有限的、客户是盯着的。防法四条：一是把验证左移——部署和联调阶段的每步即验，不带病进窗口；二是割接前演练——关键操作在测试环境预演，把意外消灭在上生产前（银行上线窗口期我就是靠"每天闭环的任务清单加高风险操作预演"扛过来的）；三是回退方案先行——回退条件和命令级动作在方案里定好，现场不临时讨论；四是验收前自验——正式验收前自己按客户的标准走一遍，先自己当一遍客户。八阶段的逻辑就是"每个阶段把下一阶段的风险提前消掉"——流程不是形式，是风险的前置管理。
Q3：每个阶段的交付物（文档）你能报出来吗？
能，按阶段：需求调研——需求确认单、版本配套表；环境规划——实施方案（IP 规划表、RAID 方案、网络拓扑、资源清单）；部署实施——部署手册（分步命令加预期输出）；联调测试——联调问题跟踪表、测试报告；割接上线——割接方案（步骤、验证清单、回退预案）、割接报告；验收交付——验收报告（五组清单逐项结果）；培训转移——培训材料、操作手册、常见问题 FAQ；质保支持——巡检报告模板、故障处理记录、月度运行报告。这套文档清单的完整模板在第 15 章 15.10——"文档跟着阶段走、阶段以文档收口"，这是我能讲的交付方法论，也是我简历里"输出文档成为公司标准"这条的结构支撑。
章末自测清单（快问快答）
- 实施版简历工作经历几条、项目职责几条？ → 实施 4 + 云平台 3；项目 6/4/3。
- 实-3 的三件核心事？ → 上线割接、环境验收、客户培训加文档输出——第 15 章核心映射条。
- 项目一 6 条职责的章号指向？ → 08（FC 底座）、06+04（K8s 高可用）、03（Vastbase）、04+05+07（BCS 联调与监控）、15（割接验收培训）、15（文档沉淀）。
- 项目二 4 条的章号指向？ → 06+15（方案编制与演练）、06+05（containerd 与避坑）、07（监控 Kuboard）、09+03（云服务配套）。
- 项目三 3 条的章号指向？ → 11（知识库工作流）、11（测评成本）、11+15（培训沉淀）。
- "一次通过客户验收"怎么讲？ → 五组验收清单先自验一轮，正式验收半天走完——"先自己当一遍客户"。
- 客户听不懂培训内容怎么办？ → 降维、类比、落到对方熟悉的动作；提问互动加现场演示对冲冷场。
- 衔接问答三题的核心句？ → 实施转云平台=业务结构+能力延续；两项目差异=四个不同一条相同；能力主线=装得快、装得稳、交得出。
- 八阶段菜名？ → 需求调研→环境规划→部署实施→联调测试→割接上线→验收交付→培训转移→质保支持。
- 八阶段最容易出问题的位置与防法？ → 割接与验收之间；验证左移、割接前演练、回退先行、验收前自验。
- 每阶段交付物举三例？ → 环境规划出实施方案与 IP 规划表；割接出割接方案与割接报告；质保出巡检报告模板。
- 三个项目 1 分钟稿的共同结尾词？ → 落在交付物：标准文档/标准底座/闭环机制——实施版的结尾永远是"交出了什么"。
- 行动主语纪律？ → 所有操作描述以"我"为主语；数字一旦出口不能改口。
- 被问"哪条最怕问"？ → 主动亮 CI/CD 口径（课程实操+生产配套两端），再引向强项——诚实分层是实施版人设。
- 本章与 13/15 章怎么配合？ → 技术与项目主战场在本章；人事与自我介绍在 13 章；流程方法论在 15 章——三者的数字与口径必须一致。
- 20 个单元复习一遍要多久？ → 按"每问 1 分钟开口讲"约 70–90 分钟，面试周每两天过一遍。
12.9 本章使用红线（面试前再读一遍）
- 每问"先结论后展开"：任何一问先一句话结论，再讲机制或过程，最后落在数字或交付物——实施版的收尾词优先级：验收结果 > 沉淀文档 > 技术细节。
- 行动主语是"我"：所有操作以"我"为主语；多方协作的部分如实说分工（华为选型我落地、一线我二线原厂），不抢功不虚功。
- 数字一致：4 台、15+、3 master+10 worker、一主一备、7 台 ECS、9 项避坑、月 5000 内、一次通过验收——同一轮面试前后必须一致。
- 不越界：项目一选型归华为、流水线属课程实操、AI 框架原型级——三个边界主动说清。
- 本章是索引不是终点：每问的段落是"可直接说的 60–90 秒版"，面试官再深挖，按"涉及知识点"指向的章节（尤其 06/08/15）拿更细的弹药。