2026-10-12 工作日志

物码早会

本次会议同步了系统测试进度与问题处理情况，明确了 UAT 测试范围简化策略，并敲定了 14 号下午的上线评审会时间及 15 号的上线计划。

小结

1. 整体测试进度与问题跟进

• 活动场景测试：当前测试通过率为 91%，剩余 10 个场景今日继续执行，目前无卡点。
• 盘点任务测试：进度达 99%，仅余一条用例需开发辅助开启定时任务，预计今日可测完。
• 积分兑换卡券测试：33 个场景因涉及模拟网络慢或兑换失败等异常场景无法执行，经与开发沟通确认不模拟则不再测试，该模块基本视为通过。
• 遗留问题处理：小智端滚动条 UI 显示重复问题正在处理；活动触发方式问题晓娜已验收且复测仍有问题，需持续跟进解决。

2. UAT 测试范围调整说明

• 范围简化决策：为避免业务二次测试，UAT 范围将与业务需求不符的门店维度部分进行简化。
• 重点验收内容：本次 UAT 将重点聚焦于盘点任务、下发积分及积分兑换环节。
• 门店维度限制说明：业务若后续改用经销商维度会导致历史数据无法融合清洗，故建议业务方不使用门店维度功能，仅使用盘点任务，暂不发放积分。

3. 移动端看板与数据一致性进展

• 移动端看板测试：环境已具备，本周 UAT 测试计划与大盘点任务合并至 14 日统一执行。
• 数据一致性修复：已沟通确认的解决方案均在按计划推进中，今日将与建新再次沟通营销活动中心 P1、P2 级问题的处理计划。

4. 监控与性能压测安排

• 监控问题排查：多个序号对应的问题已验证或处于开发/排查阶段。
  • 序号二：相关功能正在开发中。
  • 序号三：重复签收问题已于 10 月验证不存在。
  • 序号四：针对经销商财务失效导致盘点的问题已在 1015 版本解决。
  • 序号五、六：今日继续排查。
  • 序号六（新增）：上周一已沟通并解决，待发版后关闭。
• 性能压测规划：因本次为静默上线，优先保障功能测试，压测工作不一定在上线前全部完成。但鉴于业务对盘点任务的时效性要求，需单独对盘点任务场景进行压测，其他场景可不测。

5. 上线评审会与发布计划

• 评审会时间定档：定于 14 日下午 5 至 6 点进行上线评审会，请相关人员提前预留时间。
• 发布时间确认：初步计划于 15 日正式上线，届时将根据功能测试情况决定是否延后压测完成项。

待办

1. 测试推进

• 今天继续推进盘点任务剩余用例及积分兑换卡券场景的测试与开发沟通。——郑然然

2. 遗留问题与监控排查

• 今天与小智团队及开发沟通活动触发方式等遗留问题，争取当日解决。——郑然然
• 评估营销活动中心 P1 级问题优先级，协调建新及团队时间安排沟通会议。——邢健
• 今日继续排查监控部分的序号五、六问题，并跟踪序号二开发进度。——孙东栋

3. 压测与 UAT 准备

• 与开发沟通明确盘点任务场景的压测方案及其他场景的排除依据。——郑然然、吴菊
• 明天准备 UAT 测试用例和账号，并将 UAT 范围简化及门店维度使用说明通过邮件同步给业务方。——郑然然

4. 上线评审

• 在 14 日下午 5 至 6 点参加上线评审会。——全体成员

计费管理：钱包压测（压测评审会）

本次压测评审会针对红包系统 8 个核心接口展开，明确了压测通过标准与资源瓶颈问题，并要求重新调整低并发场景压测参数、补充性能分析报告及优化报告格式。

小结

1. 压测接口与场景规划

• 明确 8 个压测接口：涵盖同步红包记账流水、鸡蛋红包余额、本年统计查询、混合查询 5 个接口及钱包登录 2 个接口。
• 多事业部流量配比压测：同步记账流水按 1:2:10 比例（冷饮:椰奶:其他）传入不同事业部请求头进行阶梯式压测。
• 新增单接口独立压测：记账红包余额与本年统计为新增查询接口，不区分事业部，直接纳入混合查询场景统一压测。

