作为一个相对新手的支持和故障修复环境以及年轻的程序员，我从未遇到过只在Websphere环境而不是本地测试环境中发生的错误，直到今天。当我第一次收到这个错误报告时，我很困惑为什么无法在本地测试环境中重现它。我决定在Websphere测试环境中尝试一下，结果成功重现了该错误。问题是我无法对Websphere测试环境进行更改和构建。我只能在本地环境中进行更改。在这种情况下，有哪些解决这些错误的方法？或者根本没有方法学吗？有关如何处理此类问题的任何建议或帮助？
3个回答
8
- 争取完全访问测试环境的权限。能够进行调整、重新部署和重试会产生巨大的影响。合理地解释没有访问权限会严重限制您的工作能力。
- 确保您拥有足够的日志记录，并使其可配置。必须确保将日志保留足够长的时间以跟踪客户报告的问题，即使这些问题发生在几天前也要可以追踪。
- 当您最终诊断出为什么问题只在特定环境中发生时，请对此进行文档化，并尝试说服本地系统以相同的方式运行 - 这应该会更容易诊断出同一问题的另一个症状。
- Jon Skeet
1
日志证明是非常有帮助的，它让我找到了程序崩溃的模式。从现在开始，我一定会记住这个建议，用于所有的调试工作。 - faceless1_14
3
简而言之，这种方法论是为了隔离和理解环境之间的差异，找出可能导致问题的一个或多个环境。
检查本地构建。确保它与测试和生产环境具有相同的版本（代码和数据库）。如果是，有哪些环境差异可能会影响您所看到的问题？（多核，负载均衡，操作系统版本，第三方库版本）。不要在调试器中本地运行，请确保您运行的是发布版本（如果测试和生产环境也是如此），甚至可以进行本地部署而不是从源代码构建。
检查是否是特定数据引起了问题。如果可以，将测试环境的数据库复制回本地，并查看是否能够重现该问题。
与其他开发人员进行核实。看看他们是否可以在他们的环境中重现该问题。与您的QA团队进行核实，获取他们对可能导致这样的问题的想法（通常情况下，他们会看到“类似”的问题，可能会给您一些线索）。
在那时，如果没有任何帮助，我通常会进入深度禅定状态，以尝试理解我所缺失的东西。但是，肯定存在差异，您只需要找到它。
- JP Alioto
2
除了日志（我将本地日志与测试日志进行了比较），花时间注意环境中的差异，并停下来思考我可能遗漏的东西并发现错误。 - faceless1_14
很好。有时候深入思考问题会被误解，但它确实非常有效。 :) - JP Alioto
2
科学方法始终适用 - 首先检查您的假设。如果系统不同，则问题可能在于某种隐含默认值不同或某个函数的不同实现。
在所有调试过程中，本地化是关键。首先要隔离出问题区域。如果您的操作系统、补丁程序、库和主要软件本身都是相同的，则可能是系统设置（套接字、文件描述符等限制）。如果您知道您有足够的inode、空间和内存剩余，则不是资源问题。如果计算机对您的交互探测几乎没有响应，负载过高或者有一些失控进程。记住每个进程运行所需的内容，并确保它们得到了满足。
代码也可能无法处理生产系统的负荷。在生产与开发/测试系统中，锁定机制是一个非常普遍的问题，仅仅因为你不能生成足够的测试用例，这些测试用例在生产中是免费获得的。
日志记录很容易被忽视，但我也喜欢在代码中添加许多调试值，以使调试更轻松。我甚至数不清有多少次环境变量、路径或破损的符号链接破坏了我的一天，只是意识到如果我在运行时查看变量的值，而不是只查看静态代码，它将是一个微不足道的修复。
如果所有其他方法都失败了，则
在所有调试过程中，本地化是关键。首先要隔离出问题区域。如果您的操作系统、补丁程序、库和主要软件本身都是相同的，则可能是系统设置（套接字、文件描述符等限制）。如果您知道您有足够的inode、空间和内存剩余，则不是资源问题。如果计算机对您的交互探测几乎没有响应，负载过高或者有一些失控进程。记住每个进程运行所需的内容，并确保它们得到了满足。
代码也可能无法处理生产系统的负荷。在生产与开发/测试系统中，锁定机制是一个非常普遍的问题，仅仅因为你不能生成足够的测试用例，这些测试用例在生产中是免费获得的。
日志记录很容易被忽视，但我也喜欢在代码中添加许多调试值，以使调试更轻松。我甚至数不清有多少次环境变量、路径或破损的符号链接破坏了我的一天，只是意识到如果我在运行时查看变量的值，而不是只查看静态代码，它将是一个微不足道的修复。
如果所有其他方法都失败了，则
ltrace和strace是真正查看内部情况的最佳方式。它们不容易阅读，但一旦您习惯了如何发现并解释某些系统调用的返回值，您就会获得一个非常强大的调试工具。- Marcin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接