Work for YILI

Appearance

2026-10-13 工作日志 ​

风控中心：网易离线计算中心 SaaS 部署沟通 ​

本次会议围绕网易离线计算中心与伊利数据中台的SaaS 部署沟通展开，明确了业务场景为离线指标加工，并确定需先输出技术架构图及内部组件清单，待方案评审后再与数据底座团队深入对接。

小结 ​

1. 项目背景与业务需求

  • 明确离线计算场景：网易计划部署一期 SaaS 并开发离线模块，需从数据中台定时拉取每日业务数据（如门店进货量等），进行离线指标加工后再供风控规则分析。
  • 明确计算分工模式：复杂计算指标由网易提需求给中台处理，中台返回结果数据（阈值或明细）；网易自身不直接在中台集群内开发代码或搭建独立 Hadoop 集群。
  • 明确数据传输方式：受整体架构限制，离线中台无法直接读库读数，仅支持通过 API 获取结果数据；若数据量达千万级明细，可申请管道任务推送。

2. 组件与技术架构对齐

  • 统一中间件版本要求：为避免重复适配和版本兼容问题，网易希望其新系统使用的中间件及组件版本尽量与伊利集团现有标准保持一致。
  • 暂缺大数据组件清单：会议初期网易提出获取 Hadoop、Spark、Flink 等大数据组件清单的需求，但当前参会团队不负责底层大数据支撑，该职责归属数据智能团队。

3. 后续评审机制确认

  • 前置方案评审要求：因涉及数据底座评估与多方协作，网易不得直接按当前宽泛想法开发，需在整体技术方案完成后邀请各方进行正式评审。
  • 下次沟通材料准备：为避免信息不对称，网易需准备包含产品架构、离线场景说明及技术架构的完整材料，以便数据底座团队给出针对性建议。

待办 ​

1. 方案输出

  • 尽快输出离线计算中心的技术架构图与初步方案，明确具体操作方式与数据流向。——蔡圣亚
  • 整理包含产品架构、离线场景说明及技术架构的完整汇报材料，用于下次方案评审。——蔡圣亚

2. 组件清单与评审协调

  • 搜集并提供伊利集团内部可用的标准组件清单（包括 Hadoop、Spark、Flink 等中间件及其版本）。——孔玮、杜晓卓
  • 协调数据智能团队（如刘超等负责数据底座的同事）参与下一次技术方案评审会议。——杜晓卓

营销活动中心 / 计费管理 / 券中心：1015 上线需求推进（管理要求） ​

1015 上线需求推进，要求各供应商团队按管理要求维护上线评审检查清单，覆盖代码评审、上线方案评审等环节。

完成的工作 ​

1. 推动供应商团队按管理要求维护上线评审检查清单 ✅

  • 涉及系统：营销活动中心、计费管理、券中心（1015 上线需求）；
  • 清单覆盖环节：代码评审、上线方案评审等；
  • 管理动作：由各供应商团队自行按管理要求维护清单，而非由技术侧临时收料。

小结 ​

  • 管理抓手是"清单化"而非"临时收材料"：要求供应商按统一要求维护上线评审检查清单，把评审前置为过程动作，避免上线前临时补材料。
  • 卡点已明确：代码评审与上线方案评审两项是本次清单的必填项，须在 14 日上线评审会前完成自查。
  • 排期背景：10.12 已定档 14 日下午 5–6 点的上线评审会、15 日正式上线，本次清单维护即该评审会的前置动作。

待办 ​

  • 各供应商团队按管理要求维护 1015 上线评审检查清单，覆盖代码评审与上线方案评审。（责任人待定）
  • 汇总各供应商团队清单自查结果，确认是否具备 14 日上线评审条件。（责任人待定）

营销活动中心：盘点任务压测评审 ​

本次会议回顾了盘点任务相关查询接口的压测结果，澄清了状态更新接口的业务逻辑与压测可行性，并明确了数据库部署现状、资源监控与冷数据归档规划。

小结 ​

1. 盘点任务查询接口压测结果

  • TPS 峰值达 700–800：分页查询盘点任务接口压测 TPS 峰值 780，响应时间维持在 70 毫秒左右，整体性能表现优异。
  • 数据库 CPU 为当前瓶颈：100 并发测试下 MySQL CPU 被打满，后续通过降低并发数取得当前压测截图。
  • 当前配置可满足业务需求：数据库现有 8 核 16G 配置，结合现有业务量评估足以支撑伊利液奶场景，后续具备硬件扩容空间。

2. 数据库扩容与缓存策略评估

  • 硬件扩容为当前兜底方案：针对数据库 CPU 瓶颈，后续可通过提升 MySQL 硬件配置（如扩至 64 核）进行线性扩容以适配业务增长。
  • 缓存方案存在业务冲突：开发团队曾提议引入 Redis 缓存，但业务端指出盘点任务状态变更要求强实时性，缓存需额外处理一致性问题，当前阶段暂不强制要求加入缓存。
  • 数据量增长风险需重点关注：需警惕业务数据随时间积累导致查询变慢，要求后续对底层表设计进行白盒追踪，评估历史数据归档方案。

