S 招 2026

CV-20260713

  • 基本信息
    求职意向：Java 后端开发、AI 应用工程化
    工作年限：2 年
  • 教育经历
    华南理工大学 | 网络工程 2020.09 - 2024.07
    在校经历：曾获学校与企业奖学金, “三好学生”等荣誉，发表 EI 会议论文一篇。曾加入学院青马工程班学习，担任华工青年志愿者指导中心宣传部副部长，有丰富的志愿活动和学生组织经历。（项目统筹、跨团队协同能力）
  • 工作经历
    Midea｜ 后端开发工程师-Java 2024.7~至今
    1. MOPS 自动化运维平台
      MOPS 是集团核心自动化运维平台，主要承载主机、网络、存储等资源的自动化运维工作，旨在通过流程化、集中化、自动化的方式，提高运维效率，降低人工运维风险，提升运维效率，并优化用户体验。
      • F5自动化建设：作为MOPS平台网络模块负责人，基于F5平台独立落地DNS域名、负载均衡两大核心能力自动化建设，完成全流程产品化适配。自主研发域名申请、变更、回收、一键回退全链路自动化流程，替换老旧第三方采集数据源，实现资产元数据主动采集，半年稳定承载千余条业务工单；搭建负载均衡全生命周期自动化流程，设计蓝绿发布、动态参数校验、并发数据一致性控制、变更一键回退机制，半年承接400+生产工单，有效规避人工操作风险，大幅降低线上变更事故率，同时跟进团队全栈转型，独立承担模块前后端功能开发交付工作。
      • 防火墙自动化建设：分布式锁，线程池，，
      • 网络模块统筹：统筹 F5、DNS、防火墙全网络模块的方案调研、需求评审与风险把控；包括防火墙策略下发策略优化，，协助团队成员完成功能落地。
      • 产品私有化交付：负责网络、备份管理两大核心模块的私有化交付工作，精准对接外部客户，承接定制化需求沟通、日常问题答疑，输出使用指引与运维文档；独立完成对应模块容器打包、多环境部署上线，沉淀了从需求对接、功能落地到客户验收的完整私有化产品交付闭环能力。
    2. CMDB 基础配置数据库
      CMDB 是IT运维事实库。集团拥有上万台服务器，覆盖复杂制造业运维场景，上层IT系统全部依赖 CMDB 资产数据，保障数据准确与服务稳定是核心目标。
      • 数据管控：负责各业务方数据接入工作，维护数据表结构、上下游数据读写链路，支撑查询视图、数据订阅、资产自动采集等核心能力落地。常态化追踪业务数据状态，清洗修正脏数据，规范数据流转，保障集团运维数据源准确、可信、一致。
      • 全文检索：通过monstache同步mongodb数据到es，支持全字段搜索，实现全局IP查询
      • 自动采集：通过Kafka做任务的下发、数据入库的异步、解耦，ansible实现数据采集
      • 数据订阅：通过mongoshake获取数据变更到Kafka，消费，实现异步回调
      • 系统运维：负责平台日常线上故障排查处理，可快速定位解决功能卡顿、中间件故障及 Java 服务 GC、OOM 等异常。
    3. CMDB-Agent 智能问数
      基于CMDB数据的自然语言问数助手，基于阿里开源 Data-Agent 框架完成业务定制二次开发，落地运维 AI 问答能力，实现自然语言自动解析、语义识别、生成可执行 SQL，支撑集团人员快速查询资产配置数据。
      • 基于Graph图流程拆解问答链路
      • 完成内部运维知识库搭建、知识分层梳理、检索精度调优，优化大模型上下文匹配逻辑，显著提升问答准确率与业务适配度。
      • 优化前端流式输出交互体验，实现问答结果实时分段推送，解决大模型长响应卡顿问题，大幅提升平台整体使用体验。
      • 预研无框架轻量化通用 Agent 架构，基于可配置 Skill 体系 + 精细化提示词工程实现低代码智能编排，摆脱厚重框架依赖，打造高复用、可扩展的运维 AI 能力，形成个人差异化技术优势。
  • 个人项目
    基于XXL-Job的高并发定时秒杀商城系统 | 针对Java高并发技术短板，基于XXL-Job开源调度框架二次开发，结合电商定时秒杀业务搭建高并发调度系统，融入AI工程化开发流程，重点实现定时促销并发控制、流量防护、性能监控调优，补齐互联网后端核心实战能力。（开源源码研读+AI工程化实战）
    • 开源框架二次改造：研读XXL-Job核心源码（https://github.com/xuxueli/xxl-job ），掌握集群调度、线程模型、容错重试机制，针对电商业务场景定制任务优先级、分片执行策略，优化单机调度瓶颈，提升集群并发处理能力。
    • 定时秒杀高并发场景落地：实现用户预约定时下单、秒杀节点自动开售、超时订单取消功能，依托分布式定时任务精准管控促销窗口期，模拟电商大促瞬时高并发业务场景。
    • 并发安全与流量防护：通过Redis Lua脚本实现原子库存扣减，解决超卖问题；基于分布式锁、线程池隔离、任务限流规避流量冲击；借助Kafka异步削峰解耦，有效处理高并发任务积压，保障服务稳定运行。
    • AI工程化高效开发：落地标准化AI开发流程，通过需求拆解、AI辅助编码、人工审码、单元测试、压力验收全链路开发，提升复杂高并发项目的研发规范性与落地效率。
    • Arthas监控与性能调优：接入阿里开源Arthas组件搭建可观测能力，实时监控JVM指标、线程池状态、接口耗时及QPS；精准定位锁等待、频繁GC、任务超时等问题，针对性调优，提升系统并发承载能力与稳定性。
  • 专业技能
    • 后端开发：熟练 Java、SpringBoot、SpringCloud、MyBatis，掌握常用设计模式与企业级工程化规范
    • 线上故障治理：精通 JVM 调优、并发编程、线程池、锁机制，具备 OOM、FullGC、线程异常、接口卡顿等线上问题完整排障经验
    • 数据库与中间件：熟练 MySQL、MongoDB、Elasticsearch、Kafka；掌握索引优化、SQL 调优、消息队列治理、线上数据问题排查能力
    • 时序数据库服务化开发：熟悉 InfluxDB 时序数据库，独立参与中间件云原生服务化能力建设，落地实例备份恢复、节点重启、规格变配、跨环境数据迁移等平台化功能，具备时序中间件容器化改造与服务封装实战经验
    • 云原生工程化：熟练 Docker 容器打包部署、K8s 基础资源运维、Ansible 自动化脚本、多环境产品化交付；具备容器服务编排、资源调度、跨环境迁移落地实战经验，可独立完成中间件平台化集成与稳定性压测验证
    • AI 工程化能力：精通 Prompt 工程、大模型上下文编排、Agent 应用开发、AI 辅助全流程后端项目开发与质量验收
    • 综合能力：具备模块全栈开发、项目方案设计、需求评审、外包管控、SOP 沉淀、客户私有化交付闭环能力

