Work for YILI

Appearance

2026-09-22 工作日志 ​

物码早会 ​

发言人：李亚洲、孙东栋、陈思、王琪等

本次会议同步了智慧门店与营销中心数据差异排查进展、财务系统数据修复情况，以及积分正逆向合并上线的整体排期计划。

一、智慧门店与营销中心数据进展 ​

1. 门店与经销商数据差异排查

  • 主数据系统视图存在重复数据：经排查，门店与经销商关系差异源于主数据系统提供给小智的数据视图存在重复数据，对小智系统本身无影响，但会导致一致性比对产生差异。
  • 主数据端需优化视图逻辑：会议明确主数据端需在今日完成视图逻辑的优化，以解决数据差异问题。

2. 内部人员接口与历史数据清洗

  • 内部人员接口技术方案评审：小智系统今日将完成内部人员接口相关技术方案的评审，评审结果需同步给陈思以便后续排期。
  • 营销活动中心历史数据清洗完成：昨日已完成51条导购与门店差异数据的历史清洗，P0级5个主题域一致性问题中，除5段围栏和经销商围栏放开同步范围需求外，其余数据均已对齐。

二、财务系统数据修复进展 ​

1. 财务失效无断维控数据修复

  • 跟进财务失效无断维控数据修复情况：今日将重点查看财务失效无断维控的数据修复情况。

2. 血管控器数据排查

  • 跟进血管控器数据情况：今日将继续跟进血管控器的数据情况，以确认相关问题是否有结论。

三、积分正逆向合并上线排期对齐 ​

1. 整体上线计划与目标时间

  • 积分正逆向合并上线排期：积分正向与逆向功能将合并上线，整体计划已拉通至12月17日，该时间节点正好为SFA的发版日。
  • 10.15版本测试与上线安排：10.15版本目前正常测试中，后续将先上线涉及经销商维度调整及兑换商品选经销商的部分，并与逆向功能一起上线。

2. 各端系统改造与工作量评估

  • 各端系统需更新工作量评估：涉及各端系统调整项的团队需将自身工作量填入整体排期表格中，目前卡券与计费端已完成填写。
  • 各端产品需确认资源匹配：各端产品需核对排期时间是否与自身资源匹配，该排期表将由会议组织者统一发送给各端确认。

四、后续工作要求 ​

1. 各端系统排期反馈

  • 各端需尽快更新并反馈排期表：智慧门店与黑名单等各端系统需尽快更新排期表，今日需完成整体排期表的整理与反馈。

2. 整体进度推进要求

  • 加速推进评估与排期工作：会议强调需加速推进各端改造点评估及整体时间排期，目前进度已比原计划晚一天。

五、待办事项 ​

1. 主数据端

  • 优化主数据系统的视图逻辑，解决小智数据视图重复问题。

2. 小智

  • 完成内部人员接口相关技术方案的评审，并将结果同步给陈思。

3. 孙东栋

  • 查看财务失效无断维控的数据修复情况。
  • 跟进血管控器的数据情况。

4. 王琪

  • 跟进并解决王琪相关的数据差异问题。

5. 各端系统

  • 将各端系统调整的工作项填入整体排期表格中。
  • 更新并反馈整体排期表。

6. 各端产品

  • 核对排期时间与自身资源是否匹配。

7. 李亚洲

  • 将整理好的排期表发送给各端确认。

营销活动中心：1015版本接口压测方案评审 ​

发言人：吕杰、郑然然、邱毅、李明非、任同超等11人

本次会议针对1015版本相关接口梳理了压测范围，明确了积分活动、盘点任务及积分商城各接口的压测策略与TPS评估标准，并决定建立结构化的压测数据库。

一、压测数据库与报告规范 ​

会议首先明确了压测接口清单的维护规范，要求将非结构化的压测数据统一结构化，便于后续追溯与评估。

1. 压测报告结构化规范 ​

  • 建立压测数据库：要求将散落在Word文档中的压测报告结构化至Excel表格中，作为压测分析数据库统一管理。
  • 明确表格字段要求：Excel表格需包含功能板块、接口说明、所属系统、事业部、调用方、TPS、P90响应耗时（单位毫秒）等字段。
  • 增加版本与文档关联：表格需增加接口创建时间或版本号字段，以便区分历史记录；同时需将测试报告文档编号或超链接插入表格，实现与业务需求（MRD/PRD）的关联追溯。

二、积分活动相关接口压测评估 ​

针对本次新增的积分类型，会议对抽奖、查码及盘点等核心接口的压测必要性进行了评估。

1. 抽奖与查码接口 ​

  • 无需重新压测：抽奖接口与查码接口仅新增了积分类型字段，底层逻辑及业务调用量、用户量均未发生变化，决定无需重新压测。
  • 历史压测数据达标：该接口此前已通过底座架构升级解决了性能瓶颈，历史压测TPS已达680，远高于预估的480，满足业务需求。

