从微盟 36 小时故障,谈谈数据安全和备份这个事

阅读数:2 2020 年 3 月 16 日 20:24

从微盟36小时故障,谈谈数据安全和备份这个事

早上被微盟运维人员删库的事件刷屏了,超过 36 小时,仍未完全恢复,我花了点时间从通告的信息中做了一些深入地分析解读,分享给大家。

最主要目的还是想通过分析和建议,帮助大家如何能够避免这样灾难性故障。

从微盟36小时故障,谈谈数据安全和备份这个事

我想大家比较关心的会是下面几个关键问题:

第一,为什么恢复时间会这么久,已经过去了 36 个小时,而且至今无法完全恢复?

第二,为什么一个运维人员会有这么大破坏力,让整个公司业务都瘫痪了?

第三,以上两个问题有什么好的办法解决吗?

第四,文中提到了某云厂商,这个事跟云厂商的稳定性有什么关系吗?

我们就一个个来看一下,首先我们要结合微盟的故障通告看。

从微盟36小时故障,谈谈数据安全和备份这个事

第一个问题,为什么这么长时间还没恢复?

其实从公告中,我们可以看到,到目前为止,仍在在进行中的恢复动作就是做数据恢复。

所以不难推断,这次故障被破坏最严重的就是生产系统的数据库,而且一定是核心库,或许应用环境也被破坏掉了,但是影响不会像现在这么大。

那为什么数据恢复会花这么长时间呢?我大致推测有以下几个原因:

1、这个事件非常不幸,就是传说中删库跑路的操作,而且是极有可能是直接做了 rm -rf 或者 fdisk 这样的基本不可逆转文件删除操作,更极端可能是主备一起干掉了。

2、数据库备份没有做好,这里又分几种情况:

  • 没有备份,那好,只能从磁盘文件系统维度恢复,那一定会非常慢
  • 有备份,但是备份恢复不了,也就是备份文件不可用,没办法,还是从磁盘文件恢复
  • 有全量备份,但是无增量备份,全量有可能是一个月、一周,三天等等,这中间的增量备份没做,那也很崩溃,因为就这几天的数据一样可能会客户造成极大的损失. 从微盟这次恢复这么长时间推算,估计即使有全量,也是很长时间之前的全量了,最近几天的增量还是得从磁盘文件中恢复。
    所以,不管哪一种,只要是数据库备份机制不完善,没做过完整的恢复验证,真正要恢复的时候一定会花大量的时间找回数据。

所以,这次故障一定是这个破坏者做了非常极端的删库操作,而且还没有可快速恢复的备份,耗时超长就不难想象了。

第二个问题,为什么运维人员会有这么大的能量?

很显然,很多人都会说权限没控制好,不应该给单独一个人这么大的操作权限,同时一个人不应该有这么多业务和数据库的登陆和操作权限等等,再就是没有操作分级和审核机制等等。

这么说没错,但是这个道理,道理可不可行是要具体问题具体分析的。

从这次事件看,微盟这种规模的公司,是不太可能像大公司一样,一下招很多运维或 DBA,然后每个运维和 DBA 都严格按照不同业务授权,也就是每个 DBA 只能访问有限的业务库。

从成本角度不可能,而且招了这么多人,说实话日常也没这么多事情可以干。

所以,对于绝大多数中小型公司来说,普遍和必然的现象就是,一个运维或 DBA 管整个系统,并且拥有整个系统所有主机的最大权限,比如 root。

这种情况是这些公司的必然选择,真心没得选,所以那种说做好权限管控,要分层分级等等,这都是屁话,对微盟这种类型的公司基本不可行。

这些玩法只针对大公司有效,因为大公司有钱,有量,有事情干,招一批人,分分工,分分权限,各管各的,完全没问题。

再就是,单人或几个人共同维护一整个系统的另一个负面影响,就是上面第一个问题,没法形成一定的流程机制做事,即使有了流程机制,也没法落实执行,最后就是靠这些人的经验。

所以,对于绝大多数的中小型公司来说,是不是会遇到本次这种极端状况,真的是看命好不好,看运维和 DBA 的心情和状态好不好了。

第三个问题,就是上面两个问题有没有好的办法解决呢?

通过上面两个问题,简单总结下,就是运维人员权限太大,不受限,然后做了极端操作,又没有好的备份机制恢复,所以造成了这种极端恶劣的故障和影响。

其实再补一句,即使不是恶意,如果某个人状态不好,做了个无主观意愿的误操作,也一样会造成一样的影响。

