2026-02-03 工作日志
早会
- 09:31 #work 3倍老环境的压测过程中优化的内容，是否已经上线
- 代码分支合并什么进展
- 昨天群里说的那个问题，具体是什么情况
已帮你记录好《技术压测与优化安排》,详细内容请点击下方查看: 技术压测与优化安排 早会会议讨论了技术压测、优化方案及相关问题解决的安排，具体如下：
- 压测工作安排：
- 单接口测试：单接口测试昨晚已完成，今日需整理结果，且要将结果翻译成业务侧语言，贺阳和李杰整理后发给相关人员查看。
- 其他测试：今日上午要完成b端出货和签收不同码量的压测并得出结论，下午进行结果整理；混合测试因服务器配置（Pod）资源不足，需等腾讯购买资源完成、服务器配置升起来后开展。
- 技术优化事项：
- 主数据不停服方案：志国和陈丽、陈天乐已沟通，上午需输出结论，并跟进后续排期，包括SFA报表下的优化排期。
- TTS报警问题：TTS群里老报警，有品项需剔除，张喜今日给出评估方案。
- 云商下载问题：云商下载（SCI报表）问题评估为4个人天优化，张喜负责，今日开始接口开发，张雪写技术方案，尤其是回调部分要细化，拉着邱毅一起查看。
- b端出货明细表问题：b端出货明细表存在字段更新不及时、签收激励信息被覆盖问题，罗阳上午排查，若查不出则拉宋阳一起排查。计费相关工作梁健、周斌沟通处理。
- 测试排期相关：
- 技术优化版本回测：需对1月19号之前测完到现在期间技术优化版本修改的问题和需求进行回归测试，将此加入技术优化上线表，刘丽评估时间并同步到群里。
- 合包及资源协调：若6号上线，回归测试优先级高，小娜联系金衍MC等包的准备时间，马奇跟进此事。先等压测结论出来，再决定回归内容和时间，结果出来先发群里，若需沟通再拉会。
- 老分支压测配置情况：老分支3倍环境压测优化的大部分是配置，生产上之前已更新，PPT上未更新，将配置移到PPT上做压测，代码改动部分未上线，相关记录文档发群里查看。
- 信息同步：技术优化测试相关信息同步给青姐。
- 任务
- 压测结果整理：将单接口压测结果整理成完整版，与贺阳沟通后翻译成业务侧语言，再发给说话人 3
- TTS评估方案：针对 TTS 群里老报警需剔除品项问题给出评估方案，今日完成
- 云商问题优化：启动云商下载问题的优化，该问题评估为 4 个人天，若年前能搞定则上线；在备注中说明今天开始 SMB 接口开发，后续配合联调
- 技术方案编写：写技术方案，将回调部分细化，区分直接处理回调和定时任务回调，拉着邱毅一起查看方案并对齐内容
- 问题排查：排查 b 端出货明细表中字段更新不及时和签收激励信息被覆盖的问题，若上午无法查出，邀请宋阳一起排查
- 上线表更新：将技术优化上线的相关步骤加入整体技术优化上线表，确定加在 2 月 3 号或 2 月 4 号，告知刘丽，刘丽评估时间后同步到群里
- 时间评估同步：将技术优化版本测试所需时间评估完成，添加到技术优化上线表的 2 月 3 号或 2 月 4 号步骤中，并在群内同步结果
- 回归测试跟进：跟进压测结论与吴老师对齐事宜，结合结论及与宋洋确认的发版问题清单，确定回归测试内容和时间，若 6 号上线需提上日程
- 文档同步事宜：将优化的记录文档发群里；将技术优化测试相关事宜同步给在呼市出差的青姐
会议讨论了产品码多次出货和签收问题以及新品沙棘风味草原酸奶的数据处理问题，具体如下：
- 产品码多次出货签收问题：
- 问题表现：一个码出现两次出货且两次都签收的情况，包括不同人分别扫码和一人多次扫码，导致数据记录混乱，不知货权归属，还出现多次发放激励的问题。
- 原因分析：签收接口为异步接口，无法及时判断码是否签收过；扫码时未加锁，提交时前端仅做一次校验；营销助手推送失败重试机制可能导致多次出货；收货码不同导致系统认为是新单子，无法有效控制。
- 解决方案：将异步改实时，在提交时做二次校验；按提码控制，加强对收货码的状态控制；罗宾和德志梳理原因和解决方案发群里，必要时再开快速会议核对。
- 沙棘风味草原酸奶问题：
- 产品情况：这是市场部新增的新品，仅济源生产，只做箱和提的外码用于追溯，走流向查证场景，码格式与正常BC格式相同，域名是“草原酸奶.伊利”，用“活力伊利”查流向。
- 影响情况：该品项不在之前需求范围内，其数据导致文件解析失败，影响经典码解析，使经销商扫码提示码不存在。
- 处理方案：谦哥跟黄磊沟通该新品项需求；对11T品项暂不处理，在营销活动中心和TTS交互上做过滤；张启告知数据中台该品项暂不处理，等业务侧确定需求再处理；先加屏蔽代码保证业务出货，晚上发版，发版前群里告知；周四追中间表11T屏蔽和解析修改；张喜同步中台相关情况。
- 任务
- 校验事项同步：在测试通过后，将 b 端出货场景里 PRD 有二次校验的事情同步给前端，包括测试时让前端知晓此事。
- 单号数据查询：将两个出货单的单号发送给张喜，让其通过工具查询出货时间和处理完成时间，并根据处理情况定位问题场景。
- 条数原因排查：查看出货单重复签收的条数原因，将原因发群里；若需再确认，拉快速会议核对；已确定部分由罗宾和德志写原因和解决方案发群里
- 问题原因及方案同步：罗宾和张琪查看签到金币条数问题的原因并发送到群里，罗宾和德志将已确定的部分，包括该问题的原因和解决方案，发送到群里
- 技术问题同步：与吴老师同步技术优化版本问题，以及出货量增大问题会被放大的情况，待压测结果出来后，组织亚洲和业务侧沟通此事
- 新品需求沟通：与黄磊沟通新风味的利乐钻草原酸奶品项不在之前的需求范围内，需做码上特殊处理，因应用场景与其他品项不同，原需求未提及对应处理
- 中台事项告知：在对接数据中台的群里告知大家利乐钻的草原酸奶品项暂时不处理，因其业务逻辑与其他品项不一致，等业务侧确定需求后再处理
- 代码修改发布：修改代码，屏蔽文件中的 11T 码，让马提放码窗口，安排人修改后临时发布到线上，发前群里告知，周四追发版并屏蔽中间表的 11T，改解析
- 情况告知：告知黄磊，该品在市场上扫不出来是因未处理此场景需求，其逻辑与其他场景不同，并说明需提前打好招呼避免被指未做兼容。
- 中台同步事宜：同步中台陈奇和传希处理 11T 码的方式，即先用张喜所说方式自行处理，周四追发版并屏蔽中间表的 11T 码，同时修改解析
AI强基计划培训
- Agent Skill概念及对比：
- 概念：给agent装上可复用的操作手册，是一套结构化的任务说明书。
- 与prompt对比：prompt是一次性、临时性的提示词，对话结束后AI会忘记交代内容，下次还需重新说明；而skill可让AI拿着类似SOP手册独立完成复杂任务。
- 与MCP对比：MCP解决AI访问外部世界的连接问题，但不负责业务逻辑；skill告知AI何时、何条件触发及具体执行步骤。
- Agent Skill技术实现：
- 架构：是结构化文件，核心思想是将重复工作流程打包为agent能看懂、调用的模块，包含必须的MD文件和可选项。
- MD文件组成：元数据部分包含名字和描述，是scale的名片；另一部分是详细自然语言指令，如工作流程、输出格式要求、示例等。
- 可选项：包括Python脚本、其他工具、参考文档、文件或配置模板等。
- Agent Skill核心原理及运转流程：
- 核心原理：上下文注入和渐进式披露。启动时加载可用skills名片，匹配时注入完整指令；将过程分解，从易到难引导AI。
- 运转流程：启动时agent扫描skills名片，消耗少量TOKEN，仅知具备的能力；用户请求与skill描述匹配时，加载skill完整内容及参考文件到agent上下文窗口，避免无关信息干扰，节省TOKEN。
- Agent Skill对工作范式的影响：
- 传统模式问题：传统低代码模式搭建采购助手流程僵化，修改逻辑需重新编排，复用困难。
- Skill驱动优势：下达指令后AI自动调用工具执行，执行后可将路径整理为技能，系统自动封装能力，他人询问业务时模型自动匹配，无需授权即问即用。
- Agent Skill意义总结：
- 解决问题：prompt解决与AI说话问题，MCP解决AI连接外部能力问题，skill解决API完成任务问题。
- 未来展望：未来每个人可成为skill开发者，AI将成为个人能力数字化延伸。
系统复盘
- 会议目的与要求：
- 复盘目的：通过对点状事件复盘，找到根本原因，讨论出系统化解决方案，解决历史遗留和未来可能出现的问题。
- 责任意识：强调每个人对项目负责，杜绝置身事外，要有ownership责任心，客观公开暴露问题。
- 8月21日营销助手扫码问题：
- 问题现象：8月21日，营销助手前端扫码相关功能报错，接口故障，1000多名用户无法进行扫码查证出货和盘点操作，持续60分钟。
- 原因分析：团队误操作，暂停域名解析，导致微服务注册中心服务雪崩，中间件服务中断。
- 解决措施：恢复域名解析记录和注册中心服务，推动平台增加二次确认，规范流程，对特殊变更进行企微群同步和告警。
- 后续思考：需明确操作规范，对操作人员进行培训，考虑双人操作，评估关键操作频率，兼顾效率和体验。
- 11月17日网络中断问题：
- 问题现象：11月17日上午，网络中断约20分钟，所有操作无法进行。
- 原因分析：物理防火墙触发bug，主墙自动切换到备墙，出现严重网络丢包现象。
- 解决措施：手工将业务切回主墙，周五对bug进行补丁升级。
- 后续举措：加强设备错误日志巡检，主动跟厂商沟通补丁信息，梳理相关设备，明确责任人，定期更新和监控。
- 12月9日系统接口502异常问题：
- 问题现象：12月9日上午，登录偶发性出现系统接口502异常，多刷几次异常报错会消失，不影响正常使用。
- 原因分析：SIP服务重构部署后，集群配置无法支撑大体量，网关标准配置不足。
- 解决措施：优化网关配置，调整超时参数，优化操作系统参数，调整K8S深度机制。
- 后续思考：构建流量监控和分析机制，产品侧与业务沟通预估流量，技术人员关注业务，设置报警机制。
- 应急响应机制问题：
- 现状问题：技术团队未建立协同应急响应机制，每次出问题临时拉群。
- 建议方案：建立多角色联合运维小组，针对重点系统建立固定轮值机制，提高响应速度。
- 项目评审与监控问题：
- 评审问题：评审缺乏标准化框架和清单，技术经理评估可能不全面，执行落实不到位。
- 解决措施：建立架构评审虚拟小组，明确评审标准和要求，记录评审报告，拉通各领域评审，产品经理牵头管理过程文档。
- 1月3日扫码慢问题：
- 问题现象：1月3日下午，一线反馈扫码涉及BC相关功能慢，后停滞，影响营销助手、小智等，持续约5小时。
- 原因分析：业务侧QPS升高，资源达到峰值，服务被打爆。
- 解决措施：增加算法服务资源，提前与产品沟通并发预估，常态化监控QPS，设置告警和运维机制。
- 1月5日医疗助手登录慢问题：
- 问题现象：1月5日中午，医疗助手登录缓慢，操作集中在登录场转圈约半分钟。
- 原因分析：小兔数据量增长，基础资源可能不足，服务运行或资源使用情况导致响应慢，根因未明确。
- 解决措施：建立响应机制，系统设计增加灵活机制，要求小蜂系统加强巡检，明确上下游系统依赖和要求。
- 1月14日营销部门出货问题：
- 问题现象：1月14日早上，营销部门人员出货推送到智慧门店失败，10点前无法签收，智慧门店与营销助手出货数据不一致。
- 原因分析：管理层面未拉齐下游做全量测试，接口文档留存与线上逻辑有差异；技术层面线程池推送数据堵塞，接口字段传参错误。
- 解决措施：拉通上游进行联动测试，做好文档版本管理。
- 1月20日手机端功能问题：
- 问题现象：1月20日，手机端照片上传和报表下载失败。
- 原因分析：S3存储软限制达到上限，未纳入统一监控。
- 解决措施：研究将数据往项目高级迁移，与业务层沟通数据存储时长和方式，抽取核心数据保留。
- 任务
- 设备情况梳理：梳理机房中类似防火墙设备的老化情况、负责人、定期更新和监控方式，做成 checklist，以邮件形式设置自动触发机制，明确责任人和具体方案。
- 云资源巡检跟进：跟进云资源侧每个月常态化巡检云资源利用率的情况，给出系统客诉报告，并提供给做系统的人员
- 产品规范跟进：跟进产品同学的工作规范和要求，确保从需求池管理到各工作文档的有序推进，且产品同学对网盘文档情况清晰，技术人员对自身工作清晰。
- 事项追踪区分：追踪会议讨论的所有事情，区分一次性工作和常态化工作，如升级工作安排、并发问题处理及改进措施等情况
- 技术角色讨论：讨论技术同学在项目中扮演的角色和具体工作内容，明天开展讨论
- 网关节奏优化：拉着双方供应商团队，对小拓登录网关的节奏进行优化，确定完成时间并反馈
- 数据存储沟通：与业务层沟通数据存储标准，从产品侧核对，避免存储过多垃圾数据，将技术标准提供给财务部，抽取照片核心数据留存