2. 同步红包记账流水压测结果

• TPS 达标但 CPU 资源超标：整体 TPS 达 530，但压测过程中 CPU 最高达 99.64%，内存资源正常，断言全通过。
• 并发过高导致资源耗尽：当前并发约 500，远超实际处理能力，导致响应时间拉长且 CPU 满载，不符合压测通过标准。
  • 重新压测策略：将并发降至 100 左右，按 30/60/80/100 阶梯递增。
  • 停止阈值设定：当 CPU 达到 80% 时立即停止加压并记录最大 TPS。
• 确认前端展示对接状态：已确认该场景仅涉及前端的券资产展示，未接入领券功能，不影响核心业务逻辑验证。

3. 记账红包余额与本年统计压测结果

• 资源未超限且响应时间达标：TPS 未明显增长，CPU 在 79% 以内，响应时间符合预期，无需重新压测。
• 需补充数据库内存机制说明：数据库内存无波动且维持在高位，系腾讯数据库自身高性能机制所致，需在报告中写明原因。
  • 缓存命中分析：大部分查询走 Redis 缓存，未直接触发数据库 IO。
  • 腾讯 DB 机制说明：数据库内存持续高位属于其内部运行机制，非异常消耗。

4. 混合查询接口压测结果

• 大数据量下性能表现稳定：基于百万级红包流水与提现记录构造数据，TPS 达 1600~2800，CPU 占用 30%~40%，内存稳定。
• 压测过程符合预期：阶梯式加压过程中，各指标变化趋势合理，未发现异常波动或资源瓶颈。

5. H5 登录及身份票据压测结果

• 高 TPS 源于纯缓存处理：TPS 达 2941，因登录流程仅依赖 Redis 生成身份票据，未涉及数据库查询或其他资源消耗。
• 脚本有效性存疑待核实：虽理论逻辑无误，但需排查是否因脚本配置问题导致请求未真正打至服务端，需结合线上日志验证。

6. 压测通过标准与报告规范

• 明确硬性通过指标：CPU 和内存不得超过 80%，P95 响应时间不超过 500 毫秒，资源超标即视为压测不通过。
• 规范报告数据呈现：需补充各场景 TPS 对应的最大并发值及时间点，删除针对 ToC 生产环境的无效吞吐量计算。
  • 数据关联标注：每个场景需清晰标明压测对象及对应比例。
  • 小时级访问频次估算：根据实测 TPS 推算每小时可支撑的请求频次并写入报告末尾。

待办

1. 压测执行与验证

• 重新执行同步红包记账流水场景的阶梯式压测，将并发控制在 100 左右，并在 CPU 达 80% 时记录最大 TPS。——丁聪
• 排查 H5 登录及身份票据接口的压测脚本有效性，验证请求是否真实到达服务端。——王军

2. 报告补充与调整

• 在报告中补充记账红包余额接口数据库内存无波动的原因说明，解释腾讯 DB 的高位内存机制及缓存命中情况。——王军
• 调整压测报告格式，明确标注各场景压测对象与比例，补充关键时间点 TPS 数据，并删除无效的 ToC 生产环境吞吐量计算。——丁聪

3. 结论同步

• 尽快完成报告调整后重新发送，并附上明确的压测结论。——全体成员

营销活动中心-奶酪：UAT 环境资源评估

• 资源申请评估通过：营销活动中心-奶酪项目增加 UAT 环境资源的申请经评估通过。

营销活动中心：CSV 数据更新技术方案

• 方案沟通计划：玉平需与学通沟通使用 CSV 进行数据更新的技术方案设计，并形成 SOP。

营销活动中心：积分逆向（人员类型优化需求评审）

本次会议围绕人员类型优化需求展开，明确了前端仅传人员编码、后端通过主数据反查匹配并统一存值的技术方案，同时指出了数据治理缺失问题，决定暂缓异步处理方案，需联合高层推动数据治理。

小结

1. 人员类型优化需求与接口调整