那针对这两个问题,难道真的要认命了吗?

其实不然,就这个问题而言,我觉得还是有一些措施可以做,可以最大程度来规避的,建议如下:

1、使用云产品,微盟虽然跑在云上,但是很显然并没有直接使用云数据库产品,应该是用了云的裸金属或者是虚拟机,然后在服务器上自己搭建的 MySQL 数据库。

因为从我们使用的经验看,当前任何一家公有云厂商的数据库产品,都会有比较完善的自动备份和恢复机制,而且根本没有机会去执行 rm -rf 和 fdisk 这样极端的操作。

以云数据库的备份恢复策略为例,一般可以选择按天全量备份,甚至还可以细化到指定实例、指定库、指定表做备份和恢复。

然后云数据库产品会保留完整的 Binlog 日志,全量 +Binlong 恢复时间点确认,都是可以很快恢复的。不至于会有这长时间,这么大的影响。

这里仍然建议,如果具备条件,既然上了云,没有特殊情况,能用云产品就直接用云产品,因为云产品提供的不仅仅是产品能力,最关键的是关键时刻的容灾、应急和服务能力,这些能力,并不是所有公司都能完整建设一套,甚至是很多公司想都想不到的。

但是,到目前为止,虽然各大云厂商包括他们的产品,都还有这样那样的问题,但是从体系上,云仍然是最完善,最规范的,直接一点讲,比如 99% 的公司做的都要好。推荐一下我之前写的《云计算已经成为最大的技术专家》

2、做好备份,做好备份,做好备份。如果真心觉得自己有能力自建,那一定做好全量备份,增量备份,延迟备份,全量备份要多机房,异地备份,因为数据是核心资产,应用全删了还可以重新部署,数据没了,公司就没了,就这么简单。

就算是用了云数据库,备份文件也下载一份下来,自己在不同机房,不同云,不同地方多存几份,花不了多少钱。

3、关于权限控制,如果真的没法做到最小授权,建议上个主机安全管控软件,或者堡垒机,各个云厂商都有,类似 rm -rf 、fdisk、drop 等等这样的高危命令是可以实时拦截掉的。

说实话,这种操作我宁可屏蔽,审核上 10 遍,也允许直接操作了。管理上不用限制这么严格,但是这些底线可以通过花钱买服务规避掉,至少不会出这中灾难性的故障。

4、关于人,这个我也没有办法,再完美的技术,也防不住人。能做的有两点,尽量做些普法宣传,比如这种恶意行为,不同程度得进去蹲几年,老婆孩子跟别人跑了不说,自己的菊花还可能不保,年轻人更要慎重。有点敬畏心理,可能效果会好一些。

再就是只能是平时多关心多观察,对于运维和 DBA 好一点,如果发现异常,要及早做调整,真的,人是最不稳定的因素。另外,推荐看这篇文章吧《再好的技术,再完美的规章,也无法取代人自身的素质和责任心》

第四个问题,这个事件中,云厂商能做些什么呢?

首先,这事从信息通告中,人家微盟就明确说了,人为原因,不是云的原因,而且云是全程参与一起制定恢复方案,所以从关系上讲,我不觉得这次故障是云厂商原因导致的。

再就是,凡是脑袋绑在别人裤腰带上的稳定性建设,都是扯淡,稳定性一定是自己的事情,不是第三方谁谁谁的,这一点凡是用了云,用了公有云的公司,在内部都应该强调这个点。

那云厂商可以通过这次时间做些什么呢?就一个建议:

转变思路,不要再把自己当时是卖 cpu 核数、卖带宽、卖用户数这种销售公司,切切实实的跟客户坐到一起聊聊客户痛点,解决了客户问题,说实话,多少核、多少带宽这些都是衍生品。

就这次事件而言,跟客户介绍解决方案时,推荐上云,一定要讲到痛点上,比如不用云数据库,出了问题就是数据找不回来,用了云数据库可以有哪些机会和方案保障。

同时,从全生命周期帮用户去看 ROI,告诉客户不要光盯着资源成本,其实日常的人力成本、沟通成本、管理成本,这些隐性成本也非常高。这一点,很多客户不是没能力的问题,而是压根意识不到的问题,所以是需要不断教育和灌输的,虽然慢,但是一定会有效果。

但是如果一上来就谈要签多大单子,估计客户也不会跟你里往深里聊了,不往深里聊,那机会点怎么挖掘呢?

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/kIv2R-HI5xljY8EX4H4naw

评论

发布