热爱105℃的你教程：热爱你的Bug
热爱105℃的你教程：热爱你的Bug如果客户端收到 500，它会停止发送日志如果服务器无法解码日志文件，它会返回 500但这些都不重要——关于我你唯一需要知道的是，我爱 bug。我爱 bug 因为它们有趣。它们富有戏剧性。调试一个好的 bug 的过程可以非常迂回曲折。一个好的 bug 像是一个有趣的笑话或者或者谜语——你期望看到某种结果，但却事与愿违。日志文件从最早的开始发送日志文件从最新的开始删除
作者： Allison Kaptur
译者： yixunx
十月初的时候我在贝洛奥里藏特的巴西 Python 大会Python Brasil[1]上做了主题演讲。这是稍加改动过的演讲文稿。你可以在这里[2]观看演讲视频。
我爱 bug我目前是 Pilot.com[3] 的一位高级工程师，负责给创业公司提供自动记账服务。在此之前，我曾是 Dropbox[4] 的桌面客户端组的成员，我今天将分享关于我当时工作的一些故事。更早之前，我是 Recurse Center[5] 的导师，给身在纽约的程序员提供临时的训练环境。在成为工程师之前，我在大学攻读天体物理学并在金融界工作过几年。
但这些都不重要——关于我你唯一需要知道的是，我爱 bug。我爱 bug 因为它们有趣。它们富有戏剧性。调试一个好的 bug 的过程可以非常迂回曲折。一个好的 bug 像是一个有趣的笑话或者或者谜语——你期望看到某种结果，但却事与愿违。
日志文件从最早的开始发送
日志文件从最新的开始删除
如果服务器无法解码日志文件，它会返回 500
如果客户端收到 500，它会停止发送日志
一个存有损坏的日志文件的客户端会试着发送这个文件，服务器会返回 500，客户端会放弃发送日志。在下一次运行时，它会尝试再次发送同样的文件，再次失败，并再次放弃。最终日志目录会被填满，然后客户端会开始删除最新的日志文件，而把损坏的文件继续保留在硬盘上。
这三个 bug 导致的结果是：如果客户端在任何时候生成了损坏的日志文件，我们就再也不会收到那个客户端的日志了。
问题是，处于这种状态的客户端比我们想象的要多很多。任何有一个损坏文件的客户端都会像被关在堤坝里一样，无法再发送日志。现在这个堤坝被清除了，所有这些客户端都开始发送它们的日志目录的剩余内容。
我们的选择
好的，现在文件从世界各地的电脑如洪水般涌来。我们能做什么？（当你在一个有 Dropbox 这种规模，尤其是这种桌面客户端的规模的公司工作时，会遇到这种有趣的事情：你可以非常轻易地对自己造成 DDoS 攻击）。
当你部署的新版本发生问题时，第一个选项是回滚。这是非常合理的选择，但对于这个问题，它无法帮助我们。我们改变的不是服务器的状态而是客户端的——我们删除了那些出错文件。将服务器回滚可以防止更多客户端进入这种状态，但它并不能解决根本问题。
那扩大日志集群的规模呢？我们试过了——然后因为处理能力增加了，我们开始收到更多的请求。我们又扩大了一次，但你不可能一直这么下去。为什么不能？因为这个集群并不是独立的。它会向另一个集群发送请求，在这里是为了处理异常。如果你的一个集群正在被 DDoS，而你持续扩大那个集群，你最终会把它依赖的集群也弄坏，然后你就有两个问题了。
我们考虑过的另一个选择是减低负载——你不需要每一个日志文件，所以我们可以直接无视一些请求。一个难点是我们并没有一个很好的方法来区分好的请求和坏的请求。我们无法快速地判断哪些日志文件是旧的，哪些是新的。
我们最终使用的是一个 Dropbox 里许多不同场合都用过的一个解决方法：我们有一个自定义的头字段，chillout，全世界所有的客户端都遵守它。如果客户端收到一个有这个头字段的响应，它将在字段所标注的时间内不再发送任何请求。很早以前一个英明的程序员把它加到了 Dropbox 客户端里，在之后这些年中它已经不止一次地起了作用。
了解你的系统
这个 bug 的第一个教训是要了解你的系统。我对于客户端和服务器之间的交互有不错的理解，但我并没有考虑到当服务器和所有这些客户端同时交互的时候会发生什么。这是一个我没有完全搞懂的层面。
了解你的工具
第二个教训是要了解你的工具。如果出了差错，你有哪些选项？你能撤销你做的迁移吗？你如何知道事情出了差错，你又如何发现更多信息？所有这些事情都应该在危机发生之前就了解好——但如果你没有，你会在危机发生时学到它们并不会再忘记。
功能开关 & 服务器端功能控制
第三个教训是专门针对移动端和桌面应用开发者的：你需要服务器端功能控制和功能开关。当你发现一个问题时如果你没有服务器端的功能控制，你可能需要几天或几星期来推送新版本或者提交新版本到应用商店中，然后问题才能得到解决。这是个很糟糕的处境。Dropbox 桌面客户端不需要经过应用商店的审查过程，但光是把一个版本推送给上千万的用户就已经要花很多时间。相比之下，如果你能在新功能遇到问题的时候在服务器上翻转一个开关：十分钟之后你的问题就已经解决了。
这个策略也有它的代价。加入很多的功能开关会大幅提高你的代码的复杂度。而你的测试代码更是会成指数地复杂化：要考虑 A 功能和 B 功能都开启，或者仅开启一个，或者都不开启的情况——然后每个功能都要相乘一遍。让工程师们在事后清理他们的功能开关是一件很难的事情（我自己也有这个毛病）。另外，桌面客户端会同时有好几个版本有人使用，也会加大思考难度。
但是它的好处——啊，当你需要它的时候，你真的是很需要它。
如何去爱 bug我讲了几个我爱的 bug，也讲了为什么要爱 bug。现在我想告诉你如何去爱 bug。如果你现在还不爱 bug，我知道唯一一种改变的方法，那就是要有成长型心态。
社会学家 Carol Dweck 做了很多关于人们如何看待智力的研究。她找到两种不同的看待智力的心态。第一种，她叫做固定型心态，认为智力是一个固定的特征，人类无法改变自己智力的多寡。另一种心态叫做成长型心态。在成长型心态下，人们相信智力是可变的而且可以通过努力来增强。
Dweck 发现一个人看待智力的方式——固定型还是成长型心态——可以很大程度地影响他们选择任务的方式、面对挑战的反应、认知能力、甚至是他们的诚信度。
【我在新西兰 Kiwi Pycon 会议所做的主题演讲中也讨论过成长型心态，所以在此只摘录一部分内容。你可以在这里[7]找到完整版的演讲稿】
关于诚信的发现：
在这之后，他们让学生们给笔友写信讲这个实验，信中说“我们在学校做了这个实验，这是我得的分数”。他们发现 因智力而受到表扬的学生中几乎一半人谎报了自己的分数 ，而因努力而受表扬的学生则几乎没有人不诚实。
关于努力：
数个研究发现有着固定型心态的人会不愿真正去努力，因为他们认为这意味着他们不擅长做他们正努力去做的这件事情。Dweck 写道，“如果每当一个任务需要努力的时候你就会怀疑自己的智力，那么你会很难对自己的能力保持自信。”
关于面对困惑：
他们发现有成长型心态的学生大约能理解 70% 的内容，不论里面是否有难懂的段落。在有固定型心态的学生中，那些被分配没有难懂段落的手册的学生同样可以理解大约 70%。但那些看到了难懂段落的持固定型心态的学生的记忆则降到了 30%。有着固定型心态的学生非常不擅长从困惑中恢复。
这些发现表明成长型心态对 debug 至关重要。我们必须从从困惑中重整旗鼓，诚实地面对我们理解上的不足，并时不时地在寻找答案的路上努力奋斗——成长型心态会让这些都变得更简单而且不那么痛苦。
热爱你的 bug
我在 Recurse Center 工作时会直白地欢迎挑战，我就是这样学会热爱我的 bug 的。有时参与者会坐到我身边说“唉，我觉得我遇到了个奇怪的 Python bug”，然后我会说“太棒了，我 爱 奇怪的 Python bug！” 首先，这百分之百是真的，但更重要的是，我这样是在对参与者强调，找到让自己觉得困难的事情是一种成就，而他们做到了这一点，这是件好事。
像我之前说过的，在 Recurse Center 没有截止日期也没有作业，所以这种态度没有任何成本。我会说，“你现在可以花一整天去在 Flask 里找出这个奇怪的 bug 了，多令人兴奋啊！”在 Dropbox 和之后的 Pilot，我们有产品需要发布，有截止日期，还有用户，于是我并不总是对在奇怪的 bug 上花一整天而感到兴奋。所以我对有截止日期的现实也是感同身受。但是如果我有 bug 需要解决，我就必须得去解决它，而抱怨它的存在并不会帮助我之后更快地解决它。我觉得就算在截止日期临近的时候，你也依然可以保持这样的心态。
如果你热爱你的 bug，你可以在解决困难问题时获得更多乐趣。你可以担心得更少而更加专注，并且从中学到更多。最后，你可以和你的朋友和同事分享你的 bug，这将会同时帮助你自己和你的队友们。
鸣谢！在此向给我的演讲提出反馈以及给我的演讲提供其他帮助的人士表示感谢：
-
Sasha Laundy
-
Amy Hanlon
-
Julia Evans
-
Julian Cooper
-
Raphael Passini Diniz 以及其他的 Python Brasil 组织团队成员
via: http://akaptur.com/blog/2017/11/12/love-your-bugs/
作者：Allison Kaptur[8] 译者：yixunx 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
点击“了解更多”可访问文内链接
