mysql odbc 灾难性故障_从微盟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，告诉客户不要光盯着资源成本，其实日常的人力成本、沟通成本、管理成本，这些隐性成本也非常高。这一点，很多客户不是没能力的问题，而是压根意识不到的问题，所以是需要不断教育和灌输的，虽然慢，但是一定会有效果。

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

最后，先说这么多吧，欢迎留言讨论，也可以加我微信保持联系。