talks

  • 自我介绍。
    面试官您好，我是蔡枫，本科毕业于华南理工大学计算机学院，在美的集团从事Java后端开发的工作。
    我主要接触两方面的工作，目前正在做的是自动化运维平台的开发，面向整个集团的用户提供主机、网络管理相关的服务，我们的工作就是把以往通过管理员手动下发的工作实现流程化、自动化，保证可追溯和甚至可逆。另外，还做了半年的数据库服务化开发，建设InfluxDB的“数据库即服务”（DBaaS）能力，基于开源Influxdb Cluster支持了备份恢复、变配、迁移等功能，但是后期随着对开源数据库的可靠性存在顾虑中断了。

  • 为什么跳槽？
    “过去两年我主要负责内部两套核心底座平台 CMDB、MOPS 的开发与稳定性保障，实际上承担了系统负责人的角色，负责业务迭代和故障运维。
    但当前工作更多偏向存量系统的维稳与运维支撑，虽然把稳定性做得很好，但在公司的评价体系下，偏维护类的工作可能很难形成可以用于晋升的业务产出。长期下来我感觉到个人成长触到了天花板。
    我已经具备需求落地、线上问题治理的能力，希望能够找一个新环境，参与具备业务深度、能够产生技术沉淀的场景，或者有新兴技术、如 AI 应用工程化这类有挑战的场景，产出更有重量的技术成果，进一步把自己的技术深度往上推。
    我也十分年轻，有信心尝试不同的领域。要持续学习，保持好奇。”

    1. 能力：点明自己实际做系统负责人，做过稳定性、平台建设、故障治理（摆实绩）
    2. 潜力：不满足只做维稳，渴望更有挑战的技术场景
    3. 隐性野心：想要产出有分量的技术成果，追求更深的技术成长（不说我要升职加薪，用 “产出技术成果” 表达进取心）

  • “天花板具体是什么？突破什么？”
    “客观看，我在现有团队已经可以独立扛下整套平台的全生命周期，从功能开发、迭代的负责，到线上故障排查。但目前业务形态以存量运维底座为主，大部分精力花在把业务方（系统运维）的需求转换为功能，并且要保障系统不出问题。
    这类工作的价值是稳，但很难产生新的业务成果。（技术上来说也没有什么挑战，比如并发就很小）公司晋升评价更偏向新业务迭代类产出，所以在这套体系下我很难拿到向上的机会。
    我不希望一直停留在‘保障旧系统稳定’这个层面。我希望能够接触真正有业务深度、或者大模型工程落地的场景，去做架构层面的思考与落地。我希望把我现有的后端、云原生、运维开发的综合能力，放到更大规模的业务场景里，沉淀真正有影响力的技术产出，这也是我选择出来看机会的主要原因。”

  • 那你在原来的岗位，就不能做这些深度改造吗？
    “内部有做局部优化，比如数据库校验链路、Oplog 数据订阅、故障治理。但整体业务优先级偏向维稳，大规模架构重构、新形态业务落地的机会不多，资源和业务导向决定很难做大规模的技术产出。”
    “所在的团队和系统，目前还在自动化的构建中，在智能化方面的投入较少”

  • 你觉得你最大的优势是什么？（承接跳槽理由，顺势输出能力 + 潜力）
    “一方面，我有完整平台从开发到线上运维的实战经验，能兼顾开发和运维视角，处理复杂线上问题；另一方面我希望跳出纯维护的定位，愿意去啃高并发、AI 工程化这类比较新的难题，希望在新业务场景把能力进一步放大。”

  • 看源码？为什么禁用fastjson？

  • AI的使用，AI工作流（极海题库：https://bitfree.cn/question）
    AI Coding
    我的工作流就是将人类的战略思维（Strategy）与AI的战术执行（Tactics）分离。我负责定义‘做什么（What）’和‘为什么（Why）’，而AI负责‘怎么做（How）’，并通过 Hook 和 Review 机制确保结果的可控与高质量。

  • 如何保证AI Coding代码质量？

  • AI开发中对SDD的理解
    “总而言之，SDD 不仅仅是一个开发流程，它更是一种工程思维的转变。它标志着我们从‘凭感觉编程’（Vibe Coding）进入了‘按规范交付’的工程化时代。对于后端开发者而言，掌握 SDD 意味着我们不再是 AI 生成代码的被动接收者，而是通过定义清晰的‘契约’，主动地、系统性地驾驭 AI，确保交付的软件既正确又符合业务意图。这正是在 AI 时代，后端工程师核心价值的体现。”

  • AI coding如何节省Token？
    核心：少输入、少输出、少交互、精上下文
    面试回答：原则 + 6个具体方法 + 总结价值
    亮点：体现你会用 AI、懂成本、有工程规范

  • AI CODING L1,L2,L3？？

  • Agent如何节省Token？

  • 同样的模型，同样的提词，输出结果一定一样吗？
    结论先说：默认情况下一定不一样；只有严格锁死全部条件，才能做到每次输出完全相同

  • Skills？
    “简单来说，Agent Skills 就是AI的标准化岗位说明书。它通过 SKILL.md 文件将领域知识、操作步骤和脚本封装起来。最巧妙的是它采用了渐进式披露机制，只在需要时才加载详细内容，既保证了效果又节省了 Token。如果说 Tool 是 AI 的手和脚，那 Skill 就是 AI 的‘肌肉记忆’和‘工作经验’。在2026年，构建高质量的 Skills 库是企业级 AI 应用落地的关键。”
    cf：skills提供业务知识，让llm从普通员工→该业务的资深员工，区别于预设好场景提前设计好Prompt模板供模型使用，Skills让LLM能按需自行构造Prompt?!

  • RAG？落地？

    • 全称是 检索增强生成（Retrieval-Augmented Generation）。大模型只有预训练的知识，不具备企业内部知识，RAG 通过知识库建设，知识检索，提示词构建，在提供给LLM的Prompt里引入内部知识上下文，从而让模型生成更准确、更实时的回答。
      RAG 本质上就是为了解决 LLM “知识滞后” 和 “一本正经胡说八道” 这两个核心痛点而诞生的架构。
    • 为什么要用 RAG？（核心价值 vs 痛点，建议对比微调（Fine-tuning）来谈）
      • 时效性 →知识更新快。只需更新外部知识库即可，无需重新训练昂贵的模型。
      • 准确性 →减少幻觉。答案基于检索到的事实，有据可依，可追溯来源。
      • 成本 →性价比高。比全量微调或预训练便宜得多，适合垂直领域落地。
      • 隐私 →数据不出域。私有数据只在检索环节使用，不需要注入到模型参数中。
    • 进阶补充（加分项，可以补充一点你对 RAG 当前挑战 的理解）
      “虽然 RAG 很好，但在实际落地中也面临挑战。比如检索精度问题（如果检索不到相关内容，模型就答不对），以及上下文窗口限制（检索内容太多塞不进 Prompt）。所以现在的优化方向通常包括使用混合检索（关键词+向量）、重排序（Rerank）模型，以及更智能的切片策略。”

  • Harness？

    1. 广义Harness（行业规范/设计思想） ➡️ Agent标准化运行底座标准，定义必备能力：会话生命周期状态机、长短双层记忆、上下文自动裁剪、重试/熔断、统一Prompt管理、可插拔Skill调度、安全沙箱；
    2. Harness框架（规范落地实现）➡️ 遵循上述标准的现成代码底座，分技术栈：
      Java：AgentScope、Agents-Flex（后端业务、求职首选）
      Python：LangGraph
      TS：DeepSeek Harness（快速本地原型验证）
    3. 与旧框架层级差异：LangChain/LangChain4j仅LLM/RAG工具封装，无标准化生命周期管控，需手动拼接流程 ➡️ 新增完整运行管控层，开箱即用生命周期、记忆、容错。

  • AI 技能体系

    • 底层永久核心（不会过时，必学）
      1. LLM基础：Token、上下文窗口、流式输出、多模型调用、输入输出安全；
      2. RAG全链路：切片、向量化、多路召回、重排、幻觉优化；
      3. 原生提示词工程：CoT、结构化输出、模板设计；
      4. 原生Agent逻辑：任务拆解、工具调用、反思循环。
    • Harness体系
      1. Harness底座使用与设计：生命周期、双层记忆、重试熔断、会话隔离；
      2. Skill模块化拆分、插件化开发；
      3. 多Agent协同基础；
      4. AI工程运维：链路日志、Token监控、性能优化。
    • 个人技术体系搭建思路
      1. 底层打底：吃透LLM/RAG/原生Agent底层原理，不依赖框架；
      2. 标准化落地层：主攻Java Harness框架（AgentScope），掌握规范落地思路；
      3. 业务层：模块化Skill设计，把业务抽象为可插拔工具；
      4. 底层深挖：业余手写极简Harness（记忆/状态机/重试），面试深度作答；
      5. 边界区分：能清晰区分「规范、框架、业务Skill」三者关系。
    • 最小可运行Demo：Nl2SQL智能问数（精简落地方案）
      • 选型 ➡️ 主框架：AgentScope（Java，贴合后端求职） ➕️ 配套组件：LLM 通义千问/DeepSeek API ，数据库：SQLite（零部署测试业务表），向量库：Chroma本地轻量版（RAG存储表注释），基础依赖：SpringBoot、JDBC、Lombok
      • 分层设计 ➡️ LLM层：模型推理大脑 ➕️ Harness运行时层（AgentScope内置）：会话管理、长短记忆、上下文裁剪、3次重试熔断、Prompt模板中心、Skill调度器、SQL安全沙箱 ➕️ 可插拔Skill层（4个最小业务模块）：MetaSkill：RAG检索数据表元数据，SqlGenSkill：自然语言生成SQL， SqlCheckSkill：语法校验、拦截高危DDL/DML，QuerySkill：执行查询、结果自然语言汇总 ➕️ 存储层：SQLite业务库 + Chroma向量知识库
      • Demo标准工作流（完整Harness生命周期展示）
        1. 用户输入自然语言提问 → Harness创建独立会话，加载历史对话记忆
        2. Harness调度MetaSkill：RAG检索匹配数据表结构与字段注释
        3. Harness加载SQL生成Prompt模板，调度SqlGenSkill产出SQL
        4. Harness调度SqlCheckSkill校验语法、拦截危险语句（校验失败：触发Harness重试机制，最多3次，超限自动熔断终止流程，校验通过：进入下一步）
        5. Harness调度QuerySkill执行SQL，获取数据
        6. LLM汇总查询结果，生成自然语言回答
        7. Harness更新短期会话记忆、持久化关键元数据至长期向量记忆
        8. 输出答案，完整生命周期日志打印（状态、重试次数、Token消耗）
      • 与旧Data-Agent区别
        • 不再手写大量 if‑else 来硬编码工具调用分支。业务能力被封装成标准化 Skill 注册到 Harness；调用哪个 Skill 由大模型做动态决策，Harness 负责解析指令、安全执行、管控重试熔断和上下文记忆流转。开发者只需要新增 / 修改 Skill，不用改动 Agent 主循环。
        • 举个反例：阿里开源 Data-Agent（非 Harness）
          写死：用户提问第一步固定先调用 RAG，再生成 SQL，再校验，再执行。 这种叫固定流水线，不是 Agent。
          Agent 的价值是：由大模型动态决定步骤顺序，不一定每次都完整走全部 Skill。 比如有些简单问题不需要 RAG，直接回答；有些报错需要多轮重试调用同一个 Skill。Harness 就是承接这种动态决策后的执行。
        • Nl2SQL Demo（using Harness）举现实例子
          1. LLM 思考：需要 MetaSkill，参数 query=2026 销售总额
          2. Harness：解析调用指令，找到注册好的 MetaSkill，执行向量检索（纯代码 Skill）
          3. MetaSkill 返回订单表结构
          4. 上下文更新，再次交给 LLM
          5. LLM 思考：调用 SqlGenSkill，入参带上表结构和用户问题
          6. Harness 调度 SqlGenSkill（内部包含 Prompt 模板 + LLM 调用 + 清洗代码）
          7. 拿到 SQL，LLM 指令调用 SqlCheckSkill
          8. Harness 执行校验，发现没问题，继续调度 QuerySkill 执行 JDBC 查询
          9. 查询结果返回，LLM 不再调用任何 Skill，直接输出最终答案。
      • 大模型驱动，Harness主控，Skills支持
        1. 大模型（驱动 / 决策）
          是大脑，负责理解用户意图、规划任务步骤、选择调用哪个 Skill、决定什么时候结束任务。
          ⚠️ 它不直接执行任何外部操作：不能查数据库、不能读向量库、不能操作文件，只输出思考和工具调用指令。
        2. Harness（主控 / 运行管控）
          是运行容器与调度中枢。接收大模型输出的工具指令，完成：Skill 查找、权限沙箱、执行调用、异常捕获、重试熔断、会话生命周期、记忆读写、上下文组装，再把 Skill 执行结果回传给大模型，驱动下一轮思考。
          “主控” 不是说 Harness 自己决定业务逻辑，而是掌控整个 Agent 的执行流程与运行边界；业务走向依旧由大模型决策。
        3. Skills（支持 / 能力支撑）
          是标准化可插拔能力单元。分为两类：
          纯代码 Skill：RAG 检索、SQL 校验、DB 查询；
          LLM 型 Skill：内部封装 Prompt 模板 + LLM 调用 + 前后处理逻辑；
          对外统一接口，由 Harness 按需调度执行，提供大模型本身不具备的外部能力。

项目

  • 项目介绍。
    1 自我相信，要反复强调：这个项目非常重要
    2 包装项目：为什么做，怎么做，亮点，结果
    3 告诉面试官一件他不知道的事情，产生好奇

  • Projects

    1. CMDB 集团基础配置底座（系统管理员）
      • 业务数据对接与数据治理：作为平台管理员，负责各业务方数据接入工作，维护数据表结构、上下游数据读写链路，支撑查询视图、数据订阅、资产自动采集等核心能力落地。常态化追踪业务数据状态，清洗修正脏数据，规范数据流转，保障集团运维数据源准确、可信、一致。
      • 平台日常运营与功能维护：负责CMDB平台日常运营与内部用户支撑，维护全文检索、数据读写、自动采集、数据订阅等核心功能稳定运行，响应各业务部门日常使用咨询与基础需求，保障平台常态化稳定提供服务。
      • 系统故障排查与性能调优：负责平台日常线上故障排查处理，可快速定位解决服务卡顿、数据读写异常、接口慢查询等业务功能问题；熟练排查Kafka消息堆积、同步延迟等中间件故障及 Java 服务 GC、OOM 等异常。
      • 私有化产品化交付：负责CMDB平台私有化交付工作，完成客户环境POC验证、项目打包、容器部署、服务启停与宕机演练，独立解决Zookeeper启动异常等部署故障，累计闭环多项交付问题，保障外部项目顺利验收上线。
    2. MOPS 自动化运维平台（网络 & 备份模块 Owner）
      • F5自动化全栈建设（DNS+负载均衡）：作为MOPS平台网络模块负责人，基于F5平台独立落地DNS域名、负载均衡两大核心能力自动化建设，完成全流程产品化适配。自主研发域名申请、变更、回收、一键回退全链路自动化流程，替换老旧第三方采集数据源，实现资产元数据主动采集，半年稳定承载千余条业务工单；搭建负载均衡全生命周期自动化流程，设计蓝绿发布、动态参数校验、并发数据一致性控制、变更一键回退机制，半年承接400+生产工单，有效规避人工操作风险，大幅降低线上变更事故率，同时跟进团队全栈转型，独立承担模块前后端功能开发交付工作。
      • 网络模块统筹：统筹F5、DNS、防火墙全网络模块的方案调研、需求评审与风险把控；包括负载均衡参数下发、防火墙策略生成算法、自动采集核心设计，协助团队成员完成功能落地；同步承担平台发版、线上值班、系统调优、慢 SQL 优化等工作。
      • NBU备份模块：实现NBU备份策略申请自动化下发；完成客户端批量自动化安装、API策略远程推送、每日备份任务执行状态全量采集。
      • 产品私有化交付：负责网络、备份管理两大核心模块的私有化交付工作，精准对接外部客户，承接定制化需求沟通、日常问题答疑，输出标准化功能使用指引与交付文档；独立完成对应模块容器打包、多环境部署上线，沉淀了从需求对接、功能落地到客户验收的完整私有化产品交付闭环能力。
      • 集团数字人接入（todo）：负责运维平台Agent与集团美的数字人、负A统一门户对接改造，将网络、备份模块的自助运维能力标准化封装，实现防火墙工单、运维资源自助申请等AI自动化能力，统一集团运维操作入口，推动传统人工运维向智能化自助运维升级。
    3. CMDB-Agent 自然语言智能问数（AI 工程化项目）
      • 基于阿里开源 Data-Agent 框架完成业务定制二次开发，落地运维 AI 问答能力，实现自然语言自动解析、语义识别、生成可执行 SQL，支撑集团人员快速查询资产配置数据。
      • 独立完成内部运维知识库搭建、知识分层梳理、检索精度调优，优化大模型上下文匹配逻辑，显著提升问答准确率与业务适配度。
      • 优化前端流式输出交互体验，实现问答结果实时分段推送，解决大模型长响应卡顿问题，大幅提升平台整体使用体验。
      • 预研无框架轻量化通用 Agent 架构，基于可配置 Skill 体系 + 精细化提示词工程实现低代码智能编排，摆脱厚重框架依赖，打造高复用、可扩展的运维 AI 能力，形成个人差异化技术优势。
    4. 基于XXL-Job的高并发定时秒杀商城系统 | 针对Java高并发技术短板，基于XXL-Job开源调度框架二次开发，结合电商定时秒杀业务搭建高并发调度系统，融入AI工程化开发流程，重点实现定时促销并发控制、流量防护、性能监控调优，补齐互联网后端核心实战能力。（开源源码研读+AI工程化实战）
      • 开源框架二次改造：研读XXL-Job核心源码（https://github.com/xuxueli/xxl-job ），掌握集群调度、线程模型、容错重试机制，针对电商业务场景定制任务优先级、分片执行策略，优化单机调度瓶颈，提升集群并发处理能力。
      • 定时秒杀高并发场景落地：实现用户预约定时下单、秒杀节点自动开售、超时订单取消功能，依托分布式定时任务精准管控促销窗口期，模拟电商大促瞬时高并发业务场景。
      • 并发安全与流量防护：通过Redis Lua脚本实现原子库存扣减，解决超卖问题；基于分布式锁、线程池隔离、任务限流规避流量冲击；借助Kafka异步削峰解耦，有效处理高并发任务积压，保障服务稳定运行。
      • AI工程化高效开发：落地标准化AI开发流程，通过需求拆解、AI辅助编码、人工审码、单元测试、压力验收全链路开发，提升复杂高并发项目的研发规范性与落地效率。
      • Arthas监控与性能调优：接入阿里开源Arthas组件搭建可观测能力，实时监控JVM指标、线程池状态、接口耗时及QPS；精准定位锁等待、频繁GC、任务超时等问题，针对性调优，提升系统并发承载能力与稳定性。

