上周，我与同事进行了一次简短的交谈，讨论了我在职业生涯中搞砸的事情。这确实会成为别人的笑柄，但也给我们带来了宝贵的教训。重要的是我们要分享这些错误，以便其他人可以从中吸取教训。下面是最近发生在我身上的一个例子。为什么生产数据库的意外删除如此之多？几个月前，Reddit上有一篇关于初级开发人员在工作的第一天就删除了生产数据库的帖子。我们都喜欢阅读犯了如此大的、难以忘怀的错误的文章。因为我们离这些不远了，而大多数人都是“九死一生”。在我的第一份工作中，一名高级数据库管理员在工作的第一天不小心删除了生产数据库。这类故事情节比比皆是。该团队从一周的备份中恢复了他造成的错误，并让他继续工作。十年后，他们仍然把它当笑话。今年早些时候，我被派去检查客户的生产数据问题。他们做了一个小的私人测试，网站上什么也没有出现。我想知道是否存在导致此问题的错误或漏洞问题。我在生产机器上完成了签名循环，并打开了数据库。内容库（文章表）为空。这证实了我们在网站上看到的是真实的。用户数据库（用户表）中仍然有用户数据。有点奇怪。所以情况是我们失去了一切，但至少测试用户的信息还在。我们给出的解释是，这是一个测试活动，所以这些事情可能会发生。接下来的几分钟很混乱。我不记得我做了什么。我不认为我愚蠢到在控制台上执行删除用户库操作。但事实就是这样发生了，现在后台既没有内容库也没有用户库。这真的给了我很大的飞跃。然后我的脑子就开始转了，想着怎么解决这个问题。我真的删除了用户库吗？是的。我们有备份吗？没有。我们应该如何告诉客户这件事？不知道。我仍然记得走到项目经理身边，坐在她旁边，向她解释发生了什么。因为我们的内容库中没有内容，所以网站是空的。同时，我也删除了用户库。他们现在需要重新邀请所有用户，如果他们能弄清楚谁是谁的话。我沮丧地回到办公室。尽管如此，我还是没有接受。我们最初是如何失去这些东西的？我无法停止思考。部分是为了否认这起事件，部分是为了挽回面子。不久，我注意到了一件重要的事情。服务器上还有5个其他数据库。其中一个数据库的名称与我刚才看到的相似。当我检查数据库时，一切都在那里。用户库也安然无恙。事实证明，配置更改无意中更改了生产设置，将站点指向一个全新的数据库。我之前查看的用户信息是什么？种子数据。感谢老天爷。早上的紧张和胃酸让我恶心，但我们“恢复”了数据，在坏消息传开之前找到了真正的问题所在。从这次事件中可以吸取很多教训。其中一个要点是关于最简单的原则：我们经常做的备份可能是对开发人员最有效的挽救。继续，但不要过度我最近犯的一个错误并不突出。事实上，这是一个小错误导致混乱的故事。我们面临着一个时间紧迫的项目。在最初的会议上，我们的团队同意完成计划所需的时间是原计划的两倍。这个截止日期从一开始就打击了我们，让我可以在身份验证部分放松，有更多时间专注于客户真正关心的功能设计。我只是在单个页面上测试了身份验证测试，但当时不明白如何将它们放在一起。把它挑出来对我来说是一个错误的决定。我忽略了一些重要的事情：在用户登录后，内容是从cookie加载的，但是这个页面正在尝试加载而无需任何等待。根据事件的顺序，用户从服务器得到一个响应，说它是未经授权的。身份验证也不检查令牌是否过期。如果用户不经常访问本网站。然后再次访问时，网站要求用户注销并重新登录才能运行。令牌应该根据每个请求更新，但我从来没有花时间了解这种情况发生前后的规则。所以，这又造成了一个时间问题。如果我们同时发送多个请求，按照返回的先后顺序，用户将得到不能在后续请求中使用的token。我们匆忙完成了项目，但仍然花费了规定时间的两倍。不同的是漏洞更多，需要更多的时间去追查和修复。这让我很尴尬。然后当众羞辱我，因为整件事变得更糟了。我想说的是：在此之后，我花时间学习了认证过程。我现在了解OAuth、JWT、刷新令牌和过期行为。我仔细研究了其他人编写的身份验证代码。我能够用不同的语言和框架构建身份验证程序。将失败变成未来的成功以下是我从那些我表现不佳的事情中学到的东西。如果你愿意的话，几乎所有好的结果都会由此而来。如果有人能从他的错误中吸取教训，他会比现在更好。我尽量不打第一次犯错的队友。他们通常知道自己把事情搞砸了。我也尽量不给那些不断犯同样错误的人施加压力。他们仍然值得同情。如果你在错误中做这4件事，你将继续成长：嘲笑自己。从中学习。更正错误。分享您的错误，以便其他人也可以从中吸取教训。最后，我想讲一个关于错误价值观的轶事。在1900年代初期，IBM首席执行官ThomasJ.Watson遇到一名员工，他做出了一系列错误的决定，让公司付出了沉重的代价。当沃森被问到他是否会解雇这名员工时，他回答说：“不会，我只是在他身上花了60万美元进行培训。为什么让别人白拿呢？”
