专栏首页Forrest随想录从微盟36小时故障,谈谈数据安全和备份这个事

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

2860元腾讯云代金券免费领取,付款直接抵现金,立即领取>>>

腾讯云海外服务器1折限时抢购,2核4G云主机768元/1年,立即抢购>>>

腾讯云服务器1折限时抢购,2核4G云主机899元/3年,立即抢购>>>

早上被微盟运维人员删库的事件刷屏了,超过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,告诉客户不要光盯着资源成本,其实日常的人力成本、沟通成本、管理成本,这些隐性成本也非常高。这一点,很多客户不是没能力的问题,而是压根意识不到的问题,所以是需要不断教育和灌输的,虽然慢,但是一定会有效果。

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

本文分享自微信公众号 - 聊聊SRE(forrest_thinking),作者:Cheng哥

原文出处及转载信息见文内详细说明,如有侵权,请联系 [email protected] 删除。

原始发表时间:2020-02-25

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 团队内部邮件分享-两条腿走路是不是更轻松些?

    职业习惯和素养问题,今天说这个事情,是因为最近参加各项大促保障和腾讯云割接的会议比较多,对内对外沟通非常频繁。

    赵成
  • 选择哪家云厂商,决定因素到底是什么?

    前两天在极客时间的专栏里发了一篇文章,主要讲了下蘑菇街业务为什么会选择从自运维的托管IDC模式,完全过渡到腾讯云上的混合云模式(文末“阅读原文”),文章发布后,...

    赵成
  • 云计算:拼的就是运维

    有点长,有些内容可能略显陈旧,与当前的现状已经有了很大不同,但是其中传递的思想和观点并不过时,耐心看完一定大有收获。

    赵成
  • 备份原来可以这么值钱——9亿

    相信大家最近都听说了一件非常狗血的事情,微盟出现系统故障,原因是SaaS业务数据遭一名员工“人为破坏”。

    沃趣科技
  • 保护公共云和混合云中的数据

    自从人们开始依靠技术来运营业务以来,备份,业务连续性(BC)和灾难恢复(DR)已经成为30年来IT团队工作的重要组成部分。传统解决方案是针对内部部署基础架构和结...

    静一
  • 企业如何网站平台的安全防护

    前两天,A站收到黑客攻击,近千万条用户数据外泄,其中包含用户ID、用户昵称、加密存储的密码等信息。事件发生后,A站第一时间做出回应并证实了数据泄露事件,同时也透...

    周俊辉
  • MySQL备份恢复的自动化设计

    MySQL的备份恢复是一直想要改进的地方,其中恢复是重中之重,这部分的工作要做成平台化的工作,算是有了前期的很多铺垫和延迟,最近在和同事的共同协作下,总算有了一...

    jeanron100
  • PostgreSQL 备份“半网打尽”

    因为POSTGRESQL 备份的方式很多,所以在众多的备份方式和软件中,也只能“半网打进”。

    AustinDatabases
  • MySQL数据恢复的一些补充

    如果一个线上数据库发生了问题,需要做数据恢复,作为DBA应该给自己留一些改进的余地,否则陷入两难的境地,只会让自己更加被动。

    jeanron100
  • 选择云备份提供商的6个最佳实践

    备份供应商的产品存在很多重叠,因此在创建供研究的供应商列表方面具有战略意义非常重要。为此提供以下六个最佳实践,可以帮助企业找到合适的云备份供应商。

    静一

扫码关注云+社区

领取腾讯云代金券

http://www.vxiaotou.com