3. 盘点任务状态更新接口评估

  • 更新对象为门店维度：经开发团队确认，该接口更新的是单个门店的盘点状态，而非整个盘点任务的状态，属于主从订单关系中的子订单状态更新。
  • 任务结束依赖全门店完成或超时：只有当任务下所有关联门店均完成盘点，或到达预设结束时间时，整个盘点任务才会被标记为已完成。
  • 压测数据构造困难：同一门店在同一时间段内只能存在一个进行中的盘点任务，且任务状态仅能更新一次，无法批量造出足够多的任务数据做并发压测。
  • 改由代码审查评估性能：该接口暂不纳入压测范围，后续通过代码 Review 结合业务量预估评估性能表现。

4. 数据库部署与资源规划

  • 与主数据共用数据库：盘点任务数据当前部署在与主数据（Carsem）共用的 MySQL 数据库中，当前配置为 8 核 16G。
  • 当前资源利用率较低：现有配置足以支撑上线初期的业务调用；系统上线后将持续监控数据库资源情况，若业务量增长导致资源吃紧则按需升级。

5. 盘点机接口性能评估

  • 历史压测峰值达 1700：根据历史压测报告，盘点机提交及签收接口 TPS 峰值曾达到 1700。
  • 需进一步比对当前数据：当前 APM 监控中未能直接查看盘点接口的实时数据，会议决定会后拉取相关接口地址，比对当前实际 TPS 与历史压测结果的差异。

6. 数据归档与冷数据处理

  • 历史数据需定期归档：需补充冷数据迁移方案，将历史数据归档至其他存储介质，确保线上表数据量稳定。
  • 盘点数据保留周期较短：开发团队评估认为盘点任务结束后数据主要用于备查，保留一年左右即可，数据量级相对可控，归档处理较码和报表业务更简单。
  • 需评估长期数据增量：要求开发团队对盘点任务表的月度和年度数据增量进行预估，验证当前数据库配置及归档策略的长期可行性。

待办 ​

1. 压测报告与接口逻辑确认

  • 明天与开发团队碰头，确认盘点任务状态更新接口的具体逻辑及底层表设计。——吕杰
  • 明天出具正式的压测性能测试报告，并补充未来数据量增长的风险分析过程。——吕杰

2. 数据增量评估与归档方案

  • 评估盘点任务表的长期数据增量，并补充冷数据迁移与归档方案。——宋洋

3. 代码 Review 重点项

  • 在代码 Review 阶段，重点评估盘点任务状态更新接口是否使用了唯一性索引。——李明非

4. 盘点机接口数据比对

  • 会后拉取盘点机接口地址，比对当前实际 TPS 与历史压测结果的差异。——宋洋、张建利

营销活动中心：SR 订单数据丢失与覆盖问题分析 ​

本次会议围绕 SR 订单写入数据丢失与覆盖问题展开，分析了异步组装导致列覆盖及限流重试失败等核心原因，并确定了后链路事件驱动改造、补数任务限流管控及完善人工巡检告警机制的解决方案。

小结 ​

1. SR 订单写入覆盖问题

  • 现象与原因定位：业务系统提交成功后 SR 端无数据，本质原因是出签退同步操作在极短时间内触发异步组装并发提交，且 Streamload 采用全字段更新导致同一条数据的相同列被覆盖。
  • 现有链路缺陷：当前消息驱动链路中，1 秒内多次操作会同时组装多条消息批量提交至 SR，引发列覆盖丢数；目前仅依赖定时任务跑批修复，无法根除隐患。
  • 后链路改造方案：将后链路由消息驱动改为事件驱动，写入时生成队列表按序组装数据，并将中间表存于 Mango 库，最终通过同步工具写入 SR 或 Doris，彻底消除覆盖风险。
  • 后续评审安排：技术方案已初步完成，待内部评审通过后拉取相关人员集中过会，重点评估是否有更优解并确认回归范围。

2. MQ 限流重试失败致数据丢失

  • 故障复盘：因 29 日大批量补数导致 MQ 限流，8:00 补数任务重试三次失败，致使 B 端退货明细表缺失 6 条签收数据（前端聚合查询显示 48 条，明细表实际 42 条）。
  • 根本原因剖析：补数任务高并发未控制流量，且原定于白天执行的业务任务加剧了限流概率，缺乏兜底措施与有效告警机制。
  • 解决方案制定：需调整补数执行时间至凌晨非业务高峰期，严格控制补数频率，并建立企微告警或每日巡检表机制，确保在业务发现前完成人工介入处理。

