2026-08-11 工作日报
今日工作概述
今日参加 4 场会议，主线是「线上问题集中止血」与「技术体系收口」并行推进：稳定性问题集中爆发——data 库每日 8:00–9:30 性能瓶颈、电子围栏新功能上线即把 DB CPU 打满至 100%、806 版本 300+ 条人员编码错传，均给出"临时止血 + 长期优化"双层方案；同时体系化推进数据一致性治理（血缘追踪专项、云商/智慧门店已修复）、"奶酪"活动测试规范固化（流向查证/盘点/作弊报表）、积分活动技术选型收敛（新业务迁 PG，弃用"老活动"MySQL）。一个关键信号：电子围栏（属"奶酪"体系）的 CPU 打满，与昨日潘玉平将"奶酪"服务纳入生产改造清单形成呼应——新功能密集上线期，"上线即压垮"正从个案变成系统性压力。
一、项目进展与数据一致性同步会（治理主线）
进展与数据一致性
- 需求：B 端营销助手业务已同意、待签字发版；移动端看板本周内评审；应用中心"盘点任务""会员积分"整合下版本。
- 数据一致性：智慧门店切换数据查询服务解决历史差异；云商修复主数据推送未更新问题；营销活动中心处理高邮问题；数据血缘关系由余建新团队本周梳理排期。
- 其他：data 库 8:00–9:30 性能瓶颈（张喜排查、张建利记录）；技术方案需与产品方案对齐、新老接口兼容前置评审。
待办汇总
- [ ] 应用中心"盘点任务""会员积分"需求拆分细化后群通知、统一发布 — @刘晓娜
- [ ] 今日完成数据修复后质量核对并确认是否可用 — @邢健
- [ ] 协调电子围栏团队，跟进功能/接口问题排期 — @余建新
- [ ] 本周内梳理并排期解决数据血缘关系 — @余建新
- [ ] 跟进 data 库性能瓶颈定位与解决 — @张喜
- [ ] 将 data 库性能问题记录在案 — @张建利
二、"奶酪"活动测试范围评审会（测试规范）
配置规则与测试要点
- 配置：底座用"奶酪"数据替换回归；系统配置仅留计费/营销活动中心/基础底座，移除卡券。
- 压测：活动侧抽奖/流向查证/盘点对外接口专项压测；底座性能瓶颈走架构升级后专项压测。
- 规则：查证字段配置预置消费者/非消费者两条内置规则（可编辑显隐、不可改名称/优先级/事业部）；异常判断规则预置经销商围栏/判断门店仓库两条（仅查看不可增删改禁）。
- 报表：查证明细/流向异常做全量验证（补"扫码工具"字段说明）；作弊明细需与业务方确认级别（中转箱/袋子）；盘点统计表汇总逻辑复杂，需线下与开发确认补 PRD。
待办汇总
- [ ] PRD 明确"查证字段配置""异常判断规则"内置规则详情（名称/编码/优先级） — @吴南林
- [ ] PRD 补充"盘点统计表"数据聚合逻辑说明 — @吴南林
- [ ] PRD 明确"作弊明细表"各字段必传/非必传属性 — @吴南林
- [ ] 与开发确认"盘点统计表"汇总逻辑实现方式 — @吴南林
- [ ] 与 SFA 确认"作弊明细表"涉及码的级别及表现形式 — @吴南林
- [ ] 更新"查证字段配置"测试用例：移除创建起止时间查询、移除启/禁用 — @陈晨
- [ ] "查证明细表""流向异常明细表"导出上限 50 万 → 300 万 — @陈晨
- [ ] "作弊明细表"用例补必传/非必传验证 — @陈晨
- [ ] "盘点统计表"用例补汇总逻辑验证 — @陈晨
三、电子围栏 CPU 过高问题及数据修复方案会（稳定性止血）
问题与方案
- 问题根源：电子围栏扫码核验串货规则未命中索引→查询慢；批量出货单并发时 DB CPU 瞬间打满 100%。
- 临时方案：调用方（报表处理服务）加 Redis 临时缓存（首查落库、后续命中）。
- 长期探讨：当前订单落库后批量校验单码造成"堰塞湖"，讨论改扫码即时校验，需研究 PRD/历史需求确认可行性。
- 查询逻辑：销售区域用 LIKE 模糊匹配（兼容旧版），大数据量扫父级区域低效，是瓶颈之一。
- 数据修复：806 版本终端误将"员工编码"传为"手机号"，约 300+ 条查证明细表异常；方案=预检 SQL 定位 + UPDATE 修正（联合条件保准确）。
待办汇总
- [ ] 调用方增加 Redis 缓存，缓解 DB 瞬时高并发压力 — @宋洋
- [ ] 梳理串货校验整体业务流程并制作流程图，评估长期优化可行性 — @宋洋 @王建朝
- [ ] 评估 LIKE 查询优化为 EQ 精确查询的可行性并补充代码 — @郝梓斐
- [ ] 评估并移除无业务调用的旧版 SQL（如第 7.5 部分） — @郝梓斐
- [ ] 执行人员编码修复方案，将 300+ 条手机号修正为正确员工编码 — @潘玉平
四、积分活动技术方案评审会（技术栈收敛）
功能方案与技术选型
- 激励规则：活动编辑页新增"激励规则描述"模块（DB 加字段存规则描述）。
- 排他性校验：同商品同时间段仅匹配一个活动，维度=时间/商品·品牌·生产日期/激励类型，作用于"正式"且未开始/进行中活动。
- 盘点任务：新管理功能（列表/创建/执行状态），独立主表+明细表。
- 选型关键：新业务（门店积分）应迁移至统一技术底座 PG，弃用"老活动"MySQL，实现技术栈收敛与长期维护；盘点任务改用 PG 重新设计。
待办汇总
- [ ] 盘点任务不再用 MySQL，改 PG 并重新设计技术方案 — @粱健
- [ ] 新表主表/从表均含创建时间、更新时间等审计字段 — @粱健
- [ ] 与宋阳对齐新功能接入 PG 底座，并向邱毅汇报 — @李明非
- [ ] 与粱健/邱毅/宋洋对齐并确定最终技术方案 — @李明非
今日待办汇总
高优先级（今日截止关键路径）
- [ ] 邢健今日完成数据修复后质量核对、确认可用
- [ ] 潘玉平执行 300+ 条人员编码修复（手机号→员工编码）
- [ ] 张喜跟进 data 库 8:00–9:30 性能瓶颈定位
- [ ] 刘晓娜应用中心"盘点任务""会员积分"需求拆分细化后群通知
- [ ] 余建新协调电子围栏团队排期 + 本周梳理数据血缘关系
中优先级（规划/持续跟进）
- [ ] 宋洋加 Redis 缓存 + 与王建朝画串货校验流程图；郝梓斐评估 LIKE→EQ 并移除旧 SQL
- [ ] 吴南林 PRD 三处完善（内置规则/盘点统计聚合/作弊必传）+ 与开发/SFA 确认
- [ ] 陈晨更新测试用例（查证字段/导出 300 万/作弊/盘点表）
- [ ] 李明非与宋阳对齐 PG 接入并向邱毅汇报；粱健盘点任务改 PG 重设计
关键时间节点
| 时间 | 事项 |
|---|---|
| 今日 | 邢健数据修复质量核对；潘玉平人员编码修复执行；张喜 data 库排查 |
| 本周内 | 移动端看板评审；余建新数据血缘关系梳理排期；刘晓娜应用中心需求发布 |
| 规划中 | 李明非与宋阳对齐 PG 接入；粱健盘点任务 PG 重设计；电子围栏长期改扫码即时校验 |
明日计划
- 稳定性止血跟进：确认潘玉平 300+ 条人员编码修复执行与结果；邢健数据修复质量核对结论；张喜 data 库瓶颈初步定位。
- 电子围栏优化启动：推动宋洋 Redis 缓存落地 + 与王建朝产出串货校验流程图；郝梓斐 LIKE→EQ 评估排期。
- "奶酪"活动测试推进：跟进吴南林 PRD 三处完善、陈晨测试用例更新；确认盘点统计表汇总逻辑与开发对齐。
- 技术栈收敛启动：推动李明非与宋阳对齐 PG 接入方案并向邱毅汇报；粱健盘点任务 PG 重设计初稿。
- 数据治理：余建新数据血缘关系梳理排期、电子围栏团队接口问题跟进。
工作思考
「上线不是终点，是压力测试的开始。」
今天四场会，三场在救火、一场在收口，而救火的那三场恰好共用一个底层逻辑：新功能密集上线后，被"上线即打满"反噬。电子围栏把 DB CPU 打到 100%、data 库每天早高峰瓶颈、806 版本人员编码错传——它们不是孤立 bug，而是"上线期系统性压力"的不同切面。最值得记的是电子围栏这场和昨天"优雅停机"会形成了闭环：潘玉平昨天刚把"奶酪"服务纳入生产改造清单，今天它就爆出 CPU 打满。这说明"奶酪"体系（电子围栏属其范围）正是当前压力最集中的地方，昨天埋的清单今天就被验证不是多此一举。
另一层是"临时止血"与"长期架构"必须同时排上日程，否则会反复救火：电子围栏的 Redis 缓存是止血，但"改扫码即时校验替代订单落库后批量校验的堰塞湖"才是根治——今天把它写进了待办（画流程图评估），这比单纯加缓存进了一步。积分活动从 MySQL 迁 PG 的决定，则是把"技术栈收敛"从口号落成具体动作。今天真正的价值，不在于解决了几个问题，而在于把每一类问题的"止血"和"治本"都分别排了责任人、排了时间。