故障排除工具有什么问题？

故障排除是一种用于解决故障软件的问题解决形式。 这是对问题根源的逻辑，系统的搜索，以便可以解决问题，从而使软件可以重新运行。”

Wikipedia的这个定义是用奇特的词来告诉您的-每当您的应用程序损坏时，都必须有人提出解决方案。 这样做的过程称为故障排除。

存在多种支持故障排除过程的工具：例如，探查器，线程转储可视化器和内存转储分析器。 我相信您在整个职业生涯中都使用过许多此类工具来解决当前的问题。 我还可以打赌，在很多情况下，寻找和修复根本原因的过程既耗时又压力很大。

其原因部分是由我们行业传统上使用的工具引起的。 本质上，所有故障排除工具都做同样的事情–它们浮现出有关软件内部发生的事情的更多信息 。 在这个看起来很天真的句子中，隐藏了几个主要问题。 让我们一一打开它们。

您只能对可以访问的内容进行故障排除

首先，为了对系统进行故障排除，您需要有权访问它。 这是第一个问题–在许多情况下，故障系统附近都不允许使用故障排除工具。 最常见的原因是以下原因之一：

故障排除工具倾向于公开机密信息 。 对生产部署进行故障排除时，这将成为问题。 例如，在进行堆转储时，开发人员将获得存储在堆中的信用卡信息。

故障排除工具给应用程序带来了可观的性能开销 。 再次，这在生产中成为问题，在此情况下，将分析器连接到生产JVM可以轻松地使应用程序屈服。

很难重现该问题

因此，如果无法访问生产部署，我们是否可以解决测试/开发环境中的问题行为？ 为此，必须重新创建有问题的情况。 重现问题很简单–很好。

但是在许多情况下， 在测试环境中重现问题最终是一项复杂的工作 。 例如，大多数性能事件仅发生在非常特定的使用模式期间 。 这些模式往往很难用综合测试来表示。

信息，不可操作的数据

故障排除工具为您提供了来自JVM内部的其他信息。 但是，此信息需要人为解释，以将新发现的证据与实际根本原因联系起来。

解释证据是一项复杂的任务 ，尤其是考虑到使用这些工具可能会获得的大量数据。 我的意思是，祝您好运基于以下信息找到内存泄漏的根本原因：

您现在是否应该继续使用应用程序中的字节数组？ 可能不是。 源代码中的根本原因不在眼前，需要做更多的工作。

真？

官方定义该职位始于所谓的故障排除过程，既要系统又要合乎逻辑。 我会争辩说，软件行业中的故障排除不是系统的。

根据调查数据， 发现性能问题的根本原因 平均 需要 使用四种不同的故障排除工具 。 由于每种工具仅能为特定问题类型提供证据，因此在绊倒正确的工具之前，往往会尝试几次失败的尝试。

摘要

故障排除工具继续在开发人员的工具带中占有一席之地。 对于某些类型的错误，他们会做得很好。 例如，业务逻辑中可预测的可重现错误往往与故障排除工具很好地融合在一起。 但是，对于无法随意重现错误并且可能由多种不同的潜在问题引起的情况，有更好的选择。

查找并解决与性能相关的事件的根本原因就是这样的示例之一。 它们既难以复制，又具有多种潜在的根本原因，因此非常适合下一代监控解决方案，例如Plumbr 。 Plumbr不仅要掩盖这些症状，还应将性能事件追溯到源代码或配置中的根本原因。

结果大大缩短了故障排除时间。 在实践中，这意味着减少从了解您的问题到数周内推出修复程序所花费的时间。 因此，请帮自己一个忙， 今天就免费试用 。

翻译自: https://www.javacodegeeks.com/2015/03/what-is-wrong-with-troubleshooting-tools.html