• 优化背景：当前前端直接上传人员类型，与主数据对应不上，导致业务校验困难，需调整为后端根据人员编码反查主数据匹配存储。
• 涉及场景调整：本次改动主要涉及以下业务场景的接口逻辑。
  • 查证及签收：前端仅传人员编码，后端匹配主数据后按 3 级类型存储为人员类型。
  • 盘点：前端仅传人员编码，后端匹配主数据后按 3 级类型存储为盘点人员类型。
  • B 端出货/活动签收：活动配置与激励对象均按主数据职务编码匹配，确保新老活动规则统一。
• 前端无感改造：前端无需修改必填非必填字段，仅需传人员编码；后端在返回任务列表时直接过滤，不再新增查询接口。
• 数据时效性风险：主数据同步存在延迟，若主数据未同步则无法获取职位信息，原拟采用异步处理方案被否决，要求技术层面设计时彻底杜绝异步数据不同步情况。

2. 人员分类映射与数据治理问题

• 三层分类现状：目前业务需求将人员划分为三类以支持精细化运营。
  • 第一类：内部人员与外部人员的大类划分。
  • 第二类：外部人员的集合分类（如门店人员、经销商人员等）。
  • 第三类：最细粒度职务角色（如导购、店主、经销商司机等）。
• 数据源不一致：SFA/DMS 系统的人员职位使用自定义枚举描述，而主数据重新定义了人员属性，导致两边对同一人的语义不一致，无法跨系统通用圈选。
• 架构规划偏离预警：营销活动中心自行维护人员分类映射，偏离了渠道域"销售团队中心管人"的权威数据源规划，存在非标定制化累积导致架构退化风险。

3. 后续行动与治理推进

• 差异梳理与测试准备：需梳理 DMS 与主数据人员在职位上的具体差异点，以便后续测试验证。
• 数据治理联合推进：4 月份已提过但被搁置的数据治理事项需再次发起，由渠道域与数据智能团队联合向高层汇报，明确主数据或销售团队中心作为权威数据源进行统一定义与维护。
• 技术方案重新评估：针对人员信息不同步的异常处理，产品侧需从业务层面寻找更好的替代方案，技术侧拒绝接收无法把控的异步方案。

待办

• 梳理 DMS 与主数据人员在职位上的具体差异点，以便后续测试验证。——南林
• 补充人员类型调整涉及的页面截图与具体操作范围说明。——南林
• 约集成方开会讨论积分逆向流程配合事宜（后天上午）。——刘同学
• 将人员类型数据治理事项再次提报给王老师及高层领导拍板定夺。——南林、杰西
• 重新评估人员信息不同步的业务处理方案，坚决杜绝异步数据不同步的设计。——南林、刘同学

营销活动中心/计费管理：积分逆向需求评审

本次会议主要围绕数据口径统一、积分逆向扣减方案及积分过期预警等议题展开，明确了多端接口必传策略，并详细梳理了营销活动与积分中心的正向及逆向改动点。

小结

1. 数据源不一致与接口协同

• 统一多端接口必传策略：为解决各端数据不一致问题，明确所有接口均须保持必填协议，前端直接传递数据，后端不再自行查库加工。
• SFA 端特殊处理方案：针对 SFA 端数据质量不全且查库受限的问题，提供临时特殊接口供其先查编码再传入，后续随主数据治理完善后替换为直连主数据。

2. 营销活动中心逆向扣减方案

• 退货扣减与二次发放逻辑：门店发生退货或异常签收时自动扣减原发放积分并记录明细，同时推给计费中心执行扣费；扣减后支持门店再次签收时正常发放积分。
• 活动已发放积分处理：发生退货扣减后，需将对应积分加回总积分池并从活动已发放总额中扣除，确保池子逻辑清晰可追溯。
• 计费中心逆向处理规则：不计较积分是否过期或未使用，只要收到退货通知即正常发起扣减请求；若余额不足则允许扣成负数，由计费中心按顺序抵扣。

3. 积分中心正向维度调整