三大原则：强调项目业务价值、标准项目叙事结构、预埋知识点引导面试官提问，主动导向自身准备充分的技术栈。

  • 如何把项目讲好？细节？
    1 往岗位需求上倾向（包装）
    2 具体怎么展开？为什么做（背景，不要说“老板要做的”），核心问题（一两个难点、如何解决），惊喜（额外思考、解决了什么）
    3 面对质疑：好问题，可能当时没考虑到，而是聚焦别的问题。。未来可以。。

  • 一个挑战。
    接收 CMDB 时，团队对其代码实现了解不高，故障多。。我进行了整体梳理，负责故障处理

  • 技术亮点与难点
    分布式，高并发，，，？？

  • 处理线上问题，处理偶现问题
    先止血，后排查。。？

  • 一次排查问题。
    cpu飙升，发现是一个接口有io操作，并发大了就卡住了。。
    首先，停掉回写接口，把cpu降下来，恢复服务
    分析，不是计算型的，所以多线程没用，要考虑优化io查询，cmdb加索引。。
    其次，如何降低并发，加缓存？异步？？

  • Q&A（doubao文档 https://www.doubao.com/docx/LBf3d5HhDo1GbBxiSpucIhmDnbb）

🔗 CMDB基础配置数据库｜项目口述

CMDB 是美的集团统一 IT 资产配置底座，作为全集团自动化运维体系唯一可信数据源。集团拥有上万台服务器，覆盖复杂制造业运维场景，上层 MOPS 运维平台、备份系统、监控平台全部依赖 CMDB 资产数据；一旦数据失真、服务读写卡顿，所有变更操作、线上故障根因定位都会失去依据，所以保障数据准确与服务稳定是核心目标。
我作为平台管理员，负责业务接入、核心功能运维、线上故障兜底与私有化交付。平台基于 MongoDB 存储资产信息，围绕数据同步、资产采集、快速检索三大核心能力建设：
1、数据订阅能力：为满足下游众多系统增量同步资产数据的需求，我们基于 MongoDB Oplog 实现变更监听，资产表新增、修改、删除事件自动触发回调接口，完成增量数据推送。依托 Oplog 天然的数据变更日志机制，规避轮询查询带来的数据库压力，我也深入研究了 MongoDB 复制集、Oplog 存储与过期清理机制。
2、资产自动采集：以防火墙策略采集链路举例，整体依靠 XXL‑Job 调度下发采集任务，任务投递至 Kafka；采集执行服务消费任务，通过 API 调用、Ansible 远程执行、FTP 拉取多种方式获取远端设备配置，采集结果再次投递 Kafka；采集代理消费数据，清洗入库 MongoDB。整条链路依赖 Kafka 实现异步解耦，日常处理过大量生产消费速率不匹配导致的消息堆积问题。
3、全文检索能力：借助 mongostash 组件，将 MongoDB 资产数据实时同步至 Elasticsearch，对外提供统一检索接口，解决 MongoDB 复杂模糊查询性能差的痛点，支撑业务方快速检索各类资产。
除功能迭代支撑外，我大量精力投入平台稳定性运维与故障闭环：经常遇到查询接口响应缓慢、视图查询超时问题，多数根源为缺失合适索引，通过优化索引策略持续优化查询性能；针对服务整体读写卡顿，沉淀标准化故障排查 SOP，依次排查容器资源、外部接口耗时、数据库慢查询逐层定位瓶颈；常态化处理 Kafka 消息堆积、Java 服务频繁 FullGC、OOM 内存溢出等线上问题。
同时负责平台私有化容器化交付，独立定位并修复 ZooKeeper 集群启动异常问题：原配置固化集群 IP，容器重建后 IP 变更导致集群失联；我在集群健康状态下执行 reconf，使用域名替换固定 IP，彻底根治该缺陷，保障私有化环境长期稳定运行。
【预埋引导话术，自然穿插】整套系统混合使用 MongoDB、ES、Kafka，在实践中能明显感受到文档数据库在强事务场景存在短板，这段时间我也系统深入学习 MySQL InnoDB 索引、事务、锁相关理论，对比两类数据库适用场景差异。

