过去的36个小时我们都在干什么哪？我们是不是还没从“新冠”的阴影中清醒过来，依然沉寂在疫情的紧张和焦虑中？是不是好不容易熬到了周末，可以不用经历比平日里更加忙碌的“在线办公”的日子哪？
然而就在这过去的36个小时中，有人甚至顾不得病毒的危害，全身心的投入到了另一场没有硝烟的战斗中。这场战斗的残酷程度，不亚于与新冠病毒搏斗的场面。
这就是微盟团队。可以说，在这36小时中，微盟与死神已经碰面，几乎快去阎王那里报道了。
事情还得从几天前说起，就在几天前，国内中小企业线上服务的领军企业微盟忽然遭遇了一场“噩梦”，生产环境大批量的服务器无法响应，很多中小企业的服务页面再也无法访问了。包括集群环境也已经失效了。于是受其影响，千百万家中小企业的在线服务全部停止服务。一天之内微盟的市值蒸发了14亿，甚至濒临破产的边缘。可以说，这是笔者有生以来听说过的在国内发生的最为恶劣的网络事件之一，直逼2007年的熊猫烧香病毒。
事情的起因竟是因为微盟内部的一名程序员“删库跑路”了。以往“删库跑路”的事件倒是屡见不鲜，可从来没有哪次“删库跑路”事件像这次一样对互联网业造成了如此大的冲击。至于这名程序员为什么会这么做，就让我们等待一段时间以后的审讯结果吧。
不过幸运的是，就在昨夜，在腾讯与微盟共同的努力下，微盟的数据算是大致恢复了，大部分的中小企业得以继续享受微盟的在线服务了。具体过程不再赘述，大家可以自行上网八卦一下。
笔者在这里只是想反思一下，为什么身为国内中小企业线上服务的领军企业，竟会栽在这样一个低级问题上哪？我想，微盟内部真正的管理问题估计不会公之于众，只会吃一堑长一智，确保下次不会因为程序员删库跑路而栽倒了。
作为一个IT公司来说，往往有会很多运行数据，这些数据基本都保存在数据库中，每时每刻都在发生着变化。而公司的各项业务均依赖于这些数据，所以数据就超越了程序成为了一个企业的“命根子”。程序没了还可以重写，运行的真实数据一旦没了，可就一点儿办法都没有了。
幸好，为了防止这种情况发生，数据库软件都提供了数据备份和恢复机制，可以在数据库发生故障或者数据被损坏时将数据恢复到故障前的版本，从而将用户的损失降到最低。数据库的备份机制有“自动”和“手动”两种模式。“自动模式”就是给数据库软件设置一个自动备份策略，让它根据策略自动定时进行备份。比如每月或者每周备份一次。因为数据备份耗费的空间和时间都较长，所以一般的企业因为没有那么多的存储资源，都采用“整库备份+定时增量备份”的模式。也就是在一段时间内只让数据库进行一次完整备份，然后每天(每周/每月)只备份发生变化的部分。这样既可以保证新的数据尽可能的不丢失，又不至于每次备份都占据大量的存储空间。
微盟作为领军企业，自然是有自己的一套备份机制的。可为什么花了整整的36+个小时才把数据恢复回来哪？据笔者查阅相关资料，发现微盟并没有采用传统的数据库恢复的方式恢复丢失的数据，而是走了另一条路——将被删除文件还原回来。
这是什么意思哪？我们都知道，计算机中的文件可以被删除掉(也就是从回收站里也被删除了)，一旦被删除掉，用户也就无法再恢复文件了。所以只好自认倒霉了。
别着急，这只是一般人的困惑。对于计算机“高手”来说，就没有那么棘手了。这要从计算机的数据存储原理上来说。计算机存储文件时，是采用“0”或者“1”来记录信息的。具体来说，就是无论采用的是何种存储介质，最终都会将数据转换为“0”或者“1”存储在存储介质上。比如，对于数字5，可以用101来表示；对于数字59，可以用111011来表示。然后把这些0和1的组合按顺序写入到介质上。以光盘为例，空白的光盘可以看成是一个平整的面，上面没有任何瑕疵。人们在这个面上划定了规定数量的跑道。于是，计算机开始写数据了。如果遇到了0，就不做处理；如果遇到了1，就往这个面上打个坑……以此类推。这还没完，因为我怎么知道这次写的数据从哪个点儿开始打的，打到什么位置结束？这些位置信息也得记录下来，否则一旦有多次写入操作，就不知道之前写的数据从哪里去读了。这样在读取数据的时候，只需要首先读取信息的起止位置(学名叫“文件分区表”)，找到起始位置后再按照顺序读取每个位置有没有坑就可以把信息原样读取出来了。
而删除文件是在做什么操作哪？直觉上，我们会认为就把上面的过程反过来处理一遍好了，就是把是1的地方抹平(因为光盘被烧刻下去的部分无法再修复，所以一般的光盘是一次性写入，无法恢复成初始状态的)，这样就把介质恢复成初始状态了。
这种办法一定是没问题的，但这样会产生一个问题——因为写入过程是缓慢的，所以删除过程依旧会如此漫长。于是有人就在想：既然写入数据需要将数据的起始位置和终止位置记录下来，并且标记为被占用。那只要把这些被占用的区域标记为未占用不就相当于把文件删除掉了吗？下次再写入数据时反正要重新打坑，所以不用费时费力地把数据区域“抹平”了。聪明！于是不论什么操作系统，都是这样处理文件的删除操作的。
这就给数据恢复带来了一线生机。只需要挨个扫描一遍数据区域，把“有坑”的位置再提取一遍就可以了。没错！这就是数据恢复软件所做的事情。当然，这样做是有失败的可能的。因为被删除的区域会被操作系统再次利用，这样一旦有新的数据写入到这片区域里，那么恢复出来的数据也不再是原来的了。这样对于一般的文字性的数据没有太恶劣的影响(顶多经书不全么)，但是对于数据库文件来说，可就是致命的影响了，有可能导致恢复回来的整个文件都不能再被使用，就跟没恢复出来一样。
所以本次微盟采用的就是这种最“靠谱”的方式。这样可以最大限度地恢复最近一次的数据。当然，这种操作也存在一定的提取失败的风险，但至少可以尝试一下。实在不行了，再去用最近一次的数据库备份来恢复数据。
这就是微盟36个小时做的事情，可谓惊心动魄。幸好，恢复过程还算顺利，据说大部分的内容都回来了。
回过头来，微盟该反思一下，为什么如此重要的数据，居然被一个小小的程序猿给轻松删掉了。这里面就牵扯到管理及授权机制的问题了。
一般说来，只要是上了一定规模的软件公司或者机构，都是要由专人来负责数据库维护的(学名叫“DBA”)，只有他才具有数据库的最高权限，才有可能做到“删库跑路”。而能到这个位置的人，都是有公司“干股”的，而且精神绝对不会不正常。所以不是有国仇家恨是不会“删库跑路”的。而普通的小程序猿们是没有对整个数据库的删除权限的，顶多只能删除自己有权限的个别数据库。在IT行业，这叫数据的“分级管理”。就是什么级别的人只能干该级别对应的事，除非他盗取了DBA的账户和密码。即便这样，管理完善的公司或机构对于DBA账户的登录位置也有着严格的要求，必须在指定的机器上才能登录。这就进一步确保了数据库的安全，即便DBA的账户及密码不小心被盗了，也只能在领导或摄像头的眼皮子底下才能删库。这样第一时间就会被抓现行。
再退一步，即便数据库真的被删除了，还有上面提到的数据库备份文件。还可以用这些文件来将数据恢复到最近的一次备份时间。据说，微盟这个程序猿好狠心，连所有的备份文件都删除了。所以，微盟才迫不得已采用恢复被删除文件的方式来恢复数据。
OMG！微盟的管理这是有多么混乱呀！昨天正好听马未都老先生讲述1983年马王堆汉墓被盗的故事。说当时刚出土的文物被陈列在了博物馆里。有天夜里，一名名叫“许反帝”的17岁“不良少年”惦记上了这批无价的国宝。于是偷偷潜入了博物馆中，用大榔头将博物馆陈列柜上面的玻璃一一砸碎，将自己觉得值钱的文物装了麻袋中。砸柜台这一过程持续了很长时间居然都没有人发现异常。装满了一麻袋文物后，这名少年居然堂而皇之地走到大门口，要求门卫给开门。门卫看都不看一眼，居然嫌弃他加班太晚了，就这么着将罪犯和文物给放了出去。最后罪犯虽然被抓住了，但一件无价之宝——两件直裾素纱襌衣中的一件被许母所毁，再也回不来了。试想如果在报警器等技术手段失灵而无法阻止窃贼以后，还是可以通过保安、巡视人员等管理手段进行弥补的，窃贼也不会得逞的。然而当时的管理意识就是这么薄弱。
类似的事情还发生在巴黎圣母院，人类最爱的蒙娜丽莎也曾遭此劫难。
所以，在一个公司或者单位的内部，数据安全管理机制也是非常非常重要的。微盟在管理上跟马王堆文物所在的博物馆所犯的问题一样，居然将DBA的权限开放给了普通的程序猿，并且没有将数据库的备份文件进行异地灾备。于是一旦出现问题，就无法弥补了。还好，还有最后一线生机——磁盘被删文件的恢复。不然，微盟恐怕真的就凉凉了。
笔者又想起了前年发生在国外一个互联网巨头公司的一个事，该公司使用MongoDB来存储用户的资料。可是MongoDB默认是不需要设置访问密码的。而该公司真的心大的没有给MongoDB设置访问密码。于是有一天，该公司的MongoDB数据库被一个小黑给黑掉了，数以万计的客户资料被泄露。这家公司也遭遇了自成立以来最大的危机。
我想，微盟的这次危机应该会给国内乃至世界的IT公司敲响了警钟，让大家重视数据的安全问题及管理机制。如果下次哪家公司还发生类似的事情，恐怕会被大家笑掉大牙的。
PS：吐槽一句，刘慈欣先生在史诗级科幻巨著《三体》中早就把人类这个毛病淋漓尽致地揭露出来了，那就是人类终究是好了伤疤忘了疼的。所以，就让我们拭目以待，看看下一家如此心大的公司会是谁吧。
欢迎您关注头条本账号，或者关注本人的微信公众号greatgarden:
閱讀更多 greatfeather 的文章
