Skip to content

一、今日工作总结
1、模块TOP大事
① 风控系统部署方案评审定下落点与责任边界。系统确定部署在腾讯云,因腾讯云上已集成营销活动中心、数据中台、SFA、经典小程序、智慧门店小程序5个核心业务系统。系统含50多个微服务,生产环境主要规格为4核8G、部分接口需8G内存、其余多为2核4G,初期按最低标准分配、后续按需扩容;交付采用部分源码加部分镜像,源码在内部Coding平台打包后自动推送容器集群,MQ、Kafka、MySQL、Redis由平台提供实例并交付IP与账号密码。边界上的关键口径是中间件自建与谁建谁运维:HBase、ClickHouse、Zookeeper等大数据中间件平台不提供实例,需项目组在虚拟机上自行部署,平台仅提供虚拟机运维、不对中间件性能负责。跨云带宽需评估,SFA、经典小程序、智慧门店要求实时调用,已确认仅传人员信息与经纬度等非图片数据、流量可控;数据中台侧可接受数小时延迟且数据为T+1生成。离线数据中台需从零开发,待业务表确定后再拉通数据中台团队评估Hive、Doris、Kafka选型。
② 专项5周会完成7个Agent的9月进度盘点,新增统计看板与集成YiliBuddy两项要求。各Agent已完成本月运营效果总结,后续按双周持续推进。930版本为本轮集中发布节点:BRD评审Agent完成新BRD模板改造升级、UAT测试进行中,原型评审Agent调整模型参数验证与图片唯一标记验证,技术架构评审Agent修复已知bug,三者均合并至930版本;自动备份恢复Agent集成工作已完成、初步测试无报错、预计明日完成最终测试后按计划930发布。已发布生产的两项为PRD评审Agent(优化用户反馈并新增后台管理功能)与集成测试用例评审Agent(伊智测试模块升级至1.0.1)。平台基础能力新增多模态大模型。新增要求为各Agent补统计看板,负责人排好计划后更新至在线表、完成时间不晚于10月30日;各Agent集成到YiliBuddy,周四上午安排YiliBuddy培训会,会后各自规划集成计划并更新在线表。

2、重点/基础工作
① 货权数据同步延迟问题定位到根因并确定处置口径。经销商B签收后TDS向营销活动中心的同步存在10分钟延迟,窗口期内若经销商A再次将码调拨给C,C扫码时码仍处锁定状态,货权最终错误保留在A处。会议判定该场景属违规操作下的极限情况,决定暂不投入资源解决当前个案、仅作为案例留存;同步开展调拨变更数据的定向分析,明确状态未及时变更的环节、评估优化方案,责任人明日早会用3分钟同步整体分析结论与后续优化方向。今日新增3条货权异常数据、均涉及同一经销商,需查看原因并调整规则。
② 物码早会同步的测试排期与交付口径。积分集成测试中两个遗留问题需产品侧确认排期,需立即碰头敲定解决时间;计费钱包模块运行正常,今日完成盘点任务收尾。营销活动中心围栏数据应用优化已上线,主数据与营销活动中心关于放开围栏数据接口范围限制的需求已提报,计划10月中旬实施上线;云商郑告警问题已与主数据团队确认开发排期,计划10月中旬完成发布上线。今日上午向业务侧发出正式回复,明确本年度交付范围、无法完成需顺延至明年的项目以及费用超支情况。
③ 营销活动中心三场面试评估。李超沟通一般、对业务理解不深;顾宇鹏沟通良好、业务理解较深且技术细节清楚。杨帅良的技术面试围绕本地消息表与结算服务展开两处设计:一是幂等性,本地消息表定时扫描调用结算服务时,网络抖动或宕机会导致同一批数据重复下发、产生重复结算,方案为本地消息表新增业务ID字段、扫描调用时传给结算服务,结算侧若已处理过该业务ID则直接返回处理完成标识、不再重复生成数据;二是物资下发死锁,按风险等级批量选择并下发多种物资时偶发数据库死锁导致OM异常,解法是在下发物资的查询过程中对读取操作按物资主键ID排序以规避死锁。

3、每日总结&思考:
【AI&Agent】今天专项5周会晒出7个Agent的9月进度,并加了两项要求:补统计看板、集成到YiliBuddy。进度面上,BRD评审、原型评审、技术架构评审三个Agent合入930版本,PRD评审与集成测试用例评审已发布生产,自动备份恢复Agent明日做最终测试,平台基础能力新增多模态大模型。两项要求指向同一层能力建设:统计看板与双周运营总结是一件事的两面,把Agent从“能跑”推到“能被度量”,没有固定口径的统计,运营效果只能靠人回忆,月度回归有没有衰减也就无从判断;集成到统一入口意味着各Agent的身份、权限、调用方式要收到一套约定上,这部分必须平台先行定义字段与鉴权口径,否则各团队各写各的接法,集成成本最终会落到使用侧。
【工作思考】风控系统部署评审里真正难的不是落到腾讯云、也不是50多个微服务按最低规格起步,而是责任边界。“谁建谁运维”听上去清楚,但配套的“平台不对中间件性能负责”留下了灰区:HBase、ClickHouse、Zookeeper这些恰恰是离线分析的核心依赖,平台只给虚拟机、性能自己担,上线后一旦出问题,会先在定位与责任认定上耗一轮,建议在方案阶段就把这类中间件的故障响应归属写死。另一处是离线数据中台要从零开发、具体对接方案等业务表提供后再谈,需求输入没到位就排开发,容易做到一半回头重构。

二、明日工作计划
1、模块TOP大事

2、重点/基础工作

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