• 增加经销商维度查询与展示：在积分池、变动记录、兑换记录及钱包 H5 页面中增加经销商维度，支持基于人、活动、门店、经销商的多维下钻查看。
• 积分商城页面交互优化：优先选择门店再联动选择经销商，若仅有一个经销商则默认带出无需选择，确保跨系统跳转时的默认值准确。
• 接口维度扩展：汇总、冻结、明细列表及余额查询等核心接口均增加经销商编码作为非必填字段，支持指定经销商维度的精准查询。

4. 积分失效预警与过期处理

• 建立过期积分池：通过定时任务将超过 90 天有效期的积分转入独立的过期积分池，该池不可用于日常兑换但可作为逆向扣减的抵扣来源。
• 冻结积分时效处理：冻结期间若履约成功则正常扣减消耗；若履约失败解冻时未过期则恢复可用，若解冻时已过期则转入过期池。
• 过期预警机制：通过定时任务扫描即将失效的积分，按 1 天、7 天、15 天三个档位统计最优先级批次，打包上传至 COS 供调用方获取短信或站内信预警。

5. 积分中心逆向扣减机制

• 逆向记账流水管理：新增逆向记账流水功能，记录流水单号、关联的正向单号及扣减状态；正向流水需标记是否有逆向扣减并可联动查看。
• 记账户与池子字段扩展：在用户记账户和积分池中新增"已扣减积分"与"负积分"字段，用于直观展示逆向扣减结果及余额不足情况。
• 负积分抵扣原则：允许产生负数积分并在前端展示提示；当有正向积分入账时，优先抵扣对应的所有负积分。

6. 注销与停业场景补充

• 用户账号注销场景：业务需在 MRD 中明确注销场景下的积分扣减逻辑，建议单独定义接口类型，避免复用通用逆向记账流水接口。
• 门店停业扣减提醒：云商后台操作关闭门店时需先校验该门店是否存有未使用积分，若有则通过短信平台向操作人员发送警告提醒。
• 经销商注销待确认：因涉及主数据财务权限，经销商注销后的积分失效逻辑及提醒方式暂不明确，需后续与业务进一步沟通确认。

7. 卡券批量核销限制

• 同经销商核销限制：钱包卡券批量生成核销码时，强制要求所选券必须属于同一经销商，禁止跨经销商合并生成核销码。
• 全选按钮逻辑规范：点击全选时默认取第一张券所属经销商进行筛选，切换选中其他券后再次全选将重新按新选中的经销商范围过滤。

待办

1. 产品逻辑讨论与确认

• 针对 SFA 端查不到数据的中断流程及特殊场景产品逻辑，拉通产品团队进行讨论。——蒋老师、郑然
• 确认发钱（现金）逆向扣减逻辑是否与积分逆向一并实现，评估工作量。——郑然
• 与财务团队沟通确认积分失效相关的业务规则。——蒋老师
• 与业务沟通确认门店/经销商注销场景下的积分失效提醒方式（如短信渠道）。——赵敏

2. 方案与页面补全

• 检查 B 端出货明细表所需调整的字段，确保包含退货及积分扣减相关信息。——郑然
• 补全营销活动中心活动配置中关于已退积分扣减的逻辑描述及公式说明。——郑然
• 补全积分商城页面可选经销商范围的传值逻辑说明。——郑然
• 调整积分商城页面选择顺序为优先选择门店，再联动选择经销商。——郑然
• 在 PC 端报表及小程序列表中补充积分扣减明细的展示字段。——郑然

3. 测试准备

• 整理并输出本次需求的所有改动点清单，以便测试人员开展测试。——郑然

营销活动中心：盘点任务仓库维度下发需求评审

本次会议明确了盘点任务支持按仓库维度下发的需求，确立了盘点任务仅支持"经销商维度"与"门店维度"二选一的逻辑，并约定后续修改产品方案、评估工作量及安排测试。

小结

1. 需求明确与范围界定

• 支持仓库维度下发：盘点任务需支持下发到仓库维度，且任务下发需同时告知门店与仓库。
• 前端场景适配：前端配置时若选择其他位置或仓库，后端统一按当前经销商编码查询任务；若前端选择特定门店（如 A 类店），则只针对该门店查询。
• 业务逻辑确认：盘点任务下发维度由后端配置决定，前端仅需根据配置的维度进行筛选和展示。

