梁华生--工作周报（2018-09-09）

周报 Today周报

本周回顾

• 本周主要工作，监控线上数据，及时处理线上问题，包括修复数据
• 线上值班
• 周一发布的hotfix版本存在严重问题，导致生产故障，见下文复盘。

下周计划

• 线上问题跟进 曹璐 朱方方 吴月
• 线上数据修复 涂亚松
• 主档最小订购数按区域区分 分支同goods开发分支 曹璐 周一完成
• 周二hotfix 上线 曹佳林
  
  • 添加购物车redis分布式锁时间延长到60s，过期时间可配置化
• 闭店调整 周一提测 13号上线 曹璐
  
  • 强配单，退货计划，添加购物车，修改购物车增加门店是否闭店中、已闭店前置校验
• 退货计划 12号下班提测 18号上线 F_Purch_V1.0.5 曹佳林
  
  • 门店填写退货计划，并不立马上传退货单，暂时保存退货单数据，新增实体表
  • 修改：门店提交前可对退货计划进行多次修改
  • 提交：按照暂时保存的数据，生成退货单，推送仓库， 退货计划标记为已处理
  • 定时器去掉到期推送仓库逻辑，线上老数据处理，已填写的退货计划，标记为已完结，默认已经上报，不允许再修改（待确认）
  • 前端调整 徐泽鹏
• 店间转移调整 曹璐
  
  • 转移单以转出门店的售价/金额为准，转入门店也取转出门店的售价/金额
  • 刷线上数据，转入单售价刷成转出单上的
  • navi 转移单打印页面调整 朱方方
• 推仓库修正单，补充修正单编号 曹璐
• 经由跑p增加邮件结果提醒 曹佳林
• 定时器文档维护

本周生产事故复盘

故障经过： 早上原本修复预计到货日取值错误的问题并计划早上上线，后来测试过程中发现了收货接口修改叫货单状态不正确的问题，继而测试要求一并修复上线。开发同学修复改问题，调整了update 的语句，但是update 时忘记带上where 条件，开发并没有仔细审查代码，测试过程中也并没有发现问题，继而发布生产。更新版本后，门店调用收货接口，因没有where条件限制，任何一次更新都导致全表update， 瞬间cpu全都上来了，门店当天的待处理的叫货单也全部被更新了状态。
处理过程：14:10分左右，先停掉了采购的服务，避免继续产生新的数据，dba同时停掉了从库的同步，回退升级的代码。此时开始让dba捞binlog的记录，准备回滚语句。执行回滚语句，数据库记录回到了升级发生时间（13:48分）的状态，但是发现数据库回滚的时间跟升级时间有偏差，数据库中存在同一个门店多个待处理叫货单的问题，然后手动整理删除多余的门店叫货单（16:00左右）。然后通知门店对13:49分后的操作重新进行。
思考：
1. 13点以后是门店的叫货高峰期，非十分紧急的问题，本不应该升级系统，风险没有把控好。
2. 对于开发，对代码，对上线升级缺乏敬畏之心，对提交的代码没有仔细审查。
3. 作为团队的负责人，没有把好质量关，对升级代码没有做好review工作，放任团队成员自我把控。
4. 系统已经发布上线，400+门店已经开始日常使用，线上任何一个故障都会影响到门店的日常营业，每次发布更新应当慎之又慎。
5. 尽快发布灰度流程，所有发布增加代码审核流程，在质量上增加多一道把控。