CMDB基础配置数据库｜高频问答

  • Q0：CMDB 本质是一套资产数据读写服务，你在日常负责过程中，从架构稳定性角度，如何保障数据可信、接口稳定可靠？
    CMDB 作为集团运维领域的根数据源，它的核心本质并不是简单的增删改查接口，而是持续稳定输出可信资产数据。一旦写入脏数据、接口大面积超时不可用，上层整套自动化运维流程、故障根因分析都会完全失效。我在承担平台管理员职责期间，不只是做功能使用与问题救火，更多会从架构稳定性视角，围绕写入管控、访问防护、故障兜底、长期治理四个维度去做持续性优化与思考。

    • 第一，在数据写入链路上，基于责任链模式搭建分层校验体系，从源头降低脏数据产生概率。所有外部系统写入请求统一收口到写入 API，拆分为基础格式校验、资产关联规则校验、业务权限三层责任链。一方面实现校验逻辑解耦，新增业务规则不需要改动主业务流程；另一方面统一全集团数据写入标准，避免各个业务接入方各自实现校验逻辑，口径不一致。落地过程中也发现单纯堆叠校验节点会拉长接口耗时，我区分了强同步校验和弱业务规则校验，非关键校验后置为异步校验，在保证数据约束的前提下控制接口 RT，兼顾正确性与性能。同时写入接口层面统一增加幂等防护，依靠业务唯一标识做请求去重，解决上游系统网络抖动、服务重试带来的重复创建、重复更新问题，避免反复写入造成数据错乱。
    • 第二，在数据查询链路上，通过多重防护保障查询接口整体稳定性，防止单业务方拖垮整个平台。平台大量业务依赖多实体关联的资产视图接口，极易出现无限制条件查询、深度分页等高危请求。治理手段上：接口层面强制分页、设置单请求最大返回条数；对调用方做调用配额限流，做租户级访问隔离；持续监控慢查询，针对高频视图查询定制复合索引；通过监控提前发现异常查询流量，提前介入治理，而不是等故障发生再处理。这里我的思考是，单纯靠加索引无法永久解决查询压力，后续演进上需要做冷热资产区分，高频基础资产信息增加缓存层，把复杂视图查询流量与基础读写流量进行物理隔离，进一步提升整体可用性。
    • 第三，服务运行层面做好高可用与故障兜底设计。服务采用多实例容器部署，避免单点故障；沉淀完整的读写卡顿排查 SOP，从容器资源、外部依赖 RT、数据库慢查询、应用 GC 状态逐层定位瓶颈。在长期运维中意识到，高可用不能只依赖事后故障排查，需要前置建设：完善全链路埋点监控，对写入失败、查询超时、慢查询建立分级告警，由被动排障转向主动预警。
    • 第四，长期的数据可信治理思考。功能层面校验只能拦截实时写入错误，无法避免日积月累产生逻辑脏数据。参考业界 CMDB 产品的建设思路，我认为必须配套离线巡检任务，定时扫描全量资产，按照业务规则校验数据一致性，对异常数据产生告警，形成 “写入拦截‑实时监控‑离线巡检” 三层的数据可信保障体系。
    • 延伸总结（回答收尾拔高）
      整体来看，保障 CMDB 稳定不是一次性架构改造，而是持续性的治理工作。功能代码只解决 “能不能读写”，而稳定性设计、限流防护、校验约束、持续巡检解决 “能不能长期可信、稳定地读写”。这套架构基于 MongoDB 文档库实现，更适合资产字段灵活多变的运维场景，牺牲了原生强事务能力；如果是交易类业务系统，基于 MySQL 事务机制会是更稳妥的选择，我也针对性补充学习了 MySQL 索引、事务与锁相关原理，完善自身数据库层面的知识储备。
    • 衍生问题 1：责任链模式在校验场景相比 if‑else 有什么优势？有没有弊端？
      优势：规则解耦、易扩展、方便开关校验规则，适合持续迭代多条业务规范；
      弊端：链条过长带来性能损耗，调用链路调试复杂；
      落地取舍：核心强同步校验精简链路，次要校验后置异步执行。
    • 衍生问题 2：幂等具体怎么实现？有几种方案，你们为什么选择当前方案？
      可选方案梳理：唯一索引、token 机制、业务标识记录；
      结合你们业务：上游外部系统众多，统一 token 难以推进，选择业务主键幂等方案更易落地。
    • 衍生问题 3：如何防止业务方写出大量慢查询拖垮 CMDB 视图接口？
      四层防护：接口强制分页 + 查询参数校验 + 慢查询实时监控告警 + 业务访问限流 + 定期推动业务方优化查询语句。
    • 衍生问题 4：如果让你重构整套数据读写架构，优先增加哪些稳定性能力？
      1 新增完整变更审计日志，支持任何资产变更回溯，满足运维审计；
      2 引入缓存承载高频简单查询，隔离复杂视图查询压力；
      3 增加脏数据定时巡检任务，主动发现不合规资产信息；
      4 核心读写链路进行流量拆分，查询集群与写入集群物理隔离，互不影响。
    • 数据读写系统的关键点？？TODO
      幂等
      事务
      限流
      **

  • Q1：你站在平台管理员视角，谈谈 CMDB 整体微服务架构体系、流量链路与服务拆分的设计思想？
    CMDB 整体基于 SpringCloud 微服务架构 搭建，是一套分层清晰、职责单一、能力解耦的企业级资产底座架构。我在日常运维、问题排查、功能支撑过程中，完整梳理了平台流量链路与各核心微服务的职责边界，也理解了团队架构拆分的核心设计思路。

    • 第一，完整的整体流量接入链路。
      外部所有访问流量，经过 F5 负载均衡 做第一层流量分发与四层负载，再经过 Nginx/Apache 做静态资源处理与反向代理，统一前置流量收口，最终全部进入SpringCloud 网关。由网关实现统一鉴权、路由分发、限流拦截、请求日志埋点，再精准调度转发至后端各个微服务，实现了流量统一入口、统一管控、统一防护。
    • 第二，核心微服务职责拆分与架构解耦设计（核心亮点）。
      平台按照「用户交互、数据变更、数据同步、对外服务、采集执行、检索赋能」的职责维度做垂直拆分，避免大单体臃肿、职责混杂，我日常接触最多的四个核心服务，分工非常清晰：
      1 用户交互服务：专门承接前端页面所有用户操作、资产查询、表单提交、视图展示等交互类接口。只负责请求接收、参数校验、页面逻辑组装，不直接操作数据库，保证交互层轻量化、稳定、专注用户体验。
      2 数据连接器服务：是 CMDB 对外暴露的标准化出入口，负责对外提供统一资产读写 API、资产视图查询、第三方系统数据对接、权限鉴权。所有下游系统、外部业务方调用 CMDB，全部统一走这一层，实现对内对外接口隔离，保护底层数据安全。
      3 数据入库服务（核心中台服务）：这是我理解最深的架构亮点。无论是前端用户交互产生的数据变更，还是外部连接器接收的第三方数据变更，所有写库、数据落地、数据校验、幂等控制，全部收敛统一由数据入库服务完成。
      这个设计的优势非常关键：
      ✅ 实现读写分离、变更收口，所有脏数据拦截、校验规则、幂等逻辑只需要在这一层维护，不需要多服务重复开发；
      ✅ 彻底解耦「查询展示、对外接入、数据落地」能力，避免多服务直接写库导致的数据不一致、规则不统一、溯源困难；
      ✅ 所有变更单点可控、可审计、可兜底，从架构层面保障 CMDB 作为根数据源的权威性。
      4 配套能力服务集群：平台将非核心链路能力完全拆分独立部署，包括：
      • 数据同步服务：负责 Oplog 监听、增量数据推送下游；
      • 采集执行/采集代理服务：负责全量资产任务调度、远程采集、数据清洗；
      • 全文检索服务：负责对接 ES、模糊检索、资产搜索赋能。
      各服务各司其职，任务互不干扰，单个子服务异常不会拖垮主核心链路，极大提升平台整体可用性。
    • 第三，我对这套架构的个人设计思考与总结。
      我在长期运维中总结，这套微服务拆分完全符合单一职责、收口可控、分层隔离、高内聚低耦合的架构思想：
      1 入口统一：网关+连接器双层收口，内外流量隔离；
      2 变更唯一：全平台所有写操作统一收口入库服务，从架构根源保证数据可信；
      3 能力解耦：交互、查询、写入、同步、采集完全拆分，迭代互不影响，适合长期大型底座迭代；
      4 稳定性高：核心链路与辅助链路物理隔离，故障爆炸半径小。
    • 面试一句话亮点总结：
      CMDB 架构最大的精髓不在于微服务拆分本身，而在于所有数据变更的唯一收口设计，通过统一入库服务管控全平台写逻辑，从架构层面保证了集团资产数据源的唯一性、规范性与可信度，这也是企业级配置中心最核心的架构设计亮点。
    • 衍生追问1：为什么不让交互服务、连接器服务直接写库？
      如果多服务直接写库，会出现校验逻辑分散、幂等实现不统一、变更无统一日志、问题无法溯源，多人开发极易出现规则冲突、数据错乱。统一收口写入服务，可以做到规则统一、审计统一、兜底统一、治理统一，是底座类系统必备的架构设计。
    • 衍生追问2：F5、Nginx、网关三者的区别你怎么理解？
      三者是层层递进、各司其职的流量架构：
      1 F5：四层负载，负责最前置的 TCP 流量分发、负载均衡、高可用接入，不处理业务逻辑；
      2 Nginx/Apache：七层反向代理，处理静态资源、简单路由、解压、缓存，减轻后端服务压力；
      3 SpringCloud网关：业务层入口，负责鉴权、限流、路由、灰度、业务拦截，是微服务真正的流量管家。
      三者前置层层防护，让后端微服务只专注业务逻辑，是标准企业级流量架构。

  • Q2：介绍下基于 Oplog 实现的数据订阅方案，存在什么缺陷？如何处理？

    1. 实现原理：MongoDB 复制集生成 Oplog，完整记录库内所有 CRUD 变更；服务持续拉取解析日志，将资产变更事件推送下游系统；
    2. 方案优势：无业务代码埋点、低侵入；相比定时轮询，极大降低数据库查询压力；
    3. 现存痛点：Oplog 存在磁盘容量上限，日志滚动覆盖会造成变更丢失；消费进程宕机，窗口期变更无法捕获；
    4. 落地解决方案：持久化保存消费位点，增加消费中断告警；额外提供全量同步接口，支持下游进行数据补偿。
      延伸引导：如果是 MySQL 环境，一般依靠 Binlog 实现同等能力，我近期也对比研究过 Binlog 与 Oplog 的设计思路异同。

  • Q3：详细描述防火墙自动采集整条链路，线上遇到过哪些典型问题？
    链路流程：XXL‑Job 下发采集任务 → 消息投递 Kafka → 采集执行服务消费任务 → 通过 API/Ansible/FTP 拉取设备配置 → 结果推送 Kafka → 采集代理消费数据，清洗入库 MongoDB。
    典型故障：外部设备接口响应缓慢阻塞消费、生产速率大于消费速率引发 Kafka 消息堆积；
    优化手段：消费端开启批量处理、限制单节点任务并发、异常消息转入死信队列，避免任务持续重试堵塞链路。

  • Q4：mongostash 同步 MongoDB 数据到 ES，出现两边数据不一致，如何排查修复？

    1. 第一步排查同步组件运行状态，定位中断诱因：网络波动、文档字段结构不兼容、超大文档同步失败；
    2. 区分故障类型：增量同步链路断层、存量数据长期存在差异；
    3. 解决方案：恢复同步链路；开发定时数据校验任务，对比 MongoDB 与 ES 数据，自动触发缺失数据补偿。

  • Q5：平台查询接口响应很慢，你的标准化排查 SOP 是什么？

    1. 检查容器资源指标：CPU、内存、网络负载，确认是否资源瓶颈；
    2. 观测依赖外部接口 RT，排除第三方调用耗时拖累整体链路；
    3. 抓取数据库慢查询，核查索引是否合理；
    4. 分析应用 GC 日志，判断是否存在内存压力、频繁 GC 拖慢服务。
      实战案例：多次资产联合视图查询由于缺少复合索引导致超时，优化索引后查询耗时大幅下降。

  • Q6：线上 Java 服务频繁 FullGC、出现 OOM，你的完整排查流程？

    1. 故障发生优先保留现场，导出堆快照；利用 jstack、jmap、MAT 工具分析；
    2. 定位内存占用大户：超大集合、长期无法释放的对象、线程长时间持有资源；
      实战优化：批量资产采集任务一次性加载全量数据，改造为分页分批加载，缩短对象生命周期，解决内存溢出。

  • Q7：Kafka 消息堆积一般怎么分析、如何解决？

    1. 先监控 lag 指标，区分根因：消费处理能力不足、消费逻辑阻塞、消息重试形成死循环；
    2. 处理方案：优化消费业务逻辑、合理提升消费并发、阻塞消息隔离至死信队列；结合采集链路中真实堆积案例阐述。

  • Q8：syn-task服务FullGC失控、Kafka消费停滞的P1故障完整复盘
    我处理过采集代理服务严重FullGC失控故障，导致Kafka消费停滞、批量采集入库失败，通过线程栈、堆dump、JVM监控全方位定位根因，完成代码架构优化与JVM调优，是我Java工程稳定性的核心实战亮点。

    • 一、故障核心现象
      服务Old区使用率99.97%，每秒多次FullGC且无法回收内存，STW耗时数百毫秒，导致Kafka心跳超时、消费者反复重连，采集任务入库全部失败，故障持续80分钟，定级P1重大故障。
    • 二、多层级根因定位（面试高分逻辑）
      1. 核心代码根因：全局 synchronized 实例锁，锁内执行MB级JSON反序列化、批量入库等超耗时IO操作，持锁时间长达数十秒；
      2. 内存堆积诱因：多条Kafka消息新建裸线程消费，大量线程BLOCKED等锁，线程持有对象无法GC回收，持续积压内存；
      3. JVM配置短板：堆内存仅1G，配置严重不足，无冗余缓冲空间，轻微内存积压直接触发OOM；
      4. 恶性死循环：FullGC长时间STW导致业务处理更慢、持锁更久、线程积压更多，形成闭环故障，系统无法自愈。
    • 三、紧急止血方案
      临时扩容堆内存至4G并重启服务，快速恢复Kafka消费与采集入库能力，止损线上故障。
    • 四、四大根治优化方案（核心工程亮点）
      1. 锁粒度精细化重构（核心优化）：废弃全局大锁，基于instanceId实现细粒度分布式锁，仅将毫秒级Redis原子操作留在锁内，耗时的反序列化、入库逻辑全部移至锁外，持锁时间压缩至毫秒级；
      2. 消费线程池规范化：废弃无上限裸new Thread()，改用有界线程池+CallerRunsPolicy拒绝策略，实现消费背压，避免线程无限创建堆积；
      3. Kafka消费机制优化：关闭自动offset提交，改为业务处理完成后手动提交，避免重启丢失未入库消息，保证数据一致性；
      4. JVM参数标准化：固化4G堆内存、OOM自动dump、GC日志持久化、OOM自动退出参数，提升服务稳定性与可排查性。
    • 面试拔高总结：这次故障让我彻底掌握了「锁设计优化、线程池治理、JVM调优、消息队列消费机制」的综合工程能力，理解了代码细节缺陷如何引发线上P1级重大故障，具备从代码层、架构层、运维层全方位根治稳定性问题的能力。

  • Q9：私有化交付遇到 ZooKeeper 集群无法启动，完整说下排查过程和解决方案
    现象：容器环境重启后 ZooKeeper 集群启动失败，节点无法互相通信；
    根因：集群配置文件硬编码节点物理 IP，容器重建之后 IP 发生变动；
    手工处理：创建版本化配置文件
    解决方案：选择集群健康运行窗口期执行 reconf 动态更新集群配置，用内部域名替换固定 IP；
    亮点：方案无需停机重建集群，不存在业务中断；
    拓展思考：云原生容器环境部署中间件，应当尽量规避写死 IP，优先使用域名、服务发现机制。

  • Q11：讲讲你线上Java大日志文件清理的核心踩坑、Linux文件底层原理与零中断清理方案
    我在运维CMDB微服务过程中，深度踩坑Java服务活跃日志清理场景，吃透了Linux文件inode、文件句柄FD、幽灵文件核心原理，沉淀两套零业务中断的日志清理最优方案，规避致命操作风险。

    • 一、核心底层原理（面试高频）
      1. 核心三要素：文件名仅为目录索引标签，inode是文件真实数据存储载体，文件句柄FD是进程读写文件的内核通道；
      2. Linux文件删除判定规则：文件真正释放的前提是「文件名解绑+所有进程FD关闭」，仅执行rm删除文件名，进程持有FD仍会持续写入inode，产生deleted幽灵文件，磁盘空间无法释放；
      3. 日志缓存特性：Java服务持有活跃日志文件句柄时，ll/ls读取的是目录缓存大小，无法实时同步真实文件大小，易造成操作误判。
    • 二、线上致命踩坑复盘（避坑亮点）
      此前处理60G超大活跃日志时，因ll缓存未刷新误判清理失败，错误执行rm删除活跃日志，导致产生大量幽灵文件，服务持续向废弃inode写入数据，磁盘空间无法释放，最终只能重启服务恢复，造成短暂服务不可用。通过这次故障，我总结出严禁直接rm清理Java活跃日志的运维准则。
    • 三、两套零中断最优清理方案（适配不同场景）
      1. 轻量安全方案：cp备份+cat /dev/null > 清空，无需重启服务、无需发送信号，Java进程无感知，日志链路不中断，适配中小体积日志；缺点是cp过程短暂占用双倍磁盘空间；
      2. 超大日志最优方案：mv重命名+touch新建+kill -HUP重载日志，mv瞬间完成无磁盘翻倍风险，适配100G+超大日志文件，通过发送信号让Logback/Log4j2重新绑定新inode，实现无缝切换；
      3. 缓存刷新方案：掌握kill -USR1进程信号，不重启服务即可刷新目录缓存，让ll实时展示真实文件大小。
        面试拔高总结：日志清理看似基础，实则涉及Linux内核底层机制与Java日志框架联动，我通过实战踩坑形成了「懂原理、避风险、分场景、零中断」的标准化运维能力，规避线上低级致命故障。

  • Q12：详细说说CMDB内存Swap抖动OOM重大故障的完整排查、根因与整改思路
    我处理过CMDB data-center服务P1级内存故障，核心是Linux Swap抖动引发的服务OOM崩溃，全程沉淀了系统内存调优、JVM参数配置、线上故障止血的高阶实战能力。

    • 一、故障核心现象
      清空50G超大日志后，服务器Load飙升至15+，Swap使用率从14%暴涨至100%，持续si/so双向交换，系统陷入震荡，最终Java服务频繁FullGC、OOM崩溃，服务中断40分钟。
    • 二、核心根因（分层拆解，面试亮点）
      1. 直接诱因：错误使用cat /dev/null > 清空大日志，内核触发文件截断、刷盘操作，临时占用大量PageCache，瞬间耗尽物理内存；
      2. 系统底层问题：内核LRU算法误判，将Java、ilogtail的4GB活跃热数据换出至Swap，而非仅清理冷数据；
      3. 稳态架构隐患：服务器物理内存配置临界，长期依赖Swap存放冷数据，无冗余缓冲空间，一旦出现临时内存占用，直接打破内存平衡；
      4. 恶性死循环：热数据常驻Swap，业务频繁访问触发持续Swap In/Out，GC暂停时间从毫秒级拉长至秒级，最终OOM Killer杀死进程。
    • 三、紧急止血方案（零扩停最优操作）
      1. 精准止损：优先停止非核心日志采集服务ilogtail，快速释放5.8GB内存，满足Swap清空的物理条件；
      2. 强制恢复：执行swapoff -a && swapon -a，强制将Swap中8GB数据回迁物理内存，彻底终结内存震荡；
      3. 服务恢复：重启崩溃的data-center服务，校验日志写入、接口访问正常后恢复非核心服务。
    • 四、长效整改优化
      1. 操作标准化：统一使用truncate -s 0命令清空大日志，杜绝cat截断引发的内存震荡问题；
      2. 日志架构优化：配置Logback按天、按大小双维度日志切割，避免单日志文件超大；部署自动备份清理定时脚本，实现日志常态化轮转；
      3. JVM参数固化：统一配置4G堆内存、OOM自动dump、GC日志持久化、OOM自动退出参数，提升服务容错性与可观测性；
      4. 资源扩容优化：规划服务器内存扩容至32G，拆分非核心服务，降低核心服务内存占用压力。
    • 面试拔高总结：这次故障让我跳出单纯的JVM调优，掌握了「应用层+JVM层+Linux系统层」三层联动的故障排查思维，理解了内存、PageCache、Swap的底层联动机制，具备处理服务器级重大稳定性故障的能力。

  • Q13：讲讲CMDB MongoDB实例异常重启故障的排查思路与索引优化落地
    我处理过MongoDB节点无故崩溃重启的线上故障，通过日志溯源、慢查询分析、索引优化，彻底解决数据库实例稳定性问题，沉淀了MongoDB性能调优与故障排查能力。

    • 一、故障排查标准化SOP
      1. 定性崩溃类型：通过日志关键词Got signal区分主动崩溃（Aborted）与外部kill（Terminated），锁定为服务内部异常崩溃；
      2. 定位故障时间窗口：截取崩溃前后日志，精准筛选异常时段的数据库操作记录；
      3. 挖掘核心元凶：过滤COLLSCAN全表扫描日志，发现单条查询扫描20万+数据、仅返回1条结果，无复合索引导致超高IO消耗，是实例崩溃核心诱因；
      4. 集群状态校验：通过MongoDB Compass确认副本集主从节点状态，区分仲裁节点与数据节点，保证优化操作在主节点执行；
      5. 索引落地验证：后台创建业务复合索引，通过Explain执行计划验证，实现全表扫描（COLLSCAN）转为索引扫描（IXSCAN），查询耗时从5s+降至毫秒级。
    • 二、核心技术亮点
      1. 精准问题定位：通过日志关键词筛选、执行计划分析，定位「大扫描量、低返回量」的低效查询，解决MongoDB隐性性能瓶颈；
      2. 生产无损优化：采用background后台建索引，避免锁表影响线上读写业务；
      3. 稳定性治理：建立MongoDB慢查询巡检机制，常态化监控全表扫描、超耗时查询，提前规避实例过载、重启故障。

  • Q14：CMDB Kafka偶发性消息堆积的根因分析与治理方案
    线上出现每周定时Kafka消息堆积的规律性故障，我通过流量分析、消费能力校验，定位瓶颈并完成轻量化治理，保障采集链路稳定运行。

    • 一、故障现象与根因
      每周日凌晨定时出现Topic消息堆积，1小时后自动恢复，核心根因是：定时采集任务集中触发，消息生产流量激增，但对应Topic 6个分区仅配置1个消费实例，消费能力无法匹配瞬时生产流量，形成生产＞消费的堆积缺口。
    • 二、治理方案与优化思路
      1. 风险评估：校验Broker磁盘容量、消息堆积自愈能力，确认堆积为瞬时流量峰值导致，无数据丢失、无业务阻塞，无需扩容消费实例；
      2. 告警阈值优化：适配业务流量规律，上调该时段消息堆积告警阈值，避免无效告警干扰运维；
      3. 长效优化规划：后续可根据流量峰值，扩容消费实例、匹配分区数量，提升峰值消费能力，彻底消除堆积现象。

  • Q15：CMDB微服务视图卡顿、Tomcat线程打满故障排查与治理
    针对CMDB对外数据访问服务接口卡顿、500报错问题，我沉淀了Tomcat线程池监控、服务链路排查、上下游定位的标准化排查能力。

    • 一、故障核心现象
      ops-data-access对外查询、写入接口大面积500报错，接口响应卡顿，核心原因为Tomcat工作线程被批量写入请求打满，查询请求无线程可用、直接被拒绝。
    • 二、分层排查思路
      1. 线程监控定位：通过Tomcat线程指标判定，线程数打满100阈值、accept-count=0，新请求无排队队列直接拒绝；
      2. 链路分层校验：区分写入卡顿、查询卡顿不同场景，精准判断瓶颈在当前服务还是下游入库服务；
      3. 溯源流量源头：通过MongoDB审计表，按数据量排序筛选大批量写入请求，定位高频、大流量调用方，完成业务侧限流治理。
    • 三、核心优化思路
      1. 流量隔离：拆分批量写入与普通查询流量，避免大批量任务占用核心线程池，拖垮查询业务；
      2. 阈值管控：优化Tomcat线程池参数、请求队列长度，适配业务批量场景；
      3. 业务治理：对接调用方，规范批量写入频次与单次数据量，从源头降低流量峰值压力。

  • Q17：如果让你重新设计整套 CMDB 底座，你会做哪些优化？

    1. 对资产进行冷热分层存储，降低全量检索压力；
    2. 核心强一致性业务资产引入 MySQL 混合存储，弥补 MongoDB 事务能力短板；
    3. 在采集、数据同步全链路添加埋点监控，完善告警体系；
    4. 完善数据订阅能力，增加消息幂等、死信队列、自动补偿机制，提升下游同步可靠性。

  • 18：CMDB 大量选用 MongoDB，为什么初期没有选择 MySQL？你如何对比两种数据库？
    选型原因：平台资产类型繁杂，不同设备属性差异大，需要频繁新增扩展字段；MySQL 频繁执行 DDL 修改表成本很高，MongoDB 文档模型可以灵活扩展字段，适配业务场景。
    客观短板：MongoDB 不适合强事务、多表复杂关联的交易场景。
    主动过渡话术：如果是订单类核心业务系统，MySQL 会更加合适，事实上我对 Mysql的学习更加深入（有服务化数据库开发经验），我近期系统学习 InnoDB MVCC、锁机制、索引优化等内容，能够胜任关系型数据库相关的开发与调优工作。

