文章

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

先说一个小故事吧,某一年三四月份,我和几个同事一起去拜见某大客户的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上的备份好像也没成功、自动同步程序不稳定,也失效了。

阅读更多