sudo rm -rf /*这代码写好了，跑吗？

别惹程序员，小心他删库跑路，一句IT界老梗了。

不过调侃归调侃，毕竟谁也不想把牢底坐穿。

老板，招程序员不，rm -rf /*那种

但是没想到的是，这两天还是真实地发生了删库事件。上海微盟这家公司的一运维人员，直接远程登陆公司内网删库了……

在经历了 36 个小时的浴血奋战之后，微盟发了个关于系统故障的通告，然而数据至今依然没法恢复。公告在此：

场主带大家简单回顾下此“骇人听闻”的事件：

• 2020年2月23日，18:56分，微盟研发中心运维部核心运维人员通过V**登入服务器，并对线上生产环境进行了恶意破坏；

• 2月23日 19 时，微盟内部系统监控报警，出现大面积服务集群无法响应；

• 2月25日7 时，生产环境和数据部分恢复，预计25日晚24点完成生产环境修复，新用户恢复业务。老用户预计到2月28日晚上才能恢复。

• 微盟事后对恶意破坏生产环境的嫌疑人进行追踪分析，成功定位到嫌疑人登录账号及IP地址，并于24日向宝山公安局报案。目前犯罪嫌疑人已被宝山区公安局刑事拘留，承认了犯罪事实。

目前，微商圈一片哀嚎，内心在流泪。

为何一个员工能破坏整个系统？

作为一家互联网技术公司，微盟在故障发生后36小时才发布公告，超48小时才能恢复小部分用户的数据，让外界也对其运维工作产生了较大质疑。

正常情况下，相对比较成熟的运维，遇到比较重大的故障，一个小时之内应该能定位出故障位置，平时的小故障可能在15分钟、30分钟以内能定位到。

而微盟在36小时后才公告事件始末，慢得匪夷所思。有大佬分析认为，微盟的商家数据迟迟未能恢复可能是因为没有一个“兜底的备份、还原方案”。

有推测称，目前微盟可能需要人工通过冗余的日志，慢慢去一条条扒历史记录，构造数据，“一旦需要人工去找数据、订正数据，目前看来48小时有可能也算短的了，一周时间都是有可能的。”

另外，数据的缺失也引发了一批商家的恐慌心理，之后也将势必流失大批量用户。

网上对此事件及当事人的分析版本很多，有恶意报复论、精神失常论、高管阴谋论……场主不做任何评价，毕竟事情发生到了无法挽回的地步，现在只能交由警察叔叔秉公办理。

这也让广大公司引以为戒，如何防止数据被删去。即从源头做好防控工作，从“娃娃”抓起。

• 简单来说，通常架构规划上需要留意，重要数据永远不要直接删去，标记为“删去”状态。
• 不能给程序的用户all privileges。Insert、delete、update各类命令的权限单独赋予。
• 应用的网络进行分层规划。接入层，应用层，数据层。数据层只对固定的应用服务器开放。数据库永远只放在内网。
• 周密的备份，即使管理员跑路也不怕~

场主也去咨询了业内资深人士，大佬表示，

对付公司删库跑路的方法也不复杂，就两点：

对员工好点，让他们别冲动！ 对自己好点，备份！备份！备份！