2026-10-13 工作微博

一、今日工作总结 1、模块TOP大事 ① SR 订单写入覆盖问题定位根因，后链路事件驱动改造方案初步成型。根因：出签退同步在 1 秒内多次操作触发异步组装并发提交，Streamload 全字段更新致相同列被覆盖，业务系统提交成功后 SR 端无数据，当前仅靠定时任务跑批补救。同类故障还有 29 日补数高并发触发 MQ 限流，8:00 重试三次失败，B 端退货明细表缺 6 条签收数据，前端聚合显示 48 条、明细表实际 42 条。改造方向：后链路消息驱动改事件驱动，写入时生成队列表按序组装，中间表存 Mango 库，再经同步工具写 SR 或 Doris；补数任务改凌晨 2 点执行并严控频率，建企微告警与每日巡检兜底。张喜牵头输出排查文档，方案内部评审通过后集中过会，重点评估冷饮项目影响与回归范围。 ② 盘点任务压测评审给出上线容量结论。分页查询接口 TPS 峰值 780、响应约 70 毫秒，MySQL CPU 在 100 并发下打满为当前瓶颈，8 核 16G 配置评估可支撑液奶场景、后续可扩至 64 核线性扩容；Redis 缓存因盘点状态强实时要求暂不引入。状态更新接口实为门店维度子订单状态更新，同一门店同时间段仅一个进行中任务且状态仅能更新一次，无法构造并发数据，改由代码 Review 结合业务量评估，重点核对唯一性索引；盘点机接口历史峰值 1700，会后拉取接口地址与 APM 实际 TPS 比对；盘点数据保留约一年即可，需补冷数据归档方案并评估表增量。 ③ 网易离线计算中心 SaaS 部署沟通定调一期范围。业务场景为离线指标加工，网易从数据中台定时拉取门店进货量等数据，加工后供风控规则分析；计算分工为网易提需求、中台处理返回阈值或明细，网易不在中台集群内开发代码或自建 Hadoop 集群；数据仅支持 API 获取，千万级明细可申请管道任务推送；中间件版本对齐集团现有标准，大数据组件清单由数据智能团队提供；方案评审前置，蔡圣亚输出技术架构图与汇报材料后再约数据底座团队深入对接。 2、重点/基础工作 ① 1015 上线需求推进管理要求落地。营销活动中心、计费管理、券中心三系统由各供应商团队按管理要求维护上线评审检查清单，代码评审与上线方案评审为必填项，须在 14 日下午 5 至 6 点上线评审会前完成自查，把评审前置为过程动作而非上线前临时收材料。 ② 问题排查与文档输出规范收紧。禁止口头推测，须程序模拟推演验证结论，在测试环境复现或画图展示核心逻辑；每个问题整理独立 Word 或 Excel 文档，前置结论性说明、后置验证截图与排查过程，修复后逐条验证数据完整性方可关单。 ③ 压测与增量评估待办明确。吕杰与开发团队碰头确认状态更新接口逻辑及底层表设计、出具正式压测报告并补数据量增长风险分析；宋洋评估盘点任务表长期数据增量与冷数据迁移归档方案；宋洋与张建利比对盘点机接口实际 TPS 与历史压测差异。 3、每日总结&思考： 【AI&Agent】今日两起数据问题都走程序模拟推演、独立文档、逐条验证的闭环打法，这类结构化排查与报告产出正是技术管理智能体的标准场景；MQ 失败兜底目前靠企微告警加每日人工巡检，巡检比对类常态化工作具备交给 Agent 跑的条件，前提是口径与阈值先固定。 【工作思考】SR 覆盖与 MQ 限流是同一类病根：异步链路丢数后靠定时跑批补是事后兜底，补数自身又触发限流形成二次故障，根除要落在写入时序与限流管控；压测 TPS 达标但 CPU 打满，吞吐数字不等于资源余量，容量结论须连带配置与归档策略一起给。 二、明日工作计划 1、模块TOP大事

2、重点/基础工作

• 营销活动中心-技术梳理专项
• 物码技术支持，营销活动中心液奶、奶酪、冷饮，计费管理、券中心、帖码
• 技术管理智能体研发