2. 盘点接口 ​

  • 无需压测：盘点接口此前已做过压测，本次仅新增了关联盘点任务ID字段，逻辑无实质变化，决定无需重新压测。

三、盘点任务相关接口压测评估 ​

会议详细梳理了盘点任务从创建、查询到结束的业务链路，并据此确定了各接口的压测策略。

1. 创建盘点任务接口 ​

  • 无需压测：该接口仅在活动中心由总部、大区等后台人员调用，属于极低频操作，且正常测试中的接口响应时间已确认正常，决定无需压测。

2. 分页查询盘点任务接口 ​

  • 需压测：该接口由SFA、小智及导购等前端人员在进入盘点页面时调用，使用群体广、调用频率高，决定需要进行压测。

3. 盘点任务详情页接口 ​

  • 需压测：包含查询关联产品列表、分页查询及查询关联门店列表三个接口，在点击进入盘点任务详情页时调用，调用量一致且频率较高，决定需要进行压测。

4. 更新盘点任务状态接口 ​

  • 需压测：该接口在门店端点击开始或结束盘点时调用，存在并发情况，决定需要进行压测。
  • TPS评估标准：因缺乏实际业务数据，需先进行探索性压测，最终结果需小于或等于盘点接口的TPS；若压测结果远低于盘点接口，需与产品确认实际业务量。

四、积分商城相关接口压测评估 ​

针对积分商城及卡券兑换链路，会议明确了对外接口与内部业务接口的压测边界。

1. 对外接口评估 ​

  • 查询供货关系接口：确认存在"查询门店与经销商的供货关系"对外接口，但该接口因后续需求变更暂不上线，本次无需压测。

2. 内部业务接口评估 ​

  • 获取兑换品列表接口需压测：该接口为积分商城小程序首页展示接口，属于内部业务接口，需按营销活动中心的人员量级标准进行压测。
  • 排除涉及第三方的接口：点击兑换时调用的计费与卡券接口，因压力会直接打到其他服务器，不属于本次压测范围，已将其从清单中划掉。

五、待办事项 ​

1. 吕杰

  • 将历史压测报告补充至Excel表格中，并完善TPS、P90响应耗时、调用方及事业部等结构化字段。
  • 确认创建盘点任务接口在生产环境的历史调用频次及响应时间数据，并补充至压测清单中。
  • 对分页查询盘点任务接口、盘点任务详情页接口及更新盘点任务状态接口进行探索性压测，并输出压测结果。
  • 对获取兑换品列表接口按营销活动中心的人员量级标准进行压测，并输出压测结果。
  • 压测结果输出后，结合业务逻辑重新评估各接口TPS是否满足需求。

营销活动中心：B端出货明细表需求评审 ​

发言人：余建新、张喜、吴南林、吕杰、王建朝等11人

本次会议明确了B端出货明细表字段调整需求，重点探讨了系统出货场景的判定逻辑，并针对历史数据的修复方案及可行性进行了详细评估。

一、B端出货明细表字段调整需求 ​

会议首先明确了本次需求的核心背景，并确定了本期优先上线的字段调整范围。

1. 字段定义与合并 ​

  • 合并重复字段：B端出货明细表中"B端出货门店"与"出货首选门店"两个字段语义重复且数据基本一致，业务方要求将两者进行合并。

2. 本期上线范围 ​

  • 优先保障4和5字段：本次需求共包含5个改动点，因测试与开发时间紧张，本期仅优先保障第4和第5个字段的调整与上线。
  • 调整地址出库逻辑：针对仓库盘点签收、盘点异常签收、查证签收及查证异常签收等场景，需将其纳入出库次数统计，并调整"第几次出库"的判定逻辑。

二、系统出货场景判定逻辑 ​

针对B端出货及退货场景，会议重点讨论了"系统出货"与"沿用原出货场景"的判定标准。

1. 系统出货判定标准 ​

  • 经销商在库直接签收：若产品状态为经销商在库，且未发生过实际出货动作，直接进行盘点或查证签收的，判定为系统出货。
  • 手动退货后重新签收：若产品已出货至门店，经手动退货后，在仓库或门店再次被发现并进行盘点或查证签收的，同样判定为系统出货。

2. 沿用原出货场景判定标准 ​

  • 系统退货后重新签收：若产品已出货且完成签收，因门店不一致等原因触发系统自动退货（如查证或盘点异常签收），随后在同一动作中生成新的签收记录时，新记录的出货场景必须与原出货场景保持一致。
  • 自主签收后重新签收：若产品首次为自主签收（即BC营销出货），随后在门店或仓库再次进行查证或盘点签收的，新记录同样需保持BC营销出货的场景不变。