🛠️ MOPS 自动化运维平台｜项目口述

项目定位：集团一站式自动化运维平台，承接全集团网络设备、备份服务的日常运维工单，核心替代人工高频手工操作，实现运维流程标准化、自动化、可回滚、可交付，支撑集团海量日常运维需求与外部私有化定制交付。

标准文稿：
MOPS 是美的集团核心自动化运维平台，主要承载全集团网络 F5 设备调度、NBU 备份服务两大核心模块的日常运维工作，替代传统人工登录设备、手工执行指令、手工配置策略的低效模式，实现运维工作标准化、自动化、闭环化。我作为网络与备份模块核心负责人，全程负责需求对接、方案设计、功能迭代、落地推进、团队协同及外部私有化定制交付全流程工作。
项目核心业务价值非常明确：集团日常网络变更、资源回收、备份策略下发、设备巡检工单量极大，传统人工操作效率低、误操作率高、无统一流程规范、故障难以回滚。我的核心工作，就是把高频、重复、高危的手工运维动作，通过Java 接口调用 + Ansible 远程调度 的方式固化为平台自动化能力，实现全流程线上化、一键化执行。
我主导落地了两大核心业务场景的自动化改造。第一是 F5 网络运维全流程自动化，覆盖负载均衡、域名解析资源的申请、变更、回收全生命周期，同时创新性落地了运维操作一键回退能力，解决了传统人工变更无兜底、出错需手动排查回滚、耗时久风险高的行业痛点，极大降低了网络变更的运维风险。第二是 NBU 备份服务自动化，实现客户端批量安装、备份策略批量下发、任务调度、结果校验全流程自动化，彻底替代人工远程操作。
在功能落地和工程优化层面，我结合业务场景做了针对性的性能与体验优化。针对批量多 IP 域名解析、批量设备巡检等多任务并行场景，手动串行执行耗时极长，我通过自定义线程池实现并行异步执行，大幅缩短批量任务执行耗时；针对备份客户端安装、策略下发等耗时超长的阻塞任务，我采用异步线程解耦，避免接口长时间阻塞超时，提升平台整体响应速度与用户体验。
除核心功能迭代外，我重点承担业务需求把控、团队方案落地、私有化对外交付三大核心工作。对内，我日常对齐各业务方运维需求，梳理标准化迭代方案，统一团队开发口径，协助团队成员拆解任务、落地功能，保障平台迭代高效有序；对外支撑私有化项目交付，承接客户定制化运维需求，全程对接客户沟通、需求确认、问题闭环、版本输出，积累了完整的 ToB 产品交付与客户闭环经验。
同时我主动对接部门 AI 智能化运维建设，完成运维助手与公司统一数字人平台的接入，实现办公端一键提报运维工单、自助查询运维进度；并且在团队根因定位 Agent 建设中，主动暴露平台工单标准化接口为外部 MCP 服务，支撑 AI Agent 自动拉取工单数据、辅助故障根因分析，完成传统运维平台向智能化运维的能力升级。
整体而言，这个项目让我跳出单纯的功能开发，完整沉淀了业务抽象、需求治理、工程优化、团队协同、客户交付、AI 能力融合的综合落地能力，擅长把繁琐的业务流程转化为标准化、自动化、可兜底、可交付的工程能力。

