从GitLab事件谈我的经历

先上个图，给各位程序猿们拜个年

悲剧年年有，今年到GitLab家。著名的GitLab这几天在Tech界登上了头条，登上的原因是因为运维人员使用了rm -rf。我相信但凡老司机看到这个都会心有戚戚然。而新司机们则一脸的茫然。

GitLab的twitter公开账号在老司机们看来显得非常的喜庆。终于，你们家也见了狗了。我们来给国内看不到小鸟的司机们瞻仰一条。

这种事情出来都是程序猿，尤其资深程序猿喜闻乐见的。因为我想每个资深程序猿在其不同的历史阶段都有过一次或者若干次的蠢事。假如你还没有干过这么蠢的事情，你都不好意思说自己是资深的程序猿。至于因为某个人不小心删了点啥啥啥导致整个网站挂掉的，其实真的很常见。君不见有一年的圣诞节，亚马逊的运维人员删了数据库导致Netflix的服务挂了，而自己家的Prime Video却运转的非常的溜吗？不知道那个删除了亚马逊数据库的人是被开了还是被升级了呢？

在现实里，我们自己的东西被删除了大不了重来，产品数据被删除，应该怎么办呢？其实这个东西大家都知道，备份。但是备份并不是这样简单的东西。一般来说，如果你不懂得狡兔三窟是什么意思的话，那你最多也只是一个新司机。肯定没有经历过在线数据被删除，备份又无法恢复的场景。

在生产环境里的备份，有两点很重要，第一是，一个备份是绝对不够的。第二是，多个备份不但是需要的而且是需要物理隔绝的。解释一下来说，就是对核心数据首先需要一个在工作环境下的备份，其次还需要一个和工作环境无关的地方的备份。这基本上是对关键数据最低的要求了。

为什么我们需要一个在工作环境下的备份，因为这个备份在物理上和在线的数据近，恢复起来快。那为什么还需要一个物理上隔绝的备份呢？因为在线工作环境里面可能把这个备份也给搞掉了。这次如果我们看GitLab的事件，明显在同一个数据中心的备份出问题了，所以需要从另外一个数据中心拷贝那个物理隔绝的备份过来。这个备份的拷贝其实要花费很长时间。如果两个备份都坏了，那我想也只能自求多福了。

我在微软上班的时候，学到的另外一个特别深刻的教训就是：自动化。要相信一点，人都是会犯错的。手一抖就可能把不该删除的删除了，该删除的没有删除。这事情我们组当年干过。所以记得有一次大组party的时候，我们的distinguish engineer说过一句话，任何东西如果需要人去介入的，那都是一个bug。当时特别的不理解，经历过几次live site的事情以后就明白了。很多时候，蠢的不是机器，其实是人。人有的时候其实和猪是同类。不要以为自己是个例外，每个程序猿，在特定的时候，都和猪一样， no exception。GitLab如果说整个维护程序是通过机器自动进行的，包括备份和恢复都是自动进行的，我相信很多问题会少很多。

GitLab的这个过程还让我看到一点是我觉得它们从来没有在真实的场景中测试过他们的灾难恢复方案。当然，首先我不确定他们有没有成熟的灾难恢复方案。但是我想很多国内外的公司都是有的。在什么情况下先做什么再做什么。只是凡是没有经过检验的灾难恢复方案，最后肯定都是不行的。我有记忆中，就有若干次这样的事情。每次实际上都是有解决方案的，但是解决方案从来没实践过。最后的结果当然是这所谓的方案一点意义也没有。

其中最有意思的事情之一是机器们过热烧坏了电源，备用电源启动以后因为过载也被烧坏了，然后整个数据中心大面积停电。你想，这个设计的好好的电源，包括有自己的柴油发电机来支撑断电，有备用电源防止过载，最后还是被我们的Cosmos的客户的workload生生烧掉了。所以拿个事情之后，所有新的数据中心上线，都得先跑一边benchmark，烧一把机器看看能不能烧坏整个数据中心。

所以三俗总结来说就是，是人就会犯错，机器才靠谱。所以我们既不需要为犯错造成损失而自责，但也不要高估了自己的智商和能力。任何的东西，尤其是容错恢复解决方案，只有经过现场的实践检验，才是真的靠谱。