写点什么

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

  • 2020-03-16
  • 本文字数:3152 字

    阅读完需:约 10 分钟

从微盟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


2020-03-16 20:24498

评论

发布
暂无评论
发现更多内容

校企融合,打造金融科技应用人才高地

非凸科技

校企合作 非凸

企业电子文档管理需要注意的点及解决措施

小炮

文档管理

在线文本左边批量添加字符串工具

入门小站

工具

如何在 JavaScript 中让代码更加精简

devpoint

ES6 6月月更

小程序转App仅需7步

Speedoooo

ide APP开发 小程序转app 前端IDE

性能优化手记上篇之【原则】&【方法】

鲸品堂

web前端培训Vue3 TypeScript 如何实现useRequest

@零度

Vue 前端开发

浅析数字化转型与产业互联网

IT民工大叔

产业互联网 数字化转型

近一个月B站封禁直播间1874个:直播行业仍然是违规重灾区

石头IT视角

IOC思想开窍之路

留乘船

Java spring ioc

eBPF 简介

申屠鹏会

ebpf

王者荣耀商城异地多活架构设计

小虾米

架构师实战营

没有JDK和Maven,用Docker也能构建Maven工程

程序员欣宸

Java Docker maven 5月月更

服务端技术进阶(三)从架构到监控报警,支付系统设计如何步步为营

No Silver Bullet

架构 支付系统 架构设计 5月月更 监控报警

“技术商人”溯源考

IT民工大叔

华为 工程师 任正非讲话 商业意识 复合型人才

在FinClip Hackathon中夺冠是一种什么样的体验?

FinClip

小程序 黑客马拉松 finclip

在线HTML转ASP工具

入门小站

工具

智能手表的机遇与挑战

Geek_99967b

物联网

3000帧动画图解MySQL为什么需要binlog、redo log和undo log

CoderW

后端 面试题 Binlog Redo Log MySQL 数据库

SREWorks持续交付云原生化: 镜像构建

阿里云大数据AI技术

大数据 运维 云原生

高校学生请注意:想成为技术大牛,参加这个计划就够了!

科技热闻

给微信小程序配一个App如何?

FinClip

finclip 小程序转app

小程序生态构建能力,离不开UI定制自由

Speedoooo

ide 小程序ide

中小互联网公司研发效能团队规模、职能划分和优劣势分析

laofo

DevOps cicd 研发效能 持续交付 互联网公司

探密"一学就会,一用就废"的OKR

Bruce Talk

OKR 敏捷 Agile

拯救工程师,远程开发C++的四大秘笈|视频教程

OneFlow

c++ 教程分享

纪念左晖:敢为天下先(修订版)

IT民工大叔

产业互联网 数字化转型 企业家精神 左晖

架构的尽头是架构师

IT民工大叔

架构师

如何获得一场黑客马拉松的胜利?听听AWS特约评委怎么说

FinClip

小程序 黑客马拉松 finclip

CC2530 ADC配置步骤

DS小龙哥

5月月更

SAP UI5 框架的 manifest.json

Jerry Wang

前端开发 SAP Fiori SAP UI5 5月月更

从微盟36小时故障,谈谈数据安全和备份这个事_行业深度_成哥的世界_InfoQ精选文章