MOPS 自动化运维平台｜高频问答

  • Q0：你在 MOPS 平台主要负责什么？核心解决了什么业务问题？
    我主要负责 MOPS 平台F5 网络自动化、NBU 备份自动化两大核心模块的全栈落地与运维交付，同时承担对内需求治理、团队方案推进、对外私有化定制交付工作。
    核心解决两大业务痛点：第一，集团传统网络、备份运维高度依赖人工，高频工单重复操作多、效率低、人工误操作风险高；第二，人工变更无标准化流程、无记录、无回滚机制，一旦出错排查成本极高；第三，传统运维能力无法标准化对外输出，私有化项目交付成本高、难以闭环。
    我通过将手工运维动作固化为平台自动化能力，实现了运维流程标准化、执行自动化、风险可兜底、能力可交付，大幅提升集团运维效率，降低线上变更风险，同时支撑外部客户定制化交付。
    基本实现是工单对应变更流程，记录映射到实际的生产配置，，
    自动化，具体来说是把系统运维同事的描述转换为代码实现，关键是要理清需求，不能达成自动化的同时引入新的隐患？！如根据工单从A变更到B，A状态实际在生成环境中的一些属性可能没有完全被平台工单的字段覆盖，导致变更后如果是创建新的B覆盖A（蓝绿发布），可能B中一些属性赋值为默认值，没有从A带过来，，网络变更涉及到的影响会很大，比如F5Dns变更解析IP后丢失了解析方法的原值，于是平台要引入LoadBalanceMethod字段，并且要处理好存量数据。。

  • Q1：讲讲你 F5 自动化和一键回退功能的设计思路，亮点在哪里？
    传统 F5 网络变更、资源回收都需要运维人员手动登录设备、逐条配置指令，不仅效率低，一旦配置出错，需要人工逐条比对、手动回滚，恢复时间长、风险不可控。
    我的设计思路是：平台统一接收运维工单，标准化校验参数后，通过 Java 调用设备 API + Ansible 远程执行实现自动化配置下发；同时新增变更快照机制，每次正式变更前自动留存设备原有配置快照。
    若业务需要，例如变更后验证有误，或只是临时测试，可通过平台一键触发回退逻辑，基于前置快照自动恢复原有配置，无需人工干预。这里要注意实现回退，要在变更时记录“元数据”，替代不可信的平台数据的“变更前”值。。
    这个功能的核心亮点不只是自动化执行，而是补齐了运维变更的风险兜底能力，让高危网络变更从“人工赌风险”变成“可控可回滚”，是传统运维自动化的核心价值升级。

  • Q2：项目中用到了线程池、异步优化，具体是什么场景？解决了什么问题？
    MOPS 整体业务并发压力不高，属于典型的多任务批量耗时型业务场景，核心痛点不是高并发击穿，而是串行执行效率极低、接口阻塞超时，我针对性做了几处工程优化：

    1. 批量域名解析场景：业务经常需要对几十上百个 IP 执行 nslookup 校验，串行逐个执行耗时极高。我通过自定义核心线程池，实现多 IP 并行解析，批量任务耗时缩短 60% 以上，同时通过线程池参数管控，避免无限制创建线程导致资源溢出。
    2. 备份策略下发场景：NBU 客户端批量安装、远程策略下发属于超长耗时任务，同步执行会导致接口阻塞、前端超时。我采用异步线程单独执行耗时任务，接口即时返回受理结果，后台异步完成执行、记录日志、同步结果入库，极大优化了平台使用体验与接口稳定性。
    3. 防火墙策略下发：分布式 + 线程池！？
      核心思路：针对批量、耗时、IO 密集型运维场景，通过并行+异步的工程思维，解决效率与接口稳定性问题，适配运维类业务的核心场景痛点。

  • Q3：你说你负责需求把控和团队方案落地，具体做了什么工作？
    MOPS 承载全集团运维工单，需求零散、场景琐碎、业务方诉求不统一，如果盲目迭代会导致功能冗余、逻辑混乱、难以维护。我在团队中主要承担需求收敛、方案标准化、落地推进的工作：
    第一，日常对接各业务运维团队，收集零散工单需求，梳理共性场景，过滤无效需求，将个性化诉求沉淀为标准化通用功能，避免重复造轮子；
    第二，针对复杂运维场景，牵头拆解技术方案，统一团队开发规范，协助新人拆解任务、梳理执行逻辑，保障团队迭代节奏统一；
    第三，把控迭代优先级，区分紧急故障修复、日常功能迭代、长期能力建设，保障平台稳定优先、迭代有序。
    这让我具备了从「纯开发编码」上升到「业务理解+需求治理+团队协同落地」的综合能力，能够站在业务视角做技术建设。

  • Q4：讲讲你私有化对外交付的工作内容，遇到过什么难点，怎么解决的？
    我负责 MOPS 平台私有化项目的定制化需求交付、客户对接、问题全闭环工作。和对内迭代不同，私有化交付需要完全贴合客户现场环境、适配客户个性化运维流程，同时需要全程对接客户、答疑、处理适配问题，交付闭环要求极高。
    核心难点：客户现场运维流程、设备环境和集团内部不一致，存在大量定制化适配需求，且客户对平台稳定性、操作安全性要求极高。
    我的落地做法：前期充分对齐客户流程，梳理定制化适配清单，区分通用能力和私有化专属能力；中期迭代过程中同步适配环境差异，完成功能定制、兼容性测试；后期全程跟进交付验收、问题答疑、故障兜底，保障项目顺利交付。
    这份工作让我积累了成熟的 ToB 产品交付思维，懂得平衡通用化与定制化，保证产品可落地、可验收、可运维。

  • Q5：你在项目中怎么结合 AI 做能力升级？具体落地了什么？
    我主要从用户使用智能化、故障运维智能化两个维度，完成传统运维平台的 AI 能力赋能：

    1. 前端智能化提报：将 MOPS 运维工单体系接入部门统一数字人平台，员工可直接在办公软件端通过智能入口提报网络、备份运维工单、查询进度，降低运维操作门槛，提升工单流转效率；
    2. 底层 AI 赋能对接：在团队建设运维根因定位 Agent 时，我负责梳理平台标准化工单接口，封装为通用 MCP 服务对外暴露，支撑 AI Agent 自动调取工单全量数据，用于故障复盘、根因分析、异常工单统计，为智能化运维排查提供标准化数据底座。
      整体属于传统业务平台向智能化运维体系的能力延伸，贴合当前运维+AI的行业发展趋势。

  • Q6：MOPS 并发不高，你觉得你的技术亮点在哪里？怎么体现你的工程能力？
    虽然平台线上高并发场景少，但运维类平台的核心难点是场景复杂、流程琐碎、IO 密集、批量耗时、风险极高、交付要求高，我的工程能力主要体现在场景化落地和风险治理上：

    1. 场景化工程优化：针对批量 IO、超长耗时任务，落地线程池并行、异步解耦，解决效率与接口稳定性问题，具备典型的 IO 密集型业务优化思维；
    2. 风险工程化兜底：独创变更快照+一键回退机制，把人工不可控的运维风险，通过技术方案标准化兜底，体现风险前置、稳定优先的工程思维；
    3. 业务架构抽象：将零散、无序的人工运维操作，抽象为标准化、模块化、可复用的自动化流程，体现业务抽象与架构沉淀能力；
    4. 全链路交付工程化：实现对内标准化迭代、对外私有化可交付，具备完整的产品化、工程化落地思维。
      高并发只是工程能力的一部分，而场景适配、风险兜底、业务沉淀、稳定交付、团队落地，是我在这个项目沉淀的核心工程素养。

  • Q7：如果让你优化现在的 MOPS 平台，你会从哪些方向入手？

    1. 任务调度体系升级：目前批量异步任务依赖原生线程池管理，后续可以接入分布式调度框架，实现任务持久化、失败重试、断点续跑、任务监控告警，提升批量运维任务的可靠性；
    2. 运维数据可视化：沉淀工单执行数据、设备变更数据、故障数据，搭建运维数据大盘，实现运维状态可观测、风险可预警；
    3. AI 能力深度落地：基于已开放的 MCP 接口，深化 Agent 应用，实现异常工单自动识别、常规运维操作智能执行、故障自动根因定位；
    4. 权限与流程精细化：针对私有化多客户场景，细化租户隔离、权限分级、操作审计，进一步提升平台安全性与通用性。
    5. 性能监控体系完善：开启Tomcat JMX监控，完善线程池、请求链路指标观测，提前预警线程打满、接口阻塞等隐性故障。

  • Q8：Ansible+API 自动化运维的优势是什么？为什么不用纯自研脚本？

    1. 兼容性更强：Ansible 支持多设备、多系统远程调度，适配不同版本 F5、备份设备，无需针对不同环境单独自研脚本；
    2. 轻量化易维护：基于成熟开源组件，减少自研代码量，降低维护成本和 bug 风险；
    3. 流程标准化：可以统一封装运维剧本，将高频操作固化为标准化模板，方便批量复用；
    4. 可观测性更好：Ansible 自带执行日志、结果回显，方便平台统一记录日志、排查问题，适配工单审计需求。

  • Q9：讲讲你在云原生部署、容器化交付方面的落地能力与思考？
    我今年重点深耕平台私有化产品化交付体系建设，全程吃透了Java服务容器化打包、K8S云原生环境部署、私有化项目标准化交付全流程能力，完成了MOPS从“集团内部业务系统”到“可对外输出的标准化云原生产品”的能力沉淀，补齐了后端开发云原生交付、工程化落地的核心短板。

    • 第一，熟练掌握Java服务容器化全流程打包规范。针对MOPS多模块架构特点，统一编写优化Dockerfile，基于JDK轻量基础镜像，完成服务分层打包，精简镜像体积、减少冗余依赖；同时规范打包流程、统一配置文件环境隔离，区分开发、测试、私有化生产环境配置，避免不同环境配置混淆导致的部署异常，实现服务一键构建、可移植、可快速部署。
    • 第二，精通K8S云原生环境私有化部署与适配。熟练运用K8S核心资源对象，通过Deployment实现服务无状态弹性部署、保证副本高可用；配合Service实现服务内部负载均衡、端口统一暴露；通过ConfigMap、Secret挂载私有化定制配置和私密参数，适配不同客户现场的个性化环境需求，无需改动业务代码即可快速适配多场景交付。同时掌握容器日常运维能力，可快速排查容器启动异常、端口冲突、资源限制、配置挂载失效等私有化部署高频问题，保障交付稳定性。
    • 第三，建立了完整的产品化、标准化私有化交付思维。内部迭代侧重业务功能落地，而私有化交付核心是标准化、通用性、可适配、可维护。我在跟进交付过程中，重点沉淀了适配外部客户的交付规范：一是环境标准化，统一私有化部署依赖、中间件版本、资源配额，降低现场适配成本；二是配置解耦，将所有环境差异化配置外置，实现一套镜像适配多客户现场；三是交付闭环，梳理私有化部署SOP、问题排查手册，实现快速交付、快速兜底、故障快速复盘。
    • 第四，输出运维手册时，补充了架构梳理、配置清单（xCxG）??
      核心能力亮点拔高：很多业务开发只专注业务CRUD，缺乏上线部署和产品化交付思维，而我通过私有化工作，打通了「代码开发→容器打包→云原生部署→客户交付闭环」的完整链路。不仅具备业务开发能力，更懂云原生工程化落地，能够适配企业级私有化产品交付场景，具备独立支撑项目对外商业化交付的综合能力。
    • 衍生追问：私有化容器化部署相比传统服务器部署，最大优势是什么？
      1. 环境一致性：容器打包屏蔽系统环境差异，解决“本地正常、线上报错”的环境不一致问题，适配不同客户现场复杂环境；
      2. 部署高效化：摒弃传统服务器繁琐的环境搭建、依赖安装流程，实现一键部署、快速迁移，大幅提升私有化交付效率；
      3. 高可用可扩缩：依托K8s实现服务副本冗余、故障自动重启、弹性扩缩容，相比单机部署稳定性更强；
      4. 产品化程度高：配置与代码解耦、环境隔离，真正实现一套产物多环境复用，符合商业化产品交付标准。

  • Q10：讲讲MOPS线程池满导致接口pending的故障排查、根因与优化方案
    我处理过MOPS线上P2级线程池耗尽故障，核心是线程池设计不合理导致业务接口饿死，沉淀了Java线程池架构设计、故障排查、性能优化的工程实战能力。

    • 一、故障现象
      validatePorts核心接口持续pending、客户端超时报错，影响用户正常使用，故障持续2小时，属于典型的线上线程池资源耗尽故障。
    • 二、核心根因
      1. 架构设计缺陷：多个不同业务模块共享同一线程池queryCmdbValidIpExecutor，违反线程池隔离原则；
      2. 任务特性冲突：高峰期其他模块长耗时任务占满全部15个核心线程，快速的端口校验任务无线程可用，只能排队阻塞；
      3. 调用链路短板：上层接口使用Future.join()无超时阻塞等待，任务排队后直接导致API线程永久pending，无容错机制。
    • 三、原有线程池参数问题复盘
      原有线程池核心参数不合理：核心线程数15偏小、无任务超时机制、2000有界队列过大，导致慢任务长期占用线程、任务大量堆积、快速业务被饿死。
    • 四、完整优化方案
      1. 业务线程池隔离：拆分共享线程池，为高优、快响应的端口校验业务独立配置线程池，与耗时后台任务物理隔离，避免相互干扰；
      2. 线程池参数调优：调高核心线程数、缩减队列长度，适配IO密集型运维业务场景，避免任务无限堆积；
      3. 增加超时容错：替换无超时的join()方法，配置任务超时时间，避免接口永久阻塞，提升服务容错性；
      4. 流量均衡优化：配合集群部署，规避大量请求集中单节点的问题，分散线程池压力。
    • 面试拔高总结：这次故障让我深刻理解，线程池不仅是简单的多线程工具，更是服务资源隔离、SLA保障的核心架构手段，不同优先级、不同耗时的业务必须物理隔离，才能避免业务雪崩、接口饿死。

  • Q11：为什么需要手动开启Tomcat MBean监控？有什么工程意义？
    线上曾出现Tomcat线程池打满、接口阻塞但无监控告警的问题，核心原因是Spring Boot内嵌Tomcat默认关闭MBean注册，无法暴露线程池、连接数、请求耗时等核心指标，导致服务可观测性缺失。
    一、问题根因
    Spring Boot约定优于配置，内嵌Tomcat默认不向JMX注册MBean监控节点，监控探针无法抓取Tomcat运行指标，线上线程耗尽、连接溢出等故障无法提前预警，只能被动等待用户反馈故障。
    二、解决方案与落地链路
    在application.yml开启tomcat.mbeanregistry.enabled=true，触发自动装配机制，让TomcatServletWebServerFactory自动注册MBean到JVM，监控平台通过JMX Exporter定时抓取指标，实现线程活跃数、连接数、请求异常率、耗时等数据可视化。
    三、工程核心价值
    1 完善可观测体系：补齐Web容器层监控，实现应用层、容器层、业务层全维度监控；
    2 故障前置预警：提前感知线程池满载、连接堆积、请求超时等隐患，实现从被动救火到主动预警；
    3 性能调优依据：通过监控指标精准优化线程池参数、限流阈值，让调优有据可依。

  • Q12：讲讲MOPS慢SQL排查与索引优化实战（35万数据量级）
    我针对MOPS备份任务查询接口慢查询问题，完成全链路SQL优化，解决35万数据量级下的全表扫描性能瓶颈，沉淀了MySQL索引优化、查询语句重构的实战能力。

    • 一、故障核心问题
      备份任务记录表累积35万数据，接口多条件模糊查询+大批量IN权限过滤，导致MySQL放弃索引、全表扫描，接口响应缓慢，用户体验极差。
    • 二、核心性能瓶颈
      1. 双侧%模糊查询：所有业务字段使用LIKE ‘%值%’，完全失效B-Tree索引；
      2. 大IN列表叠加查询：权限过滤数千条系统名称IN列表，叠加模糊查询后，优化器直接放弃索引走全表扫；
      3. 索引覆盖不全：仅单字段索引，无针对性业务联合索引，无法适配多条件查询场景。
    • 三、场景化优化方案（面试核心亮点）
      • 查询语句精细化改造：
        1 备份类型改为精确等值查询，前端下拉枚举选择，废弃模糊匹配，新增专属索引；
        2 IP地址智能适配：完整IP走精确查询、IP段走前缀模糊查询，适配索引机制；
        3 文件路径优化：备份集路径废弃左侧%，改为前缀匹配likeRight，可正常命中索引；
      • 索引精准新增：针对高频查询字段backup_type、ip_address、backup_set建立专属业务索引，缩小查询候选集；
      • 查询逻辑优化：规避大IN列表低效查询，优化权限过滤逻辑，减少数据库查询压力。
    • 四、优化效果
      彻底解决全表扫描问题，接口响应耗时从秒级降至毫秒级，35万数据量级下查询性能大幅提升，同时规避了后续数据增量带来的性能恶化风险。

  • Q13：介绍下 MOPS 防火墙策略定时下发的调度方案，线上遇到过什么核心问题？如何解决的？！
    防火墙策略定时下发是 MOPS 平台高优先级的运维场景，整体依托 XXL-Job 实现定时任务调度，周期性扫描待执行防火墙策略，完成批量策略自动化下发、配置同步与状态校验。这个场景也是平台为数不多的高并发、批量 IO 密集型核心场景，线上曾出现过任务重复执行、单节点调度瓶颈、批量下发效率低下三大核心问题，我针对性做了三层架构优化，彻底解决调度缺陷，同时最大化提升批量任务执行效率。

    • 一、核心线上事故：定时任务重复执行问题
      初始调度逻辑仅依靠 XXL-Job 定时扫描任务，无状态管控机制，导致严重线上问题：前一次调度的批量策略任务尚未执行完毕，下一轮定时调度触发后，会再次扫描到同一份未完成的工单，造成同一防火墙策略重复下发、重复配置覆盖，极易引发设备配置冲突、运维工单异常、设备会话震荡等高危问题。
      根治解决方案：工单全状态流转管控
      我为防火墙策略工单设计闭环状态流转机制，从根源杜绝重复执行：所有待下发的防火墙策略工单，初始状态为「待执行」，调度任务扫描到待执行工单后，立即将工单状态原子更新为「执行中」，锁定当前任务；待当前批次策略全部下发完成、配置校验通过后，再统一更新为「执行完成」。后续所有定时调度扫描，仅筛选「待执行」状态的工单，「执行中、执行完成」的工单全部跳过，彻底规避了任务未结束、新一轮调度重复执行的线上问题，实现工单执行唯一性保障。
    • 二、集群多节点调度优化：基于 Redis 分布式锁实现节点负载均衡
      解决重复执行问题后，发现单节点执行任务资源利用率低，无法发挥集群部署优势。平台后端部署了三个服务节点，原生 XXL-Job 调度存在单点执行缺陷，大概率只会固定调度到某一个节点，其余节点资源闲置，大批量防火墙策略下发时执行耗时过长，存在性能瓶颈。
      为充分利用三节点集群调度能力，我引入Redis 分布式锁实现集群节点负载均衡调度，核心设计：拆分批量策略任务粒度，通过分布式锁抢占机制，让三个后端服务节点可以竞争式承接调度任务，避免任务单点扎堆执行；同时依托分布式锁保证同一工单、同一策略仅被一个节点抢占执行，在实现集群资源充分利用、提升调度吞吐量的同时，二次兜底杜绝跨节点重复执行问题，实现高可用、高负载的集群调度能力。
    • 三、批量任务并发优化：自定义线程池实现策略并行下发
      在单节点任务执行层面，初始为串行下发逻辑，单次调度批量 N 条防火墙策略时，逐条串行执行，IO 等待时间长、整体耗时极高，批量运维效率低下。
      针对该 IO 密集型场景，我做了并发工程优化：自定义业务线程池，设置线程池核心线程数大于单次调度批量任务数 N，保障所有待下发策略可同时进入并行执行状态；通过线程池统一管控任务生命周期、拒绝策略，规避无限制创建线程导致的系统资源溢出、任务堆积问题。通过线程池并行改造，大批量防火墙策略下发耗时大幅缩短，极致提升批量运维任务的执行效率。
    • 面试拔高总结
      这套调度优化方案，是我在 MOPS 平台核心的并发工程实战亮点，区别于常规简单 CRUD 开发。我从数据状态兜底、集群负载调度、单机并发提速三个维度，层层解决定时批量运维场景的核心痛点：通过状态流转解决任务重复执行的稳定性问题，通过 Redis 分布式锁实现集群资源最大化利用，通过自定义线程池并行优化解决批量 IO 任务效率瓶颈，完整沉淀了定时任务调度、分布式并发控制、IO 密集型场景性能优化的实战工程能力。
    • 衍生追问1：为什么线程池核心线程数要大于单次批量任务数 N？
      防火墙策略下发是典型的 IO 密集型场景，大量耗时消耗在设备接口调用、配置同步等待上，CPU 资源基本处于空闲状态。线程池线程数大于任务批量数，能够保证本轮所有批量任务全部并行执行，无任务排队阻塞，最大化压榨 IO 等待间隙的系统资源，彻底释放并发执行性能；同时通过有界队列+合理拒绝策略，规避瞬时超大批量任务导致的线程资源耗尽、任务堆积问题，兼顾性能与稳定性。
    • 衍生追问2：状态更新和分布式锁是如何配合保证绝对不重复执行的？
      形成「状态前置锁定+分布式锁兜底」的双重防护体系：工单状态更新是业务层前置拦截，优先过滤已执行、执行中任务，减少无效锁竞争；Redis 分布式锁是集群层兜底防护，防止多节点同时扫描到同一待执行工单、同时触发状态更新竞争，解决并发更新状态的线程安全问题，两层机制配合彻底杜绝单节点、跨节点的任务重复执行问题。

