运维日，说说曾经犯过的错误

这是学习笔记的第2049篇文章

当我意识到7月24日是个节日的时候，其实就间接印证了是个劳碌命。难得的日子，参加了张甦同学的直播邀请，聊了一个小时，还不过瘾。就说点对自己曾经犯过的一些错误，也许对苦海中的你有所帮助。

别人惨痛的经历可以理解为经验，发生在自己身上的惨痛事故可以理解为教训，经验要充分学习，深刻理解，而教训需要尽可能避免。

自己也大大小小犯过不少的错误，在运维行业里，没有犯过运维错误的人可以理解是神一样的存在，归根节点是愿不愿意说的问题。

擅自重启服务器

修改测试环境密码，结果修改了线上的密码

导入了错误的数据文件

线上部署脚本，重复执行

确认不需要的测试环境，找回备份

线上环境和测试环境的密码相同

可怕的报警问题

难忘的数据导入错误

我来展开说一下。

擅自重启服务器

记得刚毕业一年左右的时候，在客户现场做一个软件的版本激活，本来是需要和客户确认在中午休息的时候做一下的，结果和同事偷懒，没给客户打招呼，准备偷偷来干，想神不知鬼不觉，5分钟搞定，结果就在我们确认之后，在点击按钮要重启服务的一瞬间，客户推着门走了进来，让我们帮忙查一个紧急的数据问题，这个时候我们心都提到嗓子眼了，就差一秒，就会酿成严重的现场事故。

修改测试环境密码，结果修改了线上的密码

记得在客户现场的时候，因为测试环境的账号和线上环境的账号密码不同，所以需要我做下确认，补充修改一些账号的密码，结果这个工作我给连接到了线上环境，等操作完成，发现连接错了，这个时候庆幸的是在操作前做了一下表的备份，否则几十个客户账号失效造成的影响是很大的。

导入了错误的数据文件

记得在刚入行做DBA时，导入一个dump文件，有两个文件，一个是100M，一个是101M,结果就下意识按照文件大小来进行排序了，认为文件大的是更新时间最新的，稀里糊涂把旧的数据文件导入了线上的配置库，幸亏是一个初期业务，很快做了修复，但是这个事情给领导和团队带来了很大的影响，所幸的是领导是个很有原则的人，是一个以色列人，想法设法来“保护”我，帮助我走出了这个窘境。

线上部署脚本，重复执行

在线上部署脚本的时候，在大半夜操作基本都是按照步骤，结果在一次线上的数据迁移中，在临近90%的时候有点飘了，没有认真检查日志，把一个数据导入脚本执行了2次，而这个过程让我整夜无眠，一直在检测进度和准备修复数据，所幸的是，我在迁移前坚持的原则，一定要保留主键和唯一性索引的原则，让这个数据导入操作具有了幂等性，躲过了一劫，算是有惊无险。

确认不需要的测试环境，找回备份

很多时候我们做数据清理的时候，一般都会和业务同学确认，但是很显然，尽管我们再三确认，一旦出现数据丢失还是很被动的，之前有一个场景，业务同学确认数据不需要备份，但是还是带着一种工程师的严谨流程做了备份，结果没过几天发生了问题，真要恢复数据的时候所幸有之前的备份。所以尽管确认是不需要备份的，但是作为我们的专业角度来说，该做的工作还是需要的。

线上环境和测试环境的密码相同

这个故障让我终身难忘，是一个自动化发布系统，会自动完成版本升级管理，结果预发布环境和线上环境的账号密码完全相同，结果在升级的时候执行错了，把线上环境当做预发布环境升级了，导致整个服务的数据全部回滚。所幸后来还是艰难的恢复了数据。

可怕的报警问题

记得我们在做一次大规模的核心业务升级时，完成了高难度的工作，但是却偏偏遗漏了一些环境的监控报警，导致其中一个业务的数据库出现了宕机，但是DBA确实被动得知的，这个问题造成了严重的影响，而根源却完全不在技术。

难忘的数据导入错误

我们在导入数据的时候，因为业务方提供的dump文件不够完整，结果导入的时候报了一些错误，但是因为不够细心，把这个错误竟然给忽略了，导致线上的数据出现了遗漏，产生了一个严重的故障。

好了，零零总总列举了一些“案底”，就是想让大家引以为戒，常在河边走，哪有不湿鞋，而看这些问题，几乎所有的问题都需要的演进和认真，认真的对待工作，不要想当然，那么你就会离哪些纠结的故障问题远一些。

而无论如何，都需要珍惜你犯过的错，因为珍惜是希望我们不要重复犯错。