2. 盘点逻辑与状态流转

• 盘点维度二选一：盘点任务仅支持两种下发模式。
  • 经销商维度：未指定门店时生效，该经销商下所有门店、仓库及其他位置均可查看并参与盘点；任一位置结束任务即视为整体结束。
  • 门店维度：指定特定门店时生效，仅限所选门店查看并参与盘点；结束任务仅影响该门店维度的任务状态。
• 子任务状态隔离：基于门店维度的任务在按经销商维度查询时应不可见，避免跨维度误操作导致任务提前结束。
• 活动核减关联调整：盘点核检关联活动的逻辑保持不变，仅基于门店维度的盘点会去参与活动核减。

3. 技术方案与排期

• 链路确认与联调：需张喜与技术团队确认接口链路是否支持按不同维度查询与提交，并在改动后共同测试验证。
• 方案评审与排期：南林负责今日输出产品方案，明日内部评审并拉通技术与测试团队；金策团队评估改动量并给出排期。

待办

• 今日输出盘点任务支持仓库维度的产品方案原型，增加"所有位置均可盘"与"只能在门店盘"的选项标识。——南林
• 明天内部评审产品方案，并拉通王琪、张喜及测试团队共同评审确认。——南林、王琪、张喜
• 评估本次需求的改动量，确认技术可行性并给出上线排期。——金策

营销活动中心：技术评审（中奖明细表数据修正与查询接口优化）

本次会议评审了消费者中奖明细表数据修正与清洗方案及智慧门店查询接口优化方案，明确了数据修复范围、执行策略、备份规范及后续测试上线计划。

小结

1. 消费者中奖明细表数据修正方案

• 字段取值修正：针对产品批次和生产日期字段，将取值从无时分秒的 tag product in time 改为有时分秒的对应码表字段；生产年月取值保持不变且不受影响。
• 历史数据清洗：需对全表异常数据进行清洗，复用现有定时任务逻辑实现并发处理。
  • 处理流程：定时任务按时间分片（默认 30 线程并发，20 分钟/分片），通过游标分页避免数据重复，从 MongoDB 查码表获取信息后组装数据，使用 Stream Load 更新目标表。
  • 更新策略：因全量更新耗时较长（约 11 天），明确不更新 update_time 字段，由数据中台手动重新刷历史数据。

2. 数据修复执行规范与范围确认

• 数据影响范围：明确清洗范围为消费者中奖时间大于等于 2026 年 1 月 1 日且小于等于发版时间的数据，需在技术方案中补充该范围及数据量评估。
• 备份与清理规范：更新前必须对全表进行备份，推荐使用 CREATE TABLE AS SELECT 命令，执行后需删除备份表。
• 大文件上传优化：针对 4000 万数据的批量更新，放弃内存直接加载方式，改为脚本在本地生成 CSV 或 JSON 文件，再上传至可连通 SR 的服务器进行 Stream Load 导入。

3. 智慧门店查询接口优化方案

• 废弃无效函数：移除接口中调用多次的无效函数，该函数内部执行了冗余的盘点明细查询操作，直接返回当前时间即可。
• 增加分区过滤：为查询添加分区键过滤条件，利用现有的扫码时间参数限制 31 天内的数据查询，提升查询效率。
• 备选索引方案：当前暂不添加索引，若上述两项优化效果不理想，后续考虑使用 StarRocks 不阻塞加索引功能并评估对写入的影响。

待办

• 在技术方案中补充数据修复的目标、影响范围（2026 年 1 月 1 日至发版时间）及数据量评估。——潘玉平
• 确认本次数据修复执行时是否传参更新 update_time，并在方案中固定执行参数。——潘玉平
• 确认 4000 万数据分批更新的批次大小（如 100 万或 500 万），并编写脚本在本地生成文件上传至服务器执行。——潘玉平、朱学通
• 统计当前消费者中奖明细表总数据量，并在更新前完成全表备份。——潘玉平
• 将全表备份命令及备份表删除操作补充至技术方案中。——潘玉平
• 待代码修改并通过测试后，走上线评审流程于下周四发版。——潘玉平