CMDB-Agent 自然语言问数项目｜AI工程化实战（核心加分项）

项目定位：基于阿里开源 Spring AI Alibaba DataAgent 二次开发，面向运维资产场景打造的轻量化智能问数 Agent。解决传统 CMDB 查数门槛高、需写SQL、依赖运维经验的痛点，支持用户通过自然语言直接查询、分析、统计运维资产数据，实现「自然语言→智能解析→精准查数→结果反馈」的端到端智能化能力，是传统运维平台向 AI 智能化升级的核心落地项目。我全程负责Java后端工程改造、Agent工作流架构优化、RAG检索定制、流式交互、模型热更新等核心AI工程化落地工作，重点深耕Java与AI结合的工程实战，而非单纯算法调优。

  • 3分钟标准项目口述文稿（可直接背诵）
    CMDB-Agent 智能问数项目，是我基于 Spring AI Alibaba 开源 DataAgent 二次迭代的运维领域智能化项目，核心目标是降低集团CMDB资产数据的查询门槛，让无SQL基础、无运维经验的员工，可通过自然语言直接查询、统计、分析上万台设备的资产数据，实现运维查数智能化、轻量化。
    项目核心难点在于，大模型原生输出具有概率性、不可控性，直接端到端调用极易出现 SQL 错误、语义偏差、脱离运维业务场景的问题；同时通用RAG检索无法适配运维资产枚举类、术语类专属场景，存在漏召回、语义稀释的痛点。针对这些问题，我聚焦AI工程化落地、Java架构适配、场景化能力优化，完成了五大核心技术改造，全程规避纯算法短板，突出后端工程落地能力。
    第一，我基于 Spring AI Graph 搭建DAG 原子化工作流架构，彻底解决大模型输出不可控问题。将原本端到端的问答流程，拆解为意图识别、证据召回、查询增强、SQL规划、SQL生成、语义校验、数据执行、报告生成等独立原子节点；每个节点通过结构化Prompt、固定输出格式、Java代码约束压缩模型自由度，同时配置Dispatcher动态路由，实现SQL失败重生成、规划不合理重试的容错闭环，极大提升问答准确率与系统可控性。同时支持分支、循环、故障重试，相比传统线性流程稳定性大幅提升。
    第二，实现全链路流式交互架构，优化用户体验与实时反馈能力。基于 Spring WebFlux 响应式编程，贯通从LLM流式响应、Graph节点流式执行到SSE前端推送的完整链路，所有节点均以Flux为输出载体；同时自定义文本类型状态机，区分SQL、Markdown、推理日志、表格数据四类流式内容，前端差异化渲染展示。并且实现线程安全的主动断连、资源释放机制，避免流式请求堆积造成的内存泄漏。
    第三，落地模型懒加载+无重启热切换工程能力，解决传统模型配置更新需重启服务的痛点。通过Spring AOP动态代理、自定义TargetSource实现Embedding模型动态委托，结合FactoryBean模式封装流式/阻塞式模型调用策略；通过比对数据库配置更新时间，结合ConcurrentHashMap缓存实现ChatClient懒加载、自动淘汰，支持DeepSeek、Qwen等多模型动态切换，无需重启服务，大幅提升运维迭代效率。
    第四，定制运维场景专属混合RAG检索架构，解决通用检索适配性差、漏召回问题。采用向量检索+关键词检索并行执行、RRF算法融合的混合检索方案，同时针对运维业务特性，将知识库拆分为实体枚举类、规则映射类两类数据，差异化配置召回参数与检索策略；通过LLM提取实体关键词，联动数据库精准模糊匹配，解决向量语义稀释导致的枚举值漏召回、术语不匹配问题，大幅提升查询语义匹配度。
    第五，设计轻量级多轮对话管理机制，实现会话无缝续接与低损耗交互。采用内存滑动窗口机制缓存核心对话摘要，不冗余存储完整上下文，降低Token消耗；冷启动时自动从数据库恢复历史会话状态，将上下文信息注入各节点Prompt，保障多轮问答的语义连贯性，同时规避大模型上下文过长导致的性能衰减与成本问题。
    整体项目完全聚焦后端AI工程化落地，不依赖算法调优，通过Java架构优化、工作流约束、检索策略定制、流式能力改造，实现了大模型在企业运维场景的稳定、可控、可用落地，补齐了我Java高阶工程、AI应用开发、响应式编程、动态代理架构的实战经验，也是我区别于普通CRUD开发的核心技术亮点。

  • Q1：你为什么要基于Graph图流程拆解问答链路？核心解决大模型什么问题？
    核心解决大模型概率性输出不可控、黑盒难容错、错误无法定位的行业通用痛点。传统端到端问答，模型一次性输出所有内容，极易出现SQL语法错误、语义偏离业务、逻辑漏洞等问题，且无法精准定位出错环节、无法自动修复、难以迭代优化。
    我通过DAG有向无环图将复杂问答拆解为多个单一职责的原子节点，每个节点只负责一项任务，通过Java代码+结构化Prompt严格约束输出格式：意图识别仅做二分类、规划节点仅输出规范JSON、SQL节点仅负责语句生成、专属节点做SQL审计校验。
    同时搭配Dispatcher动态路由，形成完整容错闭环：SQL校验失败自动重生成、规划不合理触发重试、参数异常自动兜底，将大模型的不确定性，通过工程架构手段转化为可控、可观测、可修复的稳定能力，这也是企业级AI应用落地的核心关键。

  • Q2：讲讲你全链路流式输出的技术实现，用到了哪些核心技术？
    整套流式架构基于Spring WebFlux + Reactor + SSE实现，是典型的响应式编程工程落地，贯穿整个Graph工作流：

    1. 底层载体：所有Graph节点的执行结果均以Flux流式数据流返回，替代传统阻塞式返回，支持逐Chunk输出；
    2. 中转推送：通过Sinks.Many背压感知管道订阅全链路流式输出，统一封装SSE协议推送前端，实现实时流式反馈；
    3. 内容差异化渲染：自定义TextType状态机，在流中嵌入内容类型标记，区分SQL代码、推理日志、Markdown报告、表格数据，前端针对性做高亮、折叠、展示处理；
    4. 资源安全管控：基于AtomicBoolean原子标记实现线程安全的流中止机制，前端断开连接时，自动释放Disposable资源、终止任务执行，彻底解决流式请求堆积、内存泄漏问题。
      整套方案的亮点是全链路流式贯通，并非单一接口流式，而是每个AI执行节点都支持实时输出，用户体验和系统实时性远超普通单次返回的AI应用。

  • Q3：模型热切换、懒加载的核心实现思路是什么？解决了什么业务痛点？
    传统AI项目模型Bean均为容器启动时初始化，模型配置修改、模型切换必须重启服务，迭代效率低、可用性差。我通过Spring高阶特性实现无重启热更新、按需懒加载：

    1. Embedding模型动态代理：使用Spring AOP ProxyFactory + 动态TargetSource（非静态代理），容器中的代理Bean每次被调用，都会动态委托给注册器获取最新模型实例，实现无感热切换；
    2. ChatClient懒加载缓存：基于「模型名称+思考模式」组合键，通过ConcurrentHashMap实现懒加载，首次调用动态构建实例，后续复用；同时比对数据库配置updateTime，自动淘汰过期缓存，无需重启；
    3. 多模式统一封装：通过FactoryBean工厂模式，统一封装流式、阻塞式两种调用策略，业务层无需感知底层实现，按需切换。
      核心价值：实现模型配置、模型版本、调用模式的线上无重启更新，大幅提升AI应用的迭代效率与生产环境可用性。

  • Q4：你的RAG混合检索架构和普通向量检索有什么区别？解决了什么独有场景问题？
    通用单向量检索存在严重的语义稀释、枚举值漏召回、业务术语不匹配问题，完全无法适配运维资产场景，我针对性设计了分层混合检索架构：

    1. 并行融合检索：采用模板方法模式，通过CompletableFuture实现向量检索、关键词检索并行执行，再通过RRF算法融合排序结果，兼顾语义匹配和精准词条匹配；
    2. 场景化知识分层：将运维知识库拆分为两类核心数据，差异化适配：一是实体枚举类（系统名、设备类型），调低相似度阈值、增大TopK，避免精准枚举被语义结果挤压；二是规则映射类（术语翻译、概念规范），精准匹配语义，优化查询规范性；
    3. 兜底增强检索：通过LLM提取用户问题中的实体关键词，联动数据库模糊匹配，解决向量检索无法精准匹配枚举值的短板；
    4. 多后端适配：基于条件注解实现Milvus、本地向量存储的动态切换，适配开发、生产不同环境。
      最终实现用户自然语言，精准转化为CMDB运维标准查询口径，从根源提升SQL生成准确率。

  • Q5：多轮对话你是怎么设计的？为什么不直接用大模型原生上下文？
    大模型原生上下文直接累加对话，会导致Token消耗激增、推理速度变慢、冗余信息干扰查询精度，我设计了轻量级低损耗会话管理方案：

    1. 精简存储策略：不存储完整对话内容，仅持久化「用户问题+AI规划摘要」核心数据，极大降低存储与Token消耗；
    2. 滑动窗口机制：内存中仅保留最近N轮有效会话，自动淘汰过期上下文，避免对话无限累积；
    3. 冷启动恢复：客户端重新连接时，自动从数据库加载历史会话摘要，重建上下文状态，实现跨请求无缝续聊；
    4. 精准上下文注入：仅将有效会话信息注入各节点Prompt，辅助模型理解多轮语义关联，兼顾准确率与性能。
      这套方案相比原生上下文，更低成本、更高性能、更适配企业级长期会话问答场景。

  • Q6：讲讲你项目中的容错、降级、修复机制，体现工程稳定性思维
    我在项目中搭建了多层级容错自愈体系，彻底解决AI问答随机性高、易出错的问题：

    1. 节点级重试：SQL生成失败、语义校验不通过时，自动触发节点重试，更新Prompt约束重新生成，最多支持3次迭代修复；
    2. 人工介入兜底：内置Human-in-the-Loop可中断节点，复杂场景自动暂停流程，等待用户审核规划方案，支持人工修正后恢复执行，避免错误扩散；
    3. 链路级降级：模型调用超时、网络异常时，自动降级为基础查询模式，保障核心查数功能可用；
    4. 上下文回滚：人工拒绝方案或重试失败时，通过上下文管理器回滚上一轮会话状态，避免脏数据影响后续问答。
      整套容错机制让AI应用从“偶尔可用”变成“企业级稳定可用”，是核心工程亮点。

  • Q7：这个项目最大的技术难点是什么？你是怎么攻克的？
    最大难点不是调用AI接口，而是如何通过Java工程手段，约束大模型概率性输出，适配严苛的企业运维场景。通用AI模型自由度过高，极易输出错误SQL、脱离业务口径、生成不符合CMDB资产规范的查询语句，随机性强、生产可用性极低，无法直接落地企业真实业务场景。
    我的解决方案是「架构限流+代码约束+数据增强」三层工程闭环方案，完全靠后端架构手段压制模型不确定性：

    1. 架构层拆解限流：通过Spring AI Graph把端到端黑盒流程拆分为单一职责原子节点，每一步只允许模型做一件事，从流程维度大幅降低出错概率；
    2. 代码&Prompt强约束：每个节点定义严格的结构化输出规范，通过Java实体类、转换器强制校验输出格式，非法结果直接拦截重跑，杜绝不规范输出；
    3. 业务数据前置增强：通过定制混合RAG、运维术语映射、实体精准匹配，给模型注入标准业务口径，让模型“懂运维、懂CMDB资产规则”，从输入源头减少语义偏差；
    4. 容错自愈兜底：搭配节点重试、SQL语义审计、上下文回滚机制，模型出错可自动修复，形成完整工程闭环。
      简单来说，我没有依赖模型本身的能力提升，而是通过Java工程架构治理，把不可控的大模型能力，改造为企业可落地、可审计、可自愈的标准化业务能力，这也是AI应用工程落地的核心难点与核心价值。

  • Q8：你项目中用到了Spring AI Graph，讲讲DAG工作流的核心优势，和普通串行调用有什么区别？
    传统AI应用基本都是串行线性调用，流程固化、无容错、无分支、不可控，一旦某一步出错直接整体失败，且无法针对性优化单节点能力。而我基于Spring AI Graph实现的DAG有向无环工作流，是企业级Agent落地的核心架构升级，核心优势有四点：

    1. 职责原子化、可迭代优化：将复杂问答链路拆分为独立节点，意图识别、检索、规划、SQL生成、校验各司其职，可单独优化某一个节点逻辑、Prompt、策略，不影响整体流程，迭代性极强；
    2. 动态路由、支持分支与循环：通过Dispatcher分发器实现智能路由，支持条件分支、失败重试、循环修复，比如SQL校验失败自动回退重生成、规划不合理重新召回知识，串行流程完全无法实现这类自愈能力；
    3. 全链路可观测、可定位：每个节点独立执行、独立日志、独立状态，出错可以精准定位是召回问题、规划问题还是SQL生成问题，彻底解决大模型黑盒问题；
    4. 多模式适配、灵活性极高：基于同一套DAG图，通过路由配置切换纯SQL生成、完整分析、人工审核三种模式，适配不同业务场景，一套架构支撑多类问答需求。
      总结：串行调用是“一次性黑盒调用”，而Graph DAG是可管控、可自愈、可迭代、可扩展的工程化AI工作流。

  • Q9：谈谈你对AI Agent工程化的理解，你的项目和普通简单调用LLM的AIdemo有什么本质区别？
    市面上绝大多数AIdemo只是简单封装LLM接口，单次调用、无约束、无容错、无业务适配，只能做演示无法落地生产。而我的CMDB-Agent是完整企业级AI工程化落地，核心区别体现在工程稳定性、业务适配性、可运维性三个维度：

    1. 从“黑盒调用”升级为“可控工作流”：通过DAG原子化拆解+结构化输出约束，解决大模型概率不可控问题，让AI输出可标准化、可校验、可修复；
    2. 从“通用能力”升级为“场景定制能力”：针对运维资产场景定制混合RAG、术语翻译、实体补全、枚举精准匹配，解决通用模型不懂业务、答非所问的问题；
    3. 从“一次性调用”升级为“可运维可迭代系统”：具备模型热切换、懒加载缓存、全链路流式、多轮会话管理、故障重试降级、人工兜底回路等工程能力，支持线上持续迭代、稳定运行；
    4. 纯后端工程落地、贴合企业技术栈：全程基于Java/Spring生态改造，不依赖算法调优，通过架构设计、代码约束、工程优化实现AI落地，贴合后端开发的技术深耕方向，适配企业生产环境部署标准。
      一句话总结：Demo解决“能不能跑”，我的项目解决能不能长期、稳定、准确、可运维地在企业生产环境落地。

  • Q10：项目还有哪些未深入、可优化的点？体现你的复盘思考能力
    我目前核心深耕的是AI工程落地、Java架构改造、工作流约束、检索优化、流式交互，还有部分AI进阶能力尚未深入落地，也是后续优化方向，面试可坦诚说明、体现复盘思维：

    1. MCP协议能力未深度落地：目前仅了解MCP工具调用规范，尚未实现Agent主动调用外部工具、主动拉取工单数据、主动校验资产状态的能力，后续可以基于MCP对接MOPS运维工单、监控接口，实现AI主动运维排查；
    2. 精细化文本切割与RAG优化未深挖：当前知识库以整体分类召回为主，未深入做细粒度切片、重叠度优化、召回权重精细化调优，后续可以通过自适应切片、语义分块进一步提升精准度；
    3. 人工反馈回路未完全闭环落地：目前仅实现人工暂停、审核、重规划的基础能力，尚未将人工反馈持续沉淀为知识库、自动优化Prompt与检索策略，缺少数据闭环迭代能力；
    4. 多级缓存体系待完善：可以新增热门问答、高频SQL缓存，减少重复模型调用与检索开销，进一步提升响应速度、降低推理成本。
      整体来说，项目核心工程化能力已经落地成熟，进阶AI智能迭代能力是我后续重点深耕的方向。

  • Q11：如何评价问数效果？
    ？？

  • Q12：抛开Spring AI等框架，只用原生LLM能力+自定义Skills，你如何从零自研实现一套自然语言问数系统？
    如果剥离所有AI开发框架，不依赖Graph工作流、封装好的Agent组件，我可以基于原生LLM调用 + 自定义技能组件 + 纯Java工程编排，从零自研实现可落地、可控、稳定的自然语言问数系统，核心是用通用编程能力复刻框架核心逻辑，同时规避原生LLM的随机性问题，整体分为四层自研架构，完全脱离框架依赖：

    • 第一层：基础通信层（原生LLM能力封装）
      不使用框架封装的ChatClient，我会基于HTTP请求原生对接LLM模型接口，统一封装阻塞、流式两种调用工具类，自主处理请求签名、参数组装、超时重试、异常捕获、响应解析逻辑。同时通过自定义Prompt模板引擎，实现提示词的动态拼接、参数注入、版本管理，替代框架的Prompt封装能力，保证基础模型调用可管控、可复用。
    • 第二层：核心技能层（自定义Skills能力落地）
      拆解问数系统所需的核心能力，封装为独立、可复用的Java Skill技能组件，完全自主实现，核心包含四大技能：
      1. 意图识别Skill：封装原生LLM调用，传入固定分类Prompt，仅让模型输出标准化意图结果（查数/统计/分析/无效提问），通过代码枚举校验返回结果，非法输出直接拦截兜底；
      2. 知识库检索Skill：自主实现向量检索、关键词检索混合逻辑，通过Java代码完成文本向量化调用、结果排序、RRF融合、实体匹配，复刻RAG核心能力，适配运维资产场景；
      3. SQL生成&校验Skill：注入数据库表结构、资产规范、枚举口径，让模型根据用户问题和检索证据生成SQL，同时自研SQL语法校验、语义合规校验、高危语句拦截逻辑，杜绝错误SQL、删改类高危语句执行；
      4. 结果整理Skill：将数据库查询结果、原始问答数据，通过LLM二次加工为通俗易懂的自然语言报告，适配用户阅读习惯。
    • 第三层：流程编排层（纯Java自研工作流）
      替代Spring AI Graph DAG框架能力，通过责任链+状态机+条件分支纯原生代码编排完整问答链路，规避线性串行调用的缺陷。自定义全局上下文对象，统一存储用户问题、检索证据、SQL语句、会话状态、异常信息，贯穿全流程。通过代码逻辑实现核心机制：意图识别失败直接终止、SQL校验失败自动重试、证据不足触发二次检索、异常场景触发降级兜底，复刻框架的分支、重试、容错能力，实现流程可控可观测。
    • 第四层：工程稳定层（自研容错与优化能力）
      基于通用Java工程能力，补齐原生LLM的生产短板，完全复刻框架工程能力：
      1. 会话管理：自主实现内存滑动窗口+数据库持久化，管控多轮对话上下文，精简Token消耗；
      2. 重试与容错：自定义重试注解和重试策略，针对模型超时、输出不规范、SQL错误实现分级重试，搭配全局异常兜底；
      3. 流式交互：基于SSE+响应式HTTP原生实现流式推送，自主管控流资源、处理连接断连、内存释放，避免资源泄漏；
      4. 模型热更新：通过配置文件动态加载、Bean动态注册，无需重启服务切换LLM模型与参数。
    • 核心总结与面试拔高
      框架的本质是封装通用工程能力、简化开发，而底层核心逻辑完全可以通过原生LLM调用+自定义技能拆解+纯Java流程编排实现。不用框架的核心难点，不再是模型调用，而是通过手动工程约束压制大模型随机性、标准化流程、保障系统稳定性。
      这套自研方案能落地，也恰恰证明我不是只会套用AI框架的开发者，而是真正理解Agent工作流、RAG原理、AI工程化核心本质，具备透过框架底层、自主实现AI业务系统的通用编程与架构能力。

