微盟被“删库”后，为什么恢复时间这么长？

圈子外的同学可能觉得这个不应该很复杂，感觉不就是重装一下系统吗，数据库不是都应该有备份吗，直接恢复一下不就行了吗。其实事情远远要比你想的复杂得多。很多时候，人常常会有一个认知上的偏差，对于一个自己没有切身参与过的领域，我们会不自觉地对难度产生错误的判断。这种所谓的迷之自信，是很难克服的。

这样的例子很多，比如在看球赛的时候，有人就恨不得把电视砸了，总觉得某些球员怎么这么挫，但是真要是轮到你上场，你就能比他好吗。再比如兰州拉面，看起来也没什么难度嘛，来回几下子面就拉出来了，但要是换你上，你能拉出那碗面吗。

其实，熟悉现代软件架构和运维的同学一定知道，现在软件的架构以及部署是极其复杂的，尤其在微服务大行其道的今天，每个微服务本身就是一个集群，微服务和微服务之间还有各种依赖关系，同时每个微服务都有可能会和数据库打交道，光理清楚这些服务之间的依赖和配置就够大家受的了。

更何况这次的微盟事件不是一次局部的更新和发布，而是几乎整体架构的全局梳理，从这个意义上说，难度不亚于从头搭建整个系统，更何况是在如此巨大的业务压力和舆论压力之下。

再来看看数据库，根据目前官方的信息推测，这次的数据库应该是在生产环境的本地库发生了不可逆的删除，否则不可能会需要这么长的时间。假定本地生产库没了，那唯一的方法就是借助远程灾备的全量备份库来恢复，但这也会引发出一系列的问题，比如远程库容量大，需要大量的网络传输时间。

再比如，增量备份的完整性欠缺，另外，还会出现由于近期的数据Scheme变更引发的备份数据兼容性问题等。这些都需要研发人员和运维人员的共同推进，这就会需要更多的时间……