又又又因为上线整活了...

背景

这次问题是需求提测后配合测试上UAT环境，系统为仓库管理系统，主要上线功能点为为仓库管理划分出更细致区域便于管理；可以理解为超市由于堆积如山的商品不便管理，于是便有了货架及区域进行划分。

与超市不同的地方在于，超市的货物都是进来后出去了就可以了，不需要其它管理；而企业仓库管理了一批类似商品，商品根据属性不同划分不同分类，且需要做好商品生命周期管理，即商品会出去，出去后还会进来，不管进出商品属性都还是一样的，且有唯一码进行溯源，类似超市商品条形码。

由于要将原有仓库货品进行区域划分，就得对仓库货品进行盘点分类，预先做好规划，且须在系统上线后将历史数据进行区域划分管理；因此，这部分历史数据要选择使用EXCEL导入方式进行处理，预先导出仓库货品详细数据给到对应管理员进行分配后导入系统匹配处理；

原因

于是便有了本次的问题，由于数据使用EXCEL处理，而EXCEL数字格式会默认变成科学计数法，且数字头0会被剔除（如：0123显示为123），导致导入时数据匹配出错；因此须将已导入数据删除重新处理，于是就有了小伙伴手抖整活了...

本意是为了将已处理数据做逻辑删除，但未添加任何筛选条件，导致全表删除；虽然表中修改时间默认当前时间，如果加了条件完全可以将条件误删部分数据恢复，但全表删除就完全没法通过sql恢复了...

解决

本次虽然不是部署生产环境，且发布前我已经做了全库备份，单表恢复还是相对较快，并且不是生产环境，基本没有任何影响，之所以写这篇文章，是由于前几天我自身上线服务时出了一些问题导致实际上线实际与预期相差较大，见上一篇记一次惨痛的上线经历，给我带来一些启发

分析

结合上次问题，个人总结了一些上线注意事项：

• 数据备份：这个在发布前就已经提前做好，这一点是明智的，否则全表删除还真没法玩了...涉及到表历史数据修改一定要提前做好备份！！！
• 数据检查：在UAT环境部署时，没有对导入文件进行仔细核对，如果提前处理了数字科学计数法及头0丢弃问题就不会发生该情况。
• SQL审批：这个大部分公司在生产环境执行时都有该流程，一般使用云数据库都自带审批流，且提交SQL也会有自动校验，确保提交SQL预执行条数与预期一致，不会全表干掉，也就不会有本次问题了；当然也有一些中小型企业完全由程序员直接执行，没有任何审批流，这是相当危险的，没有确认好一个手抖那就玩完了...
• 配置文件：线上配置尽量新增而不要改动历史配置信息，即使功能一致只是换某些值，多余配置可以在上线后删除；
• 数据库字段：数据库字段只可新增，不能修改命名或删除字段；字段长度只允许扩大，不允许缩小；字段类型不可修改，特殊情况除外。
• 上线文档：这个在不同企业流程完全不同，没有任何标准可言，但最终目的都是一样，确保上线顺利，不出生产事故！！！所以上线文档相对来说是比较重要的，在开发过程中将本次修改内容记录在内，避免后续遗漏导致上线失败；同时文档经过测试验证确保与上线时一致，能减少遗漏；一些公司采取提测邮件形式执行，所有修改内容在提测邮件中体现，本质作用都一样。