三、历史数据修复评估 ​

1. 修复方案探讨 ​

  • 【提问人】宋洋：对于历史数据，是否可以通过对比时间差来识别同一次操作生成的退签记录？
  • 【回答人】张喜：由于系统保存时虽使用事务但记录间无强关联，单纯依靠时间差不够严谨，且当前SQL脚本无法精准定位"上一条"关联记录，必须编写代码进行遍历循环才能修复。

2. 修复可行性评估 ​

  • 数据量庞大：根据统计，自8月份以来需要修复的数据量高达200多万条，修复工作量巨大。
  • 开发排期冲突：编写修复代码并经过评审及测试，在9月29日的截止时间前无法完成。
  • 暂缓修复决策：鉴于时间限制，决定暂不通过技术手段批量修复历史数据，后续将与业务方沟通是否采用手动筛选等替代方案过渡。

四、待办事项 ​

1. 吴南林

  • 完善需求文档，补充系统出货及退货场景的详细逻辑说明。

2. 宋洋

  • 下午与张喜对齐数据修复方案，评估是否能在月底前完成历史数据修复。

3. 余建新

  • 若代码修复方案不可行，需与业务方沟通9月份历史数据的替代处理方案。

券中心工时评估 ​

后端、测试、前端、部署4个角色共核减 2 人天。跨系统对接联调不确定性高，建议根据实际情况酌情调整。

券中心工时评估（二） ​

后端、测试2个角色共核减 16 人天。跨系统对接联调不确定性高，建议根据实际情况酌情调整。

券中心工时评估（三） ​

后端、测试2个角色共核减 1.5 人天。

营销活动中心技术评审 ​

一、报表导出方案评审 ​

1. 导出限制提升与多文件拆分 ​

  • 统一导出上限至200万条：业务侧要求将报表导出限制统一提升至200万条，目前前端已做限制，后端需配合调整。
  • 超量自动拆分文件：针对Excel单Sheet及文件打开限制，系统将超过100万条的数据自动拆分为多个文件，目前B端出货明细表等已实现该逻辑，消费者中奖明细表需补充拆分逻辑。
  • 多文件下载机制：导出完成后，系统支持用户一次性触发并同时下载多个拆分后的文件，该下载机制已具备无需额外开发。

2. 流式导出与代码重构 ​

  • 引入流式查询：为解决流向异常明细表分页查询耗时过长及提升200万条导出效率的问题，需将查询方式优化为流式导出。
  • 封装公共工具类：在公共类中新增流式导出工具类，统一处理权限校验、文件创建、批次写入及上传逻辑，后续其他报表可直接复用。
  • 数据组装逻辑迁移：将原放置在Service层中的异常流向数据组装与转换逻辑，迁移至对应的实体类实现类中。
  • 增加联合组件排序：为保证流式导出数据的一致性并避免分页查询时出现重复数据，导出时必须增加联合组件的排序控制。

3. 业务需求与中台替代方案 ​

  • 业务侧真实需求未明：业务方坚持导出200万条数据，但未明确具体用途，且数据量过大导致本地电脑难以打开。
  • 建议中台自助分析替代：鉴于相关报表数据已抽取至数据中台，建议引导业务方使用数据中台的自助分析功能替代大批量导出。
  • 后续确认与培训安排：需由相关人员与业务侧建英老师确认真实需求，若中台自助分析功能可满足需求，则协调中台团队开展培训。

二、RocketMQ日志优化方案 ​

1. 磁盘写满风险 ​

  • 多Topic告警导致磁盘占满：receive服务在绕开MQ消费时，若同一消费组存在多个Topic会持续打印告警日志，在4G磁盘限制下会导致磁盘写满并致使节点被剔除。

2. 日志输出方案调整 ​

  • 日志输出至控制台：为避免大量日志写满系统磁盘，决定优先将RocketMQ日志配置修改为输出至控制台。
  • 线下验证后再上线：需在线下环境自行搭建程序消费消息，验证日志成功输出至控制台后，再交由云平台协助进行生产环境配置。
  • 撤回原有工单：原定在本地磁盘限制日志大小与数量的工单方案因不符合系统约束被撤回，待控制台验证通过后再行处理。

三、待办事项 ​

  • 在PRD需求文档中备注报表导出采用多文件方案，并指导测试按多文件逻辑进行验证。 ——潘玉平
  • 与业务侧建英老师确认导出200万条数据的真实需求，并探讨使用中台自助分析替代的可能性。
  • 若中台自助分析能满足业务需求，协调中台团队开展相关培训。
  • 线下搭建程序验证RocketMQ日志输出至控制台的可行性，验证通过后再找云平台配置。