251105上线事故分析与总结

事故过程

1. 2025/11/05 周三下午 准备上线前端和后端代码，修复仓库名称不显示的问题、火山图片生成标题等 和 前端页面部分改动
2. 下午由彭梅进行测试服的相关测试，没有检测出问题
3. 2025/11/05 周三晚上 18:59 做了前端代码和后端代码备份
4. 2025/11/05 周三晚上 20:00 之前，做了完整的测试，但是由于没有真实订单进来，所以加入发货台部分没法测试到
5. 2025/11/06 周四早上八点左右，客户反馈有大量异常订单，是加入发货台失败的问题，系统不断重试
6. 2025/11/06 周四早上 09:36 我（黄炜）将之前的备份恢复原先状态（上线前）
7. 客户问题在脚本执行中逐渐恢复正常使用

具体原因

上线的apiService/temuApi/bg.shiporder.receiveaddressv2.get.php

这个文件当中，新增的修复仓库名称无法获取的位置出现报错，导致当前加入发货台的脚本报错

进而导致加入发货台的流程中断，大量的订单都被拥挤堵在这个阶段。

具体的报错内容是这个方法未定义，由于函数定义位置不在当前文件默认引用的路径下导致的。

反思与总结提升

1. 上线时间太晚，导致第二天凌晨真实打单的时候（集中在七点左右）有大量的订单一直处于加入发货台失败的状态，没有及时维护
   这个问题我初步想法是按照工作日（除周五外）中午十二点时，做好备份信息后尝试上线
   保证上线后有足够技术人员进行维护，也有足够的客服人员进行跟进
2. 测试覆盖范围不够广，特别是订单完整的生命流程没有测试到
   这个已经于 2025/11/06 跟孙总沟通过，将店铺 Renewal Diary （ID：634418219217255） 接入测试站，完成完整的测试流程
3. 缺少开发涉及板块和缺陷的文档 和 上线测试报告
   这部分由我（黄炜）和增鸿每次上线前编写“本次上线涉及板块范围”文档
   彭梅编写具体的两次测试文档：测试站和生产站
4. 上线流程的规范不够完善
   这个我初步想法是：
   1. 【自测完成】在开发自测完成后，总结出本次上线的功能、缺陷改动范围，包括可能影响的功能模块
   2. 【发布测试】彭梅在测试服上进行部署，完成测试站的正常访问
   3. 【测试跟进】由彭梅跟进测试站，包括整个流程（核心模块）的测试步骤，涉及改动的位置
   4. 【备份生产】备份当时的生产代码
   5. 【发布生产】将生产代码部署到生产环境
   6. 【生产测试】由彭梅二次检测，包括整个流程（核心模块）的测试步骤，涉及改动的位置
5. 没有把具体的涉及改动，可能影响的范围告知客服部分
   这块缺失了给客服反馈的具体细节，导致第二天客户反馈过来的时候，客服人员很被动
   下次上线前要针对改动提前将 整个修改文档和测试流程文档 给到 客服
6. 代码规范要确定具体的条件
   因为当前系统属于面对过程的编程系统，所以这里的函数 需要手动去引用，这里需要确定具体的引用规范
   或者逐功能逐模块去重构为新的系统