3. 排查规范与文档输出要求

  • 排查逻辑要求：禁止直接口头描述推测，须通过程序模拟推演验证结论，并在测试环境复现或画图清晰展示核心逻辑。
  • 文档输出规范：针对各问题需整理独立 Word/Excel 文档，前置入结论性说明（如影响单量、修复数量），后置入验证截图与详细排查过程。
  • 验证闭环要求：修复操作完成后必须对受影响数据进行逐条验证，确认数据完整性后方可关闭工单。

待办 ​

1. 问题文档输出

  • 整理 SR 订单写入覆盖问题的排查过程、解决方案及验证结果，输出 Word 或 Excel 文档并发送会议群。——张喜
  • 将 MQ 限流重试失败的问题梳理成文档，包含限流原因、影响单量、修复情况及验证截图，并提交早会汇报。——张喜

2. 补数任务管控

  • 修改补数任务的执行时间至凌晨 2 点，并严格控制补数频率以避免 MQ 限流。——张喜

3. 兜底与告警机制

  • 建立 MQ 消息发送失败的兜底机制，如企微告警或每日巡检表，确保能及时发现并人工介入处理。——张喜

4. 方案评审与回归

  • 明天上午参加代码走查及建新方案评审会，重点评估冷饮项目是否受本次改动影响并进行回归测试。——全体成员

关联与提示

  1. 同根因链新增切面：9.14营销活动中心 Scan Detail 丢失约 3 万条，根因是 catch 后中断赋值即发 MQ、消费确认先于落库；今日 SR 覆盖的根因是 1 秒内多次操作并发组装 + Streamload 全字段更新覆盖同列。两次形态不同但都指向"异步链路丢数靠事后跑批补"，说明该类缺陷尚未收口，后链路改造须一并验证确认时序与幂等，不能只验证数据能写入。

技术管理智能体：BRD 评审 MCP 能力改造（个人交付） ​

围绕「让 AI 工具仅依赖 MCP 完成 BRD 评审」推进，新增上传工具、修正长阻塞等待，并沉淀存量系统 MCP 改造方法论。

完成的功能与优化 ​

1. 新增 brd_review_upload MCP 工具，打通"上传→提交→评审"全链路 ✅

  • 背景：BRD 上传原为 REST 接口（POST /brd/file/upload），未封装为 MCP，导致 AI 工具无法端到端只依赖 MCP。新增工具接收 fileContentBase64 + originalFilename，落盘/存储后返回 filePath，供 brd_review_submit 直接使用；校验非空、扩展名（docx/pdf/md/txt）与 Base64 合法性，失败抛协议层 INVALID_PARAMS。
  • 实现要点：抽出公共存储/校验逻辑供流式上传与字节上传复用（BrdFileService.uploadBytes）；mcp.max-request-size 由 4MB 提升至 20MB 以容纳 Base64 大文件。
  • 涉及文件：BrdReviewMcpTools.java、BrdFileService.java、BrdFileServiceImpl.java、application.yml。

2. brd_review_wait 改为默认非阻塞，规避 Tool Hub 上游超时 ✅

  • 问题：tools/call 经 Tool Hub 转发存在上游请求超时（HUB_RUNTIME_MCP_UPSTREAM_TIMEOUT），而评审需 1–3 分钟；服务端在工具内同步阻塞等待，会在返回前被 Hub 判定超时而中断整次执行。
  • 方案：timeoutSeconds 默认由 25s 改为 0——单次调用立即返回任务当前进度，由 AI 反复轮询直至 status 为 COMPLETED/FAILED；MAX 保留 25s 供显式短暂等待。响应毫秒级返回，对任何网关/Hub 超时免疫。
  • 涉及文件：BrdReviewMcpTools.java。

3. 输出《存量系统 MCP 改造升级方案》 ✅

  • 以 BRD 评审 MCP 为首个落地案例，对照 Tool Hub V1.0 接入规范，沉淀"能力盘点→工具设计→身份鉴权→结果/错误分层→接入验收"标准化五步法，供其他存量系统改造直接复用。
  • 涉及文件：docs/存量系统 MCP 改造升级方案.md。

小结 ​

  • 把重复性专家动作封装为 MCP 工具是 AI 工具端到端编排的前提；只要有一环仍是 REST（如上传），AI 就得跨协议编排，接入门槛显著上升。
  • 长阻塞在经网关/Hub 转发的链路上不可行：工具内等待时间必须远小于上游超时，"立即返回 + 客户端轮询"是更稳的契约，也让单次响应与超时解耦。
  • 规范前置：Tool Hub 合规要点应在设计与发版两个环节各过一遍，避免上线前才发现身份注入、结果分层等硬性要求缺失。

待办 ​

  • 将 MCP 改造发版至 AI 工具实际指向的环境（UAT/生产），并在 Tool Hub 刷新该 MCP Server 工具清单，新契约才会对 AI 生效。——（待补充）
  • 修复 ai_call_record.user_id NOT NULL 导致的异步落库报错（不影响评审主流程，仅丢审计记录）。——（待补充）