Debugging 解决仅在生产中出现的错误的不同方法

作为一名对整个支持和bug修复环境相对较新的年轻程序员，我从未遇到过只在Websphere环境中出现而不在localhost测试环境中出现的bug，直到今天。当我第一次收到这个bug报告时，我很困惑为什么我不能在本地主机测试环境中复制它。我决定在Websphere测试环境上进行尝试，看看会发生什么，并成功地复制了这个bug。问题是我无法对Websphere测试环境进行更改和构建。我只能对本地环境进行更改。鉴于这一障碍，有什么方法可以解决这些类型的错误。或者甚至有任何方法吗？关于如何处理此类问题，有什么建议或帮助吗？

• 完全访问测试环境的活动。能够调整、重新部署和重试会产生巨大的差异。完全有理由解释为什么没有访问权限会严重限制您的工作能力
• 确保有足够的日志记录，并使其可配置。确保日志保存足够长的时间，以便跟踪客户报告的问题，即使问题发生在几天前
• 当您最终诊断一个问题以及为什么它只发生在特定环境中时，请记录它并尝试说服您的本地系统以相同的方式运行-这将使您下次更容易诊断同一问题的另一个症状

---

简而言之，该方法是隔离和了解环境之间的差异以及哪些环境可能导致问题

检查您的本地版本。确保它与Test和Prod的版本（代码和数据库）相同。如果是，可能会影响您看到的问题的环境差异是什么？（多核、负载平衡、操作系统版本、第三个库版本）。不要在调试器中本地运行，请确保您运行的是发布版本（如果测试和生产中是这样的话），甚至可以执行本地部署，而不是从源代码生成

检查是否是特定数据导致了问题。如果可以，将数据库的副本从测试拉回到本地，看看这是否能让您重新处理问题

与其他开发人员核实。看看他们能不能重新开始。他们所处环境中的问题。与您的QA人员核实，了解他们对可能导致此类问题的原因的想法（通常情况下，他们会看到“类似”的问题，并可能给您提供线索）

---

在这一点上，如果没有任何帮助，我通常会进入禅宗的深层状态，试图理解我所缺少的东西。但是，一定有区别，你只需要找到它。

科学方法总是适用的——首先检查你的假设。如果系统不同，问题可能在于某种隐式默认值不同，或者某个函数的不同实现

在所有调试过程中，本地化是关键。你必须先找出问题所在的区域。如果您的操作系统、补丁程序、库和主软件本身都是相同的，那么可能是系统设置（套接字、文件描述符等的限制）。如果您知道您还有足够的inode、空间和内存，那么这就不是资源问题。如果计算机对您的交互式刺激几乎没有响应，则说明您的负载过高，或者您有一些失控的进程。记住每个流程需要运行什么，并确保他们得到了他们需要的

也可能是代码无法处理生产系统的负载。锁定机制是生产系统与开发/测试系统中出现问题的一个非常常见的原因，原因很简单，因为您无法生成足够的测试用例，而这些用例是您在生产中免费获得的

日志记录很容易被忽略，但我也喜欢在代码中添加许多调试值，以使调试更容易。我甚至无法计算有多少次环境变量、路径或损坏的符号链接毁了我的一天，只是想知道，如果我在运行时查看变量的值，而不仅仅是查看静态代码，这将是一个微不足道的修复

---

如果所有其他方法都失败了，

ltrace

和

strace

是真正了解引擎盖下发生的事情的最佳方式。它们不容易阅读，但一旦你习惯了如何发现和解释一些系统调用的返回值，你就会得到一个非常强大的调试工具。

日志证明了它的巨大帮助，它让我找到了它背后的模式。从现在起，对于所有调试，我一定会记住这个建议。除了日志（我比较了本地日志和测试日志），花时间注意环境中的差异，然后停下来思考我遗漏了什么并发现了错误。这对你很好。深入思考这个问题有时会受到不好的评价，但它可能非常有效