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

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

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

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

  • 擅自重启服务器
  • 修改测试环境密码,结果修改了线上的密码
  • 导入了错误的数据文件
  • 线上部署脚本,重复执行
  • 确认不需要的测试环境,找回备份
  • 线上环境和测试环境的密码相同
  • 可怕的报警问题
  • 难忘的数据导入错误

我来展开说一下。

  • 擅自重启服务器 记得刚毕业一年左右的时候,在客户现场做一个软件的版本激活,本来是需要和客户确认在中午休息的时候做一下的,结果和同事偷懒,没给客户打招呼,准备偷偷来干,想神不知鬼不觉,5分钟搞定,结果就在我们确认之后,在点击按钮要重启服务的一瞬间,客户推着门走了进来,让我们帮忙查一个紧急的数据问题,这个时候我们心都提到嗓子眼了,就差一秒,就会酿成严重的现场事故。
  • 修改测试环境密码,结果修改了线上的密码 记得在客户现场的时候,因为测试环境的账号和线上环境的账号密码不同,所以需要我做下确认,补充修改一些账号的密码,结果这个工作我给连接到了线上环境,等操作完成,发现连接错了,这个时候庆幸的是在操作前做了一下表的备份,否则几十个客户账号失效造成的影响是很大的。
  • 导入了错误的数据文件 记得在刚入行做DBA时,导入一个dump文件,有两个文件,一个是100M,一个是101M,结果就下意识按照文件大小来进行排序了,认为文件大的是更新时间最新的,稀里糊涂把旧的数据文件导入了线上的配置库,幸亏是一个初期业务,很快做了修复,但是这个事情给领导和团队带来了很大的影响,所幸的是领导是个很有原则的人,是一个以色列人,想法设法来“保护”我,帮助我走出了这个窘境。
  • 线上部署脚本,重复执行 在线上部署脚本的时候,在大半夜操作基本都是按照步骤,结果在一次线上的数据迁移中,在临近90%的时候有点飘了,没有认真检查日志,把一个数据导入脚本执行了2次,而这个过程让我整夜无眠,一直在检测进度和准备修复数据,所幸的是,我在迁移前坚持的原则,一定要保留主键和唯一性索引的原则,让这个数据导入操作具有了幂等性,躲过了一劫,算是有惊无险。
  • 确认不需要的测试环境,找回备份 很多时候我们做数据清理的时候,一般都会和业务同学确认,但是很显然,尽管我们再三确认,一旦出现数据丢失还是很被动的,之前有一个场景,业务同学确认数据不需要备份,但是还是带着一种工程师的严谨流程做了备份,结果没过几天发生了问题,真要恢复数据的时候所幸有之前的备份。所以尽管确认是不需要备份的,但是作为我们的专业角度来说,该做的工作还是需要的。
  • 线上环境和测试环境的密码相同 这个故障让我终身难忘,是一个自动化发布系统,会自动完成版本升级管理,结果预发布环境和线上环境的账号密码完全相同,结果在升级的时候执行错了,把线上环境当做预发布环境升级了,导致整个服务的数据全部回滚。所幸后来还是艰难的恢复了数据。
  • 可怕的报警问题 记得我们在做一次大规模的核心业务升级时,完成了高难度的工作,但是却偏偏遗漏了一些环境的监控报警,导致其中一个业务的数据库出现了宕机,但是DBA确实被动得知的,这个问题造成了严重的影响,而根源却完全不在技术。
  • 难忘的数据导入错误 我们在导入数据的时候,因为业务方提供的dump文件不够完整,结果导入的时候报了一些错误,但是因为不够细心,把这个错误竟然给忽略了,导致线上的数据出现了遗漏,产生了一个严重的故障。 好了,零零总总列举了一些“案底”,就是想让大家引以为戒,常在河边走,哪有不湿鞋,而看这些问题,几乎所有的问题都需要的演进和认真,认真的对待工作,不要想当然,那么你就会离哪些纠结的故障问题远一些。

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2019-07-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券