Appearance
第12章 工作与项目问答地图（简历逐条展开）
对应简历：工作经历两阶段全部职责（实施阶段 3 条 + 运维阶段 5 条）+ 项目一 5 条 + 项目二 7 条 + 项目三 4 条，共 24 条，逐条展开为问答单元。
用法：面试官的问题 80% 会落在简历某一行上——本章把每一行变成"知识点地图 + 高频问 + 可直接说的完整段落答法 + 真实数字"。面试前把本章当索引过一遍：被问任何一条，先反应出对应章号去展开技术细节。术语：Kubernetes（下文简写 K8s）。
12.0 口径总原则（先背这五条再往下看）
- 脱敏红线：不报内网 IP、账号、仓库域名、VPC 网段——一律"某银行内网环境""内网私有仓库"；被追问就说"客户内网信息，签了保密协议"（金融行业这反而是加分项）。
- 角色口径：项目一选型归华为（公司是渠道商），我负责落地交付、上线后一线运维归我、二线转华为原厂；项目二体系是通用最佳实践，方案编制/部署/验证是我；项目三是我主导。
- 数字口径：4 台 TaiShan、15+ 台虚拟机、3 master+10 work、一主一备、7 台 ECS、v1.17.3/v1.28.2、月成本 5000 内——全部有据可查，大胆说；99.99% 是设计目标，不说成实测 SLA。
- 诚实口径：Git/Jenkins/Ansible（技能第13条）是"课程项目实操 + 生产配套"；AI 框架是"自学原型级"。
- 每条职责的标准讲法：一句话概括做了什么 → 规模/版本数字 → 一个最熟的细节或坑 → 结果。
第一部分 工作经历·实施阶段（2023.08–2025.06，驻场某大型银行）
实-1 「参与数字人民币智能合约引擎平台的实施交付，负责 FusionCompute 虚拟化底座、DME 管理平台、Kubernetes 集群及国产化软件栈的部署、升级与验收」
- 涉及知识点 → 第08章（FusionCompute/DME/iBMC/RAID）、第06章（K8s）、第03章（Vastbase）、第01章（国产 OS）。
问①这个平台的整体架构是什么样？（可直接说）： 我自底向上分四层讲。最底层是硬件：4 台华为 TaiShan 2280 鲲鹏服务器，ARM 架构，每台 96 核、384G 内存；往上一层是虚拟化：FusionCompute 8.3.0 做虚拟化底座，CNA 三台加 VRM 一台，再由 DME 22.0 做统一纳管和集中监控；虚拟化之上发放了 15 台以上的统信 UOS 和麒麟 V10 国产化虚拟机，虚拟机里部署 Kubernetes 集群、华为 BCS 区块链边缘自治系统、Vastbase 一主一备数据库集群；最上层是公司自研的数字人民币智能合约管理平台。一句话总结：这是从芯片到应用全链路国产化的金融生产环境，我在里面负责从虚拟化底座到应用联调的实施交付。
问②为什么要全套国产化？： 核心原因是数字人民币的性质——它是央行主导的金融基础设施，金融行业又叠加了信创的硬性要求，所以从芯片、服务器、操作系统、数据库到中间件全部要求国产：鲲鹏芯片加 TaiShan 服务器、统信和麒麟的操作系统、Vastbase 这种基于 openGauss 的国产数据库，是一条完整的国产化技术栈。要说明的是我的角色边界：平台选型是华为和银行按配套体系定的，我们公司是华为生态渠道商，我负责的是按版本配套表把它一套一套落地装通——但为什么这么配套、配套关系是什么，我能讲清楚，这也是这段经历给我最大的专业训练：生产环境严格按配套来，不擅自升级。
问③你具体负责哪部分？： 四大块都是我做的。第一块虚拟化底座：通过 iBMC 远程装 CNA 和 VRM、做 RAID 规划、配集群和分布式交换机、批量发放那 15 台虚拟机；第二块 Kubernetes 集群：在统信 ARM 环境里从单 master 起步，后来做了三 master 高可用改造；第三块数据库：Vastbase G100 一主一备集群的部署、license 配置和验收；第四块联调收尾：华为 BCS 和自研合约平台的部署联调、基础监控部署，一直到配合客户验收。上线之后的一线运维支持也是我，疑难问题转华为原厂。
问④ARM 上部署和 x86 有什么不同？： 最大的不同是软件生态全部要换一遍：操作系统必须装 ARM 版的统信和麒麟，软件包必须选 aarch64 的，很多软件源要专门配 aarch64 源；容器镜像必须是 arm64 版本，银行内网拉不到海外镜像的时候，就只能在外网机器上下载好，打成 tar 包带进去用 docker load 离线导入——我专门写了批量加载脚本处理这件事。选任何软件第一件事先看架构标签，这成了我的肌肉记忆，也是我们部署文档里每个软件包都标注架构字段的原因。性能层面鲲鹏核多有并行优势，但运维感知最强的还是生态适配这一层。
- 真实数字锚点：CNA×3+VRM×1、DME 三节点、K8s 3 master + 10 work、Docker 18.09 aarch64 静态包、平台通过客户验收支撑数币试点运行。
实-2 「负责平台上线后的运维支持，与华为原厂协同处理日常巡检、告警、版本升级与疑难故障，保障试点业务稳定运行」
- 涉及知识点 → 第14章（故障排查框架与案例）、第07章（Prometheus 监控）、第01章（巡检命令）。
问①日常巡检都巡什么？： 我分三层巡。第一层系统层，用固定命令组过一遍：top 看 CPU 和负载、free 看内存、df 看磁盘、systemctl --failed 看失败服务、journalctl 拉当天错误级日志，这套在统信和麒麟上跟 CentOS 完全一致；第二层平台层，看 K8s 组件 Pod 状态是不是 Running、节点有没有 NotReady、Vastbase 主备复制状态、BCS 管理面页面能不能正常访问、虚拟化平台上有没有告警；第三层业务层，对关键功能做冒烟验证。巡检结果整理成日报留档，异常项当天闭环或者升级。这套三层巡检让"平台稳定"从感觉变成有记录的事实，客户那边也认这个。
问②和华为原厂怎么分工？： 分层协作：一线是我——日常巡检、告警第一响应、常见故障直接处理；二线是华为原厂——涉及产品内部机制、需要原厂工具或补丁的疑难问题转给他们。我的价值在转案质量：转之前我把现象描述、发生时间线、日志和告警截图、我已经做过的尝试全部整理好，原厂拿到手就能往下查，不用再来回要信息。对银行客户我是统一接口人，他们只需要对我，不用直接对接原厂。这套模式跑了近两年，客户验收一次通过，没有出过互相推诿的情况。
问③印象最深的故障是什么？： 我最熟的是两个：一个是单 master 升三 master 之后用 VIP 连 apiserver 报 x509 证书错误——用 openssl x509 -text 一看，证书的 SAN 字段里没有新的 VIP 和 master 主机名，apiserver 证书是按老地址签的；解法是改 kubeadm 配置补 certSANs、移走旧证书重新签发。教训是"改集群入口地址必须先想证书"。另一个是 Keepalived VIP 漂移的验证，主节点关机之后 VIP 要能在秒级漂到备节点、curl 通 16443 才算高可用真正成立。这两个都属于"设计上应该没问题、但必须实测验证过才敢睡觉"的故障，我按"先止损、再定位、后复盘"的框架完整讲（细节在第14章）。
问④版本升级怎么做的？： 银行环境的版本升级纪律非常严格：第一，严格按华为的版本配套表走，FC 8.3.0、DME 22.0、BCS 1.2.6、K8s 1.17.3 是一张表上的，任何一个组件升级都要先核对配套关系，绝不单独升级；第二，变更窗口制，升级安排在业务低峰的约定窗口，提前向客户报备变更计划，包含影响面、步骤和回退方案；第三，先备份后升级，数据库和关键配置在动手前必须有备份或者快照；第四，升级后按验收清单逐项验证，和原厂联调确认。这套流程说到底是金融环境教我的：升级不是技术问题，是变更管理问题。
- 真实数字锚点：驻场近两年；Prometheus 2.33.5 + Node Exporter 1.3.1 基础监控；简历写"7×24 应急响应"，用夜间告警处理案例支撑（第14章案例）。
实-3 「输出《智能合约引擎安装部署指南》等标准化实施文档，完成对客户方的部署交付与知识转移」
- 涉及知识点 → 第12章（讲法本身）、全章（文档化的知识）。
问①文档都写了什么内容？： 最有代表性的是《智能合约引擎安装部署指南》，v2.1 版覆盖了从零到装通的全要素：IP 与主机名规划表、RAID 方案、网络与 VLAN 配置、每个组件的版本和配套关系、分步的部署命令和参数说明、验收检查清单，还有专门一节"注意事项"记录我踩过的坑——比如 iBMC 虚拟控制台要切日语键盘布局这种细节。写法上我坚持一个标准：一个新的实施同事拿到文档，不需要来问我，照着做就能装通。这个标准逼着我把很多"手上知道但没写下来"的隐性经验显性化，这比写文档本身更有价值。
问②为什么说它是标准化文档？： 三个特征让它成了标准：第一，可复制——文档沉淀成公司同类项目的标准实施文档，后续同类项目直接复用底稿，改改规划参数就能开工；第二，可验收——文档里的验收清单直接作为客户验收的依据，双方按同一张表逐项打勾，验收一次通过；第三，可传承——新同事的培训教材就是这份文档，知识不挂在某个人的脑子里。而且这份习惯延续到了项目二：建设方案加 9 项避坑清单，是同一套方法论在云原生环境下的复刻——我两个阶段的工作其实是被"文档能力"串起来的。
问③知识转移怎么做的？： 对客户做了两层转移：一层是平台使用培训——虚拟化管理、日常巡检页面、告警怎么看怎么处理，培训对象是客户的运维对接人，讲完有实操环节；另一层是知识交付——部署文档、巡检手册、常见问题处理手册作为交付物移交给客户，验收报告里逐项列明。做完转移的标志是：客户自己能处理日常巡检和一般告警，需要我们的频率明显下降。知识转移做得好，后续支持成本就低，这是我作为交付方很实际的动力。
- 真实数字锚点：部署指南 v2.1；成为公司同类项目标准实施文档；这一条是面试讲"文档能力和交付能力"的主证据。
第二部分 工作经历·运维阶段（2025.07–2026.10，公司云平台）
运-1 「负责移动云生产 Kubernetes 集群与可视化运维管控体系的方案编制、部署实施与验证，落地互联网项目通用云原生体系」
- 涉及知识点 → 第06章（K8s 集群搭建）、第07章（监控/Kuboard）、第09章（CLB/VPC）。
问①为什么要建这套体系？： 直接背景是公司 2025 年起拓展多行业软件外包业务，新项目上线在即，但传统的虚拟机交付方式有三个突出问题：一是资源交付慢，开环境、装依赖、调配置要以天计；二是环境不一致，每个项目装的版本和配置各有各的样子，出了问题难排查；三是命令行运维门槛高，公司不是人人都会 kubectl，日常操作都压在少数人身上。所以需要一套"交付快、环境一致、门槛低"的通用基础设施。我给出的答案就是云原生体系：Kubernetes 做底座保证环境一致和快速交付，可视化平台降低使用门槛——这套体系按互联网项目的通用模式设计，后续外包项目直接复用。
问②方案编制你具体做了什么？： 方案不是拍脑袋，我做了四件事：一是资源评估——按业务规模测算节点数量和规格，规划 7 台 ECS 的配置清单；二是架构选型——确定 3 master 加 3 worker 加 1 独立监控节点的拓扑、CLB 做控制平面入口、跨可用区部署、Flannel 网络插件这些关键决策，每个决策写清理由；三是部署顺序设计——从节点初始化到组件上线的完整步骤和依赖关系；四是风险清单——把可能踩的坑提前列出来，后来部署过程中实际踩到并沉淀下来的就有 9 项生产避坑。方案编制、部署实施、验证这三件事都是我做的，这也是我跟"只执行方案"的岗位的区别——我从纸面到生产全程负责。
问③集群架构是什么样？： 一句话：7 台 ECS、三个可用区、三层角色。3 台 master 组成三副本控制平面，跑 apiserver、etcd、调度器这些组件，规格 2C4G；3 台 worker 是业务池，跑实际的工作负载，用的 8C16G 计算增强型；还有 1 台独立的 4C8G 监控节点，专门跑 Prometheus 和 Grafana。入口层用移动云 CLB 四层负载均衡做 apiserver 的统一接入，配上对三个 master 的健康检查，挂一个自动摘一个；三个 master 跨三个可用区部署，实现机房级故障隔离。软件栈是 K8s v1.28.2 加 containerd 1.7.8 运行时加 Flannel VXLAN 网络。
问④可用性怎么保障的？： 靠机制不靠运气，四层保障：第一层是控制平面三副本——etcd 用 Raft 多数派，任意一台 master 故障，剩下两台仍然构成多数派，集群决策不中断；第二层是 CLB 健康检查——某个 master 异常，秒级自动摘除，kubectl 的流量无感切到健康的节点，这个我做过停 kubelet 的实测演练；第三层是跨可用区——任何一个机房级故障，其他可用区的节点照常服务；第四层是数据面多副本——业务 Pod 多副本加反亲和调度，单节点故障 Pod 在别的节点分钟级重建。合起来，控制平面按 99.99% 的可用性目标设计——强调这是设计目标，靠这些机制保障，我不把它说成实测 SLA。
- 真实数字锚点：7 台 ECS（3+3+1）、v1.28.2、containerd 1.7.8、Flannel v0.22.0、worker 8C16G、9 项避坑、方案成为公司后续外包项目标准底座。
运-2 「负责云数据库、消息队列、注册中心及 WAF / DDoS 防护 / 主机安全 / 数据库审计等云服务的配置管理与业务系统发布支持」
- 涉及知识点 → 第09章（云服务与安全）、第03章（MySQL/Redis）、第10章（发布与回滚）。
问①为什么用云托管服务而不是自建？： 决策逻辑是业务优先：外包项目上线时间紧，自建数据库要自己搭主备、配备份、做监控、管高可用切换，一套下来一两周还要持续运维兜底；云托管这些能力都是现成的——主备自动切换、自动备份、监控告警、补丁维护全由云厂商负责，我们交付的只是规格规划和连接信息。另外一个坚持是：有状态服务不进 K8s 集群——数据库这种重状态服务跟容器"随发随销"的模型天然冲突，滚动更新时数据一致性难保证、伸缩粒度也对不上，所以架构上数据库用云托管、应用进集群，两层各得其所。当然自建的能力我有——银行项目 Vastbase 一主一备就是我手工搭的——正因为会自建，才知道什么时候不值得自建。
问②这些安全服务分别解决什么问题？： 我按攻击的层次说：WAF 部署在 HTTP 入口，防的是应用层攻击——SQL 注入、XSS、WebShell 上传这一类 OWASP Top 10，外加 CC 高频恶意请求；DDoS 原生防护防的是流量型攻击，SYN Flood、UDP Flood 打带宽的时候在云侧牵引清洗，我们配套的是 5G 基础防护；主机安全装 Agent，干两件事——基线核查（弱口令、高危端口、配置合规）和入侵检测（异常登录、WebShell、挖矿进程告警）；数据库审计做全量 SQL 访问留痕，谁在什么时间执行了什么语句都可追溯。这四件套是等保要求和客户合规的硬性配套，我的职责是规划选型、配置策略、业务发布时做放行配合。
问③业务发布你做到哪一步？： 发布支持我覆盖三段：发布前——规划云资源的规格和安全组矩阵，按最小权限放行，交付数据库、Redis、MQ、注册中心的连接信息给应用团队；发布中——集群侧配合做 K8s 滚动更新，watch rollout status 等新版本就绪；发布后——验证服务连通性和监控指标，出问题配合回滚，一条 rollout undo 切回旧版本。所以虽然 CI 流水线的日常运维不是我的主责，发布链路上云服务侧和集群侧的支持是实打实我做的——这也是"云服务运维"和"集群运维"两条线在我简历里并列的证据。
- 真实数字锚点：MySQL 8.0 主备 8C16G/300G SSD、Redis 双机热备、RocketMQ 两节点、Nacos 注册配置中心、DDoS 原生防护 5G。
运-3 「制定集群证书续期、etcd 快照备份、故障切换演练等运维规范，保障业务 7×24 小时稳定运行」
- 涉及知识点 → 第06章（证书/etcd）、第14章（演练与故障）。
问①证书怎么管理的？： kubeadm 集群的证书默认有效期一年，包括 apiserver、etcd、kubelet 这一整套，过期了整个集群会瘫痪——证书过期导致集群不可用是行业里真实发生过很多次的事故。我的规范三条：第一，到期前 30 天执行 kubeadm certs renew all 续期，续完重启对应组件生效；第二，监控里加证书剩余天数的指标告警，把"人记得"变成"系统提醒"；第三，所有证书相关操作记录留档。我对这件事特别重视有个真实原因：银行项目里我见过 BCS 中间件的证书过期问题，排查的过程很痛苦，所以自己建集群第一件事就是把证书管理立成规范。
问②etcd 备份怎么做的？： etcd 是集群的"账本"，所有状态数据都在里面，它坏了且没有备份，集群基本等于重建。我的规范两层：定期备份——用 etcdctl 带 CA、客户端证书和私钥三个参数执行 snapshot save，把快照文件保存下来并校验；重点备份——凡是升级、大变更这类高风险操作之前，必须先打一份快照再动手，这是变更纪律的一部分。恢复能力也验证过：etcd 有 snapshot restore 的完整流程，关键是快照文件和证书要一起保存在集群外的安全位置——备份放在故障域里面等于没备份。
问③故障切换演练具体怎么做的？（这条最容易被要求现场讲操作）： 四步，我完整讲。第一步制造故障：停掉一台 master 上的 kubelet，模拟控制平面节点故障；第二步观察摘除：CLB 对三个 master 配了 6443 的健康检查，kubelet 一停、节点异常，CLB 秒级把这台 master 从后端摘除，流量不再发给它；第三步验证业务无损：通过 CLB 的 VIP 执行 kubectl get nodes，命令正常返回——说明剩下的两个 master 正常承载了控制平面请求，对客户端无感；第四步恢复：重新启动 kubelet，节点上的控制面组件自动恢复，etcd 自动同步追上数据，节点重新加入集群。整个演练的结论就是"秒级摘除、无感切换"——这不是设计文档上的话，是实测结论。Worker 层另有一层保障：业务多副本加反亲和，节点故障 Pod 在别的节点分钟级迁移。
- 真实数字锚点：演练四步完整可复述；证书提前 30 天续期；这条是"高可用从设计变成验证"的证据链。
运-4 「主导公司 AI 工具的评估与内部落地：基于阿里云百炼 + Cherry Studio / Coze 搭建企业知识库、RAG 问答与自动化工作流，输出多份选型评估报告并全员分享，统一管理 API 密钥、账号权限与使用成本」
- 涉及知识点 → 第11章全部。
问①为什么公司让你来做这件事？： 两个原因：一是需求在我这——我的岗位本来就负责公司的 IT 支撑和知识管理，新员工学方案、售前答疑这些重复性问题天天从我手上过，我最清楚痛点在哪；二是能力匹配——我是团队里同时懂技术选型、又有运维治理习惯的人：密钥管理、账号权限、成本监控这些事，本质就是运维的资产管理和变更管理思维，我只是把管服务器账号的那套纪律平移到了 AI 平台上。所以这个项目落在我头上不是偶然，是"懂场景 + 会治理"的组合正好长在我身上，我也就顺理成章地从评估选型一路做到全员推广。
问②RAG 是什么原理？（此题细节全在第11章，这里给 60 秒版）： RAG 就是检索增强生成，一句话：让大模型开卷考试。链路五步：文档先切分成片段，用 embedding 模型把每个片段向量化存进向量库；用户提问时，问题也被向量化，按语义相似度召回最相关的片段；再经过一道重排精选；最后把问题加片段加"仅根据资料回答"的指令拼给大模型，生成带出处的回答。它适合企业知识的原因有四个：文档更新了重新入库就行不用训模型、回答能给出处可溯源、能按权限控制召回范围、成本比微调低一个量级。我们公司全部《解决方案》文档就是这么入库的，新员工学习和售前答疑都在用。
问③成本怎么管的？： 三板斧加一个复盘。第一板斧模型分级：分类、提取这类简单任务用便宜的小模型，复杂任务才上旗舰模型，这一项省的钱最多；第二板斧提示词瘦身：控制系统提示和知识片段的长度，token 都是钱；第三板斧分密钥监控：按应用分 API Key，谁的调用量、哪个应用的账单一目了然，配合预算告警，异常暴涨当天发现；最后每月复盘账单持续调优。结果是 API 使用成本控制在每月 5000 元以内——这是简历上唯一量化的成本结果数字，有账可查。
问④这和运维有什么关系？（必被问，三段答）： 分三层讲。第一层现在就相关：知识库里入库的运维 SOP、告警处置手册、部署指南，本来就是我运维经验的数字化——我的部署文档现在既给人看也给 AI 用。第二层场景同构：这个项目的原始场景就是 IT 支撑职能的提效，新员工学方案、售前答疑，和运维支持研发是一个性质的事。第三层方向一致：AIOps 是运维的演进方向——告警摘要、故障初判、巡检报告生成，再到 Agent 调工具执行预案，这条路上的每一步都需要"运维功底 + AI 工具链"的组合，而我两边都有实操。一句话收尾：我招进来是干运维的，但我是带着 AI 弹药来的。
- 真实数字锚点：月 5000 元以内、全部《解决方案》入库、多份评估报告、密钥不外发/按应用分/离职即回收。
运-5 「同时负责公司内部桌面运维与 IT 支持：Windows / macOS 系统与办公软件维护，打印机、门禁等办公设施日常管理，建设并维护 IT 知识库、SOP 与故障处理手册」
- 涉及知识点 → 第11章（知识库）、第12章（答法）。
问①桌面运维不是低端活吗，你怎么看？（答法比技术重要）： 我不觉得它低端，也不刻意拔高，如实讲三层。第一层是职责现实：小公司运维本来就该一专多能，桌面支持占我的精力大约两成，主责仍然是云平台和集群，这个配比我主动说清。第二层是它给我的训练：桌面支持直接面对同事，锻炼的是沟通和服务意识——把"电脑坏了"这种模糊描述收敛成具体问题，跟把"服务不通"收敛到某一层是一个能力。第三层是我做出的增量：我把重复出现的问题沉淀成 IT 知识库和 SOP，同样的问题第二次出现我发一个链接就解决——这正是我的方法论：遇到重复劳动就想自动化。所以这段经历我答得坦然，它真实、不可伪造，而且和 AI 知识库项目连成了"传统知识管理到智能知识管理"的演进故事。
问②这部分占你多少精力？： 大概两成，而且随知识库完善在下降。具体说：系统重装、软件故障、打印机门禁这类事务性工作，初期每月要花不少时间处理；后来我把高频问题全部写成 SOP——比如打印机驱动的标准安装步骤、常见软件报错的处理方法——同事里能自己照着做的就自己做了，剩下找到我的都是新问题，处理完又进知识库。这是个正循环：知识库越厚，被打断越少，我越有时间做云平台的主责工作。数字上讲，同类问题的重复处理量明显下降，这就是知识管理的直接回报。
问③IT 知识库怎么建的？： 分三步。第一步选题：从工单和被问频率里挑出高频问题——软件安装报错、网络连接、打印机配置这些；第二步标准化：每个问题按"现象、原因、解决步骤、截图"的固定格式写成 SOP，保证不懂技术的人也能照做；第三步运营：知识库持续维护更新，新问题处理完必须沉淀进去，让它成为活文档而不是死档案。后来项目三的 AI 知识库就是在这个基础上升级的——先有 SOP 的数字化打底，接上 RAG 之后检索问答就水到渠成。所以这条经历其实是 AI 项目的前史，两个串起来讲是一个完整的成长故事。
- 真实数字锚点：约占两成精力；知识库与 SOP 持续维护；与项目三形成"传统→智能"知识管理演进线。
第三部分 项目一：某大型银行数字人民币智能合约引擎国产化部署（2023.08–2025.06）
P1-1 「负责 FusionCompute 虚拟化底座建设：通过 iBMC 远程控制台完成 CNA / VRM 节点安装（镜像挂载、RAID 规划、网络与时区配置），完成集群创建、分布式交换机与端口组配置及虚拟机批量发放」
- 涉及知识点 → 第08章（FusionCompute/CNA/VRM/iBMC/RAID/分布式交换机）。
问①CNA 和 VRM 是什么关系？： CNA 是计算节点代理，装在每台物理服务器上，是裸金属型的 Hypervisor，虚拟机的实际运行都在 CNA 上；VRM 是虚拟资源管理节点，管理角色，负责集群管理、资源调度、虚拟机生命周期和 HA 热迁移这些高级特性，Web 管理入口是 8443 端口。银行项目我装的是 CNA 三台加 VRM 一台，都是物理机部署。这个架构最有意思的一点是管理面和数据面分离——VRM 挂了，CNA 上跑着的虚拟机照常运行，只是新建、迁移这些管理操作不可用，这跟后来 K8s 里 apiserver 和业务 Pod 的关系是同一个设计思想，我经常拿这个对比讲。
问②RAID 怎么规划的？： TaiShan 2280 这款机器不带 RAID 卡，所以是在安装过程中组软 RAID。方案是：系统盘两块 600G SAS 组 RAID1——系统盘的要求就是"坏不掉"，两盘互为镜像，允许坏一块，容量损失一半无所谓；数据盘 3.84T 的 SSD 组 RAID5——条带加分布式奇偶校验，容量和冗余平衡，允许坏一块盘，SSD 的性能把校验的写惩罚弥补掉。还有一个关键参数是我在 Vastbase 部署规范里学到的：Disk Cache Policy 必须设为 Disabled，防止掉电时磁盘写缓存里的数据丢失，对数据库场景这是致命项，这条是验收检查项。
问③iBMC 装系统的流程？： 六步：先做 RAID；然后登录 iBMC 打开虚拟控制台，用工具栏把本地的 ISO 镜像挂载成虚拟光驱——CNA 一个镜像、VRM 一个镜像，都是 ARM_64 版本；接着走安装向导，选目标逻辑盘、配管理平面 IP、主机名、时区、root 和 grub 密码，装 VRM 还要选密码算法模式，0 国际 1 国密，只能设一次不能改；装完重启，root 登录执行初始化——CNA 跑 cnaInit、VRM 跑 vrmInit，等到回显初始化成功；再浏览器登 8443 做 License、MAC 段、NTP 初始化；最后建集群、加主机、加存储、建网络。中间踩过一个很典型的坑：iBMC 虚拟控制台默认英文键盘布局，方向键会失灵菜单选不了，要切成日语键盘布局才正常——这个坑我写进了部署指南。
问④虚拟机怎么批量发放的？： 前提是集群、数据存储、端口组三样就绪。流程：VRM 界面创建虚拟机，选集群（不绑定主机，保留 HA 能力）、按 IP 规划表选规格和端口组，挂 ARM 版 ISO 光驱启动，VNC 控制台里装统信或麒麟；第一台标准机装好后装 Guest Tools、改主机名、配 IP 和时间同步、过安全基线，后面的机器按统一规格逐台发放，系统和配置一次到位。15 台以上虚拟机都是这么交付的，规格和 IP 严格按部署规划表执行。我的心得是：批量交付的质量取决于规划表的细度——表做细了发放就是体力活，表不细每一台都是坑。
- 真实数字锚点：4 台 TaiShan（96 核/384G/3.84T SSD）、CNA×3+VRM×1、15+ 台国产 VM、iBMC 日语键盘坑。
P1-2 「负责 DME 22.0 的安装部署与 FusionCompute 对接，实现虚拟化资源统一纳管、告警同步与集中监控」
- 涉及知识点 → 第08章（DME 与 FC 对接）。
问①DME 是什么、和 FC 什么关系？： DME 是华为的数据管理引擎，定位是虚拟化资源的统一运维管理面。FC 管的是"这一套"虚拟化环境自己；DME 在它之上做跨设备统一纳管——多套 FC、存储设备一个入口全看到，集中告警、容量报表、统一监控，这正对银行集中监控运营的要求。对接方式很轻：在 DME 里接入 VRM 的地址，FC 上的资源就自动注册纳管过来。两者打包起来就是我们方案里说的 DCS 数据中心虚拟化方案。部署形态我用 SmartKit 的部署向导做的，选 ARM 加 EulerOS，三节点集群，每节点 1T 磁盘。
问②对接怎么验证成功的？： 我的验收标准很实在：告警链路通。做法是在 FC 侧配置 SNMP 告警管理站指向 DME，然后确认 FC 产生的告警能通过 SNMP 上报到 DME 侧——两侧告警能对上，对接就是通的；反过来只看资源列表出来了还不算数，告警不通等于监控是瞎的。验证过程中还确认了两个关键细节：DME 每 30 分钟对 FC 做一次全量资源同步，所以 FC 上的变更最多 30 分钟后才在 DME 呈现，排障时要想到这个时间差；另外接入 VRM 之后不能再改 DME 的管理浮动 IP，改了 VRM 同步会失败——这两条都写进了实施文档，是"真做过"的细节证据。
问③有了 FC 为什么还要 DME？： 层次不同。FC 是虚拟化本体，管虚拟机怎么跑；DME 是运营层，管多套系统怎么统一监控管理。环境只有一套 FC 时 DME 价值不明显，但银行是 FC、存储、多套平台并存的环境，安全运营要的是集中告警、统一报表、容量趋势这些能力，逐套登录页面看是管不过来的。这跟 K8s 里"有了集群为什么还要 Prometheus"是同一类问题——运行层和观测管理层是两个职能，生产环境缺一不可。
- 真实数字锚点：DME 22.0 三节点（ARM+EulerOS、每节点 1T）、30 分钟全量同步、浮动 IP 不可改、SNMP 告警同步验收。
P1-3 「负责 Kubernetes 集群部署与高可用改造：在统信 UOS（ARM）环境完成 Docker 与 kubeadm 组件部署，先搭建单 master 集群，再通过 Nginx + Keepalived（VIP 漂移 + 健康检查脚本）升级为多 master 高可用架构并完成故障转移测试」
- 涉及知识点 → 第06章（kubeadm/集群）、第04章（Nginx stream 四层 + Keepalived）。
问①单 master 升多 master 的完整步骤？（六步，必须能背）： 第一步在负载均衡机上装好 Nginx stream 模块，配四层代理监听 16443——为什么是 16443：负载均衡和其中一台 master 复用机器，6443 已被占用；第二步导出 kubeadm-config；第三步最关键——补 certSANs，把新 VIP 和三台 master 的主机名 IP 都加进去，不补后面一定踩 x509 的坑；第四步把 /etc/kubernetes/pki 下的旧 apiserver 证书移走，用 kubeadm init phase certs apiserver 重新签发，再把配置回写；第五步把证书 scp 到 master02、03，它们带 --control-plane 参数 join 进来成为控制面节点；第六步配 Keepalived——VIP、priority 100/90、健康检查脚本，最后整体验证。这六步我在生产上完整做过，顺序错了就会卡住，比如证书没重签就去 join，新节点连 apiserver 直接报证书错误。
问②升级后连不上集群怎么回事？： 就是这个项目最有故事的故障：升级完成用 VIP 连集群，kubectl 报 x509 证书错误。排查用 openssl x509 -in apiserver.crt -text -noout 看证书详情，发现 SAN 字段里只有原来单 master 时期的地址，没有新 VIP 和新主机名——客户端连 VIP 时按证书校验身份，证书里没有这个地址就拒绝信任。解法就是回到第三步：kubeadm 配置里补全 certSANs、移走旧证书、重新签发 apiserver 证书、重启组件。教训一句话：改集群入口地址必须先想证书。这个案例我在第14章有完整版，是我讲"证书机制理解"的主案例。
问③Keepalived 怎么防脑裂？： 三道防线。第一道也是最重要的：健康检查脚本检测的是真实业务端口——脚本里探测本机 16443 有没有监听，而不是探测 Keepalived 进程本身，因为 Keepalived 活着不代表后端服务活着，检测目标选错，VIP 漂移就失去意义；第二道：主备 priority 拉开差距，100 对 90，避免抢占时的抖动；第三道：advert_int 设 1 秒，故障检测足够快。另外内网环境组播偶尔有问题时可以切单播指定对端。脑裂的本质是"两边都认为自己该持有 VIP"，防的思路就是让检测信号贴近真实服务、让优先级明确。
问④故障转移怎么验证的？： 实测三件事：第一件，主负载均衡节点关机——实测 VIP 在秒级漂移到备节点，备用 Nginx 接着代理 16443；第二件，漂移后通过 VIP 执行 curl -k https://VIP:16443/version 和 kubectl get nodes，都正常返回，说明控制平面入口恢复；第三件，恢复主节点后确认它重新接管或者保持备角色，集群状态正常。高可用这个东西，设计图画得再漂亮，没有实测都不算数——"VIP 漂移 + 端口探测 + 实测验证"这一套走完，我才敢在验收报告上写故障转移测试通过。
- 真实数字锚点：K8s v1.17.3 + Docker 18.09（BCS 1.2.6 配套约束）、3 master + 10 work、16443 端口、Keepalived priority 100/90、haproxy 和 Nginx 两方案都做过后期标准化到 Nginx。
P1-4 「负责 Vastbase G100 数据库一主一备高可用集群的部署、license 配置与环境验收」
- 涉及知识点 → 第03章（Vastbase/OpenGauss、主备、与 MySQL 对比）。
问①为什么用 Vastbase 不用 MySQL？： 三个原因，都是硬约束：第一，信创要求——数字人民币项目全链路国产化，数据库必须在国产目录里，Vastbase 是 openGauss 的商业发行版、PostgreSQL 系，在信创目录内；第二，配套认证——它是华为 BCS 方案的配套数据库，跟鲲鹏平台做过兼容认证，版本配套表里就是这么配的；第三，架构原生适配——它对鲲鹏 ARM 是原生支持，安装包直接就是 aarch64_kunpeng 专用版本，不需要任何兼容层。所以这不是我跟 MySQL 的技术对比能决定的选型，是金融信创环境的标准答案——但选型原因、配套关系我能讲清楚，这也是"按配套表落地"角色里我该有的理解深度。
问②一主一备怎么部署验收的？： 部署用海量侧提供的自动化安装脚本：两个节点同时执行安装，中间的时间误差不能超过 10 秒，这是脚本的要求——保证集群初始化时状态一致。装完配 license，然后做四步验收：一查 DCS——Vastbase 底层的分布式一致性服务状态正常；二查 HAS——高可用服务组件状态正常；三查数据库集群状态——主备角色正确、复制链路正常；四做功能验证——vsql 建用户建库，再用 DataStudio 从管理机远程连上去做真连接测试。四步全过，数据库这块才算验收完成。中间还处理过 license 到期的操作，那次的教训我放在行为题里专门讲。
问③调过什么参数？： 主要是两个：max_connections 从默认的 100 调到 10000——银行业务系统的连接数需求大，配套的自研平台连接池打满时默认值远远不够；同时打开线程池——openGauss 系的线程池模式能让高连接数下的调度开销可控，避免一万连接把资源耗在上下文切换上。这两个参数是按业务侧评估的连接规模定的，不是拍脑袋调大。其他主要按部署规范走基线配置——生产数据库我的原则是参数变更都要有依据、有记录。
- 真实数字锚点：Vastbase G100 2.2、HAS 高可用 + DCS、max_connections 100→10000、license 3 个月免费期、两节点安装误差 ≤10 秒。
P1-5 「参与华为 BCS 边缘自治版与数币智能合约管理平台的部署联调，部署 Prometheus + Node Exporter 实现基础监控，配合完成平台上线与客户验收」
- 涉及知识点 → 第07章（Prometheus）、第06章（BCS 纳管/镜像）、第03章（Redis）、第04章（Nginx 反代）。
问①内网环境镜像怎么解决的？： 银行内网拉不到任何海外镜像，这是国产化环境最现实的问题。我的解法是离线导入流水线：在外网可达的环境把需要的 arm64 镜像下载好打成 tar.gz 包，带进内网；然后我写了一个批量加载脚本——遍历镜像目录下的所有 tar 包，排除掉 BCS 管理面自带的镜像（那些已经在了），对剩下的逐个执行 docker load 导入，最后统一打 tag。这样十几台数据面节点的镜像问题一个脚本解决，重复劳动归零。这个脚本后来也进了部署文档——内网交付场景它是刚需。
问②BCS 怎么纳管数据面节点的？： BCS 边缘自治版分管理面和数据面：管理面三个节点是华为侧的平台，数据面六个节点就是承载业务的 K8s 节点。纳管用 Token 认证：用 edgetool 工具在数据面集群创建一个 edge-admin 的 ServiceAccount，从对应的 secret 里解出 token，把这个 token 填到 BCS 管理平台的数据面接入配置里，管理面就能纳管这个集群了。本质就是 K8s 的 RBAC 服务账号机制做跨集群的认证——理解了 K8s 的 ServiceAccount 和 token，这个流程就是透明的。
问③监控搭了什么？： 按 BCS 的监控规范部署了 Prometheus 2.33.5 加 Node Exporter 1.3.1，部署在 BCS 的 monitor 命名空间里：Node Exporter 以 DaemonSet 方式跑在每个节点，采集 CPU、内存、磁盘、网络这些节点指标；Prometheus 抓取后配合管理面已有的监控看资源状态。这是基础监控的定位——节点层和平台层的关键指标有数可看、有告警可报；更完整的一套三件套体系是我在项目二建的，正好可以拿来做对比讲：从"够用的基础监控"到"独立节点加集群内混合部署的完整可观测体系"，体现的是不同场景下的监控设计取舍。
问④上线验收流程是什么样的？： 四段式：环境验收——全组件 Pod 状态 Running、etcd 集群健康、Vastbase 主备正常、核心功能冒烟通过，这是技术验收；文档交付——部署指南、巡检手册、配置清单移交给客户；客户培训——平台使用、日常巡检、告警处置的实操培训；驻场保障——上线初期我在现场值守保障，稳定后转日常支持。自研合约平台的部署链路我也可以完整说：毕昇 JDK 8u362 环境准备 → Vastbase 建库导数 → Redis 5.0.3 缓存层 → 应用 jar 包部署加 BCS 证书转 p12 → Nginx 1.25.1 反代 /prod-api/ 路径，全链路联调通过后平台上线。
- 真实数字锚点：BCS 1.2.6（管理面 3 节点 + 数据面 6 节点）、Prometheus 2.33.5、Node Exporter 1.3.1、Redis 5.0.3、Nginx 1.25.1、毕昇 JDK 8u362。
第四部分 项目二：移动云生产级 Kubernetes 集群与可视化运维管控体系建设（2025.07–2026.10）
P2-1 「负责集群架构落地：按通用高可用架构规划 3 master + 3 worker + 独立监控节点，CLB 四层负载均衡实现控制平面统一接入与健康检查自动摘除，跨可用区部署实现机房级故障隔离」
- 涉及知识点 → 第06章（控制平面/etcd 奇数）、第09章（CLB/VPC/可用区）。
问①为什么 3 个 master、etcd 为什么奇数？： 根源在 etcd 的 Raft 一致性算法：写操作需要多数派节点确认，集群的容错能力是"总节点数减一的半数"——3 副本容忍 1 台故障，5 副本容忍 2 台。关键是要算清楚边际成本：4 副本的多数派是 3 台，容错能力跟 3 副本一样只容忍 1 台故障，多花一台机器没有换来任何容错提升——所以偶数副本是纯浪费，etcd 生产部署永远取奇数：3 或者 5。我们按业务规模评估，3 副本容忍单机故障已经满足要求，上 5 副本的资源成本不划算。这个"奇数不是迷信、是多数派数学"的道理讲清楚，面试官就知道你是真理解 Raft 而不是背结论。
问②CLB 和自建 Nginx+Keepalived 怎么选的？： 这是我有独特发言权的对比题，因为两个方案我都真做过。银行内网项目：没有云负载均衡可用，我自建了 Nginx 加 Keepalived——stream 模块四层代理 apiserver、VIP 漂移、健康检查脚本，脑裂防护我自己设计，优点是可控，代价是这套东西本身成了要维护的对象。移动云项目：有托管 CLB，它自身就是多可用区高可用架构没有单点，健康检查、自动摘除都是平台能力，配一下就用，不用维护 VIP 不用写脚本。结论就是：云上首选托管服务，把精力留给业务；内网环境自建方案我也验证过能力。这个对比的价值在于我不是只见过其中一种。
问③跨可用区部署的意义是什么？： 可用区是同地域内电力、网络相互独立的机房。跨可用区部署的意义就一句话：把故障域从"机房内部"缩小到"单个机房"——任何一个可用区整体断电断网，另外两个可用区的 master 继续构成多数派，集群照常决策；业务节点同理，未受影响可用区的 Pod 继续服务。配合 CLB 的健康检查，故障可用区的节点被摘除，流量无感切换。这不是理论推演，我们做过演练验证。代价也要说：跨可用区网络延迟比同机房略高，但对我们这种规模的集群完全可接受——用很小的延迟代价换机房级容灾，这笔账非常划算。
- 真实数字锚点：7 台 ECS（master 2C4G、worker 8C16G、监控 4C8G）、三可用区、CLB 四层 6443、99.99% 设计目标、设计原则五条（冗余/解耦/故障自愈/分层防御/强一致）可整段背。
P2-2 「完成全节点标准化初始化与集群部署：containerd 运行时（Systemd cgroup）、内核参数调优、NTP 时间同步，kubeadm 搭建 Kubernetes v1.28.2 三副本控制平面，部署 Flannel VXLAN 网络插件，并沉淀海外镜像拉取失败、RBAC 字段不可变等 9 项生产避坑清单」
- 涉及知识点 → 第06章、第01章（内核参数/swap）、第14章（避坑=故障案例）、第10章（IaC 思想）。
问①初始化都做了什么、为什么？： 五件事，每件都有明确的"为什么"。第一关 swap——K8s 的 kubelet 要求关掉交换分区，内存交换会让容器的资源调度和 OOM 行为不可预期；第二加载 overlay 和 br_netfilter 内核模块——overlay 是容器存储驱动要用的，br_netfilter 让网桥流量经过 iptables，Flannel 的跨节点转发依赖它；第三 sysctl 调优——开 ip_forward、bridge-nf-call-iptables 这些参数；第四文件句柄数调大，etcd 和高并发场景默认值不够；第五 chrony 时间同步——证书校验、etcd 选主都对时间敏感，时间漂移会出诡异问题。这七台节点我先在一台上验证整套初始化，再统一执行到全部节点——这就是 IaC 的思想：期望状态统一定义、所有节点收敛一致，新环境照着重放就能复制。
问②containerd 有哪三项关键配置？： 第一，SystemdCgroup 设为 true——并且要跟 kubelet 的 cgroup 驱动对齐，两边不一致是节点 NotReady 的经典原因，容器资源统计会对不上；第二，pause 镜像换国内源——sandbox 基础镜像默认是海外地址，拉不下来节点起不来 Pod；第三，/etc/crictl.yaml 里显式绑定 containerd 的 socket——让 crictl 和 kubelet 都明确用 containerd 的运行时端点，避免 Docker 遗留环境混用出歧义。这三项加上"1.24 之后没有 dockershim、容器运行时直接对接 containerd"的背景，就是 v1.28 集群运行时的完整图景——跟银行项目的 Docker 18.09 正好是两个时代的对照。
问③9 项避坑挑两个详细讲？： 讲最有代表性的两个。第一个，节点 NotReady 的排查：经验里九成的 NotReady 根因是镜像拉取失败——CNI 插件、pause 这些关键镜像拉不下来，kubelet 起不来网络组件，节点就 NotReady。我的分层策略是：优先内网私有仓库，备选阿里云公共镜像源，最后兜底二进制手动部署——三层保险把这个问题系统性解决。第二个，ClusterRoleBinding 的 roleRef 字段不可变：我改一个绑定的角色引用时报错"不可修改"，因为 RBAC 的 roleRef 在 API 层面就是 immutable 的——正确做法是删除整条绑定再重建，不能原地改。这两个坑一个关于"装得起来"，一个关于"K8s API 的设计约束"，都很典型。
问④部署顺序是怎样的？： 顺序上有一个关键点容易错：CNI 必须先于 worker 加入。完整顺序：全节点初始化 → master01 执行 kubeadm init 起三副本控制平面的第一个节点 → master02、03 join 进控制面 → 部署 Flannel CNI——这一步必须在加 worker 之前，因为网络插件没就绪，新节点的 Pod 网络不通，worker 加进来核心组件全 CrashLoop → 然后 worker 加入 → 全节点健康验证 → 最后上监控和 Kuboard。为什么强调这个顺序：我踩过"节点都加完了才装 CNI"导致一批 Pod 起不来的低级弯路，从此把"CNI 先于 worker"写进方案的部署顺序里，这也是 9 项避坑清单里的一条。
- 真实数字锚点：K8s v1.28.2、containerd 1.7.8、Flannel v0.22.0、9 项避坑全部实际踩过验证过（完整清单见项目笔记与第14章）。
P2-3 「构建"公网拉取 → 内网私有仓库托管 → 集群认证拉取"的镜像双轨体系，通过 ImagePullSecret 实现私有镜像安全分发」
- 涉及知识点 → 第05章（镜像仓库/私有仓库）、第10章（制品库）。
问①为什么要建双轨体系？： 两个现实约束逼出来的设计：一是节点不直连公网——生产集群的节点是纯内网机器，统一走 NAT 网关出公网，直连海外镜像源既慢又不可控；二是安全要求——镜像来源必须可控可审计，不能节点想从哪拉就从哪拉。所以设计成两轨：公网轨——能出公网的环境先把需要的镜像拉下来，重新打 tag 后推送到移动云的私有镜像仓库托管；内网轨——集群所有节点统一从内网私有仓库拉取，用认证凭据访问。效果是三个：拉取速度快（内网带宽）、不出公网（收敛出口）、全程可管控（仓库有账号有审计）。Flannel 的 DaemonSet 里 init 容器和主容器的镜像我都做了全局替换，全部指向内网仓库地址——这个细节是"真在内网装过集群"的铁证。
问②ImagePullSecret 怎么配的？： 三步：第一步用 kubectl create secret docker-registry 命令创建认证 Secret，参数里带上内网仓库的地址、用户名和密码——这个 Secret 本质是一段 docker auth 的 base64 配置；第二步在业务 Deployment 的 spec 里通过 imagePullSecrets 字段引用这个 Secret 的名字；第三步注意 Secret 是命名空间级资源，新命名空间要用的话要在那个命名空间再建一份。配好之后 Pod 调度到任何节点都能安全拉取私有镜像，凭据统一管理、不散落在各节点上——跟运维管密钥的原则一致：凭据集中、最小分发。
问③镜像版本怎么管理的？： 一条铁律：严格版本 tag，禁用 latest。我们的规则是每次构建用唯一版本号做 tag——_BUILD_ID 或者 git 短哈希——保证一次构建对应一个不可变的版本。为什么这么较真：latest 有两个致命问题，不可追溯——出了问题说不清线上是哪次构建；缓存不可控——节点缓存了旧 latest 就不会重新拉，发布了等于没发。版本 tag 管好了，发布可以精确指定版本、回滚可以精确回到任何一个历史版本，全链路可追溯——这是"能五分钟回滚"的前提条件。
- 真实数字锚点：内网仓库为主 + 阿里云公共仓库备选；Flannel init 容器与主容器镜像全局替换；ImagePullSecret 命名空间级分发。
P2-4 「搭建监控体系：独立节点二进制部署 Prometheus + Grafana，集群内部署 kube-state-metrics，全节点安装 Node Exporter，实现节点、控制平面与集群对象指标采集与可视化大盘」
- 涉及知识点 → 第07章全部（架构/采集/Grafana）。
问①为什么用"二进制 + 集群内"混合部署？： 按"每个组件放哪最合适"分别决策的。Prometheus 和 Grafana 放独立监控节点二进制部署：一是监控不占集群资源，监控采集和业务负载互不影响；二是故障隔离——集群出问题时监控还活着，"观察者不能和被观察者一起死"，这是可观测体系的设计原则，如果 Prometheus 本身就在集群里，集群挂了监控也挂了，你正需要看数据的时候它没了。kube-state-metrics 必须部署在集群内：它的工作就是监听 K8s API、暴露 Deployment、Pod 这些集群对象的状态指标，离开集群它无从工作。Node Exporter 的情况特殊：内网仓库里没有它的镜像，我直接用 apt 装的二进制版本，默认监听 9100 端口，跟容器版采集的指标完全兼容——工具形态服从目标，不为了统一而统一。
问②怎么发现采集目标的、为什么不用服务发现？： 我用的是 static_configs 静态配置：六台节点的 node-exporter、集群里的 kube-state-metrics、还有经 CLB VIP 访问的 apiserver——https 加 insecure_skip_verify 跳过证书校验。为什么不上 kubernetes_sd_configs 自动发现：我们的规模是六台节点、变更频率很低，静态配置一目了然、排查直观；自动发现在大规模动态环境才发挥价值。这个取舍我能讲清楚：不是不会用服务发现，是当前规模下静态更可控；如果集群扩到几十上百节点，就切服务发现——监控方案的演进跟着规模走。
问③采集哪些指标、怎么用起来的？： 三层指标：节点层——Node Exporter 的 CPU、内存、磁盘、网络，节点资源一目了然；控制平面层——apiserver 的请求延迟、etcd 的写入和心跳，控制面的健康状态；集群对象层——kube-state-metrics 提供的 Deployment 副本数、Pod 状态分布、重启次数，"业务是不是健康"从对象状态直接可读。展示层 Grafana 导了 Node Exporter Full 和 K8s 集群两套大盘，日常巡检开大盘扫一眼，异常下钻到具体指标。从"人肉 top 巡检"到"指标大盘加告警"，这是我在银行项目和移动云项目之间最直观的进步——监控体系的价值就是把发现问题从被动变主动。
- 真实数字锚点：kube-state-metrics 2.7.0（Deployment + NodePort 30080，复用内置 view 只读角色）、六节点静态采集、apiserver 走 CLB VIP；避坑 5/6/7（Grafana GPG 404、promtool 在主包里、node-exporter 无镜像）都发生在这条。
P2-5 「部署 Kuboard 可视化运维平台（固定节点调度 + hostPath 持久化 + RBAC 多级权限 + 操作审计），覆盖工作负载编排、日志终端排障等日常运维场景」
- 涉及知识点 → 第07章（Kuboard）、第06章（调度/污点/持久化）。
问①为什么选 Kuboard？： 需求决定选型：我们需要一个低门槛的可视化运维入口，让不熟 kubectl 的同事也能做日常操作。Kuboard 的匹配点：轻量——一个 Deployment 就部署起来，不像某些平台要一整套微服务；中文界面——对使用团队最友好；功能覆盖日常运维全场景——工作负载管理、扩缩容、日志、终端、权限、审计开箱即用。对比过其他方案：Rancher 更重、Lens 是桌面端不好统一管理，Kuboard 的"装即用"最贴合我们的规模和团队画像。选型逻辑跟 AI 工具一样：先看用户和使用成本，再看功能——工具是用来降低门槛的，不是炫技的。
问②部署的五个步骤和细节？： 五步，每步有讲究：第一步在能出公网的节点 pull Kuboard 镜像；第二步重新打 tag 推到内网私有仓库——延续镜像双轨体系；第三步建命名空间并创建 docker-registry 认证 Secret；第四步写 Deployment，四个关键点——nodeSelector 把它固定调度到 master-01（管控链路最短）、tolerations 容忍 control-plane 污点（否则 master 有污点调度不上去）、imagePullSecrets 引用认证、hostPath 用 DirectoryOrCreate 类型做持久化；第五步 NodePort 30088 暴露服务，首次登录强制改密码。这五步背下来，就是一个完整的"内网环境部署第三方平台"的标准作业流程。
问③持久化怎么做的、怎么验证的？： 用 hostPath 把 Kuboard 的数据目录挂到 master-01 节点的本地目录，存储它的配置、用户信息和审计日志。为什么用 hostPath 而不是 PV：单实例平台的数据量小，固定节点调度加本地目录是最简单可靠的组合，避免为一套管理平台再建一套存储体系。验证方法很直接：实测删除 Pod 再重建，登录账号还在、配置还在、审计记录还在——数据确实落在节点本地而不是容器层，这就证明持久化生效。当然这个方案的前提是固定节点调度：Pod 必须每次都调度回同一台节点才能找到数据，所以 nodeSelector 和 hostPath 是配套设计，不能只用其一。
问④覆盖了哪些日常运维场景？： 按使用频率说：工作负载编排——Deployment 的创建、更新、扩缩容页面直接操作；发布回滚——滚动更新状态可视、历史版本一键回滚；日志排障——实时日志流、按容器筛选，比 kubectl logs 直观；容器终端——网页里直接进容器排查，等同于 kubectl exec；权限和审计——按命名空间做多级 RBAC，谁在页面上做了什么操作都有审计记录。综合下来日常运维 80% 以上的操作在页面完成，kubectl 只留给少数深度排查场景——"可视化覆盖 80% 日常场景"这个简历表述就是这么来的，有实测依据。
- 真实数字锚点：Kuboard v3.5.2.2、master-01 固定调度、NodePort 30088、日常 80% 操作页面完成；与 P2-4 合起来支撑"可视化运维管控体系"。
P2-6 「配套规划云数据库 MySQL（主备高可用）、Redis（双机热备）、RocketMQ、Nacos 及 WAF、DDoS 防护、主机安全、数据库审计等云服务」
- 涉及知识点 → 第09章（云服务/安全）、第03章（数据库/中间件）。
问①为什么数据库不入 K8s 用云托管？： 我坚持的原则：有状态的重服务用云托管，无状态的应用进集群。理由三条：一是数据一致性——数据库跟容器的滚动更新模型天然冲突，更新数据库实例的过程中怎么保证事务不丢、主备不脑裂，这类问题交给专业托管服务比自己踩坑稳；二是伸缩粒度——应用扩容是加 Pod 秒级的事，数据库扩容是换规格迁数据的小项目，粒度完全不同；三是故障域——数据库和应用同集群，一次误操作或者资源争抢可能同时伤害两层，分开部署故障域隔离。云托管的 MySQL 主备自动切换、自动备份、监控告警都是现成的，我们快速上线要的就是这个。当然自建数据库的能力我有——银行项目 Vastbase 一主一备是我搭的——两种路线的成本和风险我都真实掂量过，这个决策是掂量的结果。
问②各服务的规格怎么规划的？： 按业务量估算加余量：MySQL 选 8.0 主备版 8 核 16G、300G SSD——按业务并发和数据增长估算，留出发展余量，主备同城热备；Redis 双机热备——做缓存和会话，容量按热数据规模定；RocketMQ 两节点——消息队列按峰值吞吐选规格，两节点起步保证基本可用；Nacos 做注册配置中心——轻量规格够用。我的职责链是：评估业务需求、定规格和版本、规划安全组与访问控制（只对应用子网放行）、把连接信息标准化交付给应用团队。规划的核心思路是"按量选型、留有余量、按需再扩"——云上规格随时能升，宁可起步适度不盲目高配。
问③安全类服务是必须的吗？： 是硬性要求，不是可选项。业务系统要对外服务，等保合规和客户的安全要求摆在那里：WAF、DDoS 防护、主机安全、数据库审计这四件套是等保测评和客户上线评审的检查项，缺了业务上不了线。除了合规，实际价值也真实存在：主机安全的基线核查帮我提前发现弱口令和高危端口这类问题，数据库审计让所有 SQL 访问可追溯——安全服务平时看着"没用"，出事的时候就是救命的和定责的。我的角色是配置管理者：策略怎么配、告警级别怎么定、发布时怎么放行，这块我在第09章有完整展开。
- 真实数字锚点：MySQL 8.0 主备 8C16G/300G SSD、Redis 双机热备、RocketMQ 两节点、Nacos；体现"集群运维 + 云服务运维"双能力。
P2-7 「完成控制平面故障切换演练（停止 Master 节点 kubelet 验证 CLB 自动摘除与流量无感切换）、etcd 快照备份与证书续期规范制定」
- 涉及知识点 → 第06章、第14章（演练即故障预演）。
问①演练的具体步骤和结果？（现场讲操作的标准答案）： 四步完整讲：第一步制造故障——停掉 master-02 上的 kubelet，模拟控制平面节点故障，注意是停 kubelet 不是关机，风险可控可恢复；第二步观察 CLB 行为——CLB 对三个 master 的 6443 配了健康检查，kubelet 停止后节点上的控制面组件不可用，CLB 在秒级把 master-02 从后端服务器组摘除；第三步验证无感——通过 CLB 的 VIP 执行 kubectl get nodes，命令正常返回，说明控制平面请求已经全部由 master-01 和 03 承载，客户端侧完全无感；第四步恢复验证——重启 kubelet，控制面组件自动拉起，etcd 自动同步追平数据，节点重新回到集群。结论八个字：秒级摘除、无感切换——这是演练实测结论，不是宣传语。Worker 层的保障另算：业务 Pod 多副本加反亲和，节点故障时 Pod 在其他节点分钟级重建。
问②etcd 备份具体怎么做的？： 用 etcdctl 的 snapshot save 做快照，命令要带三个证书参数——cacert、cert、key——因为 etcd 的客户端端口是 TLS 加密的。备份分两类：定期备份——按规范周期执行，快照文件连同证书一起保存到集群外的位置，这一条很关键，备份放在故障域里等于没备份；变更前备份——凡升级、改配置这类大动作之前必打一份快照，这是给自己留的后悔药。恢复流程也验证过：etcdctl snapshot restore 加数据目录参数，配合控制面组件重启。etcd 是集群的账本，我对它的态度就是：可以不用恢复，不能没有备份。
问③证书续期规范怎么定的？： 三条：第一，时间线——kubeadm 证书默认一年有效，规范定为到期前 30 天执行 kubeadm certs renew all，留足缓冲避免"还有三天到期"的仓促操作；第二，工具化提醒——监控里配证书剩余天数告警，提前 30 天自动报，把记忆交给系统；第三，操作规范——续期后要重启 apiserver 等组件生效，操作窗口和验证步骤写进运维手册，每一步可回溯。定这个规范的真实动因是银行项目的教训——我处理过 BCS 中间件证书过期引发的问题，排查过程极其痛苦，所以自己建集群时证书管理是第一批写进规范的事项。防患于未然的成本永远低于救火的成本。
- 真实数字锚点：演练四步完整可复述、秒级摘除实测、证书提前 30 天续期、etcd 快照含三证书参数——这条是面试官最爱现场追问"具体怎么操作"的单元。
第五部分 项目三：企业 AI 工具评估落地与智能知识库建设（2025.07–2026.10）
项目三的定位是差异化加分项——面试官不一定懂 AI，但一定会好奇"运维的人为什么做 AI"；所有回答收在"选型评估、成本治理、知识管理"这些展示运维素养的关键词上，技术原理点到为止（详见第11章）。
P3-1 「基于阿里云百炼（Model Studio）API 接入主流大模型，使用 Cherry Studio 搭建并维护企业知识库与 RAG 问答应用，导入公司全部《解决方案》与技术文档，支撑新员工入职方案学习与售前快速问答」
- 涉及知识点 → 第11章（RAG 原理/向量库/Prompt/幻觉）。
问①RAG 原理完整讲一遍？： 我按数据流讲两段。建库段：把公司文档做三类清理——剔过期版本、敏感信息脱敏、格式统一——然后切分成几百 token 的片段（相邻留重叠防止语义切断），每个片段用 embedding 模型向量化，存进向量库。问答段：用户提问先被向量化，在向量库里按余弦相似度召回最相关的片段，经过重排模型精选，把"问题加精选片段加指令"拼成提示词给大模型，生成带出处的回答。为什么这套适合企业知识：文档更新了重新入库就行、不用训模型；回答能标注出处、可溯源；能按权限控制召回范围；成本比微调低一个量级。核心一句话：让模型开卷考试，而不是闭卷瞎猜。
问②知识库怎么建起来的？： 七步流程：一数据准备——收集文档做清理和脱敏，敏感内容不进全员库；二工具准备——Cherry Studio 加百炼 API，开通 embedding 和对话模型；三建库——选 embedding 模型、配切分参数；四导入——分批入库，重点检查切分预览里表格和代码有没有被切碎；五建应用——助手绑定知识库，写好系统提示词（仅根据资料回答、不知道就答不知道、给出处），temperature 调低；六验证调优——用 20 到 50 题的评测集实测，答不上的按检索段、生成段、数据段三段定位调参；七上线治理——按部门授权、建立文档更新流程、密钥用量统一管理。这套流程完整走过两轮以上，是我的标准作业程序。
问③答不准怎么优化的？举实例。： 举个真实的例子：有一类含大量规格表的方案问题，知识库总答不完整。我按三段定位法排查：翻召回日志，发现目标内容其实被召回了，但表格被固定长度切分打散——相关单元格和表头不在同一个片段里，模型拿到的是断成两半的表。对策：对这类文档改用按章节切分、缩小块并加大重叠，top-K 也调大一档让模型能拿到完整表格上下文。改完用评测集复测，该类问题回答完整度明显上来。最后把"表格类文档单独切分策略"写进建库规范，同类问题不再复发——单点问题的解法沉淀成规则，这是优化的完整闭环。
问④怎么防泄密的？： 四层：平台层——账号权限分级，API 密钥统一由我配置管理、不落到个人手里；数据层——文档分级入库，含报价、客户名单的敏感文档不进全员知识库；应用层——知识库应用按部门授权，调用有审计记录；边界层——部署形态可控，公司数据不出内网和可信云环境。这四层是"选型—使用—成本—合规"闭环里合规那条腿——做 AI 落地只讲功能不讲合规是走不远的，密钥和数据安全出一次事，整个项目就清零了，这是我作为运维出身做 AI 项目的本能。
- 真实数字锚点：文档=公司全部《解决方案》与技术文档；场景=新员工入职学习+售前快速问答；评测集 20–50 题。
P3-2 「使用 Coze 搭建自动化工作流，并面向全员开展 AI 工具培训与分享，沉淀提示词模板与实践案例库」
- 涉及知识点 → 第11章（工作流 vs Agent/Prompt 工程）。
问①工作流举一个具体例子？： 讲最有代表性的"方案要点提取"工作流。输入一份新方案文档，自动输出三样东西：结构化摘要、适用客户画像、售前三句话卖点，发到指定群。节点编排五步：文档读取节点解析正文 → 大模型节点一做摘要（方案分析师角色，输出背景、架构、亮点、报价模式四段）→ 大模型节点二做售前话术（资深售前角色，输入是节点一的输出）→ 格式化节点拼装固定消息模板 → 通知节点发群。两个设计点值得说：主流程用固定工作流而不是自由 Agent——可靠性优先，每一步做什么确定可控；两个大模型节点各司其职，提示词短而专，比一个大提示词效果好还省 token——这也是成本控制的落点。每个节点配了失败重试和异常提醒分支。
问②全员培训怎么做的？： 我的原则是分场景实操、不讲概念课。按受众分组：售前同事教怎么问知识库——怎么提问召回准、怎么核对话术出处；开发同事教 AI 编程提效——提示词怎么写、生成代码怎么审；全员教办公模板——周报、纪要、润色直接套模板。每次培训只讲一个场景、练一个模板，培训完模板归档进提示词库，随用随取。效果验收看两个数：各应用的调用量有没有涨（真在用）、用户的反馈和产出（真有用）。培训是运营动作，讲完就散的那不叫培训。
问③沉淀了什么资产？： 三类可复用资产：提示词模板库——方案摘要、周报、招标应答、代码解释等十几个场景化模板，全员直接套用；实践案例库——知识库建设、工作流搭建、测评方法这些实操记录，新人照着能复刻；选型评估报告——每次重要模型测评的结论和成本分析，全员分享，后续选型直接引用。这些资产比"会用某个工具"值钱——工具会过时，方法和模板沉淀下来是组织的。这也是我做这个项目最有成就感的部分：把个人经验变成了公司资产。
- 真实数字锚点：方案要点提取工作流五节点；模板十余个场景；与运-5 的 IT 知识库呼应："重复劳动→流程化/模板化"是个人方法论。
P3-3 「在研究与落地过程中掌握 LangChain、LangGraph、deepagents 等 AI 应用开发框架，具备 AI 应用原型开发能力」
- 涉及知识点 → 第11章（框架定位/诚实边界）。
问①三个框架分别干什么？： 一句话一个。LangChain：最主流的大模型应用开发框架，把调模型、接知识库、加工具、链式编排封装成组件，拼积木式搭原型，入门必学。LangGraph：同一团队的进阶作品，把应用建成图和状态机——节点是步骤、边是流转条件，支持循环、分支、中断恢复，解决线性流水线表达不了"根据结果决定下一步"的问题，适合做可靠的多步 Agent。deepagents：更上层的深度研究型 Agent 框架，内置规划、子任务分解、长任务执行循环，面向"给个目标自主完成调研"的场景。三者是从组件到编排到自主的递进关系。
问②你用框架实际做过什么？（诚实口径）： 如实说：自学加原型级实践。用 LangChain 完整跑通过"文档加载 → 切分 → embedding → 向量库 → 检索问答"的最小链路，也做过简单的工具调用 demo——这些帮我从代码层面理解了 RAG 每一步在干什么，不是黑盒。但公司生产落地走的是百炼加 Cherry Studio 加 Coze 的低代码路线，框架没有上生产——这是选型结论，不是能力短板。原型实践的真实价值在反哺：正因为搭过代码版，我用 Cherry Studio 建知识库时，知道界面上每个参数——切分大小、top-K——底层在调什么，出了问题知道往哪查。
问③为什么落地不用框架自己开发？： 选型逻辑三条：一看用户——使用者是售前和非技术同事，要的是开箱即用，自研应用要装环境要培训，推广成本高一个量级；二看维护——低代码平台的升级由厂商负责，自研应用的所有迭代压在自己团队，当时没有这个人力画像；三看收益——需求用现成工具百分之百满足，自研没有增量价值。所以结论是低代码先行、框架储备：等出现个性化需求（比如要把 AI 嵌进自己的运维平台）再上框架，那时候我已经有原型基础。先看用户和成本、再看技术——这跟运维选型的思路完全一致。
- 真实数字锚点：原型=检索问答链路+工具调用 demo；"原型理解反哺工具落地"是这条的最佳讲法。
P3-4 「每逢重要新模型上线即组织测评，累计输出多份选型评估报告与成本分析并全员分享；统一管理 AI 平台账号、API 密钥与权限，将 API 使用成本控制在每月 5000 元以内」
- 涉及知识点 → 第11章（token 计费/成本三板斧/密钥治理）。
问①测评怎么做、评什么维度？： 原则是"用自己的业务题测，不看发布会"。四步：建评测集——从公司方案文档和售前真实提问里整理 20 到 50 道标准问答，覆盖高频场景，专门留一部分"文档里没有"的陷阱题考它会不会承认不知道；同条件实测——同题、同提示词、同温度参数，跑新旧模型各一轮；人工评分——答对、答错、编造三类打标，同时按 token 用量算单次问答成本；出报告决策——综合准确率、幻觉率、成本三项给结论。有一次的结论很有代表性：新旗舰模型质量确实提升，但单次成本接近翻倍，最终只给核心问答场景升级，日常任务维持原模型——没有数据就做不出这种精细决策。
问②成本怎么压到 5000 以内的？： 先讲计费结构：API 按输入加输出的 token 分开计价，知识库还要加 embedding 向量化和检索的费用——先懂账单才能管账单。然后三板斧：模型分级——简单任务用便宜模型，旗舰模型只留给复杂任务，这一项贡献最大；提示词瘦身——系统提示和召回片段控制长度，上下文不是免费的；分密钥监控——按应用分 Key，每个应用的调用量和费用独立可查，配预算告警。再加每月复盘账单、动态调优。这套打法本质就是运维的资源治理思路：计量、分级、监控、复盘——换了个对象而已。
问③密钥怎么管的？： 三条纪律，完全是运维账号管理的平移：第一，密钥不外发——统一由我在平台侧配置，应用引用配置，绝不硬编码明文，跟数据库密码不进代码是同一条规矩；第二，按应用分密钥——一个应用一个 Key，账目隔离、权限隔离，泄露了能一眼定位到应用；第三，定期轮换加离职即回收——人员变动当天处理密钥权限。我把 API Key 当一类密钥资产管理，纳入和服务器账号同级的安全纪律——这也是"运维人做 AI 治理"的优势所在：这些纪律本来就是我的肌肉记忆。
- 真实数字锚点：月 5000 元以内（简历唯一量化结果数字）、多份评估报告、"选型—使用—成本—合规"闭环管理机制。
第六部分 三个项目 1 分钟 / 3 分钟逐字稿
项目一 1 分钟版
我在银行驻场近两年，做数字人民币智能合约引擎平台的国产化实施。硬件是 4 台华为 TaiShan 鲲鹏 ARM 服务器，我用 FusionCompute 8.3.0 搭虚拟化底座、DME 22.0 统一纳管，发放了 15 台统信 UOS 和麒麟 V10 虚拟机；上面部署 Kubernetes 集群、华为 BCS 区块链系统、Vastbase 一主一备数据库，最后是自研数币合约平台。我负责虚拟化、K8s（含单 master 升三 master 高可用 + Nginx/Keepalived VIP 漂移）、数据库和整体联调验收。平台通过银行客户验收支撑数币试点运行，我写的部署指南成了公司同类项目的标准文档。
项目一 3 分钟版
（在 1 分钟版基础上展开三处）①架构从下往上细讲：TaiShan 2280 双平面组网（管理/业务分平面），CNA×3+VRM×1、DME 三节点；虚拟机里 K8s v1.17.3 + Docker 18.09——版本是华为 BCS 边缘自治版 1.2.6 的配套约束，生产严格按配套表；Vastbase G100 2.2 一主一备，max_connections 调到 10000 并开线程池。②高可用改造六步：负载均衡监听 16443 避开 6443 → 导出 kubeadm-config → 补 certSANs（新 VIP + 三台 master）→ 移走旧证书重签 apiserver 证书 → 配置回写 → scp 证书后 02/03 带 --control-plane 加入；Keepalived priority 100/90、检测脚本盯 16443 端口。中间踩过证书 SAN 的坑——用 VIP 连集群报 x509，openssl x509 -text 看到 SAN 列表没有新 VIP，教训是"改集群入口必须先想证书"。③ARM 差异与内网镜像：aarch64 专用源和静态包、镜像必须 arm64、我写了循环 docker load 脚本给数据面节点离线导镜像。结尾：角色口径——选型是华为配套体系定的，我负责一次装通装稳装到能交付，上线后一线运维是我、疑难转华为原厂。
项目二 1 分钟版
2025 年公司拓展外包业务，新项目上线在即，传统虚拟机资源交付慢、环境不一致。我完成资源评估和建设方案编制，在移动云落地了一套生产级 Kubernetes 集群：7 台 ECS 跨三个可用区——3 master 三副本控制平面、CLB 四层负载做统一入口和健康检查摘除、3 台 worker 业务池、1 台独立监控节点；K8s v1.28.2 + containerd + Flannel VXLAN。配套 Prometheus + Grafana 监控三件套和 Kuboard 可视化运维平台，日常 80% 运维操作在页面完成。控制平面按 99.99% 可用性目标设计，实测停 master 的 kubelet，CLB 秒级摘除、kubectl 无感；部署踩的坑沉淀成 9 项生产避坑清单，整套方案成为公司外包项目的标准基础设施底座。
项目二 3 分钟版
（在 1 分钟版基础上展开四处）①为什么这么设计：etcd Raft 多数派所以 3 副本（4 台不划算）；云上选托管 CLB 而不是自建 Nginx+Keepalived——无单点免运维，而且银行项目我做过自建方案，两个都有实操；跨可用区做机房级隔离。②标准化初始化（IaC）：全节点统一关 swap、内核模块与 sysctl 调优、文件句柄、chrony 内网 NTP、containerd 三件套（SystemdCgroup 对齐 kubelet 驱动、pause 镜像国内源、crictl 显式绑定 socket）——期望状态统一定义、所有节点收敛一致，新环境可复制。③镜像双轨体系：公网拉取→内网私有仓库托管→集群 ImagePullSecret 认证拉取，Flannel 镜像全局替换成内网地址——内网装集群最痛的镜像问题系统性解决。④避坑与验证：挑 1-2 个坑展开（NotReady 90% 是镜像拉取；ClusterRoleBinding roleRef 不可变要删了重建）；监控为什么混合部署（独立节点不占集群资源、kube-state-metrics 必须在集群内、node-exporter apt 二进制版兼容）；Kuboard 固定 master-01 + hostPath 持久化 + RBAC 审计。结尾口径：架构是通用最佳实践，方案编制、部署、验证是我做的，99.99% 是设计目标，保障机制我能讲清。
项目三 1 分钟版
2025 年起我主导公司 AI 工具的评估和落地：基于阿里云百炼 API 接入主流大模型，用 Cherry Studio 搭了企业知识库和 RAG 问答应用，导入公司全部解决方案和技术文档，新员工学方案、售前答疑都靠它；再用 Coze 搭自动化工作流处理方案要点提取这类重复劳动。治理上我统一管理账号、API 密钥和成本，用模型分级和用量监控把月成本控制在 5000 元以内；每逢重要新模型上线就组织测评、输出选型评估报告全员分享，还做了全员培训和提示词模板库。现在这套知识库是售前研发的日常工具，形成了"选型—使用—成本—合规"的闭环机制。
项目三 3 分钟版
（在 1 分钟版基础上展开四处）①RAG 原理（被追问概率最高）：文档切分→embedding 向量化→向量库语义检索→重排→带出处的生成，让模型"开卷考试"；为什么适合我们：方案文档更新频繁、要引用溯源、要控权限、不用训模型。②知识库怎么建好的：数据先脱敏分级，切分几百 token 带重叠，评测集 20-50 题验证调优；答不准按检索段/生成段/数据段三段定位。③成本与治理：token 计费逻辑（输入输出分开、embedding 另算）、三板斧（模型分级/提示词瘦身/分密钥监控）、密钥当资产管理（不外发明文、按应用分、离职回收）。④和运维的关系（主动讲）：运维 SOP、告警手册、部署指南都进了知识库，这就是运维知识数字化；往 AIOps 走——告警摘要、故障初判、巡检报告生成，再到 Agent 调工具执行预案，我同时有运维功底和 AI 工具链实操。诚实边界：LangChain/LangGraph/deepagents 是自学原型级，落地走低代码路线是选型结论不是能力短板。
第七部分 项目间衔接问答（过渡题，答好显逻辑）
Q1：为什么项目一 K8s 用 1.17，项目二用 1.28？
两个版本背后是两种决策模式。项目一是 2023 年启动的华为 BCS 边缘自治版 1.2.6 的配套约束——BCS 对纳管的 K8s 版本有严格的兼容矩阵，生产环境必须按配套表来，不能自己想升级就升级，所以 K8s 锁 v1.17.3、Docker 锁 18.09。项目二是 2025 年的新集群，没有历史配套约束，按当时的社区稳定版自主选型 v1.28.2。这两个版本之间正好横跨了 1.24 移除 dockershim 的大变更——所以项目一还在用 Docker 做运行时、项目二直接上 containerd，容器运行时的两代形态我都在生产用过。这段经历给我的习惯是：生产选型第一步查配套关系，第二步才谈新不新——这个习惯本身比"用过两个版本"更值钱，因为它是可迁移的方法。
Q2：为什么从实施转运维？（也被问"你到底是实施还是运维"）
两层原因，一层被动一层主动。被动层是公司业务结构变了：2025 年起公司从银行产品交付转向多行业软件外包，驻场需求减少，同时公司自建云平台的需求出现，我转回来负责云平台建设顺理成章。主动层是能力延续：银行项目后期我本来就承担着上线后的运维支持——巡检、告警、故障处理、和原厂协同，K8s、监控、数据库这些能力已经攒在手上，转到公司云平台等于把在客户生产环境练出来的能力用到自己公司的生产环境，还是升级版——从"使用环境"变成"从零建设环境"。所以我的画像是"实施加运维"复合：会从零建设（交付视角），也会长期保障运行（运维视角），这个复合性在项目二里体现为方案编制、部署、验证、规范全链路都是我做——我知道怎么建，也知道建成后怎么管。
Q3：三个项目连起来，你的能力主线是什么？
一条线三个台阶。项目一银行国产化实施——会装会修：在金融生产环境把虚拟化、K8s、数据库全栈一次装通装稳，练的是交付能力和踩坑能力，两年的驻场让我对"生产环境"四个字有了敬畏。项目二移动云云原生建设——会建会管：从方案编制到生产落地，再到监控体系、可视化平台、运维规范，完成了从执行者到建设者的升级，产出沉淀成了公司的标准底座。项目三 AI 工具落地——会用新工具提效：把运维攒下的知识管理、成本治理、账号治理经验迁移到 AI 工具链上，这是运维能力的外溢。主线就是简历自我评价那句话：从国产化现场交付，到云原生生产集群建设，再到 AI 工具落地，完整经历交付、运维、自动化改造全链路。下一步往 AIOps 和运维开发方向走——这也正好回答"你三五年想成为什么样的人"。
第八部分 行为面与开放题（STAR 答法）
行为题的通用公式：情境（S）→ 任务/难点（T）→ 行动（A，重点占 60%）→ 结果（R，带数字或对比）。以下每题都给出从我真实素材里提炼的答法，不编造。答题纪律：行动必须是"我"做的决策与动作，不说"我们"；结果尽量带对比或数字。
Q1 项目里最大的挫折/失败是什么？
讲 Vastbase license 到期替换那次，STAR 完整讲。情境：平台上线后数据库的三个月免费 license 到期，要替换成正式 license，替换操作需要重启数据库的 HAS 高可用服务。任务：完成替换且不能影响银行业务连续性。挫折点：我第一次操作时按惯性思维把两个节点同时重启，集群短暂出现了双主风险预警——虽然没有造成数据问题、及时稳住了，但那一刻的真切后怕我到现在都记得，金融生产环境里这就是可能出大事的操作。行动：先把集群状态稳定住，然后复盘问题出在操作序列——把两节点同时重启改造成"先重启一个节点、等它完全就绪并确认主备角色正确后，再重启另一个"的分批规范，写进部署指南的注意事项。结果：后续两次 license 操作零风险完成，这条分批规范成为公司标准文档的一部分。教训一句话：凡涉及集群状态的操作，先设计"分批加观察"的步骤再动手——这条后来被我推广到所有重启类变更。
Q2 和华为原厂/银行客户怎么协作的？（跨团队协作题）
我的协作模型是分层接口人。对银行客户：我是统一接口人，日常巡检报告我出、告警我第一响应，客户有问题只找我一个人，不让他们陷在"该找厂商还是找集成商"的扯皮里。对华为原厂：一线能处理的我自己处理；需要二线的疑难问题，我转案之前把现象描述、发生时间线、相关日志和告警截图、我已经做过的尝试全部整理成完整材料——原厂拿到手直接往下查，不用来回补充信息，二线的排查时间被压到最短。这套模型跑了近两年，结果是客户验收一次通过、驻场期间零投诉。我的心得一句话：接口人的价值不是传话，是让链条上每个人都拿到他需要的东西——客户要的是"有人管到底"，原厂要的是"信息完整"，我把两端都喂饱，自己就是那个不可替代的节点。
Q3 和开发同事有过冲突/分歧吗？怎么解决的？
有分歧但不到冲突的例子，讲移动云配套那次。情境：业务系统上云配套时，开发团队希望数据库也放进 K8s 集群统一管理，他们的诉求是部署运维界面统一、省事；我的判断是有状态服务不该进集群。任务：在不伤协作关系的前提下把技术决策做对。行动：我没有用"我是运维听我的"压人，而是把反对理由结构化地摆出来三条——滚动更新和数据库数据一致性的矛盾、伸缩粒度不匹配（应用扩容是秒级加 Pod、数据库扩容是换规格迁数据）、故障域耦合（一次误操作同时伤害应用和数据库两层）；然后回应开发的真实诉求——你们要的是省事，那我把省事用别的方式给到：连接信息标准化交付、配套监控做到和应用同等的可视水平。结果：按云托管的方案落地，业务至今稳定，开发用下来也认可。心得：分歧靠方案和取舍逻辑解决，靠数据不靠立场；而且要听懂对方诉求背后的问题，给替代方案而不是单纯说"不行"。
Q4 如果重来一次，这个项目你会怎么改进？（复盘能力题）
项目二我有三点改进，讲完三点其实指向同一个认知。第一，初始化脚本工具化：当时我做的是标准化文档加手工执行，已经做到了七台节点完全一致，但重来我会直接写成 Ansible playbook——一次编写、多次重放、进 Git 版本管理，从"人工按文档执行"升级到"代码化收敛"，这也是我后来补学 Ansible 的动因。第二，监控先行一步：实际是集群建完才上监控，部署过程中的那些坑——镜像拉取失败、节点 NotReady——都是靠报错发现的；如果监控和集群同步建设，很多问题在指标上就能提前看到异常苗头。第三，告警渠道更早接通：当时告警主要靠看大盘，应该在业务交付前就把 Alertmanager 的通知渠道配齐，让告警找人而不是人找告警。三点的共同指向：运维体系要和建设过程同步，而不是建成再补——这是我真实复盘出来的认知升级，不是面试话术。
Q5 项目二和项目三时间重叠，你怎么同时做两个？
如实拆解，两条线节奏不同。项目二是主责线：密集期在建设阶段大约三个月——方案编制、部署实施、验证，那段时间投入最重；建成后转入运维和迭代，日常占用趋于平稳。项目三是持续投入型：测评是事件触发的——重要新模型上线才组织，平时不占时间；知识库维护是轻量日常——文档入库、参数微调，每周几个小时量级；培训是周期性分享。所以两线的峰值错开了。更本质的一条：项目二把运维标准化、可视化之后，恰恰省出了我做项目三的时间——可视化平台覆盖了 80% 的日常操作，我从重复操作里解放出来才能去做 AI 这种增量的事。两个项目不是争时间，是互相成就——这个回答顺便展示了多任务管理和优先级意识。
Q6 压力最大的一段时间是什么时候？
银行平台上线的窗口期。情境：客户验收日期定死不可顺延，前期 ARM 环境的连环坑——海外镜像拉不到、证书 SAN 问题、各种国产化适配——在离上线很近的时候密集出现。压力的来源很具体：死线是死的，金融生产环境是不敢错的。我的应对两招：第一招任务清单化——把剩余工作拆成"每天必须闭环"的任务清单，每天睡前清单清零，进度可视化之后焦虑会小很多，因为"能不能赶上"从恐惧变成了算术；第二招高风险操作预演——每个要在生产上做的关键操作，先在测试虚拟机上完整走一遍，把意外消灭在上生产之前，晚上盯完验证项再睡。结果按期通过验收。这段经历给我的习惯是：压力下靠清单和预演，不靠肾上腺素——后来移动云项目，我把这个习惯升级成了"9 项避坑清单"，本质就是提前把坑变成清单上的勾选项。
Q7 你最有成就感的一件事？
看面试官类型选版本。对技术面试官讲：单 master 升多 master 的高可用改造。那件事的完整弧线是：从证书 SAN 的坑里爬出来（用 openssl 查证书定位到 SAN 缺新 VIP）→ 补 certSANs 重签证书走通流程 → Keepalived VIP 漂移实测成功的那一刻——整个集群的控制平面从单点变成了三副本，可用性能力发生质变；而且这套流程后来写成标准文档被复用，我踩的坑变成了别人的护栏。对业务型面试官讲：移动云项目成为公司外包项目的标准底座。我编制的方案和避坑清单让公司后来接新项目时"照着重放就行"，资源交付从天级缩短到分钟级——我的个人产出变成了组织能力，这个杠杆效应比任何单点技术都让我有成就感。
Q8 三个项目分别投入多久？团队怎么分工？
时间口径如实报：项目一约 22 个月，驻场全程——前期实施密集，后期转运维值守；项目二、项目三并行约 16 个月，其中项目二是主线——方案编制加实施大约三个月密集期，之后转入运维和迭代；项目三是持续投入型——测评按事件触发、知识库维护每周几小时、培训周期性做。团队分工也如实讲：项目一是"华为原厂 + 我们公司 + 我驻场"的三方结构，我在现场是唯一的实施运维接口人——一个人对多方的协作结构；项目二方案和实施主力是我，云资源采购、应用联调与开发是配合方；项目三我主导，售前和研发同事是使用方和反馈方。要说明的是单人接口不等于单打独斗——能把协作结构讲清楚，本身就是协作能力的证明。
Q9 简历里哪一条你最怕被问？哪条"最虚"？（自省题，答好显真诚）
如实但不自毁地答。最怕深挖的是 Jenkins：简历写"熟悉 CI/CD"，我的实际构成是——课程项目从零搭过 GitLab 加 Jenkins 加 K8s 部署的完整流水线，生产上配套过镜像分发和发布回滚这两个环节；两端都是真的，中间那段"流水线的日常运维"没有长期做过。所以我的策略是主动把口径说清楚："流水线是课程实操，配套环节是生产经历"，然后把话题引到我天天在用的东西上——Ansible 的标准化思想我在移动云节点初始化里实践过，K8s 滚动发布和回滚我在生产上亲手做。"最实"的反而是 AI 那条——密钥管理、成本数据、评测报告全是真实可查的。这题考察的不是有没有短板——人人都有——是有没有自知之明和口径管理能力：知道自己哪虚、主动管理预期、还有能力把话题带回强项，这本身就是职场上很值钱的能力。
章末自测清单
- 简历工作经历实施阶段三条分别是什么？ → 实施交付（FC/DME/K8s/国产栈）、上线后运维支持（与华为协同）、标准化文档与知识转移。
- 运维阶段五条？ → 移动云集群建设、云服务配置与发布支持、证书/etcd/演练规范、AI 落地、桌面运维与 IT 知识库。
- 项目一 5 条职责的章号指向？ → 08（FC/DME）、06+04（K8s 高可用）、03（Vastbase）、07+06（BCS 联调监控）。
- 项目二 7 条职责的章号指向？ → 06+09（架构）、06+01+14（初始化避坑）、05（镜像双轨）、07（监控）、07（Kuboard）、09+03（云服务）、06+14（演练备份证书）。
- 项目三 4 条职责的章号指向？ → 全部 11 章（RAG/工作流培训/框架/测评成本）。
- 99.99% 怎么说？ → 设计目标，靠三副本+CLB 秒级摘除等机制保障，不说实测 SLA。
- 桌面运维被问低端的答法？ → 一专多能+沉淀知识库 SOP 把重复劳动自动化，体现方法论。
- 三个项目 1 分钟稿能不能不看稿说完？ → 每晚睡前各过一遍，连续三天即成。
- 项目衔接三问答的核心句？ → 1.17→1.28 是配套约束 vs 自主选型；实施转运维是业务结构+能力延续；主线是"会装会修→会建会管→会用 AI 提效"。
- 被问"哪个项目最有成就感"？ → 项目二（方案到落地全链路是我，且沉淀为公司标准底座）；备选项目三（差异化，别人没有）。
- 行为题的公式？ → 情境→任务→行动（占 60%）→结果，行动里必须有你个人的决策和动作。
- "和开发冲突"那题的答法核心？ → 不叫冲突叫分歧，摆三条理由+给补偿方案，靠取舍逻辑不靠立场。
- "重来会怎么改进"三点的共同指向？ → 运维体系要和建设过程同步（IaC 化、监控先行、告警早接）。
- "哪条最怕被问"的答法核心？ → 如实亮 Jenkins 口径（课程实操+生产配套），主动管理预期并转向强项。
- 行为题里最不该犯的错？ → 把"我们"说成主语——行动必须是"我"做了什么决策和动作。
- "两个项目时间重叠"怎么答？ → 主责线+持续投入线的节奏差异，且项目二的可视化提效正好省出做项目三的时间。
- 行为题八问里最该先背的是哪三个？ → 挫折（license 双主风险）、协作（三方接口人）、重来改进（IaC/监控先行）——覆盖"失败/协作/复盘"三个考察面。
- 24 个问答单元复习一遍要多久？ → 按"每问 1 分钟开口讲"节奏约 60–80 分钟，面试周每两天过一遍正合适。
- 本章与第13章怎么配合？ → 技术面主战场在本章，人事面在第13章；两章的"项目三分钟稿"和"自我介绍"必须数字一致、口径一致。
12.9 本章使用红线（面试前再读一遍）
- 每问都要"先结论后展开"：任何一问先给一句话结论，再讲机制或过程，最后落到数字或结果——本章所有段落都按这个结构写，背的时候注意节奏。
- 行动主语是"我"：24 个单元里所有操作描述都以"我"为主语，不自觉说成"我们"会直接稀释你的贡献。
- 数字一旦出口不能改口：4 台、15+、7 台、v1.17.3/v1.28.2、月 5000 内、99.99% 设计目标——同一轮面试里前后必须一致。
- 不越界：项目一选型归华为、流水线属课程实操、AI 框架是原型级——三个边界主动说清，诚实永远是加分项。
- 本章是索引不是终点：每问的段落是"可直接说的 60–90 秒版"，面试官再深挖，按"涉及知识点"指向的章节拿更细的弹药。