2月23日晚上到25日中午，微盟经历了惊心动魄36小时。到目前，微盟的服务仍未彻底恢复。
网友们对此的第一反应：
这波广告打的不错，营销部要感谢他！至少我之前不知道微盟~
可怕，还真有删库的，我以为就是个笑话
从sql入门到删库跑路 原来是有典故的
第一眼看成微软，心想微软怎么会出这种事，微软只损失毛毛雨几百万怎么就上了新闻。
在吃瓜群众玩笑之余，让我们还原事故：
25日中午，微盟发出声明，称这次事故系人为造成，微盟研发中心运维部核心运维人员贺某，于2月23日晚18点56分通过个人VPN登入公司内网跳板机，因个人精神、生活等原因对微盟线上生产环境进行恶意破坏。目前，贺某被上海市宝山区公安局进行刑事拘留，并承认了犯罪事实。
故障发生初期，微盟方面将故障归因于“腾讯云机房内网设备物理故障”，并表示正在联合腾讯云紧急抢修。
不过，对于这个回应，网友们似乎也不太愿意相信，因为宕机这种事确实算是一个大概率事件，即便是腾讯、网易这样的大厂也难以逃脱，但一般来说，维修时间也不超过一天，此次微盟的宕机事件已过去三天，商户的损失是难以估量的，如果真的是腾讯云的锅，影响恐怕不止是微盟的用户了。
微盟使用的是腾讯云服务，目前，腾讯云技术团队已经支援微盟。腾讯云方面对记者回应称，微盟运维事故发生后，腾讯云的技术团队已经在第一时间与微盟对齐，研究制定修复方案。“工程师们正在日夜赶工，我们将尽最大努力协助微盟降低损失。”
此前，也有公司发生过数据库崩盘事件，但大多在几小时之内就能恢复。
这一次，微盟为何长达36小时后，还是不能恢复数据？
数据恢复时间快慢，一方面是因为数据量，另一方面则是困难程度。此次微盟事件，是被删除全部数据，恢复起来是要慢一些，而且还要进行校验。
数据库的主备库都被删了，并且执行的是类似"rm -fr /"这样的操作。这种行为，基本上只能通过其他备库或物理备份来恢复了。更糟糕的是，这次事故赶上特殊情况，“大家都在家远程办公，协同起来肯定更慢，也影响了恢复速度，真是祸不单行”。
技术方面，如何防范这样的事发生呢？
权限和备份！
1、更严密的权限管理：大部分公司对运维的权限都放得比较宽，容易造成事故。
2、更可靠的备份机制：主备都是可以被删的，一旦需要从磁盘恢复，恢复时间会很慢。
3、做好防灾演练，模拟各种可能的情况，以及不同情况的组合，再针对这些情况制定不同的预案，然后在开发、测试环境尝试进行演练。
当然，也有网友指出：除了超级公司(bat)，任何一个公司都很难阻止这种故障
无论多么复杂的系统管理策略，肯定有人有最高权限，而大公司也都分了权限管理，但仍然有个别人有最高root权限，那就是核心运维和运维主管！所以这事避免不了。真实案例还有github，就是运维误删库了。国内有几家敢说比github厉害。 多少企业服务器做到了服务器命令要复核？
有果必有因
虽然我们经常开玩笑说别惹技术，否则我们来个删库跑路。
但真这么干还是很难想象：
但对于个人来说，如果这样做基本上等同于不在这行干了，算是亲手埋葬了自己的职业生涯了。
对于公司来说，基本上属于毁灭性打击。如果没有备份，那就看删的库是什么性质了，既然贴出公告，那应该是重要数据库，基本就等同于倒闭了。如果有备份，企业信用的影响也是直接的，连自己的员工都管理不好，用户怎么来信任这样的公司？
精神问题只是借口而已，公司内部有问题才是真的
删生产库，是一个技术人最绝望、也是展示内心报复情绪和态度最强烈的手段，在业界属于罕见的存在，如果换成是一位剑客来比喻，相当于吐了一口二十年的“自身精血”，也要与你奋之一战，拼个你死我活。从这方面来说，一个巴掌是拍不响的，很难说企业没有责任可以无辜的置身事外。
奉劝各位技术管理者、企业主、同事们，平时多关心关心身边的技术员，尤其是全年加班、半夜随叫随起、出了问题往往比开发还着急的运维同学。
有人推测是远程办公惹的祸
在家办公，有人是优哉游哉，划水摸鱼，也有人开会开会开会，一直开会，还有人从996变成了007…..
抛去散漫怠工不谈，有人享受远程办公的自由，但也有人不习惯远程办公的方式，无法将生活和工作分开。远程办公这件事，并不是所有人都适合，体验自然也因人而异。所以还是有那么多人，想去上班，去公司的那种。
如果远程办公给你带来了困扰，可以想办法调节自己，改变心态，适当休息和运动，不要做出过激的事情。
最后奉劝大家在被激怒时理智点
这个网友说的很中肯：
