2026-10-10 工作日志
卡券开箱激励项目二期评审（冷饮营销活动）
发言人：赵化龙、李宝仟、赵敏、马佳、林焕纯等 13 人；主题：对卡券开箱激励项目二期方案进行全面评审，明确各端交互逻辑与提现机制，并针对活动限制、数据治理及接口联调等遗留问题制定后续推进计划。
小结
1. 营销活动中心功能设计
- 新增代金券与配送员激励：二期新增代金券活动模板，并针对配送员开箱扫码及核销卡券新增独立激励模板，支持配置首扫、第 N 次扫码及随机红包规则。
- 扫码位置与数量限制：门店扫码位置默认开启，配送员扫码位置可按需配置；扫码数量限制支持按近几日或冰柜数量配置，需避免规则设置冲突导致无法命中。
- 黑白名单控制：新增门店黑白名单管理功能，支持手动录入或 Excel 批量导入设置封禁状态、生效时间及原因，用于控制门店参与活动资格及冰柜扫码数量限制。
- 主数据治理与兜底方案：当前业务侧无法保证在 12 月上线前完成经销商与门店的 1 对 1 主数据治理，系统需提供兜底方案以支持一个门店对应多个经销商的情况。
- 销售五段自动更新：门店基础数据新增二批门店和冰柜数量字段，后续将优化功能，实现经销商销售五段调整后门店信息的自动联动更新。
- 新增代金券核销明细表：报表模块新增经销商代金券核销明细表，支持按经销商维度查看核销门店、金额、配送员及手机号等明细数据并支持导出。
- 预警邮箱配置待确认：活动进程和发放金额达到阈值时将通过邮件预警，但预警邮箱的具体类型（内邮或外邮）及覆盖范围需进一步确认。
2. 各端交互与提现机制
- 自动提现与手动提现并存：营销活动中心调用计费接口时携带 OpenID 则触发自动提现；未携带则余额存入钱包，需配送员在 SFA 钱包页面手动提现。
- SFA 前端增加跳转入口：SFA 端在中奖页面增加"立即提现"按钮，点击后直接跳转至微信小程序获取 OpenID 并发放红包，无需再跳转至微信钱包页面。
- 核销码生成与扫码回显：智慧门店生成多张卡券的合并核销码，SFA 扫码后调用卡券中心接口回显券信息，确认核销后调用营销活动中心接口判断中奖金额。
- 多活动命中聚合展示：若一次合并核销命中多个活动，SFA 端不再展示具体活动规则明细，仅向配送员展示核销成功的总张数及总金额，明细可在钱包页面查看。
- 计费系统新增配送员记账与提现：计费系统新增配送员角色记账流水，支持自动提现及提现失败后的余额退回；提现记录中新增配送员角色分类。
- 门店卡券核销功能：门店钱包新增代金券 Tab，支持单张、批量及全量（单次最多 500 张）核销操作，并实时轮询展示核销状态。
3. 前端小程序与 SFA 功能
- 微信扫一扫快速跳转：新增微信扫一扫链路，扫描箱内码后解析 URL 并跳转至开箱扫码页面，但需用户进入页面后再次扫码以触发 AI 防作弊识别。
- 压测与数据消费要求：二期上线前需基于预计新增的 84 万月活用户进行 2.5 至 3 倍数据量压测，并确保智慧门店能实时消费门店数据服务。
- SFA 端新增核心功能模块：SFA 端新增扫码核销、排行榜、数据看板及"我的钱包"入口，其中扫码核销支持自动识别箱码与卡券核销码。
- 看板与排行榜待确认：配送员排行榜及经销商数据看板的具体展示字段与逻辑需与业务侧进一步确认。
4. 卡券中心配置规则
- 默认参数自动带入：从营销活动中心跳转至卡券中心时，发券方、可领时间、核销方及单日发放上限等参数将默认带出，无需重复配置。
- 券面额与数量限制：配置人员需手动设置优惠券名称、使用说明、券面额及总发放数量，系统将自动核算预算金额。
- 核销时间与距离限制：支持配置"领取后 N 天内核销"或"固定时间范围内核销"两种模式，并可按需勾选核销距离限制（如 1km 或 100m）。
- 草稿保存与发布：配置完成的卡券支持保存为草稿或直接发布，发布后券信息将推送至营销活动中心供奖品配置使用。
待办
- 会后与技术团队讨论并确认经销商与门店 1 对多主数据治理的兜底方案。 — @赵化龙
- 确认预警邮件的具体类型（内邮或外邮）及覆盖范围。 — @赵化龙
- 会后补充标注二期新增的活动限制规则，以便测试团队编写测试用例。 — @赵化龙
- 下午与业务侧确认微信扫一扫防作弊链路及数据看板内容。 — @任铭
- 梳理并发送 SFA 端待业务侧决议的事项及所需接口清单。 — @李宝仟
- 下午 3 点半会议上与业务侧确认 SFA 端及智慧门店端待决议事项。 — @马佳
B 端出货明细表数据误清空事故复盘（物码复盘）
主题：复盘 B 端出货明细表数据误清空事故，明确由不当使用 insert overwrite 引发的根因，确立 SR 数据库替换、全链路备份及上线评审等改进措施，并强调质量优先与生产变更敬畏原则。
小结
1. 数据恢复与事故时间线
- 数据恢复情况：截至 9 月 30 日 20:10，B 端出货明细表所有历史数据及当天数据已恢复，合计 4.9 亿条。
- 事故处理时间线：
- 10:00 开始执行修复 SQL；
- 10:10 发现异常并联系项目经理协调中台及技术监理协助；
- 10:20 紧急召开线上会议分析原因并讨论恢复方案；
- 10:50 确认修复方案，由中台回推 7-1 历史数据至临时表再恢复至正式表；
- 凌晨 2:00 近半年 2.8 亿条历史数据推送完成，重置 Kafka 分区重新消费当天数据；
- 30 日 5:00 半年内数据恢复完毕；
- 30 日 24:00 开始恢复 2 月 25 日前约 2.1 亿条历史数据，当晚完成补齐。
2. 事故根因分析
- 直接原因：使用
insert overwrite导致原有数据被覆盖，SR 的分区匹配机制未匹配到正确分区触发了覆盖逻辑。 - 操作原因：初始因数据量太大耗时过长未执行成功后改用
insert overwrite，但未充分评估风险。 - 技术选型原因：团队对 SR 这一小众数据库的机制掌握不足且缺乏运维经验。
3. SR 替换方案与技术选型
- 短期备份与演练：建立全量备份与恢复演练机制，DDL 操作前对数据全量备份并验证恢复流程。
- 长期替换方案：计划替换 SR 等小众数据库，转向云端 PaaS 服务（如 Doris 或 ClickHouse），规避团队技术掌握不足的风险。
- 业务解耦方案：不建议直接下线 SR，通过业务解耦优化架构——TP 类业务（单条插入/更新）放入专门 TP 库；报表与分析保留在 SR 或经中间层 Doris 中转后写入 SR；状态快照（盘点及查证级签收等）落盘至基础流水表供事后加工分析。
4. 生产变更管理与评审规范
- 封版管理：重大节日前严禁随意发版和接受需求变更，严守封板底线，杜绝倒排期。
- 高风险 SQL 管控：对
insert overwrite、delete等强高风险操作保持高敏感性，必要时从技术视角做禁限或特殊审批申请。 - 上线评审机制：更新上线评审表，将涉及 SR 操作、新老接口兼容性及 PDA/App 版本兼容性列为固定检查项。
- 执行红线：技术方案评审修改需经专项评估和双人复核；若测试环境按生产条件执行仍报错或异常，必须暂停执行并及时回滚。
5. 测试环境与数据验证
- 测试环境缺陷：测试环境未能复现生产问题，主要因测试数据量小、分区分布不同及部分 SQL 条件被修改。
- UAT 数据回灌方案：建议建立 UAT 或 PET 环境与生产保持一致的数据回灌机制，以便在执行重大数据调整或修复前进行完备验证。
6. 数据库备份体系建设
- 现有备份缺失：项目组此前未提出 SR 备份需求，仅依赖三副本机制和 COS 存储，未设计有效备份与还原方案。
- 整体排查要求：对渠道域所有系统的数据备份情况进行全面盘查，梳理云上 SaaS 产品默认备份与自建系统手动备份的差异，查漏补缺。
7. 后续重点工作规划
- 营销底座迁移：Q4 推进营销活动中心的底层数据和主数据比对，准备将相关子系统统一迁至同一套技术底座。
- 报表架构优化：启动明年预算包内的报表架构优化工作，前置开展相关设计与风险评估。
- SR 深度巡检：作为 SR 专家需深度介入渠道域场景，对 SR 配置、备份等运维环节进行端到端摸底与查漏补缺。
待办
- 提供 9 月 29 日技术方案评审会议的录屏片段供监理分析测试环境与生产环境差异。 — @宋洋
- 制定并落实 UAT 或 PET 环境的生产数据回灌与测试验证方案。 — @北京诺德503
- 梳理 SR 层面的端到端巡检清单，重点排查备份设计及关键配置项，查漏补缺。 — @北京诺德503
- 盘点渠道域所有系统的数据备份情况，区分自动备份与需人工处理的系统，形成清单。 — @北京诺德503
- 评估并制定
insert overwrite、delete等高风险 SQL 操作的禁限策略或特殊审批流程。 — @北京诺德503 - 更新上线评审表，将涉及 SR 操作、SFA 新老版本兼容及 PDA/App 版本兼容列为固定检查项。 — @北京诺德503
- 撰写 SR 替换为云端 PaaS 数据库的方案初版，并于下周一周二组织评审。 — @宋洋
- 在本月中旬逐步启动 SR 替换工作。 — @宋洋
- 本月安排重点人员学习 SR 机制并进行考核。 — @宋洋
- 宣贯生产变更红线，强调质量优先原则及发现问题及时回滚的要求。 — @北京诺德503
关联与提示
- 本次事故与 2026-09-04 盘点签收故障、9.11「SQL 必带分区键」属同根因链（分区键/分区匹配命中缺失）：本次是 SR 分区匹配未命中触发
insert overwrite覆盖，新增「小众数据库机制掌握不足 + 无有效备份」切面，须并读 MEMORY.md 第 5/14 条与数据修复评审红线。
StarRocks 异常数据修复方案评审（营销活动中心）
主题：评审 StarRocks 异常数据修复方案，确立使用 Java 程序结合 Stream Load 分批更新两字段的标准化路线，并指出需优化方案文档结构、完善 SQL 逻辑说明及排查历史遗留待办。
小结
1. 数据修复背景与方案决策
- 929 紧急修复未实现：因原 SQL 修复导致数据清空，中台回灌恢复数据后，原紧急修复需求尚未真正落地。
- 确立 Java 程序+Stream Load 路线：鉴于
insert into全表更新性能极慢且存在事务风险，决定采用代码分批读取备份表，通过 Stream Load 仅指定更新两个字段（出货场景与更新时间）的方案。 - 明确后续标准化原则：此后所有 StarRocks 表的数据修饰均禁止使用 SQL 直接修改，统一由 Java 程序脚本执行。
2. 待修复数据范围与逻辑验证
- 锁定两类异常场景：涉及 B 端出货明细表中约 62 万条盘点签收异常和 3.5 万条查证签收异常数据，两者无交集且为静态数据。
- 核心抓取逻辑存疑：当前用于定位 62 万条错误数据的复杂嵌套 SQL 存在重复关联风险，需进一步验证其准确性并精简查询字段。
- 业务修正目标：将特定码在 9 月 1 日之后最后一条系统出货记录的场景枚举值，覆盖为其上一条正常的出货场景。
- SQL 逻辑缺陷：当前开窗排序仅保留最新一条记录，无法精准获取"前一条"数据进行比对覆盖，且关联查询可能产生冗余数据。
3. 方案文档结构与技术规范
- 重构文档层级框架：要求技术方案先输出伪代码或文字型大流程框架（如准备输入、建表、触发程序、任务分析等），再下钻至具体 SQL 指令，禁止直接堆砌代码。
- 规范附录与明细分离：具体的建表 SQL、统计语句及 Stream Load 指令应作为附录或超链接放置于对应大步骤之下，确保方案具备可复制、可执行的标准性。
- 补充逻辑解释与验证：需在方案中详细阐述核心 SQL 的业务逻辑依据，并在测试环境空跑验证逻辑正确性，同时附上执行计划截图证明分区命中情况。
4. 遗留问题与待办跟进
- 部分历史数据遗漏：针对多次系统退货等无法批量识别的异常数据，当前方案无法 100% 修复，需确认是否影响结案及补充手工修复手段。
- 排查功能权限角色：需查明生产环境中哪些角色开通了活动管理权限，以排查相关违规操作或异常数据来源。
- 沟通文件直传可行性：需再次与学东老师沟通，确认是否可通过上传 CSV 文件方式利用 Stream Load 进行大批量数据更新，以替代写代码循环。
待办
- 重构数据修复方案文档结构，先输出伪代码级大流程框架，再将具体 SQL 指令移至附录或作为超链接下钻。 — @玉平
- 验证并精简核心嵌套 SQL 的抓取逻辑，确保准确获取"前一条"记录用于覆盖更新，并在测试环境空跑验证逻辑正确性。 — @玉平
- 在测试环境执行核心 SQL 的执行计划查询，并将证明分区命中的截图附入方案文档。 — @玉平
- 排查生产环境中哪些角色开通了活动管理权限，并汇总结果。 — @玉平
- 与学东老师沟通，确认是否可通过上传 CSV 文件方式利用 Stream Load 进行大批量数据更新。 — @玉平
- 评估多次系统退货等无法批量识别的历史数据遗漏对结案的影响，并确认是否有更完善的修复口径。 — @晓娜 @马奇
关联与提示
- 本场是 9.29 紧急修复未落地 + 10-10 物码复盘事故的后续修复方案评审，确立「SR 数据修饰禁用 SQL 直改、统一 Java 程序 + Stream Load 分批更新两字段」标准化路线，与上一场事故复盘确立的高风险 SQL 管控（MEMORY 第 16 条）呼应。