Debugging Strategies: A Systematic Approach to Finding Bugs — cod-ai.com

改变我调试方式的3.12亿美元错误

我仍然记得我意识到自己整个调试方法根本有问题的确切时刻。那是2011年一个星期二的凌晨2:47，我坐在我作为高级软件工程师工作的一个大型金融服务公司的战情室里。我们刚刚发现我们的交易平台中有一个错误，悄悄地错误计算了三周的货币转换。估计损失？3.12亿美元。

最糟糕的部分不是金钱，尽管这肯定已经够糟了。最糟糕的是意识到我在调查过程中四次查看了包含错误的确切文件。四次。我一遍遍地滑过它，坚信问题必须出现在更复杂、更有趣、更值得我专业知识的地方。我在寻找一个复杂的算法缺陷，而实际问题只是日期计算中的一个简单的错位错误。

那个晚上从根本上改变了我对调试的看法。在过去的18年中作为软件工程师——其中12年专注于调试复杂的分布式系统——我开发了一种系统化的方法论，帮助我以73%的速度找到错误，比我以前的临时方法快得多。更重要的是，这一系统帮助我避免了当晚我所陷入的陷阱：假设错误可能和它们存在的系统一样复杂。

如今，我在一家云基础设施公司领导一个15人的工程师团队，并且我已经培训了超过200名开发人员，教授系统化调试方法。我学到的经验是，调试并不是聪明的问题——而是方法论。这不是直觉，而是证据。绝对不是你能熬夜盯着代码多少个小时。

为什么大多数开发者调试是向后进行的

在深入系统化的方法之前，我们需要理解为什么调试本身是如此困难。在我培训开发者的经验中，我识别出大约80%的调试时间被浪费的三个根本错误。

"最昂贵的错误不是崩溃系统的错误——而是那些默默运行数周，产生细微错误并随时间累积的错误"

第一个错误是我所称的“解决方案优先调试”。这是指在收集到足够证据之前就形成关于问题的假设。你的大脑会依赖于一个理论——也许是基于你以前看到的类似错误——然后你花费数小时试图证明这个理论是正确的。我见过开发者整整一天在研究数据库连接池问题，因为他们曾看到过类似的症状，结果发现实际的问题是配置错误的负载均衡器。

第二个错误是“随机游走调试”。这是一个半随机进行更改的方法，希望能有所收获。你在这里注释掉一行，在那里添加一个日志语句，重启服务，然后看看发生了什么。在我去年与我的团队进行的一项研究中，我们发现使用这种方法的开发者解决错误所需的时间平均为4.7小时，而系统化调试者只需1.3小时。这是效率上的262%的差异。

第三个错误是我所称的“自我调试”——拒绝从简单的解释开始，因为它们似乎低于你的技能水平。这正是我处理那3.12亿美元错误时的错误。我如此确信自己面对一个复杂的问题，以至于忽视了明显的错误。我见过高级工程师花费数天调查多线程代码中的竞争条件，而实际问题只是环境变量中的一个拼写错误。

这些错误有一个共同的根本原因：它们都是情感反应，而不是逻辑过程。解决方案优先调试来自于想要显得有知识的愿望。随机游走调试来自于挫折和不耐烦。自我调试则源于自尊心。我将要分享的系统化方法完全排除了情感因素。

基础：构建你的调试工具包

在系统调试之前，你需要正确的工具。我不是在谈论花哨的调试软件——虽然这些有帮助。我在谈论的是使系统化调试成为可能的心理和实际基础设施。

首先，你需要一个可靠的方式来重现错误。这听起来显而易见，但在我的经验中，大约40%的调试时间被浪费，因为开发者没有一致的复现案例。如果你无法可靠地重现一个错误，你就无法系统地调试它。绝对如此。我曾经花了三天时间追踪一个我认为是复杂并发问题的错误，结果发现我每次都在测试不同的数据集，使得错误只是偶尔出现。

你的复现案例应该尽可能简单。如果错误发生在一个包含15个步骤的复杂用户工作流中，你的第一任务是将其减少到仍能触发问题的最小可能序列。我使用我所称的“二分搜索方法”进行复现：我去掉一半的步骤，测试，然后重复。通过这种方法，我将一个23步骤的复现案例减少到仅3个步骤，这使实际调试过程快了10倍。

其次，你需要一个合适的日志基础设施。我不是在谈论在你的代码中撒上打印语句——我是在谈论结构化、分级的日志记录，能够高效过滤和搜索。在我目前的角色中，我们使用一个集中式日志系统，这让我能追踪在47个不同微服务之间的单一请求。这种基础设施将我们的生产错误的平均解决时间从6.2小时减少到了1.8小时。

第三，你需要一个假设日志。这只是一个记录你形成的每个假设、支持或反驳的证据以及你进行的测试的文档。我使用一个带时间戳的简单文本文件。这种做法有两个好处：它防止你重复测试同一假设（我见过开发者做过多次，我已经数不清了），而且它创建了一个记录。