误删了公司数据库，但我还是活下来了

时间 2021-01-21

英文：Zachary Kuhn，翻译：36氪

http://36kr.com/p/5129182.html

上周我与同事们进行了一次关于职业生涯中搞砸了一些事情的简短谈话。这确实会沦为他人笑柄，却更给我们带来了珍贵的教训。重要的是，我们应该分享那些曾经的错误，这样其他人就可以从其中学习。下文是最近在我身上发生的例子。

几个月前，Reddit上有一篇文章，讲了一名初级开发人员在上班的第一天就删除了生产数据库的事。我们都很憷于读到这类犯了这类无法让人忘却的大错误的文章。因为我们离这些也不远，而大多数人都是“死里逃生”。

在我的第一份工作中，一位高级数据库管理员在上班第一天就误删了生产数据库。这类故事情节比比皆是。这个团队从一个星期的备份中恢复了他导致的错误，并让他继续工作。十年后，他们依然将其作为笑点。

今年早些时候，我被派去检查一个客户的生产数据上的问题。他们进行了小范围的非公开测试，结果网站上没有显示任何内容。我想查查是否是存在漏洞或是易损性问题导致了这一结果。

我通过了生产机器上的签名环节，然后打开了数据库。内容库（articles table）内空空如也。这证实了我们在网站上看到的情况是真实的。

用户库（users table）内依然有用户数据存在。真让人奇怪。所以情况是我们丢失了所有内容，但是至少测试用户的信息依然存在。我们给出的解释是这是一个测试行为，所以这些事情有可能发生。

接下来的几分钟一片混乱。我不记得自己做了什么。我不认为自己笨到在控制台上执行了删除用户库的操作。但是事实就是这么发生了，现在后台既没有了内容库，也没有了用户库。这真实下了我一大跳。

然后我的大脑就开始转动起来思考如何解决这个问题。我真的把用户库给删掉了吗？是的。我们存备份了吗？没有。我们应该如何告诉客户这个事情？不知道。

我犹记得自己走向项目经理那里，坐在她身边，向她解释了发生了什么事情时的场面。因为我们的内容库中没有内容，这就是为什么网站上空空如也的原因。同时，我还删除了用户库。他们现在需要重新邀请所有的用户，如果他们能够弄清楚谁是谁。

我回到了自己的办公室，垂头丧气。

不过，我还是没有接受这件事。我们一开始是如何失去这些东西的？

我开始不停地往深处想。半是为了否认这件事，半是想要挽回面子。不久，我注意到了一些重要事情。

在服务器上还存在着其他5个数据库。其中一个数据库的名字和我刚才看到的数据库名字很像。

当我查看这个数据库的时候，发现所有的内容都在里面。用户库也安然无恙。结果证明，是一个配置变动无意中改变了生产设置，使站点指向了一个全新的数据库。我之前所看的用户信息是什么？种子数据。

真是谢天谢地。早上的神经紧张和胃酸让我觉得很不舒服，但是我们“恢复”了数据，并在坏消息传开之前找到了真正的问题。

从这件事中可以吸取很多教训。其中一点是关于最简单原则：我们总是在做的备份，也许是开发人员最有成效的挽救药。

我最近犯的一个错误不太引人注目。事实上，这是一个经由小错误所引起的小错误最终导致了一场混乱的故事。

我们面临的是一个时间紧迫的项目。

在初次会议上，我们团队一致认为完成它会花费比预定时间多一倍的时间。这个最后期限一开始就对我们产生影响，让我宽松地通过了身份认证部分而留有更多时间去关注客户所实际关注的功能设计。

我只是在一个单一页面测试了身份验证测试，但是当时还不了解它们将如何被组合在一起。

把它单列出来是我做的一个错误决定。我忽略了一些重要事情：

用户在登陆之后会从cookie中加载内容，但是这个页面却试图在没有任何等待的情况下进行加载。根据事件的发生顺序，用户会得到带来服务器的反映，说其是未经授权的。
身份验证也未检查令牌是否过期。如果用户不经常访问这个网站。那么当其再一次访问时，网站需要用户登出再登入才会运行。
令牌应该基于每个请求进行更新，但是我从未花费时间去理解其发生前后的规则。所以，这又产生了一个时间问题。如果我们同时发送了几个请求，根据它们返回的顺序，用户会得到那个在后来的请求中无法使用的令牌。

我们匆匆忙忙地赶着项目，却仍花费了比规定多一倍的时间。区别之处在于有更多的漏洞，并需要花更多时间去跟踪并修复这些漏洞。

这使我感到窘迫。之后因为整件事情变得比较糟糕哦而让我在公众场合感到羞愧。

我想说的是：在此之后，我花费了时间去学习认证程序。我现在了解了OAuth、JWT、刷新令牌和到期行为。我仔细研究了其他人所编写的身份验证代码。我能够在不同的语言和框架中建构身份验证程序。