说别人家的故障,总有点隔鞋搔痒,看人家笑话的感觉。

先说一个小故事吧,某一年三四月份,我和几个同事一起去拜见某大客户的IT总经理木总,聊大型系统的运维经验,聊我们的管控手段,木总很不屑的说,这些我们都做了好几年了……紧接着2个月发生了“由于某些原因将某数据库重启后,系统性能运行非常缓慢,后面发现原因是重启后SGA变为几百兆了,而正常是几十GB”,“某数据库出问题,需要恢复的时候,发现Veritas软件恢复的时候不支持,需要打一个补丁”,“所有的用户权限都是DBA,某天突然应用用户drop了个生产表,需要立即恢复”…..木总原以为这些数据库有备份、有流程、有规范的在运维了,事实上是情况已经不像他以为的那么好。比较幸运的是,我们的团队开始支持他们的系统。所以我们一直说,运维是个持续的过程,要靠专业的运维团队来做,而且流程规范要与时俱进更新和完善。

今天发生故障的是一家代码托管的创业公司gitlab.com,说实话我第一反应以为是github,虽然名字很像,其实不是。

简单介绍一下:

1. 工作了一天,疲惫的工程师YP同学在23点的时候,想把一个自己以为是空目录的文件夹rm –rf删除了。大概一两秒之后,YP同学突然意识到,他大爷的,是不是搞错机器了!没错,他确实搞错机器了!

2. 23点27分的时候,YP同学终止了这个操作,然后发现,310GB的数据,只剩4.5GB了,99%的数据已经被误删除。

3. 非常不幸的是,之前号称的所有备份都失效了:常规备份(说好像有,但是备份在哪不知道呢)、LVM备份(是24小时一次的。说YP在故障发生的6小时前做了一次,但从恢复进度来看,应该也是失败的)、Azure上的磁盘快照(以为做了,其实没做DB的)、S3上的备份好像也没成功、自动同步程序不稳定,也失效了。

显示恢复进度已经达到73%了,1小时5%的恢复进度,可想而知不是通过备份来做的恢复,具体恢复技术暂时不得而知。
99%数据被误删,5类备份全部失效
我们总在吹牛说,备份重于一切,备份是运维工程师的最后防线。事实上呢?这个例子告诉我们,5重防线都没卵用,因为你没去真正落地。我们在运维群里吹鼻子瞪眼的喊要做好某某检查的时候,并没有把检查结果一一确认,事情就算就做过了,反正相安无事大家也就其乐融融,然后最终悲剧一定到来。作为冲在一线的运维管理者,这种歇斯底里地没有安全感的运维意识如果没有深深刻在骨子里,墨菲小姐的邂逅通常是你最没欲望的时刻。

而且我相信,通过这样一次故障,这公司的运维团队很难再犯同样的错误了。真正值得注意的是,那些暂时还没有出过类似故障的团队或者说公司。

这次故障,从技术层面、运维层面、管理层面,我们有哪些教训可以习得?

首先从技术层面来说,这个数据库居然是用slony的,选择这个版本本身很奇怪。主流数据库不管pg也好(本次生产环境),MySQL也好,Oracle也罢,高可用配置已经是基础建议配置了,但选择一个“稳定”版本应该算是基本的技术问题吧。

其次从运维层面来说,备份脚本pg_dump失效,是因为数据库从9.2升级到9.6之后,它所需的备份目录不存在,所以备份是失败的。这东西就跟技术无关了。运维的人从来不看么?做升级这种大的动作,难道只是看升级后业务是否还能运转么?

从管理上来说,一个是重大变更操作需要实行金手指模式,不要让一个人干这种事情,老司机也会犯错,何况是半夜。另外一个,晚上工作的人,白天通常就好好休息,也就是常说的运维轮班制度。人的工资贵,但人的工资没有数据价值贵。

其实数据库运维中有太多的坑,如果你的数据真的很重要,不妨请一个专业的运维DBA,或者请一个专业的运维DBA团队更靠谱。