⚡项目四：基于XXL-Job的高并发定时秒杀商城系统

  • 为什么自己实现秒杀系统？
    日常工作以内部运维平台开发为主，业务偏向资产配置、自动化流程，较少接触高并发、流量削峰场景。因此自主搭建极简秒杀系统，一方面实践 Redis、消息队列、并发控制等技术；另一方面持续探索 AI Coding 工作流，借助大模型完成需求拆解、接口设计、单元测试、问题调试，沉淀一套标准化开发流程，同时学习优秀开源项目架构思想，补齐高并发系统工程落地经验。

🛢️ 项目五：InfluxDB数据库服务化能力建设

  • 我主导了InfluxDB数据库的服务化改造，在数据库管控平台（DataMars）中，建设InfluxDB的“数据库即服务”（DBaaS）能力，解决手动运维数据库效率低、易出错的问题。基于开源Influxdb Cluster，从0到1负责InfluxDB实例的备份恢复、在线变配、节点迁移/重搭等核心功能的调研、设计和开发。
  • 具体工作与关键技术细节
    1. 核心场景实现：
      备份恢复：调研并采用 influx_inspect export 逻辑备份与OSS对象存储结合方案，实现了数据库级和实例级的备份恢复，并集成到平台的工作流引擎中。
      在线变配：通过修改Kubernetes StatefulSet配置，实现了CPU、内存的原地变配，以及通过PVC（持久化存储声明）扩容实现存储空间的在线扩展。
      节点迁移与数据一致性保障：这是项目最大挑战。我设计并实现了 “热分片截断-冷副本恢复”双阶段迁移方案。在数据持续高速写入（2000 points/s）的场景下，通过先截断热分片引导新数据写入新节点，再从健康节点同步历史数据，有效解决了开源工具在迁移过程中可能丢失增量数据的问题，确保了数据一致性。
    2. 技术架构：功能深度集成到平台的apiserver、bakserver和agent组件中，通过K8S Operator模式对InfluxDB集群的生命周期进行管理。
  • 市场竞品对比与成果衡量
    • 对标产品：这类数据库服务化平台在业界类似云和恩墨zCloud、腾讯云DBbridge等数据库管理平台，核心是实现数据库资源的池化、按需供给和全生命周期智能化管理。
    • 我的成果：事实上基本没有用户，随着发现开源数据库的功能不完善，开发也中断了。
  • 在面试中介绍时，你可以遵循“背景-行动-结果-对比”的结构：
    • 开头总结：用一句话点明项目核心价值。
    • 具体阐述：重点突出你如何解决关键问题，特别是高可用、数据一致性、自动化闭环方面的设计。
    • 量化成果：用数据（如效率提升百分比、可靠性指标）证明你的贡献。
    • 展现视野：通过提及竞品，表明你不仅埋头编码，更抬头看路，了解行业最佳实践。

hr

  • 谈薪
    1. 背景：当前现金总包 18W（12.1K×14 薪 + 月度餐补 400 + 年度旅游补贴 5000），员工宿舍属于公司后勤福利，不计入总包基数，只可口头顺带提，不能算进年收入。尽量让对方先开薪资；如果要你先说，直接输出总包目标，不说单月底薪。
    2. 目标：目标总包28.8W（较现有总包上涨 60%），对应期望月薪约 20K；
    3. 口径原则：优先聊总包，不聊底薪涨幅，规避底薪从 12K 涨到 20K 看上去 67% 的巨大涨幅；HR 审批看总包，薪资可以拆分：底薪不暴涨，用绩效 / 年终补齐总包。如果底薪达不到 20K，但总包接近目标，是可接受的（HR 拆分薪资结构，底薪涨幅被控制，靠年终绩效拉总包）。
    4. 背景客观情况：上家是制造业，行业薪酬基线低，初始薪资低于同背景同经验；可以用来解绑 “现有底薪低 = 能力低”，不能卖惨、不提倒挂、不提晋升失败、不吐槽老公司。我项目经验丰富，希望互相尊重，达到一个合理的薪资。（20k是很多大厂的校招生水平，对比同工作年限的水平也偏低）
    5. HR 压价反复揪底薪 ➡️ “前公司行业薪资水位偏低，同背景人员和互联网赛道存在明显差距，希望可以结合我的实际交付能力综合定薪，不只参考过往底薪。”

2026