作为一个对整个支持和错误修复环境相对较新的人和一个年轻的程序员，我从来没有遇到过只发生在 Websphere 环境中而不是在 localhost 测试环境中的错误，直到今天。当我第一次收到这个错误报告时，我很困惑为什么我无法在 localhost 测试环境中重现它。我决定尝试在 Websphere 测试环境中看看会发生什么，我成功地重现了这个错误。问题是我无法对 Websphere 测试环境进行更改和构建。我只能对我的本地环境进行更改。考虑到这个障碍，解决这些错误的方法是什么。或者甚至有任何方法论吗？有关如何处理此类问题的任何建议或帮助？
问问题
1822 次
3 回答
8
- 完全访问测试环境的活动。能够调整、重新部署和重试会产生巨大的变化。解释无法访问如何严重限制您完成工作的能力是完全合理的。
- 确保您有足够的日志记录，并使其可配置。确保将日志保留足够长的时间以追踪客户报告的问题，即使它发生在几天前。
- 当您最终诊断出问题以及为什么它只发生在特定环境中时，记录它并尝试说服您的本地系统以相同的方式运行 - 这应该可以更容易地诊断下一次相同问题的另一个症状。
于 2009-07-27T16:29:23.063 回答
3
简而言之，该方法是隔离和了解环境之间的差异以及可能导致问题的一个或几个。
检查您的本地构建。确保它与 Test 和 Prod 的版本（代码和数据库）相同。如果是，哪些环境差异可能会影响您所看到的问题？（多核、负载均衡、操作系统版本、第三库版本）。不要在调试器中本地运行，确保您正在运行发布版本（如果这是测试和生产中的内容），甚至可能进行本地部署而不是从源代码构建。
检查是否是可能导致问题的特定数据。如果可以的话，将数据库的副本从 Test 拉回到 Local 上，看看这是否能让您重现问题。
与其他开发人员核实。看看他们是否可以复制。他们环境中的问题。与您的 QA 人员核实，了解他们对可能导致此类问题的原因的想法（通常他们会看到“类似”问题并可能会给您一些线索）。
那时，如果没有任何帮助，我通常会进入禅宗的深层状态，以尝试了解我所缺少的东西。但是，一定有区别，你只需要找到它。
于 2009-07-27T16:37:51.130 回答
2
科学方法总是适用的——首先检查你的假设。如果系统不同，则问题可能在于某种隐式默认值不同，或某些功能的不同实现。
在所有调试过程中，本地化是关键。您必须首先隔离问题所在的区域。如果您的操作系统、补丁程序、库和主要软件本身都是相同的，那么可能是系统设置（套接字限制、文件描述符等）。如果您知道您有足够的 inode、空间和内存，那么这不是资源问题。如果计算机对您的交互式刺激几乎没有响应，则说明您的负载太高，或者您有一些失控的进程。记住每个流程需要运行什么，并确保他们得到了他们需要的东西。
也可能是代码无法处理生产系统的负载。锁定机制是生产与开发/测试系统中问题的一个非常普遍的原因，仅仅是因为您无法生成足够的测试用例，而您可以在生产中免费获得。
日志很容易被忽略，但我也喜欢在代码中添加很多调试值，以使调试更容易。我什至无法计算某些环境变量、路径或损坏的符号链接破坏了我的一天多少次，只是意识到如果我在运行时查看变量的值，而不仅仅是查看静态代码，这将是一个微不足道的修复。
如果一切都失败了，ltrace并且strace是真正了解引擎盖下发生的事情的最佳方式。它们不容易阅读，但是一旦您习惯了如何发现和解释某些系统调用的返回值，您就会获得一个非常强大的调试工具。
于 2009-07-27T17:26:16.290 回答