关于我们
运维不备份,删库不背锅
来源: | 作者:王永刚 | 发布时间: 2017-11-09 | 31 次浏览 | 分享到:
来呀,玩游戏啊,免费的,不来玩玩吗?
问:你想删库吗?
DBA:我有病啊
问:你想删库吗?
DBA:不想啊
问:你想删库吗?
DBA:要负责任吗?
问:你想删库吗?
DBA:哎呀嘛,咔咔的!这么刺激的事谁不想干!
今年的网络安全风暴似乎比以往来得更猛烈一些,勒索事件使得业界哗然,删库跑路事件也一度使得人人自危,意外的是,一直默默无闻的“删库”顿时成为业界新宠,甚至与删库有着千丝万缕的“跑路”,也开始成为验证大神和屌丝的试金石。
删库为何会发生?
1.初级删——我真的不是故意的
夜凉如水,Gitlab的同志已经分不清是白天还是黑夜,眼镜已经戴不住了,只觉得头很重,像磕了安眠药似的,于是,在下一秒敲在键盘的时候,倒头就睡了过去……
醒来时,做梦般眼睁睁看着自己误删了一个错误的服务器上的目录!!!
这是Gitlab的管理员在极度疲劳时不小心删除了一个包含 300GB 实时产品数据的文件夹,在取消 rm -rf 删除命令后该文件夹只剩下 4.5GB 数据,无可挽回的是最近的数据是在6小时前备份的……
2.中级删——我们能怎么办?我们也很无奈
2017年2月9日至2月10日下午7时30分,Instapaper服务突然中断,事故起因是2014年4月之前创建的RDS实例的2TB文件大小限制,造成了不小的损失。
3.创意删——宁为玉碎不为瓦全
2017年8月20日电 软件工程师徐某离职后因公司未能如期结清工资,便利用其在所设计的网站中安插的后门文件将网站源代码全部删除。
一时冲动不仅毁了自己的前程,还有海量的数据……
4.高级删——未解之谜
2015年5月28日11时,携程网官网出现大面积瘫痪,网页版和手机APP均不能正常使用。携程方面对此回应称服务器遭到不明攻击,在此次故障中全部遭受物理删除,且备份数据也无法使用。
一时间众说纷纭,有人爆料说是因为运营的妹子和携程的高管好了,所以遭报复删除了数据,还有人说是离职员工联手携程的竞争对手干的……但5月29日,携程发布官方情况说明称,此次事件是由于员工错误操作,删除了生产服务器上的执行代码导致。
当然,这些都是人为的车祸事故,更多的是日常正常维护删库,或许是业务繁忙后系统已装载不下,或者是供电出现问题系统崩溃了……..但不得不承认,应对删库本身似乎成为心照不宣的衡量DBA专业素质标杆。
有人说,删库后便达到了万物皆空的高度。一切不可说、不能说、不必说、也不须说。那是背后的专业素质和心理素质的高度达到让人不得不疯狂打call的地步……
不想删库的DBA,不是一个苦逼的运维大神,但不论是哪种删库,如果能跑路,那就跑吧,不能跑的,那就勤练备份和还原吧~
而从企业角度来看,如何避免有意无意类删库事件造成损失呢?

首先,要有完善、有效的备份和容灾机制。诚然很多企业都有了一整套的备份、容灾机制,但是这套备份机制能否真实奏效是需要检验的。一些大型企业,虽然投入巨资兴建灾备中心,却从未正式切换过,这样的灾备在故障来临时也很难有人拍板去进行切换,所以备份的有效、容灾手段的有效是必须确保的。注意,备份的恢复速度必须足够的考虑到,磁带的低效备份关键时刻会害死人。
其次,要有完善的故障处理策略和流程。对于不同系统,在关键时刻要优先确保什么,是要订立规则的,有了规则才能照章办事,不走错方向,不无辜背锅。几年前国内金融系统出现数据坏块,同样选择了带病修复,最终没能解决问题,同样选择了回档承担了数据损失。
再次,要有端到端融会贯通的应急机制。也就是说不仅仅技术上具备容灾应急的响应方案,从业务端同样要有对应的预案,以便应急时同步处理,区别对待。很多时候,有了业务上的应急、降级服务方案,技术层面的处理就能够从容许多。
最后,要有能够快速协同的团队资源。很多时候严重的故障,需要较大规模的专业团队协作处理,原厂商和第三方在其中都承载着重要的角色,所以关键时刻,要能够获得内外部快速及时的支持,尤其是在绵延数天的高强度工作中。
其实,最稳妥的方式,是珍惜每个DBA,创造一个轻松舒适的工作氛围,避免熬夜加班、疲劳驾驶,没有什么解决不了的事,如果有,可能是这个公司不是像宝原科技一样和睦,那些心有戚戚的DBA,也要冷静下,删库只能获得一时快感,清醒之后更多的麻烦会压得你喘不过气儿来……而且天网恢恢疏而不漏,跑路也没用